From mailnull@www1.ietf.org Thu May 1 07:52:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05862 for ; Thu, 1 May 2003 07:52:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41Bv7v14360 for avt-archive@odin.ietf.org; Thu, 1 May 2003 07:57:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Bud814349; Thu, 1 May 2003 07:56:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41Bsp814261 for ; Thu, 1 May 2003 07:54:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05638; Thu, 1 May 2003 07:48:19 -0400 (EDT) Message-Id: <200305011148.HAA05638@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 01 May 2003 07:48:19 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-srtp-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : The Secure Real-time Transport Protocol Author(s) : M. Baugher et al. Filename : draft-ietf-avt-srtp-06.txt Pages : 53 Date : 2003-4-30 This document describes the Secure Real-time Transport Protocol (SRTP), a profile of the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and replay protection to the RTP/RTCP traffic. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-srtp-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-srtp-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-30150740.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-srtp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-srtp-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-30150740.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 1 15:20:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02088 for ; Thu, 1 May 2003 15:20:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41JQj616749 for avt-archive@odin.ietf.org; Thu, 1 May 2003 15:26:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JPV816649; Thu, 1 May 2003 15:25:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h411tg832167 for ; Wed, 30 Apr 2003 21:55:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02654 for ; Wed, 30 Apr 2003 21:49:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B3EG-0005Kn-00 for avt@ietf.org; Wed, 30 Apr 2003 21:51:20 -0400 Received: from isis.lip6.fr ([132.227.60.2] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19B3EA-0005Kk-00 for avt@ietf.org; Wed, 30 Apr 2003 21:51:14 -0400 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.9/jtpda-5.4+victor) with ESMTP id h411opEb024056 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Thu, 1 May 2003 03:50:51 +0200 X-pt: isis.lip6.fr Received: from doris (doris [132.227.72.166]) by tibre.lip6.fr (8.11.6p2/8.11.6) with ESMTP id h411om522250; Thu, 1 May 2003 03:50:48 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Timur Friedman To: , Colin Perkins , Stephen Casner Subject: Re: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-04.txt Date: Thu, 1 May 2003 03:50:44 +0200 User-Agent: KMail/1.4.3 Cc: Alan Clark , Ramon Caceres , "Kevin C. Almeroth" , Robert Cole , Nick Duffield , Kaynam Hedayat , Kamil Sarac , Magnus Westerlund References: <00ca01c30ddd$d250ccb0$6801a8c0@telchemy.com> In-Reply-To: <00ca01c30ddd$d250ccb0$6801a8c0@telchemy.com> MIME-Version: 1.0 Message-Id: <200305010350.44783.timur.friedman@lip6.fr> X-Scanned-By: isis.lip6.fr Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h411vC832217 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I have prepared an 05 version of the draft in response to the Last Call comments by Colin Perkins and responses from my co-editor Alan Clark. That draft will follow shortly. What follows are the details of the differences between the 04 and 05 drafts. - Timur Friedman > - The draft needs an explicit statement that the standard RTCP timing > rules apply, and that use of the extended report blocks will likely > increase the reporting interval. > > [Alan] Suggest adding to Section 1.1 paragraph 1 > "The XR report blocks defined in this document MUST be sent within the > defined guidelines for RTCP reporting intervals. In certain applications > the use of RTCP XR payloads may mean that less frequent reports are needed > in order to provide a sufficient degree of feedback on performance." The suggested text would make it a normative requirement that the already existing normative requirements be adhered to. My understanding is that the "explicit statement" Colin refers to should be on the order of clarifying remarks. I have added the following paragraph to Section 1.1, as the second to last paragraph (note that the reference numbers have changed, and reference [9] is for the RTP spec): --- begin quote --- XR packets supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6]. The introduction of XR packets into a session in no way changes the rules governing the calculation of the RTCP reporting interval [9, Section 6.2]. As XR packets are RTCP packets, they count as such for bandwidth calculations. As a result, the addition of extended reporting information may tend to increase the average RTCP packet size, and thus the average reporting interval. This increase may be limited by limiting the size of XR packets. --- end quote --- > - The second paragraph of section 1.1 talks about "broadcast" sessions. > I assume that one-to-many streaming is intended, but the text should > be clarified since broadcast IP is presumably not used. > > [Alan] Suggest either > (i) replacing "broadcast" with "one-to-many streaming" > (ii) delete broadcast as multicast will cover most cases I have replaced "any conversational, multicast or broadcast application" with "any one-to-one or one-to-many voice application". Further down in the paragraph, I have replaced "conferencing, multicast and broadcast applications" with "multicast conferencing applications". > - First paragraph of section 2: "thus backwards compatibility with" -> > "this backwards compatible with" Corrected. > - The packet format in section 2 has an "SSRC/CSRC" field; this should > presumably be "SSRC" only? (diagram and text following) Correct. I have fixed this. > - In explanation of the DLRR field in section 4.5 mentions LSR and DLSR > in a couple of places. Should be talking about LRR and DLRR? Correct. I have fixed this. > - Second paragraph of section 4.6 "The fields corresponding to unreported > parameters MUST be set to zero" may be clearer as "...MUST be present, > but are set to zero"? OK, I have made this change. > - In section 4.6, the avg_jitter and avt_ttl_or_hl fields are listed as > being the "average" of a particular statistic. Which average is used? > I assume the mean, but should clarify. Yes, the mean is used. I have changed "avg_" to "mean_", and "average" to "mean" in this section. I have also clarified that means are to be rounded to the closest possible value (integers for TTL values and RTP timestamp values for jitter). > - Section 4.7, second paragraph: "between RTCP end points" -> "between > RTP end points" > > [Alan] Agreed Corrected. > - I don't understand the first paragraph of section 4.7.2; please reword > for clarity. > > [Alan] "A burst is a period during which a high proportion of packets are > either lost in transit or discarded due to late arrival. A burst is > defined as a longest sequence that (a) starts with a lost or discarded > packet, (b) does not contain any occurrences of Gmin or more consecutive > received (and not discarded) packets, and (c) ends with a lost or discarded > packet." I have incorporated the suggested text, inserting "defined, in terms of a value Gmin", in order to introduce the value Gmin before it is used. > - The example of page 28 reference loss density and discard density, but > these do not appear to be defined? (they're briefly mentioned earlier > in the section, but are not reported) > > [Alan] these should be "loss rate" and "discard rate", both of which are > defined in section 4.7.1 I have changed the three uses of "density" with respect to losses and discards in this section to "rate"; I have made the same change to three uses of "density" in the code in Appendix A2. > - In section 4.7.3, the round trip delay is calculated in milliseconds, > but the discussion talk about calculating it using RTCP LSR/DLSR. Can > you confirm that milliseconds are intended? And, if so, note in the > explanation that a units conversion is needed. > > [Alan] The use of milliseconds was intentional. > Suggest changing second sentence of "round trip delay" definition to: > "This value MAY be measured using RTCP or the DLRR method defined in > Section 4.5 of this document, in which case it is necessary to convert the > units of measurement from NTP to milliseconds, or other approaches." I have incorporated the suggested text, but specify "NTP timestamp values" instead of "NTP". > - In section 4.7.3, the end system delay estimate makes the assumption > that the system can send and receive, and that it has a local analog > interface to loop-back audio. Neither of these are necessarily valid. > Accordingly, the I'd like to see the "MUST be provided" turn into a > SHOULD, and some explanation of what to do if the data cannot be > provided. > > [Alan] This was defined as an estimated rather than measured delay, and can > typically be determined by adding known framing and encode/decode delays - > it was not intended that it be measured literally. We can change the > wording to clarify. > "The most recently estimated end system delay, expressed in milliseconds. > End system delay is defined as the sum of the total sample accumulation and > encoding delay associated with the sending direction and the jitter buffer, > decoding and playout buffer delay associated with the receiving direction; > this delay MAY be estimated or measured. This value MUST be provided in > all VoIP metrics reports." I have incorporated the suggested text. > - In section 4.7.4, the signal and noise levels are defined as a ratio in > terms of a "reference digital milliwatt" and "rms talkspurt power (mW)". > Can you clarify the definition of these terms? I wouldn't know how to > calculate them, in the PC-based implementation I'm familiar with. > > [Alan] The term "digital milliwatt" is widely used in both PCM and VoIP > systems to denote the digital representation of a 0 dBm0 signal. I've not > yet found the official definition of it, although it may originate in an > IEEE standard - we can substitute a 0dBm0 reference signal. > Suggest:- > > for "signal level" and "noise level" change "digital milliwatt" to "0 dBm0 > reference [18]" > > add reference [18] TIA/EIA-810-A Transmission Requirements for Narrowband > Voice over IP and Voice over PCM Digital Wireline Telephones, December 2000 I have made the suggested changes, but have added the new reference as a normative reference rather than a non-normative reference (which the suggested reference number 18 might be thought to imply). The reference has been inserted in alphabetic order in the Normative References section, entailing reference renumbering. > - In section 4.7.4, the definition of the residual echo return loss is not > clear, and seems to assume particular implmentations of gateway devices. > Recommend separating the normative definition of the field out from the > non-normative examples of how it might be measured in particular cases. > > [Alan] This should be typical of VoIP gateways with line echo cancellers > and isn't specific to any implementations. I've checked with a number of > echo canceller software developers and the parameters are typically > available as ERL and ERLE in dB or in some format that can easily be > converted. Suggest clarifying the wording to: > > The residual echo return loss is defined as the sum of the measured echo > return loss (ERL) and the echo return loss enhancement (ERLE) of the echo > canceller (if present) expressed in dB as a signed integer in 2's > complement form. > > The residual echo return loss relates to the effective echo level that a > user would hear. The amount of echo that can occur in analog loops can be > significant, and therefore echo cancellers are typically used to try and > eliminate or reduce the audible echo. The amount of echo is typically > described as a "echo return loss" (i.e. ratio between the transmitted > signal level and the received echo level) expressed in dB. The > effectiveness of an echo canceller is normally described in terms of "echo > return loss enhancement", i.e. an echo canceller increases the effective > echo return loss and makes the audible echo smaller. Hence the residual > echo return loss (RERL) is the sum of the echo return loss (ERL) and the > echo return loss enhancement (ERLE) expressed in dB. I have incorporated the suggested text. > - In section 4.7.5, the fields are mostly 8 bits, with only a subset of > values being legal. Would it be appropriate to use smaller fields in > some cases? What should receivers do if they receive a report where a > field has an illegal value? > > [Alan] I suggest keeping these as 8 bit, otherwise we would need to handle > 6 bit values. We could change the "A value of" sentences to read > > "A value of 127 indicates that this parameter is unavailable. Values other > than 127 and the valid range defined above MUST not be sent and MUST be > ignored by the receiving system." I have incorporated the suggested text. > - In section 4.7.5, the chosen values for the PLC are not contiguous: I > can indicate a PLC that can conceal less than 3% (standard PLC), or > more than 10% (enhanced PLC), but nothing in the middle. Is there > intended to be a "better-than-standard but not quite enhanced" range? > How does this relate to the "unspecified" category? > > [Alan] There is a continuum of possibilities in terms of PLC effectiveness. > "Standard" in this case refers to algorithms that use some form of last > packet replay with attenuation and filtering/smoothing. "Enhanced" refers > to algorithms that use some form of error correction(sometimes introducing > additional delay or bandwidth overhead). "Unspecified" simply means that > the CODEC details are outside the domain of knowledge of the RTCP XR > reporting instance - they are typically internal to a DSP. > I think the standard and enhanced definitions cover what is used in the > industry today, and generally implementors could figure out which to use. This comment refers to Section 4.7.6. In keeping with the response above, I have made no changes to address this comment. > - In section 4.7.6, the jitter buffer rate assumes that the jitter buffer > can cope with a step change in jitter from 30ms to 100ms. This seems to > be somewhat aggressive? > > [Alan] Let's hope people aren't using 10BaseT and hubs for VoIP!! :-) Many > adaptive jitter buffers max out at 200-400mS although they would typically > operate in the 20-50mS range. As the description suggests, this is > intended to be an easily measured parameter that provides a guide to the JB > ramp time, in reality jitter/PDV would not behave quite this way. In keeping with the response above, I have made no changes to address this comment. > - In section 4.7.7, the units for the "JB max" and "JB abs max" fields are > not specified. Also, what is reported if the "JB abs max" is larger than > the maximum expressible value? > > [Alan] Suggested changes > > jitter buffer maximum delay... > This is the current maximum jitter buffer delay in milliseconds which > corresponds to the earliest arriving packet that would not be discarded. > In simple queue....... > > jitter buffer absolute maximum delay... > This is the absolute maximum delay in milliseconds that the adaptive jitter > buffer can reach under worst case conditions. If this value exceeds 65535 > milliseconds then it shall be limited to 65535. This parameter MUST.... I have made the suggested changes, except that I wrote "If this value exceeds 65535 milliseconds then this field SHALL convey the value 65535", giving normative force to the statement. > - In section 5.1, need a reference to the definitions of DIGIT and CRLF. I have defined these as follows, in keeping with RFC 2234: DIGIT = %x30-39 CRLF = %d13.10 > - Section 6.2 should define what information needs to be included in any > new registrations of attribute block types. There is, presumably, some > minimum degree of specification that is required for interoperability? Yes. I have added the following text: --- begin quote --- Any registration MUST contain the following information: - Contact information of the one doing the registration, including at least name, address, and email. - The format of the block type being registered, consistent with the extended report block format described in Section 3. --- end quote --- > - In section 6.2, if the BT value of 255 is reserved for future extension, > it becomes necessary to indicate how it might be extended. I expect that > this space is large enough, that we don't have to worry about reserving > the block. If memory serves, this issue came up when the 03 draft was discussed in open sesssion in San Francisco. The 03 draft did not have a reserved value. A suggestion was made to add a reserved value for future extensions. I raised the concern that then we would need to define an extension mechanism. I believe it was Henning Schulzrinne who suggested it would suffice to state that the value is reserved. My impression was that this formed the basis for a concensus in the room at the time in favor of adding a simple statement concerning a reserved value, and so I am reluctant to go back on it. > - End of section 6.3, talks about an ABNF definition of new parameters, in > accordance3 with the "format-ext" definition. It needs to reference the > location of the "format-ext" definition. Done. > - Section 7 needs to reference the standard RTCP reporting mechanism, when > it says that the security considerations therein apply. Done. > - In section 7, I'm not sure it's appropriate to mandate that XR packets > SHOULD NOT be encrypted or filtered. > > [Alan] Isn't SHOULD an advisory qualifier, unlike MUST? The goal is to > encourage implementors to turn encryption of RTCP off when sending RTCP XR > reports as this is desirable from a network management perspective. It seems to me odd to include a normative statement with pretences beyond the definition of the XR packets, regarding how third parties should treat the packets. On the other hand, I believe the advice is warranted. I have removed the normative character of this statement by replacing "SHOULD NOT" with "should not". > - Appendix A.2: If differences are found, or if the ETSI spec is updated, > what happens? > > [Alan] We are refering to a specific dated release of the ETSI spec. The > VoIP metrics payload is actually substantially more comprehensive than the > ETSI spec, which only relates to methods for calculating R factors. > We should make the reference at the end of the second paragraph in 4.7 "(as > described by the E Model defined in [6,3]) and.." I have made the suggested change. > - References: RFC 1700 is listed as Historic in my copy of the RFC index. I have replaced this reference with a non-normative reference to RFC 3232. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 1 15:20:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02123 for ; Thu, 1 May 2003 15:20:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41JR3T16820 for avt-archive@odin.ietf.org; Thu, 1 May 2003 15:27:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JPd816674; Thu, 1 May 2003 15:25:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4126P832507 for ; Wed, 30 Apr 2003 22:06:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02788; Wed, 30 Apr 2003 21:59:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B3Nv-0005NR-00; Wed, 30 Apr 2003 22:01:19 -0400 Received: from isis.lip6.fr ([132.227.60.2] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19B3Nn-0005NO-00; Wed, 30 Apr 2003 22:01:11 -0400 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.9/jtpda-5.4+victor) with ESMTP id h4120ZEb024391 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Thu, 1 May 2003 04:00:35 +0200 X-pt: isis.lip6.fr Received: from doris (doris [132.227.72.166]) by tibre.lip6.fr (8.11.6p2/8.11.6) with ESMTP id h4120Z522472; Thu, 1 May 2003 04:00:35 +0200 (CEST) From: Timur Friedman To: internet-drafts@ietf.org Date: Thu, 1 May 2003 04:00:31 +0200 User-Agent: KMail/1.4.3 Cc: avt@ietf.org, Alan Clark , Ramon Caceres , "Kevin C. Almeroth" , Robert Cole , Nick Duffield , Kaynam Hedayat , Kamil Sarac , Magnus Westerlund MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_VWQ6VCCHG26EA113DZYL" Message-Id: <200305010400.31157.timur.friedman@lip6.fr> X-Scanned-By: isis.lip6.fr Subject: [AVT] draft-ietf-avt-rtcp-report-extns-05.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --------------Boundary-00=_VWQ6VCCHG26EA113DZYL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Please find attached the latest version of the RTP Control Protocol Exten= ded=20 Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-05.txt. This d= raft=20 was produced in response to AVT working group last call comments. A PDF version is available at the following URL: =20 http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-repor= t-extns-05.pdf Regards, Timur Friedman --------------Boundary-00=_VWQ6VCCHG26EA113DZYL Content-Type: text/plain; charset="us-ascii"; name="draft-ietf-avt-rtcp-report-extns-05.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rtcp-report-extns-05.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT 30 April 2003 Internet Engineering Task Force Expires: 30 October 2003 Audio/Video Transport Working Group Timur Friedman, Paris 6 Ramon Caceres, ShieldIP Alan Clark, Telchemy Editors RTP Control Protocol Extended Reports (RTCP XR) draft-ietf-avt-rtcp-report-extns-05.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by Friedman et al. Standards Track [Page 1] =0C Internet-Draft RTCP XR April 2003 RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. Table of Contents 1. Introduction .............................................. 3 1.1 Applicability ............................................. 4 1.2 Terminology ............................................... 7 2. XR Packet Format .......................................... 7 3. Extended Report Block Framework ........................... 8 4. Extended Report Blocks .................................... 9 4.1 Loss RLE Report Block ..................................... 9 4.1.1 Run Length Chunk .......................................... 15 4.1.2 Bit Vector Chunk .......................................... 15 4.1.3 Terminating Null Chunk .................................... 15 4.2 Duplicate RLE Report Block ................................ 16 4.3 Packet Receipt Times Report Block ......................... 17 4.4 Receiver Reference Time Report Block ...................... 20 4.5 DLRR Report Block ......................................... 21 4.6 Statistics Summary Report Block ........................... 22 4.7 VoIP Metrics Report Block ................................. 25 4.7.1 Packet Loss and Discard Metrics ........................... 26 4.7.2 Burst Metrics ............................................. 27 4.7.3 Delay Metrics ............................................. 29 4.7.4 Signal Related Metrics .................................... 30 4.7.5 Call Quality or Transmission Quality Metrics .............. 33 4.7.6 Configuration Parameters .................................. 34 4.7.7 Jitter Buffer Parameters .................................. 35 5. SDP Signaling ............................................. 36 5.1 The SDP Attribute ......................................... 37 5.2 Usage in Offer/Answer ..................................... 39 5.3 Usage Outside of Offer/Answer ............................. 41 6. IANA Considerations ....................................... 41 6.1 XR Packet Type ............................................ 41 6.2 RTCP XR Block Type Registry ............................... 42 6.3 The "rtcp-xr" SDP Attribute ............................... 42 7. Security Considerations ................................... 43 A. Algorithms ................................................ 44 A.1 Sequence Number Interpretation ............................ 44 A.2 Example Burst Packet Loss Calculation ..................... 46 Intellectual Property ..................................... 48 Full Copyright Statement .................................. 48 Acknowledgments ........................................... 49 Contributors .............................................. 49 Friedman et al. Standards Track [Page 2] =0C Internet-Draft RTCP XR April 2003 Authors' Addresses ........................................ 50 References ................................................ 51 Normative References ...................................... 51 Non-Normative References .................................. 52 1. Introduction This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP) [9], and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP) [4]. XR packets convey information beyond that already contained in the reception report blocks of RTCP's sender report (SR) or Receiver Report (RR) packets. The information is of use across RTP profiles, and so is not appropriately carried in SR or RR profile-specific extensions. Information used for network management falls into this category, for instance. The definition is broken out over the three sections that follow the Introduction. Section 2 defines the XR packet as consisting of an eight octet header followed by a series of components called report blocks. Section 3 defines the common format, or framework, consisting of a type and a length field, required for all report blocks. Section 4 defines several specific report block types. Other block types can be defined in future documents as the need arises. The report block types defined in this document fall into three categories. The first category consists of packet-by-packet reports on received or lost RTP packets. Reports in the second category convey reference time information between RTP participants. In the third category, reports convey metrics relating to packet receipts, that are summary in nature but that are more detailed, or of a different type, than that conveyed in existing RTCP packets. All told, seven report block formats are defined by this document. Of these, three are packet-by-packet block types: - Loss RLE Report Block (Section 4.1): Run length encoding of reports concerning the losses and receipts of RTP packets. - Duplicate RLE Report Block (Section 4.2): Run length encoding of reports concerning duplicates of received RTP packets. - Packet Receipt Times Report Block (Section 4.3): A list of reception timestamps of RTP packets. There are two reference time related block types: Friedman et al. Standards Track [Page 3] =0C Internet-Draft RTCP XR April 2003 - Receiver Reference Time Report Block (Section 4.4): Receiver-end wallclock timestamps. Together with the DLRR Report Block mentioned next, these allow non-senders to calculate round-trip times. - DLRR Report Block (Section 4.5): The delay since the last Receiver Reference Time Report Block was received. An RTP data sender that receives a Receiver Reference Time Report Block can respond with a DLRR Report Block, in much the same way as, in the mechanism already defined for RTCP [9, Section 6.3.1], an RTP data receiver that receives a sender's NTP timestamp can respond by filling in the DLSR field of an RTCP reception report block. Finally, this document defines two summary metric block types: - Statistics Summary Report Block (Section 4.6): Statistics on RTP packet sequence numbers, losses, duplicates, jitter, and TTL or Hop Limit values. - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring Voice over IP (VoIP) calls. Before proceeding to the XR packet and report block definitions, this document provides an applicability statement (Section 1.1) that describes the contexts in which these report blocks can be used. It also defines (Section 1.2) the normative use of key words, such as MUST and SHOULD, as they are employed in this document. Following the definitions of the various report blocks, this document describes how applications that employ SDP can signal their use (Section 5). The document concludes with a discussion (Section 6) of numbering considerations for the Internet Assigned Numbers Authority (IANA), of security considerations (Section 7), and with appendices that provide examples of how to implement algorithms discussed in the text. 1.1 Applicability The XR packets are useful across multiple applications, and for that reason are not defined as profile-specific extensions to RTCP sender or Receiver Reports [9, Section 6.4.3]. Nonetheless, they are not of use in all contexts. In particular, the VoIP metrics report block (Section 4.7) is specific to voice applications, though it can be employed over a wide variety of such applications. The VoIP metrics report block can be applied to any one-to-one or one-to-many voice application for which the use of RTP and RTCP is specified. The use of conversational metrics (Section 4.7.5), including the R factor (as described by the E Model defined in [3]) Friedman et al. Standards Track [Page 4] =0C Internet-Draft RTCP XR April 2003 and the mean opinion score for conversational quality (MOS-CQ), in applications other than simple two party calls is not defined, and hence these metrics should be identified as unavailable in multicast conferencing applications. The packet-by-packet report block types, Loss RLE (Section 4.1), Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3), have been defined with network tomography applications, such as multicast inference of network characteristics (MINC) [11], in mind. MINC requires detailed packet receipt traces from multicast session receivers in order to infer the gross structure of the multicast distribution tree and the parameters, such as loss rates and delays, that apply to paths between the branching points of that tree. Any real time multicast multimedia application can use the packet-by- packet report block types. Such an application could employ a MINC inference subsystem that would provide it with multicast tree topology information. One potential use of such a subsystem would be for the identification of high loss regions in the multicast tree and the identification of multicast session participants well situated to provide retransmissions of lost packets. Detailed packet-by-packet reports do not necessarily have to consume disproportionate bandwidth with respect to other RTCP packets. An application can cap the size of these blocks. A mechanism called "thinning" is provided for these report blocks, and can be used to ensure that they adhere to a size limit by restricting the number of packets reported upon within any sequence number interval. The rationale for, and use of this mechanism is described in [13]. Furthermore, applications might not require report blocks from all receivers in order to answer such important questions as where in the multicast tree there are paths that exceed a defined loss rate threshold. Intelligent decisions regarding which receivers send these report blocks can further restrict the portion of RTCP bandwidth that they consume. The packet-by-packet report blocks can also be used by dedicated network monitoring applications. For such an application, it might be appropriate to allow more than 5% of RTP data bandwidth to be used for RTCP packets, thus allowing proportionately larger and more detailed report blocks. Nothing in the packet-by-packet block types restricts their use to multicast applications. In particular, they could be used for network tomography similar to MINC, but using striped unicast packets. In addition, if it were found useful, they could be used for applications limited to two participants. Friedman et al. Standards Track [Page 5] =0C Internet-Draft RTCP XR April 2003 One use to which the packet-by-packet reports are not immediately suited is for data packet acknowledgments as part of a packet retransmission mechanism. The reason is that the packet accounting technique suggested for these blocks differs from the packet accounting normally employed by RTP. In order to favor measurement applications, an effort is made to interpret as little as possible at the data receiver, and leave the interpretation as much as possible to participants that receive the report blocks. Thus, for example, a packet with an anomalous SSRC ID or an anomalous sequence number might be excluded by normal RTP accounting, but would be reported upon for network monitoring purposes. The Statistics Summary Report Block (Section 4.6) has also been defined with network monitoring in mind. This block type can be used equally well for reporting on unicast and multicast packet reception. The reference time related block types were conceived for receiver- based TCP-friendly multicast congestion control [18]. By allowing data receivers to calculate their round trip times to senders, they help the receivers estimate the downstream bandwidth they should request. Note that if every receiver is to send Receiver Reference Time Report Blocks (Section 4.4), a sender might potentially send a number of DLRR Report Blocks (Section 4.5) equal to the number of receivers whose RTCP packets have arrived at the sender within its reporting interval. As the number of participants in a multicast session increases, an application should use discretion regarding which participants send these blocks, and how frequently. XR packets supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6]. The introduction of XR packets into a session in no way changes the rules governing the calculation of the RTCP reporting interval [9, Section 6.2]. As XR packets are RTCP packets, they count as such for bandwidth calculations. As a result, the addition of extended reporting information may tend to increase the average RTCP packet size, and thus the average reporting interval. This increase may be limited by limiting the size of XR packets. The SDP signaling defined for XR packets in this document (Section 5) was done so with three use scenarios in mind: a Real Time Streaming Protocol (RTSP) controlled streaming application, a one-to-many multicast multimedia application such as a course lecture with enhanced feedback, and a Session Initiation Protocol (SIP) controlled conversational session involving two parties. Applications that employ SDP are free to use additional SDP signaling for cases not covered here. In addition, applications are free to use signaling mechanisms other than SDP. Friedman et al. Standards Track [Page 6] =0C Internet-Draft RTCP XR April 2003 1.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliance with this specification. 2. XR Packet Format An XR packet consists of a header of two 32-bit words, followed by a number, possibly zero, of extended report blocks. This type of packet is laid out in a manner consistent with other RTCP packets, as concerns the essential version, packet type, and length information. XR packets are thus backwards compatible with RTCP receiver implementations that do not recognize them, but that ought to be able to parse past them using the length information. A padding field and an SSRC field are also provided in the same locations that they appear in other RTCP packets, for simplicity. The format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|reserved | PT=3DXR=3D207 | length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : report blocks : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP. This specification applies to RTP version two. padding (P): 1 bit If the padding bit is set, this XR packet contains some additional padding octets at the end. The semantics of this field are identical to the semantics of the padding field in the SR packet, as defined by the RTP specification. reserved: 5 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. packet type (PT): 8 bits Friedman et al. Standards Track [Page 7] =0C Internet-Draft RTCP XR April 2003 Contains the constant 207 to identify this as an RTCP XR packet. This value is registered with the Internet Assigned Numbers Authority (IANA), as described in Section 5.1. length: 16 bits As described for the RTCP Sender Report (SR) packet (see Section 6.3.1 of the RTP specification [9]). Briefly, the length of this XR packet in 32-bit words minus one, including the header and any padding. SSRC: 32 bits The synchronization source identifier for the originator of this XR packet. report blocks: variable length. Zero or more extended report blocks. In keeping with the extended report block framework defined below, each block MUST consist of one or more 32-bit words. 3. Extended Report Block Framework Extended report blocks are stacked, one after the other, at the end of an XR packet. An individual block's length is a multiple of 4 octets. The XR header's length field describes the total length of the packet, including these extended report blocks. Each block has block type and length fields that facilitate parsing. A receiving application can demultiplex the blocks based upon their type, and can use the length information to locate each successive block, even in the presence of block types it does not recognize. An extended report block has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | type-specific | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : type-specific block contents : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits Identifies the block format. Seven block types are defined in Section 4. Additional block types may be defined in future specifications. This field's name space is managed by the Internet Assigned Numbers Authority (IANA), as described in Friedman et al. Standards Track [Page 8] =0C Internet-Draft RTCP XR April 2003 Section 5.2. type-specific: 8 bits The use of these bits is determined by the block type definition. block length: 16 bits The length of this report block including the header, in 32-bit words minus one. If the block type definition permits, zero is an acceptable value, signifying a block that consists of only the BT, type-specific, and block length fields, with a null type-specific block contents field. type-specific block contents: variable length The use of this field is defined by the particular block type, subject to the constraint that it MUST be a multiple of 32 bits long. If the block type definition permits, It MAY be zero bits long. 4. Extended Report Blocks This section defines seven extended report blocks: block types for reporting upon received packet losses and duplicates, packet reception times, receiver reference time information, receiver inter- report delays, detailed reception statistics, and voice over IP (VoIP) metrics. An implementation SHOULD ignore incoming blocks with types either not relevant or unknown to it. Additional block types MUST be registered with the Internet Assigned Numbers Authority (IANA) [16], as described in Section 5.2. 4.1 Loss RLE Report Block This block type permits detailed reporting upon individual packet receipt and loss events. Such reports can be used, for example, for multicast inference of network characteristics (MINC) [11]. With MINC, one can discover the topology of the multicast tree used for distributing a source's RTP packets, and of the loss rates along links within that tree. Or they could be used to provide raw data to a network management application. Since a Boolean trace of lost and received RTP packets is potentially lengthy, this block type permits the trace to be compressed through run length encoding. To further reduce block size, loss event reports can be systematically dropped from the trace in a mechanism called thinning that is described below and that is studied in [13]. A participant that generates a Loss RLE Report Block should favor accuracy in reporting on observed events over interpretation of those Friedman et al. Standards Track [Page 9] =0C Internet-Draft RTCP XR April 2003 events whenever possible. Interpretation should be left to those who observe the report blocks. Following this approach implies that accounting for Loss RLE Report Blocks will differ from the accounting for the generation of the SR and RR packets described in the RTP specification [9] in the following two areas: per-sender accounting and per-packet accounting. In its per-sender accounting, an RTP session participant SHOULD NOT make the receipt of a threshold minimum number of RTP packets a condition for reporting upon the sender of those packets. This accounting technique differs from the technique described in Section 6.2.1 and Appendix A.1 of the RTP specification that allows a threshold to determine whether a sender is considered valid. In its per-packet accounting, an RTP session participant SHOULD treat all sequence numbers as valid. This accounting technique differs from the technique described in Appendix A.1 of the RTP specification that suggests ruling a sequence number valid or invalid on the basis of its contiguity with the sequence numbers of previously received packets. Sender validity and sequence number validity are interpretations of the raw data. Such interpretations are justified in the interest, for example, of excluding the stray old packet from an unrelated session from having an effect upon the calculation of the RTCP transmission interval. The presence of stray packets might, on the other hand, be of interest to a network monitoring application. One accounting interpretation that is still necessary is for a participant to decide whether the 16 bit sequence number has rolled over. Under ordinary circumstances this is not a difficult task. For example, if packet number 65,535 (the highest possible sequence number) is followed shortly by packet number 0, it is reasonable to assume that there has been a rollover. However it is possible that the packet is an earlier one (from 65,535 packets earlier). It is also possible that the sequence numbers have rolled over multiple times, either forward or backward. The interpretation becomes more difficult when there are large gaps between the sequence numbers, even accounting for rollover, and when there are long intervals between received packets. The per-packet accounting technique mandated here is for a participant to keep track of the sequence number of the packet most recently received from a sender. For the next packet that arrives from that sender, the sequence number MUST be judged to fall no more than 32,768 packets ahead or behind the most recent one, whichever choice places it closer. In the event that both choices are equally distant (only possible when the distance is 32,768), the choice MUST Friedman et al. Standards Track [Page 10] =0C Internet-Draft RTCP XR April 2003 be the one that does not require a rollover. Appendix A.1 presents an algorithm that implements this technique. Each block reports on a single RTP data packet source, identified by its SSRC. The receiver that is supplying the report is identified in the header of the RTCP packet. Choice of beginning and ending RTP packet sequence numbers for the trace is left to the application. These values are reported in the block. The last sequence number in the trace MAY differ from the sequence number reported on in any accompanying SR or RR report. Note that because of sequence number wraparound the ending sequence number MAY be less than the beginning sequence number. A Loss RLE Report Block MUST NOT be used to report upon a range of 65,534 or greater in the sequence number space, as there is no means to identify multiple wraparounds. The trace described by a Loss RLE report consists of a sequence of Boolean values, one for each sequence number of the trace. A value of one represents a packet receipt, meaning that one or more packets having that sequence number have been received since the most recent wraparound of sequence numbers (or since the beginning of the RTP session if no wraparound has been judged to have occurred). A value of zero represents a packet loss, meaning that there has been no packet receipt for that sequence number as of the time of the report. If a packet with a given sequence number is received after a report of a loss for that sequence number, a later Loss RLE report MAY report a packet receipt for that sequence number. The encoding itself consists of a series of 16 bit units called chunks that describe sequences of packet receipts or losses in the trace. Each chunk either specifies a run length or a bit vector, or is a null chunk. A run length describes between 1 and 16,383 events that are all the same (either all receipts or all losses). A bit vector describes 15 events that may be mixed receipts and losses. A null chunk describes no events, and is used to round out the block to a 32 bit word boundary. The mapping from a sequence of lost and received packets into a sequence of chunks is not necessarily unique. For example, the following trace covers 45 packets, of which the 22nd and 24th have been lost and the others received: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 Friedman et al. Standards Track [Page 11] =0C Internet-Draft RTCP XR April 2003 One way to encode this would be: bit vector 1111 1111 1111 111 bit vector 1111 1101 0111 111 bit vector 1111 1111 1111 111 null chunk Another way to encode this would be: run of 21 receipts bit vector 0101 1111 1111 111 run of 9 receipts null chunk The choice of encoding is left to the application. As part of this freedom of choice, applications MAY terminate a series of run length and bit vector chunks with a bit vector chunk that runs beyond the sequence number space described by the report block. For example, if the 44th packet in the same sequence were lost: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 This could be encoded as: run of 21 receipts bit vector 0101 1111 1111 111 bit vector 1111 1110 1000 000 null chunk In this example, the last five bits of the second bit vector describe a part of the sequence number space that extends beyond the last sequence number in the trace. These bits have been set to zero. All bits in a bit vector chunk that describe a part of the sequence number space that extends beyond the last sequence number in the trace MUST be set to zero, and MUST be ignored by the receiver. A null packet MUST appear at the end of a Loss RLE Report Block if the number of run length plus bit vector chunks is odd. The null chunk MUST NOT appear in any other context. Friedman et al. Standards Track [Page 12] =0C Internet-Draft RTCP XR April 2003 Caution should be used in sending Loss RLE Report Blocks because, even with the compression provided by run length encoding, they can easily consume bandwidth out of proportion with normal RTCP packets. The block type includes a mechanism, called thinning, that allows an application to limit report sizes. A thinning value, T, selects a subset of packets within the sequence number space: those with sequence numbers that are multiples of 2^T. Packet reception and loss reports apply only to those packets. T can vary between 0 and 15. If T is zero then every packet in the sequence number space is reported upon. If T is fifteen then one in every 32,768 packets is reported upon. Suppose that the trace just described begins at sequence number 13,821. The last sequence number in the trace is 13,865. If the trace were to be thinned with a thinning value of T=3D2, then the following sequence numbers would be reported upon: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. The thinned trace would be as follows: 1 1 1 1 1 0 1 1 1 1 0 This could be encoded as follows: bit vector 1111 1011 1100 000 null chunk The last four bits in the bit vector, representing sequence numbers 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are thus set to zero and are ignored by the receiver. With thinning, the loss of the 22nd packet goes unreported because its sequence number, 13,842, is not a multiple of four. Packet receipts for all sequence numbers that are not multiples of four also go unreported. However, in this example thinning has permitted the Loss RLE Report Block to be shortened by one 32 bit word. Choice of the thinning value is left to the application. The Loss RLE Report Block has the following format: Friedman et al. Standards Track [Page 13] =0C Internet-Draft RTCP XR April 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D1 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Loss RLE Report Block is identified by the constant 1. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits The amount of thinning performed on the sequence number space. Only those packets with sequence numbers 0 mod 2^T are reported on by this block. A value of 0 indicates that there is no thinning, and all packets are reported on. The maximum thinning is one packet in every 32,768 (amounting to two packets within each 16-bit sequence space). block length: 16 bits Defined in Section 3. SSRC of source: 32 bits The SSRC of the RTP data packet source being reported upon by this report block. begin_seq: 16 bits The first sequence number that this block reports on. end_seq: 16 bits The last sequence number that this block reports on plus one. chunk i: 16 bits There are three chunk types: run length, bit vector, and Friedman et al. Standards Track [Page 14] =0C Internet-Draft RTCP XR April 2003 terminating null, defined in the following sections. If the chunk is all zeroes then it is a terminating null chunk. Otherwise, the leftmost bit of the chunk determines its type: 0 for run length and 1 for bit vector. 4.1.1 Run Length Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R| run length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A zero identifies this as a run length chunk. run type (R): 1 bit Zero indicates a run of 0s. One indicates a run of 1s. run length: 14 bits A value between 1 and 16,383. The value MUST not be zero for a run length chunk (zeroes in both the run type and run length fields would make the chunk a terminating null chunk). Run lengths of 15 or less MAY be described with a run length chunk despite the fact that they could also be described as part of a bit vector chunk. 4.1.2 Bit Vector Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| bit vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A one identifies this as a bit vector chunk. bit vector: 15 bits The vector is read from left to right, in order of increasing sequence number (with the appropriate allowance for wraparound). 4.1.3 Terminating Null Chunk Friedman et al. Standards Track [Page 15] =0C Internet-Draft RTCP XR April 2003 This chunk is all zeroes. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Duplicate RLE Report Block This block type permits per-sequence-number reports on duplicates in a source's RTP packet stream. Such information can be used for network diagnosis, and provide an alternative to packet losses as a basis for multicast tree topology inference. The Duplicate RLE Report Block format is identical to the Loss RLE Report Block format. Only the interpretation is different, in that the information concerns packet duplicates rather than packet losses. The trace to be encoded in this case also consists of zeros and ones, but a zero here indicates the presence of duplicate packets for a given sequence number, whereas a one indicates that no duplicates were received. The existence of a duplicate for a given sequence number is determined over the entire reporting period. For example, if packet number 12,593 arrives, followed by other packets with other sequence numbers, the arrival later in the reporting period of another packet numbered 12,593 counts as a duplicate for that sequence number. The duplicate does not need to follow immediately upon the first packet of that number. Care must be taken that a report does not cover a range of 65,534 or greater in the sequence number space. No distinction is made between the existence of a single duplicate packet and multiple duplicate packets for a given sequence number. Note also that since there is no duplicate for a lost packet, a loss is encoded as a one in a Duplicate RLE Report Block. The Duplicate RLE Report Block has the following format: Friedman et al. Standards Track [Page 16] =0C Internet-Draft RTCP XR April 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D2 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Duplicate RLE Report Block is identified by the constant 2. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits As defined in Section 4.1. block length: 16 bits Defined in Section 3. SSRC of source: 32 bits As defined in Section 4.1. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. chunk i: 16 bits As defined in Section 4.1. 4.3 Packet Receipt Times Report Block This block type permits per-sequence-number reports on packet receipt times for a given source's RTP packet stream. Such information can be used for MINC inference of the topology of the multicast tree used Friedman et al. Standards Track [Page 17] =0C Internet-Draft RTCP XR April 2003 to distribute the source's RTP packets, and of the delays along the links within that tree. It can also be used to measure partial path characteristics and to model distributions for packet jitter. Packet receipt times are expressed in the same units as used in the RTP timestamps of data packets. This is so that, for each packet, one can establish both the send time and the receipt time in comparable terms. Note, however, that as an RTP sender ordinarily initializes its time to a value chosen at random, there can be no expectation that reported send and receipt times will differ by an amount equal to the one-way delay between sender and receiver. The reported times can nonetheless be useful for the purposes mentioned above. At least one packet MUST have been received for each sequence number reported upon in this block. If this block type is used to report receipt times for a series of sequence numbers that includes lost packets, several blocks are required. If duplicate packets have been received for a given sequence number, and those packets differ in their receipt times, any time other than the earliest MUST NOT be reported. This is to ensure consistency among reports. Times reported in RTP timestamp format consume more bits than loss or duplicate information, and do not lend themselves to run length encoding. The use of thinning is encouraged to limit the size of Packet Receipt Times Report Blocks. The Packet Receipt Times Report Block has the following format: Friedman et al. Standards Track [Page 18] =0C Internet-Draft RTCP XR April 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D3 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receipt time of packet begin_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receipt time of packet (begin_seq + 1) mod 65536 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receipt time of packet (end_seq - 1) mod 65536 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Packet Receipt Times Report Block is identified by the constant 3. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits As defined in Section 4.1. block length: 16 bits Defined in Section 3. SSRC of source: 32 bits As defined in Section 4.1. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. Packet i receipt time: 32 bits The receipt time of the packet with sequence number i at the receiver. The modular arithmetic shown in the packet format diagram is to allow for sequence number rollover. It is preferable for the time value to be established at the link Friedman et al. Standards Track [Page 19] =0C Internet-Draft RTCP XR April 2003 layer interface, or in any case as close as possible to the wire arrival time. Units and format are the same as for the timestamp in RTP data packets. As opposed to RTP data packet timestamps, in which nominal values may be used instead of system clock values in order to convey information useful for periodic playout, the receipt times should reflect the actual time as closely as possible. For a session, if the RTP timestamp is chosen at random, the first receipt time value SHOULD also be chosen at random, and subsequent timestamps offset from this value. On the other hand, if the RTP timestamp is meant to reflect the reference time at the sender, then the receipt time SHOULD be as close as possible to the reference time at the receiver. 4.4 Receiver Reference Time Report Block This block extends RTCP's timestamp reporting so that non-senders may also send timestamps. It recapitulates the NTP timestamp fields from the RTCP Sender Report [9, Sec. 6.3.1]. A non-sender may estimate its round trip time (RTT) to other participants, as proposed in [18], by sending this report block and receiving DLRR Report Blocks (see next section) in reply. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D4 | reserved | block length =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Receiver Reference Time Report Block is identified by the constant 4. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits The constant 2, in accordance with the definition of this field in Section 3. Friedman et al. Standards Track [Page 20] =0C Internet-Draft RTCP XR April 2003 NTP timestamp: 64 bits Indicates the wallclock time when this block was sent so that it may be used in combination with timestamps returned in DLRR Report Blocks (see next section) from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the timestamp may be limited to far less than the resolution of the NTP timestamp. The measurement uncertainty of the timestamp is not indicated as it may not be known. A report block sender that can keep track of elapsed time but has no notion of wallclock time may use the elapsed time since joining the session instead. This is assumed to be less than 68 years, so the high bit will be zero. It is permissible to use the sampling clock to estimate elapsed wallclock time. A report sender that has no notion of wallclock or elapsed time may set the NTP timestamp to zero. 4.5 DLRR Report Block This block extends RTCP's delay since last Sender Report (DLSR) mechanism [9, Sec. 6.3.1] so that non-senders may also calculate round trip times, as proposed in [18]. It is termed DLRR for delay since last Receiver Report, and may be sent in response to a Receiver Timestamp Report Block (see previous section) from a receiver to allow that receiver to calculate its round trip time to the respondent. The report consists of one or more 3 word sub-blocks: one sub-block per Receiver Report. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D5 | reserved | block length | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | SSRC_1 (SSRC of first receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k | last RR (LRR) | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last RR (DLRR) | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | SSRC_2 (SSRC of second receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k : ... : 2 +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ block type (BT): 8 bits A DLRR Report Block is identified by the constant 5. Friedman et al. Standards Track [Page 21] =0C Internet-Draft RTCP XR April 2003 reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits Defined in Section 3. last RR timestamp (LRR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in the previous section) received as part of a Receiver Reference Time Report Block from participant SSRC_n. If no such block has been received, the field is set to zero. delay since last RR (DLRR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last Receiver Reference Time Report Block from participant SSRC_n and sending this DLRR Report Block. If no Receiver Reference Time Report Block has been received yet from SSRC_n, the DLRR field is set to zero (or the DLRR is omitted entirely). Let SSRC_r denote the receiver issuing this DLRR Report Block. Participant SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this Receiver Timestamp Report Block is received. It calculates the total round-trip time A-LRR using the last RR timestamp (LRR) field, and then subtracting this field to leave the round-trip propagation delay as A-LRR-DLRR. This is illustrated in [9, Fig. 2]. 4.6 Statistics Summary Report Block This block reports statistics beyond the information carried in the standard RTCP packet format, but not as fine grained as that carried in the report blocks previously described. Information is recorded about lost packets, duplicate packets, jitter measurements, and TTL or Hop Limit values. Such information can be useful for network management. The report block contents are dependent upon a series of flags bit carried in the first part of the header. Not all parameters need to be reported in each block. Flags indicate which are and which are not reported. The fields corresponding to unreported parameters MUST be present, but are set to zero. The receiver MUST ignore any Statistics Summary Report Block with a non-zero value in any field flagged as unreported. The Statistics Summary Report Block has the following format: Friedman et al. Standards Track [Page 22] =0C Internet-Draft RTCP XR April 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D6 |L|D|J|ToH|rsvd.| block length =3D 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lost_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dup_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | max_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mean_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dev_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Statistics Summary Report Block is identified by the constant 6. loss report flag (L): 1 bit Bit set to 1 if the lost_packets field contains a report, 0 otherwise. duplicate report flag (D): 1 bit Bit set to 1 if the dup_packets field contains a report, 0 otherwise. jitter flag (J): 1 bit Bit set to 1 if the min_jitter, max_jitter, mean_jitter, and dev_jitter fields all contain reports, 0 if none of them do. TTL or Hop Limit flag (ToH): 2 bits This field is set to 0 if none of the fields min_ttl_or_hl, max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain reports. If the field is non-zero then all of these fields contain reports. The value 1 signifies that they report on IPv4 TTL values. The value 2 signifies that they report on IPv6 Hop Limit values. This value 3 is undefined and MUST NOT be used. Friedman et al. Standards Track [Page 23] =0C Internet-Draft RTCP XR April 2003 rsvd.: 3 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits The constant 9, in accordance with the definition of this field in Section 3. SSRC of source: 32 bits As defined in Section 4.1. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. lost_packets: 32 bits Number of lost packets in the above sequence number interval. dup_packets: 32 bits Number of duplicate packets in the above sequence number interval. min_jitter: 32 bits The minimum relative transit time between two packets in the above sequence number interval. All jitter values are measured as the difference between a packet's RTP timestamp and the reporter's clock at the time of arrival, measured in the same units. max_jitter: 32 bits The maximum relative transit time between two packets in the above sequence number interval. mean_jitter: 32 bits The mean relative transit time between each two packet series in the above sequence number interval, rounded to the nearest value expressible as an RTP timestamp. dev_jitter: 32 bits The standard deviation of the relative transit time between each two packet series in the above sequence number interval. min_ttl_or_hl: 8 bits The minimum TTL or Hop Limit value of data packets in the sequence number range. Friedman et al. Standards Track [Page 24] =0C Internet-Draft RTCP XR April 2003 max_ttl_or_hl: 8 bits The maximum TTL or Hop Limit value of data packets in the sequence number range. mean_ttl_or_hl: 8 bits The mean TTL or Hop Limit value of data packets in the sequence number range, rounded to the nearest integer. dev_ttl_or_hl: 8 bits The standard deviation of TTL or Hop Limit values of data packets in the sequence number range. 4.7 VoIP Metrics Report Block The VoIP Metrics Report Block provides metrics for monitoring voice over IP (VoIP) calls. These metrics include packet loss and discard metrics, delay metrics, analog metrics, and voice quality metrics. The block reports separately on packets lost on the IP channel, and those that have been received but then discarded by the receiving jitter buffer. It also reports on the combined effect of losses and discards, as both have equal effect on call quality. In order to properly assess the quality of a Voice over IP call it is desirable to consider the degree of burstiness of packet loss [14]. Following a Gilbert-Elliott model [3], a period of time, bounded by lost and/or discarded packets, with a high rate of losses and/or discards is a "burst," and a period of time between two bursts is a "gap." Bursts correspond to periods of time during which the packet loss rate is high enough to produce noticeable degradation in audio quality. Gaps correspond to periods of time during which only isolated lost packets may occur, and in general these can be masked by packet loss concealment. Delay reports include the transit delay between RTP end points and the VoIP end system processing delays, both of which contribute to the user perceived delay. Additional metrics include signal, echo, noise, and distortion levels. Call quality metrics include R factors (as described by the E Model defined in [6,3]) and mean opinion scores (MOS scores). Implementations MUST provide values for all the fields defined here. For certain metrics, if the value is undefined or unknown, then the specified default or unknown field value MUST be provided. The block is encoded as seven 32-bit words: Friedman et al. Standards Track [Page 25] =0C Internet-Draft RTCP XR April 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D7 | reserved | block length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | loss rate | discard rate | burst density | gap density | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | burst duration | gap duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | round trip delay | end system delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signal level | noise level | RERL | Gmin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R factor | ext. R factor | MOS-LQ | MOS-CQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RX config | reserved | JB nominal | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JB maximum | JB abs max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A VoIP Metrics Report Block is identified by the constant 7. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits The constant 8, in accordance with the definition of this field in Section 3. SSRC of source: 32 bits As defined in Section 4.1. The remaining fields are described in the following six sections: Packet Loss and Discard Metrics, Delay Metrics, Signal Related Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, and Jitter Buffer Parameters. 4.7.1 Packet Loss and Discard Metrics It is very useful to distinguish between packets lost by the network and those discarded due to jitter. Both have equal effect on the quality of the voice stream however having separate counts helps Friedman et al. Standards Track [Page 26] =0C Internet-Draft RTCP XR April 2003 identify the source of quality degradation. These fields MUST be populated. loss rate: 8 bits The fraction of RTP data packets from the source lost since the beginning of reception, expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing the total number of packets lost (after the effects of applying any error protection such as FEC) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. The numbers of duplicated packets and discarded packets do not enter into this calculation. Since receivers cannot be required to maintain unlimited buffers, a receiver MAY categorize late-arriving packets as lost. The degree of lateness that triggers a loss SHOULD be significantly greater than that which triggers a discard. discard rate: 8 bits The fraction of RTP data packets from the source that have been discarded since the beginning of reception, due to late or early arrival, under-run or overflow at the receiving jitter buffer. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets discarded (excluding duplicate packet discards) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. 4.7.2 Burst Metrics A burst is a period during which a high proportion of packets are either lost or discarded due to late arrival. A burst is defined, in terms of a value Gmin, as a longest sequence that (a) starts with a lost or discarded packet, (b) does not contain any occurrences of Gmin or more consecutive received (and not discarded) packets, and (c) ends with a lost or discarded packet. A gap, informally, is a period of low packet losses and/or discards. Formally, a gap is defined as any of the following: (a) the period from the start of an RTP session to the receipt time of the last received packet before the first burst, (b) the period from the end of the last burst to either the time of the report or the end of the RTP session, whichever comes first, or (c) the period of time between two bursts. Friedman et al. Standards Track [Page 27] =0C Internet-Draft RTCP XR April 2003 For the purpose of determining if a lost or discarded packet near the start or end of an RTP session is within a gap or a burst it is assumed that the RTP session is preceded and followed by at least Gmin received packets, and that the time of the report is followed by at least Gmin received packets. A gap has the property that any lost or discarded packets within the gap must be preceded and followed by at least Gmin packets that were received and not discarded. This gives a maximum loss/discard rate within a gap of: 1 / (Gmin + 1). A Gmin value of 16 is RECOMMENDED as it results in gap characteristics that correspond to good quality (i.e. low packet loss rate, a minimum distance of 16 received packets between lost packets) and hence differentiates nicely between good and poor quality periods. For example, a 1 denotes a received, 0 a lost, and X a discarded packet in the following pattern covering 64 packets: 11110111111111111111111X111X1011110111111111111111111X111111111 |---------gap----------|--burst---|------------gap------------| The burst consists of the twelve packets indicated above, starting at a discarded packet and ending at a lost packet. The first gap starts at the beginning of the session and the second gap ends at the time of the report. If the packet spacing is 10 ms and the Gmin value is the recommended value of 16, the burst duration is 120 ms, the burst density 0.33, the gap duration 230 ms + 290 ms =3D 520 ms, and the gap density 0.04. This would result in reported values as follows (see field descriptions for semantics and details on how these are calculated): loss rate 12, which corresponds to 5% discard rate 12, which corresponds to 5% burst density 84, which corresponds to 33% gap density 10, which corresponds to 4% burst duration 120, value in milliseconds gap duration 520, value in milliseconds burst density: 8 bits The fraction of RTP data packets within burst periods since the beginning of reception that were either lost or discarded. This value is expressed as a fixed point number with the binary point Friedman et al. Standards Track [Page 28] =0C Internet-Draft RTCP XR April 2003 at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within burst periods by the total number of packets expected within the burst periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. gap density: 8 bits The fraction of RTP data packets within inter-burst gaps since the beginning of reception that were either lost or discarded. The value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within gap periods by the total number of packets expected within the gap periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. burst duration: 16 bits The mean duration, expressed in milliseconds, of the burst periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packets that mark the beginning and end of that period. It is equal to the timestamp of the end packet, plus the duration of the end packet, minus the timestamp of the beginning packet. If the actual values are not available, estimated values MUST be used. If there have been no burst periods, the burst duration value MUST be zero. gap duration: 16 bits The mean duration, expressed in milliseconds, of the gap periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packet that marks the end of the prior burst and the packet that marks the beginning of the subsequent burst. It is equal to the timestamp of the subsequent burst packet, minus the timestamp of the prior burst packet, plus the duration of the prior burst packet. If the actual values are not available, estimated values MUST be used. In the case of a gap that occurs at the beginning of reception, the sum of the timestamp of the prior burst packet and the duration of the prior burst packet are replaced by the reception start time. In the case of a gap that occurs at the end of reception, the timestamp of the subsequent burst packet is replaced by the reception end time. If there have been no gap periods, the gap duration value MUST be zero. 4.7.3 Delay Metrics Friedman et al. Standards Track [Page 29] =0C Internet-Draft RTCP XR April 2003 For the purpose of the following definitions, the RTP interface is the interface between the RTP instance and the voice application (i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For example, the time delay due to RTP payload multiplexing would be considered to be part of the voice application or end-system delay whereas delay due to multiplexing RTP frames within a UDP frame would be considered part of the RTP reported delay. This distinction is consistent with the use of RTCP for delay measurements. round trip delay: 16 bits The most recently calculated round trip time between RTP interfaces, expressed in milliseconds. This value MAY be measured using RTCP, the DLRR method defined in Section 4.5 of this document, in which case it is necessary to convert the units of measurement from NTP timestamp values to milliseconds, or other approaches. If RTCP is used then the reported delay value is the time of receipt of the most recent RTCP packet from source SSRC, minus the LSR (last SR) time reported in its SR (Sender Report), minus the DLSR (delay since last SR) reported in its SR. A non-zero LSR value is required in order to calculate round trip delay. A value of 0 is permissible, however this field MUST be populated as soon as a delay estimate is available. end system delay: 16 bits The most recently estimated end system delay, expressed in milliseconds. End system delay is defined as the sum of the total sample accumulation and encoding delay associated with the sending direction and the jitter buffer, decoding, and playout buffer delay associated with the receiving direction. This delay MAY be estimated or measured. This value MUST be provided in all VoIP metrics reports. Note that the one way symmetric VoIP segment delay may be calculated from the round trip and end system delays as follows. If the round trip delay is denoted RTD and the end system delays associated with the two endpoints are ESD(A) and ESD(B) then: one way symmetric voice path delay =3D ( RTD + ESD(A) + ESD(B) ) / 2 4.7.4 Signal Related Metrics The following metrics are intended to provide real time information related to the non-packet elements of the voice over IP system to assist with the identification of problems affecting call quality. The values identified below must be determined for the received audio Friedman et al. Standards Track [Page 30] =0C Internet-Draft RTCP XR April 2003 signal. The information required to populate these fields may not be available in all systems, although it is strongly recommended that this data SHOULD be provided to support problem diagnosis. signal level: 8 bits The voice signal relative level is defined as the ratio of the signal level to a 0dBm0 reference [10], expressed in decibels as a signed integer in two's complement form. This is measured only for packets containing speech energy. The intent of this metric is not to provide a precise measurement of the signal level but to provide a real time indication that the signal level may be excessively high or low. signal level =3D 10 Log10 ( rms talkspurt power (mW) ) A value of 127 indicates that this parameter is unavailable. Typical values should be generally in the -15 to -20 dBm range. noise level: 8 bits The noise level is defined as the ratio of the silent period background noise level to a 0 dBm0 reference, expressed in decibels as a signed integer in two's complement form. noise level =3D 10 Log10 ( rms silence power (mW) ) A value of 127 indicates that this parameter is unavailable. residual echo return loss (RERL): 8 bits The residual echo return loss is defined as the sum of the measured echo return loss (ERL) and the echo return loss enhancement (ERLE) of the echo canceller (if present), expressed in dB as a signed integer in two's complement form. The residual echo return loss relates to the effective echo level that a user would hear. The amount of echo that can occur in analog loops can be significant, and therefore echo cancellers are typically used to try and eliminate or reduce the audible echo. The amount of echo is typically described as an "echo return loss" (i.e. ratio between the transmitted signal level and the received echo level) expressed in dB. The effectiveness of an echo canceller is normally described in terms of "echo return loss enhancement", i.e. an echo canceller increases the effective echo return loss and makes the audible echo smaller. Hence the residual echo return loss (RERL) is the sum of the echo return loss (ERL) and the echo return loss enhancement (ERLE) expressed in dB. A low level of echo return loss (say less than 20 dB) in Friedman et al. Standards Track [Page 31] =0C Internet-Draft RTCP XR April 2003 conjunction with some delay can lead to hollowness or audible echo. A high level of echo return loss (say over 40 dB) is preferable. The ERL and ERLE parameters are often available directly from the echo canceler contained within the VoIP end system. They relate to the echo on the external network attached to the end point. In the case of a VoIP gateway this would be line echo that typically occurs at 2-4 wire conversion points in the network. Echo return loss from typical 2-4 wire conversions can be in the 8-12 dB range. A line echo canceler can provide an ERLE of 30 dB or more and hence reduce this to 40-50 dB. In the case of an IP phone this could be residual acoustic echo from speakerphone operation, and may more correctly be termed terminal coupling loss (TCL). A typical handset would result in 40-50 dB of echo due to acoustic feedback. Typical values for RERL are as follows: (i) IP gateway connected to circuit switched network with 2 wire loop Without echo cancellation, typical 2-4 wire converter ERL of 12 dB RERL =3D ERL + ERLE =3D 12 + 0 =3D 12 dB (ii) IP gateway connected to circuit switched network with 2 wire loop With echo canceler that improves echo by 30 dB RERL =3D ERL + ERLE =3D 12 + 30 =3D 42 dB (iii) IP phone with conventional handset Acoustic coupling from handset speaker to microphone 40 dB Residual echo return loss =3D TCL =3D 40 dB If we denote the "local" end of the VoIP path as A and the remote end as B and if the sender loudness rating (SLR) and receiver loudness rating (RLR) are known for A (default values 8 dB and 2 dB respectively), then the echo loudness level at end A (talker echo loudness rating or TELR) is given by: TELR(A) =3D SRL(A) + ERL(B) + ERLE(B) + RLR(A) TELR(B) =3D SRL(B) + ERL(A) + ERLE(A) + RLR(B) Hence in order to incorporate echo into a voice quality estimate at the A end of a VoIP connection it is desirable to send the ERL + ERLE value from B to A. For an IP phone with handset this metric MUST be set to the designed or measured terminal coupling loss, which would typically be 40-50 dB. Friedman et al. Standards Track [Page 32] =0C Internet-Draft RTCP XR April 2003 For a PC softphone or speakerphone this metric MUST be set to either the value reported by the acoustic echo canceler or to 127 to indicate an undefined value. For an IP gateway with ERL and ERLE measurements this metric MUST be reported as ERL + ERLE. For an IP gateway without ERL and ERLE measurement capability then this metric MUST be reported as 12 dB if line echo cancellation is disabled and 40 dB if line echo cancellation is enabled. Gmin See Configuration Parameters (Section 4.7.6, below). 4.7.5 Call Quality or Transmission Quality Metrics The following metrics are direct measures of the call quality or transmission quality, and incorporate the effects of codec type, packet loss, discard, burstiness, delay etc. These metrics may not be available in all systems however SHOULD be provided in order to support problem diagnosis. R factor: 8 bits The R factor is a voice quality metric describing the segment of the call that is carried over this RTP session. It is expressed as an integer in the range 0 to 100, with a value of 94 corresponding to "toll quality" and values of 50 or less regarded as unusable. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3]. A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. ext. R factor: 8 bits The external R factor is a voice quality metric describing the segment of the call that is carried over a network segment external to the RTP segment, for example a cellular network. Its values are interpreted in the same manner as for the RTP R factor. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3], and relates to the outward voice path from the Voice over IP termination for which this metrics block applies. A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. Friedman et al. Standards Track [Page 33] =0C Internet-Draft RTCP XR April 2003 Note that an overall R factor may be estimated from the RTP segment R factor and the external R factor, as follows: R total =3D RTP R factor + ext. R factor - 94 MOS-LQ: 8 bits The estimated mean opinion score for listening quality (MOS-LQ) is a voice quality metric on a scale from 1 to 5, in which 5 represents excellent and 1 represents unacceptable. This metric is defined as not including the effects of delay and can be compared to MOS scores obtained from listening quality (ACR) tests. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10. For example, a value of 35 would correspond to an estimated MOS score of 3.5. A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. MOS-CQ: 8 bits The estimated mean opinion score for conversational quality (MOS-CQ) is defined as including the effects of delay and other effects that would affect conversational quality. The metric may be calculated by converting an R factor determined according to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated MOS using the equation specified in G.107. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10, as for MOS-LQ. A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. 4.7.6 Configuration Parameters Gmin: 8 bits The gap threshold. This field contains the value used for this report block to determine if a gap exists. The recommended value of 16 corresponds to a burst period having a minimum density of 6.25% of lost or discarded packets, which may cause noticeable degradation in call quality; during gap periods, if packet loss or discard occurs, each lost or discarded packet would be preceded by and followed by a sequence of at least 16 received non-discarded packets. Note that lost or discarded packets that occur within Gmin packets of a report being generated may be reclassified as being part of a burst or gap in later reports. ETSI TS 101 329-5 [3] defines a computationally efficient algorithm for measuring burst and gap density using a Friedman et al. Standards Track [Page 34] =0C Internet-Draft RTCP XR April 2003 packet loss/discard event driven approach. This algorithm is reproduced in Appendix A.2 of the present document. Gmin MUST not be zero and MUST be provided. receiver configuration byte (RX config): 8 bits This byte consists of the following fields: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |PLC|JBA|JB rate| +-+-+-+-+-+-+-+-+ packet loss concealment (PLC): 2 bits Standard (11) / enhanced (10) / disabled (01) / unspecified (00). When PLC =3D 11 then a simple replay or interpolation algorithm is being used to fill-in the missing packet. This is typically able to conceal isolated lost packets with loss rates under 3%. When PLC =3D 10 then an enhanced interpolation algorithm is being used. This would typically be able to conceal lost packets for loss rates of 10% or more. When PLC =3D 01 then silence is inserted in place of lost packets. When PLC =3D 00 then no information is available concerning the use of PLC however for some codecs this may be inferred. jitter buffer adaptive (JBA): 2 bits Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When the jitter buffer is adaptive then its size is being dynamically adjusted to deal with varying levels of jitter. When non-adaptive, the jitter buffer size is maintained at a fixed level. When either adaptive or non- adaptive modes are specified then the jitter buffer size parameters below MUST be specified. jitter buffer rate (JB rate): 4 bits J =3D adjustment rate (0-15). This represents the implementation specific adjustment rate of a jitter buffer in adaptive mode. This parameter is defined in terms of the approximate time taken to fully adjust to a step change in peak to peak jitter from 30 ms to 100 ms such that: adjustment time =3D 2 * J * frame size (ms) This parameter is intended only to provide a guide to the degree of "aggressiveness" of a an adaptive jitter buffer and may be estimated. A value of 0 indicates that the Friedman et al. Standards Track [Page 35] =0C Internet-Draft RTCP XR April 2003 adjustment time is unknown for this implementation. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. 4.7.7 Jitter Buffer Parameters jitter buffer nominal delay (JB nominal): 16 bits This is the current nominal jitter buffer delay in milliseconds, which corresponds to the nominal jitter buffer delay for packets that arrive exactly on time. This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer maximum delay (JB maximum): 16 bits This is the current maximum jitter buffer delay in milliseconds which corresponds to the earliest arriving packet that would not be discarded. In simple queue implementations this may correspond to the nominal size. In adaptive jitter buffer implementations this value may dynamically vary up to JB abs max (see below). This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer absolute maximum delay (JB abs max): 16 bits This is the absolute maximum delay in milliseconds that the adaptive jitter buffer can reach under worst case conditions. If this value exceeds 65535 milliseconds then this field SHALL convey the value 65535. This parameter MUST be provided for adaptive jitter buffer implementations and its value MUST be set to JB maximum for fixed jitter buffer implementations. 5. SDP Signaling This section defines Session Description Protocol (SDP) [4] signaling for XR blocks that can be employed by applications that utilize SDP. This signaling is defined to be used either by applications that implement the SDP Offer/Answer model [8] or by applications that use SDP to describe media and transport configurations in connection with such protocols as the Session Announcement Protocol (SAP) [15] or the Real Time Streaming Protocol (RTSP) [17]. There exist other potential signaling methods, which are not defined here. The XR blocks MAY be used without prior signaling. This is consistent with the rules governing other RTCP packet types, as described in [9]. An example in which signaling would not be used is an application that always requires the use of one or more XR blocks. However for applications that are configured at session initiation, Friedman et al. Standards Track [Page 36] =0C Internet-Draft RTCP XR April 2003 the use of some type of signaling is recommended. Note that, although the use of SDP signaling for XR blocks may be optional, if used it MUST be used as defined here. If SDP signaling is used in an environment where XR blocks are only implemented by some fraction of the participants, the ones not implementing the XR blocks will ignore the SDP attribute. 5.1 The SDP Attribute This section defines one new SDP attribute "rtcp-xr" that can be used to signal participants in a media session that they should use the specified XR blocks. This attribute can be easily extended in the future with new parameters to cover any new report blocks. The RTCP XR blocks SDP attribute is defined below in Augmented Backus-Naur Form (ABNF) [2]. It is both a session and a media level attribute. When specified at session level, it applies to all media level blocks in the session. Any media level specification MUST replace a session level specification, if one is present, for that media block. rtcp-xr-attrib =3D "a=3D" "rtcp-xr" ":" [xr-format *(SP xr-format)] CR= LF xr-format =3D pkt-loss-rle / pkt-dup-rle / pkt-rcpt-times / rcvr-rtt / stat-summary / voip-metrics / format-ext pkt-loss-rle =3D "pkt-loss-rle" ["=3D" max-size] pkt-dup-rle =3D "pkt-dup-rle" ["=3D" max-size] pkt-rcpt-times =3D "pkt-rcpt-times" ["=3D" max-size] rcvr-rtt =3D "rcvr-rtt" "=3D" rcvr-rtt-mode [":" max-size] stat-summary =3D "stat-summary" voip-metrics =3D "voip-metrics" max-size =3D 1*DIGIT ; maximum block size in octets DIGIT =3D %x30-39 rcvr-rtt-mode =3D "all" / "sender" format-ext =3D non-ws-string non-ws-string =3D 1*(%x21-FF) CRLF =3D %d13.10 Friedman et al. Standards Track [Page 37] =0C Internet-Draft RTCP XR April 2003 The "rtcp-xr" attribute contains zero, one, or more XR block related parameters. Each parameter signals functionality for an XR block, or a group of XR blocks. The attribute is extensible so that parameters can be defined for any future XR block (and a parameter should be defined for every future block). Each "rtcp-xr" parameter belongs to one of two categories. The first category, the unilateral parameters, are for report blocks that simply report on the RTP stream and related metrics. The second category, collaborative parameters, are for XR blocks that involve actions by more than one party in order to carry out their functions. Round trip time (RTT) measurement is an example of collaborative functionality. An RTP data packet receiver sends a Receiver Reference Time Report Block (Section 4.4). A participant that receives this block sends a DLRR Report Block (Section 4.5) in response, allowing the receiver to calculate its RTT to that participant. As this example illustrates, collaborative functionality may be implemented by two or more different XR blocks. The collaborative functionality of several XR blocks may be governed by a single "rtcp-xr" parameter. For the unilateral category, this document defines the following parameters. The parameter names and their corresponding XR formats are as follows: Parameter name XR block (block type and name) -------------- ------------------------------------ pkt-loss-rle 1 Loss RLE Report Block pkt-dup-rle 2 Duplicate RLE Report Block pkt-rcpt-times 3 Packet Receipt Times Report Block stat-summary 6 Statistics Summary Report Block voip-metrics 7 VoIP Metrics Report Block The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters MAY specify an integer value. This value indicates the largest size the whole report block SHOULD have in octets. This shall be seen as an indication that thinning shall be applied if necessary to meet the target size. Blocks in the collaborative category are classified as initiator blocks or response blocks. Signaling SHOULD indicate which participants are required to respond to the initiator block. A party that wishes to receive response blocks from those participants can trigger this by sending an initiator block. The collaborative category currently consists only of one Friedman et al. Standards Track [Page 38] =0C Internet-Draft RTCP XR April 2003 functionality, namely the RTT measurement mechanism for RTP data receivers. The collective functionality of the Receiver Reference Time Report Block and DLRR Report Block is represented by the "rcvr- rtt" parameter. This parameter takes as its arguments a mode value and, optionally, a maximum size for the DLRR report block. The mode value "all" indicates that both RTP data senders and data receivers MAY send DLRR blocks, while the mode value "sender" indicates that only active RTP senders MAY send DLRR blocks, i.e. non RTP senders SHALL NOT send DLRR blocks. If a maximum size in octets is included, any DLRR Report Blocks that are sent SHALL NOT exceed the specified size. If size limitations mean that a DLRR Report Block sender cannot report in one block upon all participants from which it has received a Receiver Reference Time Report Block then it SHOULD report on participants in a round robin fashion across several report intervals. The "rtcp-xr" attributes parameter list MAY be empty. This is useful in cases in which an application needs to signal that it understands the SDP signaling but does not wish to avail itself of XR functionality. For example, an application in a SIP controlled session could signal that it wishes to stop using all XR blocks by removing all applicable SDP parameters in a re-INVITE message that it sends. If XR blocks are not to be used at all from the beginning of a session, it is RECOMMENDED that the "rtcp-xr" attribute not be supplied at all. When the "rtcp-xr" attribute is present, participants SHOULD NOT send XR blocks other than the ones indicated by the parameters. This means that inclusion of a "rtcp-xr" attribute without any parameters tells a participant that it SHOULD NOT send any XR blocks at all. The purpose is to conserve bandwidth. This is especially important when collaborative parameters are applied to a large multicast group: the sending of an initiator block could potentially trigger responses from all participants. There are, however, contexts in which it makes sense to send an XR block in the absence of a parameter signaling its use. For instance, an application might be designed so as to send certain report blocks without negotiation, while using SDP signaling to negotiate the use of other blocks. 5.2 Usage in Offer/Answer In the Offer/Answer context [8], the interpretation of SDP signaling for XR packets depends upon the direction attribute that is signaled: "recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute is supplied then "sendrecv" is assumed. This section applies only to unicast media streams, except where noted. Discussion of unilateral parameters is followed by discussion of collaborative parameters in this section. Friedman et al. Standards Track [Page 39] =0C Internet-Draft RTCP XR April 2003 For "sendonly" and "sendrecv" media stream offers that specify unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send the corresponding XR blocks. For "sendrecv" offers, the answerer MAY include the "rtcp-xr" attribute in its response, and specify any unilateral parameters in order to request that the offerer send the corresponding XR blocks. The offerer SHOULD send these blocks. For "recvonly" media stream offers, the offerer's use of the "rtcp- xr" attribute in connection with unilateral parameters indicates that the offerer is capable of sending the corresponding XR blocks. If the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD send XR blocks for each specified unilateral parameter that was in its offer. For multicast media streams, the inclusion of an "rtcp-xr" attribute with unilateral parameters means that every media recipient SHOULD send the corresponding XR blocks. An SDP offer with a collaborative parameter declares the offerer capable of receiving the corresponding initiator and replying with the appropriate responses. For example, an offer that specifies the "rcvr-rtt" parameter means that the offerer is prepared to receive Receiver Reference Time Report Blocks and to send DLRR Report Blocks. An offer of a collaborative parameter means that the answerer MAY send the initiator, and, having received the initiator, the offerer SHOULD send the responses. There are exceptions to the rule that an offerer of a collaborative parameter should send responses. For instance, the collaborative parameter might specify a mode that excludes the offerer. Or congestion control or maximum transmission unit considerations might militate against the offerer's response. By including a collaborative parameter in its answer, the answerer declares its ability to receive initiators and to send responses. The offerer MAY then send initiators, to which the answerer SHOULD reply with responses. As for the offer of a collaborative parameter, there are exceptions to the rule that the answerer should reply. When making an SDP offer of a collaborative parameter for a multicast media stream, the offerer SHOULD specify which participants are to respond to a received initiator. A participant that is not specified SHOULD NOT send responses. Otherwise, undue bandwidth might be consumed. The offer indicates that each participant that is specified SHOULD respond if it receives an initiator. It also indicates that a specified participant MAY send an initiator block. An SDP answer for a multicast media stream SHOULD include all Friedman et al. Standards Track [Page 40] =0C Internet-Draft RTCP XR April 2003 collaborative parameters that are present in the offer and that are supported by the answerer. It SHOULD NOT include any collaborative parameter that is absent from the offer. If a participant receives an SDP offer and understands the "rtcp-xr" attribute but does not wish to implement XR functionality offered, its answer SHOULD include an "rtcp-xr" attribute without parameters. By doing so, the party declares that at a minimum that it is capable of understanding the signaling. 5.3 Usage Outside of Offer/Answer SDP can be employed outside of the Offer/Answer context, for instance for multimedia sessions that are announced through the Session Announcement Protocol (SAP) [15], or streamed through the Real Time Streaming Protocol (RTSP) [17]. The signaling model is simpler, as the sender does not negotiate parameters, but the functionality that is expected from specifying the "rtcp-xr" attribute is the same as in Offer/Answer. When a unilateral parameter is specified for the "rtcp-xr" attribute associated with a media stream, the receiver of that stream SHOULD send the corresponding XR block. When a collaborative parameter is specified, only the participants indicated by the mode value in the collaborative parameter are concerned. Each such participant that receives an initiator block SHOULD send the corresponding response block. Each such participant MAY also send initiator blocks. 6. IANA Considerations This document defines a new RTCP packet type, the Extended Report (XR) type, within the existing Internet Assigned Numbers Authority (IANA) registry of RTP RTCP Control Packet Types. This document also defines a new IANA registry: the registry of RTCP XR Block Types. Within this new registry, this document defines an initial set of seven block types and describes how the remaining types are to be allocated. Further, this document defines a new SDP attribute, "rtcp-xr", within the existing IANA registry of SDP Parameters. It defines a new IANA registry, the registry of RTCP XR SDP Parameters, and an initial set of six parameters, and describes how additional parameters are to be allocated. 6.1 XR Packet Type The XR packet type defined by this document is registered with the IANA as packet type 207 in the registry of RTP RTCP Control Packet Friedman et al. Standards Track [Page 41] =0C Internet-Draft RTCP XR April 2003 types (PT). 6.2 RTCP XR Block Type Registry This document creates an IANA registry called the RTCP XR Block Type Registry to cover the name space of the Extended Report block type (BT) field specified in Section 3. The BT field contains eight bits, allowing 256 values. The RTCP XR Block Type Registry is to be managed by the IANA according to the Specification Required policy of RFC 2434 [7]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document: BT name -- ---- 1 Loss RLE Report Block 2 Duplicate RLE Report Block 3 Packet Receipt Times Report Block 4 Receiver Reference Time Report Block 5 DLRR Report Block 6 Statistics Summary Report Block 7 VoIP Metrics Report Block The BT value 255 is reserved for future extensions. Furthermore, future specifications SHOULD avoid the value 0. Doing so facilitates packet validity checking, since an all-zeros field might commonly be found in an ill-formed packet. Any registration MUST contain the following information: - Contact information of the one doing the registration, including at least name, address, and email. - The format of the block type being registered, consistent with the extended report block format described in Section 3. 6.3 The "rtcp-xr" SDP Attribute This SDP attribute "rtcp-xr" defined by this document is registered with the IANA registry of SDP Parameters as follows: SDP Attribute ("att-field"): Attribute name: rtcp-xr Long form: RTP Control Protocol Extended Report Parameters Friedman et al. Standards Track [Page 42] =0C Internet-Draft RTCP XR April 2003 Type of name: att-field Type of attribute: session and media level Subject to charset: no Purpose: see Section 5 of this document Reference: this document Values: see this document and registrations below The attribute has an extensible parameter field and therefore a registry for these parameters is required. This document creates an IANA registry called the RTCP XR SDP Parameters Registry. It contains the six parameters defined in Section 5.1: "pkt-loss-rle", "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and "recv-rtt". Additional parameters are to be added to this registry in accordance with the Specification Required policy of RFC 2434 [7]. Any registration MUST contain the following information: - Contact information of the one doing the registration, including at least name, address, and email. - An Augmented Backus-Naur Form (ABNF) [2] definition of the parameter, in accordance with the "format-ext" definition of Section 5.1. - A description of what the parameter represents and how it shall be interpreted, both normally and in Offer/Answer. 7. Security Considerations This document extends the RTCP reporting mechanism. The security considerations that apply to RTCP reports [9, Appendix B] also apply to XR reports. This section details the additional security considerations that apply to the extensions. The extensions introduce heightened confidentiality concerns. Standard RTCP reports contain a limited number of summary statistics. The information contained in XR reports is both more detailed and more extensive (covering a larger number of parameters). The per- packet report blocks and the VoIP Metrics Report Block provide examples. The per-packet information contained in Loss RLE, Duplicate RLE, and Packet Receipt Times Report Blocks facilitates multicast inference of network characteristics (MINC) [11]. Such inference can reveal the gross topology of a multicast distribution tree, as well as parameters, such as the loss rates and delays, along paths between branching points in that tree. Such information might be considered Friedman et al. Standards Track [Page 43] =0C Internet-Draft RTCP XR April 2003 sensitive to autonomous system administrators. The VoIP Metrics Report Block provides information on the quality of ongoing voice calls. Though such information might be carried in application specific format in standard RTP sessions, making it available in a standard format here makes it more available to potential eavesdroppers. No new mechanisms are introduced in this document to ensure confidentiality. Encryption procedures, such as those being suggested for a Secure RTCP (SRTCP) [12] at the time that this document was written, can be used when confidentiality is a concern to end hosts. Given that RTCP traffic can be encrypted by the end hosts, autonomous systems must be prepared for the fact that certain aspects of their network topology can be revealed. Any encryption or filtering of XR report blocks entails a loss of monitoring information to third parties. For example, a network that establishes a tunnel to encrypt VoIP Report Blocks denies that information to the service providers traversed by the tunnel. The service providers cannot then monitor or respond to the quality of the VoIP calls that they carry, potentially creating problems for the network's users. As a default, XR packets should not be encrypted or filtered. The extensions also make certain denial of service attacks easier. This is because of the potential to create RTCP packets much larger than average with the per packet reporting capabilities of the Loss RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the automatic bandwidth adjustment mechanisms in RTCP, if some session participants are sending large RTCP packets, all participants will see their RTCP reporting intervals lengthened, meaning they will be able to report less frequently. To limit the effects of large packets, even in the absence of denial of service attacks, applications SHOULD place an upper limit on the size of the XR report blocks they employ. The "thinning" techniques described in Section 4.1 permit the packet-by-packet report blocks to adhere to a predefined size limit. A. Algorithms A.1 Sequence Number Interpretation This the algorithm suggested by Section 4.1 for keeping track of the sequence numbers from a given sender. It implements the accounting practice required for the generation of Loss RLE Report Blocks. This algorithm keeps track of 16 bit sequence numbers by translating Friedman et al. Standards Track [Page 44] =0C Internet-Draft RTCP XR April 2003 them into a 32 bit sequence number space. The first packet received from a source is considered to have arrived roughly in the middle of that space. Each packet that follows is placed either ahead or behind the prior one in this 32 bit space, depending upon which choice would place it closer (or, in the event of a tie, which choice would not require a rollover in the 16 bit sequence number). // The reference sequence number is an extended sequence number // that serves as the basis for determining whether a new 16 bit // sequence number comes earlier or later in the 32 bit sequence // space. u_int32 _src_ref_seq; bool _uninitialized_src_ref_seq; // Place seq into a 32-bit sequence number space based upon a // heuristic for its most likely location. u_int32 extend_seq(const u_int16 seq) { u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b; if(_uninitialized_src_ref_seq) { // This is the first sequence number received. Place // it in the middle of the extended sequence number // space. _src_ref_seq =3D seq | 0x80000000u; _uninitialized_src_ref_seq =3D false; extended_seq =3D _src_ref_seq; } else { // Prior sequence numbers have been received. // Propose two candidates for the extended sequence // number: seq_a is without wraparound, seq_b with // wraparound. seq_a =3D seq | (_src_ref_seq & 0xFFFF0000u); if(_src_ref_seq < seq_a) { seq_b =3D seq_a - 0x00010000u; diff_a =3D seq_a - _src_ref_seq; diff_b =3D _src_ref_seq - seq_b; } else { seq_b =3D seq_a + 0x00010000u; diff_a =3D _src_ref_seq - seq_a; diff_b =3D seq_b - _src_ref_seq; } // Choose the closer candidate. If they are equally // close, the choice is somewhat arbitrary: we choose Friedman et al. Standards Track [Page 45] =0C Internet-Draft RTCP XR April 2003 // the candidate for which no rollover is necessary. if(diff_a < diff_b) { extended_seq =3D seq_a; } else { extended_seq =3D seq_b; } // Set the reference sequence number to be this most // recently-received sequence number. _src_ref_seq =3D extended_seq; } // Return our best guess for a 32-bit sequence number that // corresponds to the 16-bit number we were given. return extended_seq; } A.2 Example Burst Packet Loss Calculation. This is an algorithm for measuring the burst characteristics for the VoIP Metrics Report Block (Section 4.7). It is reproduced from ETSI TS 101 329-5 [3]. The algorithm is event driven and hence extremely computationally efficient. Given the following definition of states: state 1 =3D received a packet during a gap state 2 =3D received a packet during a burst state 3 =3D lost a packet during a burst state 4 =3D lost an isolated packet during a gap The "c" variables below correspond to state transition counts, i.e. c14 is the transition from state 1 to state 4. It is possible to infer one of a pair of state transition counts to an accuracy of 1 which is generally sufficient for this application. "pkt" is the count of packets received since the last packet was declared lost or discarded and "lost" is the number of packets lost within the current burst. "packet_lost" and "packet_discarded" are Boolean variables that indicate if the event that resulted in this function being invoked was a lost or discarded packet. if(packet_lost) { loss_count++; } Friedman et al. Standards Track [Page 46] =0C Internet-Draft RTCP XR April 2003 if(packet_discarded) { discard_count++; } if(!packet_lost && !packet_discarded) { pkt++; } else { if(pkt >=3D gmin) { if(lost =3D=3D 1) { c14++; } else { c13++; } lost =3D 1; c11 +=3D pkt; } else { lost++; if(pkt =3D=3D 0) { c33++; } else { c23++; c22 +=3D (pkt - 1); } } pkt =3D 0; } At each reporting interval the burst and gap metrics can be calculated as follows. // Calculate additional transition counts. c31 =3D c13; c32 =3D c23; ctotal =3D c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; // Calculate burst and densities. p32 =3D c32 / (c31 + c32 + c33); if((c22 + c23) < 1) { p23 =3D 1; } else { p23 =3D 1 - c22/(c22 + c23); } burst_density =3D 256 * p23 / (p23 + p32); gap_density =3D 256 * c14 / (c11 + c14); Friedman et al. Standards Track [Page 47] =0C Internet-Draft RTCP XR April 2003 // Calculate burst and gap durations in ms m =3D frameDuration_in_ms * framesPerRTPPkt; gap_length =3D (c11 + c14 + c13) * m / c13; burst_length =3D ctotal * m / c13 - lgap; /* calculate loss and discard rates */ loss_rate =3D 256 * loss_count / ctotal; discard_rate =3D 256 * discard_count / ctotal; Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11 [5]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Friedman et al. Standards Track [Page 48] =0C Internet-Draft RTCP XR April 2003 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgments We thank the following people: Colin Perkins, Steve Casner, and Henning Schulzrinne for their considered guidance; Sue Moon for helping foster collaboration between the authors; Mounir Benzaid for drawing our attention to the reporting needs of MLDA; Dorgham Sisalem and Adam Wolisz for encouraging us to incorporate MLDA block types; and Jose Rey for valuable review of the SDP Signaling section. Contributors The following people are the authors of this document: Kevin Almeroth, UCSB Ramon Caceres, ShieldIP Alan Clark, Telchemy Robert Cole, AT&T Labs Nick Duffield, AT&T Labs-Research Timur Friedman, Paris 6 Kaynam Hedayat, Brix Networks Kamil Sarac, UT Dallas Magnus Westerlund, Ericsson The principal people to contact regarding the individual report blocks described in this document are as follows: sec. report block principal contributors ---- ------------ ---------------------- 4.1 Loss RLE Report Block Friedman, Caceres, Duffield 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield 4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield 4.4 Receiver Reference Time Report Block Friedman 4.5 DLRR Report Block Friedman 4.6 Statistics Summary Report Block Almeroth, Sarac 4.7 VoIP Metrics Report Block Clark, Cole, Hedayat Friedman et al. Standards Track [Page 49] =0C Internet-Draft RTCP XR April 2003 The principal person to contact regarding the SDP signaling described in this document is Magnus Westerlund. Authors' Addresses Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106 USA Ramon Caceres ShieldIP, Inc. 11 West 42nd Street, 31st Floor New York, NY 10036 USA Alan Clark Telchemy Incorporated 3360 Martins Farm Road, Suite 200 Suwanee, GA 30024 USA Tel: +1 770 614 6944 Fax: +1 770 614 3951 Robert Cole AT&T Labs 330 Saint Johns Street, 2nd Floor Havre de Grace, MD 21078 USA Tel: +1 410 939 8732 Fax: +1 410 939 8732 Nick Duffield AT&T Labs-Research 180 Park Avenue, P.O. Box 971 Florham Park, NJ 07932-0971 USA Tel: +1 973 360 8726 Fax: +1 973 360 8050 Timur Friedman Universite Pierre et Marie Curie (Paris 6) Laboratoire LiP6-CNRS 8, rue du Capitaine Scott 75015 PARIS France Tel: +33 1 44 27 71 06 Fax: +33 1 44 27 74 95 Friedman et al. Standards Track [Page 50] =0C Internet-Draft RTCP XR April 2003 Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA Tel: +1 978 367 5600 Fax: +1 978 367 5700 Kamil Sarac Department of Computer Science (ES 4.207) Eric Jonsson School of Engineering & Computer Science University of Texas at Dallas Richardson, TX 75083-0688 USA Tel: +1 972 883 2337 Fax: +1 972 883 2349 Magnus Westerlund Ericsson Research, Corporate Unit Ericsson Radio Systems AB SE-164 80 Stockholm Sweden Tel: +46 8 404 82 87 Fax: +46 8 757 55 50 References The references are divided into normative references and non- normative references. Normative References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, IETF, March 1997. [2] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Engineering Task Force, November 1997. [3] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI TS 101 329-5 V1.1.1 (2000-11), November 2000. [4] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, Internet Engineering Task Force, April 1998. [5] R. Hovey and S. Bradner, "The Organizations Involved in the IETF Standards Process," best current practice BCP 11, RFC 2028, IETF, October 1996. [6] ITU-T, "The E-Model, a computational model for use in transmission planning," Recommendation G.107 (05/00), May 2000. Friedman et al. Standards Track [Page 51] =0C Internet-Draft RTCP XR April 2003 [7] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," best current practice BCP 26, RFC 2434, IETF, October 1998. [8] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, Internet Engineering Task Force, June 2002. [9] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, IETF, February 1996. [10] TIA/EIA-810-A Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones, December 2000. Non-Normative References [11] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The Use of End-to-End Multicast Measurements for Characterizing Internal Network Behavior," IEEE Communications Magazine, May 2000. [12] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman, "The Secure Real-time Transport Protocol," Internet-Draft draft-ietf-avt- srtp-05.txt, June 2002. Note: this is is a work in progress. [13] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu measurement infrastructures using RTP," Proc. IEEE Infocom 2002. [14] A. D. Clark, "Modeling the Effects of Burst Packet Loss and Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 2001. [15] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol", RFC 2974, Internet Engineering Task Force, October 2000. [16] J. Reynolds, "Assigned Numbers: RFC 1700 is Replaced by an On- line Database", RFC 3232, IETF, January 2002. [17] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 1998. [18] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Control Framework for Heterogeneous Multicast Environments", Proc. IWQoS 2000. Friedman et al. Standards Track [Page 52] =0C --------------Boundary-00=_VWQ6VCCHG26EA113DZYL-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 1 15:25:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02671 for ; Thu, 1 May 2003 15:25:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41JVeJ18238 for avt-archive@odin.ietf.org; Thu, 1 May 2003 15:31:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JPf816690; Thu, 1 May 2003 15:25:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4192W804404 for ; Thu, 1 May 2003 05:02:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02736 for ; Thu, 1 May 2003 04:55:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B9tB-0007UQ-00 for avt@ietf.org; Thu, 01 May 2003 04:58:01 -0400 Received: from [220.117.193.11] (helo=mail.nextreaming.com) by ietf-mx with esmtp (Exim 4.12) id 19B9t5-0007U6-00 for avt@ietf.org; Thu, 01 May 2003 04:57:55 -0400 content-class: urn:content-classes:message Subject: RE: [AVT] The storage format of EVRC/SMV vocoder (resent) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 1 May 2003 17:57:37 +0900 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [AVT] The storage format of EVRC/SMV vocoder (resent) Thread-Index: AcMKPG05nsWf1kL4QuaVTtnFA3KUFwE3a9Lg From: "Jae-Yong Lee" To: "Adam Li" , "Colin Perkins" Cc: , "Scott Bradner" , "Allison Mankin" , , , , "??? (E-mail)" , "??? (E-mail)" , "??? (E-mail)" , "??? (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4194c804436 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello all, I regret not being able to respond earlier. It took some time to contact all the Korean operators and reconfirm their opinions related to this issue. As the representative of Korean operators (SKT/KTF/LGT) for file format issues in 3GPP2, I'd like to clarify the current situation for Korean operators and deliver our opinions on this issue. (I cc:ed relevant people from the operators.) >> My information on the implementation of the evrc-smv draft's format >> is that Nextreaming uses this as an internal intermediate format >> prior to generating ".3g2" files (as specified in the 3GPP2 FFMS >> specification, which include both formats). This is not correct. The EVRC storage format described in the evrc-smv draft is utilized for Korean operators in such way as described in the current 3GPP2 FFMS specification, which is actually the only way for EVRC media storage in the 3GPP2 multimedia file format (.3g2). The way of storing EVRC media in .3g2 file is exactly same as the way described in the evrc-smv draft except for the magic number, "#!EVRC\n", which will not be included in the .3g2 file format. That is conceptually same as AMR storage in 3GPP file format. One of the most important rationale behind this is to facilitate the conversion of 3GPP2 files from/to EVRC-only files (.3g2 <-> .evc), which may be very helpful for some applications, e.g., MMS. Having said that, Nextreaming is not the only one that implements and uses it. The relevant terminal and system vendors for Korean operators have completed implementation based on this format and verified interop. Korean operators (also many others in 3GPP2 as far as I understand) have been waiting for the evrc-smv draft with the storage method to be approved as an RFC and are looking forward to it. We also share the opinion that the evrc-smv internet draft is independent of the possible registration of MIME type for .qcp. BR, Jay > -----Original Message----- > From: Adam Li [mailto:adamli@icsl.ucla.edu] > Sent: Thursday, April 24, 2003 5:34 PM > To: 'Colin Perkins' > Cc: avt@ietf.org; 'Scott Bradner'; 'Allison Mankin'; > craig.greer@nokia.com; Jae-Yong Lee; sakazawa@kddilabs.jp; > keith.miller@nokia.com > Subject: RE: [AVT] The storage format of EVRC/SMV vocoder (resent) > > > Dear Colin, > > Thank you very much for your email. I completely agree with you that > these two drafts are rather independent drafts which are not > necessarily > exclusive of each other. As you mentioned, both formats have been used > by one or more applications in the software and telecom > industries, and > we all agree with you that it will be very helpful to listen to the > opinions of the industries which will rely upon IETF for the protocol > standards. > > The registration MIME type of the EVRC and SMV codec has been > halted at > IANA in the last minute because of the new draft on this > storage format > issue. From the perspective of participants in IETF and as > engineers/researchers, we all wish to see the RTP payload format for > these codecs being used rather than proprietary formats being > implemented in the systems which will cause the interoperability > problems later. It will be particularly disturbing if this > would happen > while the international standards are waiting to replace the "Work in > progress" with "RFC xxxx". > > The RTP payload type specification for EVRC and SMV has been > in working > in AVT for 2.5 years, and is now stalled at RFC editor's > queue. Two and > a half years is a long time in the telecommunication > industry, and it is > a long time for Internet community too. > > I believe whatever proposal one supports, we all hope to see a swift > ending to this issue with a fair conclusion while giving each of the > proposed format the objective consideration it deserves. > > Thank you very much, > > Adam > > > > -----Original Message----- > > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of > > Colin Perkins > > Sent: Wednesday, April 23, 2003 6:52 AM > > To: Adam Li > > Cc: avt@ietf.org; 'Scott Bradner'; 'Allison Mankin'; > > craig.greer@nokia.com; jlee@nextreaming.com; sakazawa@kddilabs.jp; > > keith.miller@nokia.com > > Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) > > > > Adam, > > > > My understanding is that there have been implementations of the QCP > > format > > for several years now, but the MIME type has not been registered. > > The MIME > > type should be registered, to document this use. > > > > This is independent of whether the EVRC/SMV file format is also > > registered. > > > > Colin > > > > > > > > --> "Adam Li" writes: > > >Dear Colin, > > > > > >Thank you very much for your email. We all have agreed on the fact > > that > > >.QCP is used by Eudora while .EVC/.SMV are used by 3G service > > providers. > > > > > >However, I have difficulty seeing the rationale for your opinion > > that > > >the registration of .QCP is clearly needed while the registration > > of > > >.EVC/.SMV is the opposite. Would you mind explain to us AVT'ers > > your > > >rationales and pointing out the factors that we missed in the > > discussion > > >so we can better understand your opinions? > > > > > >With all the factors that have been expressed on this issue which > > are > > >summarized in the previous email, it does not seem that the major > > >consensus is inclining that way. Maybe we missed something? > > > > > >Your opinion is very much appreciated. > > > > > >Adam > > > > > > > > >> -----Original Message----- > > >> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of > > >> Colin Perkins > > >> Sent: Tuesday, April 22, 2003 10:27 AM > > >> To: Adam Li > > >> Cc: avt@ietf.org; 'Scott Bradner'; 'Allison Mankin'; > > >> craig.greer@nokia.com; jlee@nextreaming.com; > sakazawa@kddilabs.jp; > > >> keith.miller@nokia.com > > >> Subject: Re: [AVT] The storage format of EVRC/SMV > vocoder (resent) > > >> > > >> Adam, > > >> > > >> The format specified in draft-garudadri-qcp-00.txt clearly needs > > to > > >> be > > >> published, and to have a MIME type registered, since it has been > > >> used by > > >> several applications for some years now. > > >> > > >> What is unclear is whether draft-ieft-avt-evrc-smv-03.txt should > > >> refer to > > >> that format, or if it should continue to use the alternative > > format. > > >> The > > >> usual arguments apply: having two formats is clearly worse than > > one, > > >> but > > >> there may be technical or political reasons why the new format is > > to > > >> be > > >> preferred for some uses. > > >> > > >> As the minutes from the recent AVT meeting note, the main users > > of > > >> the > > >> format in draft-ieft-avt-evrc-smv-03.txt seem to be 3GPP2. It is > > >> currently > > >> unclear if they have implementations of the file format, and if > > they > > >> chose > > >> it for technical reasons or because it it was the only format > > they > > >> knew. We > > >> are hoping to get input from them, to clarify their position. > > >> > > >> Colin > > >> > > >> > > >> > > >> > > >> --> "Adam Li" writes: > > >> > > > >> >The issue of the storage format of the EVRC and SMV vocoders in > > the > > >> MIME > > >> >registration has came up a while ago, and has caused the last > > >> minute > > >> >holding of the MIME registration for these two vocoders. The > > issue > > >> has > > >> >been discussed thoroughly here on the mailing list in the San > > >> Francisco > > >> >meeting. The reasons of each side of the argument have been well > > >> >presented. Now it may be time to make a decision? > > >> > > > >> >Like many other issues in our AVT WG, the decision here is > > >> ultimately > > >> >relying on the judgment of our chairs. During the two and half > > >> years > > >> >that this draft is being developed in the AVT, the course of the > > >> draft > > >> >has benefited greatly from your guidance. After the open and > > ego- > > >> free > > >> >discuss that our chairs called upon at the meeting session, it > > may > > >> be > > >> >another good time to hear the opinions from the chairs and get > > some > > >> help > > >> >on the decision from their experience and vision on which one > > will > > >> >reflect the consensus of the AVT and would be most beneficial to > > >> the > > >> >whole Internet and telecom industry who will use our > > specification. > > >> > > > >> >Below is the summary of the rationales for each of the choices: > > >> > > > >> > draft-ieft-avt-evrc-smv-03.txt | draft-garudadri-qcp- > > 00.txt > > >> >------------------------------------+--------------------------- > > --- > > >> -- > > >> >(1) Mature specification, been | (1) Brand new ID > > >> > developed for 2.5 years in AVT | > > >> >------------------------------------+--------------------------- > > --- > > >> -- > > >> >(2) Covers both EVRC and SMV | (2) Only cover EVRC > > >> >------------------------------------+--------------------------- > > --- > > >> -- > > >> >(3) Referred to by 3GPP2(*) FFMS | (3) > > >> > specifications | > > >> >------------------------------------+--------------------------- > > --- > > >> -- > > >> >(4) Implemented and used by many 3G | (4) Supported in Eudora > > >> > telecom operators (e.g., SKT, | > > >> > KTF, LGT). The interoperability | > > >> > has been tested among them. | > > >> >------------------------------------+--------------------------- > > --- > > >> -- > > >> >(5) Simple and efficient design, | (5) > > >> > quick to implement | > > >> >------------------------------------+--------------------------- > > --- > > >> -- > > >> >(6) Registration already in IANA, | (6) > > >> >------------------------------------+--------------------------- > > --- > > >> -- > > >> >(7) Supported and developed by 7 | (7) Supported and > > developed > > >> by > > >> > companies and universities | Qualcomm > > >> > (including Qualcomm) | > > >> >------------------------------------+--------------------------- > > --- > > >> -- > > >> >(8) No IP related to this format | (8) IP situation unclear > > >> >------------------------------------+--------------------------- > > --- > > >> -- > > >> > > > >> >(*) ERVC and SMV are both vocoders developed and defined in the > > >> >international consortium 3GPP2 (http://www.3gpp2.org) for the > > next > > >> >generation wireless network cdma2000. > > >> > > > >> >Thank you very much. > > >> > > > >> >Adam > > >> > > > >> >PS. This is a resent of the previous message, which did not seem > > to > > >> go > > >> >through maybe because of the long cc list. If you think anyone > > is > > >> missed > > >> >out, please let me know. Thanks. > > >> > > > >> >> -----Original Message----- > > >> >> From: Adam Li [mailto:adamli@icsl.ucla.edu] > > >> >> Sent: Saturday, March 15, 2003 9:20 PM > > >> >> To: 'Ietf-Avt' > > >> >> Cc: 'casner@acm.org'; 'Scott Bradner'; 'Colin Perkins'; > > 'Allison > > >> >> Mankin'; 'randy@qualcomm.com'; 'mccap@lucent.com'; > > >> >> 'mdturner@lucent.com'; 'smathai@lucent.com'; > > 'lioy@qualcomm.com'; > > >> >> 'zeng@packetvideo.com'; 'sherwood@packetvideo.com'; > > >> >> 'villa@icsl.ucla.edu'; 'yllee@samsung.com'; > > >> 'jeonghoon@samsung.com'; > > >> >> 'tom.hiller@lucent.com'; 'David.Leon@nokia.com'; > > >> >> 'nleung@qualcomm.com'; 'dgal@lucent.com'; > > >> 'ajayrajkumar@lucent.com'; > > >> >> 'Lars-Erik.Jonsson@epl.ericsson.se'; 'magnus.westerlund@era- > > >> >> t.ericsson.se'; 'vbharga@cisco.com'; 'craig.greer@nokia.com'; > > >> >> 'magda@qualcomm.com'; 'casner@acm.org'; > > 'ned.freed@mrochek.com'; > > >> >> 'mankin@psg.com'; 'hgarudad@qualcomm.com'; 'csp@isi.edu'; > > >> >> 'jlee@nextreaming.com'; 'sakazawa@kddilabs.jp'; > > 'tsgc@3gpp2.org' > > >> >> Subject: Issues for the file format for EVRC/SMV vocoder > > >> >> > > >> >> Hi folks, > > >> >> > > >> >> The topic of the file format for EVRC/SMV vocoders hopefully > > will > > >> be > > >> >> discussed in this meeting at San Francisco. Below is a list of > > >> the > > >> >> issues that might be related to this topic. They are listed > > here > > >> as > > >> >> potential issues for you to consider before the discussion at > > the > > >> >> meeting. > > >> >> > > >> >> (1) Technically differences. Is there much difference in > > >> efficiency > > >> >> and performance between the format in draft-ietf-avt-evrc-smv > > and > > >> >> draft-garudadri-qcp? Are the differences simply on the file > > >> syntax? > > >> >> > > >> >> (2) Completeness. For EVRC codec data, formats defined in both > > >> >> document can handle it. For SMV codec data, the format defined > > in > > >> >> draft-ietf-avt-evrc-smv is currently the only file format that > > >> >> handles SMV data. draft-garudadri-qcp does not handle SMV at > > this > > >> >> time. > > >> >> > > >> >> (3) Maturity of the format definition. draft-ietf-avt-evrc-smv > > >> has > > >> >> its first version submitted to AVT on November 2000. It has > > been > > >> >> actively worked on all these years, and is co-authored by > > people > > >> >> from seven companies and universities. It is currently on the > > RFC > > >> >> editor's queue. draft-garudadri-qcp is submitted in February > > 2003. > > >> >> Will there be concerns about the maturity of the drafts, > > >> >> particularly the handling of SMV codec hasn't been written in > > the > > >> >> later draft yet? > > >> >> > > >> >> (4) The recognition. Since EVRC and SMV codec are designed in > > >> 3GPP2 > > >> >> for their CDMA networks, formats recognized by them are likely > > to > > >> be > > >> >> the most widely used format for those codecs. Which of the > > >> formats, > > >> >> as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, > > >> has > > >> >> been considered by 3GPP2 for the format for storing EVRC and > > SMV > > >> >> data? > > >> >> > > >> >> (5) Document organization. Even though this is a rather minor > > >> point, > > >> >> but would there be enough reasons to trade-off for the > > additional > > >> >> complexity for having the MIME registration of EVRC/SMV > > refering > > >> to > > >> >> a separate and yet to be complete draft? > > >> >> > > >> >> Draft-ietf-avt-evrc-smv is currently on the RFC > editor's queue. > > >> If > > >> >> we want to consider deleting the file format that is in the > > draft > > >> >> for almost two years in the last minute before it becomes an > > RFC > > >> and > > >> >> using another yet to be complete new draft instead, we should > > be > > >> >> providing ourselves with the clear justification for doing so. > > >> > > > >> >> I will not be there for the discussion unfortunately since I > > have > > >> >> not made the plan to attend in advance. However, I hope the > > list > > >> of > > >> >> potential issues above might be useful for us to discuss and > > >> >> consider. > > >> >> > > >> >> Wish we have a fruitful meeting in San Francisco. > > >> >> > > >> >> Adam > > >> > > > >> > > > >> >_______________________________________________ > > >> >Audio/Video Transport Working Group > > >> >avt@ietf.org > > >> >https://www1.ietf.org/mailman/listinfo/avt > > >> _______________________________________________ > > >> Audio/Video Transport Working Group > > >> avt@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/avt > > > > > >_______________________________________________ > > >Audio/Video Transport Working Group > > >avt@ietf.org > > >https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 1 15:26:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02819 for ; Thu, 1 May 2003 15:26:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h41JWnY18850 for avt-archive@odin.ietf.org; Thu, 1 May 2003 15:32:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JW7818687; Thu, 1 May 2003 15:32:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h41JVS818216 for ; Thu, 1 May 2003 15:31:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02461; Thu, 1 May 2003 15:24:46 -0400 (EDT) Message-Id: <200305011924.PAA02461@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 01 May 2003 15:24:46 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-report-extns-05.txt,.pdf Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Control Protocol Extended Reports (RTCP XR) Author(s) : T. Friedman et al. Filename : draft-ietf-avt-rtcp-report-extns-05.txt,.pdf Pages : 52 Date : 2003-5-1 This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-report-extns-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcp-report-extns-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-1153521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-report-extns-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-1153521.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 2 12:54:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20773 for ; Fri, 2 May 2003 12:54:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h42H0st06325 for avt-archive@odin.ietf.org; Fri, 2 May 2003 13:00:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42H05806265; Fri, 2 May 2003 13:00:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h42Gwn806001 for ; Fri, 2 May 2003 12:58:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20515 for ; Fri, 2 May 2003 12:51:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19BdnE-0005eW-00 for avt@ietf.org; Fri, 02 May 2003 12:53:52 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 19Bdn8-0005cM-00 for avt@ietf.org; Fri, 02 May 2003 12:53:46 -0400 Received: from cscoamera13263.cisco.com (rtp-vpn1-117.cisco.com [10.82.224.117]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h42GqiWT007912; Fri, 2 May 2003 12:52:45 -0400 (EDT) Message-Id: <5.1.1.5.2.20030502094532.0b8acdc0@agora.rdrop.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 02 May 2003 09:52:43 -0700 To: avt@ietf.org From: Mark Baugher Cc: Allison Mankin In-Reply-To: <200305011148.HAA05638@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Re: I-D ACTION:draft-ietf-avt-srtp-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hello, We have prepared this version of the I-D for the IESG review. It contains the following changes, most of which are what we said we were going to do in the foil presented to the last AVT WG meeting. 1. Authentication tag length # Made 80-bit SRTP authentication the default # Crafted precise language about when a NULL (zero length) or short (e.g. 32-bit) SRTP authentication tag is acceptable and its elaborated the risks # Added text describing replay attacks For the above, Section 7.5 has been added, and Section 9.5 has been extended. # Mandated 80-bit SRTCP authentication # Removed "error tolerance" from the spec (i.e. we eliminated non-propagation of bit errors from the goals) # Mandated automatic key generation/management 2. Reflect recent feedback from programmers # Clarifications on re-keying, i.e. the use of the vs MKI (Section 8.1: the to be used in simple scenarios, MKI recommended) # The master key sharing is allowed only within the same RTP session (before was allowed also between RTP sessions, but that caused complexity due to the risk of SSRC collision and two-time pad) 3. Fixed a mistake Changed the length of the authentication session key for HMAC/SHA1 from 128 to 160 bits (to conform to RFC 2104 recommendations) 4. Cleaned up Scenarios (section 11) cleaned up. Some language fixing (e.g. variable -> configurable, some mandatory --> recommended). Mark At 07:48 AM 5/1/2003 -0400, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Audio/Video Transport Working Group of >the IETF. > > Title : The Secure Real-time Transport Protocol > Author(s) : M. Baugher et al. > Filename : draft-ietf-avt-srtp-06.txt > Pages : 53 > Date : 2003-4-30 > >This document describes the Secure Real-time Transport Protocol >(SRTP), a profile of the Real-time Transport Protocol (RTP), which >can provide confidentiality, message authentication, and replay >protection to the RTP/RTCP traffic. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-06.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-avt-srtp-06.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-avt-srtp-06.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-4-30150740.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-avt-srtp-06.txt > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat May 3 23:10:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13376 for ; Sat, 3 May 2003 23:10:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h443HU328331 for avt-archive@odin.ietf.org; Sat, 3 May 2003 23:17:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h443Gd828303; Sat, 3 May 2003 23:16:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h43Kl0806339 for ; Sat, 3 May 2003 16:47:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08474 for ; Sat, 3 May 2003 16:39:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19C3oi-00064m-00 for avt@ietf.org; Sat, 03 May 2003 16:41:08 -0400 Received: from lsh110.siteprotect.com ([66.113.130.251]) by ietf-mx with esmtp (Exim 4.12) id 19C3oN-00063s-00 for avt@ietf.org; Sat, 03 May 2003 16:40:47 -0400 Received: from WOL (209-6-134-75.c3-0.lex-ubr3.sbo-lex.ma.cable.rcn.com [209.6.134.75]) by lsh110.siteprotect.com (8.11.6/8.11.6) with ESMTP id h43KdwI09220; Sat, 3 May 2003 15:39:58 -0500 From: "Oliver Morgan" To: , Cc: , , Date: Sat, 3 May 2003 16:39:57 -0400 Message-ID: <011a01c311b4$29e7d2f0$0200a8c0@WOL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <3E754BDA.70307@csiro.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 Content-Transfer-Encoding: 7bit Subject: [AVT] RE: (s22-list) Re: Comments, draft-pfeiffer-temporal-fragments-00 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Ms. Pfeiffer and Mr. Parker, I have read and concur with Bill Miller's comments on your draft on temporal fragments. As an additional input, you might like to contemplate recommending a notation for fragments of known duration. It is conventional to express these in television systems as two SMPTE timecodes, an IN and an OUT time. The IN time specifies the first frame or field that is included in the interval; the OUT time specifies the first frame or field that is *not* included in the interval. Thus an interval of duration 10 frames might be specified as #@smpte=01:00:00.00-01:00:00.10 best regards Oliver Morgan Metaglue Corporation +1 781 862 2106 voice/fax +1 781 962 3997 cell oliver@metaglue.com > -----Original Message----- > From: owner-s22-list@eng.smpte.org > [mailto:owner-s22-list@eng.smpte.org] On Behalf Of > Silvia.Pfeiffer@csiro.au > Sent: Sunday, March 16, 2003 11:15 PM > To: William.C.Miller@abc.com > Cc: Conrad.Parker@csiro.au; s22-list@eng.smpte.org; avt@ietf.org > Subject: (s22-list) Re: Comments, draft-pfeiffer-temporal-fragments-00 > > > Dear Mr. Miller, > > I am delighted to get feedback from you and the SMPTE > community on our > timed URI fragment specification proposal. I would like to thank you > very much for your well elaborated comments which we are more > than happy > to include into our proposal. > > We will be developing another version of the document over > the next few > weeks. If I may, I would like to forward you the next > version, just to > make sure we haven't overlooked anything. > > Also, in case there are any relevant changes in the new > version of SMPTE > 12M, I would be very happy if you could make me aware of them. > > Thank you very much indeed. > > Best Regards, > > Silvia Pfeiffer. > > > Miller, William C wrote: > > Dear Ms. Pfeiffer and Mr. Parker, > > > > Your draft was recently passed on to me by a SMPTE > colleague. I'd like > > to offer a couple of comments. I am not familiar with all of the > > practices of the IETF community, so forgive me if I commit > a solecism or > > two along the way. > > > > I'm chairman of SMPTE S22, the TV Systems Technology > Committee, which > > has responsibility for SMPTE time code. I'm writing as an > individual > > commenter. > > > > 1. SMPTE has about 400 Standards, Recommended Practices > and Engineering > > Guidelines, of which SMPTE time code is just one. The > reference you > > should cite is SMPTE 12M-1999, Time and Control Code. Be > aware that we > > are in the process of considering revisions to this document. > > > > 2. The current version of SMPTE 12M defines time code for > 24, 25 and 30 > > frames per second (fps). Video production standards for > all of these > > exist and are in use. A drop-frame mode is defined for 30 > fps (actually > > 30/1.001 fps) to cover 525-line systems (NTSC > time-compensated mode). > > However, there are now 50, 60 and 60/1.001 fps video production > > standards, and practices have evolved to deal with these within the > > structure of SMPTE 12M. These practices will be added to > 12M as it is > > revised. A possibility also exists that there will be > 24/1.001 fps video. > > > > To be safe you should define syntax to handle all 8 of > these rates (all > > are allowable under MPEG-2, for instance). Recapping them in order: > > > > 24/1.001 "24-drop" (this algorithm is not defined) > > 24 > > 25 > > 30/1.001 "30-drop" > > 30 > > 50 > > 60/1.001 "60-drop" (same algorithm as 30-drop, but 4 frames dropped > > rather than 2) > > 60 > > > > Your draft gives 30 fps (non-drop) as the default; in > practice this is > > the least likely frame rate to be encountered. I believe it is > > preferable to require explicit coding of the frame rate, e. g. > > "smpte-30-time". "smpte-time" should be allowed only for > those cases > > where the user does not know the frame rate; this would > serve as a wild > > card, with best-effort address resolution (the error would > be no more > > than one second, typically much less). > > > > 3. Although not generally understood as such, SMPTE time code is a > > label. Its lowest granularity is the frame for > progressive-scan and > > film material and the field for interlaced material. > Fractional frames > > (fields) are meaningless for video, and in the case of the > /1.001 rates > > are ambiguous for audio. I urge you to delete "smpte-sf". > > > > 4. The first frame of video of a program is normally > 01:00:00:00, not > > 00:00:00:00. This practice arose from the requirements of program > > production and analog videotape recording technology, and it has > > subsequently become a uniform, almost ironclad practice worldwide. > > Users should be made aware of this in an informative note. > > > > I hope these comments are of help in refining your draft. I am > > attaching a copy of SMPTE 12M for your use. Please do not > redistribute > > it except to those involved in the development of this RFC. Thanks. > > > > If I can be of further help please let me know. > > > > Best regards, > > Bill Miller > > > > > > > > William C. Miller > > ABC-TV > > 212-456-4448 > > 212-456-2284 fax > > william.c.miller@abc.com > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 5 17:34:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17191 for ; Mon, 5 May 2003 17:34:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45LgKq05496 for avt-archive@odin.ietf.org; Mon, 5 May 2003 17:42:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Lfi805429; Mon, 5 May 2003 17:41:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45KZ4832023 for ; Mon, 5 May 2003 16:35:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAB14700 for ; Mon, 5 May 2003 16:26:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CmZb-0000XI-00 for avt@ietf.org; Mon, 05 May 2003 16:28:31 -0400 Received: from wireless215.east.isi.edu ([65.123.202.215] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19CmOA-0000QS-00 for avt@ietf.org; Mon, 05 May 2003 16:16:42 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h45KFfJC051473; Mon, 5 May 2003 16:15:41 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: Timur Friedman cc: avt@ietf.org, Stephen Casner , Alan Clark , Ramon Caceres , "Kevin C. Almeroth" , Robert Cole , Nick Duffield , Kaynam Hedayat , Kamil Sarac , Magnus Westerlund Subject: Re: [AVT] Comments on draft-ietf-avt-rtcp-report-extns-04.txt In-Reply-To: Your message of "Thu, 01 May 2003 03:50:44 +0200." <200305010350.44783.timur.friedman@lip6.fr> Date: Mon, 05 May 2003 16:15:41 -0400 Message-ID: <51472.1052165741@purple.nge.isi.edu> From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Timur, Alan, Thanks for the update. These mostly look good, although I have a few comments inline. Colin --> Timur Friedman writes: >I have prepared an 05 version of the draft in response to the Last Call >comments by Colin Perkins and responses from my co-editor Alan Clark. That >draft will follow shortly. What follows are the details of the differences >between the 04 and 05 drafts. > >- Timur Friedman ... >> - In section 4.7.3, the end system delay estimate makes the assumption >> that the system can send and receive, and that it has a local analog >> interface to loop-back audio. Neither of these are necessarily valid. >> Accordingly, the I'd like to see the "MUST be provided" turn into a >> SHOULD, and some explanation of what to do if the data cannot be >> provided. >> >> [Alan] This was defined as an estimated rather than measured delay, and can >> typically be determined by adding known framing and encode/decode delays - >> it was not intended that it be measured literally. We can change the >> wording to clarify. >> "The most recently estimated end system delay, expressed in milliseconds. >> End system delay is defined as the sum of the total sample accumulation and >> encoding delay associated with the sending direction and the jitter buffer, >> decoding and playout buffer delay associated with the receiving direction; >> this delay MAY be estimated or measured. This value MUST be provided in >> all VoIP metrics reports." > >I have incorporated the suggested text. This doesn't address my concern: what about systems that cannot transmit? I might want to build a receiver with no capture and encoding capability, and to have that report on voice quality. What does that receiver do: it cannot estimate the end system delay as specified, yet the draft says it "MUST" be reported? >> - In section 4.7.4, the definition of the residual echo return loss is not >> clear, and seems to assume particular implmentations of gateway devices. >> Recommend separating the normative definition of the field out from the >> non-normative examples of how it might be measured in particular cases. >> >> [Alan] This should be typical of VoIP gateways with line echo cancellers >> and isn't specific to any implementations. I've checked with a number of >> echo canceller software developers and the parameters are typically >> available as ERL and ERLE in dB or in some format that can easily be >> converted. Suggest clarifying the wording to: >> >> The residual echo return loss is defined as the sum of the measured echo >> return loss (ERL) and the echo return loss enhancement (ERLE) of the echo >> canceller (if present) expressed in dB as a signed integer in 2's >> complement form. >> >> The residual echo return loss relates to the effective echo level that a >> user would hear. The amount of echo that can occur in analog loops can be >> significant, and therefore echo cancellers are typically used to try and >> eliminate or reduce the audible echo. The amount of echo is typically >> described as a "echo return loss" (i.e. ratio between the transmitted >> signal level and the received echo level) expressed in dB. The >> effectiveness of an echo canceller is normally described in terms of "echo >> return loss enhancement", i.e. an echo canceller increases the effective >> echo return loss and makes the audible echo smaller. Hence the residual >> echo return loss (RERL) is the sum of the echo return loss (ERL) and the >> echo return loss enhancement (ERLE) expressed in dB. > >I have incorporated the suggested text. This is an improvement, but my main concern was the text following (page 32 of the -05 draft). In particular, I'd like to see the normative description of how the parameter is calculated separated from the examples of particular devices. >> - In section 4.7.5, the fields are mostly 8 bits, with only a subset of >> values being legal. Would it be appropriate to use smaller fields in >> some cases? What should receivers do if they receive a report where a >> field has an illegal value? >> >> [Alan] I suggest keeping these as 8 bit, otherwise we would need to handle >> 6 bit values. We could change the "A value of" sentences to read >> >> "A value of 127 indicates that this parameter is unavailable. Values other >> than 127 and the valid range defined above MUST not be sent and MUST be >> ignored by the receiving system." > >I have incorporated the suggested text. You might consider the use of 6 bit fields, with reserved bits padding out the packet format to 8 bit alignment? Be explicit about the reserved values, rather than hiding them in the text. >> - In section 4.7.5, the chosen values for the PLC are not contiguous: I >> can indicate a PLC that can conceal less than 3% (standard PLC), or >> more than 10% (enhanced PLC), but nothing in the middle. Is there >> intended to be a "better-than-standard but not quite enhanced" range? >> How does this relate to the "unspecified" category? >> >> [Alan] There is a continuum of possibilities in terms of PLC effectiveness. >> "Standard" in this case refers to algorithms that use some form of last >> packet replay with attenuation and filtering/smoothing. "Enhanced" refers >> to algorithms that use some form of error correction(sometimes introducing >> additional delay or bandwidth overhead). "Unspecified" simply means that >> the CODEC details are outside the domain of knowledge of the RTCP XR >> reporting instance - they are typically internal to a DSP. >> I think the standard and enhanced definitions cover what is used in the >> industry today, and generally implementors could figure out which to use. > >This comment refers to Section 4.7.6. In keeping with the response above, I >have made no changes to address this comment. I understand Alan's explanation, but the draft is still unclear. The simplest fix is probably to remove the loss rates from the text, and to improve the explanation of what is intended for each value. >> - In section 4.7.6, the jitter buffer rate assumes that the jitter buffer >> can cope with a step change in jitter from 30ms to 100ms. This seems to >> be somewhat aggressive? >> >> [Alan] Let's hope people aren't using 10BaseT and hubs for VoIP!! :-) Many >> adaptive jitter buffers max out at 200-400mS although they would typically >> operate in the 20-50mS range. As the description suggests, this is >> intended to be an easily measured parameter that provides a guide to the JB >> ramp time, in reality jitter/PDV would not behave quite this way. > >In keeping with the response above, I have made no changes to address this >comment. If you believe a step change from 30ms to 100ms is within the range of adaptation of most implementations, then okay. >> - Section 6.2 should define what information needs to be included in any >> new registrations of attribute block types. There is, presumably, some >> minimum degree of specification that is required for interoperability? > >Yes. I have added the following text: > >--- begin quote --- > >Any registration MUST contain the following information: > >- Contact information of the one doing the registration, including at > least name, address, and email. > >- The format of the block type being registered, consistent with the > extended report block format described in Section 3. > >--- end quote --- ...and presumably, some guideance on how the block is to be used? >> - In section 6.2, if the BT value of 255 is reserved for future extension, >> it becomes necessary to indicate how it might be extended. I expect that >> this space is large enough, that we don't have to worry about reserving >> the block. > >If memory serves, this issue came up when the 03 draft was discussed in open >sesssion in San Francisco. The 03 draft did not have a reserved value. A >suggestion was made to add a reserved value for future extensions. I raised >the concern that then we would need to define an extension mechanism. I >believe it was Henning Schulzrinne who suggested it would suffice to state >that the value is reserved. My impression was that this formed the basis for >a concensus in the room at the time in favor of adding a simple statement >concerning a reserved value, and so I am reluctant to go back on it. I don't recall the discussion, but okay. >> - Appendix A.2: If differences are found, or if the ETSI spec is updated, >> what happens? >> >> [Alan] We are refering to a specific dated release of the ETSI spec. The >> VoIP metrics payload is actually substantially more comprehensive than the >> ETSI spec, which only relates to methods for calculating R factors. >> We should make the reference at the end of the second paragraph in 4.7 "(as >> described by the E Model defined in [6,3]) and.." > >I have made the suggested change. Which spec takes precedence if they are found to differ? The code in A.2 or the code in the ETSI spec? Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 5 17:35:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17245 for ; Mon, 5 May 2003 17:35:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45LhYB05558 for avt-archive@odin.ietf.org; Mon, 5 May 2003 17:43:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45LfW805414; Mon, 5 May 2003 17:41:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h45Dfh801720 for ; Mon, 5 May 2003 09:41:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01292; Mon, 5 May 2003 09:32:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cg7E-0005it-00; Mon, 05 May 2003 09:34:48 -0400 Received: from mail.zrz.tu-berlin.de ([130.149.4.15]) by ietf-mx with esmtp (Exim 4.12) id 19Cg75-0005hj-00; Mon, 05 May 2003 09:34:40 -0400 Received: from mail.zrz.tu-berlin.de ([130.149.4.15]) by mail.zrz.tu-berlin.de with esmtp (exim-4.14-8) id 19Cg62-0001S8-Lz; Mon, 05 May 2003 15:33:34 +0200 Received: from mail.zrz.TU-Berlin.DE ([130.149.4.15]) by mail.zrz.TU-Berlin.DE (MailMonitor for SMTP v1.2.2 ) ; Mon, 5 May 2003 15:33:31 +0200 (CEST) Received: from ftmail.ee.tu-berlin.de ([130.149.49.250]) by mail.zrz.tu-berlin.de with esmtp (exim-4.14-8) id 19Cg5z-0001HI-KS; Mon, 05 May 2003 15:33:31 +0200 Received: from ft.ee.tu-berlin.de (ftsu34.tkn.TU-Berlin.DE [130.149.49.204]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id h45DWRB08634; Mon, 5 May 2003 15:32:27 +0200 Message-ID: <3EB669C0.5010401@ft.ee.tu-berlin.de> Date: Mon, 05 May 2003 15:40:16 +0200 From: Heike Klemz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: klemz CC: Holger Karl Content-Type: multipart/mixed; boundary="------------080302020105080309090201" X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de; Mon, 05 May 2003 15:33:31 +0200 Subject: [AVT] CfP:1st Europaen Workshop on WIreless Sensor Networks Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --------------080302020105080309090201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear Colleague, I would like to draw your attention to the " Frist European Workshop on Wireless Sensor Networks" Berlin, January 2004 (see Attachement). Submission deadline is July 1st, 2003: submission details are available under http://www.ewsn.org Best regards Adam Wolisz --------------080302020105080309090201 Content-Type: application/pdf; name="1_EWSN-Call%20(2).pdf" Content-Disposition: inline; filename="1_EWSN-Call%20(2).pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjEwMyAwIG9iag08PCANL0xpbmVhcml6ZWQgMSANL08gMTA5IA0v SCBbIDIwODggMjczIF0gDS9MIDEyMTIwNyANL0UgOTQwMjYgDS9OIDEgDS9UIDExOTAyOCAN Pj4gDWVuZG9iag0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB4cmVmDTEwMyA1MCANMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAxMzUx IDAwMDAwIG4NCjAwMDAwMDE3MDUgMDAwMDAgbg0KMDAwMDAwMTc0NCAwMDAwMCBuDQowMDAw MDAxODA1IDAwMDAwIG4NCjAwMDAwMDE5NTQgMDAwMDAgbg0KMDAwMDAwMjM2MSAwMDAwMCBu DQowMDAwMDAyODg2IDAwMDAwIG4NCjAwMDAwMDI5MTcgMDAwMDAgbg0KMDAwMDAwMzA3MSAw MDAwMCBuDQowMDAwMDAzMTY4IDAwMDAwIG4NCjAwMDAwMDMyNjUgMDAwMDAgbg0KMDAwMDAw MzM2MiAwMDAwMCBuDQowMDAwMDAzNDU5IDAwMDAwIG4NCjAwMDAwMDM4OTYgMDAwMDAgbg0K MDAwMDAwNDY3NCAwMDAwMCBuDQowMDAwMDA0ODk2IDAwMDAwIG4NCjAwMDAwMDUxMTIgMDAw MDAgbg0KMDAwMDAwNTU0OSAwMDAwMCBuDQowMDAwMDA1Nzc5IDAwMDAwIG4NCjAwMDAwMDU4 MDkgMDAwMDAgbg0KMDAwMDAwNTg2MSAwMDAwMCBuDQowMDAwMDA1OTAyIDAwMDAwIG4NCjAw MDAwMDU5MjUgMDAwMDAgbg0KMDAwMDAwODA4NyAwMDAwMCBuDQowMDAwMDA4MTEwIDAwMDAw IG4NCjAwMDAwMTAxNDggMDAwMDAgbg0KMDAwMDAxMDE3MSAwMDAwMCBuDQowMDAwMDEyMDA2 IDAwMDAwIG4NCjAwMDAwMTIwMjkgMDAwMDAgbg0KMDAwMDAxMzkwMCAwMDAwMCBuDQowMDAw MDEzOTIzIDAwMDAwIG4NCjAwMDAwMTU3ODAgMDAwMDAgbg0KMDAwMDAxNTgwMyAwMDAwMCBu DQowMDAwMDE3ODY1IDAwMDAwIG4NCjAwMDAwMTc4ODggMDAwMDAgbg0KMDAwMDAxOTc0NyAw MDAwMCBuDQowMDAwMDE5NzcwIDAwMDAwIG4NCjAwMDAwMjI0NDggMDAwMDAgbg0KMDAwMDAz NTE4MyAwMDAwMCBuDQowMDAwMDM1MjY3IDAwMDAwIG4NCjAwMDAwNTMzMjEgMDAwMDAgbg0K MDAwMDA4NTEwMyAwMDAwMCBuDQowMDAwMDg1NTM0IDAwMDAwIG4NCjAwMDAwODc0NTAgMDAw MDAgbg0KMDAwMDA4NzUyOSAwMDAwMCBuDQowMDAwMDg3NzM2IDAwMDAwIG4NCjAwMDAwOTA4 MDUgMDAwMDAgbg0KMDAwMDAwMjA4OCAwMDAwMCBuDQowMDAwMDAyMzM5IDAwMDAwIG4NCnRy YWlsZXINPDwNL1NpemUgMTUzDS9JbmZvIDEwMCAwIFIgDS9Sb290IDEwNCAwIFIgDS9QcmV2 IDExOTAxNyANL0lEWzw1NGU5NTNmYWExYjBhMTEwNTIwOWFjN2U5YWFkZjBjOT48NjZhMzQ1 NDQ1Y2Y4OGU0YzRkYjU5MzJiYWY4NWM1ZWM+XQ0+Pg1zdGFydHhyZWYNMA0lJUVPRg0gICAg DTEwNCAwIG9iag08PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyAxMDIgMCBSIA0vTWV0YWRh dGEgMTAxIDAgUiANL1RocmVhZHMgMTA1IDAgUiANL09wZW5BY3Rpb24gWyAxMDkgMCBSIC9Y WVogbnVsbCBudWxsIG51bGwgXSANL1BhZ2VNb2RlIC9Vc2VOb25lIA0vUGFnZUxhYmVscyA5 OSAwIFIgDS9TdHJ1Y3RUcmVlUm9vdCAxMDggMCBSIA0vUGllY2VJbmZvIDw8IC9NYXJrZWRQ REYgPDwgL0xhc3RNb2RpZmllZCAoRDoyMDAzMDQyNzEzMzIzNyk+PiA+PiANL0xhc3RNb2Rp ZmllZCAoRDoyMDAzMDQyNzEzMzIzNykNL01hcmtJbmZvIDw8IC9NYXJrZWQgdHJ1ZSAvTGV0 dGVyc3BhY2VGbGFncyAwID4+IA0+PiANZW5kb2JqDTEwNSAwIG9iag1bIA0xMDYgMCBSIDEw NyAwIFIgDV0NZW5kb2JqDTEwNiAwIG9iag08PCANL0kgPDwgL1RpdGxlIChTY29wZSk+PiAN L0YgMTEyIDAgUiANPj4gDWVuZG9iag0xMDcgMCBvYmoNPDwgDS9JIDw8IC9UaXRsZSAoU3Vi bWlzc2lvbnMgc2hvdWxkIG5vdCBleGNlZWQgMTYgcGFnZXM7IGZvcm1hdHRpbmcgZ3VpZGVs aW5lcyBhcmUgZGVzY3JpXA1iZWQgb24gdGhlIHdlYnBhZ2UuKT4+IA0vRiAxMTUgMCBSIA0+ PiANZW5kb2JqDTEwOCAwIG9iag08PCANL1R5cGUgL1N0cnVjdFRyZWVSb290IA0vUm9sZU1h cCAxIDAgUiANL0NsYXNzTWFwIDQgMCBSIA0vSyA4MSAwIFIgDS9QYXJlbnRUcmVlIDkxIDAg UiANL1BhcmVudFRyZWVOZXh0S2V5IDIgDT4+IA1lbmRvYmoNMTUxIDAgb2JqDTw8IC9TIDM2 IC9MIDE0NSAvQyAxNjEgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNTIgMCBSID4+ IA1zdHJlYW0NCkiJYmBgMGBg4NBgYGBgTPnIgA1wQGkBINaCYgYGcQZ+5jcMCiwSLAs4HYQa VBnnsT5jlmHjkHwg+YDxAF+DEAODYg4DQ+0HBsajDAzsFgwMMisYGOoLGBhPMzBwxScHMHwz rj/wwZjxpoMMww7xM7oVcAuTGBhPbgDSTEDsDXIYA2OuJJBOZGCImQ4WZ2tRAAgwALozHG4N ZW5kc3RyZWFtDWVuZG9iag0xNTIgMCBvYmoNMTUxIA1lbmRvYmoNMTA5IDAgb2JqDTw8IA0v VHlwZSAvUGFnZSANL1BhcmVudCAxMDIgMCBSIA0vUmVzb3VyY2VzIDw8IC9Db2xvclNwYWNl IDw8IC9DUzMgMTI0IDAgUiAvQ1M0IDEyMiAwIFIgL0NTNSAxMjMgMCBSID4+IC9FeHRHU3Rh dGUgPDwgL0dTMiAxNDcgMCBSIC9HUzMgMTQ4IDAgUiA+PiANL0ZvbnQgPDwgL1RUMyAxMjAg MCBSIC9UVDQgMTE2IDAgUiAvVFQ1IDExNyAwIFIgPj4gL1hPYmplY3QgPDwgL0ltMiAxNDkg MCBSIC9JbTMgMTUwIDAgUiA+PiANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgL0lt YWdlSSBdID4+IA0vQ29udGVudHMgWyAxMjYgMCBSIDEyOCAwIFIgMTMwIDAgUiAxMzIgMCBS IDEzNCAwIFIgMTM2IDAgUiAxMzggMCBSIDE0NiAwIFIgXSANL0IgWyAxMTIgMCBSIDExNCAw IFIgMTEzIDAgUiAxMTUgMCBSIF0gDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9w Qm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0vU3RydWN0UGFyZW50cyAwIA0vQW5u b3RzIDExMCAwIFIgDT4+IA1lbmRvYmoNMTEwIDAgb2JqDVsgDTExMSAwIFIgDV0NZW5kb2Jq DTExMSAwIG9iag08PCANL1R5cGUgL0Fubm90IA0vU3VidHlwZSAvTGluayANL1JlY3QgWyA1 MjIgMTE3LjQ3NjIgNTQ0Ljc4Njk5IDEyOS4zMDIwMiBdIA0vQm9yZGVyIFsgMCAwIDAgXSAN L0ggL0kgDS9BIDE0MiAwIFIgDS9TdHJ1Y3RQYXJlbnQgMSANPj4gDWVuZG9iag0xMTIgMCBv YmoNPDwgDS9UIDEwNiAwIFIgDS9QIDEwOSAwIFIgDS9SIFsgMzU5IDQ3NCA1OTUgNjc1IF0g DS9WIDExMyAwIFIgDS9OIDExNCAwIFIgDT4+IA1lbmRvYmoNMTEzIDAgb2JqDTw8IA0vUCAx MDkgMCBSIA0vUiBbIDM3OSAxNjIgNTk3IDQ1OSBdIA0vViAxMTQgMCBSIA0vTiAxMTIgMCBS IA0vVCAxMDYgMCBSIA0+PiANZW5kb2JqDTExNCAwIG9iag08PCANL1AgMTA5IDAgUiANL1Ig WyAxNjMgMTc1IDM3MCA0NTkgXSANL1YgMTEyIDAgUiANL04gMTEzIDAgUiANL1QgMTA2IDAg UiANPj4gDWVuZG9iag0xMTUgMCBvYmoNPDwgDS9UIDEwNyAwIFIgDS9QIDEwOSAwIFIgDS9S IFsgNDYwIDExNiA1OTEgMTc0IF0gDS9WIDExNSAwIFIgDS9OIDExNSAwIFIgDT4+IA1lbmRv YmoNMTE2IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmly c3RDaGFyIDMyIA0vTGFzdENoYXIgMTIyIA0vV2lkdGhzIFsgMjUwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAyNTAgMCAyNTAgMjc4IDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDAgDTAgMCAw IDAgMCAwIDAgNzIyIDcyMiAwIDYxMSAwIDAgMzg5IDAgMCAwIDAgMCA3NzggNjExIDAgMCA1 NTYgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDAgNDQ0IDAgNDQ0IDMzMyA1MDAg NTU2IDI3OCAwIDAgMjc4IA04MzMgNTU2IDUwMCA1NTYgMCA0NDQgMzg5IDMzMyAwIDUwMCA3 MjIgMCAwIDQ0NCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9I TkhNQ0krVGltZXNOZXdSb21hbixCb2xkIA0vRm9udERlc2NyaXB0b3IgMTE4IDAgUiANPj4g DWVuZG9iag0xMTcgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHJ1ZVR5cGUg DS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAyNTIgDS9XaWR0aHMgWyAyNTAgMCAwIDAgMCAw IDc3OCAwIDMzMyAzMzMgMCAwIDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgMCAN NTAwIDUwMCAwIDAgMCAyNzggMjc4IDAgMCAwIDQ0NCAwIDcyMiA2NjcgNjY3IDcyMiA2MTEg NTU2IDcyMiA3MjIgDTMzMyAzODkgNzIyIDYxMSA4ODkgNzIyIDcyMiA1NTYgMCA2NjcgNTU2 IDYxMSA3MjIgNzIyIDk0NCAwIDcyMiANNjExIDAgMCAwIDAgMCAwIDQ0NCA1MDAgNDQ0IDUw MCA0NDQgMzMzIDUwMCA1MDAgMjc4IDAgNTAwIDI3OCA3NzggDTUwMCA1MDAgNTAwIDUwMCAz MzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDQ0NCAwIDAgMCAwIDAgMCANMCAwIDAg NDQ0IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA0NDQgNDQ0IDAgMCAwIDAgMCAwIDAg MCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgDTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIA1dIA0vRW5jb2RpbmcgL1dp bkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9ITkhNSUUrVGltZXNOZXdSb21hbiANL0ZvbnRE ZXNjcmlwdG9yIDEyMSAwIFIgDT4+IA1lbmRvYmoNMTE4IDAgb2JqDTw8IA0vVHlwZSAvRm9u dERlc2NyaXB0b3IgDS9Bc2NlbnQgODkxIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTYg DS9GbGFncyAzNCANL0ZvbnRCQm94IFsgLTU1OCAtMzA3IDIwMzQgMTAyNiBdIA0vRm9udE5h bWUgL0hOSE1DSStUaW1lc05ld1JvbWFuLEJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYg MTYwIA0vRm9udEZpbGUyIDE0MyAwIFIgDT4+IA1lbmRvYmoNMTE5IDAgb2JqDTw8IA0vVHlw ZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgODk1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50 IC0yMDMgDS9GbGFncyAzMiANL0ZvbnRCQm94IFsgLTUxIC0yMDMgMTA3NCA4OTYgXSANL0Zv bnROYW1lIC9ITkhLSUIrQmVybGluU2Fuc0ZCLVJlZyANL0l0YWxpY0FuZ2xlIDAgDS9TdGVt ViAwIA0vRm9udEZpbGUyIDE0MSAwIFIgDT4+IA1lbmRvYmoNMTIwIDAgb2JqDTw8IA0vVHlw ZSAvRm9udCANL1N1YnR5cGUgL1RydWVUeXBlIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIg MTIxIA0vV2lkdGhzIFsgMjUwIDAgMCAwIDAgMCAwIDAgMzUxIDM1MSAwIDAgMjE1IDM4NiAy MTUgMCA1OTcgMjgwIDQ4NSAwIDUwMCAwIDAgDTAgMCA1MTMgMCAwIDAgMCAwIDAgMCAwIDYx MSAwIDAgNTM4IDAgMCAwIDAgMjY3IDAgMCAwIDcxOCAwIDAgMCANMCA0NjcgMCAwIDAgODky IDAgMCAwIDAgMCAwIDAgMCAwIDU1NCAwIDAgMCA0ODIgMCAwIDUyMCAyMjAgMCA1NDcgDTIy MCAwIDUyMyA1MTEgNTY0IDAgMzMzIDI5OSAzNDIgNTUyIDAgNzI5IDAgNDc2IF0gDS9FbmNv ZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0hOSEtJQitCZXJsaW5TYW5zRkIt UmVnIA0vRm9udERlc2NyaXB0b3IgMTE5IDAgUiANPj4gDWVuZG9iag0xMjEgMCBvYmoNPDwg DS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA4OTEgDS9DYXBIZWlnaHQgNjU2IA0v RGVzY2VudCAtMjE2IA0vRmxhZ3MgMzQgDS9Gb250QkJveCBbIC01NjggLTMwNyAyMDI4IDEw MDcgXSANL0ZvbnROYW1lIC9ITkhNSUUrVGltZXNOZXdSb21hbiANL0l0YWxpY0FuZ2xlIDAg DS9TdGVtViA5NCANL1hIZWlnaHQgMCANL0ZvbnRGaWxlMiAxNDQgMCBSIA0+PiANZW5kb2Jq DTEyMiAwIG9iag0vRGV2aWNlR3JheSANZW5kb2JqDTEyMyAwIG9iag1bIA0vSW5kZXhlZCAx MjQgMCBSIDI1NSAxNDUgMCBSIA1dDWVuZG9iag0xMjQgMCBvYmoNWyANL0lDQ0Jhc2VkIDE0 MCAwIFIgDV0NZW5kb2JqDTEyNSAwIG9iag0yMDgyIA1lbmRvYmoNMTI2IDAgb2JqDTw8IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTI1IDAgUiA+PiANc3RyZWFtDQpIiXxXXW/b SBJ816+Yx13AHs/3B7BY4OIN7m6BBIeTgTzc3oMiUTF3bVJLSvFlf/3VULYkFhXCiEODxe6e nurq7rt/iZ9+uvtw/89fhBI///zul/vF3f3SinWPv8uP6NfNQotaLO7+XT2t9vXX6r59arv6 udp39Vp09eLu70sjvvSLdw+Lu4cHK7R42C6MGz7Hf9ZEmZyI1sngxMPz4gf948Pvi/cPi/cf 4G25WzWnGPRrDCNTSiplvXhYC+2lS4Pd45OFTR9EdF6GpPRgvN9fWj8fz3zPdPluLcqTxtOL uIjcwby5jFy8P3TtrkLEn9ruj/6x3Ym2EaJ4VIOVsQHjjdQ6ZxFVksbioRj5VHfVU/nkwpOy Mgarx8CKQDi0Sd6PQX0vllXTt534WO1fSlTitx/ef1p+/O1HcT0T9lombsepUJwKHaUqLkPS MtkcB9/vqu6pbm6EzvLWaCl+XTWHVfdNGKXcd5y7q9dwzl2Q6tXp8OSTkzkXv96eLuHCshbl 50jSYESITjrhnBa3RgU8dtViC449rnbVKYRgL5l+vxwO7Ea/xfL+I8gRvXgRWokP8PE7/v0q /vNfJTZi4TO8hCSeFzrq4elpseSj+lc3F4V0PLVj8mkjczjyeniyIUgkPfh05vVyDeJ9J6lh lFR/eaPhdKOh5FebVzdChyyRMOePnCyGL14mJYMy/vS+5vcWcbp8eg9GV2Bif2Ri88rE8Ucm a5ntxUcgKvm1Wklrwjmu5ccCOB7Fno5ix0exxhcZePsGxL89hSDardjXzdiNQ5pNUvH0yTd+ n0A+dTZ5Q+9Bdh3UOT1iddi3TfvcHnqxqb7W6zHeaxSNs2d7Fb+PUht3jqcXjLBK6qzOifnz UO921Ua81PtHccqReUuRuXrZVkujXvn0MrnS8rKw7hL1qlQXsGxxFJXHsIpBGeexdgwCP9bt M3HCGqm8jWMkg5yWbijvS9ChoRMYH2S05dYuYevVnmARhY2XIxSbgo6oYCkZkHqCJZzTQpFH sFux6irBxEbaVCTkSlBshckustsdRWcdTpASwdaF6itChiidM4mQBIpGRuPptjiyCD1OMc6m zcYsnefcfiVQ8ldAFaSa9MIpDA6GXVarbv0oyLFDRpRXxBCueheugASDcKWRQSvRHIiULqZy CRTd56or17CpucCRGBfJ6nZLKExKLmdCVV3V0GV4XwqCMyM6RiWYm+SPQAGTR+Lb6Csiko+F 6Yr4yw7RFVSeFOBRn4YBKxV9un17vKJQEEL3HZrq0ttTEahLUDttXFPQ8zPEYl/T0Q1GDJ+D HmP7G85jkR8Toh3jVgyCMWR7DGq+sEThSrwmU9ye4ExmaMsYxaZiURQGiS0HjwEqpuBns2ay krg3AhHhrVJIA/t7ZMXRmJk5Vx1jkvSWMBtWQjfFvLAzC0OKLrCja7YOMsIgsW+nWom7CSaM gbvdE3dzmw28WjfLB4zIyLundO1ryrzDwBOMpuiaXgpM8D2H6EAM5V2cza6LWirNoIpBmDBz 5KzQSV0ql5mJF48EAnmmII48e5mCmQ8cU0N2ZtaOV9iBMDTMKoVHUgGkm9xXLFfGQupLcxwV I4NQ19aTw78m4xkGuBAJtRGfWZGNtCqRx28MwvAZGERtygdMoIlBnCysEWADRYXRmKNPoYxr cbYgPVg/BZ2l3Z6l3V6Vdqy4YRhMy120TDWNGJIrLLrE0YF0icHqPAZ1DEKbz+gvI1BFvdaA SDaXoecSdXiicddAqoxzZIxuzECrsDUSSNTNvproP4S2lOZM/MZ7qUycTYQJ2JNUpuh50EVr D1GTJW6CUL3snabYOVvRy6wdJYs7jZ5iuLMlcNsShphgsGFYHfhsddtMWk2U1hpiw9O00VsL RhgdxsBe7Lkv+aKcYT711hflJKfcvIKZYuprR8ACEQbdGB2BSGjBaLQ5PUtCp+AzMAgbV9PX G1Z/TDR5kJgZHjrnyxTCdUQgpAztS8+mw/l4BVRa8Gc2hwkyxUD5ED3DchELQwZ33CoMDsmg ST8Z6tvNZsJrpFYxiC0VWUxMHh7cDeo/ZD2b09JyIBR2IieinUz4GhMsVwDftgcbU1bzqll6 RUI2pndUcIOum0Hi356mCu9B5qQQ95Cd9SN1Up3KCuHdGEex6uzKZpPGoK+VoGG06PLQu8dO WZctpm1Pkf2PQRnji9djEMWOiUNmG/0YxDG5oeopJlZJl66A2BIKJhTqjkCi2m45rhhL0VNc a0alUsmO8lA1PNeiYHxGUxnBvjEoSQvOjUE3NJ6ULQDSEMhjv6s4NuuAdFhSxxfJCugxqmlF 3JmAyj5n4nz8KAaMcwQSLyeWqxPLFbHcYuPig9f7R14XLfpXCCi3OZ5bzLoqWMo1TQtOOUwL litrukEgiWSp25TSrRqeeR1yZFMI835DWXAYxP0Gg4MJgahHPCi7iE0MKj3p8Lwr/VCsms1Z YfRb6vVVfcHOgltxx4pZcS/VWDGMxacjHA9gCnMzQXgiUkhRhsSN/VXNXop/cDFjVEvZzdvD zGfLGDYCNeuKi8aAX2qov0vgSqx5JsXCZaCkY1zbV8PE2a3WQ2Lb7ZnS+UTpPKU05uk8NsXF jHfOMqiruCvbsuMpTbhVx0vlcTuj8Hmp1OEKSGy79lls6u12wutosOrwpU2W3iijd3wTe/F5 tf5j2vKTNgT90rXcqjE9K0Idmk0v6v5Ma3TVt/ynq8Qu4+I5r38e6q7aSPG3zeY4M06WEnyV XVHXyw95KcHIHhWDbgD6vwADALYaTngNZW5kc3RyZWFtDWVuZG9iag0xMjcgMCBvYmoNMTk1 OCANZW5kb2JqDTEyOCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEy NyAwIFIgPj4gDXN0cmVhbQ0KSImMl1trW0kWhd/1K+pxBpxK3S/QNEzcYToMaRqiIcyjLB9b 6siSOOfIIf3rZ5VkO6p1Sk4IOAZ/p2rvXfuy9kwbofAP/5mYZFQ6Ch+MNEo5MX+Y/UP8c/7X 7AxKWibD0GeCspXGOFNDnxjKMjuda+iPQSz6TnSPu83jentff2KjlyH/wEILN5Jm6K7fFUxJ pVQW86V48/zrV3H2bTYyBqXrbx/qC5zC35zxZMWwfthvOkJtlMY78lHcLgjzWnqX6NqRqaCk jtHSYWNPWFTSJUeH8VmIZAyBfNgShLeeQsN+Rzd6BMSZkF8332stlQ/s5HpHmLEyhUzPtxVb Cq13DtGwxI1fJ8aFIHUIlItfBjHujolzygNTUuL5t/OM0CHLclmSTil/SqXDdgmzt4vNhjLa aGl1CjX+jaEoVWSIq8ziqTND/Xq5ErfrYezXN4exuxUDZb5WMvvyXq/cb3WQEQGpoWHsHoYr riQPK3yyNdpJppIMyuaa4soNDknJkLwSN933R8gvj8BlmZyMppTl+ddLuiLDWmPI+wVDHn9z ZMdh6Mh1p4u9iQ9bjofFuOsHsd6KcdUhKZFwnL/wIFDKcE4aJ5Uh5guZ4K2V2mqiVovHrqTu TXeWvfYYuGbiWofHUeH0yIc9aheJI4/fvp/P3n+8nr39U/zyy9uP1x9+E1H8+uu7365n7+az t/O5F1rM736yQOB1Uioe75kjMvT+OiPrrMk1SKEz6CPJM7TYiN0dor0eBIr7y7DirxIMCDHU X+152PgGJNbHNnDTTyeNCwVjfvyZZPV4N/pwd98hXXquL0wbnY2r2b4beIqgc3r0O4pLv1w1 xg3qny7n+eBwmmFoEJiQD+gud3eEw8jkoq7xrjECjHOWqO0obngMWF1ewtfk8st9vztsb596 0CnE/iXEvplzKpa/xef5/iBWi/72K7dbj5BoohfTdpucDTXUd88z4oz0OC5nR8ft95v1kg9F P4IQ8jVaBsfw3cX44mKkLNJWejLoqtiz7LvF2InFRPVomVUZh1VUdv3hQXzldDIQXpFCsmIo NaAOMVlO0ynHYCl2DHmZLUO7YXizmQgTtMbkKGrfGMp4L4a4GBJK3nmKSI/WPbKUwNyEriVf 7xkqOoKhSWMvM0hrSo9xzTWAagFC4dheie3usduIn1CqpxJwRWgrlU4lvNscjuklqISNzhgC mnBuoyiUKdQzlE/VVEFi2FNEDUYW5hdxS64lKD2NJK+gNUMRMg/SuILYwaAxKhnikyBBfGkl r9qEsMaEEVQ7uOc4JOwJHtX2akQTFpHI0A13CdeAeI+wCt1AsVlFsbG+Mem0nlXg9raolals gyKz5ClF1gboJcfUYdp7ptB4oKAdVVxQ5ASbha6pJmeJW6YyipEpbgAKGq40gAp65D6nysiM r5+kPfoN59dmt39g0BXQJwr/dNubQiNUDu97qTjpKBSfP/3Br+ThacK+QK+0XXJ3gt4wli8u qwzvVqG0Mbp5sx7X3DlRUzFTXAYeET5GVIuhbsB3JiuVZW+3Py8HylBwxz5Zqqwri9LyMAyk drUo/8Sw3M50EiGW1xcaU/qNw7rVd7O7WRIfce5fogAaOfsEPP3907lgTk+CWR1NOZ560s7u pJ3PZnwxOcscjuTxl6MyEcg9jCnsNsXs69UxKjXnrLTOxJpcNzg8mnJ0Yn9B6ueW1K+FrdEX bS7jPJS1Azf8a2oJxluwibjbBhdliNgvK64VgSIua+qhQeGnQZZVnPg8BTEtoLp1De4aXMBP lEvFbdbD31diPqWhk1X2NfzfBpaLKqTLxbspqNVxhhLZNUBd1iYXa7DfrLcN1gSJBYFCfiFH tGomyevpbI8F89qpujr1rFJs/C534sUL0MSSejL8z3533y8auRCsDFm5mhbXUzBaNI1karCR CxGPERId2Lg4hdOk+BGHfVRN7m0UdY4ypUxuj2PXXYquuVTY+qWw9eXCLpumKf0Vt/y+29w3 qgyCIEZbo1htGxkcjHTZEdqqM2ytttTjObdcNR4Bwc2Y1fXdV+L3rpnrystovKvxfr1cvXkW 2OgWzzMlTWOCNga9ArvUM1Gi0vXj32+mt0FOYY2MNfzhtOuRFwopl4lsPD1SU0cdam5sRkV5 aMOKOzRSU2FRgyavz0P43nUXmgV2QJ2w7FZfXEo8e3GipJeJYi4lnk9FjZ5G1vu+MSocvtcx VmBrUkDyAamwjbhukAHRCJg95+S3BoYcCjFXWOOtINXwBPW9/XJ9Jf7XNZzRiGd0fOrY7Vtv AAOiru1sDQFsnkZjSp5zz4ukxvfPnRUuX0x0H8vE0xdnl8VPX2J2zjUSx5WdBvO/4taPjaKB UEho0xXY8K4sgUbTgX3zUeG7qblGCUK22qKXawObnUklTdzYSJMIj5MlA8WHZhHGYPUPLYTu xIvwzQ0uSls0SsU10j0XzeP9D58uh9NuUnE3rRTGEpPQiyuw0XW0womKIrNpcRmNoNREFcIL zcZdnHIvHV03OvpTswnlv1OJ/KdhcpGlCZvIOdeP4t9dK0OUTLa80xnbmFyljXgI6nNsaMrI 0qWV8RXZKEVUObpI7UtrBkM/WIex9J37vwADAM7HTnMNZW5kc3RyZWFtDWVuZG9iag0xMjkg MCBvYmoNMTc1NSANZW5kb2JqDTEzMCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAv TGVuZ3RoIDEyOSAwIFIgPj4gDXN0cmVhbQ0KSImEV19v00cQfPenuEcqheNu77+EeCAQSNtI iJoXxIsJhrqYgBxT2n76ztkh+Dbzw0KKjDzeu9udnZ2d3Vv+Mv9r1mzLxuHf7oN33pbqm0k5 2ZS9mX+a3dusV1cE6oFokgeo6bin89nTi9PZgxfm4cMHF6fnT4xP5tGjx09OZ4/nswfzeTJA v5/dd9a5lMz80vRPFZ++mfEQ6aFNStG66GV3xIu7Vwne+lbjiFsQXLI5tDLivq7vAmOwQXIb geb5XWAK+D4dPTgVG2sOI+7v1V0gUikt+BF49YGELM2mGtUVT+7iqljvYlVPeXUX2LxtMai3 kLq3bPEUFZA8pTVbYtJvZpSLNmddZcrNhqdkdfKGMVNszFnx4Zrc0fsGQFX53hKgIDvS1CX/ ZUCkJzZNnQ4Exz0K1tl+l+hBbMkOF4lik/i4+9n8G6Fmsi3JiFuSMqVkY5QyAsnLUrWyo/AQ kDBTbI69Soe4qXbPrN17j/vbbvfT3Y52xvdld8Lzz6SNi60ulRG4/kBzlVxTwOXG/LbYrE/M nDRLtFVCGH/AekWsE69w5jHXU8neqyswIO5aRd11SnmbjU7U6ROlKJPKCz3a12JXzYla9KP6 PNjRkSpvdX1cHOL+JLhsi4gfcaS0EeMn63ifCK5BoLtYHeKY8AbEi+od11Sgswsy4szvpFDF gSJ1BF6RvioV3CvqxdeXhHMQDNBZpZAoeYs2+KLeYrhAhxJG3DmjnMPYzPotnJsSsjr5PdVT b0PR9btifBdnS3DhKCM8iFjK8TsGZ3PT8aaaok7pEyh6o0+uTfaEK/iP7JX9fEEuE2pvehmR 5mKxIczLEIiigpIGyrnXKo44ZguQhqDjraF2RJxqh9QwYkmTg3jincKZ5T+MKdm6Foq65uV2 qhBtclDk20ExKU4RTE/5ptRnm9XyHREKCI9rMmIJH1MvA2o+4IjwYFxWWMMRR+qQA+IhEQOO UCVXNDWE7BiuIF6A6xpwoNR2u2QOyGFIJ5TsWFiPOsXi1Pkn5imhgRdMx9BUjp5/9zZO4hFv E2uCJZL9pvD6TSiROu9SMbIH7GZ1SVoiNSu1hRE6QTRxU0Rzt0STaaIh+0lk73lO2Xgr1kuL I3C12CwM2VaysxJhHgYwc1zwxVVU0O1mRUSyD5sWFXS9OjGvaM13ktPUbbkz96mqm1ILDxtd sL+NT9pcr6iVzjbkpI5nVhrmQioWywF4SzeI+HeFkJ9wDr4Vpc27376B0/2dck4ctGrALswf iy8rZgDQWi7mEc06Fp0l8PsD7j8iFTAAUXLRV5VAlBhDM2LRHaDMKuBF4M6IMy+5UIRa1eFs DEMokn4N0Ufvk/UYAyOQGQDM6ZRQxPGOE+3rp9o3S2fBzs8GQoOb/k0OnkD2gkWyALL47OKI I5WCi819Mg24d1/p1Em5q/oh0Lz4/GVJHADY7WpVUYlRBKGSdGk8xJHDq2Dz6zJ9iLtPcAne valXvyZkgsf36LEBRyqKqSBJwohbExzEwsfj8WA5bExJBWSKAtcRQlaZoYKGo5tONd2wIu5Y 6wgkjeY9Kh10RHNGZgQGhE1FhXzGZA+WpXTZG0J24J7m9diYhf1sOezn4RlbsqAOrdUR+JEw CduTVGyQA/B6qkdlqkcxGL73aEqTPSqgd8Zm1c/4lTVfwN9uaQ6B3Hzv9qkBx7Qv1r3NH4Bs h+z9BAUacG+Z5/O2xaICssEOzrimnkwGYMEy5Zp6MSEhBAQ0URc0r0jHY47GIkdTWGEnalYP If0EZQixd8khjviDrgxZX5B2POYbRtIIpP4W/Zm7Fh4Cr+lGipDNKeSW2Q1fUeeoskg3Uuxi EtUt3/OOD1kDfxiYeGtg8k+6GQrj4k3vnS7W5I0RwtIH6SGSXAc8LknByPNSQcKKwm3Y6tK/ 79bhELhamMWWLZtN4HqzCsunSK769I+cAi00FW9NnQYE1TcVkzFAPBLZE3oInJK7MLm6/tSY 3qgdbo9ZGfYr1HLzllQVwBoUdLnZmpdLug5VqI/vG+IhnozfirVix4ND3Ik5I6VIaG8ZgWyw oWsliwI+M+fES3TXF6So0y+mchynciy3OXaTOQ5wwRiXe2NJbD/WC2yxdcSR9goRVw5lxH0m DREjDJBXBxNCYvBUD7c64EilEi5Ykh9xWEsuPzIXiXUDkjiC2bDA375tjEHZnthQoarzyKYA Ts76ZLol9l2jqPdgS5zwX9jJjp7de7s5n0Yg84ggXulmagBSEejPFhXxh/3qWr1jnkcSJ1U7 oBtjDXvFP2UeLGLpwygegOv18gOhQQOtdsbmAMpsRbDFYdINOEOIjw0Wfd0Ogf8LMAAWuy7O DWVuZHN0cmVhbQ1lbmRvYmoNMTMxIDAgb2JqDTE3OTEgDWVuZG9iag0xMzIgMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMzEgMCBSID4+IA1zdHJlYW0NCkiJnJdt r1NFFIW/91fMR00uw7y/JMYEEAMqSqRI4rd6OWCl9prTIpFf75rTe/Hs6To0MSSXJn06L3uv vfea1Rc3X67/WFVdkzL4N33IWfvikvLF6lB8Ues/V1/sz7nitDeuSu414bBe6Ncj+1bX9vUX 96257dutpxr3eL16/OzR6v5z9dVX9589evqNclF9/fXDbx6tHq5X99frqKxav1kZbWxMan2t 7uGjMVGtPyi5iYsahM/4vvg4bbH+/fwsPunsrJUguVuwOidTJPcn4ar2zgXJbc656LEevhbc gXBZJ+Mkpl6ccylivf4eW8IVnYLr9n1HNOQRPpcvxiWXdr7uviPRkMVfWy7GpSQdJk3OuSvC FV2d69ZTRGsW+fCdDl6ec9YEBLAPNOOydqW/yEMC2gBl2i6CAwOLDqG/CgmhdVYX019mx8CA 5IXLYrAOlei6KiEFa73TLtDokIpNCxVrrG8Va05hWSrYWPDfbU/47vworupoi5Uc0aVHCGIu krsmDSB4XXE/CQ4kCKhYl0p3QvWCrYkopRqCREn8W5Hl2B1ytxvGK/XtS0VFhdM62628ICqf Wp3PwXG3XciuzbF2N1vIbmbZpZkMWRsEoS32bDMe2dbR6ZRTFaz6ZTgeBxz1Sj1+zgrQYWiU IH7z7Q8LBRhst3jjppmRTmI81yGigU4PhXlcwwU3/e4H0qqgHB9CkuD7A2v2SaPXd0vu9yRv UE61bczMyaVUFJaK00C0d5Xm7WKludagwqmWH5DkeIye3GbPHCT2ICBgplbJkf4VkjYoC8kN m4N6ReOQSyqS3e5227d0ZORcunNeqSckEdag4nzpLn84kAZiLSZR6ON0r4FThPNdhNGQlzVk m1hDnn5LxOxRpbVEyZGODvdhkwmS2xyPrKRalG2S6DCqp4TNaJK5dMsejtsjDXKpvrvRezpv i/VecmS92raOrjumogWfcfk2H+cozRim1OQrxd4HIlnrPK5TcxdQBmI4J9uFiPg+CyM5zeY5 t1S4dWlCmvpJVct1ayxm8G0/e0A0hZ46SXzOkRhM5V285Fiba7NfUtz3wo85ybHKTjCCrnmT OUiymRL+YhYJbrc9fLxSa/r0MDVKmLi8WrWbVCxOyQatwSj0PUkHrdMlIt8CXBi0DnMAA7bb novEm0UbdSeSZlsWROJKbRbwJMNnW2p8ko4FUhTosBvUrzQZpcYsWfYaQHJ9jJIbP2KU01dl RDIk+3L/N/fmKZZue5YMUyGD2t1pJM+q1t1dDt3urPE1112D70L6D89uSUFy6m5e+Et2w+El BZdST36GjgogVXIkBm0aO0mN42bcLMnMLsms+cCTzCyZcLcygzCiiyeb8jPtRZhbUXLECMOt o3sEyVHRBu0NPKgAN+NrKtoIX5C7zcnImtw6ngqCG0knbG9d2x3yAxF2xHqu25doEDpJ0XRB fLcwKjEZLgWx4jHnXXcPVnnNQvvS7/z0BSsTq3323Z3J0JkesfhacOoRf3KmVvVzkA3zVhe+ z/T4l17SsaM6Xii6W/XGCJ3Hz7dhL9YN/9VHM+fXarLbdrkP45HgQjw1g5/Gtxv+sPQ5W8mS /MLZWV8l9pHI3qCvm265zZE9Py1aBTyLIFlXh8FOTmLkHgVGoeDtIjimAXjEWku6uC8EjS4U JMe8l4na22Ivg9br0DzPpVBP4yH0QcSzdFiSSVic1vHO0rVPCyqB2E2JpyfGExIJeLVi2vyd gzvyFgpYz9QOhPv/fjPuqHEqQRcHkYsfMOeEr53tOO6crHbJ2u4IPGswIN1ZF5yTrTrgKSp3 X0hFXEzFJ3O9mAiH4oHVOLU5cpBmmgsSKUBirqcp3MI150ZqwkxpvX3ODZsDc86YUwUyl+x2 t9sSHbTnWsode6We0PdVwFlzkOzTpeim/9Fnmy0L6bNJy2xZtpit7Tl4e8r5ala1f+pwvV/h uYhKQFRtUvc8Bt04rN6I7crtdmZafvrRuVz8fw1+ckAYhiZMPzh9sgnPCViSqG+t/KtBDZNo zkgcOrlc5/D1zfuRsc5m7TAm5+zmLSVds9BokDNyUNc3+yOlY9C2GnGGcUtJjJBS0BRm5G/v +aIZzi36NEe3NzQGrhRdMeZm5IFyFS23FHF/9XqgrLeTdxPbX3MQpsxWkS0afY9O42wVd6dB 8g4mKlgR/N+2e5oocHg/eXF3RXVyUhS6XGnTZ9p8v7/5m2sqIE5J0hueJRg+1wy9XJku61pI S6qSHdSHm/Ed5YNBWptc57y62atXL37U9JauPf1C7S76YGx974bH2jYP2O3xhqOxDezuNJzE UC0h9+GmEfQej7pm+WRUeLKDDi52wR45G52uNndJPBw/PRtduutB1sfP9CC0bszI1hT/FWAA UN02eA1lbmRzdHJlYW0NZW5kb2JqDTEzMyAwIG9iag0xNzc3IA1lbmRvYmoNMTM0IDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTMzIDAgUiA+PiANc3RyZWFtDQpI iZRXXW8bRwx816/YxxRw1vv9kRgGatlA8+AgQATkWZbOzbXOnSGfGrS/vrNybWkZrqIiQKIA I4pLDofD2Zt+WP2y+GOmtVROKPx5/qSTkcHFIJxRUuucxOLb7M0DD/Uyhhxr6HbdnQkOblSU 1vlUw+9YqDYyOu9IZB6apAkUOonlphPDOImH/hv7tahlsJl8rZ94bJTRplxju7WYxne7l94s Zje389n5J3FxcX47/3AtbBaXl1fX89nVYna+WHihxeJ+psRihaiL7+KHUoYsjXCokH+J34js FBtZKmVsCf8WH7U17R/Bo2XM2e9+5C3b1wgKAFJD2Z7q6KUPikT9jWeLlS4mAl3y0CRtRh0q 6Gb9nadVScGfENZoJV0KgYTtxP24EV8+f2S/E7RM0ZBUznioA6UolB+FgFHIhlS4k7+z4KSk V54UTvJQW4aBQN8JntbZgDXaknLwUEw65pcUeXjiwBZltlmTx626/i8WbRJGXZGmdCzUWhmC Ia/b7CpcBkC/8L98atIf+qZzDs9JjcOqe+RZBa6oktYhfno6EzwJjYYyBFvDeRaaIJVNuob+ yUKtls7GVEPZ2hgbpPUoSQXdPorNct0iq06ahO6bZC3lP0SODY2PUGPnM6nD0CAgNDjreMrz cpBBW5LEMCwF+zoLoY4umRMiW+MhdjXwqWcH0doknfeEE8PZnoBpz8B0hIL422fszd1v/c3r apJZO02wU8cuM+SCnV3IeogW/TB1vKIYB14VfT3E85OP8dQ+k0SWfD/BQZUMSaMfhwZXfKm8 yjX8cTPyxIKoqEBirzpWgUxycBrJkerxWYCEVhlPHjisxYpNpFDLJk+7OAkebb3MLtkafc9D 0cQQaRNfuGX26maOyZsP2FfZ7r7MkwVuJijta2hjDxvpjSVRh+39cjU1zBha6stKOfwCTyyd pY0q1dB+4AkL5Qe/dQ3mtzBIqLElaqi447XYoWY/JDFNvAYFJY0PmTyOnV+DZgBGEhZTt/rK kxDbxida6PFh5IUIZfZJkehsIoWuOeZ0QuWssbC5FCq6odvwWXiEzsadkgUQ8Du0HK+6aX5i jK1z6BPc+m7WVkvWSRTXGG2MNbprMEo5lBDHSAXm9x9c+Y4jh8hGVBwjoaj2IbRl5HXzRGgU AW7AFyk+FtS0rgPlX/WjfGxWGi/IPpufXgephv7kOjiEzlmlLN3DcJGwjXUXpco6nAAtx4HL VtfQ7dCvlhPfbAi2J/BxELxH9K64YpIyr3Ye1sHRSoxTY9eZAiZZrFqnqQ2apDA+8FvRy5Qy yYFfoNAjlcooHUJ5vcUVkVykdGjcMlZhQJKyNZq9ZSz+QRVcDX0nbn+di7KeXxdj2C/GcITY ameQn5XnoR9Yw60TQHDcNVo8LHmRV1iPtmzSQzS/O6AhztsauWnQqmxGXYxABebdmcUtUVbS IXS8a+3QnAq3q0rwjtJA2512JAeeK2UKsDtq6HvR8HFoRsg08Jb3k8/HRA3tB57bAYafJsFr NAgLZ01qtqPUtFmy0a1VMhka/emRt3wOLjhTDrHts7AfaefyD6HTfi/uNVsf0WyTrQw25Rf/ zKuKxrud17qGs6pSBNZGE2toQ1WgsFnDxVfYJ/HEG0SD5ZExpxW659uP0wO6UiGXd3wSzkgY P1+D+Ul0EQcNCSvuebL6LJVWJOyGvyOCL9JRQ798/ngmNt16y9MK3sw7S4qxXg4r3kSBWDg8 SFd4KwdiBU2he17lPa/yEV4l/Mf+V3h2lnTEqWJKOw+gPBInWS4jdIhkh6IYgeBMrpD8Hasz NkPwrs50wsUJ+j3y41mUDba/ft1m4ncb+o+LzFfYnVLwopkAVyTz8a5nKVtGPsaoK3A/8Z3H BrQ+1jmXJ/JiBS2Jtu7J48gLkMc/8JQVdnq/J4rdE8UeIUpAfjo9X6y7yvOdzQC7QPD87GO1 GpdqZMOd+3JH6hrasucozW5WD6Difjvw3sqCiGX/1OmCXTxXPMwgVnyF5q9OHJLBYWtXUF7Y AubXAXFCIUIhlEqnVBddi0j2lKjwoqns6wra8U4gGRAlk1aIhhmNJdt8Sgowo8iWpMD6N5OD xH1CGNaJhxF+n5dgsIfkwPfX2p0ro2BefbFpbXanUNJ6W6aVcvJ1AON+AOORASzkg3A+cw76 9MTqSNnrIapY44fV14ZXw7KOAcdTDW/tapMotP+Hn6tdkwiW749xDmaqrNUqLgS+oG8Ws5vb +ez8k7i4OL+df7gWQF5eXl3PZ1eL2fli4YUWi/uZKkVUR8qHhuWc3L72TGTHRv4fPYKJtDDg ux95y29TmKOYYw0Vn8ftZtWJ1bjuG7IGocoZ6l1/b2r4HyypUtA99l8BBgDVYTE4DWVuZHN0 cmVhbQ1lbmRvYmoNMTM1IDAgb2JqDTE5ODIgDWVuZG9iag0xMzYgMCBvYmoNPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMzUgMCBSID4+IA1zdHJlYW0NCkiJnJfJbhtHEIbv fIo+JoHU6n2xDR9sGYGD2IlBAT6PqJHMQJqhucTx2+fvoUhOFZt0EOggQvrYXVX91zb5afal +/nmr4nWUjmh8LP9ZIKXXukojFXS5uTFzdPkp3kdTTIYy9Cvm7YKJ4dzjaPwSlTZrKXz3lK2 WSyW/aLGW2OkSoGdvawabU2SMVnDzl5XWRtkVNyOVtz3Vdpb6ZLiVgweKqmU1uJmJi53H78J foAOWcIuHWXMKQzf/jz9eCFa+VCNkjbS4hbyBXkh1r1YVXl4Y4JmN2wWi35Zf10tc8qJ4mtx V4WjlXA7Uripo0lqbyw7t6krIZXXiprC95tV/W2Vl1YHRvfdy+rZRTVaaWbI3bwaPGudzNqy o0+oJkllPYtzNcbWaRmsZybUfXNORh8dRW83dSV6GVJmFqzbu4MWw0GL4YwWEVAVk9nm6rwq Q52gk5wihau1RacovU6Jos2jqGa1URZeOHZwXasqSqecpmg/q6cNYuIsY9vViZzRUkdrKVyv hlCIyd6xONRT13mki2GBGF7n3c3k3Ye3k6s/xatXVx/evr8WzovXr99cv528uZlc3dx4geJx P1HlAdXpp9PZSIdCd/bkUD25iMIe9GHPXBIzRJmGOy6rLx6NDFAgIavZqCP6TlCakNfz1br6 4DpHtB5NLag/i1LluSlZTxuDXyFGipasqevIGgnYErrvqiXBuCCTM4Gwy/6xyvosVcj0XNF0 dycKpEKrRA8e003d4KygZRrg9aZaoy1Sz2dKzvvulIzi/xJoiOgDSR8JFBbiR6xm3cTGBPln YYwXlyZHsWwn9xM3mIZmK7Rz4jKr7Z9HFmEU2FqkhmuHs440jlN2GjdDDcwDnJEWYbAPanCD ddPN7VMxcA+gjpkyF4yYbdvYE7n0wzwG2P8xWUDy5AQK5HKAGwN9R87wiGYyjlgqGIF6m4rs DsQXApTByRjiSL95JIiFFEzJ4AOyleKecEqaUlBHRNevCeI1hKSIIaKlREQXoZb8Q4CAemaJ szP6/4Chi4ac3hAxlXmXzgAO04OnnlIgyRQDcRSf903V+r2glKkICkGwKFzD9xYNeW1cjZRn zANFstSlZRCkpbK0UmUUdYKsXop7qiy4aUqhHVM9ReBoUpYiSxILZYqb7K4niqRS9NgpDRWo kan0bYKs1/Pugco0Sxu9p5igDKZbOM/is+FCDZAiReZ3LZdqSNh/CPQ47yiFLck4lVmoKYLR VZcMJkY3XHI5qHQu0DEWxJ15d18mMGOYevay/FGdQ1Ryzs96b7kso/YUoXWsDPPZMmRGVYkx 23tHkSVFfEE0RWg9RMlFb6bELbUWNRVTD3NI9FSTGBSDY+d0XJPKMI8ELWe67IWB2csqq8ay FZjX9NkMNGQSM1h849U3hRDOHWMj2kBiN93SAuO9kinzc2gCYWnAwmvPXYXRBF2YIVLcUN0D SuZscNC8URnOBgeyR2VgV+01jXwo00WRdK5I2ioJW7ffWVC9YhoMpbKNESpGGBd9zhTpuepR QtlFs7a9o3p0aBeZUXMqNoXUxYBPEPosCn2tbEEEoZVGZYjEsouYkHSSvszy1JjHR3FLxYSC XFrgmGJywyhbagy9jETZO8wMNmvKsFqcUK4zs4fa4k05hRKP8xWVEgpx0P6cwdCjj4H5xBq7 Q2/lLlEiFOWfsxaDePKROfSdIihzw35xdE+pzhrrzFbUGoo4FrVRZSLczstTKkfUGpsYwnTv JdYwT5ElFzUQdgorwugvDOgo4J8HhzFC5xhsIfyMlqeNSTqdMxXbHxDmjeCpFTC4msigNZWP RlyCTWfs8RpLkHH8nPEqNF003WH38KPdQ1d2j+Gt0fN369FoGKd3/P7xqBXEUpfGzFuK5BL+ mlZ2pr7vyigz/dIs2oPF4dniwQJdyjc2LowUZWjARDVsV2znC/E/bFjG76p0cXfkqcPYo3eu OKVruws6VohYDwnD2hGmZsuPWc5Z+iO3nU8UYpMaZgvjLEWkED8MXHoOwteJC7YErKy2pdLg ziAuMfkM0fv8i+gmV79OrXhYia8TJLr0Ybgc5dZEjE/DpGVESR+F55g94cInI677yafh+k9i gkjs5KQjPqJNOWGiEpdZbZ+o/Dnt/rr943T8Zv7km7mDMkuPeH608ukbgjLQ+KVRIXyZ+JN0 6jlK74eRf8Rg8VW+jE9jasEhpFQcVpAR1FPIKF+BlgzSGiXVMKPWHPJldWJQ0zHKYOKwJc/J UeK6WbcrhobS3xJz8gWHoCrNIcGghCIVfwBZJOMJaKfO0SPvNEmzcV9tjp8TyZi2rWi6uX2a r1bzvhN3bXNXBM+dQgeAVt34WzWX9FlkcIgjWv7GKFQzW+w8QJtHhrjSs+hB3xmCIuEsRS44 Eo8QyA9t7ESIcy3EQ/KouK94sR5tq6XalZiP/Xp+P5816xLx/l40s2Odaf6lWbtYH2kXPdNv Z6UxyaEssy8D/hhqX4jK6wTEg3J4nylubp9u2+XFuegEdTI6el9Z6rHRsZRfs21szVO7bC55 JpcGFx1FeU0wZbsok9gYgp4ZhsUi6jKkjrHvHArQe6aM+JtB2Jx8Toxq+VtiPkzFWWJ6Sbaj HMN2oSwzrPZI5gjS8o/Zuj/xRP8KMACv1zL1DWVuZHN0cmVhbQ1lbmRvYmoNMTM3IDAgb2Jq DTE3NzkgDWVuZG9iag0xMzggMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0 aCAxMzcgMCBSID4+IA1zdHJlYW0NCkiJnJdNTxtJEIbv/hV93JVM098fEeIARKsciCLFEpe9 DPaQzAY8aGyHzf76fXsSlulKDbFWOWApj8vVVW99ibOz0+vLd1ciaHF+fnF1ubhYLU5XKy+0 WN0tTpRUSlmxWovnT09CG6HwD390TNIHoZWVKpX/fFj8dvP76q/FBElZ5mBsDfUEyp6Bhi8n 3fbkceg/De1uJ3aH24dut+v67RuhvRTv+6/tw207LIVRqrbnNH5UZ1fbs6JQb1eLt9eXi9MP 4vnpLnFPL+/Vobz85Pkjnq6lct9/Zfxkk5f4Oeelc+NvnIyO/EQlGWJOU1D8aYy97jab+/ap 4b7knJba1V8aeNDJFHLlRgvrTrC0j9K6WJm963nDUUkdc6jcvvn4filaDvcqwg/jp7hkQa1k MKay+4kHg1QI0xEWk4ypBt+Iy3571/GGPdIWQsUfBjYNPmRpcq7QfdezaFIyxfpdWzYJP2Rj jUxO6RFsthvRbdk0aANr2tb8bs+zWUbvCdvcs6yJUGUINXvf8IYtJJwcgbs54SYVUo32fCQc MuGNJvDu8PjIhtgl2HbU9rBfsnDWyHIkwRD3fPKUkV5b6vUXXm5WOq91zR4eRX8nmq/sN1yW PlNXmo5NjA+oD+UdgXm0hC/W5C1vNTqpQvA1276mT4P61+hAY484bNdskJWTMZYETmlUCK9l g/wlm2ua738mFBmFGp1RcgaafY3y4sTjszXUXR7FULI+HmU1S+UTeRbbJZ2z6JKlmqfojkeT 1EmRRCwF29Kcz2AS8Zbv6wECsJnY7aHfdf/A1wb+RE2eN4Nm6aIjqThsu3Uz1zXRLBXht8tR luPctS8j2L4ygjF8/PPXNx0bT5uTxBwnMJ97vBjNwNYoH81SADa5GuVlMk7I8tgpenvgXUCp ZKtyDbcbwVcLFJidIab5aoECVSitfIryooICXXAkYnxn9lbmRNGBj0NpcOPkqRLxmVWUixhT uZThFOYLJhkk2JJUYKyKG16rAVo1BP/Id3xMh6xSjWITwoLK8hiXRkXCsy3RIx3RULTdP/UD P3zQx60l4Xili9sMfWY0x8JhmV7zbQl1G2KMNc5HGdMvZwySY1B0sIzTokJ5TUDuVmPPqtAt L0s0cYO41awoKxTvBnbe7FOoeb7qAv4kjLMKnd+PjY7EjYZ3Gbuht45Eoi0bw4bXJgZ79pnY nlunsQDT1zVL8ZnFMSxRrPoYyxZSi54EY+Abv0MxBeJvv+3+mVtbnLHuCF34gBPThXCMLnzE 05Im7MsoOe6as+giGgL//kP9pmUr3OmSfJwcFb5ut3teK0WyseRzindriHaum9qyJVT4Rmz4 5h8xKnIkxvcN73jC8prckX6POnQx/Ow3L1ssbcEa4slm4A9GhzEQiGm2gD1O3JzQ9I5BsQcl mhdeWt5IqxwJxYy0gpXGaeLBUoziertavL2+XJx+EGdnp9eX765weojz84ury8XFanG6WnmB bftuoYr+1CvKC+VKyPFFtj9b9oq1fPymZD326ohGW36EVYhNuPUiJkuF8iMGJxbOFV2jfzT7 9qn5xteBkjFoYpvv2ti/VUQR127se3HHlwy2Wh1djfOzxpfNPhP0b34whlAKt0Y34h1fh1gw cXXWMF/gqEJf2uWU3LfDlq+UcRo4EjV2gHmVZNTU8jgb+RaPtVtpIouO31Sw1PhUxm7tNF8w XpeSJTHmewzSEZUlLjf881CHwZQ6rPztt4I/LlLJNPWC1Q/ONxm8iYzqS0kZ8191lY+z1YVO ZSKkVb588/H93K4VTbA1LPigl7soF6aCUQS8AlEzCSOzpnnDDgtXDJEYnpOgQ+CdM+SFMztU gLYdfd/sdh+NJ17wVYsVKqHEanSzuW+f+EKAZU+9aIaWP6C8SbjNEnkfr1fMcp/KwjVF1/y2 5YzMmnrR8drG6FKKprpd8zWDMreB+LA/8A7HoiFHDfMoBJSJ2d3cmPP6f405i6Hh0SZfG3Nm bsyZly3OvLbF4fTA/mx+OeZijQr2/rMZx1ZZhKdouz4M3Z4fc1CTCWVsTL+wFK3krwMsz9k6 Yl/yKNpUdsTrN+KRXzsDFuGxvU/pbqYUMemUsoTdd19ZOqMasyWW2x0/nL1CS1CBPJBv2dpI ZJY8cBDN4+P8jUK9nqlbjOdR3JUTvNlSi7as1JXZju8dAYus0+R1s/MrBkvstmMVFE1rNcr7 +dOsuhFP63/MKLZBWORHm3ILTVE2LjZbNFZi9BsbFqegp4DttmL5KYD+iyZJUDblTmO2KIp+ 4hVt0HxN2bGmLH8WmYhLV8Ua5d+Flp6jItH6zM8hDE6XfTgiCaWucTSQ0M7VKlq6yaX9/zpg UFHSFJ0dxtnpCv1XgAEAquwqGQ1lbmRzdHJlYW0NZW5kb2JqDTEzOSAwIG9iag0xODM2IA1l bmRvYmoNMTQwIDAgb2JqDTw8IC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9MZW5ndGgg MjU3NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZyWeVRTdxbHf2/JnpCV sMNjDVuAsAaQNWxhkR0EUQhJCAESQkjYBUFEBRRFRISqlTLWbXRGT0WdLq5jrQ7WferSA/Uw 6ug4tBbXjp0XOEedTmem0+8f7/c593fv793fvfed8wCgJ6WqtdUwCwCN1qDPSozFFhUUYqQJ AAMKIAIRADJ5rS4tOyEH4JLGS7Ba3An8i55eB5BpvSJMysAw8P+JLdfpDQBAGTgHKJS1cpw7 ca6qN+hM9hmceaWVJoZRE+vxBHG2NLFqnr3nfOY52sQKjVaBsylnnUKjMPFpnFfXGZU4I6k4 d9WplfU4X8XZpcqoUeP83BSrUcpqAUDpJrtBKS/H2Q9nuj4nS4LzAgDIdNU7XPoOG5QNBtOl JNW6Rr1aVW7A3OUemCg0VIwlKeurlAaDMEMmr5TpFZikWqOTaRsBmL/znDim2mJ4kYNFocHB Qn8f0TuF+q+bv1Cm3s7Tk8y5nkH8C29tP+dXPQqAeBavzfq3ttItAIyvBMDy5luby/sAMPG+ Hb74zn34pnkpNxh0Yb6+9fX1Pmql3MdU0Df6nw6/QO+8z8d03JvyYHHKMpmxyoCZ6iavrqo2 6rFanUyuxIQ/HeJfHfjzeXhnKcuUeqUWj8jDp0ytVeHt1irUBnW1FlNr/1MTf2XYTzQ/17i4 Y68Br9gHsC7yAPK3CwDl0gBStA3fgd70LZWSBzLwNd/h3vzczwn691PhPtOjVq2ai5Nk5WBy o75ufs/0WQICoAIm4AErYA+cgTsQAn8QAsJBNIgHySAd5IACsBTIQTnQAD2oBy2gHXSBHrAe bALDYDsYA7vBfnAQjIOPwQnwR3AefAmugVtgEkyDh2AGPAWvIAgiQQyIC1lBDpAr5AX5Q2Io EoqHUqEsqAAqgVSQFjJCLdAKqAfqh4ahHdBu6PfQUegEdA66BH0FTUEPoO+glzAC02EebAe7 wb6wGI6BU+AceAmsgmvgJrgTXgcPwaPwPvgwfAI+D1+DJ+GH8CwCEBrCRxwRISJGJEg6UoiU IXqkFelGBpFRZD9yDDmLXEEmkUfIC5SIclEMFaLhaBKai8rRGrQV7UWH0V3oYfQ0egWdQmfQ 1wQGwZbgRQgjSAmLCCpCPaGLMEjYSfiIcIZwjTBNeEokEvlEATGEmEQsIFYQm4m9xK3EA8Tj xEvEu8RZEolkRfIiRZDSSTKSgdRF2kLaR/qMdJk0TXpOppEdyP7kBHIhWUvuIA+S95A/JV8m 3yO/orAorpQwSjpFQWmk9FHGKMcoFynTlFdUNlVAjaDmUCuo7dQh6n7qGept6hMajeZEC6Vl 0tS05bQh2u9on9OmaC/oHLonXUIvohvp6+gf0o/Tv6I/YTAYboxoRiHDwFjH2M04xfia8dyM a+ZjJjVTmLWZjZgdNrts9phJYboyY5hLmU3MQeYh5kXmIxaF5caSsGSsVtYI6yjrBmuWzWWL 2OlsDbuXvYd9jn2fQ+K4ceI5Ck4n5wPOKc5dLsJ15kq4cu4K7hj3DHeaR+QJeFJeBa+H91ve BG/GnGMeaJ5n3mA+Yv6J+SQf4bvxpfwqfh//IP86/6WFnUWMhdJijcV+i8sWzyxtLKMtlZbd lgcsr1m+tMKs4q0qrTZYjVvdsUatPa0zreutt1mfsX5kw7MJt5HbdNsctLlpC9t62mbZNtt+ YHvBdtbO3i7RTme3xe6U3SN7vn20fYX9gP2n9g8cuA6RDmqHAYfPHP6KmWMxWBU2hJ3GZhxt HZMcjY47HCccXzkJnHKdOpwOON1xpjqLncucB5xPOs+4OLikubS47HW56UpxFbuWu252Pev6 zE3glu+2ym3c7b7AUiAVNAn2Cm67M9yj3GvcR92vehA9xB6VHls9vvSEPYM8yz1HPC96wV7B XmqvrV6XvAneod5a71HvG0K6MEZYJ9wrnPLh+6T6dPiM+zz2dfEt9N3ge9b3tV+QX5XfmN8t EUeULOoQHRN95+/pL/cf8b8awAhICGgLOBLwbaBXoDJwW+Cfg7hBaUGrgk4G/SM4JFgfvD/4 QYhLSEnIeyE3xDxxhrhX/HkoITQ2tC3049AXYcFhhrCDYX8PF4ZXhu8Jv79AsEC5YGzB3Qin CFnEjojJSCyyJPL9yMkoxyhZ1GjUN9HO0YrondH3YjxiKmL2xTyO9YvVx34U+0wSJlkmOR6H xCXGdcdNxHPic+OH479OcEpQJexNmEkMSmxOPJ5ESEpJ2pB0Q2onlUt3S2eSQ5KXJZ9Ooadk pwynfJPqmapPPZYGpyWnbUy7vdB1oXbheDpIl6ZvTL+TIcioyfhDJjEzI3Mk8y9ZoqyWrLPZ 3Ozi7D3ZT3Nic/pybuW65xpzT+Yx84ryduc9y4/L78+fXOS7aNmi8wXWBeqCI4WkwrzCnYWz i+MXb1o8XRRU1FV0fYlgScOSc0utl1Yt/aSYWSwrPlRCKMkv2VPygyxdNiqbLZWWvlc6I5fI N8sfKqIVA4oHyghlv/JeWURZf9l9VYRqo+pBeVT5YPkjtUQ9rP62Iqlie8WzyvTKDyt/rMqv OqAha0o0R7UcbaX2dLV9dUP1JZ2Xrks3WRNWs6lmRp+i31kL1S6pPWLg4T9TF4zuxpXGqbrI upG65/V59Yca2A3ahguNno1rGu81JTT9phltljefbHFsaW+ZWhazbEcr1FraerLNua2zbXp5 4vJd7dT2yvY/dfh19Hd8vyJ/xbFOu87lnXdXJq7c22XWpe+6sSp81fbV6Gr16ok1AWu2rHnd rej+osevZ7Dnh1557xdrRWuH1v64rmzdRF9w37b1xPXa9dc3RG3Y1c/ub+q/uzFt4+EBbKB7 4PtNxZvODQYObt9M3WzcPDmU+k8ApAFb/pi4mSSZkJn8mmia1ZtCm6+cHJyJnPedZJ3SnkCe rp8dn4uf+qBpoNihR6G2oiailqMGo3aj5qRWpMelOKWpphqmi6b9p26n4KhSqMSpN6mpqhyq j6sCq3Wr6axcrNCtRK24ri2uoa8Wr4uwALB1sOqxYLHWskuywrM4s660JbSctRO1irYBtnm2 8Ldot+C4WbjRuUq5wro7urW7LrunvCG8m70VvY++Cr6Evv+/er/1wHDA7MFnwePCX8Lbw1jD 1MRRxM7FS8XIxkbGw8dBx7/IPci8yTrJuco4yrfLNsu2zDXMtc01zbXONs62zzfPuNA50LrR PNG+0j/SwdNE08bUSdTL1U7V0dZV1tjXXNfg2GTY6Nls2fHadtr724DcBdyK3RDdlt4c3qLf Kd+v4DbgveFE4cziU+Lb42Pj6+Rz5PzlhOYN5pbnH+ep6DLovOlG6dDqW+rl63Dr++yG7RHt nO4o7rTvQO/M8Fjw5fFy8f/yjPMZ86f0NPTC9VD13vZt9vv3ivgZ+Kj5OPnH+lf65/t3/Af8 mP0p/br+S/7c/23//wIMAPeE8/sKZW5kc3RyZWFtDWVuZG9iag0xNDEgMCBvYmoNPDwgL0Zp bHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxMjY0MyAvTGVuZ3RoMSAxODY4OCA+PiANc3Ry ZWFtDQpIidxWC1QTVxq+eQJJeTUBu13UC4gKhDABgwJiDSFAXF4mIVLbuk7CQEbzIjOAFBWI iqDVUov4pCJWQcX10fjYntala48PqhRfFVlbXalbrY/aFp+g7h1YRW3dPWfP2T17dubMmfz/ /f7/fvd/5B/AAgB4gXLAAdOTtOoUaeACM9JcA0A8IlMbGWXev6AXAD8fpNMbLbhdv692LwCq VABYp4xFNMzyj8fRugnJ1jx7vuXE3I1bAPDvBIBXmG8uyYu8uO0RACO+BWDoIhOB5x7ZvjMA gNTDyF+MCSm8p7ktAyAgC8kjTBZ61sZX0ruQTCP7FrPNiB+9dVoDQKIdAHanBZ9l59D8/ci+ GeGhFbcQtxS3PwcgZTzan7TbKBqdA10pAcy63UHYmyVNVQAEQWT/Z6Rj9d/MG4i90VsM+i+x G+YUc/geYZWplXc8WW7sBqeoB3OKbrJZLJkX9hLffWCFzeMBbDpfEM5ncVnOsWwWt0GDZWGS pzQBjcPKA8D4/jsTGAAFbMAMCECjZwJzY/BZf1yfHdhO+VDXFNXIRY2fFKSujG5wer+GOdmt 6Alli0XVruOLLjd9/qn80JolVW3D27T69zDPJ1xZXESp4gPZcGwon5PNFYj89YSD1JL5Vqhz FFI0zCDoYptjpmwI5scAhCKvxwAJVFuNUpkECxtYCB60JC0E1NK4xU5a86GWcBSRRgJqbDZa NgaLGkCHZ2TCNLUiUZ2m1r0OFUqlKkunSpLA0cbQ2LHw2T2wYUM8Y8diclkUNhZD11Qkxsqi omX/EP/3D1Cx7umYs3iAU7EExb2aXVEBTkrhTdNsSYS0ImAnf1eTcK+v55QubWdh95HosF2n bnu8MebnKzUPPV7q+Mtvp/7x2He3q3bWty4MuTonx4eaMeuLAr8HB3Nuh27NmVbHfRBh8M2p CGgrqD0dlBN5+qiYNz/m49otrvRJV27EB23Tr5obuNZc2TopZcUM16aY030eESddsWvYHFTU z5UEB/GK8127gDfhxJXy3tLTm3taSvp4fcsTCoI3h48+/46IqH4oWch6d+pqQ5tvU3nP3v3i vcf1q2a6G1QHGzd2yct4Qd84IriVvKbZHv7vi5U37/inf+W2dI2POeehQL6irXrdea59bdgc fOlnl4UFq5sP5RkSE5bXBkWtDKpedD/XfcStE/dR/R5DTwzbD3zqu7pLeT2wNzlnfnVbclVN yA3x9P+/Im6RjcJCBhwP++c0Hp9U+MKT/lsUH8dH8Iv4+GLezIKbyF1tpQmHlaCxivpflPRi lIWFTElvxa+7ti2pSak55/KdRp4TlBlq+LJj7Y+q3ks+o46rvXKK/1r9tsZZU6/d6zOqMvcJ rdgPjTFbIzzO/2gbtdVz8nSePLOsXZfZsVeS2CnsWLJv2qM95R3dda6yIHWij/nkyh0s/YYD X0rXxfWUNedsOhNEXHpn66y1n5xNSTS9ETHnwW42i/MrBW2Z3rvq9x+SH50stYcbgoclwcnb g/0O0ex76p9GvfpmS2WB3D389rvfXNhdd3lx0++6qcOpHvU7uhZ3+S1r41zyCNHzv8v4MGXj 8SnJp8bpbwUeOzAyPiIkqn3NxT9NTPm+05JSdKkV2+Bd3l7WGT+34d7yMFm43/3D4utf77iS rbAnR0jmYk6PTejxbuCwWWy2T0lenXXejo49rJet9a0uouBpxmxU0PivRP3FGYrGZAMJD3tS EUqbxUI4jCRuhlpbHl2MOwiYVWgwk5SJcFBQqegvyXHYGFkMhj0pSUaMipbHymOnYk7WW/9x ErJkLGnAKKG4uFhahAwpZCg12iyRaALbKJK2OUoilVlaZg+bwy6FhhKoIfKkEqaupWm6JKaW Y2QTsPEDfuRJZD5Jow3VSVBpxikKRsMImE4aHTYKURjkocfNZC5OkzYrLIqSCTEPxp4vYmdr ZSLMlxHcRYIpOGVCrUfbrDIfzGsgFG4aItdis+bKhmEBjIYj9ht0r0QcbY5+t4/XhS9YRwGG z3eRk+UJkN6d7WSxgKvmxMjm3L9d9TvwyFKqyBTcs4UVtEtf0W6KirlwyvRX+QP1y511fcSX WjHczz3y9q0jdkvttaMfbQ/DVkflzN6zeWZI/qrWi8Xf8y790F13Z5vwN5v+MH6+/eJd25uZ c2zeGtUivzPEuXjI605Yb14R5yUMEV0P/AIujX3bMI93JPjVPk19S31a3ZnxGTkJztIbHnL9 blNroqoxXraht3N5b/YhSfOGA6GZ7T3v3+QML/3RL27z3S1Z83gWw83FoqpxZ7sDvKjP+BM/ Hn3g6rFlBYf25+1arwv6Spg/++7CkuqWPMGWyfcfOAL7Kt862DPJ61oOHpzesTMu94Log2mH F1jS/LcnuKFG3uDkfY05eWf7szNUxGVjABMyP725XA6b14BVVDESi1tRjs0t9ymt+/a48oFp 5c/jjlrjfxI61xv/C43k5LFd6KsQC2SYcFmsR9whmBhjvvwGv+z8OWy3coCyjSACLh9D5PkT MSc35imMgDF1coORenhDaPkoE03bqbjIyH/RGOudnH0VTo5LZyIpaCQcNJlHGnGagGR/wzDF RlBM1ziIPMJBWI2EBOLWXEjSFCykEIyCFO0gjbS5REAVGmYQRhrSNgmkTQQcDMITv0y/ZDlw I80MRDSaaMJCWGk4GjEJFSCaFAOQSTG0SRFOmnGDmWHyrLfBA0CcjhO86KDxDGtVhAW5QTiI dohwEAWFBEVTE5/F2RwCBH0MfDanEhglj41GacTRhFQUEUiRbiu00jhipSeJYglKIYwdg42J FmRrFQhnL3GQ+SaaGZKy2NiY59xBqDCboYZBUOiPiEIzmciVQqVKo1OoMwRTFBqNIkOnVmlh klqrTFOo01VJUJGR9NQcTlOnq9EYlgoYdIY6IyUO6lJVMFurgpnJ6Kda2+9OnaxWKnQqiESt TqNW6tJeh9rsxEkqpQ7qMhkTgV71d+arPaipK41/Nw+IQStSUCq2nHgNQnkFRGAFNCG5IakB AgFNWLVJIDwsEsprRHYtsC7VKJXu2HF1rcK6Ptpx2otOW6DqVjuutuu262tQlhndLWqnPra6 ahWs7HdvEl62nf61szf3Jud7nt/3OOee5Orxj1fWGH19dhYx5qrUeXo1g3boIJPJykPY3BR6 kykf5yOq/Dxddi5ikXpBmrwREH2m0aD3YGbMxlzGZCKjUWESstSGfA3nZZQrRdyZTK5ah6Q3 yuxcotXnZXHmWhyriFGFGNX5BlUuMebnGrNNTBQ/yVK9wUCysvOk6QyfJAPDG6izs0xMTj6C 16sMUWiSpc/TL/HYeMFmY1S5RKPKVGUwphhiYhgpFyf3vuB8aBjUMpgw02onrv0KLJmzeGIv lpRV47bgKCIVzgqurYrLHEUm90JQ1eDKsNfiApI6VqM939x1tvJaB6kutWEfVDhriN1BCp0o KuKd2KqJrbCwtsq9AoudVav4NSOtc79uUAM7lUOgV8VIdyc2JvycZe7llztLnDElZcWKpve5 nYSImvYpGhWNPn7WFh3V8pChfCkKGeE+EtxVxGLcQafP+lH/mCSFfURToFiiCJo+YT9U4GGF mpnmZc6t5jNbNvomHtlTSHmZzR5DymtwLYw/XQJ/KaaP2elCRBKFD+52eE8493AntbcMf6zP 76tZtlF+fC/5trzrUIO2YeeuNT2v+uiCAhynl0c8zEnZ8GrnvcDk1X2b3/NrTGxbrtt6ApKl pj8rk4Zdz85dBRkJ3+kMMVV3/3Ju7fca5+zNZ36366stt64Pw2fHb1fNurRDWPHhscKG+NWa lJ2/dQ2ta0kKj7m+NzlpYc/j/zTTcc2iBNyDFRi6ovZ/8P74gcPgZB+JOykCsRjam44qnhvJ 0iRh3NgXiwjPGKOUX9yE144idNRQFBcg8rdRKezmGFlbYm8Ze+qK5TB2wKj65Lg8RW57eGMY pIMDqqAcyqACCJjAhr/VONKihPt2Il3TEdY4h+suT3Ot8h5y+O6qqa90llTZKkvrJx5yRM0U RH1+0BW6ubPoZELQpT/FCZX5c8qvpS1aeEx/eeAdeDP99KG0y3cPJ+8IevFfj+DMe/lrOhQn Kr9eSWzzSqbNKLgw9WPFZ62uj/bvX6LIXBYQ3trw6esByl1Du+3bFLfXryjtnp8AO8LvbFsr nLElnqn/5lFs/MnHQ93HivvFQSt3dw+uq73V42i4cnb/FtGswm69KD2SCZm/StLe0zbnzr6g ioyi1H79vx9vTWw5MNjb3GdsqHxZZH/Db0CVMtT6Wm+Vcfma7SmGpLOtlpVTzuvWVHyfd23T 82dLsmYllB17uy/0gO/SPdtS/zrp4oMsQ/XXvVGvfNVS/u71+1M+WG2k+ztfmxP3Rpi9/1FH M/V3POedHq2OT1wzdQRZ3VzbNXX93/+jFQTBkWnb+9S3ZENa87oNn2vXt8lvB1ontK5FETy2 c/1GCF8KG3dEIo6byv8ZSYpLiFckJMbHFTzVuEvPz/7NF//Ypt1v/27R+Y6jdyc2VVNjUVrA jmfZ9lPJe8T6oNILd7L6Qi8eKLkU/eCIqnWP6s7Si5Z99fJeS3VbR3DgR0lVBS1vXkmT/zJj T+uNF4ypv6/cWFy5oatjbcbl/rDGFwJW7PzyjjOx9kZEgGT9QMoXb/UeLj1w5hnx29HnJpuo iLrBmd8ejxaevdfkXx838FARshO+OYdnQGE21QZikIi3i+chKXf/CtuhWBAgEQie8REIxAKB 0Ac3RCGMubTpegJKIEMC38gnVjjqS1PtBB24peIGWIjPXFEnzBT2gBxg+Kr3eXJy+J74Q4An LIBg0fBdcT3MpFzDN0VHYCo8dQnvgexp7s+4jsJtOIvPJbgLT+ACnIKb8CXcgmsQBD4QAP9E nXMwgPxP8eE+12Am8p6npsMDaICr0IXag3ACPd2Ew7AVCmAGRCKaQfgD8vbCa6i9F3bAaihC nwBSSgY3oBeuUvHwLmyCfThrH/Ucej4D/fABnBE0CUVwhAoQ9FAvCd6BgyItvAJ1sFfwK6oM 8VSj30F4kUcvBRoxLIM0+DU+TogWVEArvEwFU7upC9TH1HGBmXqfWgFmqgZ9g3JBjjE7K9Ow +CW9LkPLaNTpKuWihWmpKQt+kZyUOD82JjoqPEw+h54dGhw4zX/qFD/pJImvjxjP9LixMbTW StgwKysKo3W6aI6mbciwjWFYWYIs7Xgdllh5NTJeU4maxRM0lW5N5Ygm5U9SITU6ijA0Yf+m oUkXVZBjxnGrhrYQ9hY/zuTHojCemIKETIYWhAku1RCWshKG1daVuhirBv11+knVtNohjY6C TqkfDv1wxIbTlZ1U+EKKHwjCmQWdApBM4aZlhXLGVsQac8yMJkQms/A8UPO+WB8168v7ImUc ZthIOqM+cW3q8ge7NXJyEV1kW2ZmhTY0cgkZl+t1dlokG0Fr2Ig1A8EYsoONojUMG0mjs8W5 IxNQrFjuTxPXfUDw9K2b4zk2D8dH7n8fuCEX4kiaUO4dA2JDhBifTMZh2dilBDsSbGOO2U0T sIccBGVspIUVWDnJJ15JUD4nafRKRsyttIwrFWP13HWlwWyjnURHYfb5W443ygkrDLPaC0u5 X5vDRWs07rzlmVklHr4xWZ5YmU5FLOrbrBhEGZeGHDMbS1eygXS6WwEZhKtBmcnMm3jM2EA1 C9ZCjxUby2g4XIRxWTVugJwvOsfcDfOGr3QmkJBD8yABLBwOdroaixLGuMxFxWyoNaQI+7OY mENkrNKC6bPQZoeFqxLtz0Zcwelk/Iy8FcY2QdurzEXuK5cQsyBEaOGqhQyixS86PRUF/lgu nuQqmp5KzFQIeNVwFo8GNxrnBwmhXK3jRELOVK0LkVlk7usnIIV4MInlrGSML39kjGByz/Oj 0NzaHKAIwjg0YwCOcyr2APR4+2GcAi4XnonRQsKVU+cVCeW4cpEnQDc8i6tiMGHBSMy0g7bQ 2ENKo5mLjcs1X9/FJnpxToGZr7anS/LGUW558ojMM/J+iEtCLza5OB3aIwLi0rOAzafEZZYc kODmanGfcrm0NNG6rC5b13CjnSb/Zb38g6K6rjh+7n3v7b6FFR647C4/d5cFFkJ1UcQdRdx1 YVHBKOIPFiKwIBpMY5CCGgbTJdFUq8akdaaxJqPWVkAnYxY741AnY9qJttPJGDuZkLRj88Mx jJNpdNJMYtCOvH7vCq1j82ff7od739377v3ec86976C5948EAvu3hSJCZBgGH9UvHMiMVR9s jGmRTrZQjO9e3rHfvSa8CGaYJc5pvO/i7z9Sx/Qjk/9Uj0y/Aacv9kOZaEDU+BTsGm3nW6la qaNSqZuWKzfIqzxPK1mEqvlV6uJX9Qn+N/JI5ZTLRvW7ko18bJSqeA255D+Rj1eQVbpOZuky 5WJsTbpKqXImVUl7KUk6QxrqZewoVbGj+j8wTpn0HAVQFkteypYnaIFSTSb5BnXKF1Hvpqfl ldQhV9EmZTPuL1AnG6dO7iajfBl93NRpqKdO5SK4QhXyJHXEyz9Qh/QWdWGuGcoy2iR/QxVG N9p/QQvkc+SWE8jDP6UoNIsyE309Ur/+JX+XyuQuKgY1kg/5QQ8VSdfQpwlrKMJ9EVWzd2g9 u6y/L0eoA/V2w3kKyV7yyzb8vptq5H7Y4AxV8A68Fd8iVX6KIrKZgsoY7NmHea6SW2ohB79A c9gdOobSIY2TU6w7vnasW6x5ek1x/Q80/Q9Co9D3MNBkZe/ox8FFcOQ/2h5F6HoIKUz5kptq +GXywR6lkp/KpddphRwGRN3y1yi/ppWKTEbYyQvc8OlmwzHyx21+h/KkasTBBVoBIkoVzZA0 2ip10C5+jdZJedAH2E39M+ksxj9La2UnlRs+xlqgB/6fJWIP7TuNR+mYlARbJtAZqZRmyQb4 xUDlShHiRuRvU7YS8xqfxxg3sJ4XyWvYQAsklUJgIRumOuCFpmppIeUIuwvf8259ELFziK+n MpAna/Cth2xSlEpFHOOZEjxfpF5G3At/CF9MlQLEn4ON6x+A34Av4j4S68c+mvbXNPDFBthp KcifQtjtL6AHLAQWcBIEZbc+CX99JOIWsZMmYlTEiYgRpVsfF7EYj13EuHyEOuP77zYVwsaZ yH8LDcFp9HvxGCtHjnsUz73O42Nzi/4R9K2Arauk2VQgj5LF0ANOkkVxUYo8DO0u2PMr/V9K Gc2VRilgFPtiDPPuJJsxivoEFfEi8sfbEA9YYwc0ucT9o/Ai6OjGHnyXmnAm2HAm5OBMyHnk TJghxhRnQjzubiNuPFQvD1K5fBYxeQ6aUrGXu6hN2kpP4AyokK8gz7xGrXyMHPBjmxShiOEA YsNFbeoYfg9Ts/JnlFFqlmpoNfZ+lnybGpSfUobxHClKBRXKX+KsiVC90YYzpVwfxxiJ8b6i PUwt4re4hu9BaIrreQgxt5jjYQz+eN+AbKcAYnmZtIpm879SitSJs+ELSsIeEfVy0f6wH4Vv vq+fiMGAPXDetlSL1cUisW0xOfpb1vrG22/wVW/iIP59QI/a06uj/WbHK4fMjtbDrOTgqtOt pyMHXz79ysHjp786oEaH3xx+e/jqsPzpr5k25BwqGQoM1Q0pXSeZdsp5KnBKSh70D7YORgfl /ZUpjp+APWA3eAHsC6Y49oJfBs2OHwc9jufALtCP+51B1bED9FZ6HD3gR5WqoztodWwDXeCZ oM/xFPpuQb2z0up4EmxGv02gA+0bQTtoAy3o0wQaQbiywNEA1oN1YC3GWQPqwWrweLDQsQJl LcapCezA3+VgGViK1moQAlWgcondEVyS4nAnhXLNIVdCyKmGHIZQjhzK5qEsChWoGapdtaoW NVXV1CTVrCaoqmpQZZWrpMLwGfhfhDEyMWToVFiIUyg1ReUBX7J/lNGIldWOGvX62pha90R4 hLFDjbHUWqpdG/wdHtJffCnIsmtj2WvCsUh2Y21sABXKHrFSsLEYGX/wnC2F7XPGclfvdz8b C9Q/O5Lg3Idkft2zI5wFY1KWy8WQiLorNzQFWW1deETFg5UbHpRWbdtipMjOWF5oY4wjA0ay 6xo1UGN7LLUynDnKKTIqU7t7uhJLLHY3xhKREiW4g+T324u1RcxrMMcMaDK6gz3F/8+rZ+qa qhbHkwzkG9KAoY0kMlJGIEGRTDKpRoaTwXvFe4Vpn1zBd05JaYorJd+V4hqQ6P4Ap0kytN09 PqC0IYfpmozxMeU8OagmMCecwWrwtTZZOWmb1R0qb1DZfJV5VKbuWmBjtiFnP57pzdZ6Nab1 zkwl/61mfJl2p3m8GdffL80pQcEsRoP4pFlsVvFJsxjcuZ68FM033ze/dK6Vjzl+vtSf58wv qlg1YFtkMqVPJkb3fWc3Ji5WzGmp9e3hV/dE+w7/quGZFUmJM0+Z7/G9LOfmtz3m14jpE1Dc Ele8PFDSkMOqc1hZDmtgrIqxMsa2JPcl88LkcDJP3oWz1tkP2b0ZWq+RGXvl/wr+8NIHt5qb 42qFYE2BwoKyeUKgb37ZPE+B+JTNg1qxAN4ymWA3mRbZBlYuLsp35vmrDzsWJxrt3+0d4BX3 ++6ZT81MTHp8a/jE4b7onlfD7fWpacmvmXu+vQm9d/V81s/MNJNyAokGkzmNWswWkyGVvB+n X2J27cP772mfpMNw+XGrCRmW+T6L0FI6l/W7re1bPKaVW+StDeXW25tXzX16xwYzf7nEuM2T ZRV5qY9d59f5Dcqk9EAiZWtZSScSd2ecsJH38/ufM+2P2ntzStgDfxgNnoLSXEzxYHBr6Vz8 5Z8xU7KUwH0F1U2Gxd9UZC5UbO597oo7FVb+vsld5fKbJM65zTX7Z0lKupixSr/NtrMyMpM1 YKJ+o3FGUkJUIu8tlpK6wHtLrET4+4H5rGx745IlP3hs/ZJg+HBwY2lJsLI1ImLXhzfqS3in JcOT687lqBkX9Amy6hOB2Tg3NpLLvlF1brH0WfhjFma3MMuTPjMzK5uzdmTx/Cz2b6rLPraJ +4zj99ydz2ef7buzz29JjN/txA5xYichR5L6QuIk5iXEEF6S4Ja3QFh4CSsLCiFp0zJexuiq rQGG2obRRlRa2ZtGl3VDWkeAIoVpLdJgpUJblYVqI9M0Te0fxZf9zpfQzX/Yd+efpd/v83y/ 3+exvQiKdteQQBqxZBZVMqu+o8LOcQ/RFmrQS5Ghuo9l+TpqUVn9PlWWifiyavLM2PiXX4yf PTv+xZfjY//IdI2Nda5t7/rBK8924F1P3rt+/VdffXX1g99dfXKhf2ho/+sXDo6Mfks5vw3N F9PkXSyKiZIH6yO3hQol3pgx9r3IA8+XLrXss4263UxoX4RkDCgYZhEVVAoFTnYmOp3IzaCK oL3xgtkqqOWwVPOVfvUSqe+pEBM+RX0wDXZyxVG320jpHbuddg1pW95AVC7VQIe71kSOa4xX 5R2b5Tc3h0mnFbrfgRV2j8FQbmBKGaPOsZwQK8wkQyo7N8z/k7iF+n4dtlFiz5VfLsePOOCW AO8JUD05/y/JW23qtYFtJ7YsDvFnAn3Fxj5Tvaegp0xT7FvOVffQ6Di5Gzdj08ncTYT6b3+a 5R5mp+ayZrFGtRKqvFXwxxFm0u+Lwf/4SQGvpSp8qrOslWoUKNkAlBaVIwlx4hblZe7+sUX+ a6udKmhuE04fv7IytaWzs76+kkYKBY2VbR8Z7Js8fEK+GO4oCE/laOuka3CJjaOEVw0GEz84 ce9Ad+0yv6PYD5oljqXdPM3Uh4Mbt/3i9/Klsg24AxTlcYjCA/JTrAZbhX1P6iosfD8IjiAE Xa49DaLQ0CCGxAHxuHhTJKVmMSP2CVIzn+H7mrdJFSWZkj6pgskwfRQmVbRXbK0gKtZsbYCa BmiodTUQwYqmXc59pM3GhoMaFoslb6Ci1w3POHJTZrsIsWyW+zR758ZMdCaam4miz+wJU1l0 mJuCbDbhiCm6WNQoIqNdFEQe56IoFrlRygK7VfEwWg2V4Txhra0W4uoy4oEtsMJB0ozTt/67 Nj4jX8vUWVKjP+osWs6xqVfcLOBQ0OOkcfk0peP1zJUrmtUll9cBThpp4CyAEygJzvhtJGVz XQrZ9UPb7Gvf+uxE6SZrJVOQuJMo6+8RMzRfdBB/lyZ9NuvnjxnN0NAb68sR46r5W8Q95G43 VortlhrTvk4ffpuF8+wkiysRfYolGLaQXcV2sySr9ezANFqtAyvrCUFox6ADaAc4lpbs4a1W ItBbpNH1Esjnc8k5RHN6Dikvi9zO/YEXYze4OV5UlIf0Bxzmzds9EVdVp4BciPWv/c8LefMT 9+Qu+Y6gLQ+dHU6tWIXc+I2jV+6PHLn79+H+R7UN/f95oWdXy1r8onxH7jIfLbJJ/pUdTTq9 dP/KxwPPT4y9cai9S5Z7jidE1IKxXgwjL2qGsABWiaWwHkkaDsM5J5zEYU8QNgchjdTVUthZ tacKr2rx1FLYAELUUlHbZG4ztLETzR4x3Z+AREJfkhbwFWk9vXjY7JyImuvMTG4KGY0X57JK 18o+bbJ+X2AhNcxVlbhycHJBG/mUWwKQP3JeK+hpwmPJ37tAuVMz8OKeAz+W5Hkpdi3mtFqd nbCr6+Ph8+2iy7V6i/xoZPWVdyj8M2go3Jf6/hPyxZE3U93ws58Mv0zR9v3w6/2H4KNDNrzt uQ9TYyELRXGRt2D2TIXL6T3ms291uOThI9GiwrcDrwX1+pJqJYF2zv+bLESkNmCtUqQuiG0q W9UkCc6Ms00SkMnahImNqfTy9ni8kA23R9KFeEd7e5pFPHKzydyMEqGzcwqR6Gw0V8c9nHra N9Wo96pGQTSIUAxCeR4BFYnKCh09H/5xVSN5MsoP8/FUrX67LB5EYAppHU4wGqu+aEiW0/In aa/TgOsACpvB0dwITGOMtNo2yJc3rYsSuqjBZmemXq9fb2WXGNbUTE2UFlPgce7c3wyNrHCb WxKiAykzaaZd/fBB/zdhWfu4yU7TrmMeu6V001i93g1anMYFzzGvWUuRRFjb8VpvgRUcaEhG 1LTzO+GaZhArxkolPoKtpZqkAnfG3WYuKPHi5sn5x79kuFazAYtNRZPIHdNKuihtX8AXckSl E37aWPhwpWoUdQaAa2hmqj5tobW6lpSOaXIELU4wGFyW1RbLSrNT07NdPry9/LexBycnD7BM e5LW0vpaV3lqC7jPPfvR7V0uikK7RC7QrNN8G2vBLksHTaZEoqqG6+VwrkqsWi1wgiBwz6wd EAHloJiSCCyDtRHpQQFqhFahVyCcqMenpFAkE2mTQv6Mvy000ZrADwgvCHi3ADEhKawViK1i v4h3iOARy0VJJDhRqCK9Ugw3eZFE6pJKyKoTXXJBJI/RNfcQ8chmZ5SoPWEaRlnLo6yNxxYA mRUFhPI+CuMQCvv+79HXYnqavWaw2asX/Kby06zjSCdbx3IrOLPzvpxuYvR6gW/mzS1mp1WH 0wDOhqAp7LXobLPwidWstQjmtBnRtWp6npfLD+2T1+zzUpQX/HjDZn3Jhdy5C+hW2A+/OTAI teveNrIABBriXPJU7tUCS+TsSzg9ilYo2jgw/5g4pXkZS2DfkbacKv1hKU6XwpFiWM/uYPEQ C9UsnAycD+AlgcEAHmgpQT8JoTmlyjXAANNcHKmJ4JGJykoewjysjgAT4QOktYzysOZWSrcS K8PdLT7wrbTqkAezU0nnDUfuZpRXQSuD/1x2CuXxzWx+nMayoA7UqiPj+fBR/wIsSnBRdx51 yl4MZ7uNOCX4mSJKD9eTk6N/to/+fPzzvTRponmCdexwQvXwjGbkyOFr7b0HRY3G5m10i7qW S12NB/ndP/3L6CFHKL2kTkeb9B9ub31Js+vd9/v3FrhK8lNPPYZRj1DmPAcmKT3QBB3GnUa8 0QiUEfYYYLMBtuj26vA1OtD9l+6yj2rqvOP4fZ7n5t685yY3uZeQQIJAQhIJIWEQQEg6ESFA ILxIBIMvQzfUuqoMIlTLZq2CrB4Vnc5uPZStsDfP2Wo3u7nj1qp1Hl/mus6z0+lOzyjWdfG0 Z6fr/iiXPTchyjxbDickN/88v+f7+35/n58MxCE4RIDORjBYB9bUgcFi8AManKLBHnqUhgMU 2B0CvSHQEQKh8wsfBmW9zn4n7HACp/gt2q3YphhWIAVDeygiFPJs/F6sWSoCcyRcFwZhT78T PKMBDKepcTq5QHONFCugqKnxcLjZa4zN3Ksb+j3AGVJ4ajjCFpYxbWUmSNMMbm1fUcDnE+9c bOv5WeYvifKqolgGM6vD/3XlOixGBiaL2fnY7MP0I8If88fEv5Qmojjpz4svoEcUolwA6/L4 A0x2fLqzDaJDWM5XmiY529LfkijNijuet0z3X47gS7CLqPtXV46p1OdYZejwqmMK9jWNatXY RbkR9762Rmtgr62kIFLa6xoRbWAb9fgZLwVogskDiHrqsk6KHa8LsQYkR8NSYd0x4Z7JdBYM nBcmTKajIBe8mN0KQq06itREhDciPmHzIUDxfW/923ig8qNKDZ5GgfnAlzmvMLy8lUQHwPGS VlAbwc+VIKtZuCKSoGvhPulF7+Nc9RONwZxlat5hd0BHhI4Rk+RURWlxbTEsbs+YKSdi+VRh p1VkZLnVTH+hU61XKOSY7a8nAjf8icAHWBdMJMLsXCLm9abwHt8bz4kRssi+S1cRfvGWOPTk TuJFdiMAZV81sXhJ9FT6mpvfPLDvuQN/Pr1Lm4cQxWlNodaF+qZ4vKWpqSX+teYQGiXVH7wq F+rVWapxu8dYcGbi8r2j39qqt6F9Gp3QMhxd39M1tGdtbP1aXLF94T56HT0gsgknsS5YXkrV UtAO89da+ix7LMjSzhBTy8n89ij/FT7OI37GZe8nLf0jEECoXxY10SN4CZNG9QocBnuvxDIW IeVdcSbHMKQIyWWgXIQxfAMSLlVUmTcbpAKAeMxiYrxiJBFR7PWga/43qvaWdd99nmGkklrm +NyHwj+eP3ztwr7hh/tb1x3Jm7hZAY0hI+OKVlduUanIgxJK+xIw3L95+uWxF/a3jUysM2RL Ra/XLgjoluRF7PmyoEYeqZwKeFxsZFm3ebracx4vl0qPJlpCO2J5hMSI9fMFZgOJG/6kq1Zc ZoTk8ppULL2IJcXRLj7T4kmQFjFtDn4pkHPolsGyz2Kk6R+WrV1vsDxr4VVQA5XaDYZ2VqWR +iKbnr6w2ofI3HyY43mz2P2ronNllcXzZ7OgCfxtAIwMPlCSWpLSsD3CwR4euKqqnmn9meXr lqAg9usaAoKtEgchJ/KJkqDFPhVU412kWx0xEj1k0GiOmLuN0zbperghm9KL7SmkYOmPCQav Gw/FvkztEdimaHH2Ydc/xsdFHNg6ethV4PdHaJbSvWWgeYOugWUbWC354+HhsrxltcIvm4Tf heuFu3UGxypgqA0Df1grl+MT9i58TlZJjuJpVE0MB+v2VoG+KtBVBVZ7gUKl6oISPYQS6JeU tBNTwZYgcAb9toitm/Enjx7wdyz3wMp+lUTBMFxpp4fOi2UDmksrhZutvNyXKGfuJuuavzTr uoRdl7ikLV/co9IjCDC0Xlf8aOhogOGRhDANQakE0+p9pemexGIbUjas+uRq7xdzVuuKNitv 2DnrXivHsjkr1YV5nFouy/DMnJro2fLJG2M/iezub90CzwqfR33CpxoJym45rUPgMws21Y4h MDekg3hwU5KM0j+VCoJBb/9GY9vFI+dPaJaXid26Cb/14smUSdiDvHkqCUXdKBJUYxTuVk+b WEImqpjUcH4uKSANtf9PtS8BTspc1JEGg65Oh7lNJ9mmEsaFTweF/AGeHwDvDW4HP92mT7Ja APvkDnqHqCA8wUx5xD+1wjVpiORNWqcr9YXaaDFtc1ASU/LefYHE3d8uzp3/YZDF/EpbRDxU 0iLVIBl0S92hQ3f0OftzdBTMKdjuXdvDWkesBkkhUtF3JBSU6Eo6+jZdWIXdoedgVvFVb8HL BbuK/P5K9/yMEfLNYEXLu+dkpJwEuUx1wFEVfLrlNcuIdaXwLyKZbA/Qx+ivhAbvnPXBYqaN yMlok85YZXoQ0o/poR/zZWenclAJlTRlBqvMB8ywzAzMnVEyTkISJ5qIMDtT72KcM/cSqSBf Gtz0E3mNPh4dv/X78dHRb966OT72TkM4Hm9uaGwZGGxuAPdvT5w+dfz27eMnTx77w9Ca7q7O oXg0FouKpw0Jb5Nh9B5RiJOqIWjuc4MKd8gN3e19WJypQKlNHsmc5KarvVGbOHTUNidtjZkp jbqiUyqe9UYigA2BR09SmMs4ulIAlj6vXdwAkT519LQki1rwjzLryWrI8MgLbz8bczopCAD/ bTNPZkO5rX6TUitBkKJl40euHNr/94bmgf5QTW3T4K5wHXj/2onvNNkLkIraKsxZScSPQGLk o5tKUoGgTLeiwC6VkvIjZ05ciXdv7O2KD3Vt3NwjMtmCAF9B14kioiLIEsW23MmgQhPRdCsi WZPGaY9NzGqFje50U7kxSyrL5gKJ66mknnXNXmaupItNVpBaaZ9oQVxlrjc1gZIFw1c0SGvo 4PblGmQ8jmle4oaq/JXbpYxcBZHDUVhkrwqjH+3o4mWrXYd2+Gf9JmiMgNrWz05KSaWElOoH YGamSaUUvVu48E9YgRVcTuwPRqddv3BBo8lhgk4emHiQDwEPQY0LbHENuGCHC1TyDTzMYduI KbfGDYrcC274czv4vh3Y2xTGmUKZ0WiE9Szws4AljHaSzI1m0dooSRQlcOqJrC225N5LGVjk 2E5sw72XUjy3E6RRLt2nycJ5Lte7lK9T8zclNM/BisHtZ1ZItQqdKsMCft12UN+2c8tLalU+ G3yqKRK3toKSE12tSOrgogYViRDqL3OHtKt3n2xvyDykViCZ1PAf9qs2tqkqDL/n3n7cfq23 XXd327Vb2Uc/1nbt2m7sy3atbl0ZDLovhqPAYiYQlmXyDQkiREmIP5QMDIQ/TDDTxGiJwWDA D0IXY0BJEH5oJDEREjSZMQYTf9jN9/beFqIY8If+4jw597w9Obfted73nPd5o76Gpyv7BB6Y xXvUtJyBbhjqbNTY3Y7R9gE9NOojA9pR+6itzK9fqV+vp/Wziea0oXXYU5uurvAoutLxEUVa jZF8J3c7GvruDpsL3hZExNXs7X33+Hn2VhZT1lxjoKUu/8dFASW6VjqOS4NFPSrdL+1E1KSF SMiHhSS1qGmZnBBKpu/P/MS462rLZLTNzDfIraoPynUVvxiUlNX1pouRyVm+t2q3TXuec/hL jDKl0nljiAwNuWkiX2Gz83JCOV1n3MkqutSb8dq02iadPqIv1bQmXjo2XB2uEBjZgDlQRmcg COMfocS82xkx1ZNZB9npIKsd5EIp0TXgNe/EvEAT+nQYwoQNrwpPhenKmdqUeaZsNhQwK1wj PTqiY3Vqg3AJX21Jz0dDyA+yJfgfq9kcRkDe9S2FKrZ4GIRAMIhZXshxBceLB8EQRppkMq2q lLmslavk6tnTtxLeOhVv224z6UoIbfYcjQ6P0nL3Wzb61eTCN8swzydNCuoN1ZFTzxFyd8ZJ cc7RMVdHz/sdE5FYRy+Za8Rdhxb/kJ+hL0I//Ng5vX+QbBgk0cGVgxQ7SEa4TRyV5EhLGakr IYc1JzSUR0N4GYFBog4oqFgsQFEpSC3riiYIJNgElQiaeDbi9fKRChSc2kAk0vZUKtAEQTZ4 KkgHLa4aR8rC81bL2wNangq4uiJK0/KWSkU2Rs7FyM4YiQ2p1Vkv2eE956W8Q2z+BgmF8PSE /MIREqsp5HMu5Gdz2RDWTtkQjn6heEobUGcIFZRQUqWD2dxcyFCssyTS75+6grSni9b9Y8cV i6QC+/mALcap8YFJqSCQnymz7j5YwfQ0MlXXWtvWWZi2dqbqxV3mcrXcVLm7slSmVh010rT+ oFHLGD9lFdqMjtbvV6u0psqdlZycob68GIjP3VRSFENWrVt/FA3l15/HOzLTzZysilvDvdcT /YLnPu4KzFYfWsJZ7AfsZ5cu5PhLseYDjteq9DKTE71Zs3CBztDvYl30emfcQZOKetKCqoIy G0nCSII+fwrcRmLEOpYTagM43eZvI2wbcVbXpXiO45kZDZZNlM9J2w/Vk/p8Dqsf5uxGozJs V+iGlXqIzkezxtZ9SCs/35IW3XHjjkF0SDrN/hz0pwXaW7G0zQWzoq6TKgsQmG4gAmsoNAo3 XbMkhiTOkV3jg+TSGbVuweN1fWvRNzVNNRmTR04YSygexR2rYBRf8YYPFYyWRT4qqfPv1Phy SXet5pCOs2u2myrOXw67TzpOODmmzDpl3dvhWLhO3DXBl20vWM0qENqSh2IvXBdAKNJO1iEu UDx1kjpJrygi+1fI1uRxrwB5QoSCKmJahPLU38GYJRzO43dVEvG92oY4pL6lSSM+0ca1V3Td uu4SH2LuCZ7gnwCCViX5+DYBLVjEgl0Bj2y0NGpQLOlZA5SayqBcmLAWVtQBuITRh71RMJqx txW/4BnsPQC9y6FvJaT6B2BoePUIPAtrH/3b/0uTwWf4rAc7Wmp8uqEBM34YWiEOXbAM+mAA VsMYjMNmmIAp2AG7YM/iIr5jx317IfDQtZtgC0zCVnHt4g+PB8lDj9voR65g4HnpO+m804i0 43KEaCvQahAiQqbCGQfuQrQpKMEdiDaNK/ZItgztWclWoH2zp6+nNxn3xMe3TmyeHBib3NYd 9/WPb/x30xggfdh7IYlEerCPI3UTSPgkEjqGz20oS+MoScZhIzpgAue2PuY7Pumt/3K1yCzZ AgdBCceQIwpYrIj6ce64fEf+vBFxzbVLhoX1+o7fwMLk6c+88utSYTx7ZfvaxeMLG5jjSg9+ FPjPtz8HAJiuaqMKZW5kc3RyZWFtDWVuZG9iag0xNDIgMCBvYmoNPDwgDS9TIC9VUkkgDS9V UkkgKGh0dHA6Ly93d3cuc3ByaW5nZXIuZGUvY29tL2xuY3MvaW5kZXguaHRtbCkNPj4gDWVu ZG9iag0xNDMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAxNzk2MiAv TGVuZ3RoMSAzMjI3MiA+PiANc3RyZWFtDQpIiVxVCVBV1xn+/nPufQ9RcEEE94cPEAWCCypu AeSBiIrYmoioIwgoLihRxj0uqImiNqQaosG0GtGmIVOedUOtS9RGm+AWq3XUUVxi3Yi2ExNj 5N1+YKdJev+5M2f5z3++f/sOBIAPlkIjbcSvo3pMHJpeBry5iqup2flZBdpWFQ4saALI7uw5 hY4s33t3uHcN8PKaVDA5/19+zwo55pqZPHn6/EkrB67iPNoFdC/Ky83KORX+ww7au8wzvfO4 4Dek+XbAN4Lz4Lz8wnkVRuQUztOAlv2mz8zOQm2LB0DuKc5d+VnzCny6yzqez6O+Y0ZWfu6y iTOJeGEN8bxdMHN2IXHzW3i0fr9gVm7BqGfH6oBOa4Hme8zfoKM5rOFvpzegLWDd5E+s1j1P ivXCnAanZ6pVo/1oLfjl/98vBCsQjHsoxRGMx5dKI1FeQToMCURrKOmLodIMATDFG2FwYijS 4I8UfC0+qER3PJAkLJMQjMBmdEIqWiEe72KLDLbuYxkuyBRU8PTHEofOGCbJ1g2MRJq1j3cA /fE+PhBfdOSOtzit67QwG2/jAC7BQgY2mltoJQ2/wgxrH8bhvGTIWKsdhmAGFmMjtuIQ7sgq OWqYViZ6YSJmiV38JEwXWR8jxrzcaI91wjqHZtTfSquPVLiRZH2DONwzxMpjRP3QkzIDH2Ev rkmg9NIJ8EU07xqPRajUYcSYjNX07YAslErta5XTmz7IxhLUyDw5qoLMy+YTawFa0L9oIi1G OT7DcTyktSQZpfM9sVYqBF4IRyJvWoG38CdG7hjlhDSVIBlCy5/JdbmpZ+i7tPwH1OI7PJMw mSKLVawqMnvULbP2IJQextHGEIzGdHwqoRInY3l2s5qrFqsleq++ZoQZj60Y6zhsiKJuET6h X2dwAf9gvpJkuFxSi/Uu8y1rIfFGIY9erMB27MdTMaWRNJGW4pCe0oeeLZSjclO1V06Vrifq SnOtNd9ahyDWynjk8uRULMdK7MNZ3MJD1EobnoziyVhJk3XyjpxQZ/VoPU6XGnFGqVFhHDNe mM3NY57znhpGvd5ONwynjMckLGCsqyjHcUW0tJUOtDRQUmhpgkySRVIi78k22SF75aSck/vy WH5QgWqt2qAOqr+qs+qcbq+7apf+va42gowrxo/2rLr2niOex1ZjK9zqaZVYm62rVm1DFtqx 4mORwOqaRi5YgRK8hw8Z8904jYusuxsNcgdPmIMfxcZqak1EncQpnSWC3o2WdJkrxbJeyuVz uSl35IWCaqI6Ubqq3ipFjVNF6pF6ob21U8frefp9/ZV+bsw3e1AqzD3mE9sde4hX9Yuyuuse eKZ4Sj1lVi/Woo2V58eei8Yg1lwKs5yDNyizMAdzGaMFjPhmVk4l/oyDOIVqxv4srpKh6vHW y31m4lvUwSOK+TTFi/ISezdmJoHVkim5zO1LWShFslo2Usrkd7KV8T0vX8kFuSG35Sl9gopU 8WowPUpTY9V4ygSVrZapNWo35Yy6pK6qW+q5bqab6466s07Uk/UqXazderf+u75ohBrxRrIx zThpnKfnyeYQc4KZba4xt5rbzGPmF+Yd07Ktt31kq7Lds3vbe9vT7KPsq+1/tB+0X7NbXp1Z T8OJvgt++tbLWCNKlYilquj3YVWov1QbpOJnGjCLiSAHE1SVPqQ+XFSib+lPVRFguBq2B5LF qvEXVJsXDH/zHk6qNviGfLhBZ6nDapMKlN66v7HSqCbrzCfObeqGsqtKajxkNibgNWmNfxuv 4zHjf9YsZkyT1HWpUJ+rFFbyZZSrg9iELciVPkSXgz14jndlv3bIXtbdEpzDI9T8hNaIqhuk Ym2Bao6tHzO0X0ZaJ1UX6yG7/qasxFX9nLX/uqRKFHbgNrN+UaKlo+Ex2uI8ma8Dyli1/8Qu 9uAXRjA76Cn262hkGDXMeVTd3zwus1Avl+9UPNMZ0MDcI+rZmBy8kVxVz6O+qGQlkEUaOvoh TksnRvGC7Qo+wDs4oP0RorerpcrSpwwHfosaPYy3vkl+aifRtJQPvmqGw7rrKaeFqYhBjEyU DLi4k4wOVj6R7yAXxVnjrE3mGDMcZ2SY+OMI2SuQUSw1G3lqqbmbfXgVybIGuzw5OMp3JVBC pAerqdacY5aYn5i7zcPmaVt3zGPXljGLt/AtXw2HZDMWD/A9a30QuyeC/RNPFMl8w6arMfoQ EqQNCsiBYeTtQYxBBjM5m1aKsJb9tJ1vyBk8kWYyDodxmZ0TwD7P5v1etDMUrzHrs7GD7Lhc dnElBx3QlXF6Lr4Sowp5Xz3PlpJnjxLTNdwlc1gNuCKkv7iYvWx8X9/LvKE30mQnkqy9rIRU uHQ1vkYwX9dB7NFynstkbfiiPfqat0UhwpNqxagp+pC04mvoy6oaxZd9oLxBFE3pRx38ZQR6 eQajL9/YpUgzt8fFxcW+OnBA/359Y/r0iu7Zo3u3qFciI8K7dgnrHBoS7OwU5OjYoX27tm1a Bwa08m/p16J5s6a+Pk0aezfysttMQytBRKIzKdPhDs10G6HO5OTI+rkziwtZP1vIdDu4lPRL Hbcjs0HN8UvNOGpO+j/NuJeacf/TlGaOARgQGeFIdDrcp11OR5VkjEzneJ3LOcbhrm0YD28Y lzSMfTgOCuIBR2JgnsvhlkxHojtpTl5xYqaL5nY29k5wJuR6R0Zgp3djDhtz5A5wFuyUgFel YaACEvvtVPDyISh3G6cr0d3a6apH4NYhiVk57rSR6YmutkFBYyL/w3q1B0dVXvFzn7uhC9kE wyMJssslCcluAHmYVymBJAtJeCUE3KW03TxAIEOBZqClVIwWBC6hVpwqKoOMU/sIrVzQ0dih TBw72v7B9I9OGKuVOBU7oIDa0U6nHXP7O9/eu+wuaaGdZvLL+c53vsf5zvf7zrkJW1Jdp9Fh kbHYyg6JIVQntrH0Ossjtgls5tPQ4cCZ8KDZN+CnjnjI12V0ta+PWkp7jPfICWHfemvidy9P uqli8dy66IFUa4FiNkzaHGDVNA8ErJMt0VRrkP/GYlgDc+WiSNyMYOs+BLF5dQC7yftjUUva jy0DfBI+VeJ8G4wG7olvCVhZxmJjk7kljqvJNy1q3R08m59f+6r9HuU3BMy2qBG0FhYYsfb6 wjN3kdm6+8XJtYHJ6Zby8Bl/TiKwZ8ZlOw3f2NTGhqRNtMRwbjW3JiMrsUdGIwhhBToD8CRq 4EyV/GdDJZmdlRiGn5iEWVYXbmSzlVUXN/3V3M/zLa3IbwTMzwkMMK5fS+9pd3r0Iv/nxE3m SZJqsLttKxSyysqYIp463Cl8/IrQ55eHdw3Izxrb/QEIhI9WIbbtsepZCH8wyBd8eKCWOqBY vS3RhB6gjoKzVDsrFLPkOFsGXUveGrb0upbk9LgBJr9E/P9JnuUtTv5m+yeMb9hUbUkT/oN5 Q8LevNpoblkXDTSYcSe2zW1pWsJembQ5LWt8XVQpkJ2WXKAIK0i5PjmYlajPUovwqwtSdw14 vGCl6JECEcsfX5r4GxsTDN7hpAH7E54lxM1pjptWdShdr0nT09zzmQocVovl5rZ1pjkmzRZB BjLNiBGImHGzfcDu7TACfsN8FV8rJeb2hrh7owP2rw4XWJG+GA6xSaou52B7giMNdJ+f/nlo pNXfIMKf+p0xVq+SCrklu+in0+oOslSiGcBKL9EP9H5qlauoT2bZT5PR/y31UZqB8Yuhz4Fc B7uM/ibgADAHCAJzgQZgmSOXAgt5D+AY1ijldYTEP42eHbRee5P82loKQbYABWiXqu/TTL2K VgMhZYoYOwHtmbAVe45QKcZNgb4K4+axhF6s9tAW2JvQns1r4hy5kOOAXPQHsf9F9hmyTv0J Pa6SfR3tYqy9HnNDyhFaAbkSciX6F6N/OfQI5pTJ/fabaNejHUJslnG/OHsPlQArMKcZfraI 9XpoIWzjsW8O5CwgB/Y8pYSel16nZyG/qpaST5wbY8S51948E+QS4dMoYB/Zv1SwT3KV/Snw LvC+41vjLWC/UkHUqcylGshewOD15Qs4cytJsFdr/6AahpfsL3Cuy8AEtYuyoV+Fny3aSzSf dWCcAH8XHodPn9EK2EL6EzQT/fPke8CxjTRT/jFV6kWUhfOtw9h6oEdwj7nQRW24DxtyrPoB 5cM2HSjGHZ524uTn2EDn+8X57I/hxzWMaQFWM7cEv7rIj/055nz3OdLaEXDTvgrb14Bv4Fw1 wL2wfxMcjok5mI91axweliYlwNxLwQz2wQXfk4sERygPuMtBCfA6sA94DNgObOQxWLcM45kn 3VizAfo05gdzA2vxPTQ53MkBv0sFxxJv5mnEsQmYBGTreFsOxmJsHr8X5qx4L3gLzEfmFnPG lcxvwftT0it8Tr7zFFmgXaLV7IM4O7iVIouZZyyVQSoTsoxmMGeZb64UbzLhfzG/CVcm/cH7 5DfCUg1REb9V5mJS4p1yLJJyIpVizeX6c/D923SfWkJNSjctUtdRo2Ih/4zwfvZ1dYhekH9L Ic+g4AzOSE9lSL7nY54haYs2SC8jlkXqBXoK0lCH5GnqkKRpp+yr2il5bwJuO1VmQhpM2Fgy Um3/bf//Avmidoo2ov2hNoS3M0RHcVbyfCTNBgKuRP9ZoBco84akY95uacCzBu+J6DNgm1qL t15LFeogckIe1SJORehfo/8InOumEqz9hVxLb6D9FnJfhUJ4n9hLvoh8AfD6kMtTeJTGuVG4 JKTL11FkyOGSkMxn5LW3HfmOI29AhsHJEq4NnJ+5PnCOBpYm+erysoTCkM0uPzN56vBzhcPP W3l5U86FrHNqC+fuXH6n2MvjvNn1nB85x3GO5DzHOc4dnymT8/vpSZzhLZGHL2Bu4l1PBUJA GPbdTh5BHrb3iXzYZe/0ROydarm9U6+yD+ofQW6yd8l77K3JmqrSPU4uC7q1VNTRc5Tl1lGt m3qcnMZ1d55Wg9qUqKOifuoL4McmUd/C0CfwOxRv8DDlynsQ1xIao1bQRuU8KcoK1E30q+XI yWzbQdOVG1SoHkKue9y+pjxGC0TdXEoblDhV8VzlLGVrD1FQ+yNq2R77E7Ee1ytI7mP/9Y20 iHOBtlXU3i1OPg7z3Xt18nlVKhFjLiA3DVMun0XEoImmiTjw3Ifw9YO1PFdpqlol4hBgiDl/ Ix/Hg2OUFotEbW4Saw6LfDZOrD2MPX9Haxn6VGryvIOcyXttpXiWzHnRvuLU7EbU00blOXwH +YgE/y+QT6mgAtTKiIMl6gOIeQ/GHne+K1gi74t6fwO5ChzRDlGr+J5g2/fx3fMaLWGo/TRd X4j8WIPcv5MK9SmIURsZgtfLEnujv1F8n3Cd4u8Efi8LyKfHMR/vQvjA9YbXLhWxbQRHF3nH oLZ0ULbcL0ngXqH49uvHvfdL/B31aAp+6PQVJqQUlK+I+sq2G/J5+bR83u4W9b6CwsovUB8/ Ro5/BXyYTAvkTqqUTapUs/Bt9mW0v0eVys+Bo4jBHntYnYgcXo/+Z4ADmPcHxDMbtk8x5mfg wT7MvRvtd6lOeZkqtYehF4Grb0AOA3/HvC9Rn/IC9el+2i932kfF+ow9I39l8Ho8D5jlSvbV xag+/5R8o/pbf9PPpI+j+Mdr8LpiHo+psIeJ7D8BRQk50iIfoVPASfltzB2kvdITRBLuSfoA OO7gl7RUyDNAC+5wr3QQWAWo6l46AVkO+SEwBBwHzgE31PmIxRF6DfJFHf8qMOTzFGUJ+/PA r4FLri0VvNdo/alQ/0JpujaHHmTIYXwThunW8Sdonvod5NrZ+JYElF20iqGPo20eL22T/4z+ tZiXoWsz6El1G919O39uB+n3NFvEMIHaOznjnYK/0bg+/7/Wu1Pgfh8E7hfxP0kzBYeuIP4e ypLO0del92iRcpyWMRw9LuJ5gma794T+g6I/4/7AlXuVVqrN7Ef7YYarZ97r7XSsezoVLg9c eObQIwz1EsYDmbq3lx5h6MyxsNAfYLh6ct9/hzaahzhFIElwLENHDtnJkLdDP0bM862MpN6G 76q2BD8ZiO1mBmJIDPTdz0DsiIGx+xgpcY1yXLEnzyX3flyeZ94P+6X+BuMu0zS08zNlkt9O vkjjfEuC7//ivlpjozrO6DyWtdfr613bPG1gNrvLZrlgdnNtHrEa+y6PhKZZMBVq1YZiN4q2 ykPYSfoQlGQXqiqtFAWrVCJ2VOzEaaEhCvbcFJY4DitVJS9FdqNKNo9iWkBJCIld2oTysOmZ WUNaBEortX+q1Tnnm5lvvvlm7ty9M9fK6r/k9HU+n78Tn78beFduFvP/CXh33gbeAA79r8ei +H9Q/xF+9T+hzqgbcFZdj/fiXVJPyFiakEsHCbmMXTF2GToA7cQ3ogL6GyCGOnwdxpZBpwO/ R9t5fEdwZB9PuSrIjolzJdrGV8PvaSCbjzM+FXYV4n8EdAE/Rf1pIAUEAOV39wQeRfuxfN/x H0B/gvJF6PeBd1CHHX35cdgvAetgfwL8HdgJxPLxLsHv0n51HrnBPfS/qze5f/y7mr9vEPOq Xn+H+I90wxfr9XeOq8//i/TqXeIGqtdh4t70wT/dfW52x/kXxf7x5H+EHLiSc3FnxQrLzkLn LdAqo3Mt3SArZlp9Ls7ayK1EoILKqZW6hcilSyeMRUvyhmNWWcMJddAfAZiLuCiJ5ns50QXW 6EGUKR8nPkpVLb/s+CdjND7m+MotO+HnF/AluEAY6eY9JAcw0sw/JWmAwX2vrLpNDcT3OkUl lh/+IyQAZABOOsFUl21A+Y845VNV+Pelr1T3G5bxmrzh+KdbDYnJ/BjyeYu/R0JE8D9DZ0Pf gM6CHuJvEkPn+YLj81sZjNcF9y6+kcxF8y/5JmJBd/MnSKV2OyxL8uMcllHTShTxXXyzdnmM P0JqoA/zh6QlAr38BWRq87OOx6vyOyv9U6w+/iEuYJPhdQpe04Svj28gMUDNJOt4DKs1Ucyz mGYWyyKQIyUdmm3+nkQgjPdrniFT0dbPt5Ap0Bf5VjlF5Hr5ee32mYqC8Z6XhdVKHKPEyiU8 uEtQrPg5rPg5PdrfnMgSiyQi/CkSBxgW9SSsk7D8uLjEgQagGUgDHQD+f/jHaPkYPjF+nLTw o6QV6IDtQsiNEit4QBvhqHWAP843YyX8vVg7itonHE+JymyzLCvXbpud4hKrvo8P4lUdREyb DznTplvNvfxpPZVWZ3ql6vAH6SnG0v0w/yzQcZN6Bn08w7fqldiiV6D7dRQp8fEf6c5XnOJS K42nvxbFZvA2YAAYAVxwW4s5rCWNAId7g1Pis3y9/Ju685dlSbXo4ysx9ZV6tVbKKUGd810O jDW9/CvYJKv5Knm/QIJrJDqr1lXOklor3stX6QmvkiKUr5blM7Rxp/TkN88yp6hUDbdcO86T hSW6et7Ee8dNZ/I0S2Az1uopVavvC66eASAOZFCjVtxy/GXY4vdzS6dtkSagE+gGXHiQFtwt PEiLnNA1Pr4Ic1qED8siTLsFPAow1N9G6oFtwEHgBDBJ1zYBDPVxjNAEbgUYIsZQ9oNtoAnI AJ1ADhgFCkg/r8I4VfCOgzNANzAMuPBA5iOP+Wgr4wEyhi+nwBm0za6laZKmaZbmaVd6Utqf Li20F86Zb9kPKlqgKApa3ORp8WQ8PO6xPQ0e7vcEPCx7JScLaqshdpm7tvpI8kzyYpKXLW51 txaw/kQxLSXDwAjAST/1o+RHyW8/yfvrhutG6nh/cjg5kuT9x4ePjxzn/VXDVSNV3E5W1lqL G2kzTdNt1CVojNbT1dTVyJt5mm/jLsFjvB57wdXkbfFmvDzutb0NXu73Brys1dvp7fbmvAPe Sd3unHvAfcI96p7U4G5yt7gz7lZ3p9stCmIF9QW22zWaWMaOYlE7wd0AIxlwq7b8uiUHHtDl Vl1uArfosg1u0FYIHFcWENJXT4o4R9DjiPZT5RA4rspACH/hh1HXAm4FGDtszwzGw3aY+cOB MCNhOhqmA+ETYdYdzoVZLlHLhnSWQ8hySGc5hJ5DeuwhxIUFhJDtoPYbhN+g9huEn7JuVNcE btGWDW7QVggcVxYblKHFvsQM9iwiNoI7gGGAkxi4HmjWJR9YAIw9C7ZZu3PrfCuTZe0ygj9D SDAvs/MyU4szo8JqTPhYO8K2I2y7DtSOQO0IjdKVHGuTy5Vvm7wjL7XVw4nb8blU6bThptOG dFeDO7QVA9dra6/28V0rd4NPaKsF3HmtX6O2lJ8ArvZ3sXb82mD52CbUbrK9jEzFeY+UlRaW Zdmr8oEykWWvyKgf4uRFKkmUM45nYNBPNL+suUPzzzV/XbPP9oaMCyHjdyFjV8hIFLG7SRjV o5o/1PygXRI2Pggbh8JGV9h4Pmz00pMkiIZb7IqgcTpo/DFo7A8aLwaN7UFjXdBYEzTuCapQ URIgBpulmK7XPNOeFjAuB4w/BYx3AsabAeO5gPGNgFEbgDs9h4+ngduI4h2aF+6vMUSNMavG eJVhbei90kc8vYzRe4nBi6RZJ7Lco4XdIpNzIDNlMgGplMmvQipk8lFIuUxuFwkP89EenEwE K6E9hUqLpbkFzd68FEpzPWSSNG8XWTouzRDkkkzNglyUqdmQz2SqBvKpktfoX0mKIQz9i0zt RHh6hkRVWPo+ibA90KxM1sN7f350+gqpo3NQLYmtsqAvSRPJ0d3SjEJ2STMM+VVeuqQpIM/J 1ALITpnaDvmFTJ2CtMvowypeG4nqOM+QiNbHZLISzY/IpIrQIpMxSLNMLoQ8JOvehTwg606p rt+hPRS7m6aIqTP9tkyZaG6cmMi3SFQ3ryMLdeS7ZFItyZ0qSMKgKyYmspwuUwc8upT26Ci2 NONwq5NmBHJHfuW+JFPzIEtkFGtMF8voTqzcookB5qrn8xoNIw0VKCTNPXASMjUXMlumVkAq VU8kVT4xahmp00mVSlN5+aUZEK9TL0npiEUkQtv3iTHEvVSXpV+T4qKdLaRSnI9C9omzyfvE R8ksjrfiDF7jPfvEMFyP18G0veKYeUocTQXF2yY87ErxlrlA/DayUWSjvcJJzhY9SKw7dZ/Y m9IRXo6gmxS7o1lG0bszdY94xpwndkSyKoefwflJNQYC/djcKLZGtojvYSt8N/kP4qs1po3s Ct87Y8+Mx8YePzGYwcbGg8MYQgBDIsA2ftAlrkmANLEpToAsBEKUhvDYJupuQdukZaM01bbq blbb7p9uk1ZKY5fNrkmyCkqirap0tfxopPZPxErtVpWK1KqUqt0Eeu6YhqyUX/3Ta99z7z3n u3Me9zFn5p2T1aLzlO+w87iPKCp2jlX3OEfBkWMwZ3jkmHOw+vvOgYBi8eHqj529AcWHxIji UWdQEbww0uPsAAtAECICsKAF9mU9TK0N3CIxQjU4uvCx8yvNtyl4G+NZqKfDteyH7CvsEHuA jcB7p4r1shVsOWvhTJzA6Tkdx3Mcx3AqjuLga5ay5DdXwjKCG8zCCKRhVISqlL5AEQqE5CYU 5ii0F2XNdIJK9EayzXIiz272ZHfLiSy7/6upHMbfTeNEdukoSgy5suu9njzmu/uyak8EZ00J lDgQsQM4S30nj9GBVB5vkhnnHFlTNLWIMPafu+ggbce5i+k0ss2E7CFT0LinI/YcMrBF4zF5 u9hl+QsjMfvDRG8q+3Mxna0nnU0xncju6HX1pxapE9TxeGyRGidNOrWIR6kT8R7Cx6OxNMBa FBgKUuMAQ0nSAIzqR0ECA37/MzCcA3YsFwwWQPtwjoDg0OxTQH0FUPRZEH0BRxVQlL6ggH5c UFgNdoDCMGkApj6BqhWF1eoTCsxOYDlJgieNSASSq5cAkJPqFXH3tthXEF8riK8RcR7jbXlA KljrQ5KiQaJ8gJH/j2U48j9MwgttMydT8WFPfMATH4Y6kL0wM2rPzg65XLmTM0TgytLSwNDR UdIODmdnPMOx7ElPzJVrSz1HnCLiNk8sh1LxA6lcKjwc+2VbuC3uGYylF7rmdk98Qdf8U127 557zsDnysN1EV9fEc8QTRNxFdE0QXRNEV1e4S9GV6IngxP5UjkORdLS/0C5QWh5Oy4CjIh2x CaeCytFpqbC/4ripQvgq0srprM4TyRZBJaKa9pp2IoIjTUR6YBu2RPZXWiocN/HVLZEAbKMn gqbs8bEY/CehTE1NQ4EYT04WYm0vCKbkuCIHwBT0ppQCSOiTOqlwt+RTaHq7yHIBiyblaCqX TMbtYzEHJPMLJP+W05NIlgsKZRmBTvBaSfhtSsKvZWwND5N/TP4jSS8pmf4y1BUl01+CLH8Z 6gpk+uX0UnA5uBKkl5LLyRXAPlp+tPKIXqpZrlmpoZu3LCCq0hgs3P5Ny5PThC1jxVvFbxhO yZMycfm/MYCRTLgkKlAKfGWeDE+Rn86VtzuTBeG0MqXAnXy6f+FuhZsViBp+4AuLIu9R+B7D 5mkubEZq1T0a8azqHkYlHKO+R9G3cTvSYC8+iOyysN76pLVLWGtNPmlFIegLj4HsqqswVhi9 QOAeR49d9NLjsBp9jlyqJXKRRzYu4w9xAypGzWHjvyjMalT4LvqNqVPHqxJWyALCWtzgNGBD u/3aRdCxlll7sopCq2ur2Lhnz646nDEHmpoCjVWSx80yHrcUaGxqqLdZLczI1BjLsoxOlFsO vfilg2evbVz217/Ta9RwrLE/GHnx3NSlR8SCvs0/4Su4EWmR+z3UyWjpPDaHtS5NnYbSlOi+ Nm+Xu4THmSRRCuqURxfUYNQxOBSPDw7iRqWJx4eUF9Tmp1RIPQ7RawqL8AYJUbSFguSYxpjS 0tdRqRpfp/yq23HizWqXsE4e3Rpq/ba6Vn5ZuA86sAdToY3oLL6jHv/3jPo1RPJ6sPIxfRes LEb1i6gE9mCJydzIdCJW12nSGuhOjf+OFVtL7L/7hFi8lkmukWVYVayWn7Xb/KwPBxXDBwdj W77QdwcLvgw+Of2sV92bn6oPgVeVWFxEts3ZBQ3fWJYvtMxWWwRtOA0dXanG0WROlp63XSi9 5Jgv48aN46YzxjOmeeMV5mrRu8W/Kn7g4BkbkqK29rJZ27ni845vlX2gulXO75RGnS8xM0Uz jvPmmwa2WW80VYqojxIxzmMLBLSv4mdGk159XKT1x60afGSnERtLT0lYMnlPLuJ6RJyPpsIa A+/kKT5ZUrKW/HPGsVDoraa7hMx6JvkHJTCwgf4C+0iAzYSEX++qS/SeydVz0TPhSlsZU6ST ir2chtVQjEMqsvFexJQB0dr1XqQpVXsxnE04MdWyPDeHMxMoM4GVN4DRI8FWZFjGajHZGuqb mq0MxLqSCjSaKhvqixWW+lCV/69vfvO3u0L999+efThz+p/v/n7j+gcPcPrupXf6S1w7WfX4 RnX+/uszbyy+v/Hw8qn56ZfGf4E78ndx/1KwcmcD2REOOKUT6i9DK2NtuL90FgLvIUQgRCbk mHnUfsz71o68T33MOAaDN4xv2n5iZo7qWZeI3G7OJerdnrJag55yBxwOxJlqygyiU6TEIFfH 4v0sZl/2t90o7KcJONeZ1iQJroAkQaKkJLIIljoLbWmCkEKQ35eSdRasjFbTsKeF1VDrqiwX AnuYBHavRxZKTWajmWJ8VTuqqqtoZntEMTZrsdVuLbGqmEqvLEheXE2IpxRIlbmMEBl4stfq 9iJZaC2sgFxNytwcyuAMGTYESIibAsZGWAhPoAJibrJa9BTcDrTRYiMr0NxkFKqkKslR0xIy aGzRPTXUkb//4Mat/tfvvNb2ap9gdjRcSX29p33kBa/XZR2jvzHaWOWNdG/kP7n0tx8dKdWp Nj9/dEDiDaffgq8S9dtn/U44IbUIqX4K6+GHD9Ukq9Lwftqt3atVM2qGh2DRkkriJa2k20d3 8Pu0I/wMf57Xn93xvdobqhv8R6qP+M9Un/Hr6nWe17tEi9sjukSr2y11+/15yhc+XiVKBg5z 3TrdA43IQW7NdlPUA0Zky11ipdvDsaxE6fYVQb4n3fFib2m2FtciXGTQO/WUPigaID+nULC8 XCypsVj9vkrKh326oqJKi17cQxhe5PNWUlaupvY2plAFasMsnCUZhWANhVWhda31P2SXf2wT 5xnH73396/zzzhc7d/7ts3NOnEviJGcnOWyc42eBkhK2USjDDWxdYCBCnLWBgbpSNWyFbd0Y gsCCyoRGNH5MtF2bpbCNdoOWSdVA2x/JpK2L2ohOHaFMC4xpxNnznjMEmy2/9753Z1v3fp/n 83wfN6emclP6AumYZ6cKLIRELqcnFaxvsDf0m2TIqZsUe6fwP0cSCyRXisgNGrW0KnqyxEGV SkXxihmizEPKkavAdaxUr+9b5YjHK05vq+ZBrJlsfbbK77IT4Yy7kq6vbc+dNJZm/tCyd/vM 2nf3lDYRuSSvKyZ0l6Ur7dk/EGBAoyQkzi3QKEId0OpFrTXYbouGcCzmj4a4WCwQDaFY3B4N uWNxzo2hxfAzgUgAB/J2Gyn6wtJ4+4QNNdo0W6/tHZuxCwZs80VFcjEQCKUnRNQrviPiRlET u8S94muwMM/vh/wpFPtI7YJRzyId+CRYCZul/39yLylmgBB9Z/Cthx8YXyFzxg4bIT3ykOX5 /QGYg9KdwOvbwGsnFUZnNWULu6XiqG2MG/ON+8eDY6FPOKtFsIR5LDh4Px+sZqsrqj01fluY YIMng3cO6sxDcCdHmkD+GUJ9chciAzeIjuBj5mP0EcegcxgPO943vW99LzSGxpxObLTQZqvZ xiMe8w7eWRmydvu6g7tMOx39vv7QIDMijITGArdp+5MuV4YyVGYsVs7ui/Ss06nTAbTxUQEW ROjQDMjgT0XbozjKcBEOc8AcEnlFwh6NeeQGrmOqfImASK+BhEGrCYNyKMxKoYQnYZVMCZ9f 8GMz4+Qk2KeAhLw0zHgzzNwOl4ScQQwjqrBVSpTfCIMs5+Bdxo7umID9VLEA5vBN2sypptHZ ac3OqVjgVAd88OjsX99wq47R2ZtwMJGVU7XC6nWnSv3XdD2FHrQPxQKqotysBYvR6oSbpUwQ Bm62jCwuwwJFeCDO4cGrpUOlH1x9FQ2htgubVu1ec2zzknVfembI1OUo9ZR+XypdLt2/dxk5 UQM6tPJXx0t/Kp0afrZZQ76P4Jy9h1SPNNDqFGSCn6qirr1NRWfvveFQo6Oz97QNdnVVAg0K d/m70X/FjLV0kEKOaMgSi6FoyByLO0muxAMNHNUQDJorOAArzYpI/HBj5d7KE5WGygMpqMYB BkUQRvVOysE6cKdjowM7npcSj7DlielC31xRIUV5qqCnBQAEGAO7YWBNObCPIFk4Evf4Bd7H Y3PcI6ZQxA9DzFuVQlE+nKIovRDMlQCy0NMGsgoYU06pjBglnsdiNrhJAc6kgSrJwJINM6ue XhQILC4ANatKP/7+pk9E9+6BgZdwd+nlHjUmSfG2HkMvmV0/PvCLmICPzozgg0cHv0Mc0dbZ CaMIGaYipKlC49rkTtFgdiErY5HNjQLDy/WMzCbdqVhUrqprqW2RNyf3J/fXnk6P1l5IV6gP TM1yzUutZ1oiLbjldFMoFF4fDUWiERQZRbu0peH1lJ/1Y/9pb1Jm6ARjZ5igPcgY+5n+5BBz yv6W/TJjlpOM3Rg3ZZoM8YzXugp1oR3oBfQ9ZEJry4V6FFoRF+fPanZnOsvQERrTcOrNSFOD b94oUl+fy7XJKcgnGfxoYbJQNki8CrYGkK6qFHuzMD1VmDNLZK5PmxqJ8SmgirLr8Xr4yvLb 6zGCw6zWrVDcrVTObXuiugHrDp3Xz7Qafm1Phj4e6N7pDWmpM7c+/7nSPz/Q+p5sjPjncZJU 9++DvfuULQNvn1x7662F+dS3Av6wE6xR7sy17Y/Vx1MN4hee27Llm2fu+Ks8NUlMjX+8e3Xj +tULvrj31a6Tk6xjQXQ+ifUNs/8wfGj4DdVE5XBW85pZVjVGWbVZyy1OfztzyDKUMeQJwjc9 nhlR0Tcsw/Xncj+vf69+XByrH8/cqLdmLEssKypW8Msz6/hu+jA1lDmFRtAI7VAsaG/+mPGH 9cebjFS+M//lyo35Pv6I9zw6Ne8Smsjb6MrO/LNZwzIaezkvzpJ/ucyrn2VRs0JDIyLX1ch1 klyXzClnlYuKwajMVzqU55XvKieUnyq/VH6n/FmZUuy9ClKyHlqkv0I/RxsxnaVX0rvp/fQJ epi+Sv+RttrpAN1LGzwcbRCciYgMv5jsTmWX4eZBqpBKYUFLymlGiAhdwg7hhHBeuCRY/iLc FO4LBkHQXGxawBELtjN1kbpUXXudsW5xchEjRSQsfUpRKWu79QXrJasxCgdMWVlojEbRRY3V 8nvzWMtvzOP8T6D1CJCnq+msaZ8NoIBMtbKtuLXZpMWl9A4oRbjRpJk6TRtNRpNvftsaYRQ1 7Sv7SrljqjhdlN8tsIXidAGQAKbiLonAdk6VU3CdzUGjBLZjZnqSLcdkH0cG8O96cLK/pdmc K5ejCjLq04HR3DYvGLexBiMDpBcle0JNuMLuMOWIWsNQ4ucZWsMUG3SGkS0GQ5sxGyYQAYqw uTkUvwgv1FcsUPBBRZkqwjlprmmSSCCTCk3C/UErRdpOWOrsaW7lietPVLvN5buUZrz87Mud W0dRhtdqFtT6g4nl2fY1fR/07BviXTaP0x8IN29b3Lne9vVsteirbz4w+NVV286+8vTW1mSI E7wRuaZpyUpl2UtLiwtrB0uHNZGVhBWLHj+M1MdWt7Q2xANApCdmJw1dEOdx6u/a9jtmVGVF T1mHw1fwlfg4+hR9hC02GtXhWs/aSLd1c6Tf2m/rCw9WnKs45xnFFzwj4QvxK+FrkptC3grK 4ApepyYge66jCYSNyAM0Fyu8gk+4DR3X34SE3SIuM9oZF3LJCJT/WbOvHelGyOpOMwj9CL0G 3/Cflz6DKGKCkSAONlvm7iPHkRo5fR1cLPmK1eFKW3xVba/oHJLBxndM6aUdxJc7Jvt0GE0V 2Rwo7gblVQIlXiU9m15+QShJ33BgSyvRoSxKtc4fIoDu+lsMWmThlR0XJ7r3jB88u6Qt22E1 /4fs6o9t4rrj9+7s86+z73znn/lxZ58vdhz7fE5yjkns2I+EpC6EQMWgNMUd45fawsrCRili WwtdW7pOCxua+gebSLdJTJMmIsKY6f5IpqnVmCYRNomx8gdIQ9WoBAOtrSZ1Cfu+symrZune 992787Pf530/38/nhcNKXjW/9HhxXe/W+5FvHkZt7y/84OwPpwbXTO6qRqP9609/534pkyNV ZAOgWwd0g1QMFfBWVlwXqAf2B54N7o4cDji63Gfo9+lL/iv0Feaa91rwX8y/ve6Xg0jFUtDc wuxh9quHmJfVV5nXfR95/xF09TgfhJDT5cpQTsEZczLOuj0WotB4qIG6z7cnJYe9geR5zuMK EYA8AFoIR1Uz9BxFsINbYmcJnB6fSVnm1F+g2gy1qn5Z/adqU2PppgD3CS3MrSiLzZjMmyRi DoBfEpAQjbewt05QIMm3CPqZDOEmWB4L/4+Xy4SI9VtIuDTdlGW/3NnVlOUOUZGptkBIRrK/ XUbhIDQtWSYWKUM2aRrFm/vQJEcKSCPCXjnMh9sUZOrLD1xTY18p71ilTjQOL+3dsvzL71+5 m+gKJsx4CX3y7r5No0+GTh2dPbrwEQre/uk7Lyli/1OnEgDFCEUxI6DGOsrgbdhArKRoNM9S DoUVHLaeDIVQ2i94OU6kvL6MwHOa4nhPRZrCvpcgJr/azpyFstWXPBZEuu/VLLwC1HUbOOyr 8oZi3DAYIxxuQxECWz7abkbktIohqifSxgc3dKRfpah0C/QebolH/NUl4MZVr1dMcwRzmIhE bKT7zBi3xNFQjbg89wp3gpvlWGKTtlvdJe4e5+CiMSNv0Dnjj/F30S7EErs0PWkdIIAQZeHW 9K1pKJNW70Ph08zHv4PdG9u95kOAmpioMviqMnCGEEiA0iiUyw4SWy2qE+EG3fZDbSqCU6rQ BX+i0F9ImY/oQ7hUMC0JD4aD/UF0IxDbsvy3aiFw/Dj6y/kjh9YOm8OsjRPCnSn6u8zY8qFn Il2MpqH2/AT95o4x48TitlX6yEDc1eHng24+Xzh7aAdsE7V+ZZy5DkzKU8PUBPo5fqJL8PDV bNcbruP6yfSvbRdd59IXcve0T9a43f2uAjvIlmKTdmdXpCvtSiurlJryPedrPadcZ/Qzox5c 00bi3nREoJghhxaopL0GZ6l5GyR7BYuDFZxMmRXwkNAEI2a+gsjjeTFiVhqMDQcDAULRQGfx bY7rNGgGG70m02A6MAcZ3Pu24RhLdvI1i2pilUTshn8bq6FaLTLUeLCEg8Au7xAa6osccNDo gOJABqlrDIvT2RE4DVSh4avGCOJHlBF6pBYXyKBgDQqIFxSBFhqMHQeSZh6mok3Em4pJmzie zGTJ7ykwmsXdaTNLxJTP7s/OZJmN2aUsnT20HqQ0I1iFMnOrTPZbuFMHFrfa5fr0fyBH7ljD mUyTyOXlTNlPbDbR1zsZi/MZIqRwoVYkl3/QyhIQwQyCI6nl6izmEqMX6i/2hZumGnKFCGCx 2SQtf+dovtNnZRDTLMKtuyT9E1Sa75Ui+xfWsgf04WLlV3/eMP3s5qO/+PbS1Ngzx57/+usv 3Zyrrx3auGGgvFGPHdwTH3zxZ2+d5tu/yvz4hd7ugdKuk5vspbSWo3P4tc1vxXt7n8znHo/i A2PH8r2zz715qXKw8aP9L5yeX53/7L5fKfRvWjsa9csh4trH4dyzCs49WXTjIsU+uHfOM5iz WLmuYNrHaXpjbilHO+x2NsQmWRvvpVQqq3gFVciy4lnfgo9uR5SkKb4GfR371ZSmqAnVpSne RKJDU+IN+gO8M9GtKdlEArXDV6nIHptDjcd9Pq/bqbiQqycg4fjqqoTHHjMlPFyQ8Chcg0Nw k++FJtUNTUaHRtWggayVsOA3L0uIl1BMuizRgoQkYr/ExRxScnM52sh9jSBRKZCFzMNUVoTZ rAgTWhFmsmI2Z0Xsg6TPUU1h7ulOWUPwx+6lkJFaTC2lGDI0XxwyrQicsCL8KetVV2fcTEX1 yaNNxYYPZJ51lhNaBgpKFZg5Uq8+/5ThMVQnUBEoTVUi5tYwQ0oSqo9u23qRihNmeqpx6zcC XNWHobHupJAX7qCI+nCUh6ZdqPpg/Fw8UH04/1OkrKH6AcjZDKSs37JkliMLQ4kbKLYOg3Ai IWXvf8ZSBfT79a+Mbf1Wunt4JdkXFcVMe/dElpdKK8lS1J+q2CeW//7E6K43ZldO7i04NM0R b9uN3vlGKV4cW/HsiqpOTWNjob3MhedNZxd4hR4wDAn7PspDdVDXcUh+xR+u8n5KpDoUvyAK HWxYU8QGunte9WqKn3QSEU3p+C26C+aNhdX6zQHzLItYTCGugxX9bhfBoANGm/4bM2mO472K l/b2RMIYpg8TMIYKJMzHEqYVpbAVsaHnzbkwmgkjKiyE6fARLG+UaUXeLs/Kc7LNkKvyDHQW 5Zsy2zm5CAUFNu7TulVUmtsGBrylLNU7Vr2woM6gR1oxIH0RZ8A0uXrqaYynpv6UG11xVORA bsS+zxrA+OmV0nL7zqJN02g1vJNWodsF7MwAbhqwU6BgsSJBbbuI5kTE2ymWEhS7AGc31gOi bWEH6m23sAMxF6CDQwn4Jmt3Uw9l2EOQ8TSRIWFeN01PCyEScQIgmvOgGQ+iPIKH9hxRxFlx TmQMsSrOiIviTdEukvd7TZPEC3rO9FsAkQT/AkIWOA+BgXH0f3DMP4Jh4rMXP18884cdZPGw +gmKYg+CLo7Tk1h5jEaiqGC3XHTyElWmxhUJiDPOooFiVFPAsP/1vKprSjd0cEBdrSnlhMpr ipRI4BRSNSXVoK/9JoFLqKgpJejjnsSIpownEg5VH4g7kE0u9+2xyXvcbpuDGmfLpe5UQHLX MGiNJXKbZdWkarO1udpizVYD6+PjeYWn+Z62KJStKKlRp6ML0ctRBkdnonT0dlztyenwSLce 6Qv6ZZ3B+oxO67cpvqjAYfC/hJd/bBtnGcfvPdt3ju/su1zOv+07n8++i3N1HbfnNqEJPpNu SRvyAyihWQlpmcqAFUi6IdEWcMYKAzStpWxFVYU2lYmpk1BHva5hQiJSRcf4ZxEbnQZ/UEEQ g9USsKoCpLk873uXtlAkquoe3+W51757n+f7+T59H2gQMGfz9t7G1Qb9TOOFxkrDV4HDasPX SI6OLdMfaWlYVCzX6xBFIXAbem89zg1NYqOziGk2hP/hFz8B42EbzwSYX3gT8P/b2kLsaqFS TWe5cIDpNzJGNbBRQQyb5VIK4sMVZpOC0rzimlYYAskciGdAaseuQ46k5oJduaBiBtQuzaRy WpBFWMVAZR55ZGS3U9g7dnWMZvgCb/PO2BUuMBWYCk52TXErY4EBeoqZ4v/F+LHfWjw4S2Ru DEoqliUvuiVG68zyzX+0QOhIBPkDn/jXW7E77F6HSM4Fzj0XvL+L3n0Q8fmPuUHqtuSCAZ+F L4660+n/F0TsA73hlr2rgF+deHTyvsPa9Hen9z1UNt/fyQ6mJdnKWrvL3fFGJ2OWBbmS7tUq NfibQnTT99yRXSO7Zu6bnv3Wyc4jB2zQyYCZ3odOfGW7Vq93QvtTRdwFevXD6ETTKUTV8U7o /jpD1PQALRI1dZm9FfrCov2Y2W9f4Aa7GFTGtTQwXpsuowDwusj43qKv+H6d8kWZGpDcdwX9 Lk1LQoTSKEuNiJponRN+JgRROiMXVMHltwHM1vMh4Dnhdw7zO6oD1S1d13I5QYiEkp8K+Pxs ehnNt1YRggn3gjOTqKFDFGUxIUL0aFTGSJeh9gUZ5eTXZFrGeJcB7TJGu+zUtsABiCzj3pAx 5GXMdxnzXcZ8F2UkY6gLavmFMl0pL0DbANHLHtFJhEXKHtnLHsnLHuHLHuHJOxGA7OWMQKkY RKZp3EK7gSrGirFq+AwP7YaHdsNFesE2khtuI50QXbwD6XDFHRDXz6AdRY/p161FQPpQ28X7 XVzPuVzPrXNdwFzPrXNdIFMW5rqAuS78N9fBhh7E8+PcQRgkrfVq/h+FfHfNXho7+sE9X5JF KEmzFhclKzWz06x1TK88D02O7h8fPNN58gDBejF5P3rmoSHtSIf7zAD7H2UIL3PnzTXfRajD MKWhXU7ilRQyeSR9LBgxwohi4wbbFeSyjp+8b5BRv2NYtuBH/pSOH2i8RsKoG+oktAaHbRyd Qq9lr+irOk3pjr5Xxx8Djv60TuuCpEq05KxyiIAL1iURlsbxJT5ic8k8rLH0olkbWMTK6W7e RHtuUlz3XzdgqybalLtBQ20ih9uRJhbpoqrkFJqRe6I9NMMY6Uwqk8z4GCEsmfCUWQXFuiSF SrBZE3XzERMpvoiCekJxhcoE4iblaYxl9Vl9faCYIIbVXjSIdqAd4iE+sMA0+aa4kFxijvHH xKXkL+jLaqjJLoQXhGbiGLsUXhKOJYJojppbnIU5A2F1kvFAQddsKZ5nYGqIx2Bu2AobivfT QJ3Dv/rc/sNvvr7259c274hHuLGNZcUMy0Yx5bv01be//co3zqDeS68ia3TiD798cG50ZzI/ PI+055vZKN5Bs7PTD4lg6ivoYScpVYICQ7FUt8qIrNjN9FR08FsFlcVmgsP+gvm57jk0J62X j8bZbgncGFM0VI5hI2IJlZx0Sqq6+4tDa9uwjaPTD104XV2t0v1VpzpdXaj6q5JnS8ISzJb9 vMNP8yv8Kh/gk/2Ti+4UR5qFh2WSGlbzlVYiR+L5uIrbYZbgT5zDu0pSq25q1Uut3pF6AyoA m5K269pwQ0ZEzEsPhzljQ0JJFi0ja5jFDYmSiQwFDn2psol6M0WToryttVzIbSs49VFbx4dm oqk0jeYG/8NyM7mQ/bK+YDatr8uP6yfl7yVOKafypws/lM/mny+8JP+0IG2PIgr2FqZIa7YI DRrbfGeHalH4SLDkzpaGSfYbD4rQz+hcvP/e994hrgl9s7p5x8wDZ3fv+dFnJ0Y2bZ355Bbd HjSc/Y35zrNjdqJYpLX4Xt9vsZc8MparfO2PR59450g+9ezhwV3X/j677QT2WOMU5fs8VEAJ mU6IM7hBTuZFt6VAkCH+qZVWbcvzfBCXzqs1cppV3MuCSKJjyjFbtNBJ7rhFc8lwty1kKYUq qVlREUsMisbicSp/RlWIVY1fVrPEquoFtYSrKauHNgmOMgSKl9laFx7AkKFKjJINCXNU6GU0 T/nR/MXj7Cp7lfVBPb7scFRJiKvg3vv0vFtveUID2yYxnSPRkaWYvZJHC3lE5cU8nf9N3+RH SW25XhUK6Pr1uXZbXHPdPKiBZeHiYElx4NqA0cnztWCxrHW5dX2+6VoDJhqN484kWos30jSI QZh7vDEw0thYm2RD4WyqFM0hlq8MdNhhKxgy+n3PvfGd+XvqIzu3+5lYvr7vi28ODIrppA9M weBhOjAdy6QCmPcfurlGvwF7tIl+zPk41x8V634xXJLFbMnPyDH5cvGy8Zb4F/GfIlsSi30D 4pa+x7in9KcKZ7kf6MvcizoX4APhYCnKj3LjPONwDk9Lm1TqNK0ihLmDHE6qP41hju5xeqjT UgUu2JV3rYSaPJ1WUyksrJByPIVSy+hBR0+ejr0rSQHDYiXFkDivjx0paqM9EqWJGk1GVI4T bPcsj0dTZyOItRpBkZRgo4o9Zc/bX7Cb9jmbsSUhqAbpoAM3uJ/yqVIv/la4Q+hFvQSTIO29 yc1Y07GkL1oTazB6YYW4EMwBJYM4KQ43BB1ZqweHojocYkU4hZ/ugRMT4MZBkH7vRi0Hjw+/ 9arTBSton4C78S9vwQIkwhokwjI4nr+1kjW7RlZwksjpTcAbzHTDQUzDIRKHQzjmJs5S9Tb+ IkVRhLqyfPP3LV52I2TgeB7SSSLJ+wkVAD8lQW5AgcSAAlkBeT1FvIanTiS2r7cp8RoWPEeo OKHuesXpEuAAz4LTcJKbhb+5WIafBn282nIjPCr4imIZHAacve50wYdiGUxHcfnm31qglRDX LmKZzYCQ3rbOs9QitALWLRAu1KMTn4xx5L+lVNAKum8z5hPIFbSGadRsaJU4vrCVflLIDz/a KL1PziFjbvKJmZEFhdNimpgvf//e/uGhT58q/5v9ao+Nozjj38zsrW9v77G7t763d9dx7o7k zneuc07s1O0tSTAJTmwnBINBThM5ThNw3jiQQEoFRmmANkilEaX9I60qkPijFCdyT0VVEyl9 pKpUVKkqqhC1RAoUlJRSB0LN+frN3jmBgprSSkiVbla/mW9mZ2dnv/nt91jxra+vvTGuaqEI OzN35hvbly2MRxf98tHBvuMDi+V2MjAx8fnFbT033tm5YWTsuWQggM4JUpW/0+NCGaLwpO0/ Jh/zUqeSvRAtkSk8HkHXWeNDlIiW3CbbMpP3SaN+mbIS8dtNLnnKG4sTQYCAy3RR1+JgqPGg rgdtVH6Q80nB3CwfPB18MciC0Ri3HMg9VC8GgjNOrIfBXZ+CrgW7UCyfHy5iYsZDvpluopzD zHcv7CXqksYWx863LwtXjUaH2oJ2YhkpvfJKIKVcv9xYPzV0n+o59JXnVwjluWdHyj9bn28a CZ0e+cKC4+T9lqGzB7mtDmK8dZE9AwkyYcc0CpRooBGhzRgKD0UGjB97p423jQaD22hfh8G3 n0qYhWKoPzQosga/22wQwiQcj5hhEBWRisRliiGl0QyVKkftOwOQsOKJRE9A0QMBhQBsCvhR 8if8BARRsZAiCv9d2hRboUo8HIgrAT9xJdDsNTSIYgLk+HvKwbaAHRgIsMCw/01i4yOOgbHI CUK5kfgtYWSA7+xkd3/B2WG8JV0wbF+goBibjRPGtCEoBvkRfgdtQk/BTjafQZ1nqnHbzF7U fDk6MzwTueBYax5a13LcLryF4pFcxn9YOXvElYs4QiYCygWinK7Wwx9t8HhwaR6Q240G36zB N0sVNVEkvEKjNT2pdzlNI28uT8qBIpn/IVyEcxwdNnoA/BGCQYf12BfFBkLemvt5lxVuJX/L q5HsU/d1tHaR9mxn59yvEvT3D7XEpGRSDRnJbXPfI/kHl5ppmkyKSyfKC/g5q5Xzrkk85yy9 9ZQGKsnim+1nNL0ADAQ5JIcVUJgiNOT1fCgfLurFUDHcr/eH+sO3uW7TBo2drm2erfJ27a7Q XeGtxjbzgHJIOxy6P7zfOGjdmz6WezLzkvgGvOZ/M3sZLnkuye/6Z7Mp0SPKol9QXKpg2LmB 3OacRAjVNDUYBI8imx4MjsyIkCbpzHVmGiRFopLgNqVw0MKdBUNmOGUlzZRdqhw4qTKKucx+ e4cJWSuTzfaYlm6aVhAkEE0Km0wDu4bAJEbYJlXRVVVB/wG0R9VQ1hSBUUHKGkGNgKjKFnnL mrWolUmbGcvEUVURiCebTkXCHknMMgpyjnM+25Fz8rjOgtNazU5rR6KxQs6W/QXAb6LP5Ugu HI6lxy2zRFqn7M3qHpWqL5BWsEDC2Y3c40gPSBWJtUm2NCAxKdqaK9FBh4klkn0YM4oZjAdi 0XXl4VikHIuWI303jK56bbiaWvCkgocRWK5Qcy9KKpJzXS7jRlK6jiA79/o/LjmMzcQ+zNnM J1K3Wh9R3N3ubm5khocxEXT8h1GZPoleSildaS+jh+gKufWuMILMU5e1sHn2VsnrRCycux+j MjtfgdnC+53p6BLyUttC6+iEx2jNkz91Gk0T98ZSy0hjbmlm7h8J+sPyBvr0d/KWP5lMaOot c98kOyO9i9zJJIuGQ73YHVgdSy8UkOkd95ejnOmYhLAxZLpG/oxeGliI/YXNMsFXqrxhSy3J ArNiTQXeO2lYvH3bXhuNF5bTm+h29gAb9z5CH2PHfbPsss/Ty3q8q3x3sEHvC+zXrIEq+Pi4 9x1K8+68ZKmWNuj9g/d173tet0wFb5zqXkHj9OhSPUW3pGoqvt7r07b67vZN+J7w/cB3yvcL 33nfuz7Jt4kynVJGCfOB5NVl6iesR5ZKLGX7ZA9oCiakGvGIGh+5ztcDdAqIR7eRSqATnXNP R87J7ilJ8txB2Li8SMuA4170LrDx9ylCBehuVEiJJid944Tf83AmYlAWDeol0lszhH0zGPeU Of8yMzPc6SgX+hTOPoyHkHnohy5cLGpd+WGl+6JyAcnHCcg5qHHTuM+hiA+pgXGFj1ME/Ry2 P+FUcfpKY7UNOOPTk/7gfOh05PBZvpZyTjkHGYwEePxM9jlxMRl21mX4HMYhXn5MEppPGsEK V7n4fLiLR84kM9Tc3EEwbBAbWtTmRsLDgiVs5Qe/o/T4lo2FRAsLzlH79LOZRIhtbFk3QpT4 B6d2YZpSK2P/Ay5WQb6IeOI/B9WvDfY0gGtpFeIfr6Lh7CdDOg8gp67C++J/h0CpCjVUhXYK QN8MEHoZILoCIHboKuL3AhiPAzRHABbg3ha+XEXqqwCLvguw+GtVZPcA5G+/is89WEcdddRR Rx111FFHHXXUUUcdddRRRx3/HwAKBHjRgXGJxBAiXLOwD8kBULWrvaZ5IZWGRQBZR25fArD0 Iwusgh5Yveam3rUA/QPrN9wMtwzeCkO3Awxf++WfRRHgBNYLwEKJYp2FPCx3dr0GBuBm2AIj sAP2wN1wDxyqVHAun5PDOSudOf21OaMwBvvgAJ9TefXfX7WTuFZh15zhhm21tRhEsSa1L4ri VZVFlNr5iQsSjrRDb02m4IfDNZnh+KM1WUD5pzVZRPmvq/tWr1u5JrNxx87R/X2j92zYvXPL ruyK3WNbP/0NWA19iHWouDWQgY2o1p2otv04OorK3QC7sb8FdqF6V6A8BltxbBS+DOMob0Hl fvrnP4snuKZdCrwD3TjZhZpVkEHXAzQ8gmxh2EelksfxjltAiffmW9hG8X8iV8q/Hm8RC9jI t0Nuvsxv3B1sf+2U6befWvh6PvClQPcld9TtzP7+qx09vJ3snRZnj5YfU25wd2CXn7uz8j8H AIJoyZYKZW5kc3RyZWFtDWVuZG9iag0xNDQgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgL0xlbmd0aCAzMTY5MCAvTGVuZ3RoMSA0ODkwOCA+PiANc3RyZWFtDQpIiVxVCXSOVxp+ 3nu/7/9Jal+SYuRPfllIIolaY0slf4RYYhfTkj8iiSX8CMVoUbUcsbTGeg7KOGm0OvzRobZq OHSqqvZ11DKlliljVI05+O88yXTmtPM95/vOe+997/c+973vfS4EQA3MhkZW3wEJrXIzhz4B DrzD3j4ji7y+8st5C4F9iYAcHjm12PVj78tzOHYFcB7O9xUUtZtSlgBU2wjYkwvGTc9v2vmA F0haDEwZXjjKm/dl0F/pfuAsP20L2VGveZ1SoGZ9tpsVFhVP++fKpO1stwfqJ4+bMNKr2ix7 DHzwA9tpRd5pvuBi+T3n59HfNd5bNCr6aN/VwGecL1m+CZOLyZvP/seV475Jo3yn82NpRxQD tULtpWTVC2F8m+gVaAyYG3xv8r0T6Gme22PhDowx13U9zv7jzy8QiVV4H83wUJJwCBXoiQ/w KrKwAt1xAttRE9PlGCy4kYYtiJQwKKQjRGysxSW8hkm4heuIQSauSl3+xwMfGqKDuctvJhaa PfQKQiq2Ya+MkwFIoJ2h4iSWkZeZCoQgxhw3F9laj1vSzJQjg9b3qINozMJ7qIsx+Mo8r8wg clEmM+UuwpGDEqu1tciMRUfsxDnJpNUb0+2L1XdiHGdtlhCpMNfMbRywBKP4p7exkIx3oEK1 1Kn2RrgQhc7oAy9Hf4dLUk+SdIqJNt3MWvaW4ZGKVV9oJ3nEogdGYAk2MRvncRM/SbC0kfWy lTglD+yL5JaJKZjBulrP7JXhY+yRJElSISqE2QpBcwzi2DKUMv4nOCmZki0VclCX2omBrqa+ aWBuG4MWGEqG7+MgYzyWRPowgo7QxVZTq9hu9WIOV5iHdTiJU+RxlXn/CU+lBXFDvaVmmSFm i7lFLtUQhvboh2GYgKl4A3/grh7CYfxDnqnq9DxhHbFn2A/NcuY2Ct3IvS+9B/DfJdylHdhN nOcq64iLq2gvfaS/FMgyWSW75ZJcUg4Vriaqe9qvj+krVlvbNsn8U0M0ZVw3hqCQO/AWs72c 692CIzgqDSRK4rmi85z/RHVUacRmdUJd1fP0Muu5PT9wPfC3wDOzCE5WWXfmYQo+Yhb+Lg3J obmMkcnyHZm/q/6ka+ra2q3b6Ff1QJ2tF+oV+kv9jTXJ2mpdtnvYXnur0xsYHzhlMk3lqRY4 yCsacWiNdqyffFbTWPLzEZMwE3OwCEtZL8uxEVu57s9xFOfwLX7gDkDCyXk0oxex6ubJUmKt fCwH5YgclRvypBIqgohRbVVXlarSVYGaR6xQJ9V5dUc30SP1LD2b2KB36UsWLMsydisiwy6x yxzHnDHODGduta+f33/R4kX2i6sBBBoFfhtYFTgYuG0Gm+nkH4l4tCTTBWS5ljVYSnzEStyF L/A1LlRxfSRKbFZ8qLhZDXHcta7SXXoQvaUfMYgYIsMIr+RKITFLZsvbMlfekSWysgpruLZS +VB2EZ/KXuKcXJPv5Z48UixipVnNkSpaJagOXGmq6q76qv5EgZpA+NQkNZU7VKY+UXvUeV1P R+p47dUT9Vq9TR/SZ/W/LGXFWQlWJ2uwVWDNtU5Yp6yL1jM7zPbYhfYG+5CjsaO1Y5BjjGON Y7vjjuO50+HMcuY6ZzrPOk21SKrVn7nunfjlk+A4IZPt+tY0dY3nIlT77AUyiBlzqIF6nF6q T9v58lC75LIs0qP1WLNZp6uneoIMVp9LhA6zk3U+FsPIVnVDPVa3rQYyUN2VGOs9+VRN0KnK URnEPmM1sObadwB1AcnqTalQR/RcPdd8hmR7g1yzN6hTcFnXVT1c46leoKjY+EaNViUYarW2 n2E08/6hPY357qIWSgt91tqAW9qtfpSHsoqqcVx6Ws3UcNVBtlJxX0hT3JeJ8MlKpMg++VZ2 Q2SLLpNe6iXull/VkHa8xo7rcDmrg5BdyVGiVAPJUg/VIL3fcVK3EaFKnMYM0ZLI2vnvE8B4 noAVKpqa5qGanJFWCMVq6v3jwP5KxbYv2iWss006Dv2RiNfVMSTzbNwihmI+WmEva3AhEtUa zDSzJY+635v6qbBbxiBBgqmWIeQ2i/dFQxVBLRzBqE+p/19R9TPlAd4QF09WBWKsypHFlofK lEP9LSHy8Dpb67DcsdM+g74SAliuwAZW+RUM553zHeM3QifyG4ZNVhxZu6jMEzljXSADKcR8 HBOFN8m5C895lpVB5V1lxnCFo3lH9eKdeBSjzWqkcu/6m7mmBCPMJvMaCjDAbKH+TjU70BYL 7Gw12I61WlNjj8ph3kd/kRLqdgYuU48iJRT3iG1k1MXeh0XWBWpnV7PYnEMD5iOCGcrlLXoT RXjAvGXoCrwS6KPKTbr28Ya6hn6mzIRJEArNOCrvfpQ6bWrPbDS1S1NSUrp26dypY3KH9u3a tmn9SqukxISW8XGxLZrHREdFNnNHhLvCmv6mSeNGL4eGNKxfr26d2rVq1ngpOKh6NafDtrQS xHnc6Tkuf1SO34pyZ2TEV7bdXnZ4f9GR43exK/3XPn5XTpWb69eeKfTM/z/PlP94pvzPU2q7 OqFTfJzL43b5j6e5XbtlWL+htJekubNd/vtVdu8q+90quwbt8HBOcHlCC9NcfslxefzpUwsX eXLS+Lvy4KBUd+qooPg4lAcF0wym5Q9x+8olpItUGSrEk1yuUK0GSfkbudM8/pfdaZUM/DrS 483zZ/Ub6klrHB6eHR/nl9SR7lw/3N38tWKrXJBaFcb/b9arBTaq44re9+bt2w2x8dr8bUN2 vayRf5hPbVhTYBN7NwbTEH8wu67TrsFEGDcJFZ+UNgpGiaF5QBvSNiKIIITaFOE2PANpTSsh owqhtAJaVQbl0zYloS1tAhGCShDVr+fO27esF1JoVctn78zc+dy5c+7ceXqt6ZbL+Lp4N7Td 118+aOwY8NKKRFlWZ6Czoz1mio44r5FbhnXrzAnf/Gji7Somz6uNbUvXFggjMrHLx1XD2OYz 9zfG0rV+/o3HMYepBqMJI4qFd8CFDc0+rKX2xmOm0osFfbwP3pO9u1WBCLck1vjMBwKPBFYb axI4mHzDpKZN/iP5+eHj1geUH/EZLbGA31xYEIh31BX2jyWjadPRSWHfpJGaivJ+b67t1v7R OclCVnZ6YVVKJ0uyO5camlJ+VdiiwCLQwfSt9MGSWAB7mss/q+aSsXIuuuEvrmCU2Ynz6DIf qE0Y3hq0e3m86Qp6Az7jBuH8A598PLKlI9miB703iIvMkhTRoHfKZlmZWVrKBHHX4kRh4wJZ r6oo3zigmoG1Xh8E3EePw7cd8ZpKON/v5+PdPhCmFaiYPY0xu+6jFQVHKFxZFjfVBGsGHc24 ZazpcTSp4YkAeHyM+MtinOkpTv3neMePiayuMZXx/0G9ytY3NAcaGttivoiRSPq2oWVEzdbP TemSJcVWwOGmFoSnFgVAvaa2GDfg3xWMBiJdiXqEGmw0x9TGRIEat0tqgZBTgb/tqZm5Esvi ubSgLvnfOeD2gMCyRfFFTW+i3v6Nj/L773PQgPUpj5Li9rDknsyaspH1eSPqI8zLMgQM1orV hpY2wxg1QhfFZWUY0YAvaiSMjgGrZ0XA5w0Yx0VMxIy1kYRz/APWL7YXmNEdcWxitVJTwW9E cvuHI7TcS5+tH27y1sjDSvtzZeshpZBLqgO8TkUd9Wr4fgK+ph+iej2EDPd1aoSuBZiO9l3a CxRE/6dRb4bcpYZIoH0x8ClQDjQDPmAFEAOWAM8BjehrAt/hORyIndTu/gp1uE6T19VKRcBi lAPah1SqrSM/yvVcx3qzxWQqRbkIuhL3ZPQ9bV1iPfoVyX6tGLeOeqBfgPqDQJ57JxVA5gBj 0J6PeQ6yzZAN4iTv1bqK8kbYsQjlzyCjsLUOcgnal6I8H8jGmC+qIWslyrkoz4dvclHOAiIY d5PHoH82bOyEfizqKvfFutmQBdwXc5aIC0qBsgfvkQvUr7XQWOhHS2DfvGdnT2w/2/Q5iLJ9 6bDtk2Bb1du23QE1A6vEbHlWW5J73aueobViv3UN5YA+liIM9wWagv19DIS0Tprknmz9DTYu ch2jKtQ9wEQJnnMvbRXXKQxdmf4qeNNJC9SZUFRZt9Rv0WQ9SI9iv/A3TYPtceYeuDAV/Zrl +E6aol2ifJTDDA/RX1J+gm9w9g2QtfD7FQ9Zn2COWgbmOQ6cxPgJWL+SfcDnrrQO96HvZeie BdaBI5OACdBvlxzGGB6PdR7mNexzIK/kIMDcA2Y5SJ6PgwcdSP8fkhgPTADmALzuq8AvgceA 73MfzDse/afAjueZM8xN5gdzQ/IffJKc5XNcB98wx+yY+ZH6JH0bGAuU40G/NYlS9JXxwufI NnMs8NzMLeaMI6EvtnmvXOV9MqfSZMBVLteWMcjcSpMlzH2WIiz3UKIOUjVz1va1I6UNEY5H jglHOvZwfMoYgRTdNIZ9x+fuSMcXKbmfgtAtcb1Dj2ozabk4Bf63o/w45Bz4Z5+MwavaD+gj tZdU9yCV4yw5dl/LkLsZ7iFlDeYbhC+LtTP0mpRDapE2pLhcfdZlV5/6vA2nnC4zoQzaOpaM dN1/2/6/QD3v6qMnUf67a8iytCF6BXsl9z+UGYDPkWg/AvQApZ4yZbenWxlwLyMveHMdeEYL 49svTHO0QVqojZNxF0T7MsxdqXXTPIwT+Mp5SSyjA3offUEM4RyxlnqeXmDw/JBrUzzK5Nyd XJLS4etdJMdAtiNlTIWsP8q4Cll/kjEZsoZtSSHODXw/y/xA8m7Odfia4uXrVCxupPEzg6dp /JyHcd5MXqbJ0SyTuSXbiVOMGc+5hvcv78dWGU/ynoPuiNM/U6bGH6IB9ZD1nryHz1CbE9fA TCAI/a+S9wjuYZw358ydVrv+rNUuFlvt2OfP9G2Q16yj6jSrP5VTgzQreZflO7mU/eQ6Q4Wp PBqkpcn7LMj5VDuIHG7n0TEyf/6VJrquybttlrSX45BjsBL33jTk8X9at7Q8elq8RCQQl9wO jjSyTvPQOPFn3LmLab3YZ/1e7JJ3UEQMU1yUIYYxFj6b6FKp0FVHDRhDcj7uA8ltbL+ugZ98 F9SjjrNy7mU+e/0WZQPTXFdwH7WizyG516C8x3fTVPaDHLsBeQVzucsoT1OpLNknKMc8hfeC 9AfuwDRfJHPzAp5Tb5KczZFjZlu3PHkUYrjeoGqsH5Rr1VONJ0TFrlbrinxX5NFj4jTNEPX0 EMr5kvfbkKNKkC/rkR8B8SEwDG567brM1VJaN2W+3yzzeZarkpbL9wTrdJqil9B0hhaALkEV 4g3M8wx4dQvlNy1Lvg/+QLm8NtqjyfcJvxNUGS+/w7i3qYJjjG2Q+Ybt2QO+naOHOCe6D8CH ozgGFQX+LkzmwTzUVcjvpuHlZFuhLRW/+g61Sl0LfaCeUA+rJ6xufgeKd+mr4oc4v8PkF23I 36eQG+chhy+Gr35LMXEW5SK07wM24u23nnK0HOoUF9FvFnRrMe4M5jgAPWMrxrwP+SbNF7+m LjGI98FFfiOQX9sA+QRQR7XKT6hbvUndejVy8jzrdTk/Y731ZYkDyJsXk2OTkLY6uJvNm/C2 u4u90tZ0O9nGu9jHc/C8chz6aBrlEFnvA0FbDjeqO6kP2K++i75fok3KQTzz91JUuQTsTeKn VC9lP9CIGKtSngOma1X0c2ALyuWQJ4DDdp32AO8BvZj7JORRHZ8KDPUR8BkSbfuA3cBvHF06 eK27tafDVUAj629RD0O5bv2Lkdlf20LVWK9am0/EEJfpZYa+mdrcG6lN4H7QpmDOjDrWmaW9 RWvuZc+9oJyjGdKHNsL3s8f7Bccu5+f/13z3C5zvZuAJacMV3Mc2h0Yr56kIshWyVWygbzBQ r0A97vhTuQ6uMQ7S92R76vzsdnCFBOfsjPbMeua53quuHsVbNw0OD1J8eIVeZGgL0R/IrHve phcZ+inoTt1Z1358D7ThjbJH2kSSYxl1fSk9xVCnwtZ8OWYHI1U/h28NgPvK8dm0kyFjF1CP URcjpa+i7Yw0v1azX7Gm1Dvn45xL5vnAvrB2FmjDe/YszYBshnzYkSl+J++LEZxvtPmeqvNd cimjz+2YuB0biJXPm/Pf3FdtbFPXGT7nHufaxtzYpIECITlObgwOMU0w68KHW18HB5Y4atLC IMmmOh+kVBSUMBjVumSh2uhgbZdsMKCwkrRr2NQky801UKewEXVaq1bVyKRJmyYEYePffixt N6Zugew5xw4fWqq1Uvdntp7nOed93/O+5x4f33vu/xPw33kPeAd4+39di+L+IO4RHkCeUdeR CvVBnD23ELyu3nyfkKls6H14LuCfNzWB9u/QbgaK0X4DtuPQg1CkmboF+zSeI9hKt07ZFuP8 TshBADlutafG3rwBPJ3KcfM8If/6Qxp7U+OnXgA2wIddOHUGwO6d+jkQxZiZPD9Afzf0V+hv TOWaQvvmNeC7QAw4ltKp7wHC70SN34vzyCzvoZ+rftL7x6fV9HtGaEb/4x3is+i6T6X3vHPM /P7/TWfeJWZRuQ7p+at3zeeT3nHuUewfZ+pLyOj0GLuWqKgIGklo8QNSLX9RUDqsxUuCv2DX lEGyjHAYrloLcqTnilVenm58cXWqkVi+Ing1ModdIX8FFHaFXSX+1KiE/4HgZESDgbJvETel hJM+nGRNQCEG+2OicGmw9yJ7H/732Ltkmxz2rqXNCyLhO+wNkoUT7zl2Nu05m8icFySRPVgE SsbA48AEMAnYSBv7KekCuoFhAEcwMAdKgBphYQNsAPPsx3g3uARoA7oBG9nMXof9KcHsZ2wH KcDYF9gRMh/6PDss9TXoYuirsOdBX0FfaG+6fxIq/CfS9pfQXwA9ntZjsOdAj6Iv9Efp/j48 FMS4vWntY3usPO6J5MHvBUoBhtYRtI5g6Y6IpzWYsm+znbLSCDQI3ZVSLFenla/L36gzcf+i YB+WtBNL34mV68TKdRIbXB0zMR2pmBWsAzEdiOlATAdWpZTtQb09YvuAPYAXYFj3PVh3YTfB Y8C4tH8H3AP0iR57GutYhFkdYjssP8cm255YYwTD59kTWGqDPZFYlBvsvtNzzhEbEZqZVreI bZXe1oRzrrC2JhbnphRRT0UyWQv5JqCQbHAh8AUgCthYi1VYwt9kj5BdDmJk8i6li3XZujJs pVGadZEFSS3urZxksRUkhIAiHg/RskZnu3O/k3mcXmep03DWOjPaWBfrZoyzEhZmNSzOMpLT Y5Z97SqIsVFdu6rH1ecyXWOucVeGqY6p4+qEOqlmeNVS1VBr1Ua1Xd2v9qh9qrNH7bErja52 134X87i8rlKX4ap1ZXA77YscYM3iqQH2AO1AD2DDGsdh97LHgTh+jTiW4nFxBgUT9DzAONoT 0Az03IhzI84NqxtWN6wELDy1QCPQnvaqtz0zY0T8pPAA4riSCWsm1nYCPClaQBV6Gnoaehqi xpUpzNAD9gK1AJO2CQC7BjzjK037GwFV+idlzIzPEGOVKaNp2VgRNYtoXxHtKaJGKBwJGgWg rKysuB73xf3xflub3uZr87f122r0Gl+Nv6bfFtbDvrA/3G8r0Ut8Jf6SfhvXuY/7eb+tu3q4 +mL1pWpbvLqtuqualeGnS1jFpUGpBT6hZ61Fi4Nl7shDeDekJA7uBa4CjLjBHCgBwkAbkKEM S+sQrEOwDpEaIA5kYNSQuMWAedon7L3SJ1rCr9zjZ7j4QWvtqppINW67caAXYMg9CP+gjE61 hqXdBE9Ie006vk/aRRQHZsaJm2CDvN014G/YQMJAHGgHMsgltpVcBZAdzIF2YBiwsQZ8t7Kt yhC+g8ogCxjayvmcLFiAI03WPIcn4lHmYi9oOAYLPi75kOSw5EIjs0q7UaX9skp7rkpbhobi JxE4jkjON1wR7UxEq4loRREN2e4n+URT5ktWBdO/SH5EcsDIztc+ztc+ytc+yNdeztd252sP 5YtxS/Af1pRsyS7B9KjkKslLDRfX3ubaVq6VcS2i0VMU1Um55DzJOYLph2fcUTdxnqcfkigy UStUxJMKkUKnrVAEcssKbYTctEKnIP+0Qof5BfoxlY82esMqvM4j8+nfaKVN9D9K6we0kgxA J6HboadJiPqgr1mhZ0X8TzD+BPqvkgKHiH+F1MpxvbRS2l9Oj/uxFWhG1ZNW4BuoeoIEZNVj VuA6rIetwCHID63ATki35RMT3GGFlvPIPLqdFCoitoX4FDGT6nTFLyHzTujG1OAKKyBGRUWB JF1v6Sshy8QsL1Cd1Mpy3NLlReYSXaZYQnQ56Rzik5pJ3XLyGimQ6rD0Z5FFPeO7zv8ROi8u nPyduq1T/M8XcH1b0P0TrbQG+G9HxXJZ/FIgSX3n+G/08/zXhUm6xeJjgaQDjouBpELP8hEs solYhZ7jw4HtfEiX3n4dXvzUvaEV/KTewF/yoW/xZwMXxDTILlzxFrjrAw/z6tAA3+BLUriN EIoZc/ha/Wt8Dcyrk7QyMcBXFibFVEqRY+AcX46KS3U5lS+Xvak8SOz060bAvtfebN9if9S+ zr7KvsLutefal9izHVkOjyPTMdcxx+FwqA6bQ3EQR3ZyesLAsZ6SbNUjRLUJtsm2RxEMEnd/ hToU/HfM+1hMiW0qp2ZWjMQ2l5tlxbGkffoxc3VxzHTUfqVuhNLv16NnKgeTlGyuwwYVpgM5 Ztb6ulFCacmBF3OEdhx4sb6exsyxFhJr9po3NuE65jzaYGbo5QvJgn3hheGsh+et2RCdhRrT XHzns7D47s/CXPNobFOd+XpuvRkUjenc+pi5cZP3q3Wjym6lrSI6qrQLqa8bpc8ouyseE3b6 TLT+dhgpUNoRhjN5eyosQQpEGCmgCRlWLcOwTQsqoiMFBamgt2ilCML2eUsGbU/lKkQJ5KoV gjAljxTKXIVKngjDfkglc9+dbC6hbpnMPZfIZEtE0IjPh5CAT4SMlPkQMOIrk+6BO27dl5pO PfHJOj5aL+tQeifGn4rBLkjHKA7EFH+en9byzxBME02Xt7VUtOoVjXpFK9BoPr/vyYXm/mav d2TbZeHwmmxpY3PLk0KbWs3LemvU3KZHvSNNLbO4W4S7SY+OkJaKzXUjLUZr1Goymir0pmh9 4nTX+tg9tQ7drrW+a5ZkXSLZelHrdGwWd0y4T4taMVEr9m+yqwe2qeOM393ze86LE//3+xOH xHZiR4lJsJ3YkOAkzyHhT0wySlgbp5iYjP+oCcH2OiCQUFpYo7aBbQW2Zk22MdoOtiRAqRW2 0jEYpdVEta6TWk0q29iE1lplG4W1ELPvnKjStKf7fd/57nz33ffn7ju61knlZHat8OomHF7V OZWDmiJL1s7ys0STC/EQs9ojTYJ+R0M2OBbbpX3WaRWCa0vjjkzmlTRN5gNoV2WoMkS7IDpp lxaadXNd0r7Fdus0fnWuSw/NhpIm5EZSy9bmr0o8Hk9QJJNuoImklG1LQNDaO8KTSx/p6pwM TgZbJpVYcwRTcyTnviWdiv5i8HqQ9AUHgyPBseBEkE0mI9BsvOi47iDdjj7HoGPEMeaYcHC0 Y23neSU45vjMwSTBm3ACvpbm7JpJ4FDoz0QyTj8EC8QBs8u5k+4lnSEH+gZkvRgy9EpkApQA qgEdABb9Buj7gL8C/g1QoQNAvwv4CeAsbWEqmcoWaWszXTHipoeOxPjOevy+RSng6zfN8o6u Wd7SPsuDIZ8E/ExjdW5IBwk4RtNA3wF8BPgH4EsAy/gYX3by5KzXRuIo7sYgPoIfCUri7gR2 QwVTdSfibjeioA4OFoChbvy/fo9wPIlAFWAQYDAo2xqnf0tS/tU4uCcRaIDmzEiN2qYIvkDe hGRVTS6eQawqRd48x6BcNa28jpGcw7EXoZ8gBpcjHm/H65Dk1t8NzgTb9XeCbTNB1Ah1/QMg Xo/dYDc4gcDRjx7YmLceKCy6j2yqt2Ct8MM/s/fZ7ciL6tEKHFFcKHwjTPRhzGl5q8YmaK02 OcQtq+izQtJb3de028qpfDhM81ezUEO5Ml9rrClXqss84SVlPepYYaw85ttYv8OXqP/IlpeX 7zZxDb5QeWFePqnguBReqTgaCs0NDYWMan5VpWeBGlcXVnDz3Q2mEM97jyNyHC78FPPIuUVL Sxg+RQYVjX7ZdUHQa7ygpRT2nEUtLu5XkK404KtIRuXkt28UNhaHRbEgP4UPKCa52IVd+2N+ 7L+weKqveEcxgUSgUrE2B7vlPnlQHpHH5An5onxd/lj+TM6V5VY4Ow+cta/pgnum/U60LX0n SstO/Ux7y8bmv7fp76RpuQsKpXrVp/XpxvSdLDeKtRhwSFvl3qu/jA3GWihZ6K95PTgKlu2P 4ujOfmy3cBxRC0K1L7BQ5LgSh6ssS/01gYUuoAsD1T7BYubUghjw15S5ypwB4K4SB2cxCyYX HQ0V+LfKgk881jHZG3luWUvM7HSeeGL1axsGrvb/9NIvbi9w7OvZ++TRI6nB4ckioTzz1MCe SNNjEcfvnt5U/61dw8nGJLPVqW7MXBre0hFeYX3+YGRb79cnd+/65/4tz9Sf6lr6/OZt491/ +eXvD1eVWlnN4qNrl6/bVefdNSOfO7mn5eT67T/20XRhTaaVDLAvIBOqU0qOGl4xkIN5zxpI 7nHegI5jE3hyLv+q1rGKw9yQec066pjR9Ewwqz3QnNeDQCXY4ipzEb8eLaSKsZjFIkIGjm08 PIp9d/e83G4vaN2b6XOu3HQED/8BB/DD3ormTzNHr/xxYviVH4AMVSDDo1kZapXSclVFznKW gcUNIIQJ8g8+FwSwcR5O4RhuyNJ54v+FwFGTXxAFo0WP1P5AwAhKryJVxzeOjGau39sz1maX wwPshorwpu9knvwg804G9zpbPsHbr3wwOXySStCbOQWPj7eRiDqUsgiJiJcFhhdj8nsyw2Ok Vql0OUZ03qjkaVR1OkuxZcjCWFK4ApJBXbeO6GRpFISCaI22zUTTINNNYy34j1hLJcP9Jn8g 6wYlDvWcl8y6R+/mfl6t1jiNZm9dONC0eSRzar5jZJUpnzfzddXepfHuzVPURh14iHTC04ZB jYqNsEPzNgQGWUwTvkmGQUSPV+EYPozH8XuYg6CqeR0NqWgAgJdHqY4WpIFmPdhkt9g7CDtz n4jH6MxHHt7EfegS0iC3UogUTsMovFLn55VGfzePx/gJnvDP5G3bTefq3+l20715Pc6s9LM7 wWiBEqqqCoUuZWnVAoXOyzy8SRrAogxarfCIfbd4cwAMmWLKlHzCmAkBsSH+NSiFixWzjfEw MWYHM87cYDjmAv45eVeVwn1TH9NVafBCnDYGD7HZsPR63BiXYNKQsazCn7AvfPko+zOYC7U+ vMW8wW5BelSKps+sz7HBe+EMy1ooy88vSGGdYuQLkEtxEcUVc427brhULgNt1najPjSIRtA4 nNiycxoXgWrnrJlu10f777al59xsyS5lJS4tKXWUEo5gBhNO7Sy0zrMWWRnO5NI5NS5JFmXC 2VWGHlTMFfRgsxZqQh7USrGtB1tzgBj1lh4k5wLJZlOUVGRRUbHfVGOkh4coGMwENFzmWqgX s8dMwEDPkawLkdbnEl2x0YGXvv1+z6X9T1xuqe0PJIqqPKW15XXN/uU15OVb+GurQ2NXMhOf Zs6/+Ldf38vcmnpx/c7TuPbWS3GPvb4jMwo2ug3XEwcaE9AxxaxIMWlcuiGpkKRI5JvoICLa kAlvhVctj8eRA+4mWs+BegkY+D9Ih7ciAVoQ/pcC7zUd4Qlm+Zw8wqBpfA+Gr1CMWq1OMfg9 ukHdYd24TqWTxWlSim/OKdcdbNOnb2ZP4caggQZMLfo8/QB/7nZnT5X+qMlZbTALgmix+xuI nyqA7v82brWbgmszJLZIyFU7C5xNqqs/un9o56Ii4nSSed7d5E/fq7AVFVM/nA97PAV7LMJL lafUkqZWlArrayQFiEyJrkgQytVB9Qr1a2pOsT2u6sp5XOyStuckDAnjqOaH2u8bTmtOa6+x 18S3pQ/FD6Ubti9UX4gWeLuqZNZqkQVZnCepeVEjaebVyMvkZ8URm1qSCREL5Dz5v3SXDWxT 1xmGzznX9vV1bN/j3Djx77VvHDs/TmxDTEjaCE7SlvIfKGIBhpsQ0JI1UDATDGhZkonKhJ82 bVdKlw2iQmhL0ZRgJXVCt3YTYm2HxjRtU6euImMpg7bRKo11DW3CvnsdaLZqjnPv1YliHX/f 977vcwwWzkn0BkcB6IWXdBBpbUwQWJ55YaeAhQxXycxU73rGidUQI85RrhIKdzSNiVnO4KPM ggzXGqQmabvUIemkDOaZxOBLuZCf+Tv9XLO/z0/8zgt4EnRmwYzlNZHtpIM8Q94iV8hV8g9i JE7fKH7663ker81OdGIFyIqqwpqYSiRrF04lw+OqX2ltgMAj1Fqbovr9F60gOJzcmYB+qGQT xpwyD6FslvGBqqyR8Qae8Mrcqqr53OtNX43hTdh/4vEtJ0NB55Xe/g9jS89MLsAtWxsXubB+ +ssgrsfHX+s6sys5cukPPa2tLw9Nf1ZN56gguQY0/C3o1ly8fASZ7oydN9cIKpTUmmvqhIdM i3KWFequCLi0tLqUxZvjV+Jj8X+beBTHdUJHYF/kbNFI0Wjk3cjVwNXgB5GPC28GzUuMpRl8 JF1SQlGGjKd/F8OxDBcf4vQ0H+dn8MkhLwtH494MfiBNLaUlF3AbykMC+RvLWQUVJj1ahaFP 6QEzNmdwD6xXdFaQnoq+ClIB60NNfAd89wz5iJlYHPfF346TOLjagjeY9JZEJGelaic37pVf q/1EInlLvYwD3YGxhCd2LpxITOTWRLMOUxWJyiGTqDMUKgGlSAkqOoM+aA2FTGAdUV1FC5ZF eFJyiluwSYgYYi3YZ/GqXkJrZ4i1rAtemoJ2omQ4LFVpjgJ9yteapcxEUAFIS/UWjVBAWgFV ZWpn+bb7Bg+caqwf3d+547npT7o3RxWny7anIFj2nRcDLl/42Ep/w8nFXc29bbql3S881rDh RyfmDD8x0PXqg8XecqN+oSHnxNaGZdXekjrZ9OiBhtaOM6oWW6C7e/XLkYIN7IHTOpy7Xv6u 3KHvMHR4j+iOevl5ZJ6yllvrb1TaPbv1ez0pcsh1yHOKe1XoC4wFRBTAIrXlSvb8AmMepAiX wR5m8ysQHzq/4nJ7ON6h08PqybTfr0ijoAoHJzGzxYKvIXJNUQCYR/EC5MYPD3XyfWrX8L+g awHMAs0BEoBxmBympE/BivohTPAz2kcJdRaO4hfwTa2F4wmwLJpQaVFr5Pg9gtTaBw6miihl jIT1EFVohgCSoB44bLGcdt323C3yDv0Orz6xHsCAV3id2heDYRYXzLQEOlKMub0rp9vWY6H3 qcYDq7+3d9/2SMBVHF22YtfgicPb3sQ6/fKzw8UnDmbahzuL56+Z6wlTJT7Y8cQf76vgiaim 4jqo+SAoyoFK0AQr2yXsNn3f+kPhz8GbQYOBw/u5fbp9+U8V6GqNJQY9F3CWOA2cv8mIjaCI YT+gd0gEoDiadiC9Gqhp0QKnLczUXrDcHBcqY2WElTWX9ZWNlenKnNn6wp+QRCW/FJOY1CP1 SbzkLP06Vr8CSBqfyVVNAGBCUD1gdBXAszUDGZR7gkKu1yN7iMEWtISCQgAGnbpbkGKFpyJT qAV7cv0tqNAMF3Q3SNXZ1yYf260cf9ee1CC1xXOLqiqxCt53Swwexh078Mqp9qKeZw9fbn3y 8uFNv3gOi1+0T13OfXhR5ZLG7oP7Q436tqCl4eVfd28eGzh75OzGNPYO48XT66YeTK1p/mt9 9PTx12/71VoPAEv1cAPAUgWofpBzZnCQeS2tVT3OPkAChngzlExkdkCseI+9z07sb+IgdOb3 wNga0d7SHHmGZ8N4FmRJs4FLUTELfsujdfXqnRvIklekbkqqzz7Vq/t5Gpg2ww3CfgJoM3Mr wV/aWqsuiRcLidniluxUMA87zOq+8jLcSuaTmQPoTxR8gHxVbnqfqPiUToVT3nE7i1QABANT 4ZZqPDYFu4zScS0r4K0O+X9tmPs/xItdM5t/9H/Rlxtk2b2z27e/CcEEbbzzEXc/nG0LUQTd GBKMYoyQzJ0xVh2bF4/GFsYaYk2xJ4XDQr+533XKLYSMZouVo/mcXvHpsGiVTAa9jqM84RQu VN4hYYjT4SHTIieHoEiPMHeAleaA+6NQOT941YtFL/amQnRb/vXyWAZveyPE/OWxclJ+gVhQ FMXw/LTyE/WI+Xli6rp2pEwmJ2yqB0BtPq8FP0jgbJ4W1CDtFDl7tF0FHqPZHcxxWLxIcPFe bC4webHRAxeUneOuLnUCkhgSdv6so+O9+mb9HGzDwM8ejUul/JwVtUWplsYttRGl7KFfnfnt psV13362zj4zK5j9oP/55N4FHcceiQW3eormrFma/Nmede1Lftx2uvtWXVQj+Dp1eihC+gGo twf58DnmNlpF0UJNsuBbpRjsokRdNpfb7XF4DQok9PngPPWWjq2La/dwRLufL80u+0PZZZec XS7Qls/btRt7kUpxi5gDH14jLhUX0SVyg7JebKRr89bJj4mttE3eTTt1KeshMUVTud3yQV+v 2EtfsvXKI+II/blrRP6N+B59x/ue/IH4Pv1EvEFvyJPiF3TSOymXC+IyN/GB9fhkgryy7BGs JreQ7ylw5xsJ7zbabXlu+x5ZpH4qezyFNppn22HDNiparRnyLrMRGU4rss/bj9AO3IkJuOEQ MxupyNnz841GwejJ4NtMEOF/SL+V2TIklm6QsZwhnzKrn1lXWT+zctZX/O2HNIk7XSAhh0vN DxW+KPzA9RYkylRtypqNjVTCGnGEUwBfYQeiE5i+/c1riu6/WMvXwlvLl/DdF96ZwAqveRxA M8zOfFyJswStCTKHcK9N/XNj4f0t02vXOisX4A8D+P2axJqpm6trSh6//im+9KeGYl+UDwZF R+x53cYvjx9crQ8GdRGlvAlbSNHUXwCoQYNIdx2SXEZhVE3Ws9gGtEHuRgfl7sqXXD8tPuc6 V3zT9XHx36PmarTvP1RXfWwT5xm/9+58d3Zi+3zx99l3Pt+dfY7t2MnZBlyPXCjfLCTrkhTY IsLCx7YyESc0QLsu2dQRQK0StQIBUzMqisQqV2VNoQFW1jJpE+22DsEYsD9gGjAQZO1WBlOp 3b2vQ2gnJe9zec+Wouf3PL+P6DZ9f9M+/ZDyun7RfzF6UbOQ+Un8HxP2Dbk8GopAOIOq8XeX J6MbUgIePiHTZMgaPPhgZr4yX93pvwQuKJf16ypNKkC1NrGEi+L9TsGtuDVXuqFpgbI08yRY 4VsV3YM7WIzNd4JVSk++Lz+cP5Bn/Gl/UzsGt9+vCJovRVI4IXiENn2Hsl+5pNOhvJFvz/fi vUSPqYfqoXvSg9SAf4DvEzYrA9FntOep7fx2YVQfzn+Qupy6rXym+FYydpE3S2FW5N2SrCsY QSawbFxUiHBsdkInGsJaNmt2xzSPx403aGhQxqCaoqnPZ6tlHirDE80tGfTnxOMLq9Vwwvuv rw4Ai5AO4IFOMi7OTjSiF+yCLGeQB0gcg8dVkiDRpcXqyGAkCJGAnARnjyXCrH18Tv5X4Cwm YWuAF8pKfPndQivy+PHu4uMrjmONRPIWXy1TK6FhLKDh65+qzk5/1cyg3yqRPWQvxzRvoUwG masllZE1rwBoP+/jcYqKKCqu6hHNG9FBim7UgSxEdCIDGnUiysd0kDY16JgaDOuY0ERkdegA oEktPBLrGa8Kuougv78f6y9i8YcvMRQ53NPuSJayetOsXDUBQpcqIecK71U30vFpdqQdDzW9 GkyIt15cuGb4yvXysN6peoLRVh1f+lrvnvEflp9VV8956eXlp0+sbd9cPHqq6/To3BU8/rYw 79s/XXe8U83J/cTGH0kJ1au8s2X9q3aabv5J65bD7geb+INb217qIE3IyS794m8mO+RGBXtg zDMLKZDCU0RK3GPfJxy0H+SO2d/hahgB/vfQYD3r2up+kdjlfoXY4y8RJwlzLWEj8eBiYiVh SjGsQ+FhXDAdxXkATmCTxLJjof0mLUCASfzKUUf8CAvYSaLl6Kj151bcOkmkjJjTjJcwAEAT W3rTAURHswN3+A04XOZCyAvsXtGLe5eoa3unI0d/Kwp89/qL0GsVkTjB6HH3RvPUnbuQRqag cJ2p4hpy8VQtrfojNRG3SvHmJFbrggfjMyWBxWNNYtgjyCBa0ND2Q4dVJ1e7jbucHGr+LA9F yqEoFCJOQfqEIJtFnhXFuTdeHbn83ODU3uc/2Caur3xysvLm8V3HQPO7L4/Wc7zTX2N6qqJ/ dGxn5fyVycq/x4qHnUcPf3bi8w9Bx8nF7jo+DdVIhmqEsoMbDvZHxrdq+JrgdnY3+2fWNMgO OkfYvXX7XGf4M8HzLON1cM6gQNAuMOLfIeAaQ4k8JoVpkbdKskfyiZrNZsV9mtuNMYFCGwcw juVCXJozOBO3REZr5W/OwlgQkkGfjKIHIUse6GPGw2umm1poLRdaoX/th+oP+/vl2syZWZOA X7C7WNUZEeyBLuB3wSPoELsAX+frmukk8qlw6ruL+v8Pd4jkXCwMaVHYQAxyGZxtWe9S3AE0 xRpIg6+9X3q/8vRfh7pugqbKHz9ZNaDOkgaIjUOhhLqrcupc5fqp898JgIXAA3xgfhDNaz3k 67dh93TsY6PTyG4IbAn8LP0Lbyl9Mn01y3T5+qg+eogZMg9Tw/QoM2o2KyIflMKqyMclmZFs NtHMM7SE4yLF0wGWx4EM7UBQxw7FG7Akm8STk/g5Y3EiEYezcCjI3wwEgoy5xDBUqZkeonGM Zuk2mqAHG0qJuJhMwS9s9JdCvMFf4Qn+m+3ZvuyBLJHF2LCqjGeuHgcjVUNcKBfg6HZP3e2+ Vr7X3T1VYKu9vgO1EpZKVTQhU8GPIR/KTt3B2P+A6YJwgPwBTZiEplB3yNWEKzmckDPQrMI7 YppVvuw8mmf4BEqgfnM0Q6mqzcY90Vm5wGqzbwx8Nz23RXv6we10Oh7y+JWONOmyR116k7bO hJdvyg2bK1pvQNYqLauinlBq7nOVkuphjV6i+GNBUyt/eardZYdISBAJESKRBNgvtdQkEIxZ 6tqcmTRbjqSIvfET8d/GLxHn4rfIW5YH5AOLGWZFaghiM2wapkYhNgxtMdfjtFRbOwkihpXh 6aDIe6QwBcFBNzETT9mqmiSIfESS4wnNwtSSJhxCVmu1epKYHME0VsM1hJgajUZwt4eJxrUS FgNYLB0zYn0xMjZGUSIN2mjwaxrQyPFYMFtYCI43fGUD7sIFKEBLUyxfg6hAQP7Z/QgPCAf8 QajAYa8iUp6pEBdIHVCPgAPhAJFpwGXZ4fSgVKa7vsL0M6DA9+Dg/c42q6qC6IL5960WaMUb yyfSHRGv1SJCpIl/WWX/gnXfh0jcXrapkm1bqla6Nkg+zquqjaFniI3Tz5ULq1dqaB8WQ/5+ HfJ3Bia0Dgu5sAH3Rf0aznpZHx7KGbme3Famz9vn21o/5h3zHfEe8dUkU4M1IzWEN9fgb8/1 5V4g3yCv5shaYnvNezliMQO77f00zCEs5EyV0SeqjA4moF9aZsQb9yc8Xm+Y0hKETQubQVwU wg5HOzfG4XaujcMRBw1xX3Akx03i/zVYS6E9AuwRMYJHlmTX7prh8vK9VLXr5cK1alBE3WZn qPwh92RCcZplVC0ai9ZHCaoWSrRdcjwGQiLroOOWJGaV4cGGbI9h5iiVBDWqLYlNiy6yo0iS pzk+Xl0gJMqI6SEaIWQsp6negYQ2K7lQvnM5oEJXeR9uFcp5nupHyFsQvo5tpyrlkeKeT4eX vdAitjyBW33Lg86BqzsrW36/r2v9W7s/XLpt0+y6Op6AGtBx4BtP/+GNj09X3tsdUcGO9c1S JJJRf1BZMzf/+bv3J177zfee9MZcsg4RRHrwCtyjBdjvjGLfogOL/rTo6iKybtF4wMi1w0cc QlEjhcP/I7xqYJs4z/D3fuefsxM757Px3eUC92Mc2/nzF8cJOHHIhRDSDTYiQUsD9SBqtrGW qknEf9Qt2tYy0m1UWlvGfjLE1qpoaKVhpIF2kEldJdROy6SN0g2JTIIOwdAYot1W4mTfd04I Qapm+/x93519uu993+d5n0dTywwzrak1htmuqSsME2uq14gENVU1IpTfqo1IvaY2GxF6y8jS peqK5uaiIi+uqa4uK1N5MWhiy4TLJugmMXvNI+aEOWm6zDGsW6VCx9aO8Q5O74CO9qhZ35ne msbp4dXdl+TKLwh3+hlEhL5+GyX57LzWp+8CRuYEEBXw1OpR2T5f83ZYaVwfBIXx2TCZ/Qu8 gndRfFQSglfZTEUBUkVI/m2yvlzJD9mXavNvzUKHXsHttaSSSoYP4NvbCoCRhNaeqZfm0QM/ nX78Piw9ed/PGJbqqFncQzOhoQErZ1jxesXoDvQ08JqKDVPWVNEwFU0FI+LR1IAREQOUinhZ MT29/CA/yXMzPBC+k9/Kc1v4cX6C5/huvdcYNCYNjhidxlaDGzcmDMzC+kUaSwqDvj47uDbp FAJYWRn9jIjMxRDveWDTNBx2MKILGILNp16053bfnPkbF6B7i6ARq6ldhC3BLSHcI/VKzxb/ smQ86hRlIFErikv5wnYX2xsNy2VCWMGAScgK4c4QhMY4rxVV4j7P4jLT4yG8xR/kf8a/zjvP 8Zf5Gbrl0uhlKvQml0bHcO1JY/Io0+1XcoxcqdBgW715M9fXkrW1+D2RIZSq3uLS4rImKPKq RUoTohSbtaHbT7VzX3A+BBSfpg3POXDOhel9OxJy2y92fGm7YlTpdTFpqZq0A+OM2dHIf+3w 2e/lsrWKVrG5YeUGbrgQHGAe0HmRxqYNW9a/Bvxn/Xg7gm+gnXjAv4vsrd/XcM57xsc/hUB0 tNfQgmjAD+Mv40F8wHoBH7ZO+n7tP1N3pu3Pvg9SPrEIOD92YWfqebQ/NYyOwxH/H1N8EVW5 CDuLNc8SXwWKQtLT4lnn+S56N/0hup0u8RQpRQTqcZ210upsfxV+jl+xRvGo98TK36NLaAL+ hC9wN9ANuAUfe28V3/bJ4bpwOp0i6Q1wGL3oezn1Utrj8rlVF+Nuw0xqatwws63NatbpcKjO EpvLNU2NGZGmdKPaBAiZfl+IisdWhMbweWsDSYcISSPwpVud7QS1ph2NPsDFRV6P2+3v9Z/z Y3+52+F2h8PKcTnb1BSPx5obGxOJ8uMxWZJcLmcMO/nsDxx+QpKOQSf0OsE5hpdbxZav04cH fXDCB74x/N83kyWmtmR4VfvbkLWNnTJn7PJZWiL91N3ZvCLQptAiFKb5rDD/Lixo6eSS1MrR D9Bjv7+m8hnhHTrIbJSRQNvIOG0CbFiwoAxFZSrq62971PIk66pbkyur2xy5rlxl22OPWt4G Oexr8eqhTGpsZnJUyFiCPwNjM9dG/BlEz4zYq/ERga3G36BDgfdov+liToKqAQiHJQpg27/F 4P+SXKBhGVpm2z52zo/dLjfugTsDv9qYH2isC9ZPV9kVXJM/ex/kV9YkqzQ5tBMSK9SKlAa3 qx7atjZ8Ct+aLhnoolovJsvlafjD9JoFusGUC1xn9Ux3B7eDsDm+RIpQHRJuWR06TVGQoHru TYoCHT1nqQISQEc6WOZG/FW8Gw/ph/Vj+mm9GMwx+L5V5+9peBg/tgRTJuQMM7xMDTSbXk0V jIiu6YggC3Ho72UBAZdFMMdTGGzHY/gdqygsUdbwDhvduVnxRRN65w7Twsx2XMkxRmBtpJ+1 EYkzFvqJReWzrcQWvg2Ol40ddz+qeyS6yDYUX9m+UReKU996/Cdf3wa73dMvRJfrO7gnmZmI QoW1d+r4em1RqGZnAfGu23SvBH5rXSuRwY94ya/44iWJkgoHcYvN0Jzskp+GbfJTyb3yIfhR 8j35L/I1uCH7fDJ1kS6ymnANcgPpkLkwicnlhHPJTiJJXCVK0FUTapQycr1ST1pS61Lb0D60 S96r7CBD6ID8LDmMDpFj6FVyJHUi9b50Xh5PXZI+lCdSN6Xr8nVlMvUJ+lT6N4k+BJ+TVic3 QZf0SPIJaY/yrvw7ckG+QK7KV4mfYtpjmLqmlhpmjY13Kgd4IyLYitmwsc5kGoIQkhUEiiwz oK8gyRCRJZKUk5Ckzy6VKoqEPTyPECGxOE820x6oJGtMXTeOGCcM1rAmDZcxbKUgBTSH50eF kuFau4Xdc4+f5NiEUnpymiZyFqkFfUDxGcjs52sqnQyfPMUnm8jzcoG2wD6KxxyDn5oUQsUt UPgSMrIcyMiCmEG8nJHGZiZOSRmJhDLMcaLC0QW0Oxg2yhZijAk6gPv65n2XgVudv6NGO8l0 nFAvGvKvWQ+D8A+4AoPJjdSbRjuT+XGyMRLOf+zYObXrGa0iGk3r/dyuTfHFsejdvzrs5dTQ vQtDd5+nHXbm6sx1qsTXohgMWWuGRBAPAmBrXf1BDOJiDDFcHVwe3BP8Ib6MZ7A7aJqiwASc aTABZ3Isn5EQy2dEFAOAsSmaIVE0Kd6OWiWx4+D1eACrpbzo4VgeLL+4PhDQBSJYAicMJygh WUJLvZUAPQFHEpMJnAiG7N8ZBjFh3ARTiXcfLcjvQi+mqevrr2TZEz5inbmlkLSbN/cX8oWo 78nYuXILWWZCGWvGPaIiJqAFZcR16PPiFrRJfBo9Ie4TfwzH4C04Jb4Hn4L4TwxMcnchao76 aG5PIzzz2sklYgumz3mSkqxIWXWUVodVlmHTkdlBtYdRJUOFFZtetErEjBgWM1hYRA8lE6Tn Rooy9DYTheE/p0IZbAXmqJhxsf1i5YFyHK2O9AIRFXmwXMoZI6vQyzWz1MNFVhRLp76plq+j FcIqoqm5aXGTc+2Um/PP5fzuAceqqd/cq4DX26uCHgoc243toW6sGKnoDav2kPia+5j3mODY DXvd++E7bkcb74sjblHc9T++yzw2iusA4/Pe7O7seo+ZPWzv7uzO7OwcO7vjnR17D7OLY0+E OBwDhsoiYNk1ERFxBImPGFqgCCgkhjRKQo5C/UcABagrqLhKMBTVTlKi0lKFpJVKoCpEqqJG qQuVUA+1Xvre2KAeUv/YN2/21L73ve/7fa5wC0/mSEiQDJkgDdIk7WR7HG9itK2YiJtxGPe3 MK6EC9Iu3gVd7bGn1z2sTtPLmCG0bWhiNSeLoJoAS8tuJaoEFZ/HnyVYEM6CEIVmdXY0Y2q8 WRCBaAg4a7NEva3WKkqPVkvbhY4icnw/Qwh4bC7Vo9XyMxixAn4mpcBp4AS7q1urX1X/UN39 28m/vvf8vlefOzf5933Po7ozUP119RfVfvAqaAELrp1pHx2vXq7+6NxekAGPg54Te/HaIM+1 aRZdN4DlFwkd/dU3K8Wcvik8wo7EvqUO6m/HqC3hC9Il9RZ7K3ZTckRSjK4qZbmcmq8aenfq 2dSgvlN3f0SAaCwd64j9JnKLtY+r4OfSZ/U3pc9SN9SvJEfMFOOq04fNMAl4lhJEZJW1gkjE Ew2ZuNomdopQFKnajFpXVwudlDNARJmoETWjg1F7tF2f2wJCB6Z+WoeH9Cn9uk7qDSBJ+97J 6hPgG+eEp9Y9gpaHZ2jZAqRxhcx+yVqX6TUW0zPTiFRyvajclgOzyYa2Kial62NhWVXS9Uoe SDE0pCKZPJBZ1AfntmTXLqK9C3Exh+xBnG9Lcon5aGN4Ali9ltB2WbgxjCptL65c/+uAWPFN 6B+GMC+n6ixSxkU3SYGjMWVZYebHKDdDLMpN8Of3Pn391s8ahx8vfi3ef2DJnq78Critumkn j3JzHj9CbsSzjrNbj1/3La6pObJz9YGOINpP3Fv70X6qRAFMmhOjSRB4UbkiXsmS7dL3szDM 1+vrJdIFXLIiLyZWgwE4IG0D2+AL/AuJzclvyi+D0cTB7AlwQr6gXM4+kGodiT3gFWlPakw6 Bo7C49Kp7GT2hnE3+yDrDRB1IAoDKtqnxopeMdZLz+ZqMk4Yi4FanqWFJCGrLIGaiw91Fp6N CaIJG2RJSkIQQiVNOgkTkMqkj1EMtYJaS5GvU4cpSBHsyVhhAuw36SY1Ho9B2udDmO4MCJjx VhfxxRQ6i4RwSoCdKA6hcJ4pAbM0WLpeIksFZ7Ku9p3iUxcthp1LQ6Z3GLmrpmE15GbVkJtT w1woTk8zSA69wzlMspEoM/2QWkGgHA3PYao2yti3/7TRCGO5ZBs5kZezYi4PGjk06MmGPCFK RqIpDwgNyQFYggHDSBLDVpJeJGQEqx4Mq/fOhsoqhtmQZZ9oeu88UzYYGhkmmPVJlKKCACyd /D8dURhtQdOckpCQ7P3V71aL+YSXY2LK0qKlKIvEwJ9u/PK1d0+A8NqXB/75WDDm+uDKod2V dXArBKC6+T911faDTdsnlOq2l1Z74Ftg/Ns7DgURn+188LnNjnx0HnzSjATebgA0oKGbJGib SqTtWifohC5/ZQIsMq+X5pWiJGvrC/dF+qJ9rMPutfuIzFTFNuIe8Y74NtOD3CA/mBs09jlf co96R3176FFt3DaeZwLevLfgLcbz8UK8iHAIZm0JLsGn09l8K2iFbTYjYnAGbwiPFR4rLvEu yXS5V3mfZFalV2lxHvCQzfNFttQV7op0Rdc09eR7Cj3FnlJ3s490u9NBN5sW3YnK/LRRGQ4M B/dJB6mDue8Z47kp9f3MR9pU5V4ltNw5jyUGIHsKfAwg2AEAuERMkB2mtzjWGGPjAzzLcZfi +JlCZCyU0bQWjy/k8fg0T8ZnU1zWxSGCGUSzaiMpqiEXPAlMLlkAgFeAMgFEk8n5J/3wth8k /Kf8t/2kfwKOXuBPchqDTiZ+A39IB5P6Xf0BMjlzcdHUP0Y3JKEndANZn02/DBYRZbAIhGdF 3turDaHgGb4/PYPr2nA5p82mkOV1GPfm+phvtoj98T7S8zQifDzrBcwQmlsuWJIMKqgq7gZX nkjT2AiDaKAMdFuT9eQJt6dBSzHIFmlfOiMHkDU6cw4seM2yQGuYTS8kfST8Xtzo1rnXe59h 1mm40QHky8QQYZGlxx2myzaDLucN2iKFNcAv6lBMOmpxQ+Og5ZOYG5MOSvTnOTir8pQiKUqx UMo34SAsNZMn5EDvyZ7+vVrrlz/5Tsfdy/ML/IfRSJyS5ejq8xu372+upKpH31x654cbt8yr jwo1KBu10cNf37GyNd+xff1zb60cu+2yt3E58Mkb+9fu6W5a38B9OPJK1xu/Kkb4HKJIohWl 5GkrJa+alW7QDbvj3dwGsAFuiG/gnDmhTegUDtoPsOP24ywFQZyrw60r6cIuKFJhkeAhQzuF CThlBl1AI8x6X1uARl+3gjhF2IgJqF5wupL1dbzGYXvz4ZcJjuH6uMOcjbsEVaIOTp1LPI36 GfOX+73Yxzjkhu4ifvtZN11Aa6f9nmlBtc1accJ0F9Hj4fNfWLE304JijLnKXMWEjxIqKCp4 bcX/shcMZGi5g7YjtOIO8s90TSLoys28jwns3T618ASlMPal1Q+6pErzP+4/pC2bxxfc2ANa 8Wq5H9yxn0GrpYPwRcJAZJnJFQxMmAnJuppddbGC6qg4ljq20DZZlFNNYlNqobgwdSxFpVPl FFxhjLi30WOpydTfFEeLD0UIFJI8z0aEZIZngSAGeTYsiKg+oRyBsup1ZdKYqgMul9P0lJ0m ojWn4YTOqPV7ibYiY4BB47Bx2rhj2Aw+kQwEdgTBQBAEI7n7c/jda+H3coQOiBzQqcZ3+BBZ GTHbjDpWbjnT7ETnRBHUGn8SVTrooOWULPkSWYLxK550FrhrBEbOEqpbxjAHrFOBPpzBBwIJ nxjC5wM8It+Qw/J4Bfn6vwNxyBL7nNuTn4A7+RVa7crpa7/7wkgsXJaHTxS6pEh86Wv9L366 DLm7PSXLC/ihmZvXPj8y9i+6qz62ifMO33tf73049sXn88edY5+TnO8SO7kzsdNcMPWtfJSQ AC6wkYAS0g4KFFZCYAjGQq0VSAPVlK1dVzptnVZVkIx10FBqyqTyx6T9sU3qP5vYf1RiFKlC ijSGxoKdvWeHFe3DJ7+/u9eW7Lvf8/ye5/ne0N9x/8QGTcu1jlcub/zD+LrDH93EtVfUtNsd P3LDH7hYBr9yGjkfHcf9QgIEGd6eCYKayIZrIjvXlcvWatqsVefHakv2b/6F+HyC+CR0LXxd vpR4CKmZyEX5N9RV+hpEOes8PQNnpfNB6idw2jftfyc4naD2SjtDh8ljXClBbQtuDRUTu+i9 kNoOh5jt3Ih3SKKcRBHbQmylNtOUmsiSPdIarM9LaXQbNBhDMoIU8lgJKzGKQi+FUUDBfJKg +LxMg+KNh2JKvLw46TQGIa0yECLxDyBdpGjahUMuGEJXobgPeQgMhzS7EAKhL6ygE5wOzgfJ 4F1LcqSidEmalyhVGpXGpJJESmX8y6tq4q3EvjNI+BEsIveHbw9j4aUclp+k6mMU1XDtJIUG qmsP/ntFRDs4/NWrJuzIF467w4/lwn7b5/ht0o1Wgs0wog1RjLoq2pwhurs3L/vsx0kAuQEg 0RDJfQtwWasjoNDumASgPhH1HPXBWi3XVtW1KqkLkb6n8faRnk4wBByzdzXloQa0hkRm18IJ 8gfbAvEWStPYztZlLz36K9F4uKMpxyMWIWwoi5/DCYQNG7/gRFi6AXoYjoUcZ9E29HvDou1B b8UFBcNmUS25NYqqs4hOutmcuY4dIgfZ8yydpFNMmjc8hmjIbUq7oWe6aVvOWs/Sq2A/v1bZ Qg/CQWaIG/QMyoPWlsxeeifcz++R9yj7uo6QR+gj8Ah3lD/uOS4fVSaiR9Vvm6fI15kz0dfM 16ypzA/hOf4N8Y3wOflt5U3jR+ab1gVmlp3lZ+ULykx0tum8OQfnmI+5snzF+p31kHnIP2p6 qK7bY+6y9mSmWLJH2R87EH+5g9wFdzF7WKKfHYivNfpNckjZaj5nEUVYZLbxBAkxDvmGaNBs j7bFM9DmWTYaZViWiyInEIsxGI3wKMoBxZFEw2xTDL+nUfHrsaSi25kexS4vjs0pPKeWFw84 AYuBqofnmxX0fUWORmMsx7kwlZQo2oiaTQzTbJkByzIzNITuJ1Ergy4zol83DBRWMJznOIaB 7PKf0e9n0GP/0MllXMb21oqT7LCyVqaUmc4QGzM7MqOZsdrFrcx8hsncZb5gN/HKRzL/Ca5i MvinwzueouczD+E537u8jL80V0f8g+F7tyPC7bBQuV8zzanKnX/75FqpU2DSO1GnwFcnzMQT pPj/rHhyhYI3z6ADCnlXlZZeaEq6iQuB32VKwDCCDYWYu6gWWuJhP1+oR7IaLZqXeLFEjfoM rXFD1PVk/Xhic4kwLTk4kXsmFkhVTxvV31f/2Fr9VocnsHo5eBDO9aQB/7mhSnKDGImIbbjQ 2pPtACTA003B5ApEpWS25eTCdeKbj35KvngilNQ0zWpuOVGB+OT49mVJscHP0GirreuVShz/ 8rtWyGC8mjt7RZTOZmrK+NYVCgP+mjpdKOQcayQ8EilaZDp0PHQseUw/G5rS6QgVoXHMkqBk qFbRoigK3akh4WQCU0ErNPRWQ+u0rDXAsZ4Dg3BbbNAoWofoQ/CQcah9zCqBEn0SnjRK7SXr 3fb3wHv4z63fNv2p6ZalnqIn4aRBAIgroG5V4klViWNGp4LVTUss3KTEWpPhUAgZsAB6jpBh XES26Qa6MsLJkGlAizGgngxTcQFgWDwec01OKNjsMOxFVXdvzd+QU3VLd/SiPqaX9Gkd6mX8 7TnTBVoESW5KruTlsCuzS8N1yazatvueJJcmLbkEKhTGllCVegJDqcezdnj44EHXW4JxkKrl LWrxluNFiAGGixh3CaNhiyIYrBf0H+9e9tSsJ1gasjWYIDj9hykCyf8BIiTMn4G/yPLOTfnq tWhyU7pywzVJ1defMdcFkviqmLlxBVAAl2/q7kag6fzG85VK9eJjxwS+hvfsXNbCaVo63TpS 7Qe/GOmMpiMIJTJym7MIJY0Av+J3kEdxH+ULopzt8fUIq6h1vtPkVMPH7DXfNYHVwAZsNdjA 7SRfgKPiYXIcjomnyVdhSZzBZrj3Gz7FyuBTrtwQ8AkIPRRB0I0UzWMANLNcAM0xVmA4gKFd N3gQjtPFcHxLYyOGfFULajnLqLRFO/S7NEnLplgQN4qE2LhMFYDwfSbiF48l9iFPmtpwfz0S SWSd7gwLbjPXV9x+VvLCHX89e6B2TnamUAsx1NfazhNGNOUK4hVMQJ0oL85/GLC58uI/Lgfs ek9AAln8EJHIgURz3Zi+8+gUni5N5RLOwiXixeqG/c93SckoNbBAj/2Srp7TyD+bQ98BmzEc 61u8R0wRv8aWYSvwrzsH+OiZLty/uRv41bhdKlxgr3KEP+WfwCa6TmNn+bM5uskf7BUKpQLJ RgeoAXq1urp5oNcpTDUxnBeqWHMf6Of6+L5c/1Mre/tWbOV386fYk9xJ3rcl+GoQjxd2FPBR pgvL5jvbOrLXkTZ4MM/ijaus7TF42+P2Ue7NCWjs4u7sHfUQaq0c8ZCePMLmTaeNtzeGd4QP hAkz/EoYD59A3BK0GLTyTh7Pp8mxjlIH3pFrS1tlYo3TSPKdNzpAx6iGdTV4PNls13WwG2vF NPRDAa+NaXGtpE1rpKPNa3hJA9p1fCUGMQlJRtyWymC3E1NMOwMdr63CIixBQoBgHoIiBHDl 0ytfrhvjg+PjqfUoIaYEN12mUJCoy4DwYBg1+37l9rBw72Dh3jj6NNVou19JpUyUO2skrsXK Z3PLoy2U+FRPdw9OswzH4PS/qK762CbOO/y+9+3v89k+2/HFPsex49hOnDR24gumMdglWQZN NiAEqBsLEN2mosZuiwrrhCnNUKAtXqexgkoDG2UbSCMLCU2qbU1XUWjLH9mHNlqtIpOyr9JI qUarSSzNfneO1u6k935+L7Lie5/f8/yex18n1xFM0qDIyFprk5Bgs/hMEq4LrKEVCaW4hIyT CYMg8RI218Gtk0lLKlGrCXPVVUciYKsPA9+B95AsIVYOTnQJOA9MjiKtq1rh1ZqnV+YneK1c NSsdMrxslf9Q5jMGg+KSDYoTFjiZpUyNAQyYQekIq1UPVQ9VB1WnCcWXr+0oHwRJBv+eTHS0 t3eAJmju3WmvPtMSqlMENy+Kqo50ODSvb4XvgIrAI6L7+fr2tUPf9ja+9/G2zV3BEBEPBePj YwcfXCMJeqeFNzrSw3tbO/EPY325gdTGZ/dZ3c98K9uae2qgfnRvXV2ss/m+RNNApdG3Pjry +TtH1thZUzp1Mvd9nE+7YwWlZwghYuXeygI5Q7+AROiMpcwBPoTPM1eZKfYjH0WHsqZ8uxx6 ktxPfZc8Sl0gL3FsN4s7OXuDaZ3Na8+5nEZEeUQEGcG/nWA9QZ3B2+qjKzRRoMv0ZZqk7xhF hFz1RiNv6jcNmyomqgy3cROJTLxJNrXAx1nTnIk1Qfu/lk6aCsHffFVrrCi0ipayoJWW86VF NWwtlrqsTuXTxf/gT7XOCbtl0sCGZNIr4xq9S0Jul8EocbDzUX4Zuw0eCdUyHhlVRXw1qh0+ DP0ALaCOAgABQgFbPXlVtOvYhmCb1apC0r6KGF4zcvr53/3o+KX+VwcsskuKmLGtqW2fsvPM mT3JZJj4bOaT3979Qbmzk5x6uaeGDwwvh5f/fF/bjTfGf+Wxg2JvgBPuBZ3x42cmOQoLAZXp j0eaEiignq/TtI0mJNsWajOEnC3soGdQYh+h99NlVPZPeq7Jc/I8+iut68DdeMC1VRoKFFwF ab+rJB0TXrBVrBXXBXyeuBy4gt/E19nr7n9yC9JH8l3sYoheYZtw3HdcLgeWAqxVxr9cmUcy LB90PKpFqka0AHIFf9lPID8PQaofgtSwv+I/6x/3z0Kkmvcv+U3+vbW3LdhyXQzq2FqQIdBg tWRSglLbShr8N31G3Gc8YSSMcR61oAwqoGFUQeNoFs0jnfqAQBcfrzlSQ/TX4LEaXDONjRlh icGI4ZnqBKGZbF12hvge0qAvFTct5kvF5WJ+oagBH412LS4WNbFZEEA0UqkUTkF6UiFEJc0I woRwqeFjCSISzfMKVp0vr5J49hd8lZsY5kURM4A1kUwgDXj43KANb5WY9ioNyd7grSMv/wPj yaM/b42t8VoNgcD9e9Z+7dzorgc7Evihqbcwc/sWNp/YFIqHHPt93t5d587fyzYfADah3MoC RQObfKgJN8+gOISh7u5EXEV8fbQ5UYg/TT1NH6PK8cvx2TibiZfjBIqLEUd0K72V2xI9ybI9 LJbjHfpu/YD+JeonkbNxdja+FCVkGcn+1wE8A6jSA2m5T35Y3qt/VD4oj6Ex+SI7w74dMYQ4 W4NxneC15Ry1DeI6yVub88HXDFTMgSDTsb4YjsV8pMGHDH6jrCq84CiIZfGySPog9RLincZ+ Rg1w4eaEWl/rTjLZ5uyhKiFB5pdLeRB49YI5DmxcVPnIa4RE/Be8rAlFKa4hGOIaZRSl4BZm gzKO0DGNibjKwXxKhRFALOJSMR+NBpmqLgqgi8kvqFhVRycdSFqbif/hRFzPlntPzv/7rQN9 QMmaqAlbmyx+0dNk+HypmUnvjg8+sHP80Z2PbFh779o13L3pZ2c0Zt778Fy3ZA0U38G3csNK 3zduvPsnFbWNwNDN5Diyo1oim3ELQ668u4AK9j+StFuWQP0lRcxIik+FUZ/tTXA+lbg+7aTC Ce3xzkhzwsO4dYO2h8Uh5w7XzhoWkzqG1XFG2vEVZpR4jjlqPMaP1P6YuOSasv2BeN/yAX+X +BdpE2DmcjzLcwW2wA3DmB3VvcnesCyxRgqzpmcJUqfCzgDs2XbdBqJb1+fbQmzR7SJKxKht 1H3Kdl53Xj/NTenG9deJvxPzxrt6OzfHYsTOsYTMVtiz7DhLsd+h7KhFdKi/1SYowpDjkGPM cdtBORye31OYml6ZA15T6uizqeVWpkdQqFaD4SEP9gStLHuTE8MexSLix8RD4gmRFO/a7WUO t3AVjmjhTnC3OZLnMhy8AjfOzXMMd9HsoNAonO40GcsILeaMud9MIjNvls3kkhmb1V+ig8M0 Z73ZVckHL7FpuajqfTEPZREsA6/yv6RKQLRkVeLqDH/MATNcMxqqICiaT0ylUDGPs4OTDMIE Udyu2Qz10gb9DGLhnxkCijHTpJhgcao6hFWnrxa11Sc81Z2n+rfVnb6601d3Om2XMesUB+9W 3LJVMcHSOvr/hv92G+NU50eHc1VsBFVsgn4tgNYxH+A9e47uGGnyOd596dU7n1w9/fbyUfxT mnfvbt98hFhz84kndj9lH/0Lxu/fwex7FzsH61OZwzBH+hAiD9LPoSiuzdx/XD7lOBUic2TO 2OMeIUeM9GkKx5sO+StMhR3jxnSv8K9Yx5t0PMOzxFBkKEpInHnSy71Yhye97DTJZXwB75j3 DS/htdYHnTjaD1ayJdIoWBmO1fMA+jT++pUTYB+nic8mcCQ6jfmMKdyIBYuVf9FiwfUqgFcK hYRWOzurtaurWutbtZoRJX+iYsYq7EPmYfOsec7MmN2x10mGZKtin68itWkR4NSMYxrK3/IL JS32pdPLpXTXMhjHeDSqaYsQbLCLoaAjFBTDEmqw10t4VVFUGUGwvhzP2iGeBZJt4LY0u6Up flXwwWQ52hz4ghS8f/Pyh43h9e6JicGp4jcHOxNeZ1uvzxdqzkgfkxuXL5TrYvX14dwuYkdP evTXT+aaUt6kf5/N9l+qqzW2besK85IiZVG0SOphkrIkUhb1jig5lmTRj4i2ZSeVY1tJHLuO 5sRLAxTrHpYNJCtSbHOabdkDiIUV6ZBkqA0M64DtR5M0yLxhWb0gKFBgW4wB2zD0Rzus6xZk Rg0sC4Y1UXcvpaSZJPKIl5eGdc75vvN93c//cXgfRmCDjTHiXTjf+7FnsDn8b8bLzo7K9yMX 8wSW4qr4qcSpQziWoDTq4HcVS7F3qrrYezJSq65aVsmzwtfF1dx39pwdXR3/5tQF4YJ4cWrD 8nPyunBdfCf7zvhmdav6fnWn2ulVPD1czp2Xq+SP28r5YifWQeSD5U5MGnHyHOtoZ+y0zeZy uW1tUMg7w6gEbqaIomGHznYt/Eb4rTAR3gCvGY5nkytB4FwLvhF8K0gEW1vNCHcG0RZnvQzK BlwtG3CpXHED9wZou9GWoy6OgJENottgpDKdlkBFWpFw6Sb+e4zCbMQENgBv0ZRVOgAO7NrF TvyKyEBBEIBnHZsgMobIZcBiZjWzliEyOV0jVqbBdFiOgRj6P/2CN7saA1OxWmwzthWzxE4q 1UzVqK7DJJBVs5nsTLbqWH11DIx1Kx2A7ah13IFEtIHfNFwXi6DYnSEqBF4hoGXlCJxAv0jy Z1G8AZ8kPnek+gvwIpRh9NVvQ1v6IIkkpmlMtpc/4JJLDyDdLEOZ8QHsyW1uu8U8jz5EPFTk tpe5+/CAD0EugjR0/U7wvSA+P7d8fxsOL3Qdfi+MrlEPt1wtOgCKj63O6fHZvlE15/MLIiAj 4d3dPd3ZboIaikxFtHAiMhOe9gFff8CHjecmFGwYFBVskCz6sEpqwocdTE4roCSO+cDh6KwP zMz6+zrh9s5+bH93WQHj5VzewEcUyBR7LAM+MJk+4MMOxQ8o2Kgw4jMlcNMZfXoygfPklYAY OmM6pnlEpksmdRq0xsEeyHFOZJF2rjpNLTUHIi0HA5lNMBU0FQq1BJVpXwTz3dLWUdMCwbf5 FOiCG4SmwI5GAPX0FbzOTR/57frZhVtJB0GRBJv8cuH2j0p7d8nBjK/2u8H5xRd+8PGvvzFu 53PWY9mkDjzlE6VsZf/x0Z7Gf9KZvhM3r/+0J3vpL2Ay/srct24bJGUTvDRJ7aut3HBHdDev WC0EaWuvHVx67nuzu/OiGB62PSd3y6Gj+LlTp1+bHV4+vXZk+OGZnmfDGXXP1/ZlOzoscKhg 7ZB9/wWVXR77r5EuGIkcXViAIoANs5GVQr1guVLYLGwViCQFKoWFQg0tGQWgtInxAL9BsAbf lYoHouUuOh7gyqFgPBDZIByGFspFtaFsIFcCSjSPYf5dFiucEjzP0ZKo2uo0uEIDlq7Ra/Qd 2kKjVg+nsKCqyalKaiFVS1lWUvUUfiUFINmkNlNbKUtqofd1qNi4B/PIQT0ypymKkE9R2aFm G+D1polCVTf70u31kW1UuDPiIyUfsLZ5rX5Eqy27BJaWodKG6EgCHvFo07XC6rY4theSrCnY KKsp1+AqFNKPF6GKAxOLLw9N1jpdDjpjNPZ4jN00IZcy3S+UPfpYo28w5BZZ2etJO4CTPP/o +OnRmc8YP2n8chaaLVWNRrhJUHr1aDo71fAd1WRVddGFGWKwqeigvhiAEs4KK2PHurB3Damu ggW1ptbVdXVHJRW1ouIGOqmID3bvzpqx0NeMqUwzhsJmNDTJm4UVc5W72uMBJ6xTVBpSAsES IzGuOgUoHcO6GKvLSddtwKYjark2kkPBYIs54vMM0y61q6KR1EW05s33ZesiqIhgQayJdXFd 3BFJ8Vro2g/N+iCRso2KArX1dnPeQcaBfMG1qgOljYlMmHtkVluOBWHI9STRZp6jjxMdT/T3 JxID/V+VuocaIyNap80a8PpiDuAmz6MbA4lEfyP4SJnRYWa9A4fBZy/sUiRWrcEO5zHMwsA8 9uL9xiesLuu4k+IA/Lxiu0DX7XXmMnuJv+y8JK/pb9K0LuneY9wx/pj8BW6RX5Qv47Z7gW0Z X7GdcbxNvM3exe+y2/xHzrYiXxSLckEp6mPsMn2SbUvjCU4JK5G0Dl0cZ/Vwh8FBblqxhLhZ MMt+yP2bI5/h98m3bLfov9KkYOvgZL8sj+LDLGXnWVe7l/GzAYdMHSIOWw6Rc9w0P+2iJNbv D8iHcAvHApx3ulycJHsDkgYxF+2icVuARpCLhvLR9FAukC9haczu4jhVkd0KwBWZ5eBswt0A 4AA6LdlgXcASxVma40S6F8OEDfBPY7/I/MZupymYbUkSaXuGWWHwHQZsMe8zeI3ZZHAmLQhr IhC9sg50iFJMTacxjdOuaJvalkZWNLCi1TVcWyjoG+DFN4OvfwkOosn7S9BWTaCJM8ktP0Bf 789D8D5B7AC6VRyQYGek0TARdIjMgXMOTUw6vsLdPtfW+oLBDWKrd7htwG02z+fQvdtWK+ym 5eUlqJHml8G8+cKWsCVTHnOf/MNwQ5qXY3BgwcNvwPrHWB1HDW7X7SjwOtsMtmZgYLjK62aH NuUvgHMBqi/E9NDARXNBD0VZrS5zEqBezSOKB6hzhSZF9D7NEVN3y0xbMALOH/zi0L17x7sy qrSnMRLpjDX+LmkTDW0s5LGzDsXrSfCAI88/rP2h5GQYtx9XFFzr/3PjTy8F0w5aVYHHJfSA 5xtbcwURqCpvF4IHiOG1vZ18CHX5IGQLFna5B7v8s7qwKewIhGAq17Esikaf3p8FwrX2E/mK AAyhIiwINaEurMONViYesJa7QDxARUPuaPuQK+AueTDMStEYUNuZ1p9hTOjn+rN1BlQYsMDU mDqzzuwwJHOt4ynoNzm5OPAp2OHQNcUsxPr/4/txjl6SsnsbxaLmdciiN8YDnjz/8dBMwW9i mTAu7zUpsYllKgM16SwoGb6sdWvuow5iZQ7wc2hmJdtBfQ6OJiUeEDfwh9e7euOB/zFe9rFt nHUcv+fu7LPPL3d+t8/2+Zzz2T7fOfFL7MRJtlyaNGniuPHWNY3TN6+EFdZCk1R9pW2sbu3W MUjE0MrUqS1ihWloS4YmSBEdYSuwqmMtCIbKH/xVFaI1QkKTUDXm8pztpgGBhHV+7rnn/rGf 7/P7fT/fJJwohqZhkR0YarKIrAu60zu8JLKJRcz0Dt8jsv1wojzKb44Uep5gN/fpxLaCkhOj OoQQBka3EF2yRpCNpIHQ4hpioD+ZcLvIksvF0JZQMMGBSW6BQ7lFkFGoNrFZCrUn2sBk20Ib 2qauOQtbekLDw4FCsYBWCnMFFCnQBbSgkpvd2Vooj5UW0XFYLjPuRTBxSi0Zld1goaghUHW3 2/Vb18b1X+y7g6i5oUtND/Aq1GpHBTKVxJBV33vgfE0hI2US+HDIGPQBM9VkFtY6HzQ+CcDm C49qzfj+i/01jnEtUxCE66Fwq8vEGl/8t3adBsUJa/xL6dFjjt3fzA9OBZ0mMvtItcvWGXSR uDcymtkzjKKOjv5qcjhn0ATlkWxmU9yTzFc7u1NMrbVHKGCX0LsTVDg2sfNwPr+541j14Cjn hDbponlLEbww2axkNhikar7mnbAgHodrScUvt1Ud41lvKOTt3Ax2nJWDNRuAZ8cISecf8Oyk gU7pyEDS0WXUU5PIFDPlzGRmLqOJ40CpzSvwaSGjXcjczKALGVCGC0sZzK9ziixVhx5RZEND TTqRNQ/xfpHl69CTjMR6Emyyz4fwqTTByCgR4nmKMpMuZ4iY04EFHaB0k7oLuhs6XKdCj1dM +0OxgFgUy+KkiFfEOXFBxBCRFlFRLTc9PCZiubUOPtL/Dz5WtwfT4oIHc/mARuvWMA/Eh9pv n4IXBB9YquB/Ug/Uce3iw1pNg/x3v5XfyznNhuS6aqdNSZN4T+HQQYNZlc/en4TE01Bv5b38 aNex6pEtAU+Nd6gRcOj41Mmqf7vTD/UZmABPXNrA1NRBkfX3b2OXoToU4gdjynprxQF+4Pyx 85fgmv6q/5Zea/0LCTbo1zu3OE6BF/VnqFteIqCkMnigF2p4IQB+5bjGoEoADOpoASFcgs5g xdUdlGD7H4G64uCmOhbxMj6Jz+ELuBa/a1RjoGK8AA2ul+3Nu6WN9KfTUmFFJUwpvxDdlF8o Pjb+tpEdfDuADz4+PnYFMd5fQnD4Ddxfam9vL/WO/QxhsBSCI3YstUwve9c8wgItwajVvVJT JAv8VsEcRgVfmBS0YQtl5+A/ZTjg1MOZm4Azm4nmgBeDg8Pg4hCPBg51/1n9wMoFao+FEoLe McVyAD2gPUoeNR+1HnYecB/w6baXoA+q+Ubvoy05L/w61HhjaMSblBpqtI3oks26mtSUYm2E FBS5eWLPwRszN47uPv7hpsyedRdOPnniywPY/Pnn5r/2z8qlr7954t6hnu7zxz6o/vni+5++ WIa63b9XHcJ+CnWLIDmAKyfITlWPHD1Ib6XPWPDTMuiUuzvz8lb5acvT8n7dEcsR+VndJWJZ d09vSnSOpUute1txpRO06LCoaLXB3u053WSDHTzCI5HgSIRF+lCrFMXwZjoLsiUtgRLNgtng cZtTyQA5R6JlskLOkxj5CYfaFsFuxctxxeBkEK0EARKkgwvBpeDNoCZY7ngv37CoLrpWRNMr qk2tdKts6lplU8xMq022phnXkiFMOqE1bAwnhAyR4kCLCQ5pfZYDSUMzp4bPhji1NKHmSwkT 0g61nbpWQ2LkQZdMO9fEB029vlJttb1XuykKmPDA7MgL26aen3xjKBtNuXL5Kudpi9gcNM+6 BdCqN39l08Sjj21TxhItISw3/fGRJ/c++/uVczMOKl5d3pFmBQE4DckJbFcp4TbPVN/Yx3eM bXzq8u+mNrqtapX1VYdwBKrlR+APV95iKIYdpTEQr9kn544U46gSr8Rfi16M4wkmEeyOtUsj tMIowZHYBmmMKjIlthgcj+2U9tG7mF3BfbFj9BQzw04FZ6RTzDekV6mXmVfZl4PfiZ2XXnd+ n/mh703psvNd6TfSn6S70mdSjIvvF/ZHZ21nbWftS3Fikw006cwQPyIN/PC6KTaA8YwIxJLV wAt+N0FozV4vEgiYVXV5JADmAFoGFTAPMPBJOEk7ig70544bjr85MEev3DtTK+Op6cIKlBi2 SZUuazyy0v25KrQ11+iR7lDU5gq5whwStcFBcPIciNhFri6qapKwlKCq7RLykFvS9QSorecV pOadbVgjJjrsUM8stsedHqqmbO1+u3vr84Onfgvs7+fK4Y7MM5GJ7smL39vfuQ2b/+ypsZRP EGhDDtrW3pG/X18GAsf5Qp+3gLdg13z3F5eX0tCzTFC0n0C9oshryj4IGlQKTVEKqlAncUKJ gZ0xEFBLpUY2p/lIhOsJs5E+hDTELHaOBri7ouY52giMJQxDCMguO7VAgYGvORADMcQSCgQC HKhwcxyKcDRkmSXuJqfhyqJK8HAbV2lk+vZUPcnRK9Mr2y116sghaxLdtOopDtVQ6mmuwQcN D/lPKh7ef6RtQ2uI3+KwOuIJm2ndo1Wpv8lDakw8E4iQwIHNf/RRrxzJrreLO6qDwxFoGCFn zfm/cPERXz3ZTdy/jf4B7k4S0yuiXvbIqNXarBhyctSQc9tLxvHwOfrbIQ1JkFFSLKcn05W0 lkovAk55Dp7366br5quhq8If+Y9Dt+Q7+B3+TmhZNli75e3yV+PH5Vkwi85iFUeFqXgrvjPx 2WYTBSiUxPRGrY+UP2i6xut8mNNu9Tn9HtErv6J/hTzHvcS/FDJYJVNUHpJH0jvTh8XD8mnz 6/x8+q/YHZ9R1CVZ5ArKggBogZlsEUg/Qq40LwJGscTcrOeKl2UCDKAZjkEZ9aXnilN92WS1 hniTAacitZuGBb9GmltiSQTRCDGCOQFz2yLWr9idLaxgNaAfWsG/+K762LjNMu7Xvg/bdxfb 57uc7fuy4/PZJpdLluSSOooWlzZN2i00DFgbIKRbqUQnkJKg0T9oxe0PlkQMlo1KkBa4qhJ0 CMHStE2vjUbTCVAl0FoJWm0I0f0RUCd6o0NZNalNwvP6kqkIxJ1eP69fv7ZPzz2/jwdFr2u3 tX9qlFalYm5onEMHuHFulqO4KupyZVORi1ka0YWKiQ6Y42bZpFSzzSTNy9AntiP17BNb//9Q bXLV8xxrozv2L2xoaHTEaQWFWdhAMAUOra3AdZA57EZW+NqmJU04oE8s2J9cJBSLRELQ1nnN 3IhE8HdXa9Cr8bXVWn3uTT1Mpiw7q/JCIJgVwLYGbDoFZZlJEUHLn0JbwMQeBh7OPAje5+8L Dyzf6AgYWig/WJQrqEJWqEroRGQ2PqvMJmdTc00/0CstYVBGsLwEiCdsC7XqrbnvFE7mThb8 oyNYLwVLlR3Gkh3ksg4JI4nbQdZRsImQWacISwVvME6Yz0T7GlR8AHFdSDpekJ1cdePOgujo 9QD90p1F0SlIYv1Z0fqzOGhF3Si8IuoU1Ci+557LcbCNcyg+Au+J4Afcc6MReE8E9sCQBG8Q zf/vA7kZAQgK+iYXQXuaqGPRkxdd6MByg1vYnKf+WKKw3yNntfyRL+56Ws2Ovfr7N57/7Fe1 eCKiaamfPNu/75n1v7a0nPxm11CHwEfD1Ovr177/3J6WbZZdHDh4+thchlXQwEvf+7TT/6XZ HmffxA8TXIOEvXZs4wOy13eVSBK3LhGRjTvu9rAzhsZIsi89J8zJV+JXGqvyHTlYSaMZBe0N 742MhcciH0rgVeOSKVGNcUlWKIQPseQpRMXbfFWUdFOIaiNJFAiX6AIXarwev+2x/qFY8g9E qIruugUVqK7Ymp5Pk2kCIZ/Pn4sNi6gsIkLkxXlxWbwhvisGxAOpX8xsuYE1z0bzo6uj4Nig 5MFYr61gouNrcGkFAdkRnm481gb67sn8ZDMSOuK64PF9d4enBvmSoJe6gOW60Z5btzos7XHB 1Ms7i/s/8Ur311sStu/q+h93rf1q5HHbevZgx9hB8ita4+HB/CHIFgned406ThjEX9wSMrEY qyZG5bzp6wx1Z3vUweyg6ldocS/2RdrejGHqtIm2BzP0TjVkpOkq6ndFljAMIIJAutDQwIbY UEhTsWQ2EPMIcWgcVdB15EO47TCispKLRofFWZEsw2FepHB+1M0MQX7yb37rPwUACAAyBYnC bUet3npgsH/ceXj45ZMpTkhxSorghSSfThFe1/HCC1CXgD5PRNu7E369tJUyEIRgSdtMJJyZ JeogpzVmzYb191u+cbR/aKKQ6h5E20f6mr/2hPN56vjazcpAStAn3ix/cuSlMprb3p5ExtrJ 8nDXk2TwU92kAfkUIJ81yKdK9rhM9DPsfukLMiVXN95eCJWaMAafiZdickzRmSZWE9RoTlJl VelhHLYn6kgluUfZQ+9mdrL9Ur+8WzlM/4ieY36snEhWmn5OvEb/lDktn1ZeS/6avsAssovS RfmyspRcbrop3WfvSw+UlgqD8FvOtR/o9GLzY/WYsetxYKAeTbMedb0eBcGLriunOrmmo+A6 Jslx/1H1Bf+3hZebmB66k+2UnOTvAsva20pwmp2RpmSqOzookaIUy4hEUs0QUVbIRKsbL7oF RpFVSZbbGDbGMGxSUXIMDTM6GPD7fDQokBgFlSACihySqijtRsdYxLM5tsIusn9i/ewxJomr h3cDrafoS/RbNEUfY+TnlSWUJFSCgd/LRTsZ/LvltBcX2ks4XAyXCGaZIZkqurLIN6FyUz0b sAvHRU7s1DD4ZB7amMnVUUxdypr0dxmKTVpVajhOSrW62fCKDCNwqq4eU/6i5E2aQUZqiF9+ 9AgmZBRaty0+9GquGU0Cu19g1cZIHw2EfBEikwN7UN14FziaheCyokOrQNIwPDdPeFQqavE6 jYqi59DzekmLB8DTIB3l89jVo9dTph2/eStBh5o6UXNnTE+tL9nrlxqtrNBOHTfyqt62HiAj 29INDBcyDJ+Q2fXwfcrf1cozNGbJyMaK/zzUaYFqOhst4r8+1VdqNMGICYapFseKh5nx4nvG e9ZHxkdWGG9YEEvevmvJbKdWLNpf7krLcjap80Ufm0/nC3kn/7nEmcQZ6UyeDhnduW5zL/Ek Ggrupgdyu8wha8ieDpb5svBdY9qatsvFE/xxvNlY4i8Zl6wrxWvGNesd4x3rRjFL+H3BQNyX YIygyVgBu5TYwe8Qhv1PBZ+WnrJnQi/z09KMPKNPG9P5cjExxbyYmMpTEWYEHeGPCD6oNMiS YbAoCLXGJ4QMr+paRiXsQobg2IYMl5UzmSyU6jnaMtXqxjHXlYycSgdpJpizrZhtW5Blw2yj mRhNM6ALcjzHGjGWNfRcrk2SY5Ik23ldBlMLVc0SlraE7kJpZtDdc1nECfiMJxpAFViO43kw uipB4kVEFGALlL60hJ4D0qXRz1zOcuHH5nJWSH3IHWLBmJ09v0wcsvUqot24m2wdltEpGb0h X5dvA5e8mmsF0CQvqpyBeAMZuMBD4U5jCfFEnogDbsIu2zqWR26+nCfzIE3nmWNmK30ZwEOD kLHQdKCydc8iLbj1AtxqnQp63euwjco2ImzeVm3XnreX7Rt20D7Q8rFe1VabRydkpba2As5p YhMxsKTAAlyWVhQQMTwwhDCAFKxk0P5A6N381ue1ulkDTNWx1QDYordARj+60vy/4PbfxyBP 99K9HgwnEG6eJrEtGW3GCMzzsXAfNjvnIIoYfWkn8UiI4XBvIeEYOMS9s7PxOiDxB+MxUIej idFXB+MWPDfPkU7V0RlBZVCV3/y2UzIbe9H5wUyMvnE1ZjpI22evv2X/bf1DY/3P6W29gFJf JpUtrH2AfjnVm2igDINK8HosvvYv9KBLFTOkYUQOP/wH+W/CqzW2jeMI794dRd77jiLveKRe FN88vsSXdLRknhPb8YuyktiJ44S1C9u1XRu1pdpNUlSQ0FZR0gBRgSJtUARVihZN3cBxErWy Av9JG/3Ijwbwj9QwgqLODzVJiwg1CtUoCovqLCnHcpGgJGdnd3hH3s7ON9/MztXLNLWzIELw BBCiPwHUDtDH7DX3Ng7PiDPSjDodnS5e46/pH8Y+LLByJspF+LAwxp3nP847OyoZ+WCZyVQd VaWqDkSrcauYq+zk9yp71e1dO6N74ruLduUR45HISOW8c4KfUCbUCW1Cf9E5q8yqr/quRLsk h6zIqpzqVrrV7lSCS+jZCqdU9rMHyyMVJgpYgE4rViyWOF4QCj6OdTqNaLFULJQi7hktq2K1 JIiiJnSOGyNduCsbOROaCFGhmRAOGZFMxiqk/5lIxAojsMHxEi45HM6I4XSGSxFPqRQRtFgs VxA8hYIAvvaxgl6IRQx+IGsnoz6OForOktyBO7q7U9lspl2hBoCIVJWwS4ZJ43S6q6uTE6BG +d0ZDWuZyAKW5noMbJBMJigl23jD+Mi4aTDEQFjFuEKVUQE58fG3SpkYIHAOFXDhCvV7ZKEK VZsLvg9gMG/VoWtQVs26OboMtVsr2ut3WANqleagDNZJq9os4kiwQxsyLY23QptMsM9tjWd9 nylLdbgsu0QGkHq2DhaluVS+8xnMnC5lUBqclpTB8cVFohZdi05QLrBCyI/V64RxRtEoRPvb iIcg5ix+Ye3fl1lLJ60CzD+dA+0FbbMdalW0A0rVR6ywINpu16Wqw3bzVacPhjKZVQijgk7E ZfJrN+dlK9IjE966/pZsOQlyZCsPal6EL8SmhbQY0R4iKthUch9UPk2ugyakqdQW8wVES4H9 qyA69COKIlsqSMr2Wu0tGGot5Sbc4yUNzE273WuVXV4rnvNYCRDVpVls88c0K2GrIF4rTwT+ WSf/DkJuf1O9C+Z7X//b1uB7viDAv9PO9BOo3+FhZ7um6d5gKU+ssRhJBs01KcH7CV8H8KVE MMRrW3bv6I3icl+4b//40r4dVmMkbbTbz/xoazrd+FM4ED34zuu7HhyCVNCh+/JK74kTR/ze TkgEvt6xVxsLT/fR4bBH0vX64uLjqi9GhcMOT+eTa7dP9xMOFxrb6RXIBnl82n6NVeCoJPPF BNVezGhHy99zTLVRLOtwuwyXnzU9/igbdof9UXMAl92lwAPuE+wJ7qTxNf+RwInUU66nuaeN J/3nAk+lnuOeM15CL7E/8f/YvIKuFv/aFgJCNc1UMsnhZvFmkIovlV+v+KKuHsPvzyU5D1yQ Ms1mrWcm4Zakn2U4Vwq0ATTpCq1XfTGCPQmeNpYNWZ1yUdf9BqG6wAyHb3A3Oeowd5b7B0dz 41V2L3uIpdlxaDIku9O8JvdguWe2h+qZOZTC2VQ1RaWMQvFC8FfQMZjDULzVluqjS6sr0FDV R1eHtx3b+jGq1laXzBYyAYS4iUTXBtoBTVD6pSxzl1nwKIGZ+cXVWbM8a7YWG/rbfhxtMoaA X/Om08Eb76tOV6+Jk5G4jzUaz5cvPbhpT38uaMW5rgfCWxqX5aCh6AUIh1hnbFsjj/+TiLtZ XoT6zReUqre/MfXs1lSyoMmbH5ul5rozIUERIA4SwAqnIQ68+JA94HYxPmaWmRVnpQvMAuOc 1bGonxf7yiPogDzipQOMLrXLX2Eekm8wV2UnuqUoW7xdpIUN23mH47dcF89IshymGQ9NMzRP MTIWJF2kZUpiRhzYkROFNuWQjOUcpjj5CrUZSYihNtspGmdm4WkyIyLOibZ4VqRFf1av6nt1 WhcyfAlRmDI0/eetFDq8MlpbWRpW6rfg1FbqSwq8IY+ujg02BwuOpJk8ocsDgRp8enzRh5Vl KKz+ta5I6kNjJtTazbwnrV21WchydA4GhgSZCBPZJquwZskLa3+e1ywm7iHT6/MeiznrJtMf zrstxucl00/nvTCVm9M35XuTBmSExzAdLOFgLznrUH/Qi4N5gnj6Cf72depw44OvDrYHmHgb jVZ/iodP7tYVHhuNT8J00gjldzUitz8IpXqOo7U1REGXuOoYoKLoAADZiV5AF8DaY6sUfieL J7M427Vph4kpKvU2dRHOF/JSvV4CDyKLOUyNOSzEIx3tBJ8b+2JHy4I94cZuZE+04TYD4ETb V9mPoA2aku1D3jNeyrvPt++gzxyG9qa2equ+DoxsvbacrS+DF02c17ye9dgNbphTbelqNZ22 7cYfM1U7lbarDstOr9vWNYKnup8+Tj/sOIU0lEbfteMYSYxPjwS6470ulY/bvfO6avPzSKcR nYXnkyPdkckIDWSctOVA5RXY3ruy1C1NSrREbCxTueTBHiOTXcDn5oLk2Qm6a8urEC0wrAO7 WoNKEz6tMMHroWLBhlrlGoFgYcNuIl9sxtsP7OFYUUy5E0O7+u8/PUU9fszmeYFPaYmh2sB9 X3/GcSqRObopJEryUCq37dz+oxej0coTmzskSdlk9u0Y23/yIjnVdS9gGi0ixPwCwZ7P9k32 UQhTSZocYr3pq8Yi/TB6D84vi563h14OvJy5kF3Ivpf9W7bt29J5/QfSlM74jI4YwowcdCUF 33zSDvNo3m0LfF+1ozKSxnK6Oz2ZptNNB74Sw7F3mYrs7fZOemkv2OZkI9e30XW11foynHt9 bBkwtrwEH+KojR4brbeXys10Fup1fp7FiJMcX2L/5rEqx4ucpmnJwVr/faem8ZFHaxwniJqu giPLW09PNRaTVn0I3ORyDZq5HWOPnnw9nEwf2xSSRJdrs5nbfh5ciT5/fev/C/WbltAZkDfu CjMM8muEHHCZYwyhtl8i5HwWIbaMEO9piQBrceVekb6PkPzQvaL8oSXuvyDkBdFHEPK9gJDf h1DgZwh1Hkao6+//Zb/sYZqKojj+a19pHsFARTRgABvFUj7kU6qUIqBWWrAVoYJ8iKmhGFSK oRASNhM1Dg4mkhgJk4OzEePmQoyTJg7GODgQWZwcSJzE1PPoEz+iASMDwz0vv/P+9/T03Jtz bofCnhfg/AD7PkLRGyh2I/8woTQA5bkpKiagOg41c3DQC55uqH+aouE9NLr+TrPUapF9j02D vwpa30JQaoUiEP4EHZ4UXfkQsUL3EeiRmr0z0H8UBpZh0AFR6deFdzAk5xt+DZduQlxyrsqZ xsNbjFv/TqJw6zFRJLT9H5ODCoVCoVAoFAqFQqFQKBSKn8GKBcNy0Axl2S3YWde0VZ9OxjbI cmzP3pGzcxe5eRIrKBS3l6L9rmJ3SWlZ+YGKyqrqmlrqPIcO13vxNaYKHPefaA0E29pPEj7V cbqzK3Kmu+dsb1//wLm1PZ7/uuX8k/WPtSl2zXA2Hol34RRlF++ihFo8NNBEBz30McI015lh xZnvLHAWJpOSb+S5KacOr+S10EkvUS5L3t0fecmlPz8040zeWLwnz0NzKhsxbd0MnWGzniZz xtQ20TmmtotyGzfAli4RNz5TW8lkyNSaxMdNbRM9a2q76IVAOBAK+ssiI6OxRDg21Tk2Go1v NEaAsBAiiJ8yItLZUWIkJBpjSno4JusocVExLjLJFVmNb/hbm50nHUtzsCw9GiNNOuSgUiZN 2iu5AZqspTmWO/KJbhNlrL6/GbZmS/PX7PcxNYkZd4AV3SjzUs/UEua0rPdnbXPPfOezfJ/1 PH01+8FSwYLxfty+mPFl4utth1fPxPhJWlIz/SbAAAMMNfwKZW5kc3RyZWFtDWVuZG9iag0x NDUgMCBvYmoNPDwgL0xlbmd0aCAzNTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSInawMh0KY3j+sqVP+5FTJq0euvWM08fv7jTxZPPxDQjg5WRtfn1Nr5HUziXTsv+8Pz5 jRvPjFmY//z+Hair48/EmJXVb2yQs6Kvz8tr5qPbtxYyM1+7dH1PeflmLa1T7W1XTp48lpLi 61NxxJyNmdn/84ePXUFBhcbGRzckPD17durUA9uXLSstXdBant6pq/tw9+63r9+d3b+/Ii5u uyDb5tCQZcv2trgwnzu5dWub4OuFDOwcmR93Mvz+8jkycsnZRexbJCVz2K0Ob9r0bh//jPp6 KYma799+fLx5c25q6tt1DL1lpaH6TDMkJX5+ucvAYB1r51CVaLdr80pFRsZJGSYn1jRkS0o8 X81zZ4vuzSqOmKg6aenQfkPWfSwMJyNMnaSlns5mVlGqn9iQKSBQu9XGeuXCCY9OhF+dMWOJ DMvzpXznM002zZ376cH2LSws////ZxgFQxkABBgA03KfJAplbmRzdHJlYW0NZW5kb2JqDTE0 NiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDEzOSAwIFIgPj4gDXN0 cmVhbQ0KSImcV8luG0cQvfMr+hQ4gNzsfXEMB94SKIgNByLgM02NLAbUkCaHVpyvz2tSFKdL NZQQ6+AR9Lq6upZXr0bPlrOfJ3+PtJbKCYWf/ZeLUZrgs7AqSOuzFZOb0bMlC01GxuRTDV3w UA9oDDV0w0Kzklp5W0PPeKiRKXhTQ8WmYV/mVZZeJfKyLQvVXipDoWsemmR0mbjbsFBjZYiK WBU8FAhE4Qnx8lbJYKgDP3hoYJ7FW3VKWhdIwjoeaqULKT4lAi5JmxVJ2A0L9UHGrAMTLCWV 0l5MZuL54fNW0PMWFWcE4iKDxYt3LrVf2SpS+M87V4PnPNRJHQOBtk3DloZDvrXLgRge8MJG mNa2Bovdg99PRu8/vB2NP4mXL8cf3p6/QybFq1dv3r0dvZmMxpOJF1pMrkaqxESdiEbCLzYf I8kYdqxhhBl1e4h4+Ry8IyDFGtVQLnnOvdSmhDbIqYaybWCzlj4oXUNfr1aL+WzKhzxIF3Wu D7Bl6wzoILsayWfdGiA9cXjZbgRPi6hcrTPx4YqHZplsJlETny8+nrHxKITnQ/Y1vpFsRXnl ZQDh1WDJQ5N0mkJfiHb5fYhywGMkds1CsDnxLmCiaIJGDllwAO8YSzI+kG0f0WDa6ydk20c4 YaN9Qrp9zIDmh9m+55505J50ohM8Zp5OaXd+2l6K7prNqTbS+Rrd8HVoEJtoCXYtePJBjlDi iRjmoR4MWxLUh37b8k64LJ21xIeG5XDMDzzNmKf4EHV5W66hbbfh+yAFmX0gj9tsZ2yEvQK1 WkPeJ6YbwU8eRM7kJ/jsETejMaIq6OV8Nm/5iQZltevHxy0Hg2FAPT47VuCRi/UpLnZG5pzc 3fRje3k3/YINNXh4+hW9V0HXy5ZPvonShpCoF52YLdn4FDLEGHb1AZ67EZ+Af8SToRo0IeQa yhM3ajAmCl0MUHEqVRLp87oZS7Aue5miJW/7RfDZh+LxxhE//lnxKqNIRW3LjHw0gR4jz0CF 0pTwctk56XX0BMxDCydkUnAbccvXtgPYpKf4GyKgjqS5u+a1wr7k0bw2J39HS+zYwN+hmEvf 9sH83oLuiJBmNZSVNQ7j1hhLrLIhcLoIQ+rAcr24FNOBuQgalbFUW//EnN/gMEJR8MT6dKCR UhFBltg9TDtGH/r/JTx1hJhP4aTyDEPKEwV7YLvyOXgJEqBiMo8qz1xDxefraSdW04ExaqSB BqhO8KHENHAqEz/4HnCQRCpFXWMH561Kifi8WPCkhBGTdSTufr7g2Q59mMok72M/8lwHiaI0 eRq7N5bJvNPfVRBWPCc6cCKNLV/96Njd2lFBeU2ojEzKEF9/DKleox44O2/FAHGUgR8ztb2Y /zskewEJJMf89ldkbzKGJAOKkefbGCVagUTuqA7iUR3E4X7RWCZcTHZ3mNUGNiuwA5ikgrJl arG1xsKpFXQzH96SjEMvQmdVB/gtyUCIl7BXULH9wveLkSorT3z+th1e1QJ9YMd7jGkUsiYe bzfQM7wAylnqAG6t8KttN1QDRTB5T5wRP/GVCCYr60yNPVQAYnXPmOZEBWDTiX4vLoceUTRf rqE8EGuMz1A4feS2xebWDfAaBpoxNX7ZCixKPFvhnaDXCi5e8xRUtkLwyuM+Zw2hBenUR36Z F416zkZdZ5mDrqPBa32DYZB0bblrFvzOayF8c0l8Dzzna8SlMg1qKARc82t/quJa/IjNrB1h QdWY8aWHsTg+TxrcNrrqz13o3f3cVbt7dqeGhrvZu1IWulI+HgpxP9MvtqvVct01l2LflPdA 5CL4CvqDACAddQUorCf+qFFal1kBcdXDLQnEqAeQOTJZUKUT9E5FKHnQEOQtTskYUArl2Pn7 2rQN2GRKqfZBBOMsxo5LJzFeS20iuUycv65RWFiw+sUadVFjokU34CEVZkwwoXhE7Hx6kB5v qB3iNYZADtTOnwSDssT6dNJnDSqJDwyNKQgz+YGlc1oNZi+fTrmt0awgDHfap7I8GeLSfcnc Kc+e8CRFg9P5cOr3Zn1D0g3KCtHVsGkr3pI8ISypkFAfdk3yBPcSMbTqSA5AOdoTOw0NL5pE U5/WlSQ/bxfztrm4nq6ae5KI6o4kxr9fWPF1I76NSnyTVXZvekcx+6BAk+Cm2Q0s3Vjxbjn6 i0p9ZO7emoG1x/lGYxktHLaz3U/Twz0imGqPcMc9AtPjMBX32XT35Lr70lBsKZX+c3ti/W25 FvucUiT6Jnp8HLFLFofeQYxiD7duIDCvODD6EMqlcoA1WlY10L/pG2W9RB/J7HzfSwzjZXsm VouGO4BsSpNt34Mpi9NKGm/7hjfNQXsoQ7c1etroksvjWfF9vpl3L8R1x14WVXlF/7ndigUi KVbpvvcvxuPb21sO7FD/FlvVESt5GMasS/0EspEryx8Iyfdwt5uWNxmMDA6ysJfm9dd+Mf8n wADUURb4DWVuZHN0cmVhbQ1lbmRvYmoNMTQ3IDAgb2JqDTw8IA0vVHlwZSAvRXh0R1N0YXRl IA0vU0EgZmFsc2UgDS9TTSAwLjAyIA0vVFIyIC9EZWZhdWx0IA0+PiANZW5kb2JqDTE0OCAw IG9iag08PCANL1R5cGUgL0V4dEdTdGF0ZSANL1NBIGZhbHNlIA0vT1AgZmFsc2UgDS9vcCBm YWxzZSANL09QTSAwIA0vQkcyIC9EZWZhdWx0IA0vVUNSMiAvRGVmYXVsdCANL1RSMiAvRGVm YXVsdCANL0hUIC9EZWZhdWx0IA0vQ0EgMSANL2NhIDEgDS9TTWFzayAvTm9uZSANL0FJUyBm YWxzZSANL0JNIC9Ob3JtYWwgDS9USyB0cnVlIA0+PiANZW5kb2JqDTE0OSAwIG9iag08PCAv VHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDE1MCAvSGVpZ2h0IDQzIC9C aXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDEyMyAwIFIgL0xlbmd0aCAyODk5IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJvJdtb9rYEsftvMCnglo2lpBNgMhy EIrCgx21RaBrYcRTUrn11izSao0qtimXMt//A9z/HBtC9lare9/UUmJ8PD7n55k5M38fj7/g CILAXUfFsVfDTVR28xubKFILG7cSRWU1+BU8Zyq1XN4zmKa6fBHlywfqOqoECjOpGm7v3V9M td6r6h7L8rWrlTf58uGmjCEwbfblffnX+urI7tm6rhZtXeUoXVQpQuhW9ir7ab3XVIRTc38l FVJp78IxlTCnKp/TCU7c7svlCiLrbn9xYhVUL76KtCKEAIyi7QYJpWD4FFl5KIry/y8ln/kf HmQTuElzAzVaS6oj9tsWXgtCd7OX2zIIcsR95TLfw/Cn8/3TYkEoN8/lgz9HvHluKAXV+lQR 1PXWDUJVMkVR5ZRNbgVmSLZ8tpv5VfjfMyrBPwW5Oe89OcpVL3ReoH5ir+w8unK+c/B40SKd XG29UTdcKiogW5+oEONo46oVeeE0ye46r16XY/o8f3CUc5yU4lRYOFdEB+HMS22h5IPKrtdp OC9zFI8+PbdiUVBpUZ43AX5FKAT7jRtiG2qnsAUunAfWfIVrslMhV2405PIc0tCja+FwoAIO MM5hqChhoyFXYyoQzUtV4RzDBu4oNzS7hfuURoMdD0sZXSfNDNHYrPd/hgHnPGeTWpFuUplG QbVSCyxJhRtnqiq/cqNH9MzzXun0jGU9/el63HNu9M5TY9678ZrOzZxMWEiqPq0su5QJ53lM 3rVzQ0QzRPVmTPOdo9zo5O0cwHX0hej8+PYRo+66zNWpso/K2HpqkZOBupd1Cnhbhtq6l1RK OKfJgBaiMaeZXasR2YMUwRXX5KVdzxzTddecHWy6BhaoDmY9a5Uyq0mlg0kPuxJRvSYeqDUh vAWZd4cu3jDUaSp0ONakwR9atF6DZ13ZcMk8U3E24VQpy+QvqkNOhaSnVpLRRDxTqWoYmU5+ YtSobizIy9oelfzsjqaJT3UEDVT3d+RPSlk6ht2BJpZPs2pidcw4sam9IDtLLFA96XCpTp+z v6j/6YPsz9wMkVkvWw++U11OflRTba298hUWat2vzJZlY23DSJnKOlA9YaqqR6sks+ngH8x+ KphqFdMEVDF5VaC2jFumSk2vdm+TH8Nx8YnK0Ok+uScvBtWaM1z2mu2pkLN0WO8lE3D3xUY9 USGrcLSkkyyB6XxDHOC/gspPUk9aeJl8halRN+ulzKd+NbktqIyuKU1WyWpGeveCyvgK+nfr s4dkMwxOP3ONw9eosC/Zni80qMZx1ShRzRBOTvUsfdWXVEY6pyksYkMa15IVUg++MqsI8kBS WV3T82GSGUZ1QDXhnKke3+JtUu2lOLkFIasYhirqA2fZiaq/Wtw8YfXYyDLjjjy/Gzo63bWR 6bP4rqCyBLgzo5ohMpIqK4Eqw17MJnSAv2iaihYgsqqRdo17qll/oxJYUg2UopJykqPCa7wB yvvz+Do6VVEc5q1V69OMFlY6QRiuBDYhiTa2j+0hgmOm6uLODHtKZnvNsKa8L/w+2VQHyIBo YLVbZFInXZCOsZxqanh0n70lM0M53Z/UChen8oaZypqqXoyrBVXX5yOzrKq/8lMhrPh+1cb/ lY+h6SqLfcO6xX1H3oGFw89ULSF83LGqq5qfJUKk/iq2LANztEW6mPIYnHoLQzz8+NtXH2nC vaZY3kWSo8Kj9yB2nE7uqe/kvcGxEhxYxDL4hMWTxMBVYlhyKD/jhsOX/OOIX9IQF0IYbIGb Bj8lr+RURvrEhvnD6Zt3j49CCbVCRBV6ochxRUr4Yk8WdJiQD8fp3i7aOMnr039R3MOfouSX qKKKIwpD5zSmyHPj4bZd2Kcd86EwEeK7+uHDm+8KKz7I80CWJ9leiloKzbc+7cliPyi8gBM+ Y+d34Ah5rSj5f3lLnpWTZf5jFzCc82qMuw9P4fDYTjZwJX8YyyKj8yTXcg2z1jYnKc/pNDrv yePLoQSoV/UJ7+azUsjFwOVFIRygEOY64nN8GZWnJpmD1p18MaA0J9y7Cwv2EnZ/kU1RNEQ5 DdXtWRQjtqMNnKhWRpdU19jZnBKO0tixMIBECHcNXJ0vpH4MpUiE9awLhXDc8SiPNAI0vQ7d oS1wTYe4kHLB4UnkBK727ffNpoJvmW9oweq//+Tp1ErlhAVnLbEZl6MLKnZVXeb1E2uAZ8fp 6c0OjW+a+HPQ+a/naLpQBBBRV2aDFQJBIUBZYGA3vmrqeIGnDk3kblCac3P80PJuBRQHT9CY z5s6ffwddeDHR/r4LxWBgbQA1rbYk0j40Wg0HC6Hmwuqho66yPsMzbnG2qrDlYrMWZ366RNf 9OkZVVXvih51b23EaiqadJhQT+xQxfpdVHxUvkFbzkH1wa0OAfJgelN71u3qZNZn9OWD9gM/ 3r/5Qnd3/JZoglvVLSrCKIpGmnop3ZWdie7F4eM2WIMOHKCQ+0RxVqd2yk6IUckXqJtWj2JU bi9L2mg0mWe228jrTFaOVZ+11m6MdmxUMRNsp2jMq5TfeUqf330hPTYeP43rmWETXIn0H2pq yF+qQ/hq+frbS2l4KMLIzQdzFkMDeNUJcgStPzMGIOtgUqPfr/pMhQEpb9D6PNsGOKhiqVsc C2rH7F5TyUgsVh1o9bqtg5llg0+fH99z5lm/mTPbhhvwDL4DR8MNMw21TWWoXbrqyDnRMkRB dftCVT1TWfrfqCz0lUFr0KqymcVFwnEso0U+PJrlqgM09cGg5aNlSqrsPX1GjUVcWzigdfiD azlaLpdDKbu2y1dYCkQLdzin24c6QASzAajQcatZS1IdkrZpZyztjI6kYoWACHJbAFXM5eAY OiKts7oyfctp8Ewt3thJUmVfLTAjxB9Mn0wbwtLAFj2Fbshfqkj+4VK7rFdOG7Ho9JoC+RRD 3iWgMi6ovOkgd97gDgx8p7WA7cSfriyOIAv/oDe/6sBPkIderbnLM3RWu69ZTGUw1SeT7C9N MaH3X9++ffyDmZbD7XC45SxX0BzhtUsqEQ+gFTpWu45NP8iS1msq1t5QwBOoPkQQwoKgiqvS VnQLKtQr1qCJEWN8tiiBKjvMiMYptMcKvvpsWPdoIHbKLiD7zYftaDmEBAWctnGha9z/kF4F q43DQLQlByeuC0uMFkov3iXbiy8+LG4CZmF1EDnIEGxiaG1ZUNhD//8H9s1IctxuWQwdCHnS PE0m0tjzRBs3r3eUhC7Q4NO+oH6f/iigTnb6C0BPdaV/IykSBtse+gHAcQu9XTc70gOkPnYF LV2n0BkaH/AgREhekOZodlsa52N9bLZFXteb6nBwFzB6pw+o+QTbpt48hXe+3TsNQG1/7UQB Oj5VO78f2emBlwZMTfk+FjQFe1PWGTxFQYnmxv1xAwXRH4+U1flbuLmqRxil9vourfVFA0x6 wLV/FFoa5MRMUcy4V5cIV4E2rQjReNz83FRVuYFF6jDQJZX7HyX1mJyvr5/eGXKbfV2m7+6/ 0lP89Mb5IXcavX6AwgR6NF6YA9VThDNDJudoGHBLjCKMk19Ljc5tMXmBNafq5qCiM2ygl5Xb pednVJZS8VLb77/vF5OXmNGnsqram7ZtOSdUVBKVZUTVbj3HBhBfwP/RJ2geWqHrsmqV36rJ lLLFCMtB7AiMnY1tzijD33FIxLFgkMs4zhgVoHWeZmUenMY7rV8Ap48rkAz/1GiApjmJxE7l 8Af7VJa0UWRJYh9WsBchDYPVg5HihdGtlBmDVS5l7lAm5a2jTQtGG2hwdisXzdjRxTATTRof t5PCzyEuMuTETrXWQjAiaIFFJuicGRkgwSZpi9nshOCUDExYMKPFHnEMGZyeRodmsn8QnSYS g1k26eBfAQYAd9z0mwplbmRzdHJlYW0NZW5kb2JqDTE1MCAwIG9iag08PCAvVHlwZSAvWE9i amVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDI1MCAvSGVpZ2h0IDQwIC9CaXRzUGVyQ29t cG9uZW50IDggDS9Db2xvclNwYWNlIDEyNCAwIFIgL0xlbmd0aCAyNzY1IC9GaWx0ZXIgL0RD VERlY29kZSA+PiANc3RyZWFtDQr/2P/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwR CwoLERUPDAwPFRgTExUTExgXEhQUFBQSFxcbHB4cGxckJCcnJCQ1MzMzNTs7Ozs7Ozs7OzsB DQsLDQ4NEA4OEBQODw4UFBARERAUHRQUFRQUHSUaFxcXFxolICMeHh4jICgoJSUoKDIyMDIy Ozs7Ozs7Ozs7O//AABEIACgA+gMBIgACEQEDEQH/xAE/AAABBQEBAQEBAQAAAAAAAAADAAEC BAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwz AQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNU ZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eX p7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi 4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1 xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APRsXAwDiUk41RJraSSx v7o8lI4GB/3Gp/7bb/cpUWMrwanvcGsbU0ucdAAGhZHS/rTi9R6hfhwKw0xju3SXgc7h2Ph/ eniMiCRem6CQKHd0zgYA/wC01X+Y3+5QODg/9xqv8xv9yH1Xq2H0nF+15rnNp3BktaXGXcaD 4KhnfW3o2DcynIfYH2VttaG1l3teJbwnRhI7AlEpRG5AdA4WD/3Hq/zG/wByG7Cwv+49X+Y3 +5UavrX0e/EyMxj7PRxdvqk1kEbzAgHlVmfXPoVtjK2PtLnkNb+jdEkwE8Y5/ulHHHuHUOHh /wDcer/Mb/coOxMP/QV/5jf7ln5n1r6NiZNmLc+z1qTteG1kgH4hWsDqeL1LHORilxrDiz3N LTI8ilwSAsgo4onQFk7ExOPQr/zG/wByicXE/wBBX/mj+5LIy6cdzG2naHhx3dhtEmUA9Twh JNgDRHu15O7SOZG0pykhxcX/AENf+aP7lE42L/oa/wDNH9yh+0MdzHPYS5rLG1GB+c4gCJ7a oL+q44qstAc4V2ekeBr+9JMbfNJSY42N/oWf5o/uUDj43+iZ/mj+5Cu6lTWGktcd4aQPaI3B zgCXEDhqD+18d26GuIY3eTLQY2h/0SZ4KKmycfH/ANEz/NCiaMf/AETP80KN2ZXVfXS4Eut1 B0jUx3OvyQLep0VmC1x1gHQA6uHLiP3CipOaMf8A0bP80KJoo/0bP80IdedXZf6AaQ6A6TEa jd4/ijEpwCEZoo/0bfuCiaaf9G37giEqJRpDA00/6Nv3BRNNP+jb9wVfqeXfjVA47Q58Fzt3 Aa3n8qNTcLqK7R/hGh33hNEomRj1AtAkCSOoUaqf3G/cExqq/cb9wUyqN2ZYx73Dbsrdt9P8 93mEsmSMADJmw4J5iYwqx38dA2TXUPzG/cFE11/uN+4KhdlXPYA6C1xa4EaQZ4nujU5Fz7Qy za0mTtjw8DKjjzMJS4aOtVp3Z8nIZYQ4yY6WSL6BOa6/3R9wUSyv90fcpiCYKbQgEFSSywjO OM3xSBltpQawxSlAzFVEiO/UsCxn7o+5RLGfuj7kQgDkqMA8H8E/jjV9O9Fbwy2rX6MC1n7o +5LYz90JzATJ2lXS3V2PrX+2PsWOa9x6Z6VXqNq0fOm+Tr+b9FcveWRhfYd2+HfYg0EODfWd u3nk/NeoUNY/CqY8BzXVNDmnggtCx+nfVnHwOoW5jXB4LpoYW6sadTJnUz3/AIqviyiMaI1G 3j5pnjJNg7/g4v1q/aX/ADPZ+0iDf9oZt/e2e7bv/leKoZn2/wD5zYP7ODHZX2KrYLQC3+bM zJHZdp1jpWL1fE+yZe70twf7DBlvGvzWdnfVTpeZezIsdc2yuttTSx+32sEDsnY8kQNf63TT VEsZJ08Pwc7rH7Y/5r5/7XZUy2Wen6IAG3c3mCe6F0D/AJzfZcHbXjnp8N9xDfU9P/O5Wqz6 s9Prw8jD9S99WVt9TfYXEbTI2k8KvV9Uum0vY6u3JHpkFrfVO3QzwiJw4SNN7+X+1RjKwfDu 4bP2r/zp6p+y21Ptk7xaARtlvEkd11HTjn/ZG/tFrG5MncKgA2J9vEqnl/VfpuRl25bn3Muv O55Y/aNfgFbwMCnp9Bopc97S4umx290nzKU5RkBXYdOyoRIJvx6tTN+zOzXB9b7G+1lr/U2t Y54EFrT3gA6KAPRR+k9UuJLiXEuJJAducdPCw6q7fgYt9nqWNJJguaHENcW/R3NHMITemYbG FjWmC1zeT9F0SPwTF6BtnShTZW2x3ptc17h7pBaQ0EaTy3VRro6U5xpx3Fji0T6ZIkNEzPBM O1R7em4lk7mnUkmHEcncfxSrxMektNbSCyY1J5DWn8GhFTRY/FYyt7sZzMfez0Xk7gRBY0xq eOylaemOfYXWuHqtDntBcGkOAYCBHmOFYbg4zSC0H2kFoLiQ2JgNE6DVAf0vFj2bmO9vuBJg NLTp/mooROs6a936S57hXtMuc4g/nD/NhEGPhX61ucTUQ3c0kQW7u/8AaKk7p2IfzXdvzjzr r85RWVsqbtYIEl0ebjJRAUiGJU21tsuc9vG5xImNs/cipEqJKchBlZQoc0Ebtwcf80fxOirH qZFRtNcRULQJmSTG3hXjB+SiYTDGROkqHalpEuhpzsW9/Ua8iyyv0xs9JgPeQSVDpuQW9J3f nVbmD4zp+Vaax8Jr68i7CLTt9X1JjTaNefPRRyjKEoEmzISiZeJ1DGQYmOtkgi/F02BzWBpO 4t0k6koBxGeo6zcQ4uLpEaT8kcANBjvqqubmCgemGh7n8gzoP7JCdlMYY+LIL4Ng3eTjllkG PEeEz0Pk1ywDIBc1woedrbSBq74wrVePXUSWySfGP7lVpsqyGxdsqrY5vsBLfa1r+Jk8lWcL IpyQBZ+h2j3RLp8OVU5TLAyPFHUkyiR+IdP4jgyjGOCR4YgY8g6eB/ikHIT9pUZ1T7h4hL4j ilLJjkKIjGVx2sWDX12anI5IxhMHQmQqQ6aHX6KOrfGfBOZaABHzKYkRAICYOEakFVxD0A+2 eETnL2if3hvw1WjMZeoj3PUYRj7gH7vS99WFnOohRlPYSTMg/BQlaHDP7lw2OLgrrw+V7tLi j97ujw8d9L862e+xr6fstM2M/m2fnD90KRvp/wBIz/OC+ZUkwMer9LOvp/0jf84KDr6v9I3/ ADgvmxJOFKfo919X+kb/AJwUHXVfvt/zgvnNJEIL9EG2r99v3hRNtf77fvC+eUk5T9Bm2v8A fb94UTbX++37wvn5JEIffjbX++37woGyv95v3heCJIqfeTYz94feFE2M/eH3heEJJyH3U2M/ eH3hQNjP3h94XhqSKH3EvZ+8PvCiXs/eH3heIJIqfbS9n7w+8KJe394fevFEklPtRe394feo 72/vD714ukkp9mL2+I+9RLmdyPwXjaSKtej7CSzxH4Jpb4hePpIj6K18X1/cPEfeolw8QvIk kdfBD64XDxCjI8QvJUkfsQ+slw8QmkeK8nSSU//ZCmVuZHN0cmVhbQ1lbmRvYmoNMSAwIG9i ag08PCANL1RleHRCb3ggL0RpdiANL0ZyYW1lIC9EaXYgDS9Gb290bm90ZSAvTm90ZSANL0Vu ZG5vdGUgL05vdGUgDS9TaGFwZSAvRmlndXJlIA0vSW5saW5lU2hhcGUgL0ZpZ3VyZSANL1RP QSAvVE9DIA0vVE9BSSAvVE9DSSANL1RPRiAvVE9DIA0vVE9GSSAvVE9DSSANL1N1cGVyc2Ny aXB0IC9TcGFuIA0vU3Vic2NyaXB0IC9TcGFuIA0vU3RyaWtlb3V0IC9TcGFuIA0vVW5kZXJs aW5lIC9TcGFuIA0vRHJvcENhcCAvRmlndXJlIA0vTm9ybWFsIC9QIA0vUGMtZW50cnkgL1Ag DT4+IA1lbmRvYmoNMiAwIG9iag08PCANL1MgL05vcm1hbCANL0EgWyAzIDAgUiBdIA0vQyAv Tm9ybWFsIA0vUGcgMTA5IDAgUiANL0sgWyAwIDYgMCBSIDIgXSANL1AgODEgMCBSIA0+PiAN ZW5kb2JqDTMgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9TdGFydEluZGVudCA5IA0vVGV4dEFs aWduIC9FbmQgDT4+IA1lbmRvYmoNNCAwIG9iag08PCANL05vcm1hbCA1IDAgUiANL1BjLWVu dHJ5IDE3IDAgUiANPj4gDWVuZG9iag01IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vV3JpdGlu Z01vZGUgL0xyVGIgDS9TdGFydEluZGVudCAwIA0vRW5kSW5kZW50IDAgDS9UZXh0QWxpZ24g L1N0YXJ0IA0vU3BhY2VCZWZvcmUgMCANL1NwYWNlQWZ0ZXIgMCANL1RleHRJbmRlbnQgMCAN Pj4gDWVuZG9iag02IDAgb2JqDTw8IA0vUyAvU3VwZXJzY3JpcHQgDS9QIDIgMCBSIA0vQSA5 MyAwIFIgDS9QZyAxMDkgMCBSIA0vSyAxIA0+PiANZW5kb2JqDTcgMCBvYmoNPDwgDS9TIC9O b3JtYWwgDS9BIFsgOCAwIFIgXSANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDMgDS9Q IDgxIDAgUiANPj4gDWVuZG9iag04IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWdu IC9FbmQgDT4+IA1lbmRvYmoNOSAwIG9iag08PCANL1MgL05vcm1hbCANL0EgWyAxMCAwIFIg XSANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDQgDS9QIDgxIDAgUiANPj4gDWVuZG9i ag0xMCAwIG9iag08PCANL08gL0xheW91dCANL1RleHRBbGlnbiAvRW5kIA0+PiANZW5kb2Jq DTExIDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiANL0sg OCANL1AgODMgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZElu ZGVudCA0MzkgPj4gDT4+IA1lbmRvYmoNMTIgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9O b3JtYWwgDS9QZyAxMDkgMCBSIA0vSyA5IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQg L1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0xMyAwIG9i ag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDEwIA0vUCA4 MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQz OSA+PiANPj4gDWVuZG9iag0xNCAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCAN L1BnIDEwOSAwIFIgDS9LIDExIA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0 SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0xNSAwIG9iag08PCAN L1MgL1BjLWVudHJ5IA0vQyAvUGMtZW50cnkgDS9QZyAxMDkgMCBSIA0vSyAxMiANL1AgODMg MCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0Mzkg Pj4gDT4+IA1lbmRvYmoNMTYgMCBvYmoNPDwgDS9TIC9QYy1lbnRyeSANL0MgL1BjLWVudHJ5 IA0vUGcgMTA5IDAgUiANL0sgMTMgDS9QIDgzIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3Rh cnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQgNDM5ID4+IA0+PiANZW5kb2JqDTE3IDAgb2JqDTw8 IA0vTyAvTGF5b3V0IA0vV3JpdGluZ01vZGUgL0xyVGIgDS9TdGFydEluZGVudCA3LjIgDS9F bmRJbmRlbnQgMCANL1RleHRBbGlnbiAvU3RhcnQgDS9TcGFjZUJlZm9yZSAwIA0vU3BhY2VB ZnRlciAwIA0vVGV4dEluZGVudCAtNy4xOTk5OCANPj4gDWVuZG9iag0xOCAwIG9iag08PCAN L1MgL1BjLWVudHJ5IA0vQyAvUGMtZW50cnkgDS9QZyAxMDkgMCBSIA0vSyAxNCANL1AgODMg MCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0Mzkg Pj4gDT4+IA1lbmRvYmoNMTkgMCBvYmoNPDwgDS9TIC9QYy1lbnRyeSANL0MgL1BjLWVudHJ5 IA0vUGcgMTA5IDAgUiANL0sgMTUgDS9QIDgzIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3Rh cnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQgNDM5ID4+IA0+PiANZW5kb2JqDTIwIDAgb2JqDTw8 IA0vUyAvUGMtZW50cnkgDS9DIC9QYy1lbnRyeSANL1BnIDEwOSAwIFIgDS9LIDE2IA0vUCA4 MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQz OSA+PiANPj4gDWVuZG9iag0yMSAwIG9iag08PCANL1MgL1BjLWVudHJ5IA0vQyAvUGMtZW50 cnkgDS9QZyAxMDkgMCBSIA0vSyAxNyANL1AgODMgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9T dGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0MzkgPj4gDT4+IA1lbmRvYmoNMjIgMCBvYmoN PDwgDS9TIC9QYy1lbnRyeSANL0MgL1BjLWVudHJ5IA0vUGcgMTA5IDAgUiANL0sgMTggDS9Q IDgzIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQg NDM5ID4+IA0+PiANZW5kb2JqDTIzIDAgb2JqDTw8IA0vUyAvUGMtZW50cnkgDS9DIC9QYy1l bnRyeSANL1BnIDEwOSAwIFIgDS9LIDE5IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQg L1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0yNCAwIG9i ag08PCANL1MgL1BjLWVudHJ5IA0vQyAvUGMtZW50cnkgDS9QZyAxMDkgMCBSIA0vSyAyMCAN L1AgODMgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVu dCA0MzkgPj4gDT4+IA1lbmRvYmoNMjUgMCBvYmoNPDwgDS9TIC9QYy1lbnRyeSANL0MgL1Bj LWVudHJ5IA0vUGcgMTA5IDAgUiANL0sgMjEgDS9QIDgzIDAgUiANL0EgPDwgL08gL0xheW91 dCAvU3RhcnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQgNDM5ID4+IA0+PiANZW5kb2JqDTI2IDAg b2JqDTw8IA0vUyAvUGMtZW50cnkgDS9DIC9QYy1lbnRyeSANL1BnIDEwOSAwIFIgDS9LIDIy IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5k ZW50IDQzOSA+PiANPj4gDWVuZG9iag0yNyAwIG9iag08PCANL1MgL1BjLWVudHJ5IA0vQyAv UGMtZW50cnkgDS9QZyAxMDkgMCBSIA0vSyAyMyANL1AgODMgMCBSIA0vQSA8PCAvTyAvTGF5 b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0MzkgPj4gDT4+IA1lbmRvYmoNMjgg MCBvYmoNPDwgDS9TIC9QYy1lbnRyeSANL0MgL1BjLWVudHJ5IA0vUGcgMTA5IDAgUiANL0sg MjQgDS9QIDgzIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgLTY1IC9FbmRJ bmRlbnQgNDM5ID4+IA0+PiANZW5kb2JqDTI5IDAgb2JqDTw8IA0vUyAvUGMtZW50cnkgDS9D IC9QYy1lbnRyeSANL1BnIDEwOSAwIFIgDS9LIDI1IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9M YXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0z MCAwIG9iag08PCANL1MgL1BjLWVudHJ5IA0vQyAvUGMtZW50cnkgDS9QZyAxMDkgMCBSIA0v SyAyNiANL1AgODMgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0Vu ZEluZGVudCA0MzkgPj4gDT4+IA1lbmRvYmoNMzEgMCBvYmoNPDwgDS9TIC9QYy1lbnRyeSAN L0MgL1BjLWVudHJ5IA0vUGcgMTA5IDAgUiANL0sgMjcgDS9QIDgzIDAgUiANL0EgPDwgL08g L0xheW91dCAvU3RhcnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQgNDM5ID4+IA0+PiANZW5kb2Jq DTMyIDAgb2JqDTw8IA0vUyAvUGMtZW50cnkgDS9DIC9QYy1lbnRyeSANL1BnIDEwOSAwIFIg DS9LIDI4IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAv RW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0zMyAwIG9iag08PCANL1MgL1BjLWVudHJ5 IA0vQyAvUGMtZW50cnkgDS9QZyAxMDkgMCBSIA0vSyAyOSANL1AgODMgMCBSIA0vQSA8PCAv TyAvTGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0MzkgPj4gDT4+IA1lbmRv YmoNMzQgMCBvYmoNPDwgDS9TIC9QYy1lbnRyeSANL0MgL1BjLWVudHJ5IA0vUGcgMTA5IDAg UiANL0sgMzAgDS9QIDgzIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgLTY1 IC9FbmRJbmRlbnQgNDM5ID4+IA0+PiANZW5kb2JqDTM1IDAgb2JqDTw8IA0vUyAvUGMtZW50 cnkgDS9DIC9QYy1lbnRyeSANL1BnIDEwOSAwIFIgDS9LIDMxIA0vUCA4MyAwIFIgDS9BIDw8 IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVu ZG9iag0zNiAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIg DS9LIDMyIA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAv RW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0zNyAwIG9iag08PCANL1MgL05vcm1hbCAN L0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDMzIA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9M YXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag0z OCAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDM0 IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5k ZW50IDQzOSA+PiANPj4gDWVuZG9iag0zOSAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05v cm1hbCANL1BnIDEwOSAwIFIgDS9LIDM1IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQg L1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag00MCAwIG9i ag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDM2IA0vUCA4 MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IC02NSAvRW5kSW5kZW50IDQz OSA+PiANPj4gDWVuZG9iag00MSAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCAN L1BnIDEwOSAwIFIgDS9LIDM3IA0vUCA4MyAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0 SW5kZW50IC02NSAvRW5kSW5kZW50IDQzOSA+PiANPj4gDWVuZG9iag00MiAwIG9iag08PCAN L1MgL05vcm1hbCANL0EgWyA0MyAwIFIgXSANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9L IDUgDS9QIDgyIDAgUiANPj4gDWVuZG9iag00MyAwIG9iag08PCANL08gL0xheW91dCANL1Rl eHRBbGlnbiAvQ2VudGVyIA0vU3RhcnRJbmRlbnQgNzkgDS9FbmRJbmRlbnQgLTEyIA0+PiAN ZW5kb2JqDTQ0IDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAg UiANL0sgNiANL1AgODIgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCA3OSAv RW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag00NSAwIG9iag08PCANL1MgL05vcm1hbCAN L0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDcgDS9QIDgyIDAgUiANL0EgPDwgL08gL0xh eW91dCAvU3RhcnRJbmRlbnQgNzkgL0VuZEluZGVudCAtMTIgPj4gDT4+IA1lbmRvYmoNNDYg MCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAxMDkgMCBSIA0vSyAzOCAN L1AgODQgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCA3OSAvRW5kSW5kZW50 IDIxNCA+PiANPj4gDWVuZG9iag00NyAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1h bCANL1BnIDEwOSAwIFIgDS9LIDM5IA0vUCA4NCAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0 YXJ0SW5kZW50IDc5IC9FbmRJbmRlbnQgMjE0ID4+IA0+PiANZW5kb2JqDTQ4IDAgb2JqDTw8 IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiANL0sgNDAgDS9QIDg0IDAg UiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgNzkgL0VuZEluZGVudCAyMTQgPj4g DT4+IA1lbmRvYmoNNDkgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAx MDkgMCBSIA0vSyA0MSANL1AgODQgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVu dCA3OSAvRW5kSW5kZW50IDIxNCA+PiANPj4gDWVuZG9iag01MCAwIG9iag08PCANL1MgL05v cm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDQyIA0vUCA4NCAwIFIgDS9BIDw8 IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDc5IC9FbmRJbmRlbnQgMjE0ID4+IA0+PiANZW5k b2JqDTUxIDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiAN L0sgNDMgDS9QIDg0IDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgNzkgL0Vu ZEluZGVudCAyMTQgPj4gDT4+IA1lbmRvYmoNNTIgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9D IC9Ob3JtYWwgDS9QZyAxMDkgMCBSIA0vSyA0NCANL1AgODQgMCBSIA0vQSA8PCAvTyAvTGF5 b3V0IC9TdGFydEluZGVudCA3OSAvRW5kSW5kZW50IDIxNCA+PiANPj4gDWVuZG9iag01MyAw IG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDQ1IA0v UCA4NCAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDc5IC9FbmRJbmRlbnQg MjE0ID4+IA0+PiANZW5kb2JqDTU0IDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFs IA0vUGcgMTA5IDAgUiANL0sgNDYgDS9QIDg0IDAgUiANL0EgPDwgL08gL0xheW91dCAvU3Rh cnRJbmRlbnQgNzkgL0VuZEluZGVudCAyMTQgPj4gDT4+IA1lbmRvYmoNNTUgMCBvYmoNPDwg DS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAxMDkgMCBSIA0vSyA0NyANL1AgODQgMCBS IA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCA3OSAvRW5kSW5kZW50IDIxNCA+PiAN Pj4gDWVuZG9iag01NiAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEw OSAwIFIgDS9LIDQ4IA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50 IDI5NSAvRW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag01NyAwIG9iag08PCANL1MgL05v cm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDQ5IA0vUCA4NSAwIFIgDS9BIDw8 IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5kZW50IC0xMiA+PiANPj4gDWVu ZG9iag01OCAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIg DS9LIDUwIA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAv RW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag01OSAwIG9iag08PCANL1MgL05vcm1hbCAN L0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDUxIA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9M YXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag02 MCAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDUy IA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5k ZW50IC0xMiA+PiANPj4gDWVuZG9iag02MSAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05v cm1hbCANL1BnIDEwOSAwIFIgDS9LIDUzIA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQg L1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag02MiAwIG9i ag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDU0IA0vUCA4 NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5kZW50IC0x MiA+PiANPj4gDWVuZG9iag02MyAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCAN L1BnIDEwOSAwIFIgDS9LIDU1IA0vUCA4NSAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0 SW5kZW50IDI5NSAvRW5kSW5kZW50IC0xMiA+PiANPj4gDWVuZG9iag02NCAwIG9iag08PCAN L1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDU2IA0vUCA4NSAwIFIg DS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50IDI5NSAvRW5kSW5kZW50IC0xMiA+PiAN Pj4gDWVuZG9iag02NSAwIG9iag08PCANL1MgL05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEw OSAwIFIgDS9LIDU3IA0vUCA4NiAwIFIgDS9BIDw8IC9PIC9MYXlvdXQgL1N0YXJ0SW5kZW50 IDg4IC9FbmRJbmRlbnQgMTU3ID4+IA0+PiANZW5kb2JqDTY2IDAgb2JqDTw8IA0vUyAvTm9y bWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiANL0sgNTggDS9QIDg2IDAgUiANL0EgPDwg L08gL0xheW91dCAvU3RhcnRJbmRlbnQgODggL0VuZEluZGVudCAxNTcgPj4gDT4+IA1lbmRv YmoNNjcgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9DIC9Ob3JtYWwgDS9QZyAxMDkgMCBSIA0v SyA1OSANL1AgODYgMCBSIA0vQSA8PCAvTyAvTGF5b3V0IC9TdGFydEluZGVudCA4OCAvRW5k SW5kZW50IDE1NyA+PiANPj4gDWVuZG9iag02OCAwIG9iag08PCANL1MgL05vcm1hbCANL0Mg L05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIDYwIA0vUCA4NiAwIFIgDS9BIDw8IC9PIC9MYXlv dXQgL1N0YXJ0SW5kZW50IDg4IC9FbmRJbmRlbnQgMTU3ID4+IA0+PiANZW5kb2JqDTY5IDAg b2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiANL0sgNjEgDS9Q IDg2IDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgODggL0VuZEluZGVudCAx NTcgPj4gDT4+IA1lbmRvYmoNNzAgMCBvYmoNPDwgDS9TIC9Ob3JtYWwgDS9BIFsgNzEgMCBS IF0gDS9DIC9Ob3JtYWwgDS9QZyAxMDkgMCBSIA0vSyA2MiANL1AgODcgMCBSIA0+PiANZW5k b2JqDTcxIDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dEFsaWduIC9DZW50ZXIgDS9TdGFy dEluZGVudCA1NiANL0VuZEluZGVudCA5OSANPj4gDWVuZG9iag03MiAwIG9iag08PCANL1Mg L05vcm1hbCANL0MgL05vcm1hbCANL1BnIDEwOSAwIFIgDS9LIFsgNjQgNzMgMCBSIDY3IF0g DS9QIDg5IDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgMzc2IC9FbmRJbmRl bnQgLTcgPj4gDT4+IA1lbmRvYmoNNzMgMCBvYmoNPDwgDS9TIC9MaW5rIA0vUCA3MiAwIFIg DS9LIFsgNzQgMCBSIDw8IC9UeXBlIC9PQkpSIC9QZyAxMDkgMCBSIC9PYmogMTExIDAgUiA+ PiBdIA0+PiANZW5kb2JqDTc0IDAgb2JqDTw8IA0vUyAvVW5kZXJsaW5lIA0vUCA3MyAwIFIg DS9BIDk0IDAgUiANL1BnIDEwOSAwIFIgDS9LIDY1IA0+PiANZW5kb2JqDTc1IDAgb2JqDTw8 IA0vUyAvTm9ybWFsIA0vQSBbIDc2IDAgUiBdIA0vQyAvTm9ybWFsIA0vSyA3NyAwIFIgDS9Q IDg5IDAgUiANPj4gDWVuZG9iag03NiAwIG9iag08PCANL08gL0xheW91dCANL1RleHRBbGln biAvQ2VudGVyIA0vU3RhcnRJbmRlbnQgMzc2IA0vRW5kSW5kZW50IC03IA0+PiANZW5kb2Jq DTc3IDAgb2JqDTw8IA0vUyAvSW5saW5lU2hhcGUgDS9QZyAxMDkgMCBSIA0vUCA3NSAwIFIg DS9LIFsgNjYgNjggXSANL0FsdCAoKQ0vQSBbIDk1IDAgUiBdIA0+PiANZW5kb2JqDTc4IDAg b2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFsIA0vUGcgMTA5IDAgUiANL0sgNjkgDS9Q IDkwIDAgUiANL0EgPDwgL08gL0xheW91dCAvU3RhcnRJbmRlbnQgLTY1IC9FbmRJbmRlbnQg NDM4ID4+IA0+PiANZW5kb2JqDTc5IDAgb2JqDTw8IA0vUyAvTm9ybWFsIA0vQyAvTm9ybWFs IA0vUGcgMTA5IDAgUiANL0sgWyA4MCAwIFIgNzEgXSANL1AgOTAgMCBSIA0vQSA8PCAvTyAv TGF5b3V0IC9TdGFydEluZGVudCAtNjUgL0VuZEluZGVudCA0MzggPj4gDT4+IA1lbmRvYmoN ODAgMCBvYmoNPDwgDS9TIC9JbmxpbmVTaGFwZSANL1BnIDEwOSAwIFIgDS9LIDcwIA0vUCA3 OSAwIFIgDS9BbHQgKCkNL0EgWyA5NiAwIFIgXSANPj4gDWVuZG9iag04MSAwIG9iag08PCAN L1MgL1NlY3QgDS9QIDEwOCAwIFIgDS9MYW5nIChFTi1HQikNL0sgWyAyIDAgUiA3IDAgUiA5 IDAgUiA4OCAwIFIgODMgMCBSIDgyIDAgUiA4NCAwIFIgODUgMCBSIDg2IDAgUiA4NyAwIFIg DTg5IDAgUiA5MCAwIFIgXSANPj4gDWVuZG9iag04MiAwIG9iag08PCANL1MgL1RleHRCb3gg DS9BbHQgKFRleHQgQm94OiBTY29wZVxyXG5XaXJlbGVzcyBzZW5zb3IgbmV0d29ya3MgXChX U05cKSAtIG5ldHdvcmtzIG9mIHRpbnksIFwNYXV0b25vbW91cyBkZXZpY2VzIGVxdWlwcGVk IHdpdGggd2lyZWxlc3MgY29tbXVuaWNhdGlvbiAtIGFyZSBhIHRvcGljIG9mXA0gYWN0aXZl IHJlc2VhcmNoIGluIGEgbnVtYmVyIG9mIGRpZmZlcmVudCByZXNlYXJjaCBjb21tdW5pdGll cywgcmFuZ2luZyBcDWZyb20gaGFyZHdhcmUgdG8gYXBwbGljYXRpb25zLiBXU05zIGFyZSBj aGFyYWN0ZXJpemVkIGJ5IGEgbmVlZCB0byBjYXJlZlwNdWxseSBpbnRlZ3JhdGUgZnVuY3Rp b25hbGl0aWVzIHRyYWRpdGlvbmFsbHkgY29uc2lkZXJlZCB0byBiZSBzZXBhcmF0ZSBpXA1u IG9yZGVyIHRvIGFjaGlldmUgbWF4aW11bSBlZmZpY2llbmN5LCBlc3BlY2lhbGx5IHdpdGgg cmVnYXJkIHRvIGVuZXJneSBcDWNvbnN1bXB0aW9uIGFuZCBtYW5hZ2VtZW50LiBIZW5jZSwg YSBjbG9zZSBpbnRlcmFjdGlvbiBvZiByZXNlYXJjaCBmcm9tIFwNZGlmZmVyZW50IGJhY2tn cm91bmRzIGlzIHJlcXVpcmVkLiBBZGRpdGlvbmFsbHksIFdTTnMgYXJlIGV2b2x2aW5nIGZy b20gXA1zaW1wbGUgZGF0YSB0cmFuc3BvcnRhdGlvbiBuZXR3b3JrcyB0byBmdW5jdGlvbmFs bHkgcmljaCBkaXN0cmlidXRlZCBzeXNcDXRlbXMsIGUuZy4sIGJlY2F1c2UgYWN0dWF0b3Jz IGluIHRoZSBuZXR3b3JrIGhhdmUgdG8gYmUgc3VwcG9ydGVkLlxyXG5UaFwNZSBnb2FsIG9m IHRoaXMgd29ya3Nob3AgaXMgdG8gYnJpbmcgdG9nZXRoZXIgcmVzZWFyY2hlcnMgZnJvbSBk aWZmZXJlbnQgXA1iYWNrZ3JvdW5kcywgZnJvbSBoYXJkd2FyZSB0byBhcHBsaWNhdGlvbnMs IHRvIGNyZWF0ZSBhIGZvcnVtIHdoZXJlIGNyb3NcDXMtbGF5ZXIgaW50ZWdyYXRpb24sIG5v dmVsIHNvbHV0aW9ucyBmb3Igc3BlY2lmaWMgcHJvYmxlbXMsIGFuZCB0aGUgZnV0dVwNcmUg ZGV2ZWxvcG1lbnQgb2YgV1NOIGZ1bmN0aW9uYWxpdGllcyBjYW4gYmUgZGlzY3Vzc2VkLlxy XG5cMDAwKQ0vUCA4MSAwIFIgDS9LIFsgNDIgMCBSIDQ0IDAgUiA0NSAwIFIgXSANPj4gDWVu ZG9iag04MyAwIG9iag08PCANL1MgL1RleHRCb3ggDS9BbHQgKFwzNzZcMzc3XDAwMFRcMDAw ZVwwMDB4XDAwMHRcMDAwIFwwMDBCXDAwMG9cMDAweFwwMDA6XDAwMCBcMDAwQ1wwMDBoXDAw MFwNYVwwMDBpXDAwMHJcMDAwXHJcMDAwXG5cMDAwQVwwMDBkXDAwMGFcMDAwbVwwMDAgXDAw MFdcMDAwb1wwMDBsXDAwMGlcMDAwXA1zXDAwMHpcMDAwLFwwMDAgXDAwMFRcMDAwVVwwMDAg XDAwMEJcMDAwZVwwMDByXDAwMGxcMDAwaVwwMDBuXDAwMFxyXDAwMFxuXA1cMDAwXHJcMDAw XG5cMDAwUFwwMDByXDAwMG9cMDAwZ1wwMDByXDAwMGFcMDAwbVwwMDAgXDAwMENcMDAwb1ww MDBtXDAwMG1cDVwwMDBpXDAwMHRcMDAwdFwwMDBlXDAwMGVcMDAwXHJcMDAwXG5cMDAwSFww MDBvXDAwMGxcMDAwZ1wwMDBlXDAwMHJcMDAwIFwNXDAwMEJcMDAwb1wwMDBjXDAwMGhcMDAw ZVwwMDAsXDAwMCBcMDAwSFwwMDBlXDAwMGlcMDAwblwwMDByXDAwMGlcMDAwY1wwMDBcDWhc MDAwLVwwMDBIXDAwMGVcMDAwclwwMDB0XDAwMHpcMDAwLVwwMDBJXDAwMG5cMDAwc1wwMDBp XDAwMHRcMDAwdVwwMDB0XDAwMFwNZVwwMDAsXDAwMCBcMDAwQlwwMDBlXDAwMHJcMDAwbFww MDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAwRVwwMDByXDAwMGRcMDAwXA1hXDAwMGxcMDAwIFww MDBDXDAwMGFcMDAweVwwMDBpXDAwMHJcMDAwY1wwMDBpXDAwMCxcMDAwIFwwMDBZXDAwMGVc MDAwZFwwMDBcDWlcMDAwdFwwMDBlXDAwMHBcMDAwZVwwMDAgXDAwMFVcMDAwblwwMDBpXDAw MHZcMDAwZVwwMDByXDAwMHNcMDAwaVwwMDB0XDAwMFwNeVwwMDAgXDAwMElcMDAwc1wwMDB0 XDAwMGFcMDAwblwwMDBiXDAwMHVcMDAwbFwwMDBcclwwMDBcblwwMDBLXDAwMHVcMDAwXA1y XDAwMHRcMDAwIFwwMDBHXDAwMGVcMDAwaVwwMDBoXDAwMHNcMDAwLFwwMDAgXDAwMFRcMDAw VVwwMDAgXDAwMEJcMDAwZVwwMDBcDXJcMDAwbFwwMDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAw UFwwMDBhXDAwMHVcMDAwbFwwMDAgXDAwMEhcMDAwYVwwMDB2XDAwMFwNaVwwMDBuXDAwMGdc MDAwYVwwMDAsXDAwMCBcMDAwVVwwMDBuXDAwMGlcMDAwdlwwMDBlXDAwMHJcMDAwc1wwMDBp XDAwMHRcMDAwXA15XDAwMCBcMDAwVFwwMDB3XDAwMGVcMDAwblwwMDB0XDAwMGVcMDAwXHJc MDAwXG5cMDAwSFwwMDBvXDAwMGxcMDAwZ1wwMDBcDWVcMDAwclwwMDAgXDAwMEtcMDAwYVww MDByXDAwMGxcMDAwLFwwMDAgXDAwMFRcMDAwVVwwMDAgXDAwMEJcMDAwZVwwMDByXDAwMFwN bFwwMDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAwVFwwMDBoXDAwMG9cMDAwbVwwMDBhXDAwMHNc MDAwIFwwMDBMXDAwMGVcMDAwXA1uXDAwMHRcMDAwc1wwMDBjXDAwMGhcMDAwLFwwMDAgXDAw MElcMDAwblwwMDBmXDAwMGlcMDAwblwwMDBlXDAwMG9cMDAwblwwMDBcDVxyXDAwMFxuXDAw MElcMDAwYVwwMDBuXDAwMCBcMDAwTVwwMDBhXDAwMHJcMDAwc1wwMDBoXDAwMGFcMDAwbFww MDBsXDAwMFwNLFwwMDAgXDAwMEJcMDAwVFwwMDAgXDAwMGVcMDAweFwwMDBhXDAwMGNcMDAw dFwwMDBcclwwMDBcblwwMDBGXDAwMHJcMDAwXA1pXDAwMGVcMDAwZFwwMDBlXDAwMG1cMDAw YVwwMDBuXDAwMG5cMDAwIFwwMDBNXDAwMGFcMDAwdFwwMDB0XDAwMGVcMDAwclwwMDBcDW5c MDAwLFwwMDAgXDAwMEVcMDAwVFwwMDBIXDAwMCBcMDAwWlwwMDBcMzc0XDAwMHJcMDAwaVww MDBjXDAwMGhcMDAwXHJcMDAwXA1cblwwMDBDXDAwMGhcMDAwaVwwMDBhXDAwMHJcMDAwYVww MDAgXDAwMFBcMDAwZVwwMDB0XDAwMHJcMDAwaVwwMDBvXDAwMGxcDVwwMDBpXDAwMCxcMDAw IFwwMDBVXDAwMG5cMDAwaVwwMDB2XDAwMGVcMDAwclwwMDBzXDAwMGlcMDAwdFwwMDB5XDAw MCAgXDAzNlwNXDAwMExcMDAwYVwwMDAgXDAwMFNcMDAwYVwwMDBwXDAwMGlcMDAwZVwwMDBu XDAwMHpcMDAwYSBcMDM0XDAwMCxcMDAwIFwwMDBcDVJcMDAwb1wwMDBtXDAwMGVcMDAwXHJc MDAwXG5cMDAwUlwwMDBhXDAwMGRcMDAwdVwwMDAgXDAwMFBcMDAwb1wwMDBwXDAwMFwNZVww MDBzXDAwMGNcMDAwdVwwMDAtXDAwMFpcMDAwZVwwMDBsXDAwMGVcMDAwdFwwMDBpXDAwMG5c MDAwLFwwMDAgXDAwMEZcMDAwXA1oXDAwMEdcMDAwIFwwMDBGXDAwMG9cMDAwa1wwMDB1XDAw MHNcMDAwXHJcMDAwXG5cMDAwSlwwMDBhXDAwMG5cMDAwIFwwMDBcDVJcMDAwYVwwMDBiXDAw MGFcMDAwZVwwMDB5XDAwMCxcMDAwIFwwMDBVXDAwMG5cMDAwaVwwMDB2XDAwMGVcMDAwclww MDBzXDAwMFwNaVwwMDB0XDAwMHlcMDAwIFwwMDBvXDAwMGZcMDAwIFwwMDBDXDAwMGFcMDAw bFwwMDBpXDAwMGZcMDAwb1wwMDByXDAwMG5cMDAwXA1pXDAwMGFcMDAwIFwwMDBhXDAwMHRc MDAwIFwwMDBCXDAwMGVcMDAwclwwMDBrXDAwMGVcMDAwbFwwMDBlXDAwMHlcMDAwXHJcDVww MDBcblwwMDBIXDAwMGVcMDAwclwwMDBiXDAwMGVcMDAwclwwMDB0XDAwMCBcMDAwUlwwMDBl XDAwMGlcMDAwY1wwMDBoXDAwMFwNbFwwMDAsXDAwMCBcMDAwRlwwMDBoXDAwMEdcMDAwIFww MDBJXDAwMFpcMDAwTVwwMDBcclwwMDBcblwwMDBMXDAwMGlcMDAwXA1vXDAwMG5cMDAwZVww MDBsXDAwMCBcMDAwU1wwMDBhXDAwMGNcMDAwa1wwMDBzXDAwMCxcMDAwIFwwMDBVXDAwMG5c MDAwaVwwMDBcDXZcMDAwZVwwMDByXDAwMHNcMDAwaVwwMDB0XDAwMHlcMDAwIFwwMDBDXDAw MG9cMDAwbFwwMDBsXDAwMGVcMDAwZ1wwMDBlXDAwMFwNIFwwMDBMXDAwMG9cMDAwblwwMDBk XDAwMG9cMDAwblwwMDBcclwwMDBcblwwMDBUXDAwMGhcMDAwb1wwMDBtXDAwMGFcMDAwXA1z XDAwMCBcMDAwU1wwMDBpXDAwMGtcMDAwb1wwMDByXDAwMGFcMDAwLFwwMDAgXDAwMFRcMDAw VVwwMDAgXDAwMEJcMDAwZVwwMDBcDXJcMDAwbFwwMDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAw SlwwMDBvXDAwMGNcMDAwaFwwMDBlXDAwMG5cMDAwIFwwMDBTXDAwMFwNY1wwMDBoXDAwMGlc MDAwbFwwMDBsXDAwMGVcMDAwclwwMDAsXDAwMCBcMDAwRlwwMDBVXDAwMCBcMDAwQlwwMDBl XDAwMHJcMDAwXA1sXDAwMGlcMDAwblwwMDBcclwwMDBcblwwMDBNXDAwMGFcMDAwclwwMDB0 XDAwMGlcMDAwblwwMDAgXDAwMFZcMDAwZVwwMDBcDXRcMDAwdFwwMDBlXDAwMHJcMDAwbFww MDBpXDAwMCxcMDAwIFwwMDBFXDAwMFBcMDAwRlwwMDBMXDAwMCBcMDAwTFwwMDBhXDAwMFwN dVwwMDBzXDAwMGFcMDAwblwwMDBuXDAwMGVcMDAwXHJcMDAwXG5cMDAwQVwwMDBuXDAwMGRc MDAwclwwMDBlXDAwMGFcMDAwXA1zXDAwMCBcMDAwV1wwMDBpXDAwMGxcMDAwbFwwMDBpXDAw MGdcMDAwLFwwMDAgXDAwMEhcMDAwYVwwMDBzXDAwMHNcMDAwb1wwMDBcDS1cMDAwUFwwMDBs XDAwMGFcMDAwdFwwMDB0XDAwMG5cMDAwZVwwMDByXDAwMCBcMDAwSVwwMDBuXDAwMHNcMDAw dFwwMDBpXDAwMFwNdFwwMDB1XDAwMHRcMDAwZVwwMDAgXDAwMFBcMDAwb1wwMDB0XDAwMHNc MDAwZFwwMDBhXDAwMG1cMDAwXHJcMDAwXG5cMDAwXA1BXDAwMGRcMDAwYVwwMDBtXDAwMCBc MDAwV1wwMDBvXDAwMGxcMDAwaVwwMDBzXDAwMHpcMDAwLFwwMDAgXDAwMFRcMDAwVVwwMDBc DSBcMDAwQlwwMDBlXDAwMHJcMDAwbFwwMDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAwTVwwMDBp XDAwMGNcMDAwaFwwMDBlXDAwMFwNbFwwMDBlXDAwMCBcMDAwWlwwMDBvXDAwMHJcMDAwelww MDBpXDAwMCxcMDAwIFwwMDBVXDAwMG5cMDAwdlwwMDBlXDAwMHJcMDAwXA1zXDAwMGlcMDAw dFwwMDB5XDAwMCBcMDAwRlwwMDBlXDAwMHJcMDAwclwwMDBhXDAwMHJcMDAwYVwwMDBcclww MDBcblwwMDBcDVJcMDAwaVwwMDBjXDAwMGhcMDAwYVwwMDByXDAwMGRcMDAwIFwwMDBaXDAw MHVcMDAwclwwMDBhXDAwMHdcMDAwc1wwMDBrXDAwMFwNaVwwMDAsXDAwMCBcMDAwSVwwMDBT XDAwMEFcMDAwIFwwMDBDXDAwMG9cMDAwclwwMDBwXDAwMC5cMDAwXHJcMDAwXG5cMDAwXA1c clwwMDBcblwwMDBPXDAwMHJcMDAwZ1wwMDBhXDAwMG5cMDAwaVwwMDB6XDAwMGFcMDAwdFww MDBpXDAwMG9cMDAwblwwMDBcDSBcMDAwQ1wwMDBvXDAwMG1cMDAwbVwwMDBpXDAwMHRcMDAw dFwwMDBlXDAwMGVcMDAwXHJcMDAwXG5cMDAwSFwwMDBvXDAwMFwNbFwwMDBnXDAwMGVcMDAw clwwMDAgXDAwMEtcMDAwYVwwMDByXDAwMGxcMDAwLFwwMDAgXDAwMFRcMDAwVVwwMDAgXDAw MEJcMDAwXA1lXDAwMHJcMDAwbFwwMDBpXDAwMG5cMDAwXHJcMDAwXG5cMDAwQVwwMDBuXDAw MGRcMDAwclwwMDBlXDAwMGFcMDAwc1wwMDBcDSBcMDAwV1wwMDBpXDAwMGxcMDAwbFwwMDBp XDAwMGdcMDAwLFwwMDAgXDAwMEhcMDAwUFwwMDBJXDAwMFxyXDAwMFxuXDAwMFwNXHJcMDAw XG5cMDAwXHJcMDAwXG5cMDAwXDAwMCkNL1AgODEgMCBSIA0vSyBbIDExIDAgUiAxMiAwIFIg MTMgMCBSIDE0IDAgUiAxNSAwIFIgMTYgMCBSIDE4IDAgUiAxOSAwIFIgMjAgMCBSIDIxIDAg UiANMjIgMCBSIDIzIDAgUiAyNCAwIFIgMjUgMCBSIDI2IDAgUiAyNyAwIFIgMjggMCBSIDI5 IDAgUiAzMCAwIFIgMzEgMCBSIA0zMiAwIFIgMzMgMCBSIDM0IDAgUiAzNSAwIFIgMzYgMCBS IDM3IDAgUiAzOCAwIFIgMzkgMCBSIDQwIDAgUiA0MSAwIFIgDV0gDT4+IA1lbmRvYmoNODQg MCBvYmoNPDwgDS9TIC9UZXh0Qm94IA0vQWx0IChUZXh0IEJveDogV2UgZW5jb3VyYWdlIGNv bnRyaWJ1dGlvbnMgZGVzY3JpYmluZyBpbm5vdmF0aXZlIHdvcmsgb24gV1NOLiBcDUFyZWFz IG9mIGludGVyZXN0IGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG86XHJcblxyXG4t IEhhcmR3YXJlIGZvclwNIFdTTiwgZS5nLjogdHJhbnNjZWl2ZXIgY29uY2VwdHMsIHdha2V1 cCByYWRpbywgYW50ZW5uYSBkZXNpZ24sIHN5c3RlbSBpXA1udGVncmF0aW9uLCBwcm9jZXNz IGFuZCBjb3N0IG9mIG1hbnVmYWN0dXJpbmcsIGJhdHRlcnkgdGVjaG5vbG9neSwgZW5lcmdc DXkgc2NhdmVuZ2luZ1xyXG5cclxuLSBDb21tdW5pY2F0aW9uIHByb3RvY29scywgZS5nLjog TUFDIGFuZCBsaW5rIGxheWVyIFwNcHJvYmxlbXM7IHJvdXRpbmcgYW5kIHRyYW5zcG9ydCBw cm90b2NvbHMgc3VpdGFibGUgZm9yIFdTTiwgcmVkdW5kYW5jeSwgXA1hZ2dyZWdhdGlvbiBz dXBwb3J0LCBhbmQgbW9iaWxpdHkgc3VwcG9ydDsgc3VwcG9ydGluZyBmdW5jdGlvbmFsaXRp ZXMgbGlcDWtlIGxvY2F0aW9uaW5nIGFuZCBzeW5jaHJvbml6YXRpb25cclxuXHJcbi0gU291 cmNlIGNvZGluZyB0ZWNobmlxdWVzIGFwcFwNcm9wcmlhdGUgZm9yIFdTTiwgZS5nLiwgdG8g c3VwcG9ydCBkYXRhIGZ1c2lvbjsgZGlzdHJpYnV0ZWQgc2lnbmFsIHByb2NlXA1zc2luZ1xy XG5cclxuLSBEaXN0cmlidXRlZCBjb250cm9sIGFuZCBhY3R1YXRpb25cclxuXHJcblwwMDAp DS9QIDgxIDAgUiANL0sgWyA0NiAwIFIgNDcgMCBSIDQ4IDAgUiA0OSAwIFIgNTAgMCBSIDUx IDAgUiA1MiAwIFIgNTMgMCBSIDU0IDAgUiA1NSAwIFIgDV0gDT4+IA1lbmRvYmoNODUgMCBv YmoNPDwgDS9TIC9UZXh0Qm94IA0vQWx0IChcMzc2XDM3N1wwMDBUXDAwMGVcMDAweFwwMDB0 XDAwMCBcMDAwQlwwMDBvXDAwMHhcMDAwOlwwMDAgXDAwMC1cMDAwICBcMDM0XA1cMDAwTVww MDBpXDAwMGRcMDAwZFwwMDBsXDAwMGVcMDAwd1wwMDBhXDAwMHJcMDAwZSBcMDM1XDAwMCBc MDAwZlwwMDBvXDAwMFwNclwwMDAgXDAwMFdcMDAwU1wwMDBOXDAwMCxcMDAwIFwwMDBlXDAw MC5cMDAwZ1wwMDAuXDAwMDpcMDAwIFwwMDBDXDAwMG9cMDAwXA1uXDAwMGZcMDAwaVwwMDBn XDAwMHVcMDAwclwwMDBhXDAwMHRcMDAwaVwwMDBvXDAwMG5cMDAwIFwwMDBhXDAwMG5cMDAw ZFwwMDBcDSBcMDAwaVwwMDBuXDAwMHNcMDAwdFwwMDBhXDAwMGxcMDAwbFwwMDBhXDAwMHRc MDAwaVwwMDBvXDAwMG5cMDAwIFwwMDBzXDAwMFwNdVwwMDBwXDAwMHBcMDAwb1wwMDByXDAw MHRcMDAwLFwwMDAgXDAwMGxcMDAwb1wwMDBvXDAwMGtcMDAwdVwwMDBwXDAwMCBcMDAwXA1v XDAwMGZcMDAwIFwwMDBhXDAwMHZcMDAwYVwwMDBpXDAwMGxcMDAwYVwwMDBiXDAwMGxcMDAw ZVwwMDAgXDAwMGZcMDAwdVwwMDBcDW5cMDAwY1wwMDB0XDAwMGlcMDAwb1wwMDBuXDAwMGFc MDAwbFwwMDBpXDAwMHRcMDAwaVwwMDBlXDAwMHNcMDAwLFwwMDAgXDAwMFwNZ1wwMDByXDAw MG9cMDAwdVwwMDBwXDAwMCBcMDAwY1wwMDBvXDAwMG1cMDAwbVwwMDB1XDAwMG5cMDAwaVww MDBjXDAwMGFcMDAwXA10XDAwMGlcMDAwb1wwMDBuXDAwMCxcMDAwIFwwMDBkXDAwMGlcMDAw c1wwMDB0XDAwMHJcMDAwaVwwMDBiXDAwMHVcMDAwdFwwMDBcDWVcMDAwZFwwMDAgXDAwMGFc MDAwbFwwMDBnXDAwMG9cMDAwclwwMDBpXDAwMHRcMDAwaFwwMDBtXDAwMHNcMDAwIFwwMDBp XDAwMFwNblwwMDAgXDAwMFdcMDAwU1wwMDBOXDAwMCxcMDAwIFwwMDBpXDAwMG5cMDAwLVww MDBuXDAwMGVcMDAwdFwwMDB3XDAwMG9cMDAwXA1yXDAwMGtcMDAwIFwwMDBwXDAwMHJcMDAw b1wwMDBjXDAwMGVcMDAwc1wwMDBzXDAwMGlcMDAwblwwMDBnXDAwMCBcMDAwYVwwMDBcDW5c MDAwZFwwMDAgXDAwMHNcMDAwdFwwMDBvXDAwMHJcMDAwYVwwMDBnXDAwMGVcMDAwIFwwMDBv XDAwMGZcMDAwIFwwMDBkXDAwMFwNYVwwMDB0XDAwMGFcMDAwLFwwMDAgXDAwMGhcMDAwYVww MDByXDAwMG1cMDAwb1wwMDBuXDAwMGlcMDAwelwwMDBpXDAwMG5cMDAwXA1nXDAwMCBcMDAw blwwMDBvXDAwMGRcMDAwZVwwMDAtXDAwMGNcMDAwZVwwMDBuXDAwMHRcMDAwclwwMDBpXDAw MGNcMDAwIFwwMDBcDWFcMDAwblwwMDBkXDAwMCBcMDAwZFwwMDBhXDAwMHRcMDAwYVwwMDAt XDAwMGNcMDAwZVwwMDBuXDAwMHRcMDAwclwwMDBpXDAwMFwNY1wwMDAgXDAwMGFcMDAwZFww MDBkXDAwMHJcMDAwZVwwMDBzXDAwMHNcMDAwaVwwMDBuXDAwMGdcMDAwLFwwMDAgXDAwMFxy XA1cMDAwXG5cMDAwXHJcMDAwXG5cMDAwLVwwMDAgXDAwMEdcMDAwYVwwMDB0XDAwMGVcMDAw d1wwMDBhXDAwMHlcMDAwc1wwMDBcDSBcMDAwdFwwMDBvXDAwMCBcMDAwZlwwMDBpXDAwMHhc MDAwZVwwMDBkXDAwMCBcMDAwSVwwMDBuXDAwMHRcMDAwZVwwMDByXDAwMFwNblwwMDBlXDAw MHRcMDAwIFwwMDBhXDAwMG5cMDAwZFwwMDAgXDAwMGlcMDAwblwwMDB0XDAwMGVcMDAwZ1ww MDByXDAwMGFcMDAwXA10XDAwMGlcMDAwb1wwMDBuXDAwMCBcMDAwb1wwMDBmXDAwMCBcMDAw V1wwMDBTXDAwME5cMDAwIFwwMDBpXDAwMG5cMDAwdFwwMDBcDW9cMDAwIFwwMDBJXDAwMG5c MDAwdFwwMDBlXDAwMHJcMDAwblwwMDBlXDAwMHRcMDAwIFwwMDBtXDAwMGlcMDAwZFwwMDBk XDAwMFwNbFwwMDBlXDAwMHdcMDAwYVwwMDByXDAwMGVcMDAwIFwwMDBhXDAwMHJcMDAwY1ww MDBoXDAwMGlcMDAwdFwwMDBlXDAwMGNcMDAwXA10XDAwMHVcMDAwclwwMDBlXDAwMHNcMDAw IFwwMDBcclwwMDBcblwwMDBcclwwMDBcblwwMDAtXDAwMCBcMDAwU1wwMDBlXDAwMFwNY1ww MDB1XDAwMHJcMDAwaVwwMDB0XDAwMHlcMDAwLFwwMDAgXDAwMGVcMDAwLlwwMDBnXDAwMC5c MDAwOlwwMDAgXDAwMHBcMDAwXA1yXDAwMGlcMDAwbVwwMDBpXDAwMHRcMDAwaVwwMDB2XDAw MGVcMDAwc1wwMDAgXDAwMGZcMDAwb1wwMDByXDAwMCBcMDAwYVwwMDBcDXBcMDAwcFwwMDBy XDAwMG9cMDAwcFwwMDByXDAwMGlcMDAwYVwwMDB0XDAwMGVcMDAwIFwwMDBjXDAwMHJcMDAw eVwwMDBwXDAwMFwNdFwwMDBvXDAwMGdcMDAwclwwMDBhXDAwMHBcMDAwaFwwMDBpXDAwMGNc MDAwIFwwMDBwXDAwMHJcMDAwb1wwMDB0XDAwMG9cMDAwXA1jXDAwMG9cMDAwbFwwMDBzXDAw MCxcMDAwIFwwMDBzXDAwMGVcMDAwY1wwMDB1XDAwMHJcMDAwZVwwMDAgXDAwMHNcMDAweVww MDBcDXNcMDAwdFwwMDBlXDAwMG1cMDAwIFwwMDBlXDAwMG5cMDAwZ1wwMDBpXDAwMG5cMDAw ZVwwMDBlXDAwMHJcMDAwaVwwMDBuXDAwMFwNZ1wwMDAgXDAwMFxyXDAwMFxuXDAwMFxyXDAw MFxuXDAwMC1cMDAwIFwwMDBBXDAwMHBcMDAwcFwwMDBsXDAwMGlcMDAwY1wwMDBcDWFcMDAw dFwwMDBpXDAwMG9cMDAwblwwMDBzXDAwMCBcMDAwb1wwMDBmXDAwMCBcMDAwV1wwMDBTXDAw ME5cMDAwLFwwMDAgXDAwMFwNZVwwMDAuXDAwMGdcMDAwLlwwMDA6XDAwMCBcMDAwblwwMDBv XDAwMHZcMDAwZVwwMDBsXDAwMCBcMDAwYVwwMDBwXDAwMHBcMDAwXA1sXDAwMGlcMDAwY1ww MDBhXDAwMHRcMDAwaVwwMDBvXDAwMG5cMDAwc1wwMDAgXDAwMGFcMDAwblwwMDBkXDAwMCBc MDAwdFwwMDBcDWhcMDAwZVwwMDBpXDAwMHJcMDAwIFwwMDByXDAwMGVcMDAwcVwwMDB1XDAw MGlcMDAwclwwMDBlXDAwMG1cMDAwZVwwMDBuXDAwMFwNdFwwMDBzXDAwMCBcMDAwc1wwMDB1 XDAwMGNcMDAwaFwwMDAgXDAwMGFcMDAwc1wwMDAgXDAwMG1cMDAwZVwwMDBkXDAwMGlcMDAw XA1jXDAwMGlcMDAwblwwMDBlXDAwMCxcMDAwIFwwMDBlXDAwMG5cMDAwdlwwMDBpXDAwMHJc MDAwb1wwMDBuXDAwMG1cMDAwZVwwMDBcDW5cMDAwdFwwMDAgXDAwMGNcMDAwb1wwMDBuXDAw MHRcMDAwclwwMDBvXDAwMGxcMDAwLFwwMDAgXDAwMGVcMDAwdFwwMDBjXDAwMFwNLlwwMDA7 XDAwMCBcMDAwZVwwMDB4XDAwMHBcMDAwZVwwMDByXDAwMGlcMDAwZVwwMDBuXDAwMGNcMDAw ZVwwMDBzXDAwMCBcMDAwXA13XDAwMGlcMDAwdFwwMDBoXDAwMCBcMDAwclwwMDBlXDAwMGFc MDAwbFwwMDAtXDAwMHdcMDAwb1wwMDByXDAwMGxcMDAwZFwwMDBcDSBcMDAwYVwwMDBwXDAw MHBcMDAwbFwwMDBpXDAwMGNcMDAwYVwwMDB0XDAwMGlcMDAwb1wwMDBuXDAwMHNcMDAwXHJc MDAwXG5cDVwwMDBcclwwMDBcblwwMDAtXDAwMCBcMDAwV1wwMDBoXDAwMGFcMDAwdFwwMDAg XDAwMHBcMDAwYVwwMDByXDAwMHRcMDAwIFwNXDAwMHdcMDAwaVwwMDBsXDAwMGxcMDAwIFww MDBXXDAwMFNcMDAwTlwwMDBzXDAwMCBcMDAwcFwwMDBsXDAwMGFcMDAweVwwMDBcDSBcMDAw aVwwMDBuXDAwMCBcMDAwclwwMDBlXDAwMGFcMDAwbFwwMDBpXDAwMHpcMDAwaVwwMDBuXDAw MGdcMDAwIFwwMDB0XDAwMFwNaFwwMDBlXDAwMCBcMDAwdlwwMDBpXDAwMHNcMDAwaVwwMDBv XDAwMG5cMDAwc1wwMDAgXDAwMG9cMDAwZlwwMDAgXDAwMHVcMDAwXA1iXDAwMGlcMDAwcVww MDB1XDAwMGlcMDAwdFwwMDBvXDAwMHVcMDAwc1wwMDAgXDAwMGNcMDAwb1wwMDBtXDAwMHBc MDAwdVwwMDBcDXRcMDAwaVwwMDBuXDAwMGdcMDAwIFwwMDAmXDAwMCBcMDAwY1wwMDBvXDAw MG1cMDAwbVwwMDB1XDAwMG5cMDAwaVwwMDBjXDAwMFwNYVwwMDB0XDAwMGlcMDAwb1wwMDBu XDAwMCBcMDAwYVwwMDBuXDAwMGRcMDAwIFwwMDBBXDAwMG1cMDAwYlwwMDBpXDAwMGVcMDAw XA1uXDAwMHRcMDAwIFwwMDBJXDAwMG5cMDAwdFwwMDBlXDAwMGxcMDAwbFwwMDBpXDAwMGdc MDAwZVwwMDBuXDAwMGNcMDAwZVwwMDBcDT9cMDAwXHJcMDAwXG5cMDAwXHJcMDAwXG5cMDAw LVwwMDAgXDAwMFBcMDAwclwwMDBvXDAwMHRcMDAwb1wwMDB0XDAwMHlcMDAwXA1wXDAwMGVc MDAwc1wwMDAsXDAwMCBcMDAwZlwwMDBpXDAwMGVcMDAwbFwwMDBkXDAwMCBcMDAwc1wwMDB0 XDAwMHVcMDAwZFwwMDBcDWlcMDAwZVwwMDBzXDAwMCxcMDAwIFwwMDBhXDAwMG5cMDAwZFww MDAgXDAwMHRcMDAwZVwwMDBzXDAwMHRcMDAwYlwwMDBlXDAwMFwNZFwwMDBzXDAwMCxcMDAw IFwwMDBlXDAwMC5cMDAwZ1wwMDAuXDAwMDpcMDAwIFwwMDAgXDAwMG5cMDAwb1wwMDB2XDAw MGVcMDAwXA1sXDAwMCBcMDAwc1wwMDBlXDAwMG5cMDAwc1wwMDBvXDAwMHJcMDAwIFwwMDBu XDAwMG9cMDAwZFwwMDBlXDAwMCBcMDAwcFwwMDBcDXJcMDAwb1wwMDB0XDAwMG9cMDAwdFww MDB5XDAwMHBcMDAwZVwwMDBzXDAwMCxcMDAwIFwwMDBtXDAwMGVcMDAwYVwwMDBzXDAwMFwN dVwwMDByXDAwMGVcMDAwbVwwMDBlXDAwMG5cMDAwdFwwMDBzXDAwMCBcMDAwd1wwMDBpXDAw MHRcMDAwaFwwMDBpXDAwMG5cMDAwXA0gXDAwMHNcMDAwZVwwMDBuXDAwMHNcMDAwb1wwMDBy XDAwMCBcMDAwblwwMDBlXDAwMHRcMDAwd1wwMDBvXDAwMHJcMDAwa1wwMDBcDSBcMDAwdFww MDBlXDAwMHNcMDAwdFwwMDBiXDAwMGVcMDAwZFwwMDBzXDAwMFxyXDAwMFxuXDAwMFxyXDAw MFxuXDAwMC1cMDAwXA0gXDAwME1cMDAwb1wwMDBkXDAwMGVcMDAwbFwwMDBpXDAwMG5cMDAw Z1wwMDAgXDAwMG9cMDAwZlwwMDAgXDAwMFdcMDAwU1wwMDBcDU5cMDAwLFwwMDAgXDAwMGVc MDAwLlwwMDBnXDAwMC5cMDAwOlwwMDAgXDAwMG1cMDAwb1wwMDBkXDAwMGVcMDAwbFwwMDBz XDAwMFwNIFwwMDBmXDAwMG9cMDAwclwwMDAgXDAwMFdcMDAwU1wwMDBOXDAwMC1cMDAwIFww MDBsXDAwMG9cMDAwYVwwMDBkXDAwMC9cMDAwXA1hXDAwMHBcMDAwcFwwMDBsXDAwMGlcMDAw Y1wwMDBhXDAwMHRcMDAwaVwwMDBvXDAwMG5cMDAwc1wwMDAsXDAwMCBcMDAwbVwwMDBcDW9c MDAwYlwwMDBpXDAwMGxcMDAwaVwwMDB0XDAwMHlcMDAwIFwwMDBvXDAwMHJcMDAwIFwwMDBj XDAwMGhcMDAwYVwwMDBuXDAwMFwNblwwMDBlXDAwMGxcMDAwIFwwMDBtXDAwMG9cMDAwZFww MDBlXDAwMGxcMDAwc1wwMDBcclwwMDBcblwwMDBcclwwMDBcblwwMDBcDVwwMDApDS9QIDgx IDAgUiANL0sgWyA1NiAwIFIgNTcgMCBSIDU4IDAgUiA1OSAwIFIgNjAgMCBSIDYxIDAgUiA2 MiAwIFIgNjMgMCBSIDY0IDAgUiBdIA0+PiANZW5kb2JqDTg2IDAgb2JqDTw8IA0vUyAvVGV4 dEJveCANL0FsdCAoVGV4dCBCb3g6IEltcG9ydGFudCBEYXRlczpcdFx0XHJcblN1Ym1pc3Np b24gZGVhZGxpbmU6XHRcdCAxLkp1bHksIDIwMDNcclwNXG5Ob3RpZmljYXRpb24gb2YgYWNj ZXB0YW5jZTogXHQgMS5TZXB0ZW1iZXIsIDIwMDNcclxuQ2FtZXJhLXJlYWR5IHZlcnNpXA1v bjpcdCAxLk9jdG9iZXIsIDIwMDNcclxuV29yay1pbi1wcm9ncmVzcyBzdWJtaXNzaW9uOiAx NS4gTm92ZW1iZXIsIDIwMDNcDVxyXG5cMDAwKQ0vUCA4MSAwIFIgDS9LIFsgNjUgMCBSIDY2 IDAgUiA2NyAwIFIgNjggMCBSIDY5IDAgUiBdIA0+PiANZW5kb2JqDTg3IDAgb2JqDTw8IA0v UyAvVGV4dEJveCANL0FsdCAoVGV4dCBCb3g6IEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVh c2UgdmlzaXQ6IGh0dHA6Ly93d3cuZXdzbi5vcmdcMDAwKQ0vUCA4MSAwIFIgDS9LIDcwIDAg UiANPj4gDWVuZG9iag04OCAwIG9iag08PCANL1MgL1NoYXBlIA0vQWx0ICgpDS9QZyAxMDkg MCBSIA0vSyA2MyANL1AgODEgMCBSIA0vQSA5NyAwIFIgDT4+IA1lbmRvYmoNODkgMCBvYmoN PDwgDS9TIC9UZXh0Qm94IA0vQWx0IChUZXh0IEJveDogU3VibWlzc2lvbnMgc2hvdWxkIG5v dCBleGNlZWQgMTYgcGFnZXM7IGZvcm1hdHRpbmcgZ3VpZGVsaW5lcyBcDWFyZSBkZXNjcmli ZWQgb24gdGhlIHdlYnBhZ2UuIFRoZSBwcm9jZWVkaW5ncyB3aWxsIGJlIHB1Ymxpc2hlZCBi eSBTcHJpblwNZ2VyIGluIHRoZSBMTkNTIHNlcmllcy4gXHJcbiBcclxuXDAwMCkNL1AgODEg MCBSIA0vSyBbIDcyIDAgUiA3NSAwIFIgXSANPj4gDWVuZG9iag05MCAwIG9iag08PCANL1Mg L1RleHRCb3ggDS9BbHQgKFRleHQgQm94OiBTdXBwb3J0ZWQgYnkgdGhlIEpvaW50IElFRUUg SUFTL1BFTFMvSUVTIEdlcm1hbiBDaGFwdGVyXHJcbiBcclwNXG5cMDAwKQ0vUCA4MSAwIFIg DS9LIFsgNzggMCBSIDc5IDAgUiBdIA0+PiANZW5kb2JqDTkxIDAgb2JqDTw8IA0vTnVtcyBb IDAgOTIgMCBSIDEgNzMgMCBSIF0gDT4+IA1lbmRvYmoNOTIgMCBvYmoNWyANMiAwIFIgNiAw IFIgMiAwIFIgNyAwIFIgOSAwIFIgNDIgMCBSIDQ0IDAgUiA0NSAwIFIgMTEgMCBSIDEyIDAg UiANMTMgMCBSIDE0IDAgUiAxNSAwIFIgMTYgMCBSIDE4IDAgUiAxOSAwIFIgMjAgMCBSIDIx IDAgUiAyMiAwIFIgMjMgMCBSIA0yNCAwIFIgMjUgMCBSIDI2IDAgUiAyNyAwIFIgMjggMCBS IDI5IDAgUiAzMCAwIFIgMzEgMCBSIDMyIDAgUiAzMyAwIFIgDTM0IDAgUiAzNSAwIFIgMzYg MCBSIDM3IDAgUiAzOCAwIFIgMzkgMCBSIDQwIDAgUiA0MSAwIFIgNDYgMCBSIDQ3IDAgUiAN NDggMCBSIDQ5IDAgUiA1MCAwIFIgNTEgMCBSIDUyIDAgUiA1MyAwIFIgNTQgMCBSIDU1IDAg UiA1NiAwIFIgNTcgMCBSIA01OCAwIFIgNTkgMCBSIDYwIDAgUiA2MSAwIFIgNjIgMCBSIDYz IDAgUiA2NCAwIFIgNjUgMCBSIDY2IDAgUiA2NyAwIFIgDTY4IDAgUiA2OSAwIFIgNzAgMCBS IDg4IDAgUiA3MiAwIFIgNzQgMCBSIDc3IDAgUiA3MiAwIFIgNzcgMCBSIDc4IDAgUiANODAg MCBSIDc5IDAgUiANXQ1lbmRvYmoNOTMgMCBvYmoNPDwgDS9PIC9MYXlvdXQgDS9CYXNlbGlu ZVNoaWZ0IDEyIA0+PiANZW5kb2JqDTk0IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vVGV4dERl Y29yYXRpb25UeXBlIC9VbmRlcmxpbmUgDT4+IA1lbmRvYmoNOTUgMCBvYmoNPDwgDS9PIC9M YXlvdXQgDS9CQm94IFsgNDc0IDg1IDU4NyAxMTkgXSANL1BsYWNlbWVudCAvSW5saW5lIA0+ PiANZW5kb2JqDTk2IDAgb2JqDTw8IA0vTyAvTGF5b3V0IA0vQkJveCBbIDI1IDEwNSAxNDUg MTI0IF0gDS9QbGFjZW1lbnQgL0lubGluZSANPj4gDWVuZG9iag05NyAwIG9iag08PCANL08g L0xheW91dCANL0JCb3ggWyAxNjkgNDY2IDU5NSA0NjkgXSANL1BsYWNlbWVudCAvQmxvY2sg DS9TdGFydEluZGVudCA3OSANL0VuZEluZGVudCAtMTAgDT4+IA1lbmRvYmoNOTggMCBvYmoN PDwgDS9TIC9EIA0+PiANZW5kb2JqDTk5IDAgb2JqDTw8IA0vTnVtcyBbIDAgOTggMCBSIF0g DT4+IA1lbmRvYmoNMTAwIDAgb2JqDTw8IA0vUHJvZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVy IDUuMC41IFwoV2luZG93c1wpKQ0vQXV0aG9yIChIb2xnZXIgS2FybCkNL0NyZWF0b3IgKEFj cm9iYXQgUERGTWFrZXIgNS4wIGZvciBXb3JkKQ0vTW9kRGF0ZSAoRDoyMDAzMDQyNzEzMzIz NyswMycwMCcpDS9UaXRsZSAoMXN0IEludGVybmF0aW9uYWwgQW5udWFsIEJlcmxpbikNL0Ny ZWF0aW9uRGF0ZSAoRDoyMDAzMDQyNzEzMzEzMyswMicwMCcpDT4+IA1lbmRvYmoNMTAxIDAg b2JqDTw8IC9UeXBlIC9NZXRhZGF0YSAvU3VidHlwZSAvWE1MIC9MZW5ndGggMTA5NiA+PiAN c3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49JycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6a2M5 ZCcgYnl0ZXM9JzEwOTUnPz48cmRmOlJERiB4bWxuczpyZGY9J2h0dHA6Ly93d3cudzMub3Jn LzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMnIHhtbG5zOmlYPSdodHRwOi8vbnMuYWRvYmUu Y29tL2lYLzEuMC8nPjxyZGY6RGVzY3JpcHRpb24gYWJvdXQ9JycgeG1sbnM9J2h0dHA6Ly9u cy5hZG9iZS5jb20vcGRmLzEuMy8nIHhtbG5zOnBkZj0naHR0cDovL25zLmFkb2JlLmNvbS9w ZGYvMS4zLycgcGRmOkNyZWF0aW9uRGF0ZT0nMjAwMy0wNC0yN1QxMTozMTozM1onIHBkZjpN b2REYXRlPScyMDAzLTA0LTI3VDExOjMxOjMzWicgcGRmOlByb2R1Y2VyPSdBY3JvYmF0IERp c3RpbGxlciA1LjAuNSAoV2luZG93cyknIHBkZjpBdXRob3I9J0hvbGdlciBLYXJsJyBwZGY6 Q3JlYXRvcj0nQWNyb2JhdCBQREZNYWtlciA1LjAgZm9yIFdvcmQnIHBkZjpUaXRsZT0nMXN0 IEludGVybmF0aW9uYWwgQW5udWFsIEJlcmxpbicvPgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0 PScnIHhtbG5zPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvJyB4bWxuczp4YXA9J2h0 dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8nIHhhcDpDcmVhdGVEYXRlPScyMDAzLTA0LTI3 VDExOjMxOjMzWicgeGFwOk1vZGlmeURhdGU9JzIwMDMtMDQtMjdUMTE6MzE6MzNaJyB4YXA6 QXV0aG9yPSdIb2xnZXIgS2FybCcgeGFwOk1ldGFkYXRhRGF0ZT0nMjAwMy0wNC0yN1QxMToz MTozM1onPjx4YXA6VGl0bGU+PHJkZjpBbHQ+PHJkZjpsaSB4bWw6bGFuZz0neC1kZWZhdWx0 Jz4xc3QgSW50ZXJuYXRpb25hbCBBbm51YWwgQmVybGluPC9yZGY6bGk+PC9yZGY6QWx0Pjwv eGFwOlRpdGxlPjwvcmRmOkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIGFib3V0PScn IHhtbG5zPSdodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgeG1sbnM6ZGM9J2h0 dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEvJyBkYzpjcmVhdG9yPSdIb2xnZXIgS2Fy bCcgZGM6dGl0bGU9JzFzdCBJbnRlcm5hdGlvbmFsIEFubnVhbCBCZXJsaW4nLz4KPC9yZGY6 UkRGPjw/eHBhY2tldCBlbmQ9J3InPz4KZW5kc3RyZWFtDWVuZG9iag0xMDIgMCBvYmoNPDwg DS9UeXBlIC9QYWdlcyANL0tpZHMgWyAxMDkgMCBSIF0gDS9Db3VudCAxIA0+PiANZW5kb2Jq DXhyZWYNMCAxMDMgDTAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDA5MzczOCAwMDAwMCBuDQow MDAwMDk0MDI2IDAwMDAwIG4NCjAwMDAwOTQxMjkgMDAwMDAgbg0KMDAwMDA5NDE5NyAwMDAw MCBuDQowMDAwMDk0MjUzIDAwMDAwIG4NCjAwMDAwOTQ0MDMgMDAwMDAgbg0KMDAwMDA5NDQ4 MyAwMDAwMCBuDQowMDAwMDk0NTc0IDAwMDAwIG4NCjAwMDAwOTQ2MjYgMDAwMDAgbg0KMDAw MDA5NDcxOCAwMDAwMCBuDQowMDAwMDk0NzcxIDAwMDAwIG4NCjAwMDAwOTQ5MDIgMDAwMDAg bg0KMDAwMDA5NTAzMyAwMDAwMCBuDQowMDAwMDk1MTY1IDAwMDAwIG4NCjAwMDAwOTUyOTcg MDAwMDAgbg0KMDAwMDA5NTQzMyAwMDAwMCBuDQowMDAwMDk1NTY5IDAwMDAwIG4NCjAwMDAw OTU3MjkgMDAwMDAgbg0KMDAwMDA5NTg2NSAwMDAwMCBuDQowMDAwMDk2MDAxIDAwMDAwIG4N CjAwMDAwOTYxMzcgMDAwMDAgbg0KMDAwMDA5NjI3MyAwMDAwMCBuDQowMDAwMDk2NDA5IDAw MDAwIG4NCjAwMDAwOTY1NDUgMDAwMDAgbg0KMDAwMDA5NjY4MSAwMDAwMCBuDQowMDAwMDk2 ODE3IDAwMDAwIG4NCjAwMDAwOTY5NTMgMDAwMDAgbg0KMDAwMDA5NzA4OSAwMDAwMCBuDQow MDAwMDk3MjI1IDAwMDAwIG4NCjAwMDAwOTczNjEgMDAwMDAgbg0KMDAwMDA5NzQ5NyAwMDAw MCBuDQowMDAwMDk3NjMzIDAwMDAwIG4NCjAwMDAwOTc3NjkgMDAwMDAgbg0KMDAwMDA5Nzkw NSAwMDAwMCBuDQowMDAwMDk4MDQxIDAwMDAwIG4NCjAwMDAwOTgxNzcgMDAwMDAgbg0KMDAw MDA5ODMwOSAwMDAwMCBuDQowMDAwMDk4NDQxIDAwMDAwIG4NCjAwMDAwOTg1NzMgMDAwMDAg bg0KMDAwMDA5ODcwNSAwMDAwMCBuDQowMDAwMDk4ODM3IDAwMDAwIG4NCjAwMDAwOTg5Njkg MDAwMDAgbg0KMDAwMDA5OTA2MiAwMDAwMCBuDQowMDAwMDk5MTUxIDAwMDAwIG4NCjAwMDAw OTkyODEgMDAwMDAgbg0KMDAwMDA5OTQxMSAwMDAwMCBuDQowMDAwMDk5NTQyIDAwMDAwIG4N CjAwMDAwOTk2NzMgMDAwMDAgbg0KMDAwMDA5OTgwNCAwMDAwMCBuDQowMDAwMDk5OTM1IDAw MDAwIG4NCjAwMDAxMDAwNjYgMDAwMDAgbg0KMDAwMDEwMDE5NyAwMDAwMCBuDQowMDAwMTAw MzI4IDAwMDAwIG4NCjAwMDAxMDA0NTkgMDAwMDAgbg0KMDAwMDEwMDU5MCAwMDAwMCBuDQow MDAwMTAwNzIxIDAwMDAwIG4NCjAwMDAxMDA4NTMgMDAwMDAgbg0KMDAwMDEwMDk4NSAwMDAw MCBuDQowMDAwMTAxMTE3IDAwMDAwIG4NCjAwMDAxMDEyNDkgMDAwMDAgbg0KMDAwMDEwMTM4 MSAwMDAwMCBuDQowMDAwMTAxNTEzIDAwMDAwIG4NCjAwMDAxMDE2NDUgMDAwMDAgbg0KMDAw MDEwMTc3NyAwMDAwMCBuDQowMDAwMTAxOTA5IDAwMDAwIG4NCjAwMDAxMDIwNDAgMDAwMDAg bg0KMDAwMDEwMjE3MSAwMDAwMCBuDQowMDAwMTAyMzAyIDAwMDAwIG4NCjAwMDAxMDI0MzMg MDAwMDAgbg0KMDAwMDEwMjU2NCAwMDAwMCBuDQowMDAwMTAyNjU4IDAwMDAwIG4NCjAwMDAx MDI3NDYgMDAwMDAgbg0KMDAwMDEwMjg5MSAwMDAwMCBuDQowMDAwMTAyOTk0IDAwMDAwIG4N CjAwMDAxMDMwNzUgMDAwMDAgbg0KMDAwMDEwMzE2MCAwMDAwMCBuDQowMDAwMTAzMjQ5IDAw MDAwIG4NCjAwMDAxMDMzNTEgMDAwMDAgbg0KMDAwMDEwMzQ4MyAwMDAwMCBuDQowMDAwMTAz NjI2IDAwMDAwIG4NCjAwMDAxMDM3MjEgMDAwMDAgbg0KMDAwMDEwMzg3MSAwMDAwMCBuDQow MDAwMTA0OTgxIDAwMDAwIG4NCjAwMDAxMDk1MDkgMDAwMDAgbg0KMDAwMDExMDM3MCAwMDAw MCBuDQowMDAwMTE1NDg2IDAwMDAwIG4NCjAwMDAxMTU4MTYgMDAwMDAgbg0KMDAwMDExNTk1 MiAwMDAwMCBuDQowMDAwMTE2MDM3IDAwMDAwIG4NCjAwMDAxMTYzMDAgMDAwMDAgbg0KMDAw MDExNjQ1OCAwMDAwMCBuDQowMDAwMTE2NTExIDAwMDAwIG4NCjAwMDAxMTcwMzkgMDAwMDAg bg0KMDAwMDExNzA5NCAwMDAwMCBuDQowMDAwMTE3MTYyIDAwMDAwIG4NCjAwMDAxMTcyNDQg MDAwMDAgbg0KMDAwMDExNzMyNiAwMDAwMCBuDQowMDAwMTE3NDQxIDAwMDAwIG4NCjAwMDAx MTc0NzIgMDAwMDAgbg0KMDAwMDExNzUxNiAwMDAwMCBuDQowMDAwMTE3NzY4IDAwMDAwIG4N CjAwMDAxMTg5NDkgMDAwMDAgbg0KdHJhaWxlcg08PA0vU2l6ZSAxMDMNL0lEWzw1NGU5NTNm YWExYjBhMTEwNTIwOWFjN2U5YWFkZjBjOT48NjZhMzQ1NDQ1Y2Y4OGU0YzRkYjU5MzJiYWY4 NWM1ZWM+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ== --------------080302020105080309090201-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 5 23:57:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26051 for ; Mon, 5 May 2003 23:57:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4645gM30344 for avt-archive@odin.ietf.org; Tue, 6 May 2003 00:05:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4644v830327; Tue, 6 May 2003 00:04:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4642x830202 for ; Tue, 6 May 2003 00:02:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25993 for ; Mon, 5 May 2003 23:53:56 -0400 (EDT) From: Silvia.Pfeiffer@csiro.au Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CtYg-0002xs-00 for avt@ietf.org; Mon, 05 May 2003 23:56:02 -0400 Received: from snowy.nsw.cmis.csiro.au ([130.155.16.108]) by ietf-mx with smtp (Exim 4.12) id 19CtYa-0002xh-00 for avt@ietf.org; Mon, 05 May 2003 23:55:56 -0400 Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id NAA26221; Tue, 6 May 2003 13:55:32 +1000 Received: from coxs-nh.nsw.cmis.CSIRO.AU(130.155.25.7) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa006Pf; Tue May 6 13:55:30 2003 Received: by coxs-nh.nsw.cmis.CSIRO.AU with Internet Mail Service (5.5.2656.59) id ; Tue, 6 May 2003 13:55:29 +1000 Received: from csiro.au (klee.nsw.cmis.CSIRO.AU [130.155.20.11]) by coxs-nh.nsw.cmis.csiro.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id JBJZKRFY; Tue, 6 May 2003 13:55:26 +1000 To: oliver@metaglue.com Cc: William.C.Miller@abc.com, Conrad.Parker@csiro.au, s22-list@eng.smpte.org, avt@ietf.org Message-ID: <3EB731EE.8050405@csiro.au> Date: Tue, 06 May 2003 13:54:22 +1000 Organization: CSIRO User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en, de, fr MIME-Version: 1.0 References: <011a01c311b4$29e7d2f0$0200a8c0@WOL> In-Reply-To: <011a01c311b4$29e7d2f0$0200a8c0@WOL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: (s22-list) Re: Comments, draft-pfeiffer-temporal-fragments-00 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dear Mr. Morgan, Thank you very much for your eamil. I have had several requests from other people on exactly that same extension. As there seems to be a need for this extension, we can include it into the I-D as an option. The I-D is currently getting discussed at uri@w3.org, but is still in its early stages of discussion. I hope to publish an updated version of the I-D soon. Best Regards, Silvia Pfeiffer. Oliver Morgan wrote: > Dear Ms. Pfeiffer and Mr. Parker, > > I have read and concur with Bill Miller's comments on your draft on > temporal fragments. > > As an additional input, you might like to contemplate recommending a > notation for fragments of known duration. > > It is conventional to express these in television systems as two SMPTE > timecodes, an IN and an OUT time. The IN time specifies the first frame > or field that is included in the interval; the OUT time specifies the > first frame or field that is *not* included in the interval. > > Thus an interval of duration 10 frames might be specified as > #@smpte=01:00:00.00-01:00:00.10 > > best regards > Oliver Morgan > Metaglue Corporation > +1 781 862 2106 voice/fax > +1 781 962 3997 cell > oliver@metaglue.com > > > >>-----Original Message----- >>From: owner-s22-list@eng.smpte.org >>[mailto:owner-s22-list@eng.smpte.org] On Behalf Of >>Silvia.Pfeiffer@csiro.au >>Sent: Sunday, March 16, 2003 11:15 PM >>To: William.C.Miller@abc.com >>Cc: Conrad.Parker@csiro.au; s22-list@eng.smpte.org; avt@ietf.org >>Subject: (s22-list) Re: Comments, draft-pfeiffer-temporal-fragments-00 >> >> >>Dear Mr. Miller, >> >>I am delighted to get feedback from you and the SMPTE >>community on our >>timed URI fragment specification proposal. I would like to thank you >>very much for your well elaborated comments which we are more >>than happy >>to include into our proposal. >> >>We will be developing another version of the document over >>the next few >>weeks. If I may, I would like to forward you the next >>version, just to >>make sure we haven't overlooked anything. >> >>Also, in case there are any relevant changes in the new >>version of SMPTE >>12M, I would be very happy if you could make me aware of them. >> >>Thank you very much indeed. >> >>Best Regards, >> >>Silvia Pfeiffer. >> >> >>Miller, William C wrote: >> >>>Dear Ms. Pfeiffer and Mr. Parker, >>> >>>Your draft was recently passed on to me by a SMPTE >> >>colleague. I'd like >> >>>to offer a couple of comments. I am not familiar with all of the >>>practices of the IETF community, so forgive me if I commit >> >>a solecism or >> >>>two along the way. >>> >>>I'm chairman of SMPTE S22, the TV Systems Technology >> >>Committee, which >> >>>has responsibility for SMPTE time code. I'm writing as an >> >>individual >> >>>commenter. >>> >>>1. SMPTE has about 400 Standards, Recommended Practices >> >>and Engineering >> >>>Guidelines, of which SMPTE time code is just one. The >> >>reference you >> >>>should cite is SMPTE 12M-1999, Time and Control Code. Be >> >>aware that we >> >>>are in the process of considering revisions to this document. >>> >>>2. The current version of SMPTE 12M defines time code for >> >>24, 25 and 30 >> >>>frames per second (fps). Video production standards for >> >>all of these >> >>>exist and are in use. A drop-frame mode is defined for 30 >> >>fps (actually >> >>>30/1.001 fps) to cover 525-line systems (NTSC >> >>time-compensated mode). >> >>>However, there are now 50, 60 and 60/1.001 fps video production >>>standards, and practices have evolved to deal with these within the >>>structure of SMPTE 12M. These practices will be added to >> >>12M as it is >> >>>revised. A possibility also exists that there will be >> >>24/1.001 fps video. >> >>>To be safe you should define syntax to handle all 8 of >> >>these rates (all >> >>>are allowable under MPEG-2, for instance). Recapping them in order: >>> >>>24/1.001 "24-drop" (this algorithm is not defined) >>>24 >>>25 >>>30/1.001 "30-drop" >>>30 >>>50 >>>60/1.001 "60-drop" (same algorithm as 30-drop, but 4 frames dropped >>>rather than 2) >>>60 >>> >>>Your draft gives 30 fps (non-drop) as the default; in >> >>practice this is >> >>>the least likely frame rate to be encountered. I believe it is >>>preferable to require explicit coding of the frame rate, e. g. >>>"smpte-30-time". "smpte-time" should be allowed only for >> >>those cases >> >>>where the user does not know the frame rate; this would >> >>serve as a wild >> >>>card, with best-effort address resolution (the error would >> >>be no more >> >>>than one second, typically much less). >>> >>>3. Although not generally understood as such, SMPTE time code is a >>>label. Its lowest granularity is the frame for >> >>progressive-scan and >> >>>film material and the field for interlaced material. >> >>Fractional frames >> >>>(fields) are meaningless for video, and in the case of the >> >>/1.001 rates >> >>>are ambiguous for audio. I urge you to delete "smpte-sf". >>> >>>4. The first frame of video of a program is normally >> >>01:00:00:00, not >> >>>00:00:00:00. This practice arose from the requirements of program >>>production and analog videotape recording technology, and it has >>>subsequently become a uniform, almost ironclad practice worldwide. >>>Users should be made aware of this in an informative note. >>> >>>I hope these comments are of help in refining your draft. I am >>>attaching a copy of SMPTE 12M for your use. Please do not >> >>redistribute >> >>>it except to those involved in the development of this RFC. Thanks. >>> >>>If I can be of further help please let me know. >>> >>>Best regards, >>>Bill Miller >>> >>> >>> >>>William C. Miller >>>ABC-TV >>>212-456-4448 >>>212-456-2284 fax >>>william.c.miller@abc.com >>> >> >> > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 6 03:43:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10833 for ; Tue, 6 May 2003 03:43:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h467phu24386 for avt-archive@odin.ietf.org; Tue, 6 May 2003 03:51:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467pD824350; Tue, 6 May 2003 03:51:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h467jZ823997 for ; Tue, 6 May 2003 03:45:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10643 for ; Tue, 6 May 2003 03:36:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Cx20-00040F-00 for avt@ietf.org; Tue, 06 May 2003 03:38:32 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Cx1u-0003yp-00 for avt@ietf.org; Tue, 06 May 2003 03:38:27 -0400 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h467aR0J024020; Tue, 6 May 2003 09:36:31 +0200 (MEST) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 6 May 2003 09:36:24 +0200 Message-ID: From: "Lars-Erik Jonsson (EAB)" To: "'Jae-Yong Lee'" , Adam Li , Colin Perkins Cc: avt@ietf.org, Scott Bradner , Allison Mankin Subject: RE: [AVT] The storage format of EVRC/SMV vocoder (resent) Date: Tue, 6 May 2003 09:36:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi all, The EVRC/SMV draft was put on hold at the IANA while the file format issue was discussed, but should we not be ready to let it go now, as originally intended? The format we have worked on for a few years now is actually used as file format, and we should complete our work on that. Whether to address the qcp format separately must be left independent of the evrc/smv standard. Let's finally get the EVRC/SMV file format out! BR /Lars-Erik > -----Original Message----- > From: Jae-Yong Lee [mailto:jlee@nextreaming.com] > Sent: den 1 maj 2003 10:58 > To: Adam Li; Colin Perkins > Cc: avt@ietf.org; Scott Bradner; Allison Mankin; > craig.greer@nokia.com; > sakazawa@kddilabs.jp; keith.miller@nokia.com; ??? (E-mail); ??? > (E-mail); ??? (E-mail); ??? (E-mail) > Subject: RE: [AVT] The storage format of EVRC/SMV vocoder (resent) > > > Hello all, > > I regret not being able to respond earlier. > It took some time to contact all the Korean operators and reconfirm > their opinions related to this issue. > As the representative of Korean operators (SKT/KTF/LGT) for file > format issues in 3GPP2, I'd like to clarify the current situation for > Korean operators and deliver our opinions on this issue. > (I cc:ed relevant people from the operators.) > > >> My information on the implementation of the evrc-smv > draft's format > >> is that Nextreaming uses this as an internal intermediate format > >> prior to generating ".3g2" files (as specified in the 3GPP2 FFMS > >> specification, which include both formats). > > This is not correct. > The EVRC storage format described in the evrc-smv draft is utilized > for Korean operators in such way as described in the current 3GPP2 > FFMS specification, which is actually the only way for EVRC media > storage in the 3GPP2 multimedia file format (.3g2). > The way of storing EVRC media in .3g2 file is exactly same as the > way described in the evrc-smv draft except for the magic number, > "#!EVRC\n", which will not be included in the .3g2 file format. > That is conceptually same as AMR storage in 3GPP file format. > One of the most important rationale behind this is to facilitate the > conversion of 3GPP2 files from/to EVRC-only files (.3g2 <-> .evc), > which may be very helpful for some applications, e.g., MMS. > > Having said that, Nextreaming is not the only one that implements > and uses it. The relevant terminal and system vendors for Korean > operators have completed implementation based on this format and > verified interop. > Korean operators (also many others in 3GPP2 as far as I understand) > have been waiting for the evrc-smv draft with the storage > method to be > approved as an RFC and are looking forward to it. > We also share the opinion that the evrc-smv internet draft is > independent > of the possible registration of MIME type for .qcp. > > BR, > > Jay _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 6 08:20:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17201 for ; Tue, 6 May 2003 08:20:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46BrNo14652 for avt-archive@odin.ietf.org; Tue, 6 May 2003 07:53:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Br1814626; Tue, 6 May 2003 07:53:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Bn5814447 for ; Tue, 6 May 2003 07:49:05 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14948; Tue, 6 May 2003 07:40:06 -0400 (EDT) Message-Id: <200305061140.HAA14948@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 06 May 2003 07:40:06 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-feedback-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Extended RTP Profile for RTCP-based Feedback(RTP/AVPF) Author(s) : J. Ott, S. Wenger, N. Sato Filename : draft-ietf-avt-rtcp-feedback-06.txt Pages : 51 Date : 2003-5-5 Real-time media streams that use RTP are, to some degree, resilient against packet losses. Receivers may use the base mechanisms of RTCP to report packet reception statistics and thus allow a sender to adapt its transmission behavior in the mid-term as sole means for feedback and feedback-based error repair (besides a few codec- specific mechanisms). This document defines an extension to the Audio-visual Profile (AVP) that enables receivers to provide, statistically, more immediate feedback to the senders and thus allow for short-term adaptation and efficient feedback-based repair mechanisms to be implemented. This early feedback profile (AVPF) maintains the AVP bandwidth constraints for RTCP and preserves scalability to large groups. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-feedback-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcp-feedback-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcp-feedback-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-5145543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-feedback-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-feedback-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-5145543.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 6 09:09:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19870 for ; Tue, 6 May 2003 09:09:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46DIEa22069 for avt-archive@odin.ietf.org; Tue, 6 May 2003 09:18:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46DHY821966; Tue, 6 May 2003 09:17:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46DFT821743 for ; Tue, 6 May 2003 09:15:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19345 for ; Tue, 6 May 2003 09:06:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D273-0006SX-00 for avt@ietf.org; Tue, 06 May 2003 09:04:05 -0400 Received: from dial162.east.isi.edu ([65.114.169.162] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19D26w-0006Ms-00 for avt@ietf.org; Tue, 06 May 2003 09:03:58 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h46D16JC059786; Tue, 6 May 2003 09:01:06 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: "Lars-Erik Jonsson (EAB)" cc: "'Jae-Yong Lee'" , Adam Li , avt@ietf.org, Scott Bradner , Allison Mankin Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) In-Reply-To: Your message of "Tue, 06 May 2003 09:36:18 +0200." Date: Tue, 06 May 2003 09:01:06 -0400 Message-ID: <59785.1052226066@purple.nge.isi.edu> From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Lars-Erik, The draft has been released, and is just waiting for the RFC Editor and IANA to finish their work. Colin --> "Lars-Erik Jonsson (EAB)" writes: >Hi all, > >The EVRC/SMV draft was put on hold at the IANA while the file >format issue was discussed, but should we not be ready to let >it go now, as originally intended? The format we have worked >on for a few years now is actually used as file format, and >we should complete our work on that. Whether to address the >qcp format separately must be left independent of the evrc/smv >standard. > >Let's finally get the EVRC/SMV file format out! > >BR >/Lars-Erik > > > >> -----Original Message----- >> From: Jae-Yong Lee [mailto:jlee@nextreaming.com] >> Sent: den 1 maj 2003 10:58 >> To: Adam Li; Colin Perkins >> Cc: avt@ietf.org; Scott Bradner; Allison Mankin; >> craig.greer@nokia.com; >> sakazawa@kddilabs.jp; keith.miller@nokia.com; ??? (E-mail); ??? >> (E-mail); ??? (E-mail); ??? (E-mail) >> Subject: RE: [AVT] The storage format of EVRC/SMV vocoder (resent) >> >> >> Hello all, >> >> I regret not being able to respond earlier. >> It took some time to contact all the Korean operators and reconfirm >> their opinions related to this issue. >> As the representative of Korean operators (SKT/KTF/LGT) for file >> format issues in 3GPP2, I'd like to clarify the current situation for >> Korean operators and deliver our opinions on this issue. >> (I cc:ed relevant people from the operators.) >> >> >> My information on the implementation of the evrc-smv >> draft's format >> >> is that Nextreaming uses this as an internal intermediate format >> >> prior to generating ".3g2" files (as specified in the 3GPP2 FFMS >> >> specification, which include both formats). >> >> This is not correct. >> The EVRC storage format described in the evrc-smv draft is utilized >> for Korean operators in such way as described in the current 3GPP2 >> FFMS specification, which is actually the only way for EVRC media >> storage in the 3GPP2 multimedia file format (.3g2). >> The way of storing EVRC media in .3g2 file is exactly same as the >> way described in the evrc-smv draft except for the magic number, >> "#!EVRC\n", which will not be included in the .3g2 file format. >> That is conceptually same as AMR storage in 3GPP file format. >> One of the most important rationale behind this is to facilitate the >> conversion of 3GPP2 files from/to EVRC-only files (.3g2 <-> .evc), >> which may be very helpful for some applications, e.g., MMS. >> >> Having said that, Nextreaming is not the only one that implements >> and uses it. The relevant terminal and system vendors for Korean >> operators have completed implementation based on this format and >> verified interop. >> Korean operators (also many others in 3GPP2 as far as I understand) >> have been waiting for the evrc-smv draft with the storage >> method to be >> approved as an RFC and are looking forward to it. >> We also share the opinion that the evrc-smv internet draft is >> independent >> of the possible registration of MIME type for .qcp. >> >> BR, >> >> Jay >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 6 09:09:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19872 for ; Tue, 6 May 2003 09:09:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46DIFQ22082 for avt-archive@odin.ietf.org; Tue, 6 May 2003 09:18:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46DHh822017; Tue, 6 May 2003 09:17:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46DGj821920 for ; Tue, 6 May 2003 09:16:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19717 for ; Tue, 6 May 2003 09:07:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D1ng-0005xu-00 for avt@ietf.org; Tue, 06 May 2003 08:44:04 -0400 Received: from beamer.mchh.siemens.de ([194.138.158.163]) by ietf-mx with esmtp (Exim 4.12) id 19D1nb-0005ws-00 for avt@ietf.org; Tue, 06 May 2003 08:43:59 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA00275; Tue, 6 May 2003 14:43:06 +0200 (MET DST) Received: from mchh274e.demchh201e.icn.siemens.de (mchh274e.mchh.siemens.de [139.21.200.84]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id OAA25340; Tue, 6 May 2003 14:43:05 +0200 (MET DST) Received: by mchh274e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 6 May 2003 14:42:43 +0200 Message-ID: From: Kreuter Ruediger To: "'Colin Perkins'" , avt@ietf.org Date: Tue, 6 May 2003 14:42:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [AVT] Clearmode Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi, in my view draft-ietf-avt-rtp-clearmode-00.txt is in a pretty final state now. There was only one comment according the MIME subtype, which could be clarified (to stay with the proposed name). So I would suggest to give it a last call. What's your opinion ? Regards Ruediger Kreuter _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 6 13:39:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00869 for ; Tue, 6 May 2003 13:39:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46HlZ512461 for avt-archive@odin.ietf.org; Tue, 6 May 2003 13:47:35 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Hfx811997; Tue, 6 May 2003 13:41:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46HYQ810665 for ; Tue, 6 May 2003 13:34:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00338 for ; Tue, 6 May 2003 13:25:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D6Du-0000oR-00 for avt@ietf.org; Tue, 06 May 2003 13:27:26 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19D6Dt-0000oO-00 for avt@ietf.org; Tue, 06 May 2003 13:27:25 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h46HRwKj021544; Tue, 6 May 2003 13:27:58 -0400 Message-ID: <006601c313f4$d6688d70$0401a8c0@berlin> From: "Paul E. Jones" To: , , , Date: Tue, 6 May 2003 13:27:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, As I was looking at this document, it appears that the extended reporting fields are all "mandatory". That is, it does not appear possible, for example, to signal "round trip delay" without also signaling "burst duration". Am I reading this correctly? Would it not be reasonable to consider that some devices may or may not have the capability to advertise some metrics, but not others. Please clarify. Thanks, Paul _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 6 14:52:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02940 for ; Tue, 6 May 2003 14:52:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46J1L718181 for avt-archive@odin.ietf.org; Tue, 6 May 2003 15:01:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46J0L818082; Tue, 6 May 2003 15:00:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46IvB817917 for ; Tue, 6 May 2003 14:57:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02744 for ; Tue, 6 May 2003 14:48:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D7Vx-0001MK-00 for avt@ietf.org; Tue, 06 May 2003 14:50:09 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19D7Vx-0001M5-00 for avt@ietf.org; Tue, 06 May 2003 14:50:09 -0400 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.14) id A3E716D027E; Tue, 06 May 2003 14:50:15 -0400 Reply-To: From: "Alan Clark" To: "'Paul E. Jones'" , Subject: RE: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05 Date: Tue, 6 May 2003 14:44:41 -0400 Message-ID: <003801c313ff$8e5a80f0$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <006601c313f4$d6688d70$0401a8c0@berlin> Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul The -05 draft makes it mandatory to provide values for each field in the report however in most cases there are defined values that can be used to indicate that a specific metric is unknown or unsupported. If this approach was not used then we would have to use a TLV approach (as ASN.1) or some other method of indicating whether a parameter was present or not. The ONLY mandatory parameters are SSRC and the packet loss and discard metrics. Within the intended application of the VoIP metrics payload - i.e. VoIP - it makes sense promote some minimal level of reporting. Part of the rationale for having this payload was to support more detailed reporting of packet loss and discard statistics than that currently provided by RFC1889. Regards Alan Clark Telchemy -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Paul E. Jones Sent: Tuesday, May 06, 2003 1:28 PM To: avt@ietf.org; alan@telchemy.com; almeroth@cs.ucsb.edu; ramon@shieldip.com Subject: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05 Folks, As I was looking at this document, it appears that the extended reporting fields are all "mandatory". That is, it does not appear possible, for example, to signal "round trip delay" without also signaling "burst duration". Am I reading this correctly? Would it not be reasonable to consider that some devices may or may not have the capability to advertise some metrics, but not others. Please clarify. Thanks, Paul _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 6 17:59:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10528 for ; Tue, 6 May 2003 17:59:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46M8BH01965 for avt-archive@odin.ietf.org; Tue, 6 May 2003 18:08:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46M6j801023; Tue, 6 May 2003 18:06:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46M2I800773 for ; Tue, 6 May 2003 18:02:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10364 for ; Tue, 6 May 2003 17:53:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DAP2-0002sQ-00 for avt@ietf.org; Tue, 06 May 2003 17:55:12 -0400 Received: from wireless249.east.isi.edu ([65.123.202.249] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19DAP2-0002sN-00 for avt@ietf.org; Tue, 06 May 2003 17:55:12 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h46Lu0Is069792; Tue, 6 May 2003 17:56:00 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: Kreuter Ruediger cc: avt@ietf.org Subject: Re: [AVT] Clearmode In-Reply-To: Your message of "Tue, 06 May 2003 14:42:14 +0200." Date: Tue, 06 May 2003 17:56:00 -0400 Message-ID: <69791.1052258160@purple.nge.isi.edu> From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> Kreuter Ruediger writes: >Hi, > >in my view draft-ietf-avt-rtp-clearmode-00.txt >is in a pretty final state now. >There was only one comment according the MIME >subtype, which could be clarified (to stay with >the proposed name). > >So I would suggest to give it a last call. > >What's your opinion ? Looks reasonable from a technical viewpoint, but needs a pass to address the considerations listed at http://www.ietf.org/ID-nits.html A couple of other points: - The formatting needs to be cleaned up - An "IANA Considerations" section is needed (probably just a reference to the MIME type registration) - References must be split into normative and informative - You should expand "VoIP" in the abstract - The port on the m= line of the example should be even numbered Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 6 18:30:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12478 for ; Tue, 6 May 2003 18:30:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46Mdc904451 for avt-archive@odin.ietf.org; Tue, 6 May 2003 18:39:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46McC804279; Tue, 6 May 2003 18:38:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46MZl803305 for ; Tue, 6 May 2003 18:35:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12326 for ; Tue, 6 May 2003 18:26:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DAvR-00033n-00 for avt@ietf.org; Tue, 06 May 2003 18:28:41 -0400 Received: from wireless249.east.isi.edu ([65.123.202.249] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19DAvP-00033k-00 for avt@ietf.org; Tue, 06 May 2003 18:28:41 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h46MTPIs070328; Tue, 6 May 2003 18:29:25 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: philkerr@elec.gla.ac.uk cc: avt@ietf.org In-Reply-To: Your message of "Thu, 01 May 2003 14:08:02 BST." <1051794482.3eb11c325c7ba@dlana.elec.gla.ac.uk> Date: Tue, 06 May 2003 18:29:25 -0400 Message-ID: <70327.1052260165@purple.nge.isi.edu> From: Colin Perkins Subject: [AVT] Re: Status of draft-kerr-avt-vorbis-rtp-01 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Phil, --> philkerr@elec.gla.ac.uk writes: >I'm checking on the status of draft-kerr-avt-vorbis-rtp-01 and how things can be >moved forward with it. The update was submitted just before the cutoff for the >last AVT meeting and there seems to have been no action on it since. I took the liberty of cc'ing the AVT mailing list, to encourage feedback. >There are a few small changes I may wish to make to the draft, which will be >discussed at a Vorbis meeting tomorrow, but I wanted to check with you first on >if the 01 draft is good enough to move forward. I think it's in good shape, although I have a couple of issues: - Section 2.1 notes that the P, X and CC fields of the RTP header are set to 0. I'm not sure it's appropriate for a payload format to specify this: I can imagine valid scenarios where each of these can be used with Vorbis. - The discussion in section 3 can make use of normative language to be clear on how frames are packetized. I suggest the following changes: Any Vorbis packet that is larger than 256 octets and less than the path-MTU should be placed in a RTP packet by itself. ^^^^^^ MUST Any Vorbis packet that is 256 bytes or less should be bundled in the ^^^^^^ SHOULD RTP packet with as many Vorbis packets as will fit, up to a maximum of 32. If a Vorbis packet will not fit into the RTP packet, it must be within the network MTU ^^^^^^^^^^^^^^^^^^^ ^^^^ SHOULD fragmented. A fragmented packet has a zero in the last five bits of the payload header. Each fragment after the first will also set the Continued (C) bit to one in the payload header. The RTP packet containing the last fragment of the Vorbis packet will have the Marker (F) bit set to one. ^^^^^^ Final Fragment (to avoid confusion with the RTP Marker bit) - The IANA considerations section needs to be expanded. Section 4 of RFC 3047 is a good example, to illustrate the format. - Regarding the configuration headers, is there a need to send updates during a session? If not, it might be appropriate to define some SDP parameters to convey the configuration data at session initiation time, rather than relying on RTCP. If RTCP is to be used, it's necessary to discuss reliability, and how a receiver reacts if the information is lost. I also have a few editorial comments: - The interpretation of key words and reference to RFC 2119 should be moved into the Introduction rather than being in the Status of this Memo section. - I suggest moving the last three paragraphs of the Introduction into section 2.3, where the packing of the payload data is discussed. It may also be appropriate to include a slightly longer description of the Vorbis codec and when it might be useful in the Introduction. - In section 3.1, it might be useful to include the RTP packet header details, to show how the RTP sequence number and timestamp are used (sequence number increases by one for each packet, timestamp stays the same for each fragment). - Section 7 might reference the discussion of congestion control in the RTP spec and/or profile - References should be split into Normative and Informative sections. Cheers, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 7 05:24:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21935 for ; Wed, 7 May 2003 05:24:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h479XOD29844 for avt-archive@odin.ietf.org; Wed, 7 May 2003 05:33:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h479WV829792; Wed, 7 May 2003 05:32:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h479TG829631 for ; Wed, 7 May 2003 05:29:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21862 for ; Wed, 7 May 2003 05:19:52 -0400 (EDT) From: philkerr@elec.gla.ac.uk Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DL7c-0006qs-00 for avt@ietf.org; Wed, 07 May 2003 05:21:56 -0400 Received: from dlana.elec.gla.ac.uk ([130.209.176.2]) by ietf-mx with esmtp (Exim 4.12) id 19DL7b-0006qp-00 for avt@ietf.org; Wed, 07 May 2003 05:21:55 -0400 Received: from nobody by dlana.elec.gla.ac.uk with local (Exim 4.04) id 19DL8R-0000uL-00; Wed, 07 May 2003 10:22:47 +0100 Received: from 81.86.177.17 ( [81.86.177.17]) as user philkerr@dlana.elec.gla.ac.uk by dlana.elec.gla.ac.uk with HTTP; Wed, 7 May 2003 10:22:46 +0100 Message-ID: <1052299366.3eb8d066de013@dlana.elec.gla.ac.uk> Date: Wed, 7 May 2003 10:22:46 +0100 To: Colin Perkins Cc: avt@ietf.org References: <70327.1052260165@purple.nge.isi.edu> In-Reply-To: <70327.1052260165@purple.nge.isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 X-Originating-IP: 81.86.177.17 Content-Transfer-Encoding: 8bit Subject: [AVT] Re: Status of draft-kerr-avt-vorbis-rtp-01 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi Colin, Many thanks for the feedback. I'll update the draft with your change suggestions together with any further comments that come in. Cheers Phil Quoting Colin Perkins : > Hi Phil, > > --> philkerr@elec.gla.ac.uk writes: > >I'm checking on the status of draft-kerr-avt-vorbis-rtp-01 and how things > can be > >moved forward with it. The update was submitted just before the cutoff for > the > >last AVT meeting and there seems to have been no action on it since. > > I took the liberty of cc'ing the AVT mailing list, to encourage feedback. > > >There are a few small changes I may wish to make to the draft, which will > be > >discussed at a Vorbis meeting tomorrow, but I wanted to check with you first > on > >if the 01 draft is good enough to move forward. > > I think it's in good shape, although I have a couple of issues: > > - Section 2.1 notes that the P, X and CC fields of the RTP header are set > to 0. I'm not sure it's appropriate for a payload format to specify this: > > I can imagine valid scenarios where each of these can be used with > Vorbis. > > - The discussion in section 3 can make use of normative language to be > clear on how frames are packetized. I suggest the following changes: > > Any Vorbis packet that is larger than 256 octets and less than the > path-MTU should be placed in a RTP packet by itself. > ^^^^^^ MUST > > Any Vorbis packet that is 256 bytes or less should be bundled in the > ^^^^^^ SHOULD > RTP packet with as many Vorbis packets as will fit, up to a maximum > of 32. > > If a Vorbis packet will not fit into the RTP packet, it must be > within the network MTU ^^^^^^^^^^^^^^^^^^^ ^^^^ SHOULD > fragmented. A fragmented packet has a zero in the last five bits > of the payload header. Each fragment after the first will also set > the Continued (C) bit to one in the payload header. The RTP packet > containing the last fragment of the Vorbis packet will have the > Marker (F) bit set to one. > ^^^^^^ Final Fragment > (to avoid confusion with the RTP Marker bit) > > - The IANA considerations section needs to be expanded. Section 4 of RFC > 3047 is a good example, to illustrate the format. > > - Regarding the configuration headers, is there a need to send updates > during a session? If not, it might be appropriate to define some SDP > parameters to convey the configuration data at session initiation time, > rather than relying on RTCP. If RTCP is to be used, it's necessary to > discuss reliability, and how a receiver reacts if the information is > lost. > > I also have a few editorial comments: > > - The interpretation of key words and reference to RFC 2119 should be > moved into the Introduction rather than being in the Status of this > Memo section. > > - I suggest moving the last three paragraphs of the Introduction into > section 2.3, where the packing of the payload data is discussed. It > may also be appropriate to include a slightly longer description of > the Vorbis codec and when it might be useful in the Introduction. > > - In section 3.1, it might be useful to include the RTP packet header > details, to show how the RTP sequence number and timestamp are used > (sequence number increases by one for each packet, timestamp stays > the same for each fragment). > > - Section 7 might reference the discussion of congestion control in > the RTP spec and/or profile > > - References should be split into Normative and Informative sections. > > > Cheers, > Colin > ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 7 11:04:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05022 for ; Wed, 7 May 2003 11:04:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h47FDd224906 for avt-archive@odin.ietf.org; Wed, 7 May 2003 11:13:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47F5w823665; Wed, 7 May 2003 11:05:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47Ex2823303 for ; Wed, 7 May 2003 10:59:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04650 for ; Wed, 7 May 2003 10:49:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DQGd-00024U-00 for avt@ietf.org; Wed, 07 May 2003 10:51:35 -0400 Received: from isis.lip6.fr ([132.227.60.2] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19DQGc-00024L-00 for avt@ietf.org; Wed, 07 May 2003 10:51:34 -0400 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.9/jtpda-5.4+victor) with ESMTP id h47EqKJW010144 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Wed, 7 May 2003 16:52:20 +0200 X-pt: isis.lip6.fr Received: from doris (doris [132.227.72.166]) by tibre.lip6.fr (8.11.6p2/8.11.6) with ESMTP id h47EqF520469; Wed, 7 May 2003 16:52:15 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Timur Friedman To: "Paul E. Jones" , Subject: Re: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05 Date: Wed, 7 May 2003 16:52:13 +0200 User-Agent: KMail/1.4.3 References: <006601c313f4$d6688d70$0401a8c0@berlin> In-Reply-To: <006601c313f4$d6688d70$0401a8c0@berlin> Cc: , , MIME-Version: 1.0 Message-Id: <200305071652.13470.timur.friedman@lip6.fr> X-Scanned-By: isis.lip6.fr Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h47Ex2823305 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Tuesday 06 May 2003 07:27 pm, Paul E. Jones wrote: > > As I was looking at this document, it appears that the extended reporting > fields are all "mandatory". That is, it does not appear possible, for > example, to signal "round trip delay" without also signaling "burst > duration". Am I reading this correctly? Would it not be reasonable to > consider that some devices may or may not have the capability to advertise > some metrics, but not others. > > Please clarify. The RTCP XR draft specifies a number of report blocks: Loss RLE Report Block Duplicate RLE Report Block Packet Receipt Times Report Block Receiver Reference Time Report Block DLRR Report Block Statistics Summary Report Block VoIP Metrics Report Block None of these blocks are mandatory. However, an application can perfectly well require the use of some of these blocks. The SDP signaling mechanism described in the draft allows an application to signal that certain blocks should be used. Other signaling mechanisms or norms not described in the draft could do the same. Some blocks necessarily come in pairs. For instance, the DLRR Report Block only makes sense in response to a Receiver Reference Time Report Block. In the SDP signaling section, this is referred to as "collaborative functionality", and the use of the two blocks is signaled collectively. Other blocks have "unilateral functionality", and and their use is signaled individually. Within a block, there might be mechanisms for reporting on certain fields and not on others. For instance, in the Statistics Summary Report Blocks, there are flags that indicate which fields are populated with values and which are not. No signaling has been specified at this level, though the existing signaling mechanism could conceivably be extended to cover the choice of fields. For the VoIP Metrics Report Block, on the other hand, all fields must be reported upon. This is from the introduction to Section 4.7: "Implementations MUST provide values for all the fields defined here. For certain metrics, if the value is undefined or unknown, then the specified default or unknown field value MUST be provided." VoIP equipment cannot pick and choose and remain compliant with this draft. If partial implementations were allowed, the utility of this report block would be significantly diminished. As I understand, from those much better versed in the field (notably the authors of this VoIP Metrics Report Block section), the set of parameters defined for the block is fairly standard and readily-implementable. It would be surprising if equipment could not be designed to report upon all of these values. A provision is made, nonetheless, for indicating that certain values are not yet available at the time of reporting. - Timur Friedman _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 7 21:21:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26363 for ; Wed, 7 May 2003 21:21:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h481V3112690 for avt-archive@odin.ietf.org; Wed, 7 May 2003 21:31:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h481Tx812608; Wed, 7 May 2003 21:29:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h481Po812435 for ; Wed, 7 May 2003 21:25:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26288 for ; Wed, 7 May 2003 21:16:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Da30-0006lJ-00 for avt@ietf.org; Wed, 07 May 2003 21:18:10 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Da2z-0006lG-00 for avt@ietf.org; Wed, 07 May 2003 21:18:09 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19Da3q-0005CV-00; Thu, 08 May 2003 01:19:02 +0000 To: avt@ietf.org Cc: mbaugher@cisco.com, casner@acm.org, csp@csperkins.org, jon.peterson@neustar.biz, mankin@psg.com In-Reply-To: Message from Mark Baugher of "Fri, 02 May 2003 09:52:43 PDT." <5.1.1.5.2.20030502094532.0b8acdc0@agora.rdrop.com> Date: Wed, 07 May 2003 18:19:00 -0700 From: Allison Mankin Message-Id: Subject: [AVT] Re: I-D ACTION:draft-ietf-avt-srtp-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Folks, I plan to Last Call SRTP, having done a long security and AD review on version 05, resulting in a number of the changes that Mark describes. So far I have seen no list discussion of his mail, but if working group issues do come up, I suggest we take them in parallel with the IETF Last Call, and if extra time is needed, that is ok. Allison _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 7 23:39:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28754 for ; Wed, 7 May 2003 23:39:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h483mVn22176 for avt-archive@odin.ietf.org; Wed, 7 May 2003 23:48:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h483ga821901; Wed, 7 May 2003 23:42:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h483da821789 for ; Wed, 7 May 2003 23:39:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28569 for ; Wed, 7 May 2003 23:29:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Dc8Q-0007LL-00 for avt@ietf.org; Wed, 07 May 2003 23:31:54 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19Dc8P-0007L6-00 for avt@ietf.org; Wed, 07 May 2003 23:31:53 -0400 Received: from alansnotebook [66.156.9.93] by telchemy.com with ESMTP (SMTPD32-7.14) id A0182500294; Wed, 07 May 2003 23:33:44 -0400 From: "Alan Clark" To: "Colin Perkins" , , "Timur Friedman" Date: Wed, 7 May 2003 23:35:16 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <39737.1052084232@purple.nge.isi.edu> Content-Transfer-Encoding: 7bit Subject: [AVT] RE: RTCP XR comments Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin Section 4.7.3 With regard to your comment concerning end systems that are receive-only or streaming, I'd like to keep the delay related metrics mandatory for conversational applications as delay is a significant impairment factor. I suggest that we change "This value MUST be provided in all VoIP metrics reports" to "This value MUST be provided in all VoIP metrics reports that relate to two-party real-time interactive or conversational RTP sessions and MAY be provided for multi-party conference or streaming applications." Section 4.7.4 Residual Echo Return Loss On draft 05 page 32 I suggest adding the following after the paragraph "The ERL and ERLE parameters are often..........................................network attached to the endpoint. The Residual Echo Return Loss value may be measured directly by the VoIP end system's Echo Canceller or may be estimated by adding the Echo Return Loss and Echo Return Loss Enhancement (ERLE) values reported by the Echo Canceller. RERL(dB) = ERL (dB) + ERLE (dB) In the case of a VoIP gateway the source of echo is typically line echo that occurs at 2-4 wire conversion points in the network. Echo Return Loss from typical 2-4 wire conversion points........(existing paragraph) Section 4.7.5 Suggest changing PLC description to "When PLC = 11 then a simple replay or interpolation algorithm is being used to fill-in the missing packet; this approach is typically able to conceal isolated lost packets at low packet loss rates. When PLC = 10 then an enhanced interpolation algorithm is being used; algorithms of this type are able to conceal high packet loss rates effectively. When PLC = 01 then silence is being inserted in place of lost packets. When PLC = 00 then no information is available concerning the use of PLC however for some codecs this may be inferred." Appendix A.2 The software example in Appendix A.2 has been verified against a working implementation for correctness. The ETSI document provided an algorithm description. Appendix A.2 should take precedence. Regards Alan Clark Telchemy _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 8 13:35:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01039 for ; Thu, 8 May 2003 13:35:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h48HifN01785 for avt-archive@odin.ietf.org; Thu, 8 May 2003 13:44:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48HZ0800379; Thu, 8 May 2003 13:35:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48HVn832728 for ; Thu, 8 May 2003 13:31:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00721; Thu, 8 May 2003 13:21:45 -0400 (EDT) Message-Id: <200305081721.NAA00721@ietf.org> To: IETF-Announce: ; Cc: avt@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Thu, 08 May 2003 13:21:45 -0400 Subject: [AVT] Last Call: The Secure Real-time Transport Protocol to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Audio/Video Transport Working Group to consider The Secure Real-time Transport Protocol as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-22. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-06.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 8 21:36:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18992 for ; Thu, 8 May 2003 21:36:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h491kdI07285 for avt-archive@odin.ietf.org; Thu, 8 May 2003 21:46:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h491k7807269; Thu, 8 May 2003 21:46:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47BPo805164 for ; Wed, 7 May 2003 07:25:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23836 for ; Wed, 7 May 2003 07:16:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DMwO-0007JA-00 for avt@ietf.org; Wed, 07 May 2003 07:18:28 -0400 Received: from web10501.mail.yahoo.com ([216.136.130.151]) by ietf-mx with smtp (Exim 4.12) id 19DMwO-0007J7-00 for avt@ietf.org; Wed, 07 May 2003 07:18:28 -0400 Message-ID: <20030507111920.55594.qmail@web10501.mail.yahoo.com> Received: from [12.91.162.187] by web10501.mail.yahoo.com via HTTP; Wed, 07 May 2003 04:19:20 PDT Date: Wed, 7 May 2003 04:19:20 -0700 (PDT) From: Rekha P To: avt@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [AVT] Video Combining Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , All, Does any one know the Annex C H.263 equivalent in H.264. Thanks, Rekha. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 8 21:39:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19025 for ; Thu, 8 May 2003 21:39:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h491mja07369 for avt-archive@odin.ietf.org; Thu, 8 May 2003 21:48:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h491mP807352; Thu, 8 May 2003 21:48:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h47DT2815546 for ; Wed, 7 May 2003 09:29:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29521 for ; Wed, 7 May 2003 09:19:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DOrZ-000194-00 for avt@ietf.org; Wed, 07 May 2003 09:21:37 -0400 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19DOrY-00018u-00 for avt@ietf.org; Wed, 07 May 2003 09:21:36 -0400 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h47DJ0Zs020823; Wed, 7 May 2003 09:19:00 -0400 Received: from research.att.com (wold1037.research.att.com [135.207.49.37]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h47DLwV26010; Wed, 7 May 2003 09:21:58 -0400 (EDT) Message-ID: <3EB908B1.EC8E4AB1@research.att.com> Date: Wed, 07 May 2003 09:22:58 -0400 From: Tim Griffin Organization: AT&T Labs Research X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: avt@ietf.org, rmt@lbl.gov, mboned@network-services.uoregon.edu, rm@openmash.org References: <3E9D6B64.8D902E4E@research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: CFP: 11th IEEE International Conference on Network Protocols (ICNP'03) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit REMINDER: paper registration is just a few days away. Tim Griffin wrote: > > CALL FOR PAPERS > > 11th IEEE International Conference on Network Protocols (ICNP'03) > > Atlanta, Georgia > November 4-7, 2003 > > http://icnp03.cc.gatech.edu > > ICNP is a highly selective conference dealing with all aspects of > communication protocols including design, specification, analysis, > verification, implementation, and performance. The program consists > of a full day of tutorials followed by a single three-day track of > peer-reviewed papers, including a limited number of invited talks and > panels. The web page will contain up-to-date information on the > conference program and tutorials. > > High-quality papers dealing with any aspect of network protocols are > solicited for submission to the conference. Topics of particular > interest include, but are not limited to: > > protocol testing and analysis protocol design and implementation > network measurement and monitoring ad-hoc and sensor networks > peer-to-peer/overlay protocols routing protocols > wireless and mobile networks security > multimedia distributed gaming > QoS signaling > flow and congestion control active/programmable networks > > IMPORTANT DATES: > > Register title, abstract and author affiliations: May 9, 2003 > Paper submission (hard deadline): May 16, 2003 > Acceptance: July 25, 2003 > Camera ready: August 25, 2003 > > GENERAL CO-CHAIRS: > > Kevin Almeroth, UC Santa Barbara > Ken Calvert, U. of Kentucky > > PROGRAM CO-CHAIRS: > > Jorg Liebeherr, U. of Virginia > Ellen Zegura, Georgia Tech > > PROGRAM COMMITTEE: > > Kevin Almeroth, UC Santa Barbara > Mostafa Ammar, Georgia Tech > Paul Barford, U. of Wisconsin > Bobby Bhattacharjee, U. of Maryland > Ernst Biersack, Eurecom > John Byers, Boston University > Andrew Campbell, Columbia University > Reuven Cohen, Technion > John Crowcroft, U. of Cambridge > Constantinos Dovrolis, Georgia Tech > Wolfgang Effelsberg, U. of Mannheim > Magda El Zarki, UC Irvine > Michalis Faloutsos, UC Riverside > Serge Fdida, U. of Pierre and Marie Curie > Lixin Gao, U. of Massachusetts > Timothy G. Griffin, AT&T Research > Katie Guo, Bell Labs > Teruo Higashino, Osaka University > Sugih Jamin, U. of Michigan > Ed Knightly, Rice University > Jim Kurose, U. of Massachusetts > Tom Laporta, Penn State University > Brian Levine, U. of Massachusetts > Steven Low, CalTech > Ibrahim Matta, Boston University > Sue Moon, Sprint ATL > Klara Nahrstedt, U. of Illinois > Venkat Padmanabhan, Microsoft Research > Kihong Park, Purdue University > Sanjoy Paul, Bell Labs > Jennifer Rexford, AT&T Research > Dan Rubenstein, Columbia University > Srini Seshan, CMU > R. Srikant, U. of Illinois > Rolf Stadler, Royal Institute of Technology > Ioannis Stavrakakis, University of Athens > Peter Steenkiste, CMU > Joe Touch, ISI > Don Towsley, U. of Massachusetts > Hassan Ural, U. of Ottawa > Jim Xu, Georgia Tech > David Yau, Purdue University _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 8 21:41:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19112 for ; Thu, 8 May 2003 21:41:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h491ooJ07478 for avt-archive@odin.ietf.org; Thu, 8 May 2003 21:50:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h491oY807463; Thu, 8 May 2003 21:50:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h48Jst812166 for ; Thu, 8 May 2003 15:54:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06593 for ; Thu, 8 May 2003 15:44:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DrLv-0005RB-00 for avt@ietf.org; Thu, 08 May 2003 15:46:51 -0400 Received: from nn1.excitenetwork.com ([207.159.120.55] helo=xmxpita.myway.com) by ietf-mx with esmtp (Exim 4.12) id 19DrLv-0005Qa-00 for avt@ietf.org; Thu, 08 May 2003 15:46:51 -0400 Received: by xmxpita.myway.com (Postfix, from userid 110) id 168EA39F1; Thu, 8 May 2003 15:47:13 -0400 (EDT) To: avt@ietf.org Received: from [129.46.235.83] by mprdmailfe3.nwk.myway.com via HTTP; Thu, 08 May 2003 15:47:13 EST X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = ee3fe312cac0fba266e5dbcbe1b4e922 Reply-To: mvaidya@myway.com From: "M Vaidya" MIME-Version: 1.0 X-Sender: mvaidya@myway.com X-Mailer: PHP Content-Type: multipart/alternative; boundary="MYWAYBOUNDARY_000__a6ed4b2568b36bbe9aadf295f887ec90"; Content-Transfer-Encoding: 7bit Message-Id: <20030508194713.168EA39F1@xmxpita.myway.com> Date: Thu, 8 May 2003 15:47:13 -0400 (EDT) Subject: [AVT] CRTP implementation Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --MYWAYBOUNDARY_000__a6ed4b2568b36bbe9aadf295f887ec90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Is there any free/shareware implementation of CRTP that is available..? ThanksMVaidya _______________________________________________ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com --MYWAYBOUNDARY_000__a6ed4b2568b36bbe9aadf295f887ec90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
Is there any free/shareware implementation of CRTP that is available..?

Thanks
MVaidya

No banners. No pop-ups. No kidding.
Introducing My Way - http://www.myway.com --MYWAYBOUNDARY_000__a6ed4b2568b36bbe9aadf295f887ec90-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 8 23:10:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20976 for ; Thu, 8 May 2003 23:10:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h493K3R13381 for avt-archive@odin.ietf.org; Thu, 8 May 2003 23:20:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h493Jb813311; Thu, 8 May 2003 23:19:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h493G8813227 for ; Thu, 8 May 2003 23:16:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20920 for ; Thu, 8 May 2003 23:05:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19DyEl-0000mQ-00 for avt@ietf.org; Thu, 08 May 2003 23:07:55 -0400 Received: from mail.cs.tu-berlin.de ([130.149.17.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19DyEl-0000mN-00 for avt@ietf.org; Thu, 08 May 2003 23:07:55 -0400 Received: from hobel.cs.tu-berlin.de (stewe@basta.cs.tu-berlin.de [130.149.17.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id FAA22442; Fri, 9 May 2003 05:04:49 +0200 (MET DST) Message-Id: <5.2.0.9.2.20030509045930.020cef58@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 09 May 2003 05:03:52 +0200 To: Rekha P From: Stephan Wenger Subject: Re: [AVT] Video Combining Cc: avt@ietf.org In-Reply-To: <20030507111920.55594.qmail@web10501.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 04:19 AM 5/7/2003 -0700, Rekha P wrote: > Does any one know the Annex C H.263 equivalent in H.264. If you are referring to H.263 Annex C (multipoint considerations) -- there are currently two draft ITU-T Recommendations under consideration in SG16 that implement stuff such as fast update request, freeze request and freeze release (the stuff used for video switching MCUs). I'm unaware that anyone is considering an equivalent to the CPM bit. In the IETF, there is also work that could be used to implement a similar functionality, see draft-ietf-avt-rtcp-feedback-06.txt. Stephan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 9 11:33:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20422 for ; Fri, 9 May 2003 11:33:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49FhV918175 for avt-archive@odin.ietf.org; Fri, 9 May 2003 11:43:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Fgr818087; Fri, 9 May 2003 11:42:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Fd7817817 for ; Fri, 9 May 2003 11:39:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20275 for ; Fri, 9 May 2003 11:28:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E9pW-0005CX-00 for avt@ietf.org; Fri, 09 May 2003 11:30:38 -0400 Received: from ras01.isi.edu ([128.9.176.101] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19E9pU-0005CT-00 for avt@ietf.org; Fri, 09 May 2003 11:30:37 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h49FUh93061209; Fri, 9 May 2003 11:30:44 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: "Alan Clark" cc: avt@ietf.org, "Timur Friedman" Subject: Re: [AVT] RE: RTCP XR comments In-Reply-To: Your message of "Wed, 07 May 2003 23:35:16 EDT." Date: Fri, 09 May 2003 11:30:43 -0400 Message-ID: <61208.1052494243@purple.nge.isi.edu> From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Alan, --> "Alan Clark" writes: > >Section 4.7.3 > >With regard to your comment concerning end systems that are receive-only or >streaming, I'd like to keep the delay related metrics mandatory for >conversational applications as delay is a significant impairment factor. >I suggest that we change "This value MUST be provided in all VoIP metrics >reports" to "This value MUST be provided in all VoIP metrics reports that >relate to two-party real-time interactive or conversational RTP sessions and >MAY be provided for multi-party conference or streaming applications." How about: "This value SHOULD be provided in all VoIP metrics reports. If an implementation is unable to provide the data, the value 0 MUST be used." >Section 4.7.4 Residual Echo Return Loss > >On draft 05 page 32 I suggest adding the following after the paragraph "The >ERL and ERLE parameters are >often..........................................network attached to the >endpoint. > >The Residual Echo Return Loss value may be measured directly by the VoIP end >system's Echo Canceller or may be estimated by adding the Echo Return Loss >and Echo Return Loss Enhancement (ERLE) values reported by the Echo >Canceller. > > RERL(dB) = ERL (dB) + ERLE (dB) > >In the case of a VoIP gateway the source of echo is typically line echo that >occurs at 2-4 wire conversion points in the network. Echo Return Loss from >typical 2-4 wire conversion points........(existing paragraph) This is a good addition, but my concern was about the typical values discussion which seems to imply particular implementation strategies. I suggest deleting everything from the paragraph that begins "In the case of a VoIP gateway..." to the Gmin discussion? Or, at least, re- writing it in a manner independent of particular implementations. >Section 4.7.5 > >Suggest changing PLC description to > >"When PLC = 11 then a simple replay or interpolation algorithm is being used >to fill-in the missing packet; this approach is typically able to conceal >isolated lost packets at low packet loss rates. When PLC = 10 then an >enhanced interpolation algorithm is being used; algorithms of this type are >able to conceal high packet loss rates effectively. When PLC = 01 then >silence is being inserted in place of lost packets. When PLC = 00 then no >information is available concerning the use of PLC however for some codecs >this may be inferred." Much better, thanks. >Appendix A.2 >The software example in Appendix A.2 has been verified against a working >implementation for correctness. The ETSI document provided an algorithm >description. Appendix A.2 should take precedence. Okay. Thanks, Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 9 12:35:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22184 for ; Fri, 9 May 2003 12:35:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49GjCp23706 for avt-archive@odin.ietf.org; Fri, 9 May 2003 12:45:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Ggx823553; Fri, 9 May 2003 12:42:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49E86809748 for ; Fri, 9 May 2003 10:08:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15959; Fri, 9 May 2003 09:57:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19E8PT-0004UR-00; Fri, 09 May 2003 09:59:39 -0400 Received: from orion.lrg.ufsc.br ([150.162.63.1] helo=lrg.ufsc.br) by ietf-mx with esmtp (Exim 4.12) id 19E8PP-0004U8-00; Fri, 09 May 2003 09:59:35 -0400 Received: from localhost (westphal@localhost) by (8.9.3+Sun/8.9.3) with ESMTP id KAA10883 Date: Fri, 9 May 2003 10:55:56 -0400 (WST) From: Carlos Becker Westphall To: Carlos Becker Westphall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by www1.ietf.org id h49E86809751 Subject: [AVT] LANOMS'03 - Extended Deadline for submissions - June 6th (fwd) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit LANOMS'03 - Extended Deadline for submissions - June 6th ### #### # ## # # #### # # #### # # # # # # ## # # # ## ## # # # # # # # # # # # # # ## # #### # # ### # ###### # # # # # # # # # # # # # # # ## # # # # # # # # # ###### # # # # #### # # #### ### #### LANOMS 2003 ----------- 3rd Latin American Network Operations and Management Symposium Iguassu Falls, Brazil September 4-6, 2003 IEEE ComSoc CNOM Technically Co-sponsored http://www.inf.ufpr.br/lanoms lanoms@inf.ufpr.br Call for Papers --------------- The Third Latin American Network Operations and Management Symposium - LANOMS, to be held in Iguassu Falls (Foz do Iguaçu), Brazil, is the result of the great success of both LANOMS'1999 which was held in Rio de Janeiro and LANOMS'2001 which was held in Belo Horizonte, as well as the other events in the area of network management known as NOMS and APNOMS. NOMS (Network Operations and Management Symposium) was originally created 13 years ago, and nowadays constitutes a worldwide event for the researches in the area of network management. The Asia/Pacific community promoted the APNOMS (Asia-Pacific Network Operations and Management Symposium), which is an event more oriented to the research and development community in that region. Continuing the success of the second LANOMS, we will promote the third edition of LANOMS (http://www.inf.ufpr.br/lanoms) on September 4-6 2003, in Iguassu Falls, Paraná, Brazil. The symposium is a promotion of the Federal University of Paraná (UFPR), Brazil, technically co-sponsored by IEEE Communications Society, and supported by IEEE Technical Committee on Network Operations and Management (CNOM). The main goal of the LANOMS is to create a forum more specific to the necessities of Latin America in the area of network management involving networking and telecommunication companies, academic institutions and equipment vendors. LANOMS is an event open to participants from all over the world who are interest in having, or already have, research or commercial liaisons in Latin America - one of the fastest growing regions in the world in networking. This year, we intend to increase the submissions from North America, Europe, Africa and Asia. Topics of interest include, but are not limited to: - Integrating Intrusion Detection and Network Management - Intrusion Policy Management - Web Services Security - Business and Service Management - Management Platforms, Interoperability, Standards and Protocols - Management of Networks and Services: VPNs, Optical Networks, CATV Networks, Mobile/Wireless and Ad-Hoc Networks, Voice over IP, Transaction-Oriented Services, Electronic Commerce, Active and Programmable Networks, Sensor Networks - Management Technologies and Frameworks (Web, XML, CORBA, DEN, etc) - Management Aspects of Service Pricing, Accounting and Billing - Management of Service Level Agreements and Quality of Service - Bandwidth Brokerage - Data Warehousing and Data Mining in Management - Programmable, Mobile and Intelligent Agents in Management - Network and Systems Monitoring - Fault and Performance Management - Security Management - Configuration Management and Policy-Driven Management - Information Modeling - Traffic and Performance Management - Open-Source Management Software - Management of Grid Computing, Clusters, Peer-to-Peer Applications, and Ubiquitous Computing Environments - Operations Support Systems - Business Processes for Network and Service Management - Peer-to-peer Network Technologies for Management - Management of Distributed Systems - Case Studies and Experiences in Management Authors are invited to submit unpublished papers, which are not under review for publication elsewhere. Papers are to be submitted in English. Submissions should be complete, full-length papers and should not exceed 12 pages. Electronic submission of papers is mandatory. Full instructions for the electronic submissions will be available soon on the LANOMS Web page. Authors are requested to submit papers in PDF (preferred) or PostScript format via web. The manuscript should include an abstract and three key-words. The format is size A4 (preferred) or Letter, single column, font size 12. All papers will be carefully reviewed by at least three international experts and returned to the author(s) with comments to ensure high quality. Important Dates: ---------------- Deadline for receipt of papers: June 06, 2003 Notification of acceptance: June 30, 2003 Final camera ready paper due: July 15, 2003 LANOMS 2003 Committee --------------------- General Chair: Elias Procópio Duarte Jr., Brazil elias@inf.ufpr.br TPC Chair: Edmundo Roberto Mauro Madeira, Brazil edmundo@ic.unicamp.br Tutorial Chair: José Marcos Silva Nogueira, Brazil jmarcos@dcc.ufmg.br Publicity Chair: Carlos Becker Westphall, Brazil westphal@lrg.ufsc.br International Liaisons: Asia: Masayoshi Ejiri ejiri@jp.fujitsu.com Australia: Abbas Jamalipour abbas@ee.usyd.edu.au Europe: Rolf Stadler stadler@ctr.columbia.edu North America: Mehmet Ulema mehmet.ulema@manhattan.edu Africa: Abderrahim Sekkaki sekkaki@hotmail.com Peru: Carlos Silva csilva@pucp.edu.pe Colombia: Aldo Forero aforero@col1.telecom.com.co Colombia: Omar Rodriguez Ramirez omar-r@andinet.com Chile: Ivan Ramirez Ayala iraft@123mail.cl Costa Rica: Francisco Murrillo fmurillos@ice.go.cr Technical Program Committee: Ahmed Karmouch - Univ. of Ottawa, Canada Antonio Alfredo F. Loureiro - Federal Univ. of Minas Gerais, Brazil Bruno R. Schulze - LNCC, Brazil Carlos Becker Westphall - Federal Univ. of Santa Catarina, Brazil Carlos de Castro Goulart - Federal Univ. of Viçosa, Brazil Elias P. Duarte Jr. (General Chair) - Federal Univ. of Paraná, Brazil Edmundo Monteiro - Univ. of Coimbra, Portugal Edmundo R. M. Madeira (TPC Chair) - State Univ. of Campinas, Brazil Edward L. Pinnes - Telcordia, USA Elizabeth Specialski - Federal Univ. of Santa Catarina, Brazil Fernando Boavida - Univ. of Coimbra, Portugal Germán Goldszmidt - IBM, USA Iara Machado - RNP, Brazil James Won-Ki Hong - Postech, Korea Javier Diaz - Univ. of La Plata, Argentina José Marcos Silva Nogueira - Federal Univ. of Minas Gerais, Brazil José Neuman de Souza - Federal Univ. of Ceará, Brazil Liane Tarouco - Federal Univ. of Rio Grande do Sul, Brazil Lisandro Z. Granville - Federal Univ. of Rio Grande do Sul, Brazil Luciano P. Gaspary - Univ. of Vale do Rio dos Sinos, Brazil Lundy Lewis - Aprisma Management Technologies, USA Masayoshi Ejiri - Fujitsu, Japan Mehmet Ulema, Manhattan College, USA Nazim Agoulmine - Univ. of Evry - France Nelson L.S. Fonseca - State Univ. of Campinas, Brazil Otto C.M.B. Duarte - Federal Univ. of Rio de Janeiro, Brazil Raouf Boutaba - Univ. of Waterloo, Canada Thomas Magedanz - IKV++ Technologies AG, TU Berlin, Germany _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 9 17:04:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02274 for ; Fri, 9 May 2003 17:04:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49LEaF14674 for avt-archive@odin.ietf.org; Fri, 9 May 2003 17:14:36 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49LDv814639; Fri, 9 May 2003 17:14:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49L6V813321 for ; Fri, 9 May 2003 17:06:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01952 for ; Fri, 9 May 2003 16:55:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EEwF-0007RB-00 for avt@ietf.org; Fri, 09 May 2003 16:57:55 -0400 Received: from wireless249.east.isi.edu ([65.123.202.249] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19EEwD-0007R8-00 for avt@ietf.org; Fri, 09 May 2003 16:57:53 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h49Kwo93066263; Fri, 9 May 2003 16:58:50 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Fri, 9 May 2003 16:58:50 -0400 From: Colin Perkins To: Aaron Colwell Cc: avt@ietf.org Subject: Re: [AVT] RTP collision resolution Message-Id: <20030509165850.49f46424.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.8.3 (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, --> Aaron Colwell writes: > > I've been reading through the RFC 1889 and draft-ietf-avt-rtp-new-12.txt > and I still can't quite figure out a few things about the SSRC collision > resolution algorithm. > > I will first start with the simple case where there is one sender in the > RTP session. In this case there is only one sending SSRC and the "send a > BYE for the old SSRC and pick a new SSRC" is pretty clear and easy for > the client to figure out what is happening. Does the sender keep the same > sequence number and timestamp offset across this switch? My current > assumption is that it does, but I could not find that explicitly stated > anywhere. Is that assumption correct? I hope so since it might cause all > sorts of problems for certain payload types like interleaved AMR. I'd expect a sender to pick new random offsets for the sequence number and timestamp when a collision occurs, as if it had just joined the session. A collision should be a very rare event, so I'm not worried that this might cause a glitch in the playout. > The second case that I am confused about is when there are more than one > sender in an RTP session. For this example I'll use the case where we are > doing SSRC multiplexing of a stream and a retransmission stream. In this > case both SSRCs are associated with the same CNAME. In the highly > unlikely chance that both SSRCs conflict with existing SSRCs in the > session, how will the client resolve the proper transition of both of > these SSRCs to new SSRCs? The only way that I can think of to resolve > this would be to use the payload type. Is that how the resolution should > happen? Yes, I think so. > My third case is similar to my second case. I have seen examples in the > archives where people talk about using SSRC multiplexing for a lecture > type environment where there is a SSRC assigned to a lecturer, and a > SSRC assigned to a question microphone. In this scenario, the two SSRCs > likely have the same payload type so the resolution mechanism from case 2 > would not work. How is the client supposed to resolve the transitions in > this case? Do all of these sources have the same CNAME? If not, then the > resolution can be done based on the CNAME. I was under the impression > that the CNAME would be the same for all the SSRCs in this scenario > though. I'd be tempted to give these separate CNAMEs, since they're really two different sources. > One final question about SSRC multiplexing in general. Is it assumed that > all SSRCs associated with the same CNAME should be mixed together on the > client side? Depends on what payload formats are used. The traditional model was that SSRC multiplexing represented multiple cameras or microphones for a single source, so it made sense to mix audio streams. If payload formats like the retransmision format, SSRC multiplexing is now used for other purposes, so you need to determine what is being multiplexed before you decide what to do with it. This is one of the reasons why there was pushback about the use of SSRC multiplexing with retransmission. Cheers, -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 9 17:07:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02363 for ; Fri, 9 May 2003 17:07:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49LHeF14872 for avt-archive@odin.ietf.org; Fri, 9 May 2003 17:17:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49LH6814762; Fri, 9 May 2003 17:17:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49LBS814438 for ; Fri, 9 May 2003 17:11:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02081 for ; Fri, 9 May 2003 17:00:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EF13-0007Sm-00 for avt@ietf.org; Fri, 09 May 2003 17:02:53 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19EF12-0007Sj-00 for avt@ietf.org; Fri, 09 May 2003 17:02:52 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h49L3gKj030500; Fri, 9 May 2003 17:03:42 -0400 Message-ID: <022501c3166e$79320240$0401a8c0@berlin> From: "Paul E. Jones" To: "Timur Friedman" , Cc: , , References: <006601c313f4$d6688d70$0401a8c0@berlin> <200305071652.13470.timur.friedman@lip6.fr> Subject: Re: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05 Date: Fri, 9 May 2003 17:03:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Timur, Alan, Thanks for your feedback. > For the VoIP Metrics Report Block, on the other hand, all fields must be > reported upon. This is from the introduction to Section 4.7: > "Implementations MUST provide values for all the fields defined here. For > certain metrics, if the value is undefined or unknown, then the specified > default or unknown field value MUST be provided." VoIP equipment cannot pick > and choose and remain compliant with this draft. If partial implementations > were allowed, the utility of this report block would be significantly > diminished. This is the kind of thing that concerns me a bit. I don't think we necessarily want to mandate that every single parameter be signaled. Perhaps it does not have the value or perhaps it does not want to waste cycles producing the value. Would the value of the report be diminished? Possibly, but then again, one could argue that some information is better than no information at all. I think we should have the flexibility of indicating, within every report block, which fields are and are not present. Paul _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 9 17:38:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03332 for ; Fri, 9 May 2003 17:38:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49LmSJ17375 for avt-archive@odin.ietf.org; Fri, 9 May 2003 17:48:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49LlR817301; Fri, 9 May 2003 17:47:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49LiS817167 for ; Fri, 9 May 2003 17:44:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03150 for ; Fri, 9 May 2003 17:33:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EFWy-0007iF-00 for avt@ietf.org; Fri, 09 May 2003 17:35:52 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19EFWx-0007hu-00 for avt@ietf.org; Fri, 09 May 2003 17:35:51 -0400 Received: from alansnotebook [216.200.102.183] by telchemy.com with ESMTP (SMTPD32-7.14) id AFAA11D027C; Fri, 09 May 2003 17:37:46 -0400 From: "Alan Clark" To: "Paul E. Jones" , "Timur Friedman" , Cc: , Subject: RE: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05 Date: Fri, 9 May 2003 17:39:18 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <022501c3166e$79320240$0401a8c0@berlin> Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul The current format can also encourage implementers to try and populate as many fields as possible. If we make everything optional then it would be possible to comply with RTCP XR but send no information. At the end of the day we should be trying to encourage product developers to move towards a common useful set of management performance data - the RTCP XR VoIP metrics payload provides good insight into the operation of a VoIP endpoint and can help considerably in diagnosing typical problems. Regards Alan -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Friday, May 09, 2003 5:04 PM To: Timur Friedman; avt@ietf.org Cc: alan@telchemy.com; almeroth@cs.ucsb.edu; ramon@shieldip.com Subject: Re: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05 Timur, Alan, Thanks for your feedback. > For the VoIP Metrics Report Block, on the other hand, all fields must be > reported upon. This is from the introduction to Section 4.7: > "Implementations MUST provide values for all the fields defined here. For > certain metrics, if the value is undefined or unknown, then the specified > default or unknown field value MUST be provided." VoIP equipment cannot pick > and choose and remain compliant with this draft. If partial implementations > were allowed, the utility of this report block would be significantly > diminished. This is the kind of thing that concerns me a bit. I don't think we necessarily want to mandate that every single parameter be signaled. Perhaps it does not have the value or perhaps it does not want to waste cycles producing the value. Would the value of the report be diminished? Possibly, but then again, one could argue that some information is better than no information at all. I think we should have the flexibility of indicating, within every report block, which fields are and are not present. Paul _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 9 17:40:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03438 for ; Fri, 9 May 2003 17:40:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49Lodc17543 for avt-archive@odin.ietf.org; Fri, 9 May 2003 17:50:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49LoH817510; Fri, 9 May 2003 17:50:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Lj9817248 for ; Fri, 9 May 2003 17:45:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03175 for ; Fri, 9 May 2003 17:34:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EFXc-0007it-00 for avt@ietf.org; Fri, 09 May 2003 17:36:32 -0400 Received: from www.routeexplorer.net ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19EFXc-0007iJ-00 for avt@ietf.org; Fri, 09 May 2003 17:36:32 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h49LahvW076845; Fri, 9 May 2003 14:36:43 -0700 (PDT) (envelope-from casner@acm.org) Date: Fri, 9 May 2003 14:43:30 -0700 (PDT) From: Stephen Casner To: "Paul E. Jones" cc: Timur Friedman , , , , Subject: Re: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05 In-Reply-To: <022501c3166e$79320240$0401a8c0@berlin> Message-ID: <20030509143450.S25814-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Paul, > > For the VoIP Metrics Report Block, on the other hand, all fields must be > > reported upon. This is from the introduction to Section 4.7: > > "Implementations MUST provide values for all the fields defined here. For > > certain metrics, if the value is undefined or unknown, then the specified > > default or unknown field value MUST be provided." VoIP equipment cannot > pick > > and choose and remain compliant with this draft. If partial > implementations > > were allowed, the utility of this report block would be significantly > > diminished. The fact that some fields specify a default or unknown value means that can still be compliant while supplying the default or unknown value for those fields. Therefore, it is not quite true to say that all fields must be reported on. > This is the kind of thing that concerns me a bit. I don't think we > necessarily want to mandate that every single parameter be signaled. > Perhaps it does not have the value or perhaps it does not want to waste > cycles producing the value. Would the value of the report be diminished? > Possibly, but then again, one could argue that some information is better > than no information at all. It may well be the case that the bandwidth cost of sending the VoIP metrics block is not justified if some minimum set of fields is not complete. > I think we should have the flexibility of indicating, within every report > block, which fields are and are not present. One important point about which I think there may be some confusion in this discussion: The layout of fields in the VoIP metrics block is fixed. It is not possible to include some fields and omit others. To allow doing so would require extra overhead for a variable format. What is allowed is to supply a value for some fields that indicates no information is present in that field. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 9 17:42:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03499 for ; Fri, 9 May 2003 17:42:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49Lqxh17721 for avt-archive@odin.ietf.org; Fri, 9 May 2003 17:52:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Lqb817687; Fri, 9 May 2003 17:52:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49Llo817305 for ; Fri, 9 May 2003 17:47:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03271 for ; Fri, 9 May 2003 17:37:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EFaE-0007ks-00 for avt@ietf.org; Fri, 09 May 2003 17:39:14 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19EFaD-0007kT-00 for avt@ietf.org; Fri, 09 May 2003 17:39:13 -0400 Received: from alansnotebook [216.200.102.183] by telchemy.com with ESMTP (SMTPD32-7.14) id A07A104021A; Fri, 09 May 2003 17:41:14 -0400 From: "Alan Clark" To: "Colin Perkins" Cc: , "Timur Friedman" Subject: RE: [AVT] RE: RTCP XR comments Date: Fri, 9 May 2003 17:42:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <61208.1052494243@purple.nge.isi.edu> Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin --> "Alan Clark" writes: > >Section 4.7.3 > >With regard to your comment concerning end systems that are receive-only or >streaming, I'd like to keep the delay related metrics mandatory for >conversational applications as delay is a significant impairment factor. >I suggest that we change "This value MUST be provided in all VoIP metrics >reports" to "This value MUST be provided in all VoIP metrics reports that >relate to two-party real-time interactive or conversational RTP sessions and >MAY be provided for multi-party conference or streaming applications." How about: "This value SHOULD be provided in all VoIP metrics reports. If an implementation is unable to provide the data, the value 0 MUST be used." [Alan] That is acceptable >Section 4.7.4 Residual Echo Return Loss > >On draft 05 page 32 I suggest adding the following after the paragraph "The >ERL and ERLE parameters are >often..........................................network attached to the >endpoint. > >The Residual Echo Return Loss value may be measured directly by the VoIP end >system's Echo Canceller or may be estimated by adding the Echo Return Loss >and Echo Return Loss Enhancement (ERLE) values reported by the Echo >Canceller. > > RERL(dB) = ERL (dB) + ERLE (dB) > >In the case of a VoIP gateway the source of echo is typically line echo that >occurs at 2-4 wire conversion points in the network. Echo Return Loss from >typical 2-4 wire conversion points........(existing paragraph) This is a good addition, but my concern was about the typical values discussion which seems to imply particular implementation strategies. I suggest deleting everything from the paragraph that begins "In the case of a VoIP gateway..." to the Gmin discussion? Or, at least, re- writing it in a manner independent of particular implementations. [Alan] Actually the description is more geared around the defaults and recommendations of typical TIA and ITU standards and is not oriented towards any specific implementations. If this is not apparent or if the text does not add anything then we could delete it as suggested. Regards Alan _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 9 18:00:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04216 for ; Fri, 9 May 2003 18:00:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h49MABZ19584 for avt-archive@odin.ietf.org; Fri, 9 May 2003 18:10:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49M9c819515; Fri, 9 May 2003 18:09:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h49M6I818503 for ; Fri, 9 May 2003 18:06:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04084 for ; Fri, 9 May 2003 17:55:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EFs5-00007u-00 for avt@ietf.org; Fri, 09 May 2003 17:57:41 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19EFs4-00007r-00 for avt@ietf.org; Fri, 09 May 2003 17:57:41 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h49Lw6Z22858 for avt@ietf.org; Fri, 9 May 2003 14:58:06 -0700 Date: Fri, 9 May 2003 14:58:06 -0700 From: John Lazzaro Message-Id: <200305092158.h49Lw6Z22858@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] Network Musical Performance talk at CCRMA ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, This is for SF Bay Area locals -- I've mentioned the Network Musical Performance work going on at Stanford a few times on AVT list over the years, the CCRMA folks are hosting an AES-SF meeting later this month (May 20th, 7:30 PM, at their building on the Stanford campus), that will include performance demos and such. See: http://www.aessf.org/meetings/May03.html for the meeting details, if you've ever wondered "how can people perform music with Internet latencies in the loop", you can go watch musicians play in person and find out for yourself :-). It's free ... ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 9 21:03:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08794 for ; Fri, 9 May 2003 21:03:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4A1DRq31177 for avt-archive@odin.ietf.org; Fri, 9 May 2003 21:13:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4A1Ct831133; Fri, 9 May 2003 21:12:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4A194831042 for ; Fri, 9 May 2003 21:09:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08709 for ; Fri, 9 May 2003 20:58:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EIit-0000wm-00 for avt@ietf.org; Fri, 09 May 2003 21:00:23 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19EIis-0000wj-00 for avt@ietf.org; Fri, 09 May 2003 21:00:22 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h4A11IKj031045; Fri, 9 May 2003 21:01:18 -0400 Message-ID: <030d01c3168f$aa254710$0401a8c0@berlin> From: "Paul E. Jones" To: "Alan Clark" , "Timur Friedman" , Cc: , References: Subject: Re: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05 Date: Fri, 9 May 2003 21:01:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alan, > The current format can also encourage implementers to try and populate as > many fields as possible. If we make everything optional then it would be > possible to comply with RTCP XR but send no information. > > At the end of the day we should be trying to encourage product developers to > move towards a common useful set of management performance data - the RTCP > XR VoIP metrics payload provides good insight into the operation of a VoIP > endpoint and can help considerably in diagnosing typical problems. I think your arguments would be justified when it comes to call control signaling. Certainly, a tightly-defined call signaling protocol improves interoperability and improves products. However, these fields are, by their very nature, are ones that are not absolutely essential to call establishment and not every field is absolutely useful in ensuring quality of service. I would venture to guess that, if these are used, vendors will pick and choose which metrics will be used and which will not... if they have the option. I can certainly say that I'd rather have the option of excluding some value I don't want to compute or maintain stats for. Paul _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 9 21:43:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09374 for ; Fri, 9 May 2003 21:43:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4A1rcx01070 for avt-archive@odin.ietf.org; Fri, 9 May 2003 21:53:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4A1rI801061; Fri, 9 May 2003 21:53:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4A1nt800917 for ; Fri, 9 May 2003 21:49:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09297 for ; Fri, 9 May 2003 21:39:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EJMQ-000175-00 for avt@ietf.org; Fri, 09 May 2003 21:41:14 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19EJMP-000172-00 for avt@ietf.org; Fri, 09 May 2003 21:41:13 -0400 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h4A1g8Kj031110; Fri, 9 May 2003 21:42:08 -0400 Message-ID: <031901c31695$5eb62780$0401a8c0@berlin> From: "Paul E. Jones" To: "Stephen Casner" Cc: "Timur Friedman" , , , , References: <20030509143450.S25814-100000@oak.packetdesign.com> Subject: Re: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05 Date: Fri, 9 May 2003 21:42:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Steve, > The fact that some fields specify a default or unknown value means > that can still be compliant while supplying the default or unknown > value for those fields. Therefore, it is not quite true to say that > all fields must be reported on. OK.. this part I missed. So, for every field in every block, it is possible to insert a "dummy" value that is recognized as a "dummy"? > It may well be the case that the bandwidth cost of sending the VoIP > metrics block is not justified if some minimum set of fields is not > complete. Actually, bandwidth is not my concern, really. I don't see those stats as being bandwidth constrained. > One important point about which I think there may be some confusion in > this discussion: The layout of fields in the VoIP metrics block is > fixed. It is not possible to include some fields and omit others. To > allow doing so would require extra overhead for a variable format. > What is allowed is to supply a value for some fields that indicates no > information is present in that field. I know that they're fixed in position. That's OK. In fact, given the nature and size of each datagram, having these fixed field positions would be good, as processing performance can be improved when both sending and receiving. However, I would like a means of either marking fields as present or not or having a "dummy" value. Statistics Summary, for example, allows one to signal presence of most fields. However, the "J" flag, for example, requires the inclusion of a number of fields, including one that reports a measures the standard deviation. Perhaps I would prefer not to report that value... as it is, I have no option, as far as I can tell. Certainly, for most other fields, I do think they're required to be present. If there is a "dummy" default for each, then that would be fine, but I missed that part. Paul _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 9 22:18:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09810 for ; Fri, 9 May 2003 22:18:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4A2T1903179 for avt-archive@odin.ietf.org; Fri, 9 May 2003 22:29:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4A2Rd803102; Fri, 9 May 2003 22:27:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4A2Od803003 for ; Fri, 9 May 2003 22:24:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09781 for ; Fri, 9 May 2003 22:13:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EJu1-0001FH-00 for avt@ietf.org; Fri, 09 May 2003 22:15:57 -0400 Received: from www.route-explorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19EJu0-0001FE-00 for avt@ietf.org; Fri, 09 May 2003 22:15:56 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h4A2EcvW087835; Fri, 9 May 2003 19:14:38 -0700 (PDT) (envelope-from casner@acm.org) Date: Fri, 9 May 2003 19:21:27 -0700 (PDT) From: Stephen Casner To: "Paul E. Jones" cc: Timur Friedman , , , , Subject: Re: [AVT] Question on draft-ietf-avt-rtcp-report-extns-05 In-Reply-To: <031901c31695$5eb62780$0401a8c0@berlin> Message-ID: <20030509191110.S25985-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , On Fri, 9 May 2003, Paul E. Jones wrote: > > The fact that some fields specify a default or unknown value means > > that can still be compliant while supplying the default or unknown > > value for those fields. Therefore, it is not quite true to say that > > all fields must be reported on. > > OK.. this part I missed. So, for every field in every block, it is possible > to insert a "dummy" value that is recognized as a "dummy"? No, that statement does not hold true for every field in every block. My comments were regarding the VoIP metrics block in particular. Some of the other blocks do use a variable format rather than dummy values. > > One important point about which I think there may be some confusion in > > this discussion: The layout of fields in the VoIP metrics block is > > fixed. It is not possible to include some fields and omit others. To > > allow doing so would require extra overhead for a variable format. > > What is allowed is to supply a value for some fields that indicates no > > information is present in that field. > > I know that they're fixed in position. That's OK. In fact, given the > nature and size of each datagram, having these fixed field positions would > be good, as processing performance can be improved when both sending and > receiving. However, I would like a means of either marking fields as > present or not or having a "dummy" value. So, for the VoIP block, that means does exist for several of the fields. For some of the fields, providing a dummy value may not make sense (because the entire space is used). Extra bits could be allocated to indicate presence, but that may not be justified -- that is, I believe it is perfectly reasonable to say that there is a minimum subset of fields without which it does not make sense to send the block. I guess the selection of that subset is the point of disagreement. > Statistics Summary, for example, allows one to signal presence of most > fields. However, the "J" flag, for example, requires the inclusion of a > number of fields, including one that reports a measures the standard > deviation. Perhaps I would prefer not to report that value... as it is, I > have no option, as far as I can tell. > > Certainly, for most other fields, I do think they're required to be present. > If there is a "dummy" default for each, then that would be fine, but I > missed that part. As I say above, not every block type has dummy values defined. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 12 06:57:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07805 for ; Mon, 12 May 2003 06:57:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CAMtx15299 for avt-archive@odin.ietf.org; Mon, 12 May 2003 06:22:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CAMCB15269; Mon, 12 May 2003 06:22:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CAFBB15023 for ; Mon, 12 May 2003 06:15:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07647 for ; Mon, 12 May 2003 06:49:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FAti-0006k4-00 for avt@ietf.org; Mon, 12 May 2003 06:51:10 -0400 Received: from csperkins.demon.co.uk ([193.237.26.84] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19FAtd-0006jo-00 for avt@ietf.org; Mon, 12 May 2003 06:51:07 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h4CApLU2001393; Mon, 12 May 2003 06:51:31 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: avt@ietf.org, "Timur Friedman" Subject: Re: [AVT] RE: RTCP XR comments In-Reply-To: Your message of "Fri, 09 May 2003 17:42:46 EDT." Date: Mon, 12 May 2003 11:51:21 +0100 Message-ID: <1392.1052736681@purple.nge.isi.edu> From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> "Alan Clark" writes: ... >>Section 4.7.4 Residual Echo Return Loss >> >>On draft 05 page 32 I suggest adding the following after the paragraph "The >>ERL and ERLE parameters are >>often..........................................network attached to the >>endpoint. >> >>The Residual Echo Return Loss value may be measured directly by the VoIP >end >>system's Echo Canceller or may be estimated by adding the Echo Return Loss >>and Echo Return Loss Enhancement (ERLE) values reported by the Echo >>Canceller. >> >> RERL(dB) = ERL (dB) + ERLE (dB) >> >>In the case of a VoIP gateway the source of echo is typically line echo >that >>occurs at 2-4 wire conversion points in the network. Echo Return Loss from >>typical 2-4 wire conversion points........(existing paragraph) > >This is a good addition, but my concern was about the typical values >discussion which seems to imply particular implementation strategies. >I suggest deleting everything from the paragraph that begins "In the >case of a VoIP gateway..." to the Gmin discussion? Or, at least, re- >writing it in a manner independent of particular implementations. > >[Alan] Actually the description is more geared around the defaults and >recommendations of typical TIA and ITU standards and is not oriented towards >any specific implementations. If this is not apparent or if the text does >not add anything then we could delete it as suggested. Right, but the draft uses normative language in this section, based around particular implementation choices. If you can rewrite the text from "For an IP phone with handset this metric MUST..." until the discussion of Gmin, so that it describes examples of how particular systems calculate the metric, without using normative (RFC 2119) language, that would be acceptable. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 12 10:12:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13825 for ; Mon, 12 May 2003 10:12:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CDcKN30532 for avt-archive@odin.ietf.org; Mon, 12 May 2003 09:38:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CDbeB30341; Mon, 12 May 2003 09:37:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4CDYmB29304 for ; Mon, 12 May 2003 09:34:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13308 for ; Mon, 12 May 2003 10:08:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FE0o-0000D7-00 for avt@ietf.org; Mon, 12 May 2003 10:10:42 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19FE0o-0000Ct-00 for avt@ietf.org; Mon, 12 May 2003 10:10:42 -0400 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.14) id AB6554022C; Mon, 12 May 2003 10:10:45 -0400 Reply-To: From: "Alan Clark" To: "'Colin Perkins'" , , "'Timur Friedman'" Subject: RE: [AVT] RE: RTCP XR comments Date: Mon, 12 May 2003 10:04:53 -0400 Message-ID: <006901c3188f$76733ec0$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1392.1052736681@purple.nge.isi.edu> Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Colin Would this revised text be acceptable? Regards Alan The Residual Echo Return Loss value may be measured directly by the VoIP end system's Echo Canceller or may be estimated by adding the Echo Return Loss and Echo Return Loss Enhancement (ERLE) values reported by the Echo Canceller. RERL(dB) = ERL (dB) + ERLE (dB) In the case of a VoIP gateway the source of echo is typically line echo that occurs at 2-4 wire conversion points in the network. This can be in the 8-12 dB range. A line echo canceler can provide an ERLE of 30 dB or more and hence reduce this to 40-50 dB. In the case of an IP phone this could be acoustic coupling between handset speaker and microphone or residual acoustic echo from speakerphone operation, and may more correctly be termed terminal coupling loss (TCL). A typical handset would result in 40-50 dB of echo "loss" due to acoustic feedback. Examples: (i) IP gateway connected to circuit switched network with 2 wire loop Without echo cancellation, typical 2-4 wire converter ERL of 12 dB RERL = ERL + ERLE = 12 + 0 = 12 dB (ii) IP gateway connected to circuit switched network with 2 wire loop With echo canceler that improves echo by 30 dB RERL = ERL + ERLE = 12 + 30 = 42 dB (iii) IP phone with conventional handset Acoustic coupling from handset speaker to microphone ("Terminal Coupling Loss") is typically 40 dB. RERL = TCL = 40 dB If we denote the "local" end of the VoIP path as A and the remote end as B and if the sender loudness rating (SLR) and receiver loudness rating (RLR) are known for A (default values 8 dB and 2 dB respectively), then the echo loudness level at end A (talker echo loudness rating or TELR) is given by: TELR(A) = SRL(A) + ERL(B) + ERLE(B) + RLR(A) TELR(B) = SRL(B) + ERL(A) + ERLE(A) + RLR(B) Hence in order to incorporate echo into a voice quality estimate at the A end of a VoIP connection it is desirable to send the ERL + ERLE value from B to A using a protocol such as RTCP XR. Echo related information may not be available in all VoIP end systems. As Echo does have a significant effect on conversational quality it is recommended that estimated values for Echo Return Loss and Terminal Coupling Loss be provided (if sensible estimates can be reasonably determined). Typical values for end systems are given below to provide guidance: (a) IP Phone with handset - typically 45 dB (b) PC softphone or speakerphone - extremely variable, consider reporting "undefined" (127). (c) IP gateway with line echo canceller - typically has ERL and ERLE available (d) IP gateway without line echo canceller - frequently a source of echo related problems, consider reporting either a low value (12db) or "undefined" (127). -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Colin Perkins Sent: Monday, May 12, 2003 6:51 AM To: avt@ietf.org; Timur Friedman Subject: Re: [AVT] RE: RTCP XR comments --> "Alan Clark" writes: ... >>Section 4.7.4 Residual Echo Return Loss >> >>On draft 05 page 32 I suggest adding the following after the paragraph "The >>ERL and ERLE parameters are >>often..........................................network attached to the >>endpoint. >> >>The Residual Echo Return Loss value may be measured directly by the VoIP >end >>system's Echo Canceller or may be estimated by adding the Echo Return Loss >>and Echo Return Loss Enhancement (ERLE) values reported by the Echo >>Canceller. >> >> RERL(dB) = ERL (dB) + ERLE (dB) >> >>In the case of a VoIP gateway the source of echo is typically line echo >that >>occurs at 2-4 wire conversion points in the network. Echo Return Loss from >>typical 2-4 wire conversion points........(existing paragraph) > >This is a good addition, but my concern was about the typical values >discussion which seems to imply particular implementation strategies. >I suggest deleting everything from the paragraph that begins "In the >case of a VoIP gateway..." to the Gmin discussion? Or, at least, re- >writing it in a manner independent of particular implementations. > >[Alan] Actually the description is more geared around the defaults and >recommendations of typical TIA and ITU standards and is not oriented towards >any specific implementations. If this is not apparent or if the text does >not add anything then we could delete it as suggested. Right, but the draft uses normative language in this section, based around particular implementation choices. If you can rewrite the text from "For an IP phone with handset this metric MUST..." until the discussion of Gmin, so that it describes examples of how particular systems calculate the metric, without using normative (RFC 2119) language, that would be acceptable. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 13 17:26:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29636 for ; Tue, 13 May 2003 17:26:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DKqDL30027 for avt-archive@odin.ietf.org; Tue, 13 May 2003 16:52:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DKiZB29780; Tue, 13 May 2003 16:44:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DKe7B29645 for ; Tue, 13 May 2003 16:40:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29375 for ; Tue, 13 May 2003 17:13:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fh7J-0007hy-00 for avt@ietf.org; Tue, 13 May 2003 17:15:21 -0400 Received: from fmr06.intel.com ([134.134.136.7] helo=caduceus.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 19Fh7I-0007hC-00 for avt@ietf.org; Tue, 13 May 2003 17:15:20 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by caduceus.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.57 2003/05/13 17:32:58 rfjohns1 Exp $) with ESMTP id h4DLAuk01107 for ; Tue, 13 May 2003 21:10:56 GMT Received: from azsmsxvs040.ch.intel.com (azsmsxvs040.ch.intel.com [10.2.248.11]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.30 2003/05/07 16:53:35 rfjohns1 Exp $) with SMTP id h4DKkmg07806 for ; Tue, 13 May 2003 20:46:48 GMT Received: from azsmsx023.ch.intel.com ([10.2.248.28]) by azsmsxvs040.ch.intel.com (NAVGW 2.5.2.11) with SMTP id M2003051314155424232 for ; Tue, 13 May 2003 14:15:54 -0700 Received: by azsmsx023.ch.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 13 May 2003 14:10:49 -0700 Message-ID: <3D90571297ABD511957400508BF29C43043EA7CD@pysmsx101.py.intel.com> From: "Miao, Kai" To: avt@ietf.org Date: Tue, 13 May 2003 14:15:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [AVT] FAX/RTP Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Anyone is still working on fax/RTP, to replace T.38 UDPTL? Kai Miao Intel _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 13 17:41:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00042 for ; Tue, 13 May 2003 17:41:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4DL7cL32066 for avt-archive@odin.ietf.org; Tue, 13 May 2003 17:07:38 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DL2GB30862; Tue, 13 May 2003 17:02:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4DKxsB30329 for ; Tue, 13 May 2003 16:59:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29761 for ; Tue, 13 May 2003 17:33:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FhQS-0007nB-00 for avt@ietf.org; Tue, 13 May 2003 17:35:08 -0400 Received: from csperkins.demon.co.uk ([193.237.26.84] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19FhQP-0007n7-00 for avt@ietf.org; Tue, 13 May 2003 17:35:06 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h4DLUAE7000364; Tue, 13 May 2003 17:30:10 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: alan@telchemy.com cc: avt@ietf.org, "'Timur Friedman'" Subject: Re: [AVT] RE: RTCP XR comments In-Reply-To: Your message of "Mon, 12 May 2003 10:04:53 EDT." <006901c3188f$76733ec0$6801a8c0@telchemy.com> Date: Tue, 13 May 2003 22:30:10 +0100 Message-ID: <363.1052861410@purple.nge.isi.edu> From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> "Alan Clark" writes: >Would this revised text be acceptable? Yes, thanks! Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 14 04:50:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09702 for ; Wed, 14 May 2003 04:50:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4E8HC725023 for avt-archive@odin.ietf.org; Wed, 14 May 2003 04:17:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E8GmB24978; Wed, 14 May 2003 04:16:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4E8D8B24880 for ; Wed, 14 May 2003 04:13:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09643 for ; Wed, 14 May 2003 04:46:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Frvj-0003mF-00 for avt@ietf.org; Wed, 14 May 2003 04:48:07 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Frvi-0003mC-00 for avt@ietf.org; Wed, 14 May 2003 04:48:06 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4E8n60J008746; Wed, 14 May 2003 10:49:11 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id K6Z07SPW; Wed, 14 May 2003 10:48:50 +0200 Message-ID: <3EC20264.8060603@era.ericsson.se> Date: Wed, 14 May 2003 10:46:28 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: IETF AVT WG Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt References: <20030425110714.C77830-100000@ash.packetdesign.com> <3EACD0C1.1050803@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Stephen, I have made a mistake in this. I applied the 1/4 rule also the other way to be used also for the receivers. This is of course in error. To verify that my understanding is correct I will calculate an example of my objection case. Assumption. One active data sender, one receiver. Both RS and RR set. Which will on the sender side use the 1/4 active sender rule: - Sender bandwidth RR+RS. The number that share this bandwidth is 2. - Receiver bandwidth will be RR. The number in the calculation to share this is 1. The interesting result in this case is that the total amount of bandwidth used according to RTCP algorithm is: (RR+RS)/2 + RR = 1.5*RR + 0.5 RS. Depending on the values this can certainly be more than the sum of RR and RS. It is also obvious that it works correctly for when one turns of RTCP Receiver reports. RR=0 results in that no sends RTCP back to the sender. The number of participants will be 1 at the sender side. When that SSRC sends data and is considered an active sender it will use the full RS pot for itself. Sorry for the confusion. Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 14 11:41:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22502 for ; Wed, 14 May 2003 11:41:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4EF8Pb23831 for avt-archive@odin.ietf.org; Wed, 14 May 2003 11:08:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EF6eB22889; Wed, 14 May 2003 11:06:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4EF3dB22767 for ; Wed, 14 May 2003 11:03:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22320 for ; Wed, 14 May 2003 11:36:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FyKr-0006rU-00 for avt@ietf.org; Wed, 14 May 2003 11:38:29 -0400 Received: from [203.199.83.248] (helo=rediffmail.com) by ietf-mx with smtp (Exim 4.12) id 19FyKq-0006r2-00 for avt@ietf.org; Wed, 14 May 2003 11:38:28 -0400 Received: (qmail 32745 invoked by uid 510); 14 May 2003 15:38:50 -0000 Date: 14 May 2003 15:38:50 -0000 Message-ID: <20030514153850.32744.qmail@webmail36.rediffmail.com> Received: from unknown (61.11.82.27) by rediffmail.com via HTTP; 14 may 2003 15:38:50 -0000 MIME-Version: 1.0 From: "vairavan srinivasan" Reply-To: "vairavan srinivasan" To: avt@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [AVT] real-time applications on the internet Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , hai, i have an idea about the real-time applications on internet like audio and video,i would like to know whether such an implementation is possible and if not why?... This a query regarding internet services,as we know real time applications like audio and video are getting more demand in the wold wide web. we also know internet suffers for these applications,suffers in the sense gives poor quality of service like high jitter , high delay...so i have an idea , i just want to know whether is it possible to implement it...the idea is as follows... when the client sends in a request,say or video ,the server when it gets the request it is about to send the response along with the MIME type,this means that the server can know what type of file is being requested by the client.Now my question is why can't the server say to the client that i can offer a better service for the requested file if i can have a connection setup permanently with you(connection oriented service) the client would accept this after all the client wants a high user productivity.so that server terminates the already existing TCP connection with the client through which it got the request and has a permanent connection with the client , in turn enough bandwidth and router space is reserved in the line and hence the client gets a better service just like telephone system.I just want to know whether is it possible to have this implemented.Kindly do reply. Thanking You, S.Vairavan ___________________________________________________ Get www. mycompany .com and 5 matching email ids. Just Rs. 1499/ year. Click here http://www.rediffmailpro.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 16 03:32:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15748 for ; Fri, 16 May 2003 03:32:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4G6xdZ17521 for avt-archive@odin.ietf.org; Fri, 16 May 2003 02:59:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G6veB17467; Fri, 16 May 2003 02:57:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G6rLB17335 for ; Fri, 16 May 2003 02:53:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15709 for ; Fri, 16 May 2003 03:25:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GZcf-00051N-00 for avt@ietf.org; Fri, 16 May 2003 03:27:21 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19GZcZ-00051I-00 for avt@ietf.org; Fri, 16 May 2003 03:27:15 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4G7Rx0J012553; Fri, 16 May 2003 09:27:59 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LA2RXFMD; Fri, 16 May 2003 09:27:51 +0200 Message-ID: <3EC49291.2050209@era.ericsson.se> Date: Fri, 16 May 2003 09:26:09 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner , Colin Perkins CC: IETF AVT WG Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt References: <20030425110714.C77830-100000@ash.packetdesign.com> <3EACD0C1.1050803@era.ericsson.se> <3EC20264.8060603@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Stephen, I have know further considered the interaction between the text written in draft-ietf-avt-rtp-new-12 and draft-ietf-avt-rtcp-bw-5.txt. I think there is two problems, one with each draft. - draft-ietf-avt-rtp-new-12: The algorithm in section 6.3.1 does not match text declaring intention further up in the draft. This should be resolved in some way. But it might be best to consider the RR and RS modifiers. - draft-ietf-avt-rtcp-bw-5.txt: This does not present any solution on how to actually use the RR and RS in the RTCP report interval calculations. I think it should to achieve consistent behavior. Also as the presented RTP algorithm will not allow for turning of the receivers report in cases where the number of senders are more than 1/4 of the participants. In the RTP draft there is chapter 6.3.1 that defines the RTCP transmission algorithm. The most relevant section is this: "1. If there are any senders (senders > 0) in the session, but the number of senders is less than 25% of the membership (members), the interval depends on whether the participant is a sender or not (based on the value of we_sent). If the participant is a sender (we_sent true), the constant C is set to the average RTCP packet size (avg_rtcp_size) divided by 25% of the RTCP bandwidth (rtcp_bw), and the constant n is set to the number of senders. If we_sent is not true, the constant C is set to the average RTCP packet size divided by 75% of the RTCP bandwidth. The constant n is set to the number of receivers (members - senders). If the number of senders is greater than 25%, senders and receivers are treated together. The constant C is set to the average RTCP packet size divided by the total RTCP bandwidth and n is set to the total number of members." If one uses the bandwidth modifiers for RTCP RR and RS they are easy to plug in in the form of: Total RTCP bandwidth (RR+RS) and the fraction for senders only RS/(RR+RS) and receivers RR/(RR+RS). This works fine until we have situation where the senders are either 0 more than 1/4 of the total nr of participants. In that case according to the above algorithm the senders and receivers are treated together. If RR = 0, then the receivers are suddenly able to send again. My problem is that receivers behavior can't be controlled in any of the situations where senders are more than 1/4. I can agree that giving the active senders there part of the total bandwidth pool in these cases is the right thing to do. However giving the receivers the senders part is not good. Another side of this problem is that this 1/4 active sender rules does apply in almost all cases where one has 1-to-1 communication using RTP. It applies for streaming, it applies for conversational cases. Further I can actually think that the above quoted algorithm is actually in error to what is intended: From draft-ietf-avt-rtp-new-12 section 6.2: "When the proportion of senders is greater than 1/4 of the participants, the senders get their proportion of the sum of these parameters. Using two parameters allows RTCP reception reports to be turned off entirely for a particular session by setting the RTCP bandwidth for non-data-senders to zero while keeping the RTCP bandwidth for data senders non-zero so that sender reports can still be sent for inter- media synchronization." This section seems to indicate that only senders should be given an advantage in these cases, and that turning of recievers is necessary to support. Based on this I would propose that algorithm is changed, my proposal is below. I have also changed the text to better clarify where you add the bandwidth values for active senders (RS) and non data senders (RR). It assumes that these values has been fully defined by either being explicit specified or using the default rules in the SDP RTCP bw parameter draft. If there are any senders (senders > 0) in the session, but the number of senders is less than 25% of the membership (members), the interval depends on whether the participant is a sender or not (based on the value of we_sent). If the participant is a sender (we_sent true), the constant C is set to the average RTCP packet size (avg_rtcp_size) divided the RTCP bandwidth for active data senders (25% of rtcp_bw or RS), and the constant n is set to the number of senders. If we_sent is not true, the constant C is set to the average RTCP packet size divided by the RTCP bandwidth for non data senders (75% of rtcp_bw or RR). The constant n is set to the number of receivers (members - senders). If the number of senders is greater than 25%, the interval depends on whether the participant is a sender or not (based on the value of we_sent). If the participant is a sender (we_sent true), the constant C is set to the average RTCP packet size (avg_rtcp_size) divided by the total RTCP bandwidth (rtcp_bw or RR+RS), and the constant n is set to the number of members. If we_sent is not true, the constant C is set to the average RTCP packet size divided by RTCP bandwidth assigned to receivers (b=RR or 75% of rtcp_bw). The constant n is set to the number of members. If there is no senders, the constant C is set to the average RTCP packet size (avg_rtcp_size) divided by the RTCP bandwidth assigned to non data senders (b=RR or 75% of rtcp_bw). To my understanding the above algorithm would handle the usage of RR and RS even when RR=0 in a consistent way. Of course the implementation must handle the division by 0 and that this will give a infinite sending interval. I hope that we can quickly resolve these issues before the documents get published. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 16 07:13:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19101 for ; Fri, 16 May 2003 07:13:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4GA3bA29390 for avt-archive@odin.ietf.org; Fri, 16 May 2003 06:03:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GA09B29269; Fri, 16 May 2003 06:00:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4G9uTB29077 for ; Fri, 16 May 2003 05:56:29 -0400 Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18457 for ; Fri, 16 May 2003 06:28:15 -0400 (EDT) Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id h4GAR3120000 for ; Fri, 16 May 2003 15:57:03 +0530 (IST) Received: from chn-gdy-msg.wipro.com ([10.146.50.99]) by blr-m1-bh1.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 May 2003 15:56:58 +0530 Received: from GDYMCI104863 ([192.168.165.26]) by chn-gdy-msg.wipro.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 16 May 2003 15:56:57 +0530 Message-ID: <028501c31b95$6a962e10$1aa5a8c0@GDYMCI104863> From: "Praveen Athanki" To: "Audio Video Transport" Date: Fri, 16 May 2003 15:55:04 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-bad9c579-8639-11d7-ba7f-006067005148" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 16 May 2003 10:26:57.0569 (UTC) FILETIME=[ADC10110:01C31B95] Subject: [AVT] Regarding RTP payload format for MPEG4 flexmux streams Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPartTM-000-bad9c579-8639-11d7-ba7f-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0282_01C31BC3.8429CB10" ------=_NextPart_000_0282_01C31BC3.8429CB10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Everyone, I would like to know the RFC no. or draft version for transport of = MPEG-4 flexmuxed streams over RTP. Can somebody pls help me? Thanks & Regards, Praveen. ------=_NextPart_000_0282_01C31BC3.8429CB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Everyone,
    I would like to know = the RFC no.=20 or draft version for transport of MPEG-4 flexmuxed streams = over RTP.=20 Can somebody pls help me?
 
Thanks & Regards,
Praveen.
------=_NextPart_000_0282_01C31BC3.8429CB10-- ------=_NextPartTM-000-bad9c579-8639-11d7-ba7f-006067005148-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat May 17 17:27:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15372 for ; Sat, 17 May 2003 17:27:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4HKtET07854 for avt-archive@odin.ietf.org; Sat, 17 May 2003 16:55:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4HKoVB07497; Sat, 17 May 2003 16:50:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4GN39B20448 for ; Fri, 16 May 2003 19:03:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14614 for ; Fri, 16 May 2003 19:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Gokq-0003a4-00 for avt@ietf.org; Fri, 16 May 2003 19:36:48 -0400 Received: from gremlin.ics.uci.edu ([128.195.1.70] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Gokp-0003a1-00 for avt@ietf.org; Fri, 16 May 2003 19:36:48 -0400 Received: from PITBOSS (pitboss.ics.uci.edu [128.195.4.115]) by gremlin.ics.uci.edu (8.12.9/8.12.9) with SMTP id h4GNbTSd001060 for ; Fri, 16 May 2003 16:37:29 -0700 (PDT) From: "Nalini Venkatasubramanian" To: Date: Fri, 16 May 2003 16:37:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-101.7, required 5, DOUBLE_CAPSWORD, LINES_OF_YELLING, MAILTO_TO_SPAM_ADDR, MIME_EXCESSIVE_QP, MSGID_GOOD_EXCHANGE, USER_IN_WHITELIST) Content-Transfer-Encoding: 7bit Subject: [AVT] Call for Papers - MMCN 2004 (Multimedia Computing and Networking 2004) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ********************************************************************** * * * CALL FOR PAPERS * * * * MMCN 2004 * * * * MULTIMEDIA COMPUTING AND NETWORKING 2004 (EI22) * * * * http://www.ics.uci.edu/~mmcn2004 * * * * January 21-22, 2004 * * San Jose, CA, USA * * * * Held in cooperation with ACM SIG Multimedia * * * ********************************************************************** MMCN 2004 will be held January 21-22, 2004, at the San Jose Marriott and San Jose Convention Center, San Jose, California, USA. Present your work at MMCN 2004 and define the future of multimedia! The paper submission deadline is June 23, 2003. For paper submissions please check the MMCN 2004 webpage at http://www.ics.uci.edu/~mmcn2004 Recent advances in telecommunication, storage and information technologies along with enhancements in consumer electronics have stimulated the development of pervasive multimedia applications. New and upcoming standards (MPEG-4, MPEG-7 and MPEG-21) facilitate the seamless integration of multiple modalities of information into truly interoperable multimedia frameworks, creating new experiences for consumers. Such powerful multimedia solutions can have significant impact across a wide spectrum of commercial, consumer, non-profit and governmental domains. The objective of this conference is to bring together researchers, developers, and practitioners contributing to all facets of multimedia computing and networking. The conference will serve as an invigorating forum for the dissemination of state-of-the-art research, development, and implementations of multimedia systems, technologies, and applications. Presenters will be encouraged to make multimedia presentations and demonstrate their solutions in person. We especially encourage papers on emerging technologies such as multimedia and QoS support for 3G and UWB networks, power-aware computing and communications, mobile and fixed wireless multimedia networks, multimedia in P2P environments, network processors, content distribution networks, home networking and digital appliances. An exclusive industrial track will feature industrial design experiences and showcase tools for next-generation multimedia systems and applications. Papers are solicited in all areas of multimedia, including, but not limited to: Multimedia Computing * hardware accelerators * multimedia OS services * power-aware systems * video-on-demand services * peer-to-peer media systems Multimedia and the Internet * web-based services * push technologies and content distribution * wide-area caching * data streaming and delivery Multimedia Networking * mobile and wireless networks * broadband networks * network-processor systems * home networking * QoS control and scheduling * access technologies Measurement and Modeling * performance measurement of multimedia systems * statistical modeling of server traffic and server software * multimedia system simulations * benchmark comparisons Multimedia Middleware * proxy services * transcoding * multimedia data management * security and multimedia Case Studies and Applications * synthetic animation * multimedia search engines * entertainment and games * distributed virtual reality * multimedia authoring We specifically solicit submissions in new and emerging areas in the field. AWARDS will be given to the best paper and the best student paper. PANELS will consist of discussions on timely and controversial topics. Author Information Submissions should not exceed 15 single-spaced pages including figures, tables, and references, using a typeface no smaller than 10 point. Papers must be electronically submitted in PDF or postscript format (using standard fonts and "US letter" size). Detailed instructions on the electronic submission process can be found on the conference web page at http://www.ics.uci.edu/~mmcn2004/. Please also submit a cover page electronically, (in plain text format) to mmcn2004@ics.uci.edu. Each cover page should contain paper title, author names and affiliations, name and address (both postal and electronic) of contact author, abstract (less than 500 words), keywords, and submission area. Please direct questions about paper submission to the Program Co-Chair at mmcn2004@ics.uci.edu IMPORTANT DATES Paper submission deadline : June 23, 2003 Notification of acceptance : Aug 24, 2003 Camera-ready manuscripts due : Oct 27, 2003 200-word Summary to SPIE : Nov 17, 2003 CONFERENCE ORGANIZERS General Chair Ragunathan Rajkumar, Carnegie Mellon University Program Chair Nalini Venkatasubramanian, University of California, Irvine. Publicity Chairs Americas: Ketan Mayer-Patel, University of North Carolina, Chapel Hill Europe: Carsten Griwodz, University of Oslo, Norway Far East: Wei-Ying Ma, Microsoft Research, China Program Committee Tarek F. Abdelzaher, University of Virginia Kevin Almeroth, University of California, Santa Barbara Riccardo Bettati, Texas A&M University Nina Bhatti, Hewlett-Packard Labs Sajal K. Das, University of Texas, Arlington Magda El Zarki, University of California, Irvine Carsten Griwodz, University of Oslo (Norway) Martin G. Kienzle, IBM Research Ketan D. Mayer-Patel, University of North Carolina, Chapel Hill Klara Nahrstedt, University of Illinois, Urbana-Champaign Scott Brandt, University of California, Santa Cruz Douglas C. Schmidt, DARPA/Vanderbilt University Prashant J. Shenoy, University of Massachusetts, Amherst Cormac J. Sreenan, University College Cork (Ireland) Michael Zink, Technical University of Darmstadt (Germany) Roger Zimmermann, University of Southern California Dongyan Xu, Purdue University Hong Jiang Zhang, Microsoft Research Wei-Ying Ma, Microsoft Research, China Reza Rejaie, University of Oregon Prof. Nalini Venkatasubramanian 464 Computer Science Building Department of Information and Computer Science University of California, Irvine Irvine CA 92697-3425 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun May 18 18:52:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20065 for ; Sun, 18 May 2003 18:52:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4IMLKe11217 for avt-archive@odin.ietf.org; Sun, 18 May 2003 18:21:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4IMKeB11182; Sun, 18 May 2003 18:20:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4IMBDB11008 for ; Sun, 18 May 2003 18:11:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19906 for ; Sun, 18 May 2003 18:42:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HWsj-0005n0-00 for avt@ietf.org; Sun, 18 May 2003 18:43:53 -0400 Received: from dial162.east.isi.edu ([65.114.169.162] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19HWsh-0005mx-00 for avt@ietf.org; Sun, 18 May 2003 18:43:52 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h4IMj5Eg064866; Sun, 18 May 2003 18:45:06 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: "Praveen Athanki" cc: "Audio Video Transport" Subject: Re: [AVT] Regarding RTP payload format for MPEG4 flexmux streams In-Reply-To: Your message of "Fri, 16 May 2003 15:55:04 +0530." <028501c31b95$6a962e10$1aa5a8c0@GDYMCI104863> Date: Sun, 18 May 2003 18:45:05 -0400 Message-ID: <64865.1053297905@purple.nge.isi.edu> From: Colin Perkins Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --> "Praveen Athanki" writes: > I would like to know the RFC no. or draft version for transport of >MPEG-4 flexmuxed streams over RTP. Can somebody pls help me? There is no RFC for MPEG-4 FlexMux over RTP, and the draft has expired. The proposed payload format had a number of open issues, which you should be aware of before attempting to use or extend the format. The minutes of the Yokohama AVT meeting (http://www.ietf.org/proceedings/02jul/216.htm) have a summary of these. Colin _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 19 20:06:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10865 for ; Mon, 19 May 2003 20:06:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JNZxh29687 for avt-archive@odin.ietf.org; Mon, 19 May 2003 19:35:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JNZTB29643; Mon, 19 May 2003 19:35:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JNWqB29507 for ; Mon, 19 May 2003 19:32:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10774 for ; Mon, 19 May 2003 20:03:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hucm-0007c4-00 for avt@ietf.org; Mon, 19 May 2003 20:05:00 -0400 Received: from wireless249.east.isi.edu ([65.123.202.249] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19Hucl-0007c1-00 for avt@ietf.org; Mon, 19 May 2003 20:04:59 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h4K05kEg081108; Mon, 19 May 2003 20:05:46 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: Timur Friedman cc: avt@ietf.org, Stephen Casner , Alan Clark , Ramon Caceres , "Kevin C. Almeroth" , Robert Cole , Nick Duffield , Kaynam Hedayat , Kamil Sarac , Magnus Westerlund In-Reply-To: Your message of "Mon, 19 May 2003 23:44:32 +0200." <200305192344.32599.timur.friedman@lip6.fr> Date: Mon, 19 May 2003 20:05:46 -0400 Message-ID: <81107.1053389146@purple.nge.isi.edu> From: Colin Perkins Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Thanks. Unless there are objections, we intend to request that the IESG consider this version for publication as a proposed standard. Colin --> Timur Friedman writes: >Hello, > >Please find attached the latest version of the RTP Control Protocol Extended >Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. > >This draft was produced in response to AVT working group last call comments. > >In addition to the changes discussed online on the AVT list, some additional >detail has been added to the SDP signaling section, to allow individual flags >in the Statistics Summary report blocks to be signaled. Also, default values >have been specified for the VoIP metrics section in places where there might >have been some confusion about what to do if no packets had been received. >And the time frame over which some of the VoIP fields are calculated has >also been specified. > >A PDF version of this draft is available at the following URL: > >http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-report-extns-06.pdf > >Regards, > >Timur Friedman _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 19 20:07:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10880 for ; Mon, 19 May 2003 20:07:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4JNaQ529766 for avt-archive@odin.ietf.org; Mon, 19 May 2003 19:36:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JNYlB29578; Mon, 19 May 2003 19:34:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4JLDCB20820 for ; Mon, 19 May 2003 17:13:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06860; Mon, 19 May 2003 17:42:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HsQc-0006nd-00; Mon, 19 May 2003 17:44:18 -0400 Received: from isis.lip6.fr ([132.227.60.2] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19HsQZ-0006nV-00; Mon, 19 May 2003 17:44:15 -0400 Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.9/jtpda-5.4+victor) with ESMTP id h4JLiaA8017387 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Mon, 19 May 2003 23:44:36 +0200 X-pt: isis.lip6.fr Received: from doris (doris [132.227.72.166]) by tibre.lip6.fr (8.11.6p2/8.11.6) with ESMTP id h4JLiYb07610; Mon, 19 May 2003 23:44:34 +0200 (CEST) From: Timur Friedman To: internet-drafts@ietf.org Date: Mon, 19 May 2003 23:44:32 +0200 User-Agent: KMail/1.4.3 Cc: avt@ietf.org, Colin Perkins , Stephen Casner , Alan Clark , Ramon Caceres , "Kevin C. Almeroth" , Robert Cole , Nick Duffield , Kaynam Hedayat , Kamil Sarac , Magnus Westerlund References: <200305010400.31157.timur.friedman@lip6.fr> In-Reply-To: <200305010400.31157.timur.friedman@lip6.fr> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_8QL5IB8PQ6KXBLPXF656" Message-Id: <200305192344.32599.timur.friedman@lip6.fr> X-Scanned-By: isis.lip6.fr Subject: [AVT] draft-ietf-avt-rtcp-report-extns-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --------------Boundary-00=_8QL5IB8PQ6KXBLPXF656 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Please find attached the latest version of the RTP Control Protocol Exten= ded=20 Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. This draft was produced in response to AVT working group last call commen= ts. =20 In addition to the changes discussed online on the AVT list, some additio= nal=20 detail has been added to the SDP signaling section, to allow individual f= lags=20 in the Statistics Summary report blocks to be signaled. Also, default va= lues=20 have been specified for the VoIP metrics section in places where there mi= ght=20 have been some confusion about what to do if no packets had been received= =2E =20 And the time frame over which some of the VoIP fields are calculated has = also=20 been specified. A PDF version of this draft is available at the following URL: http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-repor= t-extns-06.pdf Regards, Timur Friedman --------------Boundary-00=_8QL5IB8PQ6KXBLPXF656 Content-Type: text/plain; charset="iso-8859-1"; name="draft-ietf-avt-rtcp-report-extns-06.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rtcp-report-extns-06.txt" Content-Transfer-Encoding: quoted-printable INTERNET-DRAFT 19 May 2003 Internet Engineering Task Force Expires: 19 November 2003 Audio/Video Transport Working Group Timur Friedman, Paris 6 Ramon Caceres, ShieldIP Alan Clark, Telchemy Editors RTP Control Protocol Extended Reports (RTCP XR) draft-ietf-avt-rtcp-report-extns-06.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by Friedman et al. Standards Track [Page 1] =0C Internet-Draft RTCP XR May 2003 RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. Table of Contents 1. Introduction .............................................. 3 1.1 Applicability ............................................. 4 1.2 Terminology ............................................... 7 2. XR Packet Format .......................................... 7 3. Extended Report Block Framework ........................... 8 4. Extended Report Blocks .................................... 9 4.1 Loss RLE Report Block ..................................... 9 4.1.1 Run Length Chunk .......................................... 15 4.1.2 Bit Vector Chunk .......................................... 15 4.1.3 Terminating Null Chunk .................................... 15 4.2 Duplicate RLE Report Block ................................ 16 4.3 Packet Receipt Times Report Block ......................... 17 4.4 Receiver Reference Time Report Block ...................... 20 4.5 DLRR Report Block ......................................... 21 4.6 Statistics Summary Report Block ........................... 22 4.7 VoIP Metrics Report Block ................................. 25 4.7.1 Packet Loss and Discard Metrics ........................... 26 4.7.2 Burst Metrics ............................................. 27 4.7.3 Delay Metrics ............................................. 30 4.7.4 Signal Related Metrics .................................... 30 4.7.5 Call Quality or Transmission Quality Metrics .............. 33 4.7.6 Configuration Parameters .................................. 34 4.7.7 Jitter Buffer Parameters .................................. 35 5. SDP Signaling ............................................. 36 5.1 The SDP Attribute ......................................... 37 5.2 Usage in Offer/Answer ..................................... 40 5.3 Usage Outside of Offer/Answer ............................. 41 6. IANA Considerations ....................................... 42 6.1 XR Packet Type ............................................ 42 6.2 RTCP XR Block Type Registry ............................... 42 6.3 The "rtcp-xr" SDP Attribute ............................... 43 7. Security Considerations ................................... 44 A. Algorithms ................................................ 45 A.1 Sequence Number Interpretation ............................ 45 A.2 Example Burst Packet Loss Calculation ..................... 46 Intellectual Property ..................................... 48 Full Copyright Statement .................................. 49 Acknowledgments ........................................... 49 Contributors .............................................. 50 Friedman et al. Standards Track [Page 2] =0C Internet-Draft RTCP XR May 2003 Authors' Addresses ........................................ 50 References ................................................ 52 Normative References ...................................... 52 Non-Normative References .................................. 53 1. Introduction This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP) [9], and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP) [4]. XR packets convey information beyond that already contained in the reception report blocks of RTCP's sender report (SR) or Receiver Report (RR) packets. The information is of use across RTP profiles, and so is not appropriately carried in SR or RR profile-specific extensions. Information used for network management falls into this category, for instance. The definition is broken out over the three sections that follow the Introduction. Section 2 defines the XR packet as consisting of an eight octet header followed by a series of components called report blocks. Section 3 defines the common format, or framework, consisting of a type and a length field, required for all report blocks. Section 4 defines several specific report block types. Other block types can be defined in future documents as the need arises. The report block types defined in this document fall into three categories. The first category consists of packet-by-packet reports on received or lost RTP packets. Reports in the second category convey reference time information between RTP participants. In the third category, reports convey metrics relating to packet receipts, that are summary in nature but that are more detailed, or of a different type, than that conveyed in existing RTCP packets. All told, seven report block formats are defined by this document. Of these, three are packet-by-packet block types: - Loss RLE Report Block (Section 4.1): Run length encoding of reports concerning the losses and receipts of RTP packets. - Duplicate RLE Report Block (Section 4.2): Run length encoding of reports concerning duplicates of received RTP packets. - Packet Receipt Times Report Block (Section 4.3): A list of reception timestamps of RTP packets. There are two reference time related block types: Friedman et al. Standards Track [Page 3] =0C Internet-Draft RTCP XR May 2003 - Receiver Reference Time Report Block (Section 4.4): Receiver-end wallclock timestamps. Together with the DLRR Report Block mentioned next, these allow non-senders to calculate round-trip times. - DLRR Report Block (Section 4.5): The delay since the last Receiver Reference Time Report Block was received. An RTP data sender that receives a Receiver Reference Time Report Block can respond with a DLRR Report Block, in much the same way as, in the mechanism already defined for RTCP [9, Section 6.3.1], an RTP data receiver that receives a sender's NTP timestamp can respond by filling in the DLSR field of an RTCP reception report block. Finally, this document defines two summary metric block types: - Statistics Summary Report Block (Section 4.6): Statistics on RTP packet sequence numbers, losses, duplicates, jitter, and TTL or Hop Limit values. - VoIP Metrics Report Block (Section 4.7): Metrics for monitoring Voice over IP (VoIP) calls. Before proceeding to the XR packet and report block definitions, this document provides an applicability statement (Section 1.1) that describes the contexts in which these report blocks can be used. It also defines (Section 1.2) the normative use of key words, such as MUST and SHOULD, as they are employed in this document. Following the definitions of the various report blocks, this document describes how applications that employ SDP can signal their use (Section 5). The document concludes with a discussion (Section 6) of numbering considerations for the Internet Assigned Numbers Authority (IANA), of security considerations (Section 7), and with appendices that provide examples of how to implement algorithms discussed in the text. 1.1 Applicability The XR packets are useful across multiple applications, and for that reason are not defined as profile-specific extensions to RTCP sender or Receiver Reports [9, Section 6.4.3]. Nonetheless, they are not of use in all contexts. In particular, the VoIP metrics report block (Section 4.7) is specific to voice applications, though it can be employed over a wide variety of such applications. The VoIP metrics report block can be applied to any one-to-one or one-to-many voice application for which the use of RTP and RTCP is specified. The use of conversational metrics (Section 4.7.5), including the R factor (as described by the E Model defined in [3]) Friedman et al. Standards Track [Page 4] =0C Internet-Draft RTCP XR May 2003 and the mean opinion score for conversational quality (MOS-CQ), in applications other than simple two party calls is not defined, and hence these metrics should be identified as unavailable in multicast conferencing applications. The packet-by-packet report block types, Loss RLE (Section 4.1), Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3), have been defined with network tomography applications, such as multicast inference of network characteristics (MINC) [11], in mind. MINC requires detailed packet receipt traces from multicast session receivers in order to infer the gross structure of the multicast distribution tree and the parameters, such as loss rates and delays, that apply to paths between the branching points of that tree. Any real time multicast multimedia application can use the packet-by- packet report block types. Such an application could employ a MINC inference subsystem that would provide it with multicast tree topology information. One potential use of such a subsystem would be for the identification of high loss regions in the multicast tree and the identification of multicast session participants well situated to provide retransmissions of lost packets. Detailed packet-by-packet reports do not necessarily have to consume disproportionate bandwidth with respect to other RTCP packets. An application can cap the size of these blocks. A mechanism called "thinning" is provided for these report blocks, and can be used to ensure that they adhere to a size limit by restricting the number of packets reported upon within any sequence number interval. The rationale for, and use of this mechanism is described in [13]. Furthermore, applications might not require report blocks from all receivers in order to answer such important questions as where in the multicast tree there are paths that exceed a defined loss rate threshold. Intelligent decisions regarding which receivers send these report blocks can further restrict the portion of RTCP bandwidth that they consume. The packet-by-packet report blocks can also be used by dedicated network monitoring applications. For such an application, it might be appropriate to allow more than 5% of RTP data bandwidth to be used for RTCP packets, thus allowing proportionately larger and more detailed report blocks. Nothing in the packet-by-packet block types restricts their use to multicast applications. In particular, they could be used for network tomography similar to MINC, but using striped unicast packets. In addition, if it were found useful, they could be used for applications limited to two participants. Friedman et al. Standards Track [Page 5] =0C Internet-Draft RTCP XR May 2003 One use to which the packet-by-packet reports are not immediately suited is for data packet acknowledgments as part of a packet retransmission mechanism. The reason is that the packet accounting technique suggested for these blocks differs from the packet accounting normally employed by RTP. In order to favor measurement applications, an effort is made to interpret as little as possible at the data receiver, and leave the interpretation as much as possible to participants that receive the report blocks. Thus, for example, a packet with an anomalous SSRC ID or an anomalous sequence number might be excluded by normal RTP accounting, but would be reported upon for network monitoring purposes. The Statistics Summary Report Block (Section 4.6) has also been defined with network monitoring in mind. This block type can be used equally well for reporting on unicast and multicast packet reception. The reference time related block types were conceived for receiver- based TCP-friendly multicast congestion control [18]. By allowing data receivers to calculate their round trip times to senders, they help the receivers estimate the downstream bandwidth they should request. Note that if every receiver is to send Receiver Reference Time Report Blocks (Section 4.4), a sender might potentially send a number of DLRR Report Blocks (Section 4.5) equal to the number of receivers whose RTCP packets have arrived at the sender within its reporting interval. As the number of participants in a multicast session increases, an application should use discretion regarding which participants send these blocks, and how frequently. XR packets supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6]. The introduction of XR packets into a session in no way changes the rules governing the calculation of the RTCP reporting interval [9, Section 6.2]. As XR packets are RTCP packets, they count as such for bandwidth calculations. As a result, the addition of extended reporting information may tend to increase the average RTCP packet size, and thus the average reporting interval. This increase may be limited by limiting the size of XR packets. The SDP signaling defined for XR packets in this document (Section 5) was done so with three use scenarios in mind: a Real Time Streaming Protocol (RTSP) controlled streaming application, a one-to-many multicast multimedia application such as a course lecture with enhanced feedback, and a Session Initiation Protocol (SIP) controlled conversational session involving two parties. Applications that employ SDP are free to use additional SDP signaling for cases not covered here. In addition, applications are free to use signaling mechanisms other than SDP. Friedman et al. Standards Track [Page 6] =0C Internet-Draft RTCP XR May 2003 1.2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliance with this specification. 2. XR Packet Format An XR packet consists of a header of two 32-bit words, followed by a number, possibly zero, of extended report blocks. This type of packet is laid out in a manner consistent with other RTCP packets, as concerns the essential version, packet type, and length information. XR packets are thus backwards compatible with RTCP receiver implementations that do not recognize them, but that ought to be able to parse past them using the length information. A padding field and an SSRC field are also provided in the same locations that they appear in other RTCP packets, for simplicity. The format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|reserved | PT=3DXR=3D207 | length = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : report blocks : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP. This specification applies to RTP version two. padding (P): 1 bit If the padding bit is set, this XR packet contains some additional padding octets at the end. The semantics of this field are identical to the semantics of the padding field in the SR packet, as defined by the RTP specification. reserved: 5 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. packet type (PT): 8 bits Friedman et al. Standards Track [Page 7] =0C Internet-Draft RTCP XR May 2003 Contains the constant 207 to identify this as an RTCP XR packet. This value is registered with the Internet Assigned Numbers Authority (IANA), as described in Section 5.1. length: 16 bits As described for the RTCP Sender Report (SR) packet (see Section 6.3.1 of the RTP specification [9]). Briefly, the length of this XR packet in 32-bit words minus one, including the header and any padding. SSRC: 32 bits The synchronization source identifier for the originator of this XR packet. report blocks: variable length. Zero or more extended report blocks. In keeping with the extended report block framework defined below, each block MUST consist of one or more 32-bit words. 3. Extended Report Block Framework Extended report blocks are stacked, one after the other, at the end of an XR packet. An individual block's length is a multiple of 4 octets. The XR header's length field describes the total length of the packet, including these extended report blocks. Each block has block type and length fields that facilitate parsing. A receiving application can demultiplex the blocks based upon their type, and can use the length information to locate each successive block, even in the presence of block types it does not recognize. An extended report block has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT | type-specific | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : type-specific block contents : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits Identifies the block format. Seven block types are defined in Section 4. Additional block types may be defined in future specifications. This field's name space is managed by the Internet Assigned Numbers Authority (IANA), as described in Friedman et al. Standards Track [Page 8] =0C Internet-Draft RTCP XR May 2003 Section 5.2. type-specific: 8 bits The use of these bits is determined by the block type definition. block length: 16 bits The length of this report block including the header, in 32-bit words minus one. If the block type definition permits, zero is an acceptable value, signifying a block that consists of only the BT, type-specific, and block length fields, with a null type-specific block contents field. type-specific block contents: variable length The use of this field is defined by the particular block type, subject to the constraint that it MUST be a multiple of 32 bits long. If the block type definition permits, It MAY be zero bits long. 4. Extended Report Blocks This section defines seven extended report blocks: block types for reporting upon received packet losses and duplicates, packet reception times, receiver reference time information, receiver inter- report delays, detailed reception statistics, and voice over IP (VoIP) metrics. An implementation SHOULD ignore incoming blocks with types either not relevant or unknown to it. Additional block types MUST be registered with the Internet Assigned Numbers Authority (IANA) [16], as described in Section 5.2. 4.1 Loss RLE Report Block This block type permits detailed reporting upon individual packet receipt and loss events. Such reports can be used, for example, for multicast inference of network characteristics (MINC) [11]. With MINC, one can discover the topology of the multicast tree used for distributing a source's RTP packets, and of the loss rates along links within that tree. Or they could be used to provide raw data to a network management application. Since a Boolean trace of lost and received RTP packets is potentially lengthy, this block type permits the trace to be compressed through run length encoding. To further reduce block size, loss event reports can be systematically dropped from the trace in a mechanism called thinning that is described below and that is studied in [13]. A participant that generates a Loss RLE Report Block should favor accuracy in reporting on observed events over interpretation of those Friedman et al. Standards Track [Page 9] =0C Internet-Draft RTCP XR May 2003 events whenever possible. Interpretation should be left to those who observe the report blocks. Following this approach implies that accounting for Loss RLE Report Blocks will differ from the accounting for the generation of the SR and RR packets described in the RTP specification [9] in the following two areas: per-sender accounting and per-packet accounting. In its per-sender accounting, an RTP session participant SHOULD NOT make the receipt of a threshold minimum number of RTP packets a condition for reporting upon the sender of those packets. This accounting technique differs from the technique described in Section 6.2.1 and Appendix A.1 of the RTP specification that allows a threshold to determine whether a sender is considered valid. In its per-packet accounting, an RTP session participant SHOULD treat all sequence numbers as valid. This accounting technique differs from the technique described in Appendix A.1 of the RTP specification that suggests ruling a sequence number valid or invalid on the basis of its contiguity with the sequence numbers of previously received packets. Sender validity and sequence number validity are interpretations of the raw data. Such interpretations are justified in the interest, for example, of excluding the stray old packet from an unrelated session from having an effect upon the calculation of the RTCP transmission interval. The presence of stray packets might, on the other hand, be of interest to a network monitoring application. One accounting interpretation that is still necessary is for a participant to decide whether the 16 bit sequence number has rolled over. Under ordinary circumstances this is not a difficult task. For example, if packet number 65,535 (the highest possible sequence number) is followed shortly by packet number 0, it is reasonable to assume that there has been a rollover. However it is possible that the packet is an earlier one (from 65,535 packets earlier). It is also possible that the sequence numbers have rolled over multiple times, either forward or backward. The interpretation becomes more difficult when there are large gaps between the sequence numbers, even accounting for rollover, and when there are long intervals between received packets. The per-packet accounting technique mandated here is for a participant to keep track of the sequence number of the packet most recently received from a sender. For the next packet that arrives from that sender, the sequence number MUST be judged to fall no more than 32,768 packets ahead or behind the most recent one, whichever choice places it closer. In the event that both choices are equally distant (only possible when the distance is 32,768), the choice MUST Friedman et al. Standards Track [Page 10] =0C Internet-Draft RTCP XR May 2003 be the one that does not require a rollover. Appendix A.1 presents an algorithm that implements this technique. Each block reports on a single RTP data packet source, identified by its SSRC. The receiver that is supplying the report is identified in the header of the RTCP packet. Choice of beginning and ending RTP packet sequence numbers for the trace is left to the application. These values are reported in the block. The last sequence number in the trace MAY differ from the sequence number reported on in any accompanying SR or RR report. Note that because of sequence number wraparound the ending sequence number MAY be less than the beginning sequence number. A Loss RLE Report Block MUST NOT be used to report upon a range of 65,534 or greater in the sequence number space, as there is no means to identify multiple wraparounds. The trace described by a Loss RLE report consists of a sequence of Boolean values, one for each sequence number of the trace. A value of one represents a packet receipt, meaning that one or more packets having that sequence number have been received since the most recent wraparound of sequence numbers (or since the beginning of the RTP session if no wraparound has been judged to have occurred). A value of zero represents a packet loss, meaning that there has been no packet receipt for that sequence number as of the time of the report. If a packet with a given sequence number is received after a report of a loss for that sequence number, a later Loss RLE report MAY report a packet receipt for that sequence number. The encoding itself consists of a series of 16 bit units called chunks that describe sequences of packet receipts or losses in the trace. Each chunk either specifies a run length or a bit vector, or is a null chunk. A run length describes between 1 and 16,383 events that are all the same (either all receipts or all losses). A bit vector describes 15 events that may be mixed receipts and losses. A null chunk describes no events, and is used to round out the block to a 32 bit word boundary. The mapping from a sequence of lost and received packets into a sequence of chunks is not necessarily unique. For example, the following trace covers 45 packets, of which the 22nd and 24th have been lost and the others received: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1111 1 Friedman et al. Standards Track [Page 11] =0C Internet-Draft RTCP XR May 2003 One way to encode this would be: bit vector 1111 1111 1111 111 bit vector 1111 1101 0111 111 bit vector 1111 1111 1111 111 null chunk Another way to encode this would be: run of 21 receipts bit vector 0101 1111 1111 111 run of 9 receipts null chunk The choice of encoding is left to the application. As part of this freedom of choice, applications MAY terminate a series of run length and bit vector chunks with a bit vector chunk that runs beyond the sequence number space described by the report block. For example, if the 44th packet in the same sequence were lost: 1111 1111 1111 1111 1111 1010 1111 1111 1111 1111 1110 1 This could be encoded as: run of 21 receipts bit vector 0101 1111 1111 111 bit vector 1111 1110 1000 000 null chunk In this example, the last five bits of the second bit vector describe a part of the sequence number space that extends beyond the last sequence number in the trace. These bits have been set to zero. All bits in a bit vector chunk that describe a part of the sequence number space that extends beyond the last sequence number in the trace MUST be set to zero, and MUST be ignored by the receiver. A null packet MUST appear at the end of a Loss RLE Report Block if the number of run length plus bit vector chunks is odd. The null chunk MUST NOT appear in any other context. Friedman et al. Standards Track [Page 12] =0C Internet-Draft RTCP XR May 2003 Caution should be used in sending Loss RLE Report Blocks because, even with the compression provided by run length encoding, they can easily consume bandwidth out of proportion with normal RTCP packets. The block type includes a mechanism, called thinning, that allows an application to limit report sizes. A thinning value, T, selects a subset of packets within the sequence number space: those with sequence numbers that are multiples of 2^T. Packet reception and loss reports apply only to those packets. T can vary between 0 and 15. If T is zero then every packet in the sequence number space is reported upon. If T is fifteen then one in every 32,768 packets is reported upon. Suppose that the trace just described begins at sequence number 13,821. The last sequence number in the trace is 13,865. If the trace were to be thinned with a thinning value of T=3D2, then the following sequence numbers would be reported upon: 13,824, 13,828, 13,832, 13,836, 13,840, 13,844, 13,848, 13,852, 13,856, 13,860, 13,864. The thinned trace would be as follows: 1 1 1 1 1 0 1 1 1 1 0 This could be encoded as follows: bit vector 1111 1011 1100 000 null chunk The last four bits in the bit vector, representing sequence numbers 13,868, 13,872, 13,876, and 13,880, extend beyond the trace and are thus set to zero and are ignored by the receiver. With thinning, the loss of the 22nd packet goes unreported because its sequence number, 13,842, is not a multiple of four. Packet receipts for all sequence numbers that are not multiples of four also go unreported. However, in this example thinning has permitted the Loss RLE Report Block to be shortened by one 32 bit word. Choice of the thinning value is left to the application. The Loss RLE Report Block has the following format: Friedman et al. Standards Track [Page 13] =0C Internet-Draft RTCP XR May 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D1 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Loss RLE Report Block is identified by the constant 1. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits The amount of thinning performed on the sequence number space. Only those packets with sequence numbers 0 mod 2^T are reported on by this block. A value of 0 indicates that there is no thinning, and all packets are reported on. The maximum thinning is one packet in every 32,768 (amounting to two packets within each 16-bit sequence space). block length: 16 bits Defined in Section 3. SSRC of source: 32 bits The SSRC of the RTP data packet source being reported upon by this report block. begin_seq: 16 bits The first sequence number that this block reports on. end_seq: 16 bits The last sequence number that this block reports on plus one. chunk i: 16 bits There are three chunk types: run length, bit vector, and Friedman et al. Standards Track [Page 14] =0C Internet-Draft RTCP XR May 2003 terminating null, defined in the following sections. If the chunk is all zeroes then it is a terminating null chunk. Otherwise, the leftmost bit of the chunk determines its type: 0 for run length and 1 for bit vector. 4.1.1 Run Length Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R| run length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A zero identifies this as a run length chunk. run type (R): 1 bit Zero indicates a run of 0s. One indicates a run of 1s. run length: 14 bits A value between 1 and 16,383. The value MUST not be zero for a run length chunk (zeroes in both the run type and run length fields would make the chunk a terminating null chunk). Run lengths of 15 or less MAY be described with a run length chunk despite the fact that they could also be described as part of a bit vector chunk. 4.1.2 Bit Vector Chunk 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| bit vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ chunk type (C): 1 bit A one identifies this as a bit vector chunk. bit vector: 15 bits The vector is read from left to right, in order of increasing sequence number (with the appropriate allowance for wraparound). 4.1.3 Terminating Null Chunk Friedman et al. Standards Track [Page 15] =0C Internet-Draft RTCP XR May 2003 This chunk is all zeroes. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Duplicate RLE Report Block This block type permits per-sequence-number reports on duplicates in a source's RTP packet stream. Such information can be used for network diagnosis, and provide an alternative to packet losses as a basis for multicast tree topology inference. The Duplicate RLE Report Block format is identical to the Loss RLE Report Block format. Only the interpretation is different, in that the information concerns packet duplicates rather than packet losses. The trace to be encoded in this case also consists of zeros and ones, but a zero here indicates the presence of duplicate packets for a given sequence number, whereas a one indicates that no duplicates were received. The existence of a duplicate for a given sequence number is determined over the entire reporting period. For example, if packet number 12,593 arrives, followed by other packets with other sequence numbers, the arrival later in the reporting period of another packet numbered 12,593 counts as a duplicate for that sequence number. The duplicate does not need to follow immediately upon the first packet of that number. Care must be taken that a report does not cover a range of 65,534 or greater in the sequence number space. No distinction is made between the existence of a single duplicate packet and multiple duplicate packets for a given sequence number. Note also that since there is no duplicate for a lost packet, a loss is encoded as a one in a Duplicate RLE Report Block. The Duplicate RLE Report Block has the following format: Friedman et al. Standards Track [Page 16] =0C Internet-Draft RTCP XR May 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D2 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk 1 | chunk 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | chunk n-1 | chunk n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Duplicate RLE Report Block is identified by the constant 2. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits As defined in Section 4.1. block length: 16 bits Defined in Section 3. SSRC of source: 32 bits As defined in Section 4.1. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. chunk i: 16 bits As defined in Section 4.1. 4.3 Packet Receipt Times Report Block This block type permits per-sequence-number reports on packet receipt times for a given source's RTP packet stream. Such information can be used for MINC inference of the topology of the multicast tree used Friedman et al. Standards Track [Page 17] =0C Internet-Draft RTCP XR May 2003 to distribute the source's RTP packets, and of the delays along the links within that tree. It can also be used to measure partial path characteristics and to model distributions for packet jitter. Packet receipt times are expressed in the same units as used in the RTP timestamps of data packets. This is so that, for each packet, one can establish both the send time and the receipt time in comparable terms. Note, however, that as an RTP sender ordinarily initializes its time to a value chosen at random, there can be no expectation that reported send and receipt times will differ by an amount equal to the one-way delay between sender and receiver. The reported times can nonetheless be useful for the purposes mentioned above. At least one packet MUST have been received for each sequence number reported upon in this block. If this block type is used to report receipt times for a series of sequence numbers that includes lost packets, several blocks are required. If duplicate packets have been received for a given sequence number, and those packets differ in their receipt times, any time other than the earliest MUST NOT be reported. This is to ensure consistency among reports. Times reported in RTP timestamp format consume more bits than loss or duplicate information, and do not lend themselves to run length encoding. The use of thinning is encouraged to limit the size of Packet Receipt Times Report Blocks. The Packet Receipt Times Report Block has the following format: Friedman et al. Standards Track [Page 18] =0C Internet-Draft RTCP XR May 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D3 | rsvd. | T | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receipt time of packet begin_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receipt time of packet (begin_seq + 1) mod 65536 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receipt time of packet (end_seq - 1) mod 65536 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Packet Receipt Times Report Block is identified by the constant 3. rsvd.: 4 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. thinning (T): 4 bits As defined in Section 4.1. block length: 16 bits Defined in Section 3. SSRC of source: 32 bits As defined in Section 4.1. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. Packet i receipt time: 32 bits The receipt time of the packet with sequence number i at the receiver. The modular arithmetic shown in the packet format diagram is to allow for sequence number rollover. It is preferable for the time value to be established at the link Friedman et al. Standards Track [Page 19] =0C Internet-Draft RTCP XR May 2003 layer interface, or in any case as close as possible to the wire arrival time. Units and format are the same as for the timestamp in RTP data packets. As opposed to RTP data packet timestamps, in which nominal values may be used instead of system clock values in order to convey information useful for periodic playout, the receipt times should reflect the actual time as closely as possible. For a session, if the RTP timestamp is chosen at random, the first receipt time value SHOULD also be chosen at random, and subsequent timestamps offset from this value. On the other hand, if the RTP timestamp is meant to reflect the reference time at the sender, then the receipt time SHOULD be as close as possible to the reference time at the receiver. 4.4 Receiver Reference Time Report Block This block extends RTCP's timestamp reporting so that non-senders may also send timestamps. It recapitulates the NTP timestamp fields from the RTCP Sender Report [9, Sec. 6.3.1]. A non-sender may estimate its round trip time (RTT) to other participants, as proposed in [18], by sending this report block and receiving DLRR Report Blocks (see next section) in reply. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D4 | reserved | block length =3D 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Receiver Reference Time Report Block is identified by the constant 4. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits The constant 2, in accordance with the definition of this field in Section 3. Friedman et al. Standards Track [Page 20] =0C Internet-Draft RTCP XR May 2003 NTP timestamp: 64 bits Indicates the wallclock time when this block was sent so that it may be used in combination with timestamps returned in DLRR Report Blocks (see next section) from other receivers to measure round-trip propagation to those receivers. Receivers should expect that the measurement accuracy of the timestamp may be limited to far less than the resolution of the NTP timestamp. The measurement uncertainty of the timestamp is not indicated as it may not be known. A report block sender that can keep track of elapsed time but has no notion of wallclock time may use the elapsed time since joining the session instead. This is assumed to be less than 68 years, so the high bit will be zero. It is permissible to use the sampling clock to estimate elapsed wallclock time. A report sender that has no notion of wallclock or elapsed time may set the NTP timestamp to zero. 4.5 DLRR Report Block This block extends RTCP's delay since last Sender Report (DLSR) mechanism [9, Sec. 6.3.1] so that non-senders may also calculate round trip times, as proposed in [18]. It is termed DLRR for delay since last Receiver Report, and may be sent in response to a Receiver Timestamp Report Block (see previous section) from a receiver to allow that receiver to calculate its round trip time to the respondent. The report consists of one or more 3 word sub-blocks: one sub-block per Receiver Report. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D5 | reserved | block length | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | SSRC_1 (SSRC of first receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k | last RR (LRR) | 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | delay since last RR (DLRR) | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | SSRC_2 (SSRC of second receiver) | sub- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bloc= k : ... : 2 +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ block type (BT): 8 bits A DLRR Report Block is identified by the constant 5. Friedman et al. Standards Track [Page 21] =0C Internet-Draft RTCP XR May 2003 reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits Defined in Section 3. last RR timestamp (LRR): 32 bits The middle 32 bits out of 64 in the NTP timestamp (as explained in the previous section) received as part of a Receiver Reference Time Report Block from participant SSRC_n. If no such block has been received, the field is set to zero. delay since last RR (DLRR): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last Receiver Reference Time Report Block from participant SSRC_n and sending this DLRR Report Block. If no Receiver Reference Time Report Block has been received yet from SSRC_n, the DLRR field is set to zero (or the DLRR is omitted entirely). Let SSRC_r denote the receiver issuing this DLRR Report Block. Participant SSRC_n can compute the round-trip propagation delay to SSRC_r by recording the time A when this Receiver Timestamp Report Block is received. It calculates the total round-trip time A-LRR using the last RR timestamp (LRR) field, and then subtracting this field to leave the round-trip propagation delay as A-LRR-DLRR. This is illustrated in [9, Fig. 2]. 4.6 Statistics Summary Report Block This block reports statistics beyond the information carried in the standard RTCP packet format, but not as fine grained as that carried in the report blocks previously described. Information is recorded about lost packets, duplicate packets, jitter measurements, and TTL or Hop Limit values. Such information can be useful for network management. The report block contents are dependent upon a series of flags bit carried in the first part of the header. Not all parameters need to be reported in each block. Flags indicate which are and which are not reported. The fields corresponding to unreported parameters MUST be present, but are set to zero. The receiver MUST ignore any Statistics Summary Report Block with a non-zero value in any field flagged as unreported. The Statistics Summary Report Block has the following format: Friedman et al. Standards Track [Page 22] =0C Internet-Draft RTCP XR May 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D6 |L|D|J|ToH|rsvd.| block length =3D 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | begin_seq | end_seq | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lost_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dup_packets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | max_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mean_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dev_jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | min_ttl_or_hl | max_ttl_or_hl |mean_ttl_or_hl | dev_ttl_or_hl | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A Statistics Summary Report Block is identified by the constant 6. loss report flag (L): 1 bit Bit set to 1 if the lost_packets field contains a report, 0 otherwise. duplicate report flag (D): 1 bit Bit set to 1 if the dup_packets field contains a report, 0 otherwise. jitter flag (J): 1 bit Bit set to 1 if the min_jitter, max_jitter, mean_jitter, and dev_jitter fields all contain reports, 0 if none of them do. TTL or Hop Limit flag (ToH): 2 bits This field is set to 0 if none of the fields min_ttl_or_hl, max_ttl_or_hl, mean_ttl_or_hl, or dev_ttl_or_hl contain reports. If the field is non-zero then all of these fields contain reports. The value 1 signifies that they report on IPv4 TTL values. The value 2 signifies that they report on IPv6 Hop Limit values. This value 3 is undefined and MUST NOT be used. Friedman et al. Standards Track [Page 23] =0C Internet-Draft RTCP XR May 2003 rsvd.: 3 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits The constant 9, in accordance with the definition of this field in Section 3. SSRC of source: 32 bits As defined in Section 4.1. begin_seq: 16 bits As defined in Section 4.1. end_seq: 16 bits As defined in Section 4.1. lost_packets: 32 bits Number of lost packets in the above sequence number interval. dup_packets: 32 bits Number of duplicate packets in the above sequence number interval. min_jitter: 32 bits The minimum relative transit time between two packets in the above sequence number interval. All jitter values are measured as the difference between a packet's RTP timestamp and the reporter's clock at the time of arrival, measured in the same units. max_jitter: 32 bits The maximum relative transit time between two packets in the above sequence number interval. mean_jitter: 32 bits The mean relative transit time between each two packet series in the above sequence number interval, rounded to the nearest value expressible as an RTP timestamp. dev_jitter: 32 bits The standard deviation of the relative transit time between each two packet series in the above sequence number interval. min_ttl_or_hl: 8 bits The minimum TTL or Hop Limit value of data packets in the sequence number range. Friedman et al. Standards Track [Page 24] =0C Internet-Draft RTCP XR May 2003 max_ttl_or_hl: 8 bits The maximum TTL or Hop Limit value of data packets in the sequence number range. mean_ttl_or_hl: 8 bits The mean TTL or Hop Limit value of data packets in the sequence number range, rounded to the nearest integer. dev_ttl_or_hl: 8 bits The standard deviation of TTL or Hop Limit values of data packets in the sequence number range. 4.7 VoIP Metrics Report Block The VoIP Metrics Report Block provides metrics for monitoring voice over IP (VoIP) calls. These metrics include packet loss and discard metrics, delay metrics, analog metrics, and voice quality metrics. The block reports separately on packets lost on the IP channel, and those that have been received but then discarded by the receiving jitter buffer. It also reports on the combined effect of losses and discards, as both have equal effect on call quality. In order to properly assess the quality of a Voice over IP call it is desirable to consider the degree of burstiness of packet loss [14]. Following a Gilbert-Elliott model [3], a period of time, bounded by lost and/or discarded packets, with a high rate of losses and/or discards is a "burst," and a period of time between two bursts is a "gap." Bursts correspond to periods of time during which the packet loss rate is high enough to produce noticeable degradation in audio quality. Gaps correspond to periods of time during which only isolated lost packets may occur, and in general these can be masked by packet loss concealment. Delay reports include the transit delay between RTP end points and the VoIP end system processing delays, both of which contribute to the user perceived delay. Additional metrics include signal, echo, noise, and distortion levels. Call quality metrics include R factors (as described by the E Model defined in [6,3]) and mean opinion scores (MOS scores). Implementations MUST provide values for all the fields defined here. For certain metrics, if the value is undefined or unknown, then the specified default or unknown field value MUST be provided. The block is encoded as seven 32-bit words: Friedman et al. Standards Track [Page 25] =0C Internet-Draft RTCP XR May 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BT=3D7 | reserved | block length =3D 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | loss rate | discard rate | burst density | gap density | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | burst duration | gap duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | round trip delay | end system delay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signal level | noise level | RERL | Gmin | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R factor | ext. R factor | MOS-LQ | MOS-CQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RX config | reserved | JB nominal | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | JB maximum | JB abs max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block type (BT): 8 bits A VoIP Metrics Report Block is identified by the constant 7. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. block length: 16 bits The constant 8, in accordance with the definition of this field in Section 3. SSRC of source: 32 bits As defined in Section 4.1. The remaining fields are described in the following six sections: Packet Loss and Discard Metrics, Delay Metrics, Signal Related Metrics, Call Quality or Transmission Quality Metrics, Configuration Metrics, and Jitter Buffer Parameters. 4.7.1 Packet Loss and Discard Metrics It is very useful to distinguish between packets lost by the network and those discarded due to jitter. Both have equal effect on the quality of the voice stream however having separate counts helps Friedman et al. Standards Track [Page 26] =0C Internet-Draft RTCP XR May 2003 identify the source of quality degradation. These fields MUST be populated, and MUST be set to zero if no packets have been received. loss rate: 8 bits The fraction of RTP data packets from the source lost since the beginning of reception, expressed as a fixed point number with the binary point at the left edge of the field. This value is calculated by dividing the total number of packets lost (after the effects of applying any error protection such as FEC) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. The numbers of duplicated packets and discarded packets do not enter into this calculation. Since receivers cannot be required to maintain unlimited buffers, a receiver MAY categorize late-arriving packets as lost. The degree of lateness that triggers a loss SHOULD be significantly greater than that which triggers a discard. discard rate: 8 bits The fraction of RTP data packets from the source that have been discarded since the beginning of reception, due to late or early arrival, under-run or overflow at the receiving jitter buffer. This value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets discarded (excluding duplicate packet discards) by the total number of packets expected, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. 4.7.2 Burst Metrics A burst is a period during which a high proportion of packets are either lost or discarded due to late arrival. A burst is defined, in terms of a value Gmin, as a longest sequence that (a) starts with a lost or discarded packet, (b) does not contain any occurrences of Gmin or more consecutive received (and not discarded) packets, and (c) ends with a lost or discarded packet. A gap, informally, is a period of low packet losses and/or discards. Formally, a gap is defined as any of the following: (a) the period from the start of an RTP session to the receipt time of the last received packet before the first burst, (b) the period from the end of the last burst to either the time of the report or the end of the RTP session, whichever comes first, or (c) the period of time between two bursts. Friedman et al. Standards Track [Page 27] =0C Internet-Draft RTCP XR May 2003 For the purpose of determining if a lost or discarded packet near the start or end of an RTP session is within a gap or a burst it is assumed that the RTP session is preceded and followed by at least Gmin received packets, and that the time of the report is followed by at least Gmin received packets. A gap has the property that any lost or discarded packets within the gap must be preceded and followed by at least Gmin packets that were received and not discarded. This gives a maximum loss/discard rate within a gap of: 1 / (Gmin + 1). A Gmin value of 16 is RECOMMENDED as it results in gap characteristics that correspond to good quality (i.e. low packet loss rate, a minimum distance of 16 received packets between lost packets) and hence differentiates nicely between good and poor quality periods. For example, a 1 denotes a received, 0 a lost, and X a discarded packet in the following pattern covering 64 packets: 11110111111111111111111X111X1011110111111111111111111X111111111 |---------gap----------|--burst---|------------gap------------| The burst consists of the twelve packets indicated above, starting at a discarded packet and ending at a lost packet. The first gap starts at the beginning of the session and the second gap ends at the time of the report. If the packet spacing is 10 ms and the Gmin value is the recommended value of 16, the burst duration is 120 ms, the burst density 0.33, the gap duration 230 ms + 290 ms =3D 520 ms, and the gap density 0.04. This would result in reported values as follows (see field descriptions for semantics and details on how these are calculated): loss rate 12, which corresponds to 5% discard rate 12, which corresponds to 5% burst density 84, which corresponds to 33% gap density 10, which corresponds to 4% burst duration 120, value in milliseconds gap duration 520, value in milliseconds burst density: 8 bits The fraction of RTP data packets within burst periods since the beginning of reception that were either lost or discarded. This value is expressed as a fixed point number with the binary point Friedman et al. Standards Track [Page 28] =0C Internet-Draft RTCP XR May 2003 at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within burst periods by the total number of packets expected within the burst periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. This field MUST be populated and MUST be set to zero if no packets have been received. gap density: 8 bits The fraction of RTP data packets within inter-burst gaps since the beginning of reception that were either lost or discarded. The value is expressed as a fixed point number with the binary point at the left edge of the field. It is calculated by dividing the total number of packets lost or discarded (excluding duplicate packet discards) within gap periods by the total number of packets expected within the gap periods, multiplying the result of the division by 256, limiting the maximum value to 255 (to avoid overflow), and taking the integer part. This field MUST be populated and MUST be set to zero if no packets have been received. burst duration: 16 bits The mean duration, expressed in milliseconds, of the burst periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packets that mark the beginning and end of that period. It is equal to the timestamp of the end packet, plus the duration of the end packet, minus the timestamp of the beginning packet. If the actual values are not available, estimated values MUST be used. If there have been no burst periods, the burst duration value MUST be zero. gap duration: 16 bits The mean duration, expressed in milliseconds, of the gap periods that have occurred since the beginning of reception. The duration of each period is calculated based upon the packet that marks the end of the prior burst and the packet that marks the beginning of the subsequent burst. It is equal to the timestamp of the subsequent burst packet, minus the timestamp of the prior burst packet, plus the duration of the prior burst packet. If the actual values are not available, estimated values MUST be used. In the case of a gap that occurs at the beginning of reception, the sum of the timestamp of the prior burst packet and the duration of the prior burst packet are replaced by the reception start time. In the case of a gap that occurs at the end of reception, the timestamp of the subsequent burst packet is replaced by the reception end time. If there have been no Friedman et al. Standards Track [Page 29] =0C Internet-Draft RTCP XR May 2003 gap periods, the gap duration value MUST be zero. 4.7.3 Delay Metrics For the purpose of the following definitions, the RTP interface is the interface between the RTP instance and the voice application (i.e. FEC, de-interleaving, de-multiplexing, jitter buffer). For example, the time delay due to RTP payload multiplexing would be considered to be part of the voice application or end-system delay whereas delay due to multiplexing RTP frames within a UDP frame would be considered part of the RTP reported delay. This distinction is consistent with the use of RTCP for delay measurements. round trip delay: 16 bits The most recently calculated round trip time between RTP interfaces, expressed in milliseconds. This value MAY be measured using RTCP, the DLRR method defined in Section 4.5 of this document, in which case it is necessary to convert the units of measurement from NTP timestamp values to milliseconds, or other approaches. If RTCP is used then the reported delay value is the time of receipt of the most recent RTCP packet from source SSRC, minus the LSR (last SR) time reported in its SR (Sender Report), minus the DLSR (delay since last SR) reported in its SR. A non-zero LSR value is required in order to calculate round trip delay. A value of 0 is permissible, however this field MUST be populated as soon as a delay estimate is available. end system delay: 16 bits The most recently estimated end system delay, expressed in milliseconds. End system delay is defined as the sum of the total sample accumulation and encoding delay associated with the sending direction and the jitter buffer, decoding, and playout buffer delay associated with the receiving direction. This delay MAY be estimated or measured. This value SHOULD be provided in all VoIP metrics reports. If an implementation is unable to provide the data, the value 0 MUST be used. Note that the one way symmetric VoIP segment delay may be calculated from the round trip and end system delays as follows. If the round trip delay is denoted RTD and the end system delays associated with the two endpoints are ESD(A) and ESD(B) then: one way symmetric voice path delay =3D ( RTD + ESD(A) + ESD(B) ) / 2 4.7.4 Signal Related Metrics Friedman et al. Standards Track [Page 30] =0C Internet-Draft RTCP XR May 2003 The following metrics are intended to provide real time information related to the non-packet elements of the voice over IP system to assist with the identification of problems affecting call quality. The values identified below must be determined for the received audio signal. The information required to populate these fields may not be available in all systems, although it is strongly recommended that this data SHOULD be provided to support problem diagnosis. signal level: 8 bits The voice signal relative level is defined as the ratio of the signal level to a 0 dBm0 reference [10], expressed in decibels as a signed integer in two's complement form. This is measured only for packets containing speech energy. The intent of this metric is not to provide a precise measurement of the signal level but to provide a real time indication that the signal level may be excessively high or low. signal level =3D 10 Log10 ( rms talkspurt power (mW) ) A value of 127 indicates that this parameter is unavailable. Typical values should be generally in the -15 to -20 dBm range. noise level: 8 bits The noise level is defined as the ratio of the silent period background noise level to a 0 dBm0 reference, expressed in decibels as a signed integer in two's complement form. noise level =3D 10 Log10 ( rms silence power (mW) ) A value of 127 indicates that this parameter is unavailable. residual echo return loss (RERL): 8 bits The residual echo return loss value may be measured directly by the VoIP end system's echo canceller or may be estimated by adding the echo return loss (ERL) and echo return loss enhancement (ERLE) values reported by the echo canceller. RERL(dB) =3D ERL (dB) + ERLE (dB) In the case of a VoIP gateway the source of echo is typically line echo that occurs at 2-4 wire conversion points in the network. This can be in the 8-12 dB range. A line echo canceler can provide an ERLE of 30 dB or more and hence reduce this to 40-50 dB. In the case of an IP phone this could be acoustic coupling between handset speaker and microphone or residual acoustic echo from speakerphone operation, and may more correctly be termed terminal coupling loss (TCL). A typical handset would result in 40-50 dB of echo loss due to acoustic Friedman et al. Standards Track [Page 31] =0C Internet-Draft RTCP XR May 2003 feedback. Examples: - IP gateway connected to circuit switched network with 2 wire loop. Without echo cancellation, typical 2-4 wire converter ERL of 12 dB. RERL =3D ERL + ERLE =3D 12 + 0 =3D 12 dB. - IP gateway connected to circuit switched network with 2 wire loop. With echo canceler that improves echo by 30 dB. RERL =3D ERL + ERLE =3D 12 + 30 =3D 42 dB. - IP phone with conventional handset. Acoustic coupling from handset speaker to microphone (terminal coupling loss) is typically 40 dB. RERL =3D TCL =3D 40 dB. If we denote the local end of the VoIP path as A and the remote end as B and if the sender loudness rating (SLR) and receiver loudness rating (RLR) are known for A (default values 8 dB and 2 dB respectively), then the echo loudness level at end A (talker echo loudness rating or TELR) is given by: TELR(A) =3D SRL(A) + ERL(B) + ERLE(B) + RLR(A) TELR(B) =3D SRL(B) + ERL(A) + ERLE(A) + RLR(B) Hence in order to incorporate echo into a voice quality estimate at the A end of a VoIP connection it is desirable to send the ERL + ERLE value from B to A using a format such as RTCP XR. Echo related information may not be available in all VoIP end systems. As echo does have a significant effect on conversational quality it is recommended that estimated values for echo return loss and terminal coupling loss be provided (if sensible estimates can be reasonably determined). Typical values for end systems are given below to provide guidance: - IP Phone with handset: typically 45 dB. - PC softphone or speakerphone: extremely variable, consider reporting "undefined" (127). - IP gateway with line echo canceller: typically has ERL and ERLE available. - IP gateway without line echo canceller: frequently a source of Friedman et al. Standards Track [Page 32] =0C Internet-Draft RTCP XR May 2003 echo related problems, consider reporting either a low value (12 dB) or "undefined" (127). Gmin See Configuration Parameters (Section 4.7.6, below). 4.7.5 Call Quality or Transmission Quality Metrics The following metrics are direct measures of the call quality or transmission quality, and incorporate the effects of codec type, packet loss, discard, burstiness, delay etc. These metrics may not be available in all systems however SHOULD be provided in order to support problem diagnosis. R factor: 8 bits The R factor is a voice quality metric describing the segment of the call that is carried over this RTP session. It is expressed as an integer in the range 0 to 100, with a value of 94 corresponding to "toll quality" and values of 50 or less regarded as unusable. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3]. A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. ext. R factor: 8 bits The external R factor is a voice quality metric describing the segment of the call that is carried over a network segment external to the RTP segment, for example a cellular network. Its values are interpreted in the same manner as for the RTP R factor. This metric is defined as including the effects of delay, consistent with ITU-T G.107 [6] and ETSI TS 101 329-5 [3], and relates to the outward voice path from the Voice over IP termination for which this metrics block applies. A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. Note that an overall R factor may be estimated from the RTP segment R factor and the external R factor, as follows: R total =3D RTP R factor + ext. R factor - 94 MOS-LQ: 8 bits The estimated mean opinion score for listening quality (MOS-LQ) Friedman et al. Standards Track [Page 33] =0C Internet-Draft RTCP XR May 2003 is a voice quality metric on a scale from 1 to 5, in which 5 represents excellent and 1 represents unacceptable. This metric is defined as not including the effects of delay and can be compared to MOS scores obtained from listening quality (ACR) tests. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10. For example, a value of 35 would correspond to an estimated MOS score of 3.5. A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. MOS-CQ: 8 bits The estimated mean opinion score for conversational quality (MOS-CQ) is defined as including the effects of delay and other effects that would affect conversational quality. The metric may be calculated by converting an R factor determined according to ITU-T G.107 [6] or ETSI TS 101 329-5 [3] into an estimated MOS using the equation specified in G.107. It is expressed as an integer in the range 10 to 50, corresponding to MOS x 10, as for MOS-LQ. A value of 127 indicates that this parameter is unavailable. Values other than 127 and the valid range defined above MUST not be sent and MUST be ignored by the receiving system. 4.7.6 Configuration Parameters Gmin: 8 bits The gap threshold. This field contains the value used for this report block to determine if a gap exists. The recommended value of 16 corresponds to a burst period having a minimum density of 6.25% of lost or discarded packets, which may cause noticeable degradation in call quality; during gap periods, if packet loss or discard occurs, each lost or discarded packet would be preceded by and followed by a sequence of at least 16 received non-discarded packets. Note that lost or discarded packets that occur within Gmin packets of a report being generated may be reclassified as being part of a burst or gap in later reports. ETSI TS 101 329-5 [3] defines a computationally efficient algorithm for measuring burst and gap density using a packet loss/discard event driven approach. This algorithm is reproduced in Appendix A.2 of the present document. Gmin MUST not be zero and MUST be provided and MUST remain constant across VoIP Metrics report blocks for the duration of the RTP session. receiver configuration byte (RX config): 8 bits This byte consists of the following fields: Friedman et al. Standards Track [Page 34] =0C Internet-Draft RTCP XR May 2003 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |PLC|JBA|JB rate| +-+-+-+-+-+-+-+-+ packet loss concealment (PLC): 2 bits Standard (11) / enhanced (10) / disabled (01) / unspecified (00). When PLC =3D 11 then a simple replay or interpolation algorithm is being used to fill-in the missing packet; this approach is typically able to conceal isolated lost packets at low packet loss rates. When PLC =3D 10 then an enhanced interpolation algorithm is being used; algorithms of this type are able to conceal high packet loss rates effectively. When PLC =3D 01 then silence is being inserted in place of lost packets. When PLC =3D 00 then no information is available concerning the use of PLC, however for some codecs this may be inferred. jitter buffer adaptive (JBA): 2 bits Adaptive (11) / non-adaptive (10) / reserved (01)/ unknown (00). When the jitter buffer is adaptive then its size is being dynamically adjusted to deal with varying levels of jitter. When non-adaptive, the jitter buffer size is maintained at a fixed level. When either adaptive or non- adaptive modes are specified then the jitter buffer size parameters below MUST be specified. jitter buffer rate (JB rate): 4 bits J =3D adjustment rate (0-15). This represents the implementation specific adjustment rate of a jitter buffer in adaptive mode. This parameter is defined in terms of the approximate time taken to fully adjust to a step change in peak to peak jitter from 30 ms to 100 ms such that: adjustment time =3D 2 * J * frame size (ms) This parameter is intended only to provide a guide to the degree of "aggressiveness" of a an adaptive jitter buffer and may be estimated. A value of 0 indicates that the adjustment time is unknown for this implementation. reserved: 8 bits This field is reserved for future definition. In the absence of such definition, the bits in this field MUST be set to zero and MUST be ignored by the receiver. 4.7.7 Jitter Buffer Parameters Friedman et al. Standards Track [Page 35] =0C Internet-Draft RTCP XR May 2003 The values reported in these fields SHOULD be the most recently obtained values at the time of reporting. jitter buffer nominal delay (JB nominal): 16 bits This is the current nominal jitter buffer delay in milliseconds, which corresponds to the nominal jitter buffer delay for packets that arrive exactly on time. This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer maximum delay (JB maximum): 16 bits This is the current maximum jitter buffer delay in milliseconds which corresponds to the earliest arriving packet that would not be discarded. In simple queue implementations this may correspond to the nominal size. In adaptive jitter buffer implementations this value may dynamically vary up to JB abs max (see below). This parameter MUST be provided for both fixed and adaptive jitter buffer implementations. jitter buffer absolute maximum delay (JB abs max): 16 bits This is the absolute maximum delay in milliseconds that the adaptive jitter buffer can reach under worst case conditions. If this value exceeds 65535 milliseconds then this field SHALL convey the value 65535. This parameter MUST be provided for adaptive jitter buffer implementations and its value MUST be set to JB maximum for fixed jitter buffer implementations. 5. SDP Signaling This section defines Session Description Protocol (SDP) [4] signaling for XR blocks that can be employed by applications that utilize SDP. This signaling is defined to be used either by applications that implement the SDP Offer/Answer model [8] or by applications that use SDP to describe media and transport configurations in connection with such protocols as the Session Announcement Protocol (SAP) [15] or the Real Time Streaming Protocol (RTSP) [17]. There exist other potential signaling methods, which are not defined here. The XR blocks MAY be used without prior signaling. This is consistent with the rules governing other RTCP packet types, as described in [9]. An example in which signaling would not be used is an application that always requires the use of one or more XR blocks. However for applications that are configured at session initiation, the use of some type of signaling is recommended. Note that, although the use of SDP signaling for XR blocks may be optional, if used it MUST be used as defined here. If SDP signaling is used in an environment where XR blocks are only implemented by some fraction of the participants, the ones not implementing the XR Friedman et al. Standards Track [Page 36] =0C Internet-Draft RTCP XR May 2003 blocks will ignore the SDP attribute. 5.1 The SDP Attribute This section defines one new SDP attribute "rtcp-xr" that can be used to signal participants in a media session that they should use the specified XR blocks. This attribute can be easily extended in the future with new parameters to cover any new report blocks. The RTCP XR blocks SDP attribute is defined below in Augmented Backus-Naur Form (ABNF) [2]. It is both a session and a media level attribute. When specified at session level, it applies to all media level blocks in the session. Any media level specification MUST replace a session level specification, if one is present, for that media block. rtcp-xr-attrib =3D "a=3D" "rtcp-xr" ":" [xr-format *(SP xr-format)] CR= LF xr-format =3D pkt-loss-rle / pkt-dup-rle / pkt-rcpt-times / rcvr-rtt / stat-summary / voip-metrics / format-ext pkt-loss-rle =3D "pkt-loss-rle" ["=3D" max-size] pkt-dup-rle =3D "pkt-dup-rle" ["=3D" max-size] pkt-rcpt-times =3D "pkt-rcpt-times" ["=3D" max-size] rcvr-rtt =3D "rcvr-rtt" "=3D" rcvr-rtt-mode [":" max-size] rcvr-rtt-mode =3D "all" / "sender" stat-summary =3D "stat-summary" ["=3D" stat-flag *("," stat-flag)] stat-flag =3D "loss" / "dup" / "jitt" / "TTL" / "HL" voip-metrics =3D "voip-metrics" max-size =3D 1*DIGIT ; maximum block size in octets DIGIT =3D %x30-39 format-ext =3D non-ws-string non-ws-string =3D 1*(%x21-FF) CRLF =3D %d13.10 Friedman et al. Standards Track [Page 37] =0C Internet-Draft RTCP XR May 2003 The "rtcp-xr" attribute contains zero, one, or more XR block related parameters. Each parameter signals functionality for an XR block, or a group of XR blocks. The attribute is extensible so that parameters can be defined for any future XR block (and a parameter should be defined for every future block). Each "rtcp-xr" parameter belongs to one of two categories. The first category, the unilateral parameters, are for report blocks that simply report on the RTP stream and related metrics. The second category, collaborative parameters, are for XR blocks that involve actions by more than one party in order to carry out their functions. Round trip time (RTT) measurement is an example of collaborative functionality. An RTP data packet receiver sends a Receiver Reference Time Report Block (Section 4.4). A participant that receives this block sends a DLRR Report Block (Section 4.5) in response, allowing the receiver to calculate its RTT to that participant. As this example illustrates, collaborative functionality may be implemented by two or more different XR blocks. The collaborative functionality of several XR blocks may be governed by a single "rtcp-xr" parameter. For the unilateral category, this document defines the following parameters. The parameter names and their corresponding XR formats are as follows: Parameter name XR block (block type and name) -------------- ------------------------------------ pkt-loss-rle 1 Loss RLE Report Block pkt-dup-rle 2 Duplicate RLE Report Block pkt-rcpt-times 3 Packet Receipt Times Report Block stat-summary 6 Statistics Summary Report Block voip-metrics 7 VoIP Metrics Report Block The "pkt-loss-rle", "pkt-dup-rle", and "pkt-rcpt-times" parameters MAY specify an integer value. This value indicates the largest size the whole report block SHOULD have in octets. This shall be seen as an indication that thinning shall be applied if necessary to meet the target size. The "stat-summary" parameter contains a list indicating which fields SHOULD be included in the Statistics Summary report blocks that are sent. The list is a comma separated list, containing one or more field indicators. The space character (0x20) SHALL NOT be present within the list. Field indicators represent the flags defined in section 4.6. The field indicators and their respective flags are as follows: Friedman et al. Standards Track [Page 38] =0C Internet-Draft RTCP XR May 2003 Indicator Flag --------- --------------------------- loss loss report flag (L) dup duplicate report flag (D) jitt jitter flag (J) TTL TTL or Hop Limit flag (ToH) HL TTL or Hop Limit flag (ToH) For "loss", "dup", and "jitt", the presence of the indicator indicates that the corresponding flag should be set to 1 in the Statistics Summary report blocks that are sent. The presence of "TTL" indicates that the corresponding flag should be set to 1. The presence of "HL" indicates that the corresponding flag should be set to 2. The indicators "TTL" and "HL" MUST NOT be signaled together. Blocks in the collaborative category are classified as initiator blocks or response blocks. Signaling SHOULD indicate which participants are required to respond to the initiator block. A party that wishes to receive response blocks from those participants can trigger this by sending an initiator block. The collaborative category currently consists only of one functionality, namely the RTT measurement mechanism for RTP data receivers. The collective functionality of the Receiver Reference Time Report Block and DLRR Report Block is represented by the "rcvr- rtt" parameter. This parameter takes as its arguments a mode value and, optionally, a maximum size for the DLRR report block. The mode value "all" indicates that both RTP data senders and data receivers MAY send DLRR blocks, while the mode value "sender" indicates that only active RTP senders MAY send DLRR blocks, i.e. non RTP senders SHALL NOT send DLRR blocks. If a maximum size in octets is included, any DLRR Report Blocks that are sent SHALL NOT exceed the specified size. If size limitations mean that a DLRR Report Block sender cannot report in one block upon all participants from which it has received a Receiver Reference Time Report Block then it SHOULD report on participants in a round robin fashion across several report intervals. The "rtcp-xr" attributes parameter list MAY be empty. This is useful in cases in which an application needs to signal that it understands the SDP signaling but does not wish to avail itself of XR functionality. For example, an application in a SIP controlled session could signal that it wishes to stop using all XR blocks by removing all applicable SDP parameters in a re-INVITE message that it sends. If XR blocks are not to be used at all from the beginning of a session, it is RECOMMENDED that the "rtcp-xr" attribute not be supplied at all. Friedman et al. Standards Track [Page 39] =0C Internet-Draft RTCP XR May 2003 When the "rtcp-xr" attribute is present, participants SHOULD NOT send XR blocks other than the ones indicated by the parameters. This means that inclusion of a "rtcp-xr" attribute without any parameters tells a participant that it SHOULD NOT send any XR blocks at all. The purpose is to conserve bandwidth. This is especially important when collaborative parameters are applied to a large multicast group: the sending of an initiator block could potentially trigger responses from all participants. There are, however, contexts in which it makes sense to send an XR block in the absence of a parameter signaling its use. For instance, an application might be designed so as to send certain report blocks without negotiation, while using SDP signaling to negotiate the use of other blocks. 5.2 Usage in Offer/Answer In the Offer/Answer context [8], the interpretation of SDP signaling for XR packets depends upon the direction attribute that is signaled: "recvonly", "sendrecv", or "sendonly" [4]. If no direction attribute is supplied then "sendrecv" is assumed. This section applies only to unicast media streams, except where noted. Discussion of unilateral parameters is followed by discussion of collaborative parameters in this section. For "sendonly" and "sendrecv" media stream offers that specify unilateral "rtcp-xr" attribute parameters, the answerer SHOULD send the corresponding XR blocks. For "sendrecv" offers, the answerer MAY include the "rtcp-xr" attribute in its response, and specify any unilateral parameters in order to request that the offerer send the corresponding XR blocks. The offerer SHOULD send these blocks. For "recvonly" media stream offers, the offerer's use of the "rtcp- xr" attribute in connection with unilateral parameters indicates that the offerer is capable of sending the corresponding XR blocks. If the answerer responds with an "rtcp-xr" attribute, the offerer SHOULD send XR blocks for each specified unilateral parameter that was in its offer. For multicast media streams, the inclusion of an "rtcp-xr" attribute with unilateral parameters means that every media recipient SHOULD send the corresponding XR blocks. An SDP offer with a collaborative parameter declares the offerer capable of receiving the corresponding initiator and replying with the appropriate responses. For example, an offer that specifies the "rcvr-rtt" parameter means that the offerer is prepared to receive Receiver Reference Time Report Blocks and to send DLRR Report Blocks. An offer of a collaborative parameter means that the answerer MAY send the initiator, and, having received the initiator, the offerer Friedman et al. Standards Track [Page 40] =0C Internet-Draft RTCP XR May 2003 SHOULD send the responses. There are exceptions to the rule that an offerer of a collaborative parameter should send responses. For instance, the collaborative parameter might specify a mode that excludes the offerer. Or congestion control or maximum transmission unit considerations might militate against the offerer's response. By including a collaborative parameter in its answer, the answerer declares its ability to receive initiators and to send responses. The offerer MAY then send initiators, to which the answerer SHOULD reply with responses. As for the offer of a collaborative parameter, there are exceptions to the rule that the answerer should reply. When making an SDP offer of a collaborative parameter for a multicast media stream, the offerer SHOULD specify which participants are to respond to a received initiator. A participant that is not specified SHOULD NOT send responses. Otherwise, undue bandwidth might be consumed. The offer indicates that each participant that is specified SHOULD respond if it receives an initiator. It also indicates that a specified participant MAY send an initiator block. An SDP answer for a multicast media stream SHOULD include all collaborative parameters that are present in the offer and that are supported by the answerer. It SHOULD NOT include any collaborative parameter that is absent from the offer. If a participant receives an SDP offer and understands the "rtcp-xr" attribute but does not wish to implement XR functionality offered, its answer SHOULD include an "rtcp-xr" attribute without parameters. By doing so, the party declares that at a minimum that it is capable of understanding the signaling. 5.3 Usage Outside of Offer/Answer SDP can be employed outside of the Offer/Answer context, for instance for multimedia sessions that are announced through the Session Announcement Protocol (SAP) [15], or streamed through the Real Time Streaming Protocol (RTSP) [17]. The signaling model is simpler, as the sender does not negotiate parameters, but the functionality that is expected from specifying the "rtcp-xr" attribute is the same as in Offer/Answer. When a unilateral parameter is specified for the "rtcp-xr" attribute associated with a media stream, the receiver of that stream SHOULD send the corresponding XR block. When a collaborative parameter is specified, only the participants indicated by the mode value in the collaborative parameter are concerned. Each such participant that Friedman et al. Standards Track [Page 41] =0C Internet-Draft RTCP XR May 2003 receives an initiator block SHOULD send the corresponding response block. Each such participant MAY also send initiator blocks. 6. IANA Considerations This document defines a new RTCP packet type, the Extended Report (XR) type, within the existing Internet Assigned Numbers Authority (IANA) registry of RTP RTCP Control Packet Types. This document also defines a new IANA registry: the registry of RTCP XR Block Types. Within this new registry, this document defines an initial set of seven block types and describes how the remaining types are to be allocated. Further, this document defines a new SDP attribute, "rtcp-xr", within the existing IANA registry of SDP Parameters. It defines a new IANA registry, the registry of RTCP XR SDP Parameters, and an initial set of six parameters, and describes how additional parameters are to be allocated. 6.1 XR Packet Type The XR packet type defined by this document is registered with the IANA as packet type 207 in the registry of RTP RTCP Control Packet types (PT). 6.2 RTCP XR Block Type Registry This document creates an IANA registry called the RTCP XR Block Type Registry to cover the name space of the Extended Report block type (BT) field specified in Section 3. The BT field contains eight bits, allowing 256 values. The RTCP XR Block Type Registry is to be managed by the IANA according to the Specification Required policy of RFC 2434 [7]. Future specifications SHOULD attribute block type values in strict numeric order following the values attributed in this document: BT name -- ---- 1 Loss RLE Report Block 2 Duplicate RLE Report Block 3 Packet Receipt Times Report Block 4 Receiver Reference Time Report Block 5 DLRR Report Block 6 Statistics Summary Report Block 7 VoIP Metrics Report Block Friedman et al. Standards Track [Page 42] =0C Internet-Draft RTCP XR May 2003 The BT value 255 is reserved for future extensions. Furthermore, future specifications SHOULD avoid the value 0. Doing so facilitates packet validity checking, since an all-zeros field might commonly be found in an ill-formed packet. Any registration MUST contain the following information: - Contact information of the one doing the registration, including at least name, address, and email. - The format of the block type being registered, consistent with the extended report block format described in Section 3. - A description of what the block type represents and how it shall be interpreted, detailing this information for each of its fields. 6.3 The "rtcp-xr" SDP Attribute This SDP attribute "rtcp-xr" defined by this document is registered with the IANA registry of SDP Parameters as follows: SDP Attribute ("att-field"): Attribute name: rtcp-xr Long form: RTP Control Protocol Extended Report Parameters Type of name: att-field Type of attribute: session and media level Subject to charset: no Purpose: see Section 5 of this document Reference: this document Values: see this document and registrations below The attribute has an extensible parameter field and therefore a registry for these parameters is required. This document creates an IANA registry called the RTCP XR SDP Parameters Registry. It contains the six parameters defined in Section 5.1: "pkt-loss-rle", "pkt-dup-rle", "pkt-rcpt-times", "stat-summary", "voip-metrics", and "recv-rtt". Additional parameters are to be added to this registry in accordance with the Specification Required policy of RFC 2434 [7]. Any registration MUST contain the following information: - Contact information of the one doing the registration, including at least name, address, and email. - An Augmented Backus-Naur Form (ABNF) [2] definition of the Friedman et al. Standards Track [Page 43] =0C Internet-Draft RTCP XR May 2003 parameter, in accordance with the "format-ext" definition of Section 5.1. - A description of what the parameter represents and how it shall be interpreted, both normally and in Offer/Answer. 7. Security Considerations This document extends the RTCP reporting mechanism. The security considerations that apply to RTCP reports [9, Appendix B] also apply to XR reports. This section details the additional security considerations that apply to the extensions. The extensions introduce heightened confidentiality concerns. Standard RTCP reports contain a limited number of summary statistics. The information contained in XR reports is both more detailed and more extensive (covering a larger number of parameters). The per- packet report blocks and the VoIP Metrics Report Block provide examples. The per-packet information contained in Loss RLE, Duplicate RLE, and Packet Receipt Times Report Blocks facilitates multicast inference of network characteristics (MINC) [11]. Such inference can reveal the gross topology of a multicast distribution tree, as well as parameters, such as the loss rates and delays, along paths between branching points in that tree. Such information might be considered sensitive to autonomous system administrators. The VoIP Metrics Report Block provides information on the quality of ongoing voice calls. Though such information might be carried in application specific format in standard RTP sessions, making it available in a standard format here makes it more available to potential eavesdroppers. No new mechanisms are introduced in this document to ensure confidentiality. Encryption procedures, such as those being suggested for a Secure RTCP (SRTCP) [12] at the time that this document was written, can be used when confidentiality is a concern to end hosts. Given that RTCP traffic can be encrypted by the end hosts, autonomous systems must be prepared for the fact that certain aspects of their network topology can be revealed. Any encryption or filtering of XR report blocks entails a loss of monitoring information to third parties. For example, a network that establishes a tunnel to encrypt VoIP Report Blocks denies that information to the service providers traversed by the tunnel. The service providers cannot then monitor or respond to the quality of the VoIP calls that they carry, potentially creating problems for the Friedman et al. Standards Track [Page 44] =0C Internet-Draft RTCP XR May 2003 network's users. As a default, XR packets should not be encrypted or filtered. The extensions also make certain denial of service attacks easier. This is because of the potential to create RTCP packets much larger than average with the per packet reporting capabilities of the Loss RLE, Duplicate RLE, and Timestamp Report Blocks. Because of the automatic bandwidth adjustment mechanisms in RTCP, if some session participants are sending large RTCP packets, all participants will see their RTCP reporting intervals lengthened, meaning they will be able to report less frequently. To limit the effects of large packets, even in the absence of denial of service attacks, applications SHOULD place an upper limit on the size of the XR report blocks they employ. The "thinning" techniques described in Section 4.1 permit the packet-by-packet report blocks to adhere to a predefined size limit. A. Algorithms A.1 Sequence Number Interpretation This the algorithm suggested by Section 4.1 for keeping track of the sequence numbers from a given sender. It implements the accounting practice required for the generation of Loss RLE Report Blocks. This algorithm keeps track of 16 bit sequence numbers by translating them into a 32 bit sequence number space. The first packet received from a source is considered to have arrived roughly in the middle of that space. Each packet that follows is placed either ahead or behind the prior one in this 32 bit space, depending upon which choice would place it closer (or, in the event of a tie, which choice would not require a rollover in the 16 bit sequence number). // The reference sequence number is an extended sequence number // that serves as the basis for determining whether a new 16 bit // sequence number comes earlier or later in the 32 bit sequence // space. u_int32 _src_ref_seq; bool _uninitialized_src_ref_seq; // Place seq into a 32-bit sequence number space based upon a // heuristic for its most likely location. u_int32 extend_seq(const u_int16 seq) { u_int32 extended_seq, seq_a, seq_b, diff_a, diff_b; if(_uninitialized_src_ref_seq) { // This is the first sequence number received. Place Friedman et al. Standards Track [Page 45] =0C Internet-Draft RTCP XR May 2003 // it in the middle of the extended sequence number // space. _src_ref_seq =3D seq | 0x80000000u; _uninitialized_src_ref_seq =3D false; extended_seq =3D _src_ref_seq; } else { // Prior sequence numbers have been received. // Propose two candidates for the extended sequence // number: seq_a is without wraparound, seq_b with // wraparound. seq_a =3D seq | (_src_ref_seq & 0xFFFF0000u); if(_src_ref_seq < seq_a) { seq_b =3D seq_a - 0x00010000u; diff_a =3D seq_a - _src_ref_seq; diff_b =3D _src_ref_seq - seq_b; } else { seq_b =3D seq_a + 0x00010000u; diff_a =3D _src_ref_seq - seq_a; diff_b =3D seq_b - _src_ref_seq; } // Choose the closer candidate. If they are equally // close, the choice is somewhat arbitrary: we choose // the candidate for which no rollover is necessary. if(diff_a < diff_b) { extended_seq =3D seq_a; } else { extended_seq =3D seq_b; } // Set the reference sequence number to be this most // recently-received sequence number. _src_ref_seq =3D extended_seq; } // Return our best guess for a 32-bit sequence number that // corresponds to the 16-bit number we were given. return extended_seq; } A.2 Example Burst Packet Loss Calculation. This is an algorithm for measuring the burst characteristics for the VoIP Metrics Report Block (Section 4.7). The algorithm, which has Friedman et al. Standards Track [Page 46] =0C Internet-Draft RTCP XR May 2003 been verified against a working implementation for correctness, is reproduced from ETSI TS 101 329-5 [3]. The algorithm as described here takes precedence over any change that might eventually be made to the algorithm in future ETSI documents. This algorithm is event driven and hence extremely computationally efficient. Given the following definition of states: state 1 =3D received a packet during a gap state 2 =3D received a packet during a burst state 3 =3D lost a packet during a burst state 4 =3D lost an isolated packet during a gap The "c" variables below correspond to state transition counts, i.e. c14 is the transition from state 1 to state 4. It is possible to infer one of a pair of state transition counts to an accuracy of 1 which is generally sufficient for this application. "pkt" is the count of packets received since the last packet was declared lost or discarded and "lost" is the number of packets lost within the current burst. "packet_lost" and "packet_discarded" are Boolean variables that indicate if the event that resulted in this function being invoked was a lost or discarded packet. if(packet_lost) { loss_count++; } if(packet_discarded) { discard_count++; } if(!packet_lost && !packet_discarded) { pkt++; } else { if(pkt >=3D gmin) { if(lost =3D=3D 1) { c14++; } else { c13++; } lost =3D 1; c11 +=3D pkt; } Friedman et al. Standards Track [Page 47] =0C Internet-Draft RTCP XR May 2003 else { lost++; if(pkt =3D=3D 0) { c33++; } else { c23++; c22 +=3D (pkt - 1); } } pkt =3D 0; } At each reporting interval the burst and gap metrics can be calculated as follows. // Calculate additional transition counts. c31 =3D c13; c32 =3D c23; ctotal =3D c11 + c14 + c13 + c22 + c23 + c31 + c32 + c33; // Calculate burst and densities. p32 =3D c32 / (c31 + c32 + c33); if((c22 + c23) < 1) { p23 =3D 1; } else { p23 =3D 1 - c22/(c22 + c23); } burst_density =3D 256 * p23 / (p23 + p32); gap_density =3D 256 * c14 / (c11 + c14); // Calculate burst and gap durations in ms m =3D frameDuration_in_ms * framesPerRTPPkt; gap_length =3D (c11 + c14 + c13) * m / c13; burst_length =3D ctotal * m / c13 - lgap; /* calculate loss and discard rates */ loss_rate =3D 256 * loss_count / ctotal; discard_rate =3D 256 * discard_count / ctotal; Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it Friedman et al. Standards Track [Page 48] =0C Internet-Draft RTCP XR May 2003 has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP 11 [5]. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgments We thank the following people: Colin Perkins, Steve Casner, and Henning Schulzrinne for their considered guidance; Sue Moon for helping foster collaboration between the authors; Mounir Benzaid for Friedman et al. Standards Track [Page 49] =0C Internet-Draft RTCP XR May 2003 drawing our attention to the reporting needs of MLDA; Dorgham Sisalem and Adam Wolisz for encouraging us to incorporate MLDA block types; and Jose Rey for valuable review of the SDP Signaling section. Contributors The following people are the authors of this document: Kevin Almeroth, UCSB Ramon Caceres, ShieldIP Alan Clark, Telchemy Robert Cole, AT&T Labs Nick Duffield, AT&T Labs-Research Timur Friedman, Paris 6 Kaynam Hedayat, Brix Networks Kamil Sarac, UT Dallas Magnus Westerlund, Ericsson The principal people to contact regarding the individual report blocks described in this document are as follows: sec. report block principal contributors ---- ------------ ---------------------- 4.1 Loss RLE Report Block Friedman, Caceres, Duffield 4.2 Duplicate RLE Report Block Friedman, Caceres, Duffield 4.3 Packet Receipt Times Report Block Friedman, Caceres, Duffield 4.4 Receiver Reference Time Report Block Friedman 4.5 DLRR Report Block Friedman 4.6 Statistics Summary Report Block Almeroth, Sarac 4.7 VoIP Metrics Report Block Clark, Cole, Hedayat The principal person to contact regarding the SDP signaling described in this document is Magnus Westerlund. Authors' Addresses Kevin Almeroth Department of Computer Science University of California Santa Barbara, CA 93106 USA Ramon Caceres ShieldIP, Inc. 11 West 42nd Street, 31st Floor New York, NY 10036 USA Friedman et al. Standards Track [Page 50] =0C Internet-Draft RTCP XR May 2003 Alan Clark Telchemy Incorporated 3360 Martins Farm Road, Suite 200 Suwanee, GA 30024 USA Tel: +1 770 614 6944 Fax: +1 770 614 3951 Robert Cole AT&T Labs 330 Saint Johns Street, 2nd Floor Havre de Grace, MD 21078 USA Tel: +1 410 939 8732 Fax: +1 410 939 8732 Nick Duffield AT&T Labs-Research 180 Park Avenue, P.O. Box 971 Florham Park, NJ 07932-0971 USA Tel: +1 973 360 8726 Fax: +1 973 360 8050 Timur Friedman Universite Pierre et Marie Curie (Paris 6) Laboratoire LiP6-CNRS 8, rue du Capitaine Scott 75015 PARIS France Tel: +33 1 44 27 71 06 Fax: +33 1 44 27 74 95 Kaynam Hedayat Brix Networks 285 Mill Road Chelmsford, MA 01824 USA Tel: +1 978 367 5600 Fax: +1 978 367 5700 Kamil Sarac Department of Computer Science (ES 4.207) Eric Jonsson School of Engineering & Computer Science University of Texas at Dallas Richardson, TX 75083-0688 USA Tel: +1 972 883 2337 Fax: +1 972 883 2349 Friedman et al. Standards Track [Page 51] =0C Internet-Draft RTCP XR May 2003 Magnus Westerlund Ericsson Research, Corporate Unit Ericsson Radio Systems AB SE-164 80 Stockholm Sweden Tel: +46 8 404 82 87 Fax: +46 8 757 55 50 References The references are divided into normative references and non- normative references. Normative References [1] S. Bradner, "Key words for use in RFCs to indicate requirement levels," BCP 14, RFC 2119, IETF, March 1997. [2] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Engineering Task Force, November 1997. [3] ETSI, "Quality of Service (QoS) measurement methodologies," ETSI TS 101 329-5 V1.1.1 (2000-11), November 2000. [4] M. Handley, V. Jacobson, "SDP: Session Description Protocol", RFC 2327, Internet Engineering Task Force, April 1998. [5] R. Hovey and S. Bradner, "The Organizations Involved in the IETF Standards Process," best current practice BCP 11, RFC 2028, IETF, October 1996. [6] ITU-T, "The E-Model, a computational model for use in transmission planning," Recommendation G.107 (05/00), May 2000. [7] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," best current practice BCP 26, RFC 2434, IETF, October 1998. [8] J. Rosenberg, H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, Internet Engineering Task Force, June 2002. [9] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A transport protocol for real-time applications," RFC 1889, IETF, February 1996. [10] TIA/EIA-810-A Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones, December Friedman et al. Standards Track [Page 52] =0C Internet-Draft RTCP XR May 2003 2000. Non-Normative References [11] A. Adams, T. Bu, R. Caceres, N. G. Duffield, T. Friedman, J. Horowitz, F. Lo Presti, S. B. Moon, V. Paxson, and D. Towsley, "The Use of End-to-End Multicast Measurements for Characterizing Internal Network Behavior," IEEE Communications Magazine, May 2000. [12] Baugher, McGrew, Oran, Blom, Carrara, Naslund, and Norrman, "The Secure Real-time Transport Protocol," Internet-Draft draft-ietf-avt- srtp-05.txt, June 2002. Note: this is is a work in progress. [13] R. Caceres, N. G. Duffield, and T. Friedman, "Impromptu measurement infrastructures using RTP," Proc. IEEE Infocom 2002. [14] A. D. Clark, "Modeling the Effects of Burst Packet Loss and Recency on Subjective Voice Quality," Proc. IP Telephony Workshop 2001. [15] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol", RFC 2974, Internet Engineering Task Force, October 2000. [16] J. Reynolds, "Assigned Numbers: RFC 1700 is Replaced by an On- line Database", RFC 3232, IETF, January 2002. [17] H. Schulzrinne, R. Lanphier, and A. Rao, "Real time streaming protocol (RTSP)," RFC 2326, Internet Engineering Task Force, Apr. 1998. [18] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Control Framework for Heterogeneous Multicast Environments", Proc. IWQoS 2000. Friedman et al. Standards Track [Page 53] =0C --------------Boundary-00=_8QL5IB8PQ6KXBLPXF656-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 19 21:41:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12499 for ; Mon, 19 May 2003 21:41:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4K1AvK04023 for avt-archive@odin.ietf.org; Mon, 19 May 2003 21:10:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K1AYB04006; Mon, 19 May 2003 21:10:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K19iB03952 for ; Mon, 19 May 2003 21:09:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12473 for ; Mon, 19 May 2003 21:40:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Hw8U-0000Jv-00 for avt@ietf.org; Mon, 19 May 2003 21:41:50 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Hw8T-0000Js-00 for avt@ietf.org; Mon, 19 May 2003 21:41:49 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h4K1fvl21676 for avt@ietf.org; Mon, 19 May 2003 18:41:57 -0700 Date: Mon, 19 May 2003 18:41:57 -0700 From: John Lazzaro Message-Id: <200305200141.h4K1fvl21676@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] RTP MIDI normative I-D released ... Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, I submitted an update to the normative RTP MIDI I-D today, you can pick it up from my website as: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-rtp-midi.txt Note the old name (MWPP) has been discarded -- the new title of the I-D is "RTP Payload Format for MIDI", and the new MIME subtype and mpeg4-generic mode name is rtp-midi. I consider this release to be "almost Last Call". My "open issues" list has no items left on it, I believe the memo passes the ID-nits checks, and the document contains proposed solutions to the outstanding open issues contributed by MMA and IETF folks in the past few months. See the Change Log, now at the end of the memo. My plan going forward is: [1] Rewrite the TCP Framing I-D to reflect the San Francisco concerns, and resubmit as a -01.txt individual submission. [2] Rewrite the "RTP MIDI Implementation Guidelines" to reflect the new normative RTP MIDI I-D. [3] Formulate suggestions for draft-ietf-avt-rtcpssm-03.txt with respect to the RTCP "extended highest sequence number received" field, and either post them to the list or write a short I-D, depending on length. By then, the Vienna deadline will be approaching, and ideally, I'll have feedback from readers on the new normative document. If there are no show-stoppers, I'll probably do a light edit and resubmit a true "Last Call" in time for the Vienna deadline. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 20 02:08:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27009 for ; Tue, 20 May 2003 02:08:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4K5bRi21919 for avt-archive@odin.ietf.org; Tue, 20 May 2003 01:37:27 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K5aqB21346; Tue, 20 May 2003 01:36:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4K5ZKB21317 for ; Tue, 20 May 2003 01:35:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24316 for ; Tue, 20 May 2003 02:05:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19I0HQ-0001kp-00 for avt@ietf.org; Tue, 20 May 2003 02:07:20 -0400 Received: from www.route-explorer.org ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19I0HP-0001km-00 for avt@ietf.org; Tue, 20 May 2003 02:07:19 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h4K67dvW009122; Mon, 19 May 2003 23:07:40 -0700 (PDT) (envelope-from casner@acm.org) Date: Mon, 19 May 2003 23:08:27 -0700 (PDT) From: Stephen Casner To: Magnus Westerlund cc: IETF AVT WG Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt In-Reply-To: <3EC49291.2050209@era.ericsson.se> Message-ID: <20030519230757.U40866-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Magnus, > I have know further considered the interaction between the text written > in draft-ietf-avt-rtp-new-12 and draft-ietf-avt-rtcp-bw-5.txt. I think > there is two problems, one with each draft. > > - draft-ietf-avt-rtp-new-12: The algorithm in section 6.3.1 does not > match text declaring intention further up in the draft. This should be > resolved in some way. But it might be best to consider the RR and RS > modifiers. You are right, the text allowing the sender and receiver RTCP bandwidths to be modified as separate parameters was added in Section 6.2 without being addressed in 6.3.1. My only explanation is that these sections have two different authors. > - draft-ietf-avt-rtcp-bw-5.txt: This does not present any solution on > how to actually use the RR and RS in the RTCP report interval > calculations. I think it should to achieve consistent behavior. Also as > the presented RTP algorithm will not allow for turning of the receivers > report in cases where the number of senders are more than 1/4 of the > participants. I don't think this draft should say how to do the interval calculations since that is the province of the RTP spec itself. However, this draft should not cause confusion. It is reasonable to clarify the application of the 1/4 rule. There is a slightly bigger issue here. The 1/4 rule originated in RFC 1889 when the interval calculation was simpler and there was no option for changing the sender and receiver RTCP bandwidth allocations. The notion was that 25% of the RTCP bandwidth should be allocated to the senders so long as the number of senders was not more than 25% of the total participants. The fraction 1/4 was chosen after some amount of thought and analysis (1/8 was also considered) to give the right emphasis to senders without causing other participants to time out. Furthermore, those two 25%'s are supposed to be the same, such that there is no discontinuity as the number of senders crosses 25%. That is, if the number of senders is exactly 25% of the number of participants, the interval calculation produces the same result with and without the 1/4 rule. We have not adequately specified what the algorithm should be when RS and RR are changed from the default values. I had two use cases in mind: - setting RR to zero to turn off feedback (with all the caveats we have listed); - changing the ratio of RTCP bw to RTP bw, either lower because the RTP bw is a max value and the typical value will be much lower so a lower RTCP bw is appropriate, or higher because the RTP bw is very low and the control traffic is important enough to allocate more bw to it. In both of these cases, I had in mind that the RS:RR ratio would remain 1:3. Under those conditions, the 1/4 rule is still fine, perhaps with some clarification. However, if some application sets the RS:RR ratio to be 1:9, then what happens? If the senders share RS bw until their number increases to 25% of the participants, that means the senders get _less_ than their fair share of the overall RTCP bw when they number between 10% and 25% of the participants. That's not what we intended. The relevant text from draft-ietf-avt-rtp-new-12.txt is: The profile MAY further specify that the control traffic bandwidth may be divided into two separate session parameters for those participants which are active data senders and those which are not. Following the recommendation that 1/4 of the RTCP bandwidth be dedicated to data senders, the RECOMMENDED default values for these two parameters would be 1.25% and 3.75%, respectively. When the proportion of senders is greater than 1/4 of the participants, the senders get their proportion of the sum of these parameters. The second "1/4" is only valid when the sender bandwidth is 1/4 of the total. I suggest that this text be modified as follows: The profile MAY further specify that the control traffic bandwidth may be divided into two separate session parameters for those participants which are active data senders and those which are not; let us call the parameters S and R. Following the recommendation that 1/4 of the RTCP bandwidth be dedicated to data senders, the RECOMMENDED default values for S and R would be 1.25% and 3.75% of the session bandwidth, respectively. When the proportion of senders is greater than S/(S+R) of the participants, the senders get their proportion of the sum of these parameters. Do you (and other AVT readers) find this change acceptable? The RFC Editor might consider this a technical change that requires IESG approval. If you look at the rtcp_interval() function in A.7, the sender bandwidth fraction and the cutover fraction of senders as members are the same value, though it is implemented as a constant. If the sender fraction was set to 100%, then the non-senders would get no bandwidth. There are two problems: first, if there are no senders, then the non-senders get bandwidth. Perhaps the senders > 0 clause should be removed. Second, there is no protection for divide-by-zero in the case where non-senders get no bandwidth. As you say, the algorithm in 6.3.1 does not match the intended meaning when the RTCP bandwidth fractions are specified separately. I'm not entirely satisfied with the text you've provided, though. It is a lot more complicated than the code in A.7. The terms RS and RR are not defined; we need to be careful not to tie the RTP spec to SDP. I have to admit some concern here because we are also trying to get RFC numbers on an accelerated basis at the request of the ITU. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 20 18:50:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04549 for ; Tue, 20 May 2003 18:50:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KMGWT10297 for avt-archive@odin.ietf.org; Tue, 20 May 2003 18:16:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KMFjB10238; Tue, 20 May 2003 18:15:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KMEkB10162 for ; Tue, 20 May 2003 18:14:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04501 for ; Tue, 20 May 2003 18:47:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IFsH-0001UT-00 for avt@ietf.org; Tue, 20 May 2003 18:46:25 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 19IFsG-0001UQ-00 for avt@ietf.org; Tue, 20 May 2003 18:46:24 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.5) with ESMTP id h4KMlcTU020375 for ; Tue, 20 May 2003 15:47:38 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h4KMlPKN020134; Tue, 20 May 2003 15:47:25 -0700 (PDT) Message-Id: <4.3.1.1.20030520154104.00b5ca00@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 20 May 2003 15:46:36 -0700 To: avt@ietf.org From: Ross Finlayson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Examples of "audio/mpeg4-generic" other than non-interleaved "AAC-hbr"? Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , To date, every "audio/mpeg4-generic" RTSP/RTP stream that I've found on the Internet has used "mode=AAC-hbr", and with no interleaving. Does anyone know of any publically accessible "audio/mpeg4-generic" RTSP/RTP streams that use a different mode, and/or use interleaving? (I'd like to use these for testing some client software.) Ross. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 20 19:50:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06271 for ; Tue, 20 May 2003 19:50:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KNH3h15040 for avt-archive@odin.ietf.org; Tue, 20 May 2003 19:17:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KNGOB15011; Tue, 20 May 2003 19:16:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHp7B22604 for ; Tue, 20 May 2003 13:51:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24062 for ; Tue, 20 May 2003 14:24:12 -0400 (EDT) From: conf@uha.fr Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBlE-0007U5-00 for avt@ietf.org; Tue, 20 May 2003 14:22:52 -0400 Received: from ngc45.uha.fr ([194.167.107.45] helo=dnsinterne.uha.fr) by ietf-mx with esmtp (Exim 4.12) id 19IBlC-0007Tl-00 for avt@ietf.org; Tue, 20 May 2003 14:22:51 -0400 Received: from admpcsrv1.uha.fr (admpcsrv1.uha.fr [192.168.11.2]) by dnsinterne.uha.fr (8.11.6/8.11.0) with ESMTP id h4KGZbh25021; Tue, 20 May 2003 18:35:37 +0200 Received: from grtc2.uha.fr ([192.168.12.156]) by admpcsrv1.uha.fr (Lotus Domino Release 5.0.10) with ESMTP id 2003052018165795:214 ; Tue, 20 May 2003 18:16:57 +0200 Message-Id: <5.1.0.14.2.20030520181247.00b50f80@admpcsrv1.uha.fr> X-Sender: conf@admpcsrv1.uha.fr (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 20 May 2003 18:13:23 +0200 To: conf@uha.fr Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on ADMPCSRV1/SRV/COLMAR(Release 5.0.10 |March 22, 2002) at 20/05/2003 18:16:58, Serialize by Router on ADMPCSRV1/SRV/COLMAR(Release 5.0.10 |March 22, 2002) at 20/05/2003 18:29:48, Serialize complete at 20/05/2003 18:29:48 Content-Type: multipart/alternative; boundary="=====================_114097293==_.ALT" Subject: [AVT] CfP - ICN'2004 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --=====================_114097293==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable (* Our apologies if you receive this multiple times* ) CALL FOR PAPERS 3rd International Conference on Networking (ICN'04) March 1-4, 2004 Pointe-=E0-Pitre, Guadeloupe, French Caribbean http://conf.uha.fr/ICN04.html GENERAL INFORMATION The 2004 International Conference on Networking (ICN'04) is sponsored by=20 IEEE/Comsoc CSIM committee, IEEE/Computer and by IEE. ICN'04 is organized=20 by academic, research and industrial societies will be held from Monday=20 March 1, 2004 to Thursday March 4, 2004. In order to encourage closer interaction between academic and industrial=20 networking research communities, we solicit both academic research papers=20 and industrial contributions. The 3rd edition of ICN will be held in=20 Pointe-=E0-Pitre, Guadeloupe. ICN 2004 will offer tutorials, plenary=20 sessions, poster sessions, panels and exhibition opportunities. TOPICS OF SPECIAL INTEREST Topics of interest include, but are not limited to the following: Communications switching and routing Communications modelling Communications security Computer communications Multimedia and multicast communications Next Generation Network Network Management and control Quality of Service Wireless Communications (Satellite, WLL, 4G) Voice over IP Network, control and service architectures Network signalling Optical networking Distributed communications Traffic engineering Telecommunication networks architectures Performance evaluation, simulation Mobile networking and systems Applications and case studies Protocol design and evaluation MPLS, GMPLS These topics can be discussed in term of concepts, state of the art,=20 standards, implementations, running experiments and applications. INSTRUCTIONS FOR AUTHORS Mail four papers OR E-mail preferably in PDF format your original paper (6= =20 or 8 pages). All the manuscripts must be written in English. The top of the= =20 first page of each paper should include the title of the paper, authors'=20 name, position, address, telephone and fax numbers, e-mail of the author=20 responsible for correspondence and a list of four keywords. The deadline=20 for submission of all extended papers is September 10, 2003 with=20 notification of acceptance by October 10, 2003. Submission of camera-ready= =20 paper is by November 10, 2003. Authors of accepted papers will be invited to submit full-length=20 manuscripts for inclusion in the proceedings with ISBN. All hard copies papers should be sent to the following address: Pascal LORENZ University of Haute Alsace 34 rue du Grillenbreit 68008 Colmar, France Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)632630204 E-mail: lorenz@ieee.org Check our Web page at http://conf.uha.fr/ICN04.html for the latest=20 information concerning the conference. Best papers will be forwarded for consideration in a special issue of a=20 journal. TUTORIALS AND WORKSHOPS Tutorials and workshops provide overviews of current high interest topics.= =20 Proposals for half of full day tutorials are due by September 10, 2003. INTERNATIONAL ADVISORY COMMITTEE H. Abouaissa (France) - University of Haute Alsace R. Addie (Australia) - University of Southern Queensland K. Begain (UK) - University of Bradford B. Bing (USA) - Georgia Institute of Technology A. Brandwajn (USA) - University of California Santa Cruz P. Chemouil (France) France Telecom R&D J.P. Coudreuse (France) - Mitsubishi M. Devetsikiotis (USA) - North Carolina State University S. Fdida (France) - LIP6 N. Fonseca (Brazil) - University of Campinas E. Fulp (USA) - Wake Forest University B. Gavish (USA) - Vanderbilt University H. Guyennet (France) - University of Franche-Comte Z. Hulicki (Poland) - University of Cracow R. Israel (France) - IEEE A. Jajszczyk (Poland) - University of Mining & Metallurgy A. Jamalipour (Australia) - University of Sydney S. Jiang (Singapore) - National University of Singapore S. Karnouskos (Germany) - GMD FOKUS G. Kesidis (USA) Pennsylvania State University D. Khotimsky (USA) - Lucent Bell Labs D. Kofman (France) - ENST Paris S. Kota (USA) - Lockeed Martin D. Kouvatsos (UK) - University of Bradford S. Kumar (USA) - Ericsson G.S. Kuo (Taiwan) - National Central University F. Le Faucheur (France) - Cisco M. Lee (Korea) - Dongshin University P. Lorenz (France) - University of Haute Alsace Z. Mammeri (France) - University of Toulouse N. Mastorakis (Greece) - Military Institutions of University Education H. Mouftah (Canada) - Queen's University G. Omidyar (USA) - Computer Sciences Corp. M. Potts (Switzerland) - Martel G. Pujolle (France) - University of Paris 6 S. Rao (Switzerland) - Ascom A. Reid (UK) - British Telecom S. Ritzenthaler (France) - Alcatel P. Rolin (France) France Telecom R&D D. Sadok (Brazil) - Federal University of Pernambuco R. Saracco (Italy) - CSELT H. Tobiet (France) - NMG V.A. Villagra (Spain) - University of Madrid E. Vazquez Gallo (Spain) - University of Madrid O. Yang (Canada) - University of Ottawa IMPORTANT DATES Extended papers deadline September 10, 2003 Authors Notification: October 10, 2003 Camera ready, full papers due: November 10, 2003 --=====================_114097293==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (* Our apologies if you receive this multiple times* )

CALL FOR PAPERS
3rd International Conference on Networking (ICN'04)
March 1-4, 2004  Pointe-=E0-Pitre,
Guadeloupe, French Caribbean

http://conf.uha.fr/ICN04.html


GENERAL INFORMATION
The 2004 International Conference on Networking (ICN'04) is sponsored by IEEE/Comsoc CSIM committee, IEEE/Computer and by IEE. ICN'04 is organized by academic, research and industrial societies will be held from Monday March 1, 2004 to Thursday March 4, 2004.
In order to encourage closer interaction between academic and industrial networking research communities, we solicit both academic research papers and industrial contributions. The 3rd edition of ICN will be held in Pointe-=E0-Pitre, Guadeloupe. ICN 2004 will offer tutorials, plenary sessions, poster sessions, panels and exhibition opportunities.

TOPICS OF SPECIAL INTEREST
Topics of interest include, but are not limited to the following:

Communications switching and routing
Communications modelling
Communications security
Computer communications
Multimedia and multicast communications
Next Generation Network
Network Management and control
Quality of Service
Wireless Communications (Satellite, WLL, 4G)
Voice over IP
Network, control and service architectures
Network signalling
Optical networking
Distributed communications
Traffic engineering
Telecommunication networks architectures
Performance evaluation, simulation
Mobile networking and systems
Applications and case studies
Protocol design and evaluation
MPLS, GMPLS

These topics can be discussed in term of concepts, state of the art, standards, implementations, running experiments and applications.

INSTRUCTIONS FOR AUTHORS
Mail four papers OR E-mail preferably in PDF format your original paper (6 or 8 pages). All the manuscripts must be written in English. The top of the first page of each paper should include the title of the paper, authors' name, position, address, telephone and fax numbers, e-mail of the author responsible for correspondence and a list of four keywords. The deadline for submission of all extended papers is September 10, 2003 with notification of acceptance by October 10, 2003. Submission of camera-ready paper is by November 10, 2003.
Authors of accepted papers will be invited to submit full-length manuscripts for inclusion in the proceedings with ISBN.
All hard copies papers should be sent to the following address:
Pascal LORENZ
University of Haute Alsace
34 rue du Grillenbreit
68008 Colmar, France
Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)632630204
E-mail: lorenz@ieee.org
Check our Web page at http://conf.uha.fr/ICN04.html for the latest information concerning the conference.
Best papers will be forwarded for consideration in a special issue of a= journal. 

TUTORIALS AND WORKSHOPS
Tutorials and workshops provide overviews of current high interest topics.= Proposals for half of full day tutorials are due by September 10, 2003.=

INTERNATIONAL ADVISORY COMMITTEE
H. Abouaissa (France) - University of Haute Alsace
R. Addie (Australia) - University of Southern Queensland
K. Begain (UK) - University of Bradford
B. Bing (USA) - Georgia Institute of Technology
A. Brandwajn (USA) - University of California Santa Cruz
P. Chemouil (France)  France Telecom R&D
J.P. Coudreuse (France) - Mitsubishi
M. Devetsikiotis (USA) - North Carolina State University
S. Fdida (France) - LIP6
N. Fonseca (Brazil) - University of Campinas
E. Fulp (USA) - Wake Forest University
B. Gavish (USA) - Vanderbilt University
H. Guyennet (France) - University of Franche-Comte
Z. Hulicki (Poland) - University of Cracow
R. Israel (France) - IEEE
A. Jajszczyk (Poland) - University of Mining & Metallurgy
A. Jamalipour (Australia) - University of Sydney
S. Jiang (Singapore) - National University of Singapore
S. Karnouskos (Germany) - GMD FOKUS
G. Kesidis (USA)  Pennsylvania State University
D. Khotimsky (USA) - Lucent Bell Labs
D. Kofman (France) - ENST Paris
S. Kota (USA) - Lockeed Martin
D. Kouvatsos (UK) - University of Bradford
S. Kumar (USA) - Ericsson
G.S. Kuo (Taiwan) - National Central University
F. Le Faucheur (France) - Cisco
M. Lee (Korea) - Dongshin University
P. Lorenz (France) - University of Haute Alsace
Z. Mammeri (France) - University of Toulouse
N. Mastorakis (Greece) - Military Institutions of University Education
H. Mouftah (Canada) - Queen's University
G. Omidyar (USA) - Computer Sciences Corp.
M. Potts (Switzerland) - Martel
G. Pujolle (France) - University of Paris 6
S. Rao (Switzerland) - Ascom
A. Reid (UK) - British Telecom
S. Ritzenthaler (France) - Alcatel
P. Rolin (France)  France Telecom R&D
D. Sadok (Brazil) - Federal University of Pernambuco
R. Saracco (Italy) - CSELT
H. Tobiet (France) - NMG
V.A. Villagra (Spain) - University of Madrid
E. Vazquez Gallo (Spain) - University of Madrid
O. Yang (Canada) - University of Ottawa

IMPORTANT DATES
Extended papers= deadline                September 10,= 2003
Authors= Notification:      &nbs= p;          = ;  October 10, 2003
Camera ready, full papers due:=          = ;November 10, 2003


--=====================_114097293==_.ALT-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 20 19:50:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06289 for ; Tue, 20 May 2003 19:50:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4KNHNS15071 for avt-archive@odin.ietf.org; Tue, 20 May 2003 19:17:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KNGTB15031; Tue, 20 May 2003 19:16:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4KHOPB20172 for ; Tue, 20 May 2003 13:24:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23072 for ; Tue, 20 May 2003 13:57:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IBLO-0007GL-00 for avt@ietf.org; Tue, 20 May 2003 13:56:10 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19IBLN-0007GI-00 for avt@ietf.org; Tue, 20 May 2003 13:56:09 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4KHvR0J023998; Tue, 20 May 2003 19:57:27 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LH1P18GD; Tue, 20 May 2003 19:57:18 +0200 Message-ID: <3ECA6C0F.8070406@ericsson.com> Date: Tue, 20 May 2003 19:55:27 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Casner CC: IETF AVT WG Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt References: <20030519230757.U40866-100000@oak.packetdesign.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Stephen, I like the idea that Senders get there share of the total bandwidth. I think that work fine with the examples that I have. However I think I must actually ask the question: What happens the day one likes to turn of the senders and only have the receivers, i.e. RS=0 RR=5000? I don't need the functionality to turn of the senders. However I think the bw modifier draft should explicitly talk about this case and say that it is not supported by the underlying RTCP mechanism. So your proposal is to change a section of draft-ietf-rtp-new-12 to the following: > The profile MAY further specify that the control traffic bandwidth > may be divided into two separate session parameters for those > participants which are active data senders and those which are not; > let us call the parameters S and R. Following the recommendation > that 1/4 of the RTCP bandwidth be dedicated to data senders, the > RECOMMENDED default values for S and R would be 1.25% and 3.75% of > the session bandwidth, respectively. When the proportion of senders > is greater than S/(S+R) of the participants, the senders get their > proportion of the sum of these parameters. > I think this change is for the better and at least clarify that part. However what do you intend with the other relevant sections of the RTP draft? I think there are two changes in the RTP draft that also needs to be made: 1. Update Section 6.3.1. Bullet 1. 2. Update the algorithm in A.7 > I have to admit some concern here because we are also trying to get RFC > numbers on an accelerated basis at the request of the ITU. > If we propose these changes so that the protocol is at least as restricted in BW behavior I can't see major problems with the IESG. Sure it is not good that it has taken this long to find this problem. I guess this is the result of that no one has tried to apply the RTCP SDP bw modifier draft before. Which shows that implementation helps finding a lot of bugs. However to continue the work, I have below provided a proposal for the A.7 code. I think that we should simply remove the senders=0 part. Then in cases the S/(R+S) rules kicks in the receivers will only get RR divided by the total nr. of participants. This will result in a underutilization of the total RTCP bandwidth. Let number of receivers be Nr, number of senders Ns and the total number of participants be N, i.e. N = Ns + Nr. The active senders bandwidth is S and the receivers is R. Then the non-utilized bandwidth, as a fraction of the total bandwidth, in case the fraction of senders are over the threshold, will be Nr*S/(N*(S+R)). Which in bandwidth is the fraction of receivers in the session multiplied by the bandwidth assigned to active senders. To get some perspective on this, lets calculate a few examples. For the default bandwidth partition S = 0.25 and R = 0.75 the worst case will be when Ns is exactly on the threshold of 1/4. This will result in 0.75 * 0.25 = 0.1875 of the total bandwidth will not be utilized. For a case where Ns/N = 0.5 the underutilization is 0.5 * 0.25 = 0.125. Some possible alternatives is considered below. Another assignment rule I can think on would be to give the senders their fraction of the total bandwidth while the receivers still get a full share of the receiver bandwidth. This will instead result in a overutilization. The over utilization fraction will be R/(S+R) - Nr/N. Utilizing the same number is the previous examples for Ns/N = 0.25 there will be a over utilization of 0.75 - 0.75 = 0 while for Ns/N = 0.5 it will be 0.75 - 0.5 = 0.25. Where the worst case is a single receiver and a infinite number of senders, in which the utilized bandwidth becomes 1 + R/(S+R). This does not seem a viable way. A third way I can think of would be to assign the senders there portion of the sender bw + an equal share of the receiver bandwidth. However this would complicate the calculation in this case. It would of course utilize the whole bandwidth and also give the senders a edge in terms of bandwidth. ----------- A.7 Computing the RTCP Transmission Interval ... double rtcp_interval(int members, int senders, double rtcp_bw_senders, double rtcp_bw_receivers, int we_sent, double avg_rtcp_size, int initial) { /* * Minimum average time between RTCP packets from this site (in * seconds). This time prevents the reports from `clumping' when * sessions are small and the law of large numbers isn't helping * to smooth out the traffic. It also keeps the report interval * from becoming ridiculously small during transient outages like * a network partition. */ double const RTCP_MIN_TIME = 5.; /* * To prevent senders from getting less than a equal share of * the total RTCP bandwidth, a threshold is calculated. When the * number of senders out of the total number of participants is * larger than the treshold fraction they are getting less * bandwidth. This threshold is based on the assigned bandwidth * to active senders (S) and non-data senders (R). The threshold * is calculated as S/(S+R). For the default settings of giving * 1/4 of the bandwidth to active senders, i.e. 1.75% to senders * and 3.75% to receivers, the threshold will be 1/4 senders. */ double RTCP_FRAC_SENDER_THRESHOLD = rtcp_bw_senders / (rtcp_bw_senders + rtcp_bw_receivers) /* /* To compensate for "timer reconsideration" converging to a * value below the intended average. */ double const COMPENSATION = 2.71828 - 1.5; double t; /* interval */ double rtcp_min_time = RTCP_MIN_TIME; int n; /* no. of members for computation */ /* * Very first call at application start-up uses half the min * delay for quicker notification while still allowing some time * before reporting for randomization and to learn about other * sources so the report interval will converge to the correct * interval more quickly. */ if (initial) { rtcp_min_time /= 2; } /* * If there were active senders, give them at least a minimum * share of the RTCP bandwidth. */ double rtcp_bw; n = members; if (senders / members > RTCP_FRAC_SENDER_THRESHOLD) { if (we_sent) { rtcp_bw = rtcp_bw_senders + rtcp_bw_receivers; } else { rtcp_bw = rtcp_bw_receivers; } } else { if (we_sent) { rtcp_bw = rtcp_bw_senders; n = senders; } else { rtcp_bw = rtcp_bw_receivers; n -= senders; } } /* * The effective number of sites times the average packet size is * the total number of octets sent when each site sends a report. * Dividing this by the effective bandwidth gives the time * interval over which those packets must be sent in order to * meet the bandwidth target, with a minimum enforced. In that * time interval we send one report so this time is also our * average time between reports. In case a bandwidth value is 0 * the interval becomes infinite, which here is represented by the * largest positive double value possible. */ if (rtcp_bw == 0.0) { t = MAX_POSITIVE_DOUBLE; } else { t = avg_rtcp_size * n / rtcp_bw; } if (t < rtcp_min_time) t = rtcp_min_time; /* * To avoid traffic bursts from unintended synchronization with * other sites, we then pick our actual next report interval as a * random number uniformly distributed between 0.5*t and 1.5*t. */ t = t * (drand48() + 0.5); t = t / COMPENSATION; return t; } -------- Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 21 08:13:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16235 for ; Wed, 21 May 2003 08:13:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LBeHn10391 for avt-archive@odin.ietf.org; Wed, 21 May 2003 07:40:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LBcZB10280; Wed, 21 May 2003 07:38:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LBalB09299 for ; Wed, 21 May 2003 07:36:47 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15756; Wed, 21 May 2003 08:09:30 -0400 (EDT) Message-Id: <200305211209.IAA15756@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 21 May 2003 08:09:30 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-mwpp-midi-rtp-07.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for MIDI Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-avt-mwpp-midi-rtp-07.txt Pages : 102 Date : 2003-5-20 This memo describes an RTP payload format for the MIDI command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as the remote operation of musical instruments) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP as well as TCP, and defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-mwpp-midi-rtp-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-mwpp-midi-rtp-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-20123439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mwpp-midi-rtp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-mwpp-midi-rtp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-20123439.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 21 08:48:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17705 for ; Wed, 21 May 2003 08:48:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LCF2113198 for avt-archive@odin.ietf.org; Wed, 21 May 2003 08:15:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LCDDB13043; Wed, 21 May 2003 08:13:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LCALB12892 for ; Wed, 21 May 2003 08:10:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17188 for ; Wed, 21 May 2003 08:43:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ISud-0005WF-00 for avt@ietf.org; Wed, 21 May 2003 08:41:43 -0400 Received: from [64.19.188.18] (helo=db1.contentcatcher.com) by ietf-mx with esmtp (Exim 4.12) id 19ISuc-0005Uu-00 for avt@ietf.org; Wed, 21 May 2003 08:41:42 -0400 Received: from CC1 ([192.168.200.2]) by db1.contentcatcher.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 08:38:55 -0400 x-sender: owner-ietf-announce@ietf.org x-receiver: spamtrap@spam.clearnetwork.com Received: from pf1.contentcatcher.com ([192.168.100.2]) by CC1 with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 08:42:48 -0400 Received: by pf1.contentcatcher.com (Postfix, from userid 502) id 944C69F605; Wed, 21 May 2003 08:28:44 -0400 (EDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by pf1.contentcatcher.com (Postfix) with ESMTP id 3E1109F617; Wed, 21 May 2003 08:27:53 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19ISTd-0003Wa-T9 for ietf-announce-list@asgard.ietf.org; Wed, 21 May 2003 08:13:49 -0400 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by asgard.ietf.org with esmtp (Exim 4.14) id 19ISPT-0003UP-TL for all-ietf@asgard.ietf.org; Wed, 21 May 2003 08:09:31 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15756; Wed, 21 May 2003 08:09:30 -0400 (EDT) Message-Id: <200305211209.IAA15756@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Reply-To: Internet-Drafts@ietf.org Date: Wed, 21 May 2003 08:09:30 -0400 Precedence: bulk X-Spam-Status: Yes, hits=10.6 required=5.0tests=BAYES_80,CC_Bulk_Header_1,MIME_BOUND_NEXTPART,TO_MALFORMEDversion=2.53-contentcatcher X-Spam-Level: ********** X-Spam-Checker-Version: SpamAssassin 2.53-contentcatcher (1.174.2.15-2003-03-30-exp) X-Spam-Report: ---- Start SpamAssassin results10.60 points, 5 required;* 1.8 -- To: has a malformed address* 5.0 -- Mail has precedence set to bulk* 3.5 -- BODY: Bayesian classifier says spam probability is 80 to 90%[score: 0.8258]* 0.3 -- Spam tool pattern in MIME boundary---- End of SpamAssassin results X-Spam-Flag: YES X-VIRUS-FOUND: NO X-GHOST-SENDER: owner-ietf-announce@ietf.org X-GHOST-RECEIVER: braja@tellium.com X-OriginalArrivalTime: 21 May 2003 12:42:48.0578 (UTC) FILETIME=[7C330620:01C31F96] x-contentCatcher: ContentCatcher build 0407021738 Cc: avt@ietf.org To: braja@tellium.com From: Internet-Drafts@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-mwpp-midi-rtp-07.txt [owner-ietf-announce@ietf.org in Pass-Through List] ['from' in Pass-Through List] Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --NextPart Title : RTP Payload Format for MIDI Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-avt-mwpp-midi-rtp-07.txt Pages : 102 Date : 2003-5-20 This memo describes an RTP payload format for the MIDI command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as the remote operation of musical instruments) and content-delivery applications (such as file streaming). The format may be used over unicast and multicast UDP as well as TCP, and defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-mwpp-midi-rtp-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-mwpp-midi-rtp-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" This is a multi-part message in MIME format. --OtherAccess Content-Type: Message/External-body;access-type="mail-server";server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-20123439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-mwpp-midi-rtp-07.txt --OtherAccess Content-Type: Message/External-body;name="draft-ietf-avt-mwpp-midi-rtp-07.txt";site="ftp.ietf.org";access-type="anon-ftp";directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-20123439.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 21 13:28:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29131 for ; Wed, 21 May 2003 13:28:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LGtLh31191 for avt-archive@odin.ietf.org; Wed, 21 May 2003 12:55:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LGleB19818; Wed, 21 May 2003 12:47:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LGksB07596 for ; Wed, 21 May 2003 12:46:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28966 for ; Wed, 21 May 2003 13:19:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IXEA-0000oR-00 for avt@ietf.org; Wed, 21 May 2003 13:18:10 -0400 Received: from www.routeexplorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19IXE9-0000oK-00 for avt@ietf.org; Wed, 21 May 2003 13:18:09 -0400 Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h4LHIPvW064836; Wed, 21 May 2003 10:18:25 -0700 (PDT) (envelope-from casner@acm.org) Date: Wed, 21 May 2003 10:18:25 -0700 (PDT) From: Stephen Casner To: Magnus Westerlund cc: IETF AVT WG Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt In-Reply-To: <3ECA6C0F.8070406@ericsson.com> Message-ID: <20030521094546.R30279-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , [Note to other WG participants: I'd like to hear more opinions about what we should do here.] Magnus, > I like the idea that Senders get there share of the total bandwidth. I > think that work fine with the examples that I have. However I think I > must actually ask the question: What happens the day one likes to turn > of the senders and only have the receivers, i.e. RS=0 RR=5000? If the senders are also receivers, then it is OK for them to still get RTCP bandwidth. It might be that this combination of parameters is supposed to indicate that Sender Report information should not be sent. However, I don't think this makes sense. > I don't need the functionality to turn of the senders. However I think > the bw modifier draft should explicitly talk about this case and say > that it is not supported by the underlying RTCP mechanism. I agree that it would be reasonable to add a note about this. > So your proposal is to change a section of draft-ietf-rtp-new-12 to the > following: ... > I think this change is for the better and at least clarify that part. > However what do you intend with the other relevant sections of the RTP > draft? > > I think there are two changes in the RTP draft that also needs to be made: > > 1. Update Section 6.3.1. Bullet 1. > 2. Update the algorithm in A.7 I see two possibilities. If this is considered a technical change that is not allowed at this stage, we could finesse this problem by adding a note in both places to say that the algorithm as stated is for the normal RTCP bandwidth allocation and must be modified if explicit RTCP bandwidth parameters are implemented. The justification for this would be that the RTP spec does not define the parameters itself, it just says profiles MAY do so. If there is not an objection to making a more-than-editorial change, we can remove the senders > 0 condition in both places and fix the "senders and receivers are treated together" phrase in 6.3.1. I don't want to go as far as what you have proposed in modifications to A.7 because this changes the function signature which means it also needs to be changed in other places; instead, I would leave the fraction fixed 25%, and simply remove the senders > 0 condition. I would add to the comment that a check must be added to avoid division by zero if the sender fraction is changed to 100% or parameterized. > > I have to admit some concern here because we are also trying to get RFC > > numbers on an accelerated basis at the request of the ITU. > > If we propose these changes so that the protocol is at least as > restricted in BW behavior I can't see major problems with the IESG. That is not the issue. If the RFC Editor feels this change would require discussion by the IESG, then that is already a problem for delay. > Sure it is not good that it has taken this long to find this > problem. I guess this is the result of that no one has tried to > apply the RTCP SDP bw modifier draft before. Which shows that > implementation helps finding a lot of bugs. Yes, that is certainly true. > However to continue the work, I have below provided a proposal for the > A.7 code. I think that we should simply remove the senders=0 part. Then > in cases the S/(R+S) rules kicks in the receivers will only get RR > divided by the total nr. of participants. This will result in a > underutilization of the total RTCP bandwidth. Yes, but that is a straightforward consequence of the decision to dedicate a portion of the bandwidth to senders, and I believe it is acceptable. Does it make sense to have an RTP session with no data senders? And when no data is sent, then there is not much for receivers to say in RTCP, either. I suppose if RTCP were being used on its own for a scalable-timer-based entity identification protocol, perhaps with some other RTCP packet types defined, then this could make some sense. But in that case, the RS=0 and RR=n parameters can be used to control the RTCP bandwidth at the desired level. In fact, if there is no data, then the concept of RTP session bandwidth is not defined, so you'd have to be explicit about the RTCP bandwidth. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 21 14:58:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01928 for ; Wed, 21 May 2003 14:58:29 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LIPOT06430 for avt-archive@odin.ietf.org; Wed, 21 May 2003 14:25:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LIJLB06051; Wed, 21 May 2003 14:19:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LIIhB05966 for ; Wed, 21 May 2003 14:18:43 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01387; Wed, 21 May 2003 14:51:17 -0400 (EDT) Message-Id: <200305211851.OAA01387@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: avt@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 21 May 2003 14:51:17 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-report-extns-06.txt,.pdf Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Control Protocol Extended Reports (RTCP XR) Author(s) : T. Friedman et al. Filename : draft-ietf-avt-rtcp-report-extns-06.txt,.pdf Pages : 53 Date : 2003-5-21 This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-report-extns-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcp-report-extns-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-21144406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-report-extns-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-21144406.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 21 15:23:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04688 for ; Wed, 21 May 2003 15:23:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4LIone08845 for avt-archive@odin.ietf.org; Wed, 21 May 2003 14:50:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LIg9B08158; Wed, 21 May 2003 14:42:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LIdaB07992 for ; Wed, 21 May 2003 14:39:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03294 for ; Wed, 21 May 2003 15:12:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IYzB-0001TZ-00 for avt@ietf.org; Wed, 21 May 2003 15:10:49 -0400 Received: from [64.19.188.18] (helo=db1.contentcatcher.com) by ietf-mx with esmtp (Exim 4.12) id 19IYzA-0001SO-00 for avt@ietf.org; Wed, 21 May 2003 15:10:48 -0400 Received: from CC1 ([192.168.200.2]) by db1.contentcatcher.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 15:07:59 -0400 x-sender: owner-ietf-announce@ietf.org x-receiver: spamtrap@spam.clearnetwork.com Received: from pf1.contentcatcher.com ([192.168.100.2]) by CC1 with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 15:11:52 -0400 Received: by pf1.contentcatcher.com (Postfix, from userid 502) id 8C2D69F616; Wed, 21 May 2003 14:57:43 -0400 (EDT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by pf1.contentcatcher.com (Postfix) with ESMTP id 96F739F618; Wed, 21 May 2003 14:57:29 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19IYio-0003ZQ-AK for ietf-announce-list@asgard.ietf.org; Wed, 21 May 2003 14:53:54 -0400 Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by asgard.ietf.org with esmtp (Exim 4.14) id 19IYgJ-0003UX-Fn for all-ietf@asgard.ietf.org; Wed, 21 May 2003 14:51:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01387; Wed, 21 May 2003 14:51:17 -0400 (EDT) Message-Id: <200305211851.OAA01387@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Reply-To: Internet-Drafts@ietf.org Date: Wed, 21 May 2003 14:51:17 -0400 Precedence: bulk X-Spam-Status: Yes, hits=10.6 required=5.0tests=BAYES_80,CC_Bulk_Header_1,MIME_BOUND_NEXTPART,TO_MALFORMEDversion=2.53-contentcatcher X-Spam-Level: ********** X-Spam-Checker-Version: SpamAssassin 2.53-contentcatcher (1.174.2.15-2003-03-30-exp) X-Spam-Report: ---- Start SpamAssassin results10.60 points, 5 required;* 1.8 -- To: has a malformed address* 5.0 -- Mail has precedence set to bulk* 3.5 -- BODY: Bayesian classifier says spam probability is 80 to 90%[score: 0.8596]* 0.3 -- Spam tool pattern in MIME boundary---- End of SpamAssassin results X-Spam-Flag: YES X-VIRUS-FOUND: NO X-GHOST-SENDER: owner-ietf-announce@ietf.org X-GHOST-RECEIVER: braja@tellium.com X-OriginalArrivalTime: 21 May 2003 19:11:52.0078 (UTC) FILETIME=[D60272E0:01C31FCC] x-contentCatcher: ContentCatcher build 0407021738 Cc: avt@ietf.org To: braja@tellium.com From: Internet-Drafts@ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-report-extns-06.txt,.pdf [owner-ietf-announce@ietf.org in Pass-Through List] ['from' in Pass-Through List] Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. --NextPart Title : RTP Control Protocol Extended Reports (RTCP XR) Author(s) : T. Friedman et al. Filename : draft-ietf-avt-rtcp-report-extns-06.txt,.pdf Pages : 53 Date : 2003-5-21 This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-report-extns-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtcp-report-extns-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" This is a multi-part message in MIME format. --OtherAccess Content-Type: Message/External-body;access-type="mail-server";server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-21144406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-report-extns-06.txt --OtherAccess Content-Type: Message/External-body;name="draft-ietf-avt-rtcp-report-extns-06.txt";site="ftp.ietf.org";access-type="anon-ftp";directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-21144406.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed May 21 20:33:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13898 for ; Wed, 21 May 2003 20:33:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4M00vW31569 for avt-archive@odin.ietf.org; Wed, 21 May 2003 20:00:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LNxVB31476; Wed, 21 May 2003 19:59:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4LNRFB29591 for ; Wed, 21 May 2003 19:27:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13358; Wed, 21 May 2003 19:59:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IdTS-0003o3-00; Wed, 21 May 2003 19:58:22 -0400 Received: from santee.icann.org ([192.0.35.122]) by ietf-mx with esmtp (Exim 4.12) id 19IdTR-0003nz-00; Wed, 21 May 2003 19:58:21 -0400 Received: from tarim (tarim.icann.org [192.0.35.80]) by santee.icann.org (8.11.6/8.11.6) with SMTP id h4LNxDB02116; Wed, 21 May 2003 16:59:13 -0700 From: "IANA" To: Cc: Date: Wed, 21 May 2003 16:55:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200305081721.NAA00721@ietf.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [AVT] RE: Last Call: The Secure Real-time Transport Protocol to Proposed Standard Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit IESG: The IANA has reviewed the following Internet-Draft which is in Last Call: , and has the following comments with regards to the publication of this document: We understand the first paragraph of the IANA considerations section to request a profile name registration in the rtp-parameters registry. The second and third paragraphs of the IANA considerations sections says the following: SRTP uses cryptographic transforms, which a key management protocol signals. It is the task of each particular key management protocol to register the cryptographic transforms or suites of transforms with IANA. The key management protocol conveys these protocol numbers, not SRTP, and each key management protocol chooses the numbering scheme and syntax that it requires. Specification of a key management protocol for SRTP is out of scope here. Section 8.2, however, provides guidance on the parameters that need to be defined for the default and mandatory transforms. Is the IANA requested to create a new registry for "SRTP cryptographic transforms or suites of transforms"? In section 8.2 we see the list of Key Management parameters. Is this the initial registry? How are others to be added? The IANA Considerations section needs to be more clear. Please respond to the IANA about our concerns with regards to this document. Failing to do so may cause delay of the approval and publication of your document. Thank you. Michelle S. Cotton (on behalf of the IANA) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 22 10:33:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16453 for ; Thu, 22 May 2003 10:33:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4ME1BS11888 for avt-archive@odin.ietf.org; Thu, 22 May 2003 10:01:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MDsMB11292; Thu, 22 May 2003 09:54:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MDnGB11079 for ; Thu, 22 May 2003 09:49:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16036 for ; Thu, 22 May 2003 10:21:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IqvN-0002AL-00 for avt@ietf.org; Thu, 22 May 2003 10:20:05 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19IqvN-0002A7-00 for avt@ietf.org; Thu, 22 May 2003 10:20:05 -0400 Received: from TELWS104 [64.238.103.215] by telchemy.com with ESMTP (SMTPD32-7.14) id ACB476E0224; Thu, 22 May 2003 10:20:36 -0400 Reply-To: From: "Alan Clark" To: "'Siddiqui, Anwar A \(Anwar\)'" , "'Colin Perkins'" , "'Timur Friedman'" , "'Stephen Casner'" , "'Ramon Caceres'" Cc: Date: Thu, 22 May 2003 10:14:13 -0400 Message-ID: <003001c3206c$6c5e9300$6801a8c0@telchemy.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0031_01C3204A.E54CF300" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-MS-TNEF-Correlator: 000000009988B8DB99EF5848818B736CCB599E21047AB500 Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C3204A.E54CF300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Anwar This was brought up several weeks ago on the mailing list. This approach was taken deliberately for several reasons:- (i) To encourage implementors to move towards implementing the complete set of metrics. I've socialized this data set with a variety of service providers, enterprise network managers, equipment manufacturers and there seems to be general agreement that this metrics set provides a good "minimum set" for diagnosing VoIP performance problems. (ii) There is overhead associated with identifying whether fields are or are not present (see Colin Perkins comment on this issue several weeks ago). I am aware of several major equipment manufacturers and DSP software vendors that intend to fully implement the RTCP XR VoIP metrics, and several tier one carriers that are currently specifying that this metric set be used for VoIP service management. There is also considerable interest from other standards groups in this work. Regards Alan Clark Telchemy -----Original Message----- From: Siddiqui, Anwar A (Anwar) [mailto:anwars@avaya.com] Sent: Thursday, May 22, 2003 9:23 AM To: Colin Perkins; Timur Friedman; Stephen Casner; alan@telchemy.com; Ramon Caceres Cc: avt@ietf.org Subject: Re: draft-ietf-avt-rtcp-report-extns-06.txt Timur, Alan I did mention this during last IETF session. And I believe few other people also have similar concerns. So here is the issue I am requesting this be reconsidered and if possible be avoided. ------------------------------ Is there anyway that we can avoid hard coding VoIP metrics like it is identified in this draft. Its not the usefulness of the metrics that I am having difficulties with. I actually believe they are useful parameters to be included in RTCP. But its just that its hardcoded right now ....and if an RTP source does not have parameters to report it will keep sending these default hard coded values! It is this kind of hardcoding in SR/RR reports that makes us do this XR reports now. So I am requesting if it possible such hard coding of VoIP metrics be avoided. ------------------------------- Thanks in advance Anwar ----- Original Message ----- From: "Colin Perkins" To: "Timur Friedman" Cc: ; "Stephen Casner" ; "Alan Clark" ; "Ramon Caceres" ; "Kevin C. Almeroth" ; "Robert Cole" ; "Nick Duffield" ; "Kaynam Hedayat" ; "Kamil Sarac" ; "Magnus Westerlund" Sent: Monday, May 19, 2003 8:05 PM Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt > Thanks. Unless there are objections, we intend to request that the IESG > consider this version for publication as a proposed standard. > > Colin > > > --> Timur Friedman writes: > >Hello, > > > >Please find attached the latest version of the RTP Control Protocol Extended > >Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. > > > >This draft was produced in response to AVT working group last call comments. > > > >In addition to the changes discussed online on the AVT list, some additional > >detail has been added to the SDP signaling section, to allow individual flags > >in the Statistics Summary report blocks to be signaled. Also, default values > >have been specified for the VoIP metrics section in places where there might > >have been some confusion about what to do if no packets had been received. > >And the time frame over which some of the VoIP fields are calculated has > >also been specified. > > > >A PDF version of this draft is available at the following URL: > > > >http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-report- extns-06.pdf > > > >Regards, > > > >Timur Friedman > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > ------=_NextPart_000_0031_01C3204A.E54CF300 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ig4OAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANMHBQAWAAoADgAAAAQAEQEB A5AGALAOAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAAoAAAAZHJhZnQtaWV0Zi1hdnQtcnRjcC1yZXBvcnQtZXh0bnMtMDYudHh0AAIB cQABAAAAFgAAAAHDIGxrud2DjhAytUUnprwT/FaVbWAAAAIBHQwBAAAAFwAAAFNNVFA6QUxBTkBU RUxDSEVNWS5DT00AAAsAAQ4AAAAAQAAGDgCE1WNsIMMBAgEKDgEAAAAYAAAAAAAAAJmIuNuZ71hI gYtzbMtZniHCgAAAAwAUDgEAAAALAB8OAQAAAAIBCRABAAAAZgoAAGIKAAB5EgAATFpGdUZcNf8D AAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEK wHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUHMLCQFkMzYWUAumEMBunncK wAqiCoQKgFRoBAAWIB0QBCBiA2B1Z2jRBUB1cCAUEHYEkAdACx5ACeBrBCBhZ28gwQIgIHRoZSAA wAMQCQuAZyAhAHN0LiBiIB4DYXBwA2AA0GhrHkMBkGsJ8CABACEAYuMfcQ6wbHkgAhAFwB9GRxgg HmACIHM6LR1KKPxpKSGwIEAJ8AWgCHAgIPcgsAdwC1BlB4ACMAWwIsHfIEAEYB9gJ/EdEWQEICc3 fyESIJIFoCdCDrAfMQVAb05mIMAUIAUQY3MhkUmWJyhRJQBjBzFpegmA6yCBHiFkI7BhKpMD8CCQ 2SAQIHYKwAiQdCPwKuH5FBBydg3gILAiMS7gBIHscywmgQ6wciIwBAAgsKpuFCB3BbBrIMFuJvE5 L6NxdQUgJ4IxAnVm3QDQdAhwL5EgEG4skgSQ7yqCJ3An4yOAICcAMJAfgv8gIAnRMgMgkCOwLKQr FSqTFy81IAE0gG8EcCAibVMLgAdwdW0qkiIkA2QxBzBnbm8AkCEhVm/8SVAvIASQJBEDgS8EAmB9 M/EuJWwmMjODHiEoQXL9IKBhLJAeYCwDDrAskC2T0y9xKXFmeSESdyCgM3L7JAAIkGwo0QrAILAF sUBi7zlwNvIHkDISKDPREiEhAfQgUASQawuABCAqETIDnyBjHiEEAQpQHz9vKTt79kkgEDiAYR0R QIEukh9knQDAagWxMb8yyURTOhD/JQABgEazH2AzQCfDNcILgMcOsDNCIEBmdWwj4Sc3kSCDUlRD OhBYUjnU/ysVL8AzMkRmKYASgQIgKfHvCsAIgksFQGJjCHAYIAIw/SPhczowLCA/FDW+KpM0Yf51 FBAskCQSOeMutjEUJ4L/IZA8lwdAJQAqAQCBBIEBoP8nYEtjQWEFQANSIFA/oyFw7zMxKLMJwAhg cCjhQ5UwwmMhkR1KUmVnKLIdSkH/C2ASEQtgMOAdpSNQE9AncKp5HUotXzJPBRBnC4B1H5FNB5Bz JvFfMx1ERv0DYToGAC9wOTBIIS/AHPNvEMBBwBzzJkBbINInsDojAHAdEXNAYS4AeWH6LioRXR1E BmACMGFwHgBVCHBzLQB5L8BNZEAgDDIyL8AB0DAzIDnkOjJm0EFNHaVjkEIcvjshsDhRBcBhMAiQ ZAOB9WjQUw6wcCCgEhEeYDSx92jQB0AAcEAjwV4jZHIZMH9bdEZwIGFqcC8AQWEdREMmY2FwZCB0 QC4xZi7FBbBnZMV1YmoFkGVRW1vAYXBkH4ABgC1uIi19beEtACAN8HCwahAXwS1DDsEAgC0wNi4M 0HT/HUodpWkCYhFdAUWcOTAskHspU0OGZAhxISIeYAVASfhFVEZEUQQQdXEhkBzw/yyQRlAjgCEA H1EkAAfRWKT9OjBvJ1FWlBPgK9IHcAMQ3wrBVvFs8QCAIZBTecE8tf8gkkQERlMYIEggWBEplB4h /zRhGCBW9iyBMzIGkC8gOYCvAJBXgjRhZCBvL3FkO3t/XzOBr4I2RfV74zOhAHB5/x0QI/A1sx/A T/EDoIAjedH/CyAqATkwObY2ViEAIwAnIH9LUSjhPsRpcVoHb9MhkEn+dAQgQRIgklPxTBEwkAQR /yrhIJM2ZTWzRlN54SESOTD/ASAN4EwgT3EeMS2hiYEgEP8ysQdAI+F4BiCRI/BAYopkfy8gCsBG cCphJ9Q0YQuAY58KQIBhWgJNUiGQQnVLUf2JsWpT8DWVkuKFwoYRLIHvX5Ee4TlwB+AulUF+9QOR /01QSfIIcC8BStAHkUESeePfkHxxFIeSA/BMMCAjAGoQ30RRM0AplTBhAQFhjXGFt+csgS4ACkFz IYmRe8QeIT9CsSyQKuGUBSESQlFTUvwvUk2wcRRLBQDAIwAEIP9T8JbBLKRNoZ7WlQF7M3yu/38x h6F/Z0QgInGFyirhhov/f/+CP4JvHXkAcB/xQlE9gL8uADqxXDtiQ3JPXsogX462IK1UYNoiQis4 0DwrYFxwQLDxQpRuYj5naCJvaPywwSmAaREuA1BpdEC9IQBwcfADULIFbaI8bep6PmjQImn8sMJq g2QQY/ZttnZc+CIdRLXgaw62ss9se7DBkJECIEBzHhBAEdsFILsWSx9QQlFDO3Vc8H8HgANgIJCw wQdAvvSxIS7RGtBzYi4JgHW7UzsQVwSQBUBCIWW8YmcXkWW3ZBACQLsWTg3gXYVEMoDvP/OwwXYA w8RAQWIKwBPQu5VwwmhLZEAxMDiASAmAt2RBOMC51WsgoMazQB6QfGl4MJHFqHpRBgEfgGP3sMEf 8MlyQJKwLQBMMB5g38CGZiA5YFPwHURXWBEEkN8KQDNAsMEAwMtyLh/AzDbeQB9xwIArQiUBLhQQ sgVNZSRNAiBl1zE5ZoU4ODowNUJwZ1VvB1tBeFZUXW+PcJ9xrx1ZPuchsanCIZBVbidgBBGD1f9A cm8jdXEvsYTxS3h89VJm8XyBRVNH1kZW9iykH2H7d0IkA3BvECEAUAB1Yx5h/y0wIjF/YSyBWQY7 dbIF1qD/QiPfjNZGXzDWoWkLHkAFEDcOsCUw1kY+xpBMMG8s++PH48dQJ2AeYHhhnSLCUf8iYSyD ILALYOOBBUDclosV35YiCFACMANgAyBQvxEsEPsG8B1ERQ7QSrEJgOPHW8D9nvQoTVUmQNMTL8DT H9Qv/9Uz33blKR4D7QMeQyIxdgD/LwCIk0Fh7mAAgChiEMDSkP9agyESWaN2ZFAATDAdREMF+ztm 5RpJqiI5MHVkoEIp8f+psScALOEEAFEgBBAsgQIg/yEBQIEgdPMSIVIvwCUAB4D/HUT3BgdA48cB AAGQAxET4J990iMR9wEsgvekU0RJ8f9foF/RIRIUENiTL8AoAY6hu5URnSFpL2GOkSXEZgtg/mdc JeQhWhP+IQyQKYB9Qf82oW8AQyAKwCPwmJUX8CwQ/x/xNDT+hIBxIaBc8CUA7OH/msQlxJvk48d5 4/0jUcSIcv9UQiCShov/JVoCG2EvAB4x/zODM3MlxDggHtEHTwhR+rH/VuJMENzDV3ASQC1xNcMg QP+gMX8xOXCQYcMgFCCT4iyQ9/0iJcR+IWUAcIB35CF3ov8gkrPReGGQkj0TP2EDACKA/w4TixU5 4z/59IGNYT4T/OG/48dWowgs9a8S0UJwRHbw/+fb8Mch4i4AemF/stqFVEDj//IhElVSTOO434wM wMB0cDovL3cgIO3gW71gtMUvf5AjwF8wIC8CX91Zcy8zNzgtj+0P7hglxO63cGRmGU+/62Fb4+Sv 8IFpC9ZGXymvNyq/K4rWRkGRwHVwL1a7L3EQUFTOENvQmLNX82X+R/Pi1kZt79aRH7LjoCADtDEu biYvY0LjES/6QlvgoFRALy/B34t9NIAAAB4AQhABAAAASQAAADxFRjIxNEU2MkU5RTIwMjQxODQw NEE3QTY5NTg1QjcyQzAyMTA4REUxQG5qNzQ2MGF2ZXh1Mi5nbG9iYWwuYXZheWEuY29tPgAAAAAD AAlZAQAAAAsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAA AEYAAAAAEIUAAAAAAAADAAeACCAGAAAAAADAAAAAAAAARgAAAABShQAAfW4BAB4ACYAIIAYAAAAA AMAAAAAAAABGAAAAAFSFAAABAAAABAAAADkuMAALABGACCAGAAAAAADAAAAAAAAARgAAAAAGhQAA AAAAAAMAEoAIIAYAAAAAAMAAAAAAAABGAAAAAAGFAAAAAAAACwAbgAggBgAAAAAAwAAAAAAAAEYA AAAADoUAAAAAAAADAByACCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAHoAIIAYAAAAAAMAA AAAAAABGAAAAABiFAAAAAAAAAgH4DwEAAAAQAAAAmYi425nvWEiBi3Nsy1meIQIB+g8BAAAAEAAA AJmIuNuZ71hIgYtzbMtZniECAfsPAQAAAJIAAAAAAAAAOKG7EAXlEBqhuwgAKypWwgAAbXNwc3Qu ZGxsAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBhbmQgU2V0dGluZ3NcYWxhblxM b2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRhXE1pY3Jvc29mdFxPdXRsb29rXG1haWxib3gu cHN0AAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMQAAADAwMDAwMDAwOTk4OEI4REI5OUVGNTg0 ODgxOEI3MzZDQ0I1OTlFMjEwNDdBQjUwMAAAAAADAAYQnITi5QMABxCPDAAAAwAQEAAAAAADABEQ AQAAAB4ACBABAAAAZQAAAEFOV0FSVEhJU1dBU0JST1VHSFRVUFNFVkVSQUxXRUVLU0FHT09OVEhF TUFJTElOR0xJU1RUSElTQVBQUk9BQ0hXQVNUQUtFTkRFTElCRVJBVEVMWUZPUlNFVkVSQUxSRUFT T04AAAAA3qo= ------=_NextPart_000_0031_01C3204A.E54CF300-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 22 11:48:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18807 for ; Thu, 22 May 2003 11:48:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4MFG5s19079 for avt-archive@odin.ietf.org; Thu, 22 May 2003 11:16:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MFERB18982; Thu, 22 May 2003 11:14:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MFAVB18811 for ; Thu, 22 May 2003 11:10:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18707 for ; Thu, 22 May 2003 11:42:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19IsBy-0002tq-00 for avt@ietf.org; Thu, 22 May 2003 11:41:18 -0400 Received: from wireless249.east.isi.edu ([65.123.202.249] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19IsBx-0002tn-00 for avt@ietf.org; Thu, 22 May 2003 11:41:17 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h4MFgcEg073639; Thu, 22 May 2003 11:42:38 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: avt@ietf.org cc: casner@acm.org From: Colin Perkins Date: Thu, 22 May 2003 11:42:38 -0400 Message-ID: <73638.1053618158@purple.nge.isi.edu> Subject: [AVT] WG last call: RTP Profile for RTCP-based Feedback (RTP/AVPF) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is to announce a working group last call on the Extended RTP Profile for RTCP-based Feedback (RTP/AVPF) (draft-ietf-avt-rtcp-feedback-06.txt), and simulation results (draft-burmeister-avt-rtcp-feedback-sim-01.txt). These were previously last called in March this year, and have been updated in response to comments made at that time. Please review and send any final comments to the mailing list by 30th May 2003. At that time, we propose to submit the profile to the IESG for publication as a Proposed Standard RFC, and the simulation results for publication as an Informational RFC. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 22 12:22:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19985 for ; Thu, 22 May 2003 12:22:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4MFnNx21930 for avt-archive@odin.ietf.org; Thu, 22 May 2003 11:49:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MFgoB21493; Thu, 22 May 2003 11:42:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MCpFB05549 for ; Thu, 22 May 2003 08:51:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12931 for ; Thu, 22 May 2003 09:23:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Iq1F-0001TH-00 for avt@ietf.org; Thu, 22 May 2003 09:22:05 -0400 Received: from ierw.net.avaya.com ([198.152.13.101]) by ietf-mx with esmtp (Exim 4.12) id 19Iq1E-0001T9-00 for avt@ietf.org; Thu, 22 May 2003 09:22:04 -0400 Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21346 for ; Thu, 22 May 2003 09:20:40 -0400 (EDT) Received: from nj7460avexu2.global.avaya.com (h198-152-6-52.avaya.com [198.152.6.52]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21326 for ; Thu, 22 May 2003 09:20:39 -0400 (EDT) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 22 May 2003 09:23:20 -0400 Message-ID: Thread-Topic: [Fwd: Fw: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt] Thread-Index: AcMgYHxjxQ1md5CbRnakW7hbCp8xUQAAcoMA From: "Siddiqui, Anwar A (Anwar)" To: "Colin Perkins" , "Timur Friedman" , "Stephen Casner" , , "Ramon Caceres" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4MCpFB05550 Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Timur, Alan I did mention this during last IETF session. And I believe few other people also have similar concerns. So here is the issue I am requesting this be reconsidered and if possible be avoided. ------------------------------ Is there anyway that we can avoid hard coding VoIP metrics like it is identified in this draft. Its not the usefulness of the metrics that I am having difficulties with. I actually believe they are useful parameters to be included in RTCP. But its just that its hardcoded right now ....and if an RTP source does not have parameters to report it will keep sending these default hard coded values! It is this kind of hardcoding in SR/RR reports that makes us do this XR reports now. So I am requesting if it possible such hard coding of VoIP metrics be avoided. ------------------------------- Thanks in advance Anwar ----- Original Message ----- From: "Colin Perkins" To: "Timur Friedman" Cc: ; "Stephen Casner" ; "Alan Clark" ; "Ramon Caceres" ; "Kevin C. Almeroth" ; "Robert Cole" ; "Nick Duffield" ; "Kaynam Hedayat" ; "Kamil Sarac" ; "Magnus Westerlund" Sent: Monday, May 19, 2003 8:05 PM Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt > Thanks. Unless there are objections, we intend to request that the IESG > consider this version for publication as a proposed standard. > > Colin > > > --> Timur Friedman writes: > >Hello, > > > >Please find attached the latest version of the RTP Control Protocol Extended > >Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. > > > >This draft was produced in response to AVT working group last call comments. > > > >In addition to the changes discussed online on the AVT list, some additional > >detail has been added to the SDP signaling section, to allow individual flags > >in the Statistics Summary report blocks to be signaled. Also, default values > >have been specified for the VoIP metrics section in places where there might > >have been some confusion about what to do if no packets had been received. > >And the time frame over which some of the VoIP fields are calculated has > >also been specified. > > > >A PDF version of this draft is available at the following URL: > > > >http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-report- extns-06.pdf > > > >Regards, > > > >Timur Friedman > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu May 22 12:51:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21165 for ; Thu, 22 May 2003 12:51:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4MGJK424841 for avt-archive@odin.ietf.org; Thu, 22 May 2003 12:19:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MGIKB24811; Thu, 22 May 2003 12:18:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MGERB24658 for ; Thu, 22 May 2003 12:14:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21056 for ; Thu, 22 May 2003 12:46:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ItBp-0003Ro-00 for avt@ietf.org; Thu, 22 May 2003 12:45:13 -0400 Received: from wireless249.east.isi.edu ([65.123.202.249] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19ItBp-0003Rl-00 for avt@ietf.org; Thu, 22 May 2003 12:45:13 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h4MGkWEg075180; Thu, 22 May 2003 12:46:32 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) To: avt@ietf.org cc: casner@acm.org From: Colin Perkins Date: Thu, 22 May 2003 12:46:31 -0400 Message-ID: <75179.1053621991@purple.nge.isi.edu> Subject: [AVT] WG last call: RTP Retransmission Payload Format Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is to announce a working group last call on the RTP Retransmission Payload Format . Please send any final comments on this draft to the mailing list by 30th May 2003. If no substantive technical comments are received by that time, we propose to submit this draft to the IESG for publication as a Proposed Standard RFC. -- Colin Perkins http://csperkins.org/ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 23 13:14:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14379 for ; Fri, 23 May 2003 13:14:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NHEW603972 for avt-archive@odin.ietf.org; Fri, 23 May 2003 13:14:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NHAPB02591; Fri, 23 May 2003 13:10:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4MLSMB12409 for ; Thu, 22 May 2003 17:28:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00535 for ; Thu, 22 May 2003 18:00:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Iy5V-0005Gx-00 for avt@ietf.org; Thu, 22 May 2003 17:59:01 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Iy5V-0005Gu-00 for avt@ietf.org; Thu, 22 May 2003 17:59:01 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h4MLx2L27731 for avt@ietf.org; Thu, 22 May 2003 14:59:02 -0700 Date: Thu, 22 May 2003 14:59:02 -0700 From: John Lazzaro Message-Id: <200305222159.h4MLx2L27731@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] Updated I-D: Framing RTP over TCP/TLS Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi everyone, Just sent in an updated draft of the RTP over TCP/TLS I-D off to internet-drafts@ietf.org. You can download a copy now from: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-contrans.txt I believe this reflects the consensus reached in San Francisco on draft-lazzaro-avt-rtp-framing-contrans-00.txt, and I believe the document satifies http://www.ietf.org/ID-nits.html. The document is very short (8 pages including all the boilerplate), and is essentially rewritten, so there is no change log. Comments are welcome, especially from those who have implemented the framing themselves. I'd like to request WG Item status for the document, and I would think that the rebadged WG Item I-D I would submit (reflecting any comments received) would be ready for Last Call. However, draft-ietf-mmusic-sdp-comedia-05.txt is a normative reference, and so I would guess the progess of the RTP over TCP I-D would be in its wake ... a draft-ietf-mmusic-sdp-comedia-06.txt is expected soon, according to recent mmusic postings by David Yon, and is expected to be "ready for Last Call". ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 23 15:36:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22344 for ; Fri, 23 May 2003 15:36:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4NJZpK23856 for avt-archive@odin.ietf.org; Fri, 23 May 2003 15:35:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NJVUB23681; Fri, 23 May 2003 15:31:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4NDWxB14771 for ; Fri, 23 May 2003 09:32:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05553 for ; Fri, 23 May 2003 10:04:42 -0400 (EDT) From: musicnetwork@violino.dsi.unifi.it Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JD8g-00050K-00 for avt@ietf.org; Fri, 23 May 2003 10:03:18 -0400 Received: from violino.dsi.unifi.it ([150.217.15.208]) by ietf-mx with esmtp (Exim 4.12) id 19JD8a-00050H-00 for avt@ietf.org; Fri, 23 May 2003 10:03:16 -0400 Received: (from musicnetwork@localhost) by violino.dsi.unifi.it (8.8.7/8.8.7) id PAA11825 for avt@ietf.org; Fri, 23 May 2003 15:47:59 +0200 Date: Fri, 23 May 2003 15:47:59 +0200 Message-Id: <200305231347.PAA11825@violino.dsi.unifi.it> X-Authentication-Warning: violino.dsi.unifi.it: Processed from queue /var/spool/bulkmail/musicnetwork/mqueue To: avt@ietf.org Subject: [AVT] CFC: MUSICNETWORK Open Workshop Call, Leeds, UK, September 2003 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , As promised to most of you, we are trying to organise the Second Open workshop of MUSICNETWORK Thematic Network of the European Commission. A service to put together industrial and research communities. http://www.interactivemusicnetwork.org I hope that you can contribute with your valuable activity at the workshop. See in the Following the Call for Contributions. The workshop will be partially overlapped with the WEDELMUSIC conference mainly focussed on research aspects and multimedia, DRM technologies http://www.wedelmusic.org/wedelmusic2003/index.html Specific workshops are going to be organised as additional events. Send an email back with a REMOVE in the subject to musicnetwork@dsi.unifi.it if you prefer to not receivie thie emails in the future. cheers, Paolo Nesi (MUSICNETWORK, Thematic Network of the European Commission) .-.-.-.-.-.-.ò-ò-ò-ò-ò-ò-.-.-.-.-.-ò-ò-ò-ò-ò-.-.-.-.-.-ò-ò-ò-ò-ò- CALL for CONTRIBUTIONS Second MUSICNETWORK Open Workshop University of Leeds, Leeds, UK 17-18 September, 2003, Open to all http://www.interactivemusicnetwork.org Solutions for Music Distribution and Fruition: Two days dedicated to the emerging applications for Music: on the www, multimedia integration and mobile. Tutorials, Products, Best practices, Case Studies and Innovative Applications. The main theme of the Second MUSICNETWORK workshop is dedicated to the state of the art and the identification of the future trends in music. on the WWW, multimedia integration and mobile. The Open Workshop is free, no registration fee is requested to attend the sections of the Workshop. A preliminary registration will be requested to have an estimation of the number of registered people. The workshop is economically supported by the European Commission with the MUSICNETWORK project. The MUSICNETWORK will give space to industries, experts, professionals and research institutions that are working in this sector to present their work in an open environment in which the innovation will be promoted with benefits for all the community. To this end, a set of calls have been opened as described in the following. Deadline for the submission is the 1st of July 2003 according to the following descriptions. *+****+Call for Tutorial*+****+ Tutorial proposals have to be presented as 2-3 pages description including: description of the tutorial, list of the tools mentioned, name and biography of the person giving the tutorial, history of the tutorial if it has been already given other times. The tutorial should be focussed on more than one product and should give a general view of the problems of the topic. The tutorials have to be of 45 minutes and should to be focussed on the following topics: -- production of courseware and content for music education -- production of music scores for publishing -- music distribution and protection -- Standardization: MPEG, SMIL, SVG, XHTML, XML... --…. *+****+Call for Products & Best Practices*+****+ Product presentations have to be proposed as 1-2 pages description as a flyer with possibly a demo to be uploaded on the MUSICNETWORK www site. In addition, it is requested to know: name and biography of the person giving the presentation, material distributed during the workshop, number of customers using the products and a description of its diffusion. The presentation has to be focussed on a general view of the product, architecture, format, most important features, future developments and evolutions, integration and interoperability aspects, etc. The selected Products will be entitled to use the seal "Assessed by MUSICNETWORK". The selected products will have 30 minutes of presentation and should be focussed on the following topics: -- Music educational tools -- Music sheet production tools -- Integration of Music and Multimedia tools -- Digital asset management for music and multimedia archives tools -- Music, Multimedia and Content Protection and distribution tools -- Music tools for impaired people --…. *+****+Call for Case study, Problems*+****+ The case studies have to be proposed with a simple description of the problem. They may be or not accompanied by some examples (or tools that are close to cope with them), and/or by the sketch of an ideal solution. The accepted case studies will be discussed in the Open Workshop and on the WWW site. Each accepted case study will have 10 minutes to explain the problem at the workshop to start the discussion for other 15-20 minutes. Specific experts will be invited by the MUSICNETWORK to cope with the problem explained. The presenter of the problem can even decide to remain anonymous. In that case, one of our experts will explain the problem in front of the audience. Preferred topics are: -- Music notation formats -- Multimedia and music notation -- Music recognition -- … *+****+Call for innovative Applications with demo*+****+ Innovative applications are typically in a middle status from research work and real products. They have been probably proposed in the past as research works while they have not been supported enough to become real products. They have to be proposed as 2-3 pages description as a flyer with possibly a demo to be uploaded on the MUSICNETWORK www site. The selected Applications will be entitled to use the seal "Assessed by MUSICNETWORK". In addition, it is requested to know: name and biography of the person giving the presentation, material distributed during the workshop. Preferred topics are: -- Music notation usage -- Multimedia and music notation -- Music recognition -- … The proposals will be assessed, voted and selected by MUSICNETWORK experts and participants. Among the selected, the best 2-3 proposals for Tutorial, Case Study Problems and innovative Applications categories will be economically supported to attend the workshop and give their presentation, while we will give space to present the results to a very large number of proposals in each category. A large visibility will be given to all proposals on the WWW site. All the proposals will be posted on the WWW site, if this is not acceptable for you please mention in the proposal and email. The documents submitted will be collected and used for creating the Proceedings distributed during the conference and via the WWW site. The selected Products and Applications will be entitled to use the seal "Assessed by MUSICNETWORK". The results of the assessment and the follow up of your presentation at the workshop will be presented on the WWW site. Submissions have to be sent via email to mailto:musicnetwork@dsi.unifi.it within the 1st of July, 2003. The acceptance and the evaluation will be communicated within the 15th of July, 2003. -.-.-.-.-ò-ò-ò-ò-ò-.-.-.-.-ò-ò-ò-ò--ò-.-.-.-.-ò-ò-ò-ò-ò-.-.-.-ò-ò--ò-ò- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat May 24 10:49:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28768 for ; Sat, 24 May 2003 10:49:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4OEmsr09243 for avt-archive@odin.ietf.org; Sat, 24 May 2003 10:48:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4OEi9B09130; Sat, 24 May 2003 10:44:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4OEenB09055 for ; Sat, 24 May 2003 10:40:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28651 for ; Sat, 24 May 2003 10:40:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JaB3-0000ZE-00 for avt@ietf.org; Sat, 24 May 2003 10:39:17 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19JaB2-0000Z5-00 for avt@ietf.org; Sat, 24 May 2003 10:39:16 -0400 Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h4OEdwKw015625; Sat, 24 May 2003 10:39:59 -0400 Message-ID: <018701c32202$5a5b7cd0$c9cc6a9c@cisco.com> From: "Paul E. Jones" To: , "'Siddiqui, Anwar A \(Anwar\)'" , "'Colin Perkins'" , "'Timur Friedman'" , "'Stephen Casner'" , "'Ramon Caceres'" Cc: References: <003001c3206c$6c5e9300$6801a8c0@telchemy.com> Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Date: Sat, 24 May 2003 10:39:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Alan, I still think we should allow every field to be optional. I recognize the desire to encourage reporting a complete set of stats, but I would tend to believe that there will be environments wherein not all stats are necessary. Now, not to sound that I'm in disagreement with Anwar, but I think it might be useful to allow one to indicate that a particular parameter is not measured by populating the field with some default value. This default value would not indicate a "valid", but be an indicator of the fact that the field is not present. This would address your concern that the fields and reporting blocks are fixed in size. I also realize that some time will be wasted to determine that a measurement is not present, but the same amount of time will be consumed by a system to extract a valid value today. So, the system performance is the same, albeit with potentially less useful data. Paul ----- Original Message ----- From: "Alan Clark" To: "'Siddiqui, Anwar A (Anwar)'" ; "'Colin Perkins'" ; "'Timur Friedman'" ; "'Stephen Casner'" ; "'Ramon Caceres'" Cc: Sent: Thursday, May 22, 2003 10:14 AM Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > Anwar > > This was brought up several weeks ago on the mailing list. This approach > was taken deliberately for several reasons:- > > (i) To encourage implementors to move towards implementing the complete set > of metrics. I've socialized this data set with a variety of service > providers, enterprise network managers, equipment manufacturers and there > seems to be general agreement that this metrics set provides a good "minimum > set" for diagnosing VoIP performance problems. > > (ii) There is overhead associated with identifying whether fields are or are > not present (see Colin Perkins comment on this issue several weeks ago). > > I am aware of several major equipment manufacturers and DSP software vendors > that intend to fully implement the RTCP XR VoIP metrics, and several tier > one carriers that are currently specifying that this metric set be used for > VoIP service management. There is also considerable interest from other > standards groups in this work. > > Regards > > Alan Clark > Telchemy > > -----Original Message----- > From: Siddiqui, Anwar A (Anwar) [mailto:anwars@avaya.com] > Sent: Thursday, May 22, 2003 9:23 AM > To: Colin Perkins; Timur Friedman; Stephen Casner; alan@telchemy.com; > Ramon Caceres > Cc: avt@ietf.org > Subject: Re: draft-ietf-avt-rtcp-report-extns-06.txt > > > Timur, Alan > > I did mention this during last IETF session. And I believe few other people > also have similar concerns. So here is the issue I am requesting this be > reconsidered and if possible be avoided. > > ------------------------------ > Is there anyway that we can avoid hard coding VoIP metrics like it is > identified in this draft. Its not the usefulness of the metrics that I am > having difficulties with. I actually believe they are useful parameters to > be included in RTCP. But its just that its hardcoded right now ....and if an > RTP source does not have parameters to report it will keep sending these > default hard coded values! It is this kind of hardcoding in SR/RR reports > that makes us do this XR reports now. So I am requesting if it possible such > hard coding of VoIP metrics be avoided. > ------------------------------- > > Thanks in advance > > Anwar > > > > ----- Original Message ----- > From: "Colin Perkins" > To: "Timur Friedman" > Cc: ; "Stephen Casner" ; "Alan Clark" > ; "Ramon Caceres" ; "Kevin C. > Almeroth" ; "Robert Cole" ; "Nick > Duffield" ; "Kaynam Hedayat" > ; "Kamil Sarac" ; "Magnus > Westerlund" > Sent: Monday, May 19, 2003 8:05 PM > Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt > > > > Thanks. Unless there are objections, we intend to request that the IESG > > consider this version for publication as a proposed standard. > > > > Colin > > > > > > --> Timur Friedman writes: > > >Hello, > > > > > >Please find attached the latest version of the RTP Control Protocol > Extended > > >Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. > > > > > >This draft was produced in response to AVT working group last call > comments. > > > > > >In addition to the changes discussed online on the AVT list, some > additional > > >detail has been added to the SDP signaling section, to allow individual > flags > > >in the Statistics Summary report blocks to be signaled. Also, default > values > > >have been specified for the VoIP metrics section in places where there > might > > >have been some confusion about what to do if no packets had been > received. > > >And the time frame over which some of the VoIP fields are calculated has > > >also been specified. > > > > > >A PDF version of this draft is available at the following URL: > > > > > > >http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-report- > extns-06.pdf > > > > > >Regards, > > > > > >Timur Friedman > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat May 24 10:54:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28893 for ; Sat, 24 May 2003 10:54:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4OErlV09492 for avt-archive@odin.ietf.org; Sat, 24 May 2003 10:53:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4OEr9B09446; Sat, 24 May 2003 10:53:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4OEoLB09294 for ; Sat, 24 May 2003 10:50:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28788 for ; Sat, 24 May 2003 10:50:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JaKH-0000bd-00 for avt@ietf.org; Sat, 24 May 2003 10:48:49 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19JaKG-0000ba-00 for avt@ietf.org; Sat, 24 May 2003 10:48:48 -0400 Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h4OEoDKw015640; Sat, 24 May 2003 10:50:15 -0400 Message-ID: <019c01c32203$c84a3aa0$c9cc6a9c@cisco.com> From: "Paul E. Jones" To: "Miao, Kai" , References: <3D90571297ABD511957400508BF29C43043EA7CD@pysmsx101.py.intel.com> Subject: Re: [AVT] FAX/RTP Date: Sat, 24 May 2003 10:50:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Kai, Yes. This is being worked on right now in ITU-T Q.14/SG16. Paul ----- Original Message ----- From: "Miao, Kai" To: Sent: Tuesday, May 13, 2003 5:15 PM Subject: [AVT] FAX/RTP > Anyone is still working on fax/RTP, to replace T.38 UDPTL? > > Kai Miao > Intel > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun May 25 08:20:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28924 for ; Sun, 25 May 2003 08:20:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4PCJoL30552 for avt-archive@odin.ietf.org; Sun, 25 May 2003 08:19:50 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PCG8B30437; Sun, 25 May 2003 08:16:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PC8pB30199 for ; Sun, 25 May 2003 08:08:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28682 for ; Sun, 25 May 2003 08:08:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JuHY-0005aO-00 for avt@ietf.org; Sun, 25 May 2003 08:07:20 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19JuHX-0005Zx-00 for avt@ietf.org; Sun, 25 May 2003 08:07:20 -0400 Received: from alansnotebook [66.156.10.119] by telchemy.com with ESMTP (SMTPD32-7.14) id A21BEE30250; Sun, 25 May 2003 08:07:55 -0400 From: "Alan Clark" To: "Paul E. Jones" , "'Siddiqui, Anwar A \(Anwar\)'" , "'Colin Perkins'" , "'Timur Friedman'" , "'Stephen Casner'" , "'Ramon Caceres'" Cc: Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Date: Sun, 25 May 2003 08:11:43 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <018701c32202$5a5b7cd0$c9cc6a9c@cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul If you bear in mind that RTCP XR is likely to be used to exchange information between endpoints through the media path then there are several implementation considerations. (i) It is quite likely that intermediate systems such as Ethernet switches, edge routers and shapers may scan RTCP XR payloads. A number of such systems already do this with RTCP SR/RR reports, either for QoS monitoring or for active control. With switch speeds getting to 10 gigabit then it is important to keep parsing complexity very low. (ii) High density gateways are pushing the density of CODECs per DSP but also pushing RTP packet processing into the DSP. This places severe constraints on the available program and data memory space - again a strong incentive to keep things as simple as possible. Regards Alan -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Saturday, May 24, 2003 10:40 AM To: alan@telchemy.com; 'Siddiqui, Anwar A (Anwar)'; 'Colin Perkins'; 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' Cc: avt@ietf.org Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Alan, I still think we should allow every field to be optional. I recognize the desire to encourage reporting a complete set of stats, but I would tend to believe that there will be environments wherein not all stats are necessary. Now, not to sound that I'm in disagreement with Anwar, but I think it might be useful to allow one to indicate that a particular parameter is not measured by populating the field with some default value. This default value would not indicate a "valid", but be an indicator of the fact that the field is not present. This would address your concern that the fields and reporting blocks are fixed in size. I also realize that some time will be wasted to determine that a measurement is not present, but the same amount of time will be consumed by a system to extract a valid value today. So, the system performance is the same, albeit with potentially less useful data. Paul ----- Original Message ----- From: "Alan Clark" To: "'Siddiqui, Anwar A (Anwar)'" ; "'Colin Perkins'" ; "'Timur Friedman'" ; "'Stephen Casner'" ; "'Ramon Caceres'" Cc: Sent: Thursday, May 22, 2003 10:14 AM Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > Anwar > > This was brought up several weeks ago on the mailing list. This approach > was taken deliberately for several reasons:- > > (i) To encourage implementors to move towards implementing the complete set > of metrics. I've socialized this data set with a variety of service > providers, enterprise network managers, equipment manufacturers and there > seems to be general agreement that this metrics set provides a good "minimum > set" for diagnosing VoIP performance problems. > > (ii) There is overhead associated with identifying whether fields are or are > not present (see Colin Perkins comment on this issue several weeks ago). > > I am aware of several major equipment manufacturers and DSP software vendors > that intend to fully implement the RTCP XR VoIP metrics, and several tier > one carriers that are currently specifying that this metric set be used for > VoIP service management. There is also considerable interest from other > standards groups in this work. > > Regards > > Alan Clark > Telchemy > > -----Original Message----- > From: Siddiqui, Anwar A (Anwar) [mailto:anwars@avaya.com] > Sent: Thursday, May 22, 2003 9:23 AM > To: Colin Perkins; Timur Friedman; Stephen Casner; alan@telchemy.com; > Ramon Caceres > Cc: avt@ietf.org > Subject: Re: draft-ietf-avt-rtcp-report-extns-06.txt > > > Timur, Alan > > I did mention this during last IETF session. And I believe few other people > also have similar concerns. So here is the issue I am requesting this be > reconsidered and if possible be avoided. > > ------------------------------ > Is there anyway that we can avoid hard coding VoIP metrics like it is > identified in this draft. Its not the usefulness of the metrics that I am > having difficulties with. I actually believe they are useful parameters to > be included in RTCP. But its just that its hardcoded right now ....and if an > RTP source does not have parameters to report it will keep sending these > default hard coded values! It is this kind of hardcoding in SR/RR reports > that makes us do this XR reports now. So I am requesting if it possible such > hard coding of VoIP metrics be avoided. > ------------------------------- > > Thanks in advance > > Anwar > > > > ----- Original Message ----- > From: "Colin Perkins" > To: "Timur Friedman" > Cc: ; "Stephen Casner" ; "Alan Clark" > ; "Ramon Caceres" ; "Kevin C. > Almeroth" ; "Robert Cole" ; "Nick > Duffield" ; "Kaynam Hedayat" > ; "Kamil Sarac" ; "Magnus > Westerlund" > Sent: Monday, May 19, 2003 8:05 PM > Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt > > > > Thanks. Unless there are objections, we intend to request that the IESG > > consider this version for publication as a proposed standard. > > > > Colin > > > > > > --> Timur Friedman writes: > > >Hello, > > > > > >Please find attached the latest version of the RTP Control Protocol > Extended > > >Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. > > > > > >This draft was produced in response to AVT working group last call > comments. > > > > > >In addition to the changes discussed online on the AVT list, some > additional > > >detail has been added to the SDP signaling section, to allow individual > flags > > >in the Statistics Summary report blocks to be signaled. Also, default > values > > >have been specified for the VoIP metrics section in places where there > might > > >have been some confusion about what to do if no packets had been > received. > > >And the time frame over which some of the VoIP fields are calculated has > > >also been specified. > > > > > >A PDF version of this draft is available at the following URL: > > > > > > >http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-report- > extns-06.pdf > > > > > >Regards, > > > > > >Timur Friedman > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun May 25 08:55:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29415 for ; Sun, 25 May 2003 08:55:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4PCtQE32662 for avt-archive@odin.ietf.org; Sun, 25 May 2003 08:55:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PCt0B32644; Sun, 25 May 2003 08:55:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PCotB32583 for ; Sun, 25 May 2003 08:50:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29370 for ; Sun, 25 May 2003 08:50:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19JuwF-0005nI-00 for avt@ietf.org; Sun, 25 May 2003 08:49:23 -0400 Received: from 212.199.61.2.forward.012.net.il ([212.199.61.2] helo=accord-ntsrv3.polycom.co.il) by ietf-mx with esmtp (Exim 4.12) id 19JuwD-0005nF-00 for avt@ietf.org; Sun, 25 May 2003 08:49:21 -0400 Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Sun, 25 May 2003 15:50:21 +0300 Message-ID: From: "Even, Roni" To: "'Alan Clark'" , "Paul E. Jones" , "'Siddiqui, Anwar A (Anwar)'" , "'Colin Perkins'" , "'Timur Friedman'" , "'Stephen Casner'" , "'Ramon Caceres'" Cc: avt@ietf.org Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Date: Sun, 25 May 2003 15:50:17 +0300 X-Mailer: Internet Mail Service (5.5.2656.59) Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Alan, I agree with Paul Jones. Your answer may be right but Paul pointed out that there are other environments that may not need all the stats. So why mandate it for them. I thought that the extensions are for all and not for a specific implementation Thanks Roni Even > -----Original Message----- > From: Alan Clark [mailto:alan@telchemy.com] > Sent: Sunday, May 25, 2003 3:12 PM > To: Paul E. Jones; 'Siddiqui, Anwar A (Anwar)'; 'Colin > Perkins'; 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' > Cc: avt@ietf.org > Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > > Paul > > If you bear in mind that RTCP XR is likely to be used to exchange > information between endpoints through the media path then > there are several > implementation considerations. > > (i) It is quite likely that intermediate systems such as > Ethernet switches, > edge routers and shapers may scan RTCP XR payloads. A number of such > systems already do this with RTCP SR/RR reports, either for > QoS monitoring > or for active control. With switch speeds getting to 10 > gigabit then it is > important to keep parsing complexity very low. > > (ii) High density gateways are pushing the density of CODECs > per DSP but > also pushing RTP packet processing into the DSP. This places severe > constraints on the available program and data memory space - > again a strong > incentive to keep things as simple as possible. > > Regards > > Alan > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Saturday, May 24, 2003 10:40 AM > To: alan@telchemy.com; 'Siddiqui, Anwar A (Anwar)'; 'Colin Perkins'; > 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' > Cc: avt@ietf.org > Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > > Alan, > > I still think we should allow every field to be optional. I > recognize the > desire to encourage reporting a complete set of stats, but I > would tend to > believe that there will be environments wherein not all stats > are necessary. > > Now, not to sound that I'm in disagreement with Anwar, but I > think it might > be useful to allow one to indicate that a particular parameter is not > measured by populating the field with some default value. > This default > value would not indicate a "valid", but be an indicator of > the fact that the > field is not present. This would address your concern that > the fields and > reporting blocks are fixed in size. > > I also realize that some time will be wasted to determine > that a measurement > is not present, but the same amount of time will be consumed > by a system to > extract a valid value today. So, the system performance is > the same, albeit > with potentially less useful data. > > Paul > > ----- Original Message ----- > From: "Alan Clark" > To: "'Siddiqui, Anwar A (Anwar)'" ; "'Colin > Perkins'" > ; "'Timur Friedman'" > ; "'Stephen > Casner'" ; "'Ramon Caceres'" > Cc: > Sent: Thursday, May 22, 2003 10:14 AM > Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > > > Anwar > > > > This was brought up several weeks ago on the mailing list. > This approach > > was taken deliberately for several reasons:- > > > > (i) To encourage implementors to move towards implementing > the complete > set > > of metrics. I've socialized this data set with a variety of service > > providers, enterprise network managers, equipment > manufacturers and there > > seems to be general agreement that this metrics set provides a good > "minimum > > set" for diagnosing VoIP performance problems. > > > > (ii) There is overhead associated with identifying whether > fields are or > are > > not present (see Colin Perkins comment on this issue > several weeks ago). > > > > I am aware of several major equipment manufacturers and DSP software > vendors > > that intend to fully implement the RTCP XR VoIP metrics, > and several tier > > one carriers that are currently specifying that this metric > set be used > for > > VoIP service management. There is also considerable > interest from other > > standards groups in this work. > > > > Regards > > > > Alan Clark > > Telchemy > > > > -----Original Message----- > > From: Siddiqui, Anwar A (Anwar) [mailto:anwars@avaya.com] > > Sent: Thursday, May 22, 2003 9:23 AM > > To: Colin Perkins; Timur Friedman; Stephen Casner; > alan@telchemy.com; > > Ramon Caceres > > Cc: avt@ietf.org > > Subject: Re: draft-ietf-avt-rtcp-report-extns-06.txt > > > > > > Timur, Alan > > > > I did mention this during last IETF session. And I believe few other > people > > also have similar concerns. So here is the issue I am > requesting this be > > reconsidered and if possible be avoided. > > > > ------------------------------ > > Is there anyway that we can avoid hard coding VoIP metrics > like it is > > identified in this draft. Its not the usefulness of the > metrics that I am > > having difficulties with. I actually believe they are > useful parameters to > > be included in RTCP. But its just that its hardcoded right > now ....and if > an > > RTP source does not have parameters to report it will keep > sending these > > default hard coded values! It is this kind of hardcoding in > SR/RR reports > > that makes us do this XR reports now. So I am requesting if > it possible > such > > hard coding of VoIP metrics be avoided. > > ------------------------------- > > > > Thanks in advance > > > > Anwar > > > > > > > > ----- Original Message ----- > > From: "Colin Perkins" > > To: "Timur Friedman" > > Cc: ; "Stephen Casner" ; "Alan Clark" > > ; "Ramon Caceres" ; "Kevin C. > > Almeroth" ; "Robert Cole" > ; "Nick > > Duffield" ; "Kaynam Hedayat" > > ; "Kamil Sarac" ; "Magnus > > Westerlund" > > Sent: Monday, May 19, 2003 8:05 PM > > Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt > > > > > > > Thanks. Unless there are objections, we intend to request > that the IESG > > > consider this version for publication as a proposed standard. > > > > > > Colin > > > > > > > > > --> Timur Friedman writes: > > > >Hello, > > > > > > > >Please find attached the latest version of the RTP > Control Protocol > > Extended > > > >Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. > > > > > > > >This draft was produced in response to AVT working group > last call > > comments. > > > > > > > >In addition to the changes discussed online on the AVT list, some > > additional > > > >detail has been added to the SDP signaling section, to > allow individual > > flags > > > >in the Statistics Summary report blocks to be signaled. > Also, default > > values > > > >have been specified for the VoIP metrics section in > places where there > > might > > > >have been some confusion about what to do if no packets had been > > received. > > > >And the time frame over which some of the VoIP fields > are calculated > has > > > >also been specified. > > > > > > > >A PDF version of this draft is available at the following URL: > > > > > > > > > > >http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-av > t-rtcp-report- > > extns-06.pdf > > > > > > > >Regards, > > > > > > > >Timur Friedman > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun May 25 18:00:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12675 for ; Sun, 25 May 2003 18:00:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4PLxxL02479 for avt-archive@odin.ietf.org; Sun, 25 May 2003 17:59:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PLu6B02313; Sun, 25 May 2003 17:56:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PLlUB02126 for ; Sun, 25 May 2003 17:47:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12399 for ; Sun, 25 May 2003 17:47:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19K3JK-0001Au-00 for avt@ietf.org; Sun, 25 May 2003 17:45:46 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19K3JJ-0001Af-00 for avt@ietf.org; Sun, 25 May 2003 17:45:45 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h4PLkdNb012533; Sun, 25 May 2003 14:46:39 -0700 (PDT) Received: from [10.32.254.189] (stealth-10-32-254-189.cisco.com [10.32.254.189]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AEL99661; Sun, 25 May 2003 14:46:35 -0700 (PDT) Date: Sun, 25 May 2003 17:46:26 -0400 From: "David R. Oran" To: Alan Clark , "Paul E. Jones" , "'Siddiqui, Anwar A (Anwar)'" , "'Colin Perkins'" , "'Timur Friedman'" , "'Stephen Casner'" , "'Ramon Caceres'" cc: avt@ietf.org Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Message-ID: <449304937.1053884786@[10.32.254.189]> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Sunday, May 25, 2003 8:11 AM -0400 Alan Clark wrote: > Paul > > If you bear in mind that RTCP XR is likely to be used to exchange > information between endpoints through the media path then there are > several implementation considerations. > > (i) It is quite likely that intermediate systems such as Ethernet > switches, edge routers and shapers may scan RTCP XR payloads. A number > of such systems already do this with RTCP SR/RR reports, either for QoS > monitoring or for active control. With switch speeds getting to 10 > gigabit then it is important to keep parsing complexity very low. > Really? Boy, I'm glad I'm using SRTP and encrypting my RTCP packets. Put another way, I don't find snooping to be a valid argument in favor of fast parsing. That said, I do prefer to have an encoding which uses "value not valid" semantics rather than "value not present", because, like is done with IEEE floating point, it has much better robustness in the face of cascaded computations that may use inappropriate arithmetic. In fact, I think that's where the real savings is - in not having to scatter your data reduction for stats with a zillion if tests and multiple code patsh based on what dat ayou have. You just do the computation and error propagation will take care of ensuring that invalid stuff is marked as such. > (ii) High density gateways are pushing the density of CODECs per DSP but > also pushing RTP packet processing into the DSP. This places severe > constraints on the available program and data memory space - again a > strong incentive to keep things as simple as possible. > Simplicity does resonate as a good argument here. Dave. > Regards > > Alan > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Saturday, May 24, 2003 10:40 AM > To: alan@telchemy.com; 'Siddiqui, Anwar A (Anwar)'; 'Colin Perkins'; > 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' > Cc: avt@ietf.org > Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > > Alan, > > I still think we should allow every field to be optional. I recognize the > desire to encourage reporting a complete set of stats, but I would tend to > believe that there will be environments wherein not all stats are > necessary. > > Now, not to sound that I'm in disagreement with Anwar, but I think it > might be useful to allow one to indicate that a particular parameter is > not measured by populating the field with some default value. This > default value would not indicate a "valid", but be an indicator of the > fact that the field is not present. This would address your concern that > the fields and reporting blocks are fixed in size. > > I also realize that some time will be wasted to determine that a > measurement is not present, but the same amount of time will be consumed > by a system to extract a valid value today. So, the system performance > is the same, albeit with potentially less useful data. > > Paul > > ----- Original Message ----- > From: "Alan Clark" > To: "'Siddiqui, Anwar A (Anwar)'" ; "'Colin Perkins'" > ; "'Timur Friedman'" ; > "'Stephen Casner'" ; "'Ramon Caceres'" > Cc: > Sent: Thursday, May 22, 2003 10:14 AM > Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > >> Anwar >> >> This was brought up several weeks ago on the mailing list. This approach >> was taken deliberately for several reasons:- >> >> (i) To encourage implementors to move towards implementing the complete > set >> of metrics. I've socialized this data set with a variety of service >> providers, enterprise network managers, equipment manufacturers and there >> seems to be general agreement that this metrics set provides a good > "minimum >> set" for diagnosing VoIP performance problems. >> >> (ii) There is overhead associated with identifying whether fields are or > are >> not present (see Colin Perkins comment on this issue several weeks ago). >> >> I am aware of several major equipment manufacturers and DSP software > vendors >> that intend to fully implement the RTCP XR VoIP metrics, and several tier >> one carriers that are currently specifying that this metric set be used > for >> VoIP service management. There is also considerable interest from other >> standards groups in this work. >> >> Regards >> >> Alan Clark >> Telchemy >> >> -----Original Message----- >> From: Siddiqui, Anwar A (Anwar) [mailto:anwars@avaya.com] >> Sent: Thursday, May 22, 2003 9:23 AM >> To: Colin Perkins; Timur Friedman; Stephen Casner; alan@telchemy.com; >> Ramon Caceres >> Cc: avt@ietf.org >> Subject: Re: draft-ietf-avt-rtcp-report-extns-06.txt >> >> >> Timur, Alan >> >> I did mention this during last IETF session. And I believe few other > people >> also have similar concerns. So here is the issue I am requesting this be >> reconsidered and if possible be avoided. >> >> ------------------------------ >> Is there anyway that we can avoid hard coding VoIP metrics like it is >> identified in this draft. Its not the usefulness of the metrics that I am >> having difficulties with. I actually believe they are useful parameters >> to be included in RTCP. But its just that its hardcoded right now >> ....and if > an >> RTP source does not have parameters to report it will keep sending these >> default hard coded values! It is this kind of hardcoding in SR/RR reports >> that makes us do this XR reports now. So I am requesting if it possible > such >> hard coding of VoIP metrics be avoided. >> ------------------------------- >> >> Thanks in advance >> >> Anwar >> >> >> >> ----- Original Message ----- >> From: "Colin Perkins" >> To: "Timur Friedman" >> Cc: ; "Stephen Casner" ; "Alan Clark" >> ; "Ramon Caceres" ; "Kevin C. >> Almeroth" ; "Robert Cole" ; "Nick >> Duffield" ; "Kaynam Hedayat" >> ; "Kamil Sarac" ; "Magnus >> Westerlund" >> Sent: Monday, May 19, 2003 8:05 PM >> Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt >> >> >> > Thanks. Unless there are objections, we intend to request that the IESG >> > consider this version for publication as a proposed standard. >> > >> > Colin >> > >> > >> > --> Timur Friedman writes: >> > > Hello, >> > > >> > > Please find attached the latest version of the RTP Control Protocol >> Extended >> > > Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. >> > > >> > > This draft was produced in response to AVT working group last call >> comments. >> > > >> > > In addition to the changes discussed online on the AVT list, some >> additional >> > > detail has been added to the SDP signaling section, to allow >> > > individual >> flags >> > > in the Statistics Summary report blocks to be signaled. Also, >> > > default >> values >> > > have been specified for the VoIP metrics section in places where >> > > there >> might >> > > have been some confusion about what to do if no packets had been >> received. >> > > And the time frame over which some of the VoIP fields are calculated > has >> > > also been specified. >> > > >> > > A PDF version of this draft is available at the following URL: >> > > >> > >> >> http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-repo >> rt- extns-06.pdf >> > > >> > > Regards, >> > > >> > > Timur Friedman >> > _______________________________________________ >> > Audio/Video Transport Working Group >> > avt@ietf.org >> > https://www1.ietf.org/mailman/listinfo/avt >> > >> > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun May 25 19:10:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15219 for ; Sun, 25 May 2003 19:10:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4PNAMh06934 for avt-archive@odin.ietf.org; Sun, 25 May 2003 19:10:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PN6jB06003; Sun, 25 May 2003 19:06:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4PMwiB05737 for ; Sun, 25 May 2003 18:58:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14906 for ; Sun, 25 May 2003 18:58:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19K4QE-0001Xk-00 for avt@ietf.org; Sun, 25 May 2003 18:56:58 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19K4QE-0001XM-00 for avt@ietf.org; Sun, 25 May 2003 18:56:58 -0400 Received: from alansnotebook [66.156.21.98] by telchemy.com with ESMTP (SMTPD32-7.14) id AA5BA33020C; Sun, 25 May 2003 18:57:31 -0400 From: "Alan Clark" To: "David R. Oran" , "Paul E. Jones" , "'Colin Perkins'" , "'Timur Friedman'" , "'Stephen Casner'" , "'Ramon Caceres'" Cc: Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Date: Sun, 25 May 2003 19:01:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <449304937.1053884786@[10.32.254.189]> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dave, RTCP XR can be extremely useful in supporting problem detection, call admission control etc. as it provides a fast method for a probe, analyzer, session controller... to get call quality related information from the endpoint. In general the data available in RTCP XR should not represent a security concern - unlike SDES - and hence (I think) there is no advantage to applying encryption and considerable disadvantage. In an Enterprise network using VPN for inter-site connections you could consider using SRTP for RTP payloads and rely on the VPN tunnel to protect RTCP SDES information, which is a good compromise between management and security. In some other applications, notably IP Centrex, the service provider is already handling signaling - RTCP XR gives them feedback on call quality from the customer desktop and alerts them to customer LAN problems that affect call quality. Regards Alan -----Original Message----- From: David R. Oran [mailto:oran@cisco.com] Sent: Sunday, May 25, 2003 5:46 PM To: Alan Clark; Paul E. Jones; 'Siddiqui, Anwar A (Anwar)'; 'Colin Perkins'; 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' Cc: avt@ietf.org Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt --On Sunday, May 25, 2003 8:11 AM -0400 Alan Clark wrote: > Paul > > If you bear in mind that RTCP XR is likely to be used to exchange > information between endpoints through the media path then there are > several implementation considerations. > > (i) It is quite likely that intermediate systems such as Ethernet > switches, edge routers and shapers may scan RTCP XR payloads. A number > of such systems already do this with RTCP SR/RR reports, either for QoS > monitoring or for active control. With switch speeds getting to 10 > gigabit then it is important to keep parsing complexity very low. > Really? Boy, I'm glad I'm using SRTP and encrypting my RTCP packets. Put another way, I don't find snooping to be a valid argument in favor of fast parsing. That said, I do prefer to have an encoding which uses "value not valid" semantics rather than "value not present", because, like is done with IEEE floating point, it has much better robustness in the face of cascaded computations that may use inappropriate arithmetic. In fact, I think that's where the real savings is - in not having to scatter your data reduction for stats with a zillion if tests and multiple code patsh based on what dat ayou have. You just do the computation and error propagation will take care of ensuring that invalid stuff is marked as such. > (ii) High density gateways are pushing the density of CODECs per DSP but > also pushing RTP packet processing into the DSP. This places severe > constraints on the available program and data memory space - again a > strong incentive to keep things as simple as possible. > Simplicity does resonate as a good argument here. Dave. > Regards > > Alan > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Saturday, May 24, 2003 10:40 AM > To: alan@telchemy.com; 'Siddiqui, Anwar A (Anwar)'; 'Colin Perkins'; > 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' > Cc: avt@ietf.org > Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > > Alan, > > I still think we should allow every field to be optional. I recognize the > desire to encourage reporting a complete set of stats, but I would tend to > believe that there will be environments wherein not all stats are > necessary. > > Now, not to sound that I'm in disagreement with Anwar, but I think it > might be useful to allow one to indicate that a particular parameter is > not measured by populating the field with some default value. This > default value would not indicate a "valid", but be an indicator of the > fact that the field is not present. This would address your concern that > the fields and reporting blocks are fixed in size. > > I also realize that some time will be wasted to determine that a > measurement is not present, but the same amount of time will be consumed > by a system to extract a valid value today. So, the system performance > is the same, albeit with potentially less useful data. > > Paul > > ----- Original Message ----- > From: "Alan Clark" > To: "'Siddiqui, Anwar A (Anwar)'" ; "'Colin Perkins'" > ; "'Timur Friedman'" ; > "'Stephen Casner'" ; "'Ramon Caceres'" > Cc: > Sent: Thursday, May 22, 2003 10:14 AM > Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > >> Anwar >> >> This was brought up several weeks ago on the mailing list. This approach >> was taken deliberately for several reasons:- >> >> (i) To encourage implementors to move towards implementing the complete > set >> of metrics. I've socialized this data set with a variety of service >> providers, enterprise network managers, equipment manufacturers and there >> seems to be general agreement that this metrics set provides a good > "minimum >> set" for diagnosing VoIP performance problems. >> >> (ii) There is overhead associated with identifying whether fields are or > are >> not present (see Colin Perkins comment on this issue several weeks ago). >> >> I am aware of several major equipment manufacturers and DSP software > vendors >> that intend to fully implement the RTCP XR VoIP metrics, and several tier >> one carriers that are currently specifying that this metric set be used > for >> VoIP service management. There is also considerable interest from other >> standards groups in this work. >> >> Regards >> >> Alan Clark >> Telchemy >> >> -----Original Message----- >> From: Siddiqui, Anwar A (Anwar) [mailto:anwars@avaya.com] >> Sent: Thursday, May 22, 2003 9:23 AM >> To: Colin Perkins; Timur Friedman; Stephen Casner; alan@telchemy.com; >> Ramon Caceres >> Cc: avt@ietf.org >> Subject: Re: draft-ietf-avt-rtcp-report-extns-06.txt >> >> >> Timur, Alan >> >> I did mention this during last IETF session. And I believe few other > people >> also have similar concerns. So here is the issue I am requesting this be >> reconsidered and if possible be avoided. >> >> ------------------------------ >> Is there anyway that we can avoid hard coding VoIP metrics like it is >> identified in this draft. Its not the usefulness of the metrics that I am >> having difficulties with. I actually believe they are useful parameters >> to be included in RTCP. But its just that its hardcoded right now >> ....and if > an >> RTP source does not have parameters to report it will keep sending these >> default hard coded values! It is this kind of hardcoding in SR/RR reports >> that makes us do this XR reports now. So I am requesting if it possible > such >> hard coding of VoIP metrics be avoided. >> ------------------------------- >> >> Thanks in advance >> >> Anwar >> >> >> >> ----- Original Message ----- >> From: "Colin Perkins" >> To: "Timur Friedman" >> Cc: ; "Stephen Casner" ; "Alan Clark" >> ; "Ramon Caceres" ; "Kevin C. >> Almeroth" ; "Robert Cole" ; "Nick >> Duffield" ; "Kaynam Hedayat" >> ; "Kamil Sarac" ; "Magnus >> Westerlund" >> Sent: Monday, May 19, 2003 8:05 PM >> Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt >> >> >> > Thanks. Unless there are objections, we intend to request that the IESG >> > consider this version for publication as a proposed standard. >> > >> > Colin >> > >> > >> > --> Timur Friedman writes: >> > > Hello, >> > > >> > > Please find attached the latest version of the RTP Control Protocol >> Extended >> > > Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. >> > > >> > > This draft was produced in response to AVT working group last call >> comments. >> > > >> > > In addition to the changes discussed online on the AVT list, some >> additional >> > > detail has been added to the SDP signaling section, to allow >> > > individual >> flags >> > > in the Statistics Summary report blocks to be signaled. Also, >> > > default >> values >> > > have been specified for the VoIP metrics section in places where >> > > there >> might >> > > have been some confusion about what to do if no packets had been >> received. >> > > And the time frame over which some of the VoIP fields are calculated > has >> > > also been specified. >> > > >> > > A PDF version of this draft is available at the following URL: >> > > >> > >> >> http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-repo >> rt- extns-06.pdf >> > > >> > > Regards, >> > > >> > > Timur Friedman >> > _______________________________________________ >> > Audio/Video Transport Working Group >> > avt@ietf.org >> > https://www1.ietf.org/mailman/listinfo/avt >> > >> > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 26 03:19:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04483 for ; Mon, 26 May 2003 03:19:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4Q7JSf14414 for avt-archive@odin.ietf.org; Mon, 26 May 2003 03:19:28 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4Q7FjB14260; Mon, 26 May 2003 03:15:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4Q7ChB14134 for ; Mon, 26 May 2003 03:12:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04276 for ; Mon, 26 May 2003 03:12:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KC87-00045B-00 for avt@ietf.org; Mon, 26 May 2003 03:10:47 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.tn.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19KC86-000458-00 for avt@ietf.org; Mon, 26 May 2003 03:10:46 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4Q7CH0J017109; Mon, 26 May 2003 09:12:17 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LFPFL3K5; Mon, 26 May 2003 09:12:37 +0200 Message-ID: <3ED1BDCA.1000604@ericsson.com> Date: Mon, 26 May 2003 09:10:02 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alan Clark CC: avt@ietf.org Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, Looking at this discussion it seems that one can make two resolutions. 1. Do not mandate calculation of all fields in report block. I would think that a SHOULD calculate all field is a good level. Text motivating that all fields should be calculated is good. 2. Keep the structure as is, define for each field a "NOT VALID" value. I think this is reasonable compromise. It keeps the VoIP report block simple to process and at the same time a implementor that is unable to provide a measurement does not need to. Best Regards Magnus Alan Clark wrote: > Dave, > > RTCP XR can be extremely useful in supporting problem detection, call > admission control etc. as it provides a fast method for a probe, analyzer, > session controller... to get call quality related information from the > endpoint. In general the data available in RTCP XR should not represent a > security concern - unlike SDES - and hence (I think) there is no advantage > to applying encryption and considerable disadvantage. > > In an Enterprise network using VPN for inter-site connections you could > consider using SRTP for RTP payloads and rely on the VPN tunnel to protect > RTCP SDES information, which is a good compromise between management and > security. In some other applications, notably IP Centrex, the service > provider is already handling signaling - RTCP XR gives them feedback on call > quality from the customer desktop and alerts them to customer LAN problems > that affect call quality. > > Regards > > Alan > > > > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Sunday, May 25, 2003 5:46 PM > To: Alan Clark; Paul E. Jones; 'Siddiqui, Anwar A (Anwar)'; 'Colin > Perkins'; 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' > Cc: avt@ietf.org > Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > > --On Sunday, May 25, 2003 8:11 AM -0400 Alan Clark > wrote: > > >>Paul >> >>If you bear in mind that RTCP XR is likely to be used to exchange >>information between endpoints through the media path then there are >>several implementation considerations. >> >>(i) It is quite likely that intermediate systems such as Ethernet >>switches, edge routers and shapers may scan RTCP XR payloads. A number >>of such systems already do this with RTCP SR/RR reports, either for QoS >>monitoring or for active control. With switch speeds getting to 10 >>gigabit then it is important to keep parsing complexity very low. >> > > Really? Boy, I'm glad I'm using SRTP and encrypting my RTCP packets. Put > another way, I don't find snooping to be a valid argument in favor of fast > parsing. > That said, I do prefer to have an encoding which uses "value not valid" > semantics rather than "value not present", because, like is done with IEEE > floating point, it has much better robustness in the face of cascaded > computations that may use inappropriate arithmetic. In fact, I think that's > where the real savings is - in not having to scatter your data reduction > for stats with a zillion if tests and multiple code patsh based on what dat > ayou have. You just do the computation and error propagation will take care > of ensuring that invalid stuff is marked as such. > > >>(ii) High density gateways are pushing the density of CODECs per DSP but >>also pushing RTP packet processing into the DSP. This places severe >>constraints on the available program and data memory space - again a >>strong incentive to keep things as simple as possible. >> > > Simplicity does resonate as a good argument here. > > Dave. > > >>Regards >> >>Alan >> >>-----Original Message----- >>From: Paul E. Jones [mailto:paulej@packetizer.com] >>Sent: Saturday, May 24, 2003 10:40 AM >>To: alan@telchemy.com; 'Siddiqui, Anwar A (Anwar)'; 'Colin Perkins'; >>'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' >>Cc: avt@ietf.org >>Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt >> >> >>Alan, >> >>I still think we should allow every field to be optional. I recognize the >>desire to encourage reporting a complete set of stats, but I would tend to >>believe that there will be environments wherein not all stats are >>necessary. >> >>Now, not to sound that I'm in disagreement with Anwar, but I think it >>might be useful to allow one to indicate that a particular parameter is >>not measured by populating the field with some default value. This >>default value would not indicate a "valid", but be an indicator of the >>fact that the field is not present. This would address your concern that >>the fields and reporting blocks are fixed in size. >> >>I also realize that some time will be wasted to determine that a >>measurement is not present, but the same amount of time will be consumed >>by a system to extract a valid value today. So, the system performance >>is the same, albeit with potentially less useful data. >> >>Paul >> >>----- Original Message ----- >>From: "Alan Clark" >>To: "'Siddiqui, Anwar A (Anwar)'" ; "'Colin Perkins'" >>; "'Timur Friedman'" ; >>"'Stephen Casner'" ; "'Ramon Caceres'" >> Cc: >>Sent: Thursday, May 22, 2003 10:14 AM >>Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt >> >> >> >>>Anwar >>> >>>This was brought up several weeks ago on the mailing list. This approach >>>was taken deliberately for several reasons:- >>> >>>(i) To encourage implementors to move towards implementing the complete >> >>set >> >>>of metrics. I've socialized this data set with a variety of service >>>providers, enterprise network managers, equipment manufacturers and there >>>seems to be general agreement that this metrics set provides a good >> >>"minimum >> >>>set" for diagnosing VoIP performance problems. >>> >>>(ii) There is overhead associated with identifying whether fields are or >> >>are >> >>>not present (see Colin Perkins comment on this issue several weeks ago). >>> >>>I am aware of several major equipment manufacturers and DSP software >> >>vendors >> >>>that intend to fully implement the RTCP XR VoIP metrics, and several tier >>>one carriers that are currently specifying that this metric set be used >> >>for >> >>>VoIP service management. There is also considerable interest from other >>>standards groups in this work. >>> >>>Regards >>> >>>Alan Clark >>>Telchemy >>> >>>-----Original Message----- >>>From: Siddiqui, Anwar A (Anwar) [mailto:anwars@avaya.com] >>>Sent: Thursday, May 22, 2003 9:23 AM >>>To: Colin Perkins; Timur Friedman; Stephen Casner; alan@telchemy.com; >>>Ramon Caceres >>>Cc: avt@ietf.org >>>Subject: Re: draft-ietf-avt-rtcp-report-extns-06.txt >>> >>> >>>Timur, Alan >>> >>>I did mention this during last IETF session. And I believe few other >> >>people >> >>>also have similar concerns. So here is the issue I am requesting this be >>>reconsidered and if possible be avoided. >>> >>>------------------------------ >>>Is there anyway that we can avoid hard coding VoIP metrics like it is >>>identified in this draft. Its not the usefulness of the metrics that I am >>>having difficulties with. I actually believe they are useful parameters >>>to be included in RTCP. But its just that its hardcoded right now >>>....and if >> >>an >> >>>RTP source does not have parameters to report it will keep sending these >>>default hard coded values! It is this kind of hardcoding in SR/RR reports >>>that makes us do this XR reports now. So I am requesting if it possible >> >>such >> >>>hard coding of VoIP metrics be avoided. >>>------------------------------- >>> >>>Thanks in advance >>> >>>Anwar >>> >>> >>> >>>----- Original Message ----- >>>From: "Colin Perkins" >>>To: "Timur Friedman" >>>Cc: ; "Stephen Casner" ; "Alan Clark" >>>; "Ramon Caceres" ; "Kevin C. >>>Almeroth" ; "Robert Cole" ; "Nick >>>Duffield" ; "Kaynam Hedayat" >>>; "Kamil Sarac" ; "Magnus >>>Westerlund" >>>Sent: Monday, May 19, 2003 8:05 PM >>>Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt >>> >>> >>> >>>>Thanks. Unless there are objections, we intend to request that the IESG >>>>consider this version for publication as a proposed standard. >>>> >>>>Colin >>>> >>>> >>>>--> Timur Friedman writes: >>>> >>>>>Hello, >>>>> >>>>>Please find attached the latest version of the RTP Control Protocol >>>> >>>Extended >>> >>>>>Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. >>>>> >>>>>This draft was produced in response to AVT working group last call >>>> >>>comments. >>> >>>>>In addition to the changes discussed online on the AVT list, some >>>> >>>additional >>> >>>>>detail has been added to the SDP signaling section, to allow >>>>>individual >>>> >>>flags >>> >>>>>in the Statistics Summary report blocks to be signaled. Also, >>>>>default >>>> >>>values >>> >>>>>have been specified for the VoIP metrics section in places where >>>>>there >>>> >>>might >>> >>>>>have been some confusion about what to do if no packets had been >>>> >>>received. >>> >>>>>And the time frame over which some of the VoIP fields are calculated >>>> >>has >> >>>>>also been specified. >>>>> >>>>>A PDF version of this draft is available at the following URL: >>>>> >>>> >>>http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-repo >>>rt- extns-06.pdf >>> >>>>>Regards, >>>>> >>>>>Timur Friedman >>>> >>>>_______________________________________________ >>>>Audio/Video Transport Working Group >>>>avt@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/avt >>>> >>> >> >>_______________________________________________ >>Audio/Video Transport Working Group >>avt@ietf.org >>https://www1.ietf.org/mailman/listinfo/avt > > > > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 26 10:37:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14622 for ; Mon, 26 May 2003 10:37:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4QEbQ411900 for avt-archive@odin.ietf.org; Mon, 26 May 2003 10:37:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QEXdB10961; Mon, 26 May 2003 10:33:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QEVjB10902 for ; Mon, 26 May 2003 10:31:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14254 for ; Mon, 26 May 2003 10:31:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KIzI-0006gz-00 for avt@ietf.org; Mon, 26 May 2003 10:30:08 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19KIzH-0006gw-00 for avt@ietf.org; Mon, 26 May 2003 10:30:07 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4QEV5FW022912; Mon, 26 May 2003 07:31:05 -0700 (PDT) Received: from [10.32.254.189] (stealth-10-32-254-189.cisco.com [10.32.254.189]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with SMTP id AEM16157; Mon, 26 May 2003 07:31:02 -0700 (PDT) Date: Mon, 26 May 2003 10:30:52 -0400 From: David Oran To: Alan Clark , "Paul E. Jones" , "'Colin Perkins'" , "'Timur Friedman'" , "'Stephen Casner'" , "'Ramon Caceres'" cc: avt@ietf.org Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Message-ID: <509570578.1053945052@[10.32.254.189]> In-Reply-To: References: X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit --On Sunday, May 25, 2003 7:01 PM -0400 Alan Clark wrote: > Dave, > > RTCP XR can be extremely useful in supporting problem detection, call > admission control etc. as it provides a fast method for a probe, analyzer, > session controller... to get call quality related information from the > endpoint. Of course. I agree 100%. I only was reacting to using snooping as a mainstream way to see the packets. What we really need is 3rd-party RTCP monitoring that works for unicast sessions as well as multicast sessions. > In general the data available in RTCP XR should not represent a > security concern - unlike SDES - and hence (I think) there is no advantage > to applying encryption and considerable disadvantage. > How do you know what is RTCP without parsing every packet at wire rate? What about RTP/RTCP over TCP? What about NATs that move RTP/RTCP into arbitrary ports? What about eCRTP with tunnels? What about RTP through IPSEC VPN tunnels? I would say there is no downside to encrypting RTCP since snooping monitors are a losing proposition anyway and I wouldn't want to stand up and try to prove that there is no security advantage to encrypting the packets. I can actually think of an advantage - it's pretty "out-there", but just illustrative. Suppose I have an ISP with whom I've contracted for "scavenger" style voice service. What they do is monitor my RTCP and if I'm getting too good voice service in the middle of the day they stomp on my session just to "encourage" me to buy their higher grade of service. Another advantage of encryption is if somebody is using the RTCP for billing adjustments. On the assumption I can't hide my quality stuff from eavesdroppers, I may instead be motivated to lie, which is to everybody's detriment. All that said, I am in fact in complete agreement with the current spec as far as using fixed reporting blocks rather than variable length encoding, so perhaps we should just drop this aspect of the discussion. > In an Enterprise network using VPN for inter-site connections you could > consider using SRTP for RTP payloads and rely on the VPN tunnel to protect > RTCP SDES information, which is a good compromise between management and > security. In some other applications, notably IP Centrex, the service > provider is already handling signaling - RTCP XR gives them feedback on > call quality from the customer desktop and alerts them to customer LAN > problems that affect call quality. > It's bad enough to have to do heurisitic packet inspection to separate out different flows. Are you seriously suggesting that a VPN gateway separate out invididual packets of a flow and send only some through the tunnel? Ycccchh. Dave. > Regards > > Alan > > > > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Sunday, May 25, 2003 5:46 PM > To: Alan Clark; Paul E. Jones; 'Siddiqui, Anwar A (Anwar)'; 'Colin > Perkins'; 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' > Cc: avt@ietf.org > Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > > --On Sunday, May 25, 2003 8:11 AM -0400 Alan Clark > wrote: > >> Paul >> >> If you bear in mind that RTCP XR is likely to be used to exchange >> information between endpoints through the media path then there are >> several implementation considerations. >> >> (i) It is quite likely that intermediate systems such as Ethernet >> switches, edge routers and shapers may scan RTCP XR payloads. A number >> of such systems already do this with RTCP SR/RR reports, either for QoS >> monitoring or for active control. With switch speeds getting to 10 >> gigabit then it is important to keep parsing complexity very low. >> > Really? Boy, I'm glad I'm using SRTP and encrypting my RTCP packets. Put > another way, I don't find snooping to be a valid argument in favor of fast > parsing. > That said, I do prefer to have an encoding which uses "value not valid" > semantics rather than "value not present", because, like is done with IEEE > floating point, it has much better robustness in the face of cascaded > computations that may use inappropriate arithmetic. In fact, I think > that's where the real savings is - in not having to scatter your data > reduction for stats with a zillion if tests and multiple code patsh based > on what dat ayou have. You just do the computation and error propagation > will take care of ensuring that invalid stuff is marked as such. > >> (ii) High density gateways are pushing the density of CODECs per DSP but >> also pushing RTP packet processing into the DSP. This places severe >> constraints on the available program and data memory space - again a >> strong incentive to keep things as simple as possible. >> > Simplicity does resonate as a good argument here. > > Dave. > >> Regards >> >> Alan >> >> -----Original Message----- >> From: Paul E. Jones [mailto:paulej@packetizer.com] >> Sent: Saturday, May 24, 2003 10:40 AM >> To: alan@telchemy.com; 'Siddiqui, Anwar A (Anwar)'; 'Colin Perkins'; >> 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' >> Cc: avt@ietf.org >> Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt >> >> >> Alan, >> >> I still think we should allow every field to be optional. I recognize >> the desire to encourage reporting a complete set of stats, but I would >> tend to believe that there will be environments wherein not all stats are >> necessary. >> >> Now, not to sound that I'm in disagreement with Anwar, but I think it >> might be useful to allow one to indicate that a particular parameter is >> not measured by populating the field with some default value. This >> default value would not indicate a "valid", but be an indicator of the >> fact that the field is not present. This would address your concern that >> the fields and reporting blocks are fixed in size. >> >> I also realize that some time will be wasted to determine that a >> measurement is not present, but the same amount of time will be consumed >> by a system to extract a valid value today. So, the system performance >> is the same, albeit with potentially less useful data. >> >> Paul >> >> ----- Original Message ----- >> From: "Alan Clark" >> To: "'Siddiqui, Anwar A (Anwar)'" ; "'Colin Perkins'" >> ; "'Timur Friedman'" ; >> "'Stephen Casner'" ; "'Ramon Caceres'" >> Cc: >> Sent: Thursday, May 22, 2003 10:14 AM >> Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt >> >> >>> Anwar >>> >>> This was brought up several weeks ago on the mailing list. This >>> approach was taken deliberately for several reasons:- >>> >>> (i) To encourage implementors to move towards implementing the complete >> set >>> of metrics. I've socialized this data set with a variety of service >>> providers, enterprise network managers, equipment manufacturers and >>> there seems to be general agreement that this metrics set provides a >>> good >> "minimum >>> set" for diagnosing VoIP performance problems. >>> >>> (ii) There is overhead associated with identifying whether fields are or >> are >>> not present (see Colin Perkins comment on this issue several weeks ago). >>> >>> I am aware of several major equipment manufacturers and DSP software >> vendors >>> that intend to fully implement the RTCP XR VoIP metrics, and several >>> tier one carriers that are currently specifying that this metric set be >>> used >> for >>> VoIP service management. There is also considerable interest from other >>> standards groups in this work. >>> >>> Regards >>> >>> Alan Clark >>> Telchemy >>> >>> -----Original Message----- >>> From: Siddiqui, Anwar A (Anwar) [mailto:anwars@avaya.com] >>> Sent: Thursday, May 22, 2003 9:23 AM >>> To: Colin Perkins; Timur Friedman; Stephen Casner; alan@telchemy.com; >>> Ramon Caceres >>> Cc: avt@ietf.org >>> Subject: Re: draft-ietf-avt-rtcp-report-extns-06.txt >>> >>> >>> Timur, Alan >>> >>> I did mention this during last IETF session. And I believe few other >> people >>> also have similar concerns. So here is the issue I am requesting this be >>> reconsidered and if possible be avoided. >>> >>> ------------------------------ >>> Is there anyway that we can avoid hard coding VoIP metrics like it is >>> identified in this draft. Its not the usefulness of the metrics that I >>> am having difficulties with. I actually believe they are useful >>> parameters to be included in RTCP. But its just that its hardcoded >>> right now ....and if >> an >>> RTP source does not have parameters to report it will keep sending these >>> default hard coded values! It is this kind of hardcoding in SR/RR >>> reports that makes us do this XR reports now. So I am requesting if it >>> possible >> such >>> hard coding of VoIP metrics be avoided. >>> ------------------------------- >>> >>> Thanks in advance >>> >>> Anwar >>> >>> >>> >>> ----- Original Message ----- >>> From: "Colin Perkins" >>> To: "Timur Friedman" >>> Cc: ; "Stephen Casner" ; "Alan Clark" >>> ; "Ramon Caceres" ; "Kevin C. >>> Almeroth" ; "Robert Cole" ; "Nick >>> Duffield" ; "Kaynam Hedayat" >>> ; "Kamil Sarac" ; "Magnus >>> Westerlund" >>> Sent: Monday, May 19, 2003 8:05 PM >>> Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt >>> >>> >>> > Thanks. Unless there are objections, we intend to request that the >>> > IESG consider this version for publication as a proposed standard. >>> > >>> > Colin >>> > >>> > >>> > --> Timur Friedman writes: >>> > > Hello, >>> > > >>> > > Please find attached the latest version of the RTP Control Protocol >>> Extended >>> > > Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. >>> > > >>> > > This draft was produced in response to AVT working group last call >>> comments. >>> > > >>> > > In addition to the changes discussed online on the AVT list, some >>> additional >>> > > detail has been added to the SDP signaling section, to allow >>> > > individual >>> flags >>> > > in the Statistics Summary report blocks to be signaled. Also, >>> > > default >>> values >>> > > have been specified for the VoIP metrics section in places where >>> > > there >>> might >>> > > have been some confusion about what to do if no packets had been >>> received. >>> > > And the time frame over which some of the VoIP fields are calculated >> has >>> > > also been specified. >>> > > >>> > > A PDF version of this draft is available at the following URL: >>> > > >>> > >>> >>> http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-repo >>> rt- extns-06.pdf >>> > > >>> > > Regards, >>> > > >>> > > Timur Friedman >>> > _______________________________________________ >>> > Audio/Video Transport Working Group >>> > avt@ietf.org >>> > https://www1.ietf.org/mailman/listinfo/avt >>> > >>> >> >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > > > > ------------------------ > David R. Oran > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 > Office: +1 978 264 2048 > VoIP: +1 408 571 4576 > Email: oran@cisco.com > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 26 16:23:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25541 for ; Mon, 26 May 2003 16:23:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4QKMs302699 for avt-archive@odin.ietf.org; Mon, 26 May 2003 16:22:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QKMOB02692; Mon, 26 May 2003 16:22:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QKKYB02630 for ; Mon, 26 May 2003 16:20:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25460 for ; Mon, 26 May 2003 16:20:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KOQj-0001rE-00 for avt@ietf.org; Mon, 26 May 2003 16:18:49 -0400 Received: from rrcs-midsouth-24-199-221-51.biz.rr.com ([24.199.221.51] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 19KOQi-0001rA-00 for avt@ietf.org; Mon, 26 May 2003 16:18:48 -0400 Received: from PAULEJW2K1 (geneva.packetizer.org [192.168.1.2]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id h4QKJcKw027054; Mon, 26 May 2003 16:19:40 -0400 Message-ID: <00c301c323c4$24b575e0$dc7c3d0a@cisco.com> From: "Paul E. Jones" To: "David Oran" , "Alan Clark" , "'Colin Perkins'" , "'Timur Friedman'" , "'Stephen Casner'" , "'Ramon Caceres'" Cc: References: <509570578.1053945052@[10.32.254.189]> Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Date: Mon, 26 May 2003 16:19:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dave, My original point was not related to variable reporting block sizes. Rather, it was related to the requirement that we report so many fields if we report anything at all. For example, if the flag to report jitter is included in the Statistics Summary Report block, then all of the fields min_jitter, max_jitter, mean_jitter, and dev_jitter MUST be included. Perhaps I don't want to waste the processing time to calculate the standard deviation or mean? One is left with no choice, unfortunately. What I'd like to see is either a flag to indicate that each of those fields are present or to fill the fields with some "dummy" value that is known to indicate that the value is not provided. Granted, having the stats there might be helpful, but it somewhat removes the flexibility from the equipment manufacturer. I'd question why we even have any flags at all to indicate the presence/absence of certain fields, if we don't want to be flexible with sub-fields with a particular group of fields. Paul ----- Original Message ----- From: "David Oran" To: "Alan Clark" ; "Paul E. Jones" ; "'Colin Perkins'" ; "'Timur Friedman'" ; "'Stephen Casner'" ; "'Ramon Caceres'" Cc: Sent: Monday, May 26, 2003 10:30 AM Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > --On Sunday, May 25, 2003 7:01 PM -0400 Alan Clark > wrote: > > > Dave, > > > > RTCP XR can be extremely useful in supporting problem detection, call > > admission control etc. as it provides a fast method for a probe, analyzer, > > session controller... to get call quality related information from the > > endpoint. > Of course. I agree 100%. I only was reacting to using snooping as a > mainstream way to see the packets. What we really need is 3rd-party RTCP > monitoring that works for unicast sessions as well as multicast sessions. > > > In general the data available in RTCP XR should not represent a > > security concern - unlike SDES - and hence (I think) there is no advantage > > to applying encryption and considerable disadvantage. > > > How do you know what is RTCP without parsing every packet at wire rate? > What about RTP/RTCP over TCP? What about NATs that move RTP/RTCP into > arbitrary ports? What about eCRTP with tunnels? What about RTP through > IPSEC VPN tunnels? > > I would say there is no downside to encrypting RTCP since snooping monitors > are a losing proposition anyway and I wouldn't want to stand up and try to > prove that there is no security advantage to encrypting the packets. > > I can actually think of an advantage - it's pretty "out-there", but just > illustrative. Suppose I have an ISP with whom I've contracted for > "scavenger" style voice service. What they do is monitor my RTCP and if I'm > getting too good voice service in the middle of the day they stomp on my > session just to "encourage" me to buy their higher grade of service. > > Another advantage of encryption is if somebody is using the RTCP for > billing adjustments. On the assumption I can't hide my quality stuff from > eavesdroppers, I may instead be motivated to lie, which is to everybody's > detriment. > > All that said, I am in fact in complete agreement with the current spec as > far as using fixed reporting blocks rather than variable length encoding, > so perhaps we should just drop this aspect of the discussion. > > > In an Enterprise network using VPN for inter-site connections you could > > consider using SRTP for RTP payloads and rely on the VPN tunnel to protect > > RTCP SDES information, which is a good compromise between management and > > security. In some other applications, notably IP Centrex, the service > > provider is already handling signaling - RTCP XR gives them feedback on > > call quality from the customer desktop and alerts them to customer LAN > > problems that affect call quality. > > > It's bad enough to have to do heurisitic packet inspection to separate out > different flows. Are you seriously suggesting that a VPN gateway separate > out invididual packets of a flow and send only some through the tunnel? > Ycccchh. > > Dave. > > > Regards > > > > Alan > > > > > > > > > > -----Original Message----- > > From: David R. Oran [mailto:oran@cisco.com] > > Sent: Sunday, May 25, 2003 5:46 PM > > To: Alan Clark; Paul E. Jones; 'Siddiqui, Anwar A (Anwar)'; 'Colin > > Perkins'; 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' > > Cc: avt@ietf.org > > Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > > > > > --On Sunday, May 25, 2003 8:11 AM -0400 Alan Clark > > wrote: > > > >> Paul > >> > >> If you bear in mind that RTCP XR is likely to be used to exchange > >> information between endpoints through the media path then there are > >> several implementation considerations. > >> > >> (i) It is quite likely that intermediate systems such as Ethernet > >> switches, edge routers and shapers may scan RTCP XR payloads. A number > >> of such systems already do this with RTCP SR/RR reports, either for QoS > >> monitoring or for active control. With switch speeds getting to 10 > >> gigabit then it is important to keep parsing complexity very low. > >> > > Really? Boy, I'm glad I'm using SRTP and encrypting my RTCP packets. Put > > another way, I don't find snooping to be a valid argument in favor of fast > > parsing. > > That said, I do prefer to have an encoding which uses "value not valid" > > semantics rather than "value not present", because, like is done with IEEE > > floating point, it has much better robustness in the face of cascaded > > computations that may use inappropriate arithmetic. In fact, I think > > that's where the real savings is - in not having to scatter your data > > reduction for stats with a zillion if tests and multiple code patsh based > > on what dat ayou have. You just do the computation and error propagation > > will take care of ensuring that invalid stuff is marked as such. > > > >> (ii) High density gateways are pushing the density of CODECs per DSP but > >> also pushing RTP packet processing into the DSP. This places severe > >> constraints on the available program and data memory space - again a > >> strong incentive to keep things as simple as possible. > >> > > Simplicity does resonate as a good argument here. > > > > Dave. > > > >> Regards > >> > >> Alan > >> > >> -----Original Message----- > >> From: Paul E. Jones [mailto:paulej@packetizer.com] > >> Sent: Saturday, May 24, 2003 10:40 AM > >> To: alan@telchemy.com; 'Siddiqui, Anwar A (Anwar)'; 'Colin Perkins'; > >> 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' > >> Cc: avt@ietf.org > >> Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > >> > >> > >> Alan, > >> > >> I still think we should allow every field to be optional. I recognize > >> the desire to encourage reporting a complete set of stats, but I would > >> tend to believe that there will be environments wherein not all stats are > >> necessary. > >> > >> Now, not to sound that I'm in disagreement with Anwar, but I think it > >> might be useful to allow one to indicate that a particular parameter is > >> not measured by populating the field with some default value. This > >> default value would not indicate a "valid", but be an indicator of the > >> fact that the field is not present. This would address your concern that > >> the fields and reporting blocks are fixed in size. > >> > >> I also realize that some time will be wasted to determine that a > >> measurement is not present, but the same amount of time will be consumed > >> by a system to extract a valid value today. So, the system performance > >> is the same, albeit with potentially less useful data. > >> > >> Paul > >> > >> ----- Original Message ----- > >> From: "Alan Clark" > >> To: "'Siddiqui, Anwar A (Anwar)'" ; "'Colin Perkins'" > >> ; "'Timur Friedman'" ; > >> "'Stephen Casner'" ; "'Ramon Caceres'" > >> Cc: > >> Sent: Thursday, May 22, 2003 10:14 AM > >> Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > >> > >> > >>> Anwar > >>> > >>> This was brought up several weeks ago on the mailing list. This > >>> approach was taken deliberately for several reasons:- > >>> > >>> (i) To encourage implementors to move towards implementing the complete > >> set > >>> of metrics. I've socialized this data set with a variety of service > >>> providers, enterprise network managers, equipment manufacturers and > >>> there seems to be general agreement that this metrics set provides a > >>> good > >> "minimum > >>> set" for diagnosing VoIP performance problems. > >>> > >>> (ii) There is overhead associated with identifying whether fields are or > >> are > >>> not present (see Colin Perkins comment on this issue several weeks ago). > >>> > >>> I am aware of several major equipment manufacturers and DSP software > >> vendors > >>> that intend to fully implement the RTCP XR VoIP metrics, and several > >>> tier one carriers that are currently specifying that this metric set be > >>> used > >> for > >>> VoIP service management. There is also considerable interest from other > >>> standards groups in this work. > >>> > >>> Regards > >>> > >>> Alan Clark > >>> Telchemy > >>> > >>> -----Original Message----- > >>> From: Siddiqui, Anwar A (Anwar) [mailto:anwars@avaya.com] > >>> Sent: Thursday, May 22, 2003 9:23 AM > >>> To: Colin Perkins; Timur Friedman; Stephen Casner; alan@telchemy.com; > >>> Ramon Caceres > >>> Cc: avt@ietf.org > >>> Subject: Re: draft-ietf-avt-rtcp-report-extns-06.txt > >>> > >>> > >>> Timur, Alan > >>> > >>> I did mention this during last IETF session. And I believe few other > >> people > >>> also have similar concerns. So here is the issue I am requesting this be > >>> reconsidered and if possible be avoided. > >>> > >>> ------------------------------ > >>> Is there anyway that we can avoid hard coding VoIP metrics like it is > >>> identified in this draft. Its not the usefulness of the metrics that I > >>> am having difficulties with. I actually believe they are useful > >>> parameters to be included in RTCP. But its just that its hardcoded > >>> right now ....and if > >> an > >>> RTP source does not have parameters to report it will keep sending these > >>> default hard coded values! It is this kind of hardcoding in SR/RR > >>> reports that makes us do this XR reports now. So I am requesting if it > >>> possible > >> such > >>> hard coding of VoIP metrics be avoided. > >>> ------------------------------- > >>> > >>> Thanks in advance > >>> > >>> Anwar > >>> > >>> > >>> > >>> ----- Original Message ----- > >>> From: "Colin Perkins" > >>> To: "Timur Friedman" > >>> Cc: ; "Stephen Casner" ; "Alan Clark" > >>> ; "Ramon Caceres" ; "Kevin C. > >>> Almeroth" ; "Robert Cole" ; "Nick > >>> Duffield" ; "Kaynam Hedayat" > >>> ; "Kamil Sarac" ; "Magnus > >>> Westerlund" > >>> Sent: Monday, May 19, 2003 8:05 PM > >>> Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt > >>> > >>> > >>> > Thanks. Unless there are objections, we intend to request that the > >>> > IESG consider this version for publication as a proposed standard. > >>> > > >>> > Colin > >>> > > >>> > > >>> > --> Timur Friedman writes: > >>> > > Hello, > >>> > > > >>> > > Please find attached the latest version of the RTP Control Protocol > >>> Extended > >>> > > Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. > >>> > > > >>> > > This draft was produced in response to AVT working group last call > >>> comments. > >>> > > > >>> > > In addition to the changes discussed online on the AVT list, some > >>> additional > >>> > > detail has been added to the SDP signaling section, to allow > >>> > > individual > >>> flags > >>> > > in the Statistics Summary report blocks to be signaled. Also, > >>> > > default > >>> values > >>> > > have been specified for the VoIP metrics section in places where > >>> > > there > >>> might > >>> > > have been some confusion about what to do if no packets had been > >>> received. > >>> > > And the time frame over which some of the VoIP fields are calculated > >> has > >>> > > also been specified. > >>> > > > >>> > > A PDF version of this draft is available at the following URL: > >>> > > > >>> > > >>> > >>> http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-repo > >>> rt- extns-06.pdf > >>> > > > >>> > > Regards, > >>> > > > >>> > > Timur Friedman > >>> > _______________________________________________ > >>> > Audio/Video Transport Working Group > >>> > avt@ietf.org > >>> > https://www1.ietf.org/mailman/listinfo/avt > >>> > > >>> > >> > >> > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www1.ietf.org/mailman/listinfo/avt > > > > > > > > ------------------------ > > David R. Oran > > Cisco Systems > > 7 Ladyslipper Lane > > Acton, MA 01720 > > Office: +1 978 264 2048 > > VoIP: +1 408 571 4576 > > Email: oran@cisco.com > > > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon May 26 19:20:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04007 for ; Mon, 26 May 2003 19:20:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4QNJnK13639 for avt-archive@odin.ietf.org; Mon, 26 May 2003 19:19:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QNG9B13536; Mon, 26 May 2003 19:16:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4QNE9B13495 for ; Mon, 26 May 2003 19:14:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03847 for ; Mon, 26 May 2003 19:13:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KR8f-00043v-00 for avt@ietf.org; Mon, 26 May 2003 19:12:21 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19KR8e-00043k-00 for avt@ietf.org; Mon, 26 May 2003 19:12:20 -0400 Received: from alansnotebook [66.156.12.185] by telchemy.com with ESMTP (SMTPD32-7.14) id AF7B12400148; Mon, 26 May 2003 19:12:59 -0400 From: "Alan Clark" To: "Paul E. Jones" , "David Oran" , "'Colin Perkins'" , "'Timur Friedman'" , "'Stephen Casner'" , "'Ramon Caceres'" Cc: Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Date: Mon, 26 May 2003 19:16:49 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <00c301c323c4$24b575e0$dc7c3d0a@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Paul The VoIP metrics block is intended to be relatively self contained, hence you shouldn't need to use other blocks in normal usage. It is quite common to report jitter, as in RFC1889, however this can actually be quite difficult to relate to VoIP performance. Quite a few test equipment vendors have tried to use RTCP stats as a basis for VoIP QoS reporting and some have tried to use packet-to-packet delay variation as a basis for estimating jitter buffer size, which doesn't work too well (see below). The approach taken in the RTCP XR VoIP metrics is based on the premise that in a VoIP (or similar real time) application you "really" need to know what the effects of jitter are - i.e. what proportion of packets are getting discarded and what is the jitter buffer size. This is preferable since jitter itself is a time varying effect and most jitter buffers exhibit dynamic behavior. High levels of jitter are often due to excessive congestion on access links, narrow bandwidth WAN connections and 10 Mbit LANs. This leads to time varying jitter levels, and to short term variations in delay (due to the integrating effect of queues). If we use PPDV to measure jitter then the following problems can result:- (i) A short term increase in traffic level can cause the queue in a router to fill, leading to a short term increase in delay accompanying an increase in jitter. The observable increase in PPDV may be quite small however the jitter buffer may run out of packets due to the delay increase and hence resynchronize. Say the jitter buffer was set to 50mS, the jitter level increased from 10mS to 30mS and the delay increased by 30mS - PPDV would see a 30mS jitter level and would not predict any discards. If on the other hand we measured packet delay variation with respect to the base delay (i.e. absolute packet delay variation) then we would see an apparent increase in delay variation from 10mS to 60mS and would predict excessive numbers of discards. (ii) Say we have two RTP streams, each suffering from 10Mbit Ethernet + hub LAN congestion, and our VoIP end systems have identical adaptive jitter buffers. 10BaseT congestion can lead to substantial packet delay transients, which would lead to discards. On one stream the congestion is fairly uniform, and on the other it is concentrated in short periods. In the first case, having an adaptive jitter buffer may not be too helpful as a delay transient may lead to the jitter buffer increasing in size however the following packets may have less delay variation. In the second case the adaptive jitter buffer can be very helpful, as the increase in jitter triggers a buffer size increase which reduces discards during the following period of high delay variation. (iii) Packet delay variation measurements, for example that used in RFC1889, provide snapshots of the jitter level at some point in time. RFC1889 uses a running average with a scaling factor of 16, and hence provides some idea of the jitter level during the preceding few hundred milliseconds. It is quite difficult to conceive of a jitter measurement that would provide a good cumulative view of the RTP session to date - unless you started measuring means/ standard deviations and potentially skew and kurtosis. The number of packets discarded due to jitter is a "factual" measurement that provides a view of the cumulative effect of jitter on the RTP session. >From a practical perspective, knowing the discard rate and jitter buffer size saves much guesswork. If the discard rate is zero and the jitter buffer size is high then it may be safe to reduce the jitter buffer size. If the discard rate is high and the jitter buffer is fixed and small then it would make sense to increase it's size. etc. Regards Alan -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Paul E. Jones Sent: Monday, May 26, 2003 4:20 PM To: David Oran; Alan Clark; 'Colin Perkins'; 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' Cc: avt@ietf.org Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Dave, My original point was not related to variable reporting block sizes. Rather, it was related to the requirement that we report so many fields if we report anything at all. For example, if the flag to report jitter is included in the Statistics Summary Report block, then all of the fields min_jitter, max_jitter, mean_jitter, and dev_jitter MUST be included. Perhaps I don't want to waste the processing time to calculate the standard deviation or mean? One is left with no choice, unfortunately. What I'd like to see is either a flag to indicate that each of those fields are present or to fill the fields with some "dummy" value that is known to indicate that the value is not provided. Granted, having the stats there might be helpful, but it somewhat removes the flexibility from the equipment manufacturer. I'd question why we even have any flags at all to indicate the presence/absence of certain fields, if we don't want to be flexible with sub-fields with a particular group of fields. Paul ----- Original Message ----- From: "David Oran" To: "Alan Clark" ; "Paul E. Jones" ; "'Colin Perkins'" ; "'Timur Friedman'" ; "'Stephen Casner'" ; "'Ramon Caceres'" Cc: Sent: Monday, May 26, 2003 10:30 AM Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > --On Sunday, May 25, 2003 7:01 PM -0400 Alan Clark > wrote: > > > Dave, > > > > RTCP XR can be extremely useful in supporting problem detection, call > > admission control etc. as it provides a fast method for a probe, analyzer, > > session controller... to get call quality related information from the > > endpoint. > Of course. I agree 100%. I only was reacting to using snooping as a > mainstream way to see the packets. What we really need is 3rd-party RTCP > monitoring that works for unicast sessions as well as multicast sessions. > > > In general the data available in RTCP XR should not represent a > > security concern - unlike SDES - and hence (I think) there is no advantage > > to applying encryption and considerable disadvantage. > > > How do you know what is RTCP without parsing every packet at wire rate? > What about RTP/RTCP over TCP? What about NATs that move RTP/RTCP into > arbitrary ports? What about eCRTP with tunnels? What about RTP through > IPSEC VPN tunnels? > > I would say there is no downside to encrypting RTCP since snooping monitors > are a losing proposition anyway and I wouldn't want to stand up and try to > prove that there is no security advantage to encrypting the packets. > > I can actually think of an advantage - it's pretty "out-there", but just > illustrative. Suppose I have an ISP with whom I've contracted for > "scavenger" style voice service. What they do is monitor my RTCP and if I'm > getting too good voice service in the middle of the day they stomp on my > session just to "encourage" me to buy their higher grade of service. > > Another advantage of encryption is if somebody is using the RTCP for > billing adjustments. On the assumption I can't hide my quality stuff from > eavesdroppers, I may instead be motivated to lie, which is to everybody's > detriment. > > All that said, I am in fact in complete agreement with the current spec as > far as using fixed reporting blocks rather than variable length encoding, > so perhaps we should just drop this aspect of the discussion. > > > In an Enterprise network using VPN for inter-site connections you could > > consider using SRTP for RTP payloads and rely on the VPN tunnel to protect > > RTCP SDES information, which is a good compromise between management and > > security. In some other applications, notably IP Centrex, the service > > provider is already handling signaling - RTCP XR gives them feedback on > > call quality from the customer desktop and alerts them to customer LAN > > problems that affect call quality. > > > It's bad enough to have to do heurisitic packet inspection to separate out > different flows. Are you seriously suggesting that a VPN gateway separate > out invididual packets of a flow and send only some through the tunnel? > Ycccchh. > > Dave. > > > Regards > > > > Alan > > > > > > > > > > -----Original Message----- > > From: David R. Oran [mailto:oran@cisco.com] > > Sent: Sunday, May 25, 2003 5:46 PM > > To: Alan Clark; Paul E. Jones; 'Siddiqui, Anwar A (Anwar)'; 'Colin > > Perkins'; 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' > > Cc: avt@ietf.org > > Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > > > > > --On Sunday, May 25, 2003 8:11 AM -0400 Alan Clark > > wrote: > > > >> Paul > >> > >> If you bear in mind that RTCP XR is likely to be used to exchange > >> information between endpoints through the media path then there are > >> several implementation considerations. > >> > >> (i) It is quite likely that intermediate systems such as Ethernet > >> switches, edge routers and shapers may scan RTCP XR payloads. A number > >> of such systems already do this with RTCP SR/RR reports, either for QoS > >> monitoring or for active control. With switch speeds getting to 10 > >> gigabit then it is important to keep parsing complexity very low. > >> > > Really? Boy, I'm glad I'm using SRTP and encrypting my RTCP packets. Put > > another way, I don't find snooping to be a valid argument in favor of fast > > parsing. > > That said, I do prefer to have an encoding which uses "value not valid" > > semantics rather than "value not present", because, like is done with IEEE > > floating point, it has much better robustness in the face of cascaded > > computations that may use inappropriate arithmetic. In fact, I think > > that's where the real savings is - in not having to scatter your data > > reduction for stats with a zillion if tests and multiple code patsh based > > on what dat ayou have. You just do the computation and error propagation > > will take care of ensuring that invalid stuff is marked as such. > > > >> (ii) High density gateways are pushing the density of CODECs per DSP but > >> also pushing RTP packet processing into the DSP. This places severe > >> constraints on the available program and data memory space - again a > >> strong incentive to keep things as simple as possible. > >> > > Simplicity does resonate as a good argument here. > > > > Dave. > > > >> Regards > >> > >> Alan > >> > >> -----Original Message----- > >> From: Paul E. Jones [mailto:paulej@packetizer.com] > >> Sent: Saturday, May 24, 2003 10:40 AM > >> To: alan@telchemy.com; 'Siddiqui, Anwar A (Anwar)'; 'Colin Perkins'; > >> 'Timur Friedman'; 'Stephen Casner'; 'Ramon Caceres' > >> Cc: avt@ietf.org > >> Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > >> > >> > >> Alan, > >> > >> I still think we should allow every field to be optional. I recognize > >> the desire to encourage reporting a complete set of stats, but I would > >> tend to believe that there will be environments wherein not all stats are > >> necessary. > >> > >> Now, not to sound that I'm in disagreement with Anwar, but I think it > >> might be useful to allow one to indicate that a particular parameter is > >> not measured by populating the field with some default value. This > >> default value would not indicate a "valid", but be an indicator of the > >> fact that the field is not present. This would address your concern that > >> the fields and reporting blocks are fixed in size. > >> > >> I also realize that some time will be wasted to determine that a > >> measurement is not present, but the same amount of time will be consumed > >> by a system to extract a valid value today. So, the system performance > >> is the same, albeit with potentially less useful data. > >> > >> Paul > >> > >> ----- Original Message ----- > >> From: "Alan Clark" > >> To: "'Siddiqui, Anwar A (Anwar)'" ; "'Colin Perkins'" > >> ; "'Timur Friedman'" ; > >> "'Stephen Casner'" ; "'Ramon Caceres'" > >> Cc: > >> Sent: Thursday, May 22, 2003 10:14 AM > >> Subject: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > >> > >> > >>> Anwar > >>> > >>> This was brought up several weeks ago on the mailing list. This > >>> approach was taken deliberately for several reasons:- > >>> > >>> (i) To encourage implementors to move towards implementing the complete > >> set > >>> of metrics. I've socialized this data set with a variety of service > >>> providers, enterprise network managers, equipment manufacturers and > >>> there seems to be general agreement that this metrics set provides a > >>> good > >> "minimum > >>> set" for diagnosing VoIP performance problems. > >>> > >>> (ii) There is overhead associated with identifying whether fields are or > >> are > >>> not present (see Colin Perkins comment on this issue several weeks ago). > >>> > >>> I am aware of several major equipment manufacturers and DSP software > >> vendors > >>> that intend to fully implement the RTCP XR VoIP metrics, and several > >>> tier one carriers that are currently specifying that this metric set be > >>> used > >> for > >>> VoIP service management. There is also considerable interest from other > >>> standards groups in this work. > >>> > >>> Regards > >>> > >>> Alan Clark > >>> Telchemy > >>> > >>> -----Original Message----- > >>> From: Siddiqui, Anwar A (Anwar) [mailto:anwars@avaya.com] > >>> Sent: Thursday, May 22, 2003 9:23 AM > >>> To: Colin Perkins; Timur Friedman; Stephen Casner; alan@telchemy.com; > >>> Ramon Caceres > >>> Cc: avt@ietf.org > >>> Subject: Re: draft-ietf-avt-rtcp-report-extns-06.txt > >>> > >>> > >>> Timur, Alan > >>> > >>> I did mention this during last IETF session. And I believe few other > >> people > >>> also have similar concerns. So here is the issue I am requesting this be > >>> reconsidered and if possible be avoided. > >>> > >>> ------------------------------ > >>> Is there anyway that we can avoid hard coding VoIP metrics like it is > >>> identified in this draft. Its not the usefulness of the metrics that I > >>> am having difficulties with. I actually believe they are useful > >>> parameters to be included in RTCP. But its just that its hardcoded > >>> right now ....and if > >> an > >>> RTP source does not have parameters to report it will keep sending these > >>> default hard coded values! It is this kind of hardcoding in SR/RR > >>> reports that makes us do this XR reports now. So I am requesting if it > >>> possible > >> such > >>> hard coding of VoIP metrics be avoided. > >>> ------------------------------- > >>> > >>> Thanks in advance > >>> > >>> Anwar > >>> > >>> > >>> > >>> ----- Original Message ----- > >>> From: "Colin Perkins" > >>> To: "Timur Friedman" > >>> Cc: ; "Stephen Casner" ; "Alan Clark" > >>> ; "Ramon Caceres" ; "Kevin C. > >>> Almeroth" ; "Robert Cole" ; "Nick > >>> Duffield" ; "Kaynam Hedayat" > >>> ; "Kamil Sarac" ; "Magnus > >>> Westerlund" > >>> Sent: Monday, May 19, 2003 8:05 PM > >>> Subject: [AVT] Re: draft-ietf-avt-rtcp-report-extns-06.txt > >>> > >>> > >>> > Thanks. Unless there are objections, we intend to request that the > >>> > IESG consider this version for publication as a proposed standard. > >>> > > >>> > Colin > >>> > > >>> > > >>> > --> Timur Friedman writes: > >>> > > Hello, > >>> > > > >>> > > Please find attached the latest version of the RTP Control Protocol > >>> Extended > >>> > > Reports (RTCP XR) draft, draft-ietf-avt-rtcp-report-extns-06.txt. > >>> > > > >>> > > This draft was produced in response to AVT working group last call > >>> comments. > >>> > > > >>> > > In addition to the changes discussed online on the AVT list, some > >>> additional > >>> > > detail has been added to the SDP signaling section, to allow > >>> > > individual > >>> flags > >>> > > in the Statistics Summary report blocks to be signaled. Also, > >>> > > default > >>> values > >>> > > have been specified for the VoIP metrics section in places where > >>> > > there > >>> might > >>> > > have been some confusion about what to do if no packets had been > >>> received. > >>> > > And the time frame over which some of the VoIP fields are calculated > >> has > >>> > > also been specified. > >>> > > > >>> > > A PDF version of this draft is available at the following URL: > >>> > > > >>> > > >>> > >>> http://www-rp.lip6.fr/site_rp/_publications/378-draft-ietf-avt-rtcp-repo > >>> rt- extns-06.pdf > >>> > > > >>> > > Regards, > >>> > > > >>> > > Timur Friedman > >>> > _______________________________________________ > >>> > Audio/Video Transport Working Group > >>> > avt@ietf.org > >>> > https://www1.ietf.org/mailman/listinfo/avt > >>> > > >>> > >> > >> > >> _______________________________________________ > >> Audio/Video Transport Working Group > >> avt@ietf.org > >> https://www1.ietf.org/mailman/listinfo/avt > > > > > > > > ------------------------ > > David R. Oran > > Cisco Systems > > 7 Ladyslipper Lane > > Acton, MA 01720 > > Office: +1 978 264 2048 > > VoIP: +1 408 571 4576 > > Email: oran@cisco.com > > > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue May 27 09:07:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10617 for ; Tue, 27 May 2003 09:07:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4RD77g16736 for avt-archive@odin.ietf.org; Tue, 27 May 2003 09:07:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RD3VB16356; Tue, 27 May 2003 09:03:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4RBv0B12283 for ; Tue, 27 May 2003 07:57:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09284 for ; Tue, 27 May 2003 07:56:58 -0400 (EDT) From: heikki.maki@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Kd36-0003gM-00 for avt@ietf.org; Tue, 27 May 2003 07:55:24 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 19Kd35-0003gE-00 for avt@ietf.org; Tue, 27 May 2003 07:55:23 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4RBuKW05357 for ; Tue, 27 May 2003 14:56:20 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 27 May 2003 14:56:19 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 27 May 2003 14:56:19 +0300 Received: from ouebe002.NOE.Nokia.com ([172.23.70.27]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 27 May 2003 14:56:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 27 May 2003 14:56:17 +0300 Message-ID: <208348E4C6F952449F7C21062920AC8A0246E54D@ouebe002.ntc.nokia.com> Thread-Topic: Minor typo in draft-ietf-avt-srtp-06.txt Thread-Index: AcMkRvr++V+2wN74TOmJpsTJtXCg+Q== To: X-OriginalArrivalTime: 27 May 2003 11:56:19.0595 (UTC) FILETIME=[FC507DB0:01C32446] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4RBv0B12284 Subject: [AVT] Minor typo in draft-ietf-avt-srtp-06.txt Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello, In the first page of draft-ietf-avt-srtp-06.txt there is a URL to the list of current Internet-Drafts. Unfortunately there is a typo in that link. http://www.ietf.org/ietf/lid-abstracts.txt ^ should be http://www.ietf.org/ietf/1id-abstracts.txt ^ regards, Heikki Mäki _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 30 11:18:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12754 for ; Fri, 30 May 2003 11:18:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UFHtC11910 for avt-archive@odin.ietf.org; Fri, 30 May 2003 11:17:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UFHMB11870; Fri, 30 May 2003 11:17:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UFClB11647 for ; Fri, 30 May 2003 11:12:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12560 for ; Fri, 30 May 2003 11:12:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LlX8-0005d5-00 for avt@ietf.org; Fri, 30 May 2003 11:11:06 -0400 Received: from www.routeexplorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19LlX7-0005c3-00 for avt@ietf.org; Fri, 30 May 2003 11:11:05 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h4UFCCKn002709; Fri, 30 May 2003 08:12:12 -0700 (PDT) (envelope-from casner@acm.org) Date: Fri, 30 May 2003 08:13:27 -0700 (PDT) From: Stephen Casner To: AVT WG Message-ID: <20030530080123.S48880-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Meeting in Vienna Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Folks, You may have noted that AVT is not yet on the schedule for Vienna. Colin and I would first like to know how much business we have -- that is, who would like an agenda slot -- and how many people are planning to attend. Please send a message to us now if you would like an agenda slot. We'd also like to hear from those who are planning to attend and those who are planning not to attend. You may also cc the avt mailing list if you'd like the group to be aware of your topic request. Thanks. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 30 15:30:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24382 for ; Fri, 30 May 2003 15:30:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UJUFN30584 for avt-archive@odin.ietf.org; Fri, 30 May 2003 15:30:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJSpB30506; Fri, 30 May 2003 15:28:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJRpB30450 for ; Fri, 30 May 2003 15:27:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24206 for ; Fri, 30 May 2003 15:27:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LpVx-0000Tm-00 for avt@ietf.org; Fri, 30 May 2003 15:26:09 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19LpVw-0000Tj-00 for avt@ietf.org; Fri, 30 May 2003 15:26:09 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h4UJPtm18672; Fri, 30 May 2003 12:25:55 -0700 Date: Fri, 30 May 2003 12:25:55 -0700 From: John Lazzaro Message-Id: <200305301925.h4UJPtm18672@snap.CS.Berkeley.EDU> To: casner@acm.org Subject: Re: [AVT] Meeting in Vienna Cc: avt@ietf.org Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Hi Steve (and list), > Please send a message to us now if you would like an agenda slot. > We'd also like to hear from those who are planning to attend and those > who are planning not to attend. I won't be there in person, with a month to go here's where I guess all of the documents I'm associated with will be by the deadline: -- rtp-midi normative: the big refresh went out a few weeks ago, I'm in the process of collecting feedback (so far, nothing worrying has come in ...), and may do another refresh in time for the deadline. -- TCP framing: the big refresh went out a few weeks ago, with a request for WG status. So, it might need a few minutes of meeting time to get a consensus on the request. I believe the document is substantially ready for Last Call, but since it depends on an mmusic I-D that isn't yet in Last Call, it may make sense to wait and be synchronized. -- rtp-midi informative: I'm in the final stages of rewriting this, taking Colin's suggestions, its a radically cut-down document, that is limited to answering a few rtp-midi specific implementation issues (how to send/receiver recovery journals, and how to packetize a MIDI source stream into a packet stream). I'll probably request WG item status for this as well in its slimmed-down form, so that request may need a few minutes of meeting time to get a consensus on the request. -- Some sort of input into with respect to the RTCP "extended highest sequence number received" field. This may just be an email to the list, or may end up being a short I-D if its too unweildy for an email message. I was also hoping to get to an I-D that would put some ideas for re-chartering topics related to synchronization and pro-audio, but realistically, I'd say about a 25% chance that would happen in time for Vienna. ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 30 15:55:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25125 for ; Fri, 30 May 2003 15:55:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UJsnK32390 for avt-archive@odin.ietf.org; Fri, 30 May 2003 15:54:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJsHB32378; Fri, 30 May 2003 15:54:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UJr2B32348 for ; Fri, 30 May 2003 15:53:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25073 for ; Fri, 30 May 2003 15:53:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LpuK-0000kP-00 for avt@ietf.org; Fri, 30 May 2003 15:51:20 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19LpuJ-0000kG-00 for avt@ietf.org; Fri, 30 May 2003 15:51:19 -0400 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4UJqQFY025390; Fri, 30 May 2003 12:52:28 -0700 (PDT) Received: from MRAMALHO-W2K1.cisco.com (dhcp-64-100-135-190.cisco.com [64.100.135.190]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEQ04608; Fri, 30 May 2003 12:52:25 -0700 (PDT) Message-Id: <4.3.2.7.2.20030530154800.01680068@mira-sjc5-9.cisco.com> X-Sender: mramalho@mira-sjc5-9.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 May 2003 15:52:24 -0400 To: Stephen Casner , AVT WG From: "Michael A. Ramalho" Subject: Re: [AVT] Meeting in Vienna In-Reply-To: <20030530080123.S48880-100000@oak.packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , At 08:13 AM 5/30/2003 -0700, Stephen Casner wrote: >Folks, > >You may have noted that AVT is not yet on the schedule for Vienna. >Colin and I would first like to know how much business we have -- that >is, who would like an agenda slot -- and how many people are planning >to attend. Steve, I plan to update the RGL payload format. However, I do not know if I am going to Vienna this point. If I do not, I could make a 10 minute presentation for you/Colin to present in my absence. Otherwise ... since I only had a few items of contention from last time (RGL -> RGLA/RGLU & finalizing the payload format) ... I could finish the discussion on the list and post an updated draft by the deadline. Your call - your advise always appreciated. Regards, Michael Ramalho >Please send a message to us now if you would like an agenda slot. >We'd also like to hear from those who are planning to attend and those >who are planning not to attend. You may also cc the avt mailing list >if you'd like the group to be aware of your topic request. Thanks. > > -- Steve > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt Michael A. Ramalho, Ph.D. Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.941.708.4650 Cell: +1.941.544.2844 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri May 30 16:16:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26045 for ; Fri, 30 May 2003 16:16:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4UKFld02043 for avt-archive@odin.ietf.org; Fri, 30 May 2003 16:15:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UKFDB02026; Fri, 30 May 2003 16:15:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4UKEtB02001 for ; Fri, 30 May 2003 16:14:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26023 for ; Fri, 30 May 2003 16:14:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LqFU-0000y3-00 for avt@ietf.org; Fri, 30 May 2003 16:13:12 -0400 Received: from [66.150.16.91] (helo=mail.i2telecom.com) by ietf-mx with esmtp (Exim 4.12) id 19LqFU-0000xs-00 for avt@ietf.org; Fri, 30 May 2003 16:13:12 -0400 Received: from albab [64.171.55.1] by mail.i2telecom.com with ESMTP (SMTPD32-7.07) id AAC1F8902B4; Fri, 30 May 2003 16:10:41 -0400 Message-ID: <02ec01c326e9$daeb3930$8001a8c0@albab> From: "Awais Ali" To: Date: Fri, 30 May 2003 13:27:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E9_01C326AF.2E094E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [AVT] packing audio and SID frames in the same RTP packet Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_02E9_01C326AF.2E094E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All May be somebody can clarify a confusion I am having right now.=20 RFC 1890 specifies that Audio frames and sid frames can be packed in the = same RTP packets for example in section 4.5.3 it says "There is no = restriction on how 4, 20, and 24 octet frames are intermixed." However = RFC 3389 describes a separate payload type for sid frames, which implies = that audio and sid frames cannot be in the same packet because they will = have different payload types. So the question is can I put both audio and sid frames in the same RTP = packet?. With G.723.1 for example I will have and RTP packet with = payload type of 4 and it will have both 20 and 4 octet frames in it. Regards Ali ------=_NextPart_000_02E9_01C326AF.2E094E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All
 
May be somebody can clarify a confusion = I am having=20 right now.
 
RFC 1890 specifies that Audio frames = and sid frames=20 can be packed in the same RTP packets for example in section 4.5.3 it = says=20 "There is no restriction on how 4, 20, and 24 octet frames are = intermixed."=20 However RFC 3389 describes a separate payload type for sid frames, which = implies=20 that audio and sid frames cannot be in the same packet because they will = have=20 different payload types.
 
So the question is can I put both audio = and sid=20 frames in the same RTP packet?.  With G.723.1 for example I will = have and=20 RTP packet with payload type of 4 and it will have both 20 and 4 octet = frames in=20 it.
 
 
Regards
Ali
------=_NextPart_000_02E9_01C326AF.2E094E80-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat May 31 01:25:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12242 for ; Sat, 31 May 2003 01:25:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4V5PMV05822 for avt-archive@odin.ietf.org; Sat, 31 May 2003 01:25:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V5OjB05769; Sat, 31 May 2003 01:24:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4V5NPB05703 for ; Sat, 31 May 2003 01:23:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12208 for ; Sat, 31 May 2003 01:23:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19LyoG-00055C-00 for avt@ietf.org; Sat, 31 May 2003 01:21:40 -0400 Received: from [202.62.83.99] (helo=gateway.blr.dlink.com) by ietf-mx with esmtp (Exim 4.12) id 19LyoE-000553-00 for avt@ietf.org; Sat, 31 May 2003 01:21:39 -0400 Received: from bino (localhost [127.0.0.1]) by gateway.blr.dlink.com (8.11.0/8.11.0) with SMTP id h4V5VDE16548; Sat, 31 May 2003 11:01:13 +0530 Message-ID: <001f01c32735$406ad900$8964a8c0@bino> From: "Bino George" To: "Awais Ali" , References: <02ec01c326e9$daeb3930$8001a8c0@albab> Subject: Re: [AVT] packing audio and SID frames in the same RTP packet Date: Sat, 31 May 2003 10:56:55 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C32763.59CF28A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C32763.59CF28A0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ----------------------------------------- (on the network)---------------- email-body was scanned and no virus found email-body was scanned and no virus found -----------------------------------------D-Link R & D E-Mail Traffic----------- ------=_NextPart_000_001C_01C32763.59CF28A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Ali: Both RFC's are correct. RFC 3389 refering to SID frame representation = for sample based codecs like G.711, where VAD is not an inherent = mechanism (to codec algorithm) and frame size is also not fixed.Here to = distinguish SID frames from normal speech frame, SID frames are = represented with seperate Payload type(13).=20 But G.729 & G.723 has VAD functionality internal to codec algorithm = and G.723 frame has frame Indication to differentiate between the 6.3, = 5.3 and SID frames. In G.729 this is achieved by in a tricky way by = make use of frame length. Please read "draft-ietf-avt-profile-new-12" = for details. bino =20 ----- Original Message -----=20 From: Awais Ali=20 To: avt@ietf.org=20 Sent: Saturday, May 31, 2003 1:57 AM Subject: [AVT] packing audio and SID frames in the same RTP packet Hi All May be somebody can clarify a confusion I am having right now.=20 RFC 1890 specifies that Audio frames and sid frames can be packed in = the same RTP packets for example in section 4.5.3 it says "There is no = restriction on how 4, 20, and 24 octet frames are intermixed." However = RFC 3389 describes a separate payload type for sid frames, which implies = that audio and sid frames cannot be in the same packet because they will = have different payload types. So the question is can I put both audio and sid frames in the same RTP = packet?. With G.723.1 for example I will have and RTP packet with = payload type of 4 and it will have both 20 and 4 octet frames in it. Regards Ali ------=_NextPart_000_001C_01C32763.59CF28A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Ali:
   Both RFC's are correct. RFC 3389 = refering to=20 SID frame representation for sample based codecs like G.711, where VAD = is not an=20 inherent mechanism (to codec algorithm) and frame size is also not=20 fixed.Here to distinguish SID frames from = normal speech=20 frame, SID frames are represented with seperate Payload type(13). =
 
    But G.729 & G.723 has=20 VAD functionality internal to codec algorithm and G.723 frame has = frame=20 Indication to differentiate between the 6.3, 5.3 and SID frames. = In G.729=20 this is achieved by in a tricky way by make use of frame=20 length. Please read = "draft-ietf-avt-profile-new-12"=20 for details.
bino
  
----- Original Message -----
From:=20 Awais = Ali=20
Sent: Saturday, May 31, 2003 = 1:57=20 AM
Subject: [AVT] packing audio = and SID=20 frames in the same RTP packet

Hi All
 
May be somebody can clarify a = confusion I am=20 having right now.
 
RFC 1890 specifies that Audio frames = and sid=20 frames can be packed in the same RTP packets for example in section = 4.5.3 it=20 says "There is no restriction on how 4, 20, and 24 octet frames are=20 intermixed." However RFC 3389 describes a separate payload type for = sid=20 frames, which implies that audio and sid frames cannot be in the same = packet=20 because they will have different payload types.
 
So the question is can I put both = audio and sid=20 frames in the same RTP packet?.  With G.723.1 for example I will = have and=20 RTP packet with payload type of 4 and it will have both 20 and 4 octet = frames=20 in it.
 
 
Regards
Ali
------=_NextPart_000_001C_01C32763.59CF28A0-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sat May 31 10:00:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01958 for ; Sat, 31 May 2003 10:00:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4VE0B115500 for avt-archive@odin.ietf.org; Sat, 31 May 2003 10:00:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VDxnB15444; Sat, 31 May 2003 09:59:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4VDwcB15397 for ; Sat, 31 May 2003 09:58:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01916 for ; Sat, 31 May 2003 09:58:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19M6qq-0007QU-00 for avt@ietf.org; Sat, 31 May 2003 09:56:52 -0400 Received: from mail.cs.tu-berlin.de ([130.149.17.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19M6qp-0007QR-00 for avt@ietf.org; Sat, 31 May 2003 09:56:51 -0400 Received: from hobel.cs.tu-berlin.de (stewe@basta.cs.tu-berlin.de [130.149.17.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id PAA28271; Sat, 31 May 2003 15:57:23 +0200 (MET DST) Message-Id: <5.2.0.9.2.20030531095556.0243ad90@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 31 May 2003 09:56:27 -0400 To: Stephen Casner From: Stephan Wenger Subject: Re: [AVT] Meeting in Vienna Cc: AVT WG In-Reply-To: <20030530080123.S48880-100000@oak.packetdesign.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: avt-admin@ietf.org Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , I'll be in Wien, and I'll want to take about H.264 packetization (for the last time ;-) Stephan At 08:13 AM 5/30/2003 -0700, Stephen Casner wrote: >Folks, > >You may have noted that AVT is not yet on the schedule for Vienna. >Colin and I would first like to know how much business we have -- that >is, who would like an agenda slot -- and how many people are planning >to attend. > >Please send a message to us now if you would like an agenda slot. >We'd also like to hear from those who are planning to attend and those >who are planning not to attend. You may also cc the avt mailing list >if you'd like the group to be aware of your topic request. Thanks. > > -- Steve > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt