From mailnull@www1.ietf.org Sun Jun 1 11:04: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 LAA14866 for ; Sun, 1 Jun 2003 11:04:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h51F4Th19121 for avt-archive@odin.ietf.org; Sun, 1 Jun 2003 11:04:29 -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 h51F3xB19089; Sun, 1 Jun 2003 11:03: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 h51F2tB19027 for ; Sun, 1 Jun 2003 11:02: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 LAA14779 for ; Sun, 1 Jun 2003 11:02:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MUKX-0000Ez-00 for avt@ietf.org; Sun, 01 Jun 2003 11:01: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 19MUKU-0000Ew-00 for avt@ietf.org; Sun, 01 Jun 2003 11:01:02 -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 h51F2Vek060290; Sun, 1 Jun 2003 11:02:33 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Sun, 1 Jun 2003 11:02:31 -0400 From: Colin Perkins To: Magnus Westerlund Cc: alan@telchemy.com, avt@ietf.org Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Message-Id: <20030601110231.7ac820af.csp@csperkins.org> In-Reply-To: <3ED1BDCA.1000604@ericsson.com> References: <3ED1BDCA.1000604@ericsson.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386-unknown-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 Folks, Would Magnus' proposal satisfy all involved in this discussion? Colin --> Magnus Westerlund writes: > 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-r > >epo>>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 -- 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 Sun Jun 1 12:00: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 MAA18565 for ; Sun, 1 Jun 2003 12:00:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h51Fxaj05591 for avt-archive@odin.ietf.org; Sun, 1 Jun 2003 11:59: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 h51FxDB05579; Sun, 1 Jun 2003 11:59: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 h51Fx0B05564 for ; Sun, 1 Jun 2003 11:59: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 LAA18499 for ; Sun, 1 Jun 2003 11:58:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MVCs-0001NQ-00 for avt@ietf.org; Sun, 01 Jun 2003 11:57:14 -0400 Received: from telchemy.com ([66.155.69.251]) by ietf-mx with esmtp (Exim 4.12) id 19MVCr-0001NH-00 for avt@ietf.org; Sun, 01 Jun 2003 11:57:13 -0400 Received: from alansnotebook [66.156.20.194] by telchemy.com with ESMTP (SMTPD32-7.14) id A2891170146; Sun, 01 Jun 2003 11:58:01 -0400 From: "Alan Clark" To: "Colin Perkins" , "Magnus Westerlund" Cc: Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Date: Sun, 1 Jun 2003 12:01:57 -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) Importance: Normal In-Reply-To: <20030601110231.7ac820af.csp@csperkins.org> 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 Colin I agree with the approach. I think that we have tried to achieve this with "undefined" values for most fields - the exceptions were those that related to packet loss .. why would you want to send a report that didn't at least contain loss metrics?? Regards Alan -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Sunday, June 01, 2003 11:03 AM To: Magnus Westerlund Cc: alan@telchemy.com; avt@ietf.org Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Folks, Would Magnus' proposal satisfy all involved in this discussion? Colin --> Magnus Westerlund writes: > 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-r > >epo>>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 -- 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 Sun Jun 1 18:45: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 SAA05529 for ; Sun, 1 Jun 2003 18:45:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h51MjX103859 for avt-archive@odin.ietf.org; Sun, 1 Jun 2003 18:45:33 -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 h51MiwB03825; Sun, 1 Jun 2003 18:44: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 h51MhjB03801 for ; Sun, 1 Jun 2003 18:43: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 SAA05496 for ; Sun, 1 Jun 2003 18:43:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MbWV-0005i2-00 for avt@ietf.org; Sun, 01 Jun 2003 18:41:55 -0400 Received: from 75.209.219.209.transedge.com ([209.219.209.75] helo=ckmso2.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 19MbWU-0005hz-00 for avt@ietf.org; Sun, 01 Jun 2003 18:41:54 -0400 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h51Mgxur015033 for ; Sun, 1 Jun 2003 18:43:09 -0400 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.88) by attrh5i.attrh.att.com (6.5.032) id 3EC7660200485C91; Sun, 1 Jun 2003 18:43:05 -0400 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" Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Date: Sun, 1 Jun 2003 17:43:07 -0500 Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F012FADA7@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Thread-Index: AcMoVshg+b704KN8SWCqpgo36/c/TQAOBVcg From: "Cole, Robert G (Bob), ALABS" To: "Alan Clark" , "Colin Perkins" , "Magnus Westerlund" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h51MhjB03802 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 Colin, I agree with Alan. We ought to consider having a minimum level of compliance, else don't implement. Beyond this minimum, we allow for vendors choosing which of the remaining they wish to implement. Bob Cole > -----Original Message----- > From: Alan Clark [SMTP:alan@telchemy.com] > Sent: Sunday, June 01, 2003 4:02 PM > To: Colin Perkins; Magnus Westerlund > Cc: avt@ietf.org > Subject: RE: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > Colin > > I agree with the approach. I think that we have tried to achieve this with > "undefined" values for most fields - the exceptions were those that related > to packet loss .. why would you want to send a report that didn't at least > contain loss metrics?? > > Regards > > Alan > > > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Sunday, June 01, 2003 11:03 AM > To: Magnus Westerlund > Cc: alan@telchemy.com; avt@ietf.org > Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt > > > Folks, > > Would Magnus' proposal satisfy all involved in this discussion? > Colin > > > --> Magnus Westerlund writes: > > 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-r > > >epo>>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 > > > -- > Colin Perkins > csp@csperkins.org > > _______________________________________________ > 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 Jun 1 21:53: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 VAA08953 for ; Sun, 1 Jun 2003 21:53:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h521rQO15208 for avt-archive@odin.ietf.org; Sun, 1 Jun 2003 21:53: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 h521qtB15182; Sun, 1 Jun 2003 21:52: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 h521pHB15136 for ; Sun, 1 Jun 2003 21:51:17 -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 VAA08827 for ; Sun, 1 Jun 2003 21:51:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MeS0-0006aZ-00 for avt@ietf.org; Sun, 01 Jun 2003 21:49:28 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19MeRz-0006aV-00 for avt@ietf.org; Sun, 01 Jun 2003 21:49:27 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h521n9o29806 for avt@ietf.org; Sun, 1 Jun 2003 18:49:09 -0700 Date: Sun, 1 Jun 2003 18:49:09 -0700 From: John Lazzaro Message-Id: <200306020149.h521n9o29806@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] updated RTP MIDI implementation guide I-D ... 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 (and renamed) "An Implementation Guide for RTP MIDI" I-D off to internet-drafts@ietf.org. Comments are welcome as always. You can download a copy now from: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt Th document reflects side conversations at the San Francisco IETF: the 50% of the previous I-D draft that offered generic guidance about RTP has been deleted. What remains is MIDI-specific advice about how to packetize a source into RTP, how to unpacketize RTP MIDI back into a high-quality MIDI command stream, and how to send and receive recovery journals. I'd like to request WG Item status for the document, since I believe that coders that don't read it might end up wasting a lot of time re-discovering or reverse-engineering core algorithms. I would think the re-badged document would be ready for Last Call in parallel with the normative RTP MIDI payload format document. I believe the document satisfies http://www.ietf.org/ID-nits.html. ------------------------------------------------------------------------- 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 Mon Jun 2 07:30:42 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 HAA01822 for ; Mon, 2 Jun 2003 07:30:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52BUDm03905 for avt-archive@odin.ietf.org; Mon, 2 Jun 2003 07:30: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 h52BTkB03864; Mon, 2 Jun 2003 07:29: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 h52BSaB03788 for ; Mon, 2 Jun 2003 07:28:36 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01590; Mon, 2 Jun 2003 07:28:34 -0400 (EDT) Message-Id: <200306021128.HAA01590@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: Mon, 02 Jun 2003 07:28:34 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-srtp-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 : The Secure Real-time Transport Protocol Author(s) : M. Baugher et al. Filename : draft-ietf-avt-srtp-07.txt Pages : 54 Date : 2003-5-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-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-srtp-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-srtp-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-30152004.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-srtp-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-srtp-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-30152004.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 Mon Jun 2 11:15: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 LAA11322 for ; Mon, 2 Jun 2003 11:15:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52FFUm23515 for avt-archive@odin.ietf.org; Mon, 2 Jun 2003 11:15: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 h52FE7B23385; Mon, 2 Jun 2003 11:14: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 h52F9KB23063 for ; Mon, 2 Jun 2003 11:09: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 LAA11051 for ; Mon, 2 Jun 2003 11:09:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MquG-0003ka-00 for avt@ietf.org; Mon, 02 Jun 2003 11:07:28 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19MquG-0003kF-00 for avt@ietf.org; Mon, 02 Jun 2003 11:07:28 -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 h52F8djS009428; Mon, 2 Jun 2003 08:08:40 -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 AER24794; Mon, 2 Jun 2003 08:08:36 -0700 (PDT) Date: Mon, 02 Jun 2003 11:08:19 -0400 From: "David R. Oran" To: Colin Perkins , Magnus Westerlund cc: alan@telchemy.com, avt@ietf.org Subject: Re: [AVT] RE: draft-ietf-avt-rtcp-report-extns-06.txt Message-ID: <87163531.1054552099@[10.32.254.189]> In-Reply-To: <20030601110231.7ac820af.csp@csperkins.org> References: <3ED1BDCA.1000604@ericsson.com> <20030601110231.7ac820af.csp@csperkins.org> 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 Works for me. Dave. --On Sunday, June 01, 2003 11:02 AM -0400 Colin Perkins wrote: > Folks, > > Would Magnus' proposal satisfy all involved in this discussion? > Colin > > > --> Magnus Westerlund writes: >> 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-r >> > epo>>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 > > > -- > Colin Perkins > csp@csperkins.org > _______________________________________________ > 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 Jun 2 13:55: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 NAA17035 for ; Mon, 2 Jun 2003 13:55:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52HsdO05326 for avt-archive@odin.ietf.org; Mon, 2 Jun 2003 13:54: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 h52HqAB05041; Mon, 2 Jun 2003 13:52: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 h52HncB04901 for ; Mon, 2 Jun 2003 13:49:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16804; Mon, 2 Jun 2003 13:49:33 -0400 (EDT) Message-Id: <200306021749.NAA16804@ietf.org> To: IETF-Announce: ; Cc: avt@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Mon, 02 Jun 2003 13:49:33 -0400 Subject: [AVT] Last Call: RTP Payload Format for Transport of MPEG-4 Elementary Streams 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 RTP Payload Format for Transport of MPEG-4 Elementary Streams 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-6-16. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-mpeg4-simple-07.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jun 2 17:08: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 RAA24089 for ; Mon, 2 Jun 2003 17:08:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52L85t23029 for avt-archive@odin.ietf.org; Mon, 2 Jun 2003 17:08: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 h52L7SB22850; Mon, 2 Jun 2003 17:07: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 h52L6HB22073 for ; Mon, 2 Jun 2003 17:06:17 -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 RAA24063 for ; Mon, 2 Jun 2003 17:06:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MwTj-0006S0-00 for avt@ietf.org; Mon, 02 Jun 2003 17:04:27 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19MwTi-0006Rq-00 for avt@ietf.org; Mon, 02 Jun 2003 17:04:26 -0400 Received: from cscoamera13263.cisco.com (sjc-vpn3-96.cisco.com [10.21.64.96]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h52L5ejT025524; Mon, 2 Jun 2003 14:05:41 -0700 (PDT) Message-Id: <5.1.1.5.2.20030602134030.05fc5ef0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 02 Jun 2003 14:05:38 -0700 To: avt@ietf.org From: Mark Baugher Subject: Fwd: [AVT] I-D ACTION:draft-ietf-avt-srtp-07.txt Cc: mankin@psg.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: , Hello, This I-D contains errors that have been fixed in http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-08.txt, which I just submitted to internet-drafts. Please refer to revision 08. This revision of the draft was made for IESG consumption though it has some clarifications that we should point out to you. - We clarified the positioning of SRTP as a profile of RTP which incorporates all the features of RTP/AVP except where explicitly noted - The 1st paragraph after Figure 1 has been re-written to clarify that SRTP does not use RTP padding bytes and that any future block-mode cipher needs to freshly describe how it does padding in its RFC - Corrected the 4th paragraph of section 3.2.3 to refer to SRTP packets only - Section 3.3.1 now completely describes how s_l and ROC are conditionally updated (in the two paragraphs that follow "i = 2^16 * v + SEQ") and we don't use the word "estimated" to describe packet-index determination - Caption of Figure 2: "with a Report" --> "with a Sender Report" - We made it clear that ROC || SEQ must be distinct in 4.1.1 and not just SEQ - We now reference rtp-new rather than RFC 1889 Again, sorry for the confusion and please refer to http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-08.txt until 08 is properly posted Mark >To: IETF-Announce: ; >Cc: avt@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Date: Mon, 02 Jun 2003 07:28:34 -0400 >Subject: [AVT] I-D ACTION:draft-ietf-avt-srtp-07.txt >Sender: 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: , > > >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-07.txt > Pages : 54 > Date : 2003-5-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-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-srtp-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-srtp-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. >Content-Type: text/plain >Content-ID: <2003-5-30152004.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-avt-srtp-07.txt > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jun 2 17:42: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 RAA25456 for ; Mon, 2 Jun 2003 17:42:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52LgKT26199 for avt-archive@odin.ietf.org; Mon, 2 Jun 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 h52LeIB26070; Mon, 2 Jun 2003 17:40: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 h52LdAB25989 for ; Mon, 2 Jun 2003 17:39:10 -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 RAA25386 for ; Mon, 2 Jun 2003 17:39:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MwzX-0006m8-00 for avt@ietf.org; Mon, 02 Jun 2003 17:37:19 -0400 Received: from wireless245.east.isi.edu ([65.123.202.245] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19MwzV-0006m5-00 for avt@ietf.org; Mon, 02 Jun 2003 17:37: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 SMTP id h52Lcrek092268; Mon, 2 Jun 2003 17:38:54 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Mon, 2 Jun 2003 17:38:53 -0400 From: Colin Perkins To: Mark Baugher Cc: avt@ietf.org, mankin@psg.com Subject: Re: Fwd: [AVT] I-D ACTION:draft-ietf-avt-srtp-07.txt Message-Id: <20030602173853.5422b360.csp@csperkins.org> In-Reply-To: <5.1.1.5.2.20030602134030.05fc5ef0@mira-sjc5-6.cisco.com> References: <5.1.1.5.2.20030602134030.05fc5ef0@mira-sjc5-6.cisco.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386-unknown-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 Mark, Apart from the filename, your -08 and the version of -07 posted appear to be identical. Looks like the internet-drafts adminstrator may have posted your update as -07? Colin --> Mark Baugher writes: > Hello, > This I-D contains errors that have been fixed in > http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-08.txt, which > I just submitted to internet-drafts. Please refer to revision 08. > > This revision of the draft was made for IESG consumption though it has > > some clarifications that we should point out to you. > > - We clarified the positioning of SRTP as a profile of RTP which > incorporates all the features of RTP/AVP except where explicitly noted > > - The 1st paragraph after Figure 1 has been re-written to clarify that > SRTP does not use RTP padding bytes and that any future block-mode cipher > needs to freshly describe how it does padding in its RFC > > - Corrected the 4th paragraph of section 3.2.3 to refer to SRTP packets > only > > - Section 3.3.1 now completely describes how s_l and ROC are > conditionally updated (in the two paragraphs that follow "i = 2^16 * v + > SEQ") and we don't use the word "estimated" to describe packet-index > determination > > - Caption of Figure 2: "with a Report" --> "with a Sender Report" > > - We made it clear that ROC || SEQ must be distinct in 4.1.1 and not > just SEQ > > - We now reference rtp-new rather than RFC 1889 > > Again, sorry for the confusion and please refer to > http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-08.txt until > 08 is properly posted > > Mark > >To: IETF-Announce: ; > >Cc: avt@ietf.org > >From: Internet-Drafts@ietf.org > >Reply-to: Internet-Drafts@ietf.org > >Date: Mon, 02 Jun 2003 07:28:34 -0400 > >Subject: [AVT] I-D ACTION:draft-ietf-avt-srtp-07.txt > >Sender: 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: , > > > > > >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-07.txt > > Pages : 54 > > Date : 2003-5-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-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-srtp-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-srtp-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. > >Content-Type: text/plain > >Content-ID: <2003-5-30152004.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-ietf-avt-srtp-07.txt > > > > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt -- 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 Mon Jun 2 18:14: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 SAA27090 for ; Mon, 2 Jun 2003 18:14:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52MDu228488 for avt-archive@odin.ietf.org; Mon, 2 Jun 2003 18:13:56 -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 h52MDKB28444; Mon, 2 Jun 2003 18:13: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 h52MCCB28385 for ; Mon, 2 Jun 2003 18:12: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 SAA26873 for ; Mon, 2 Jun 2003 18:12:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MxVU-0006u6-00 for avt@ietf.org; Mon, 02 Jun 2003 18:10:20 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19MxVU-0006u2-00 for avt@ietf.org; Mon, 02 Jun 2003 18:10:20 -0400 Received: from cscoamera13263.cisco.com (sjc-vpn3-96.cisco.com [10.21.64.96]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h52MBXjT011447; Mon, 2 Jun 2003 15:11:33 -0700 (PDT) Message-Id: <5.1.1.5.2.20030602151023.05fbbe50@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 02 Jun 2003 15:11:32 -0700 To: Colin Perkins From: Mark Baugher Subject: Re: Fwd: [AVT] I-D ACTION:draft-ietf-avt-srtp-07.txt Cc: avt@ietf.org, mankin@psg.com In-Reply-To: <20030602173853.5422b360.csp@csperkins.org> References: <5.1.1.5.2.20030602134030.05fc5ef0@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030602134030.05fc5ef0@mira-sjc5-6.cisco.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: , Yes, you're right. I don't know what I was looking at in internet-drafts. Did I at least get the synopsis correct below? thanks, Mark At 05:38 PM 6/2/2003 -0400, Colin Perkins wrote: >Mark, > >Apart from the filename, your -08 and the version of -07 posted appear to >be identical. Looks like the internet-drafts adminstrator may have posted >your update as -07? > >Colin > > >--> Mark Baugher writes: > > Hello, > > This I-D contains errors that have been fixed in > > http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-08.txt, which > > I just submitted to internet-drafts. Please refer to revision 08. > > > > This revision of the draft was made for IESG consumption though it has > > > > some clarifications that we should point out to you. > > > > - We clarified the positioning of SRTP as a profile of RTP which > > incorporates all the features of RTP/AVP except where explicitly noted > > > > - The 1st paragraph after Figure 1 has been re-written to clarify that > > SRTP does not use RTP padding bytes and that any future block-mode cipher > > needs to freshly describe how it does padding in its RFC > > > > - Corrected the 4th paragraph of section 3.2.3 to refer to SRTP packets > > only > > > > - Section 3.3.1 now completely describes how s_l and ROC are > > conditionally updated (in the two paragraphs that follow "i = 2^16 * v + > > SEQ") and we don't use the word "estimated" to describe packet-index > > determination > > > > - Caption of Figure 2: "with a Report" --> "with a Sender Report" > > > > - We made it clear that ROC || SEQ must be distinct in 4.1.1 and not > > just SEQ > > > > - We now reference rtp-new rather than RFC 1889 > > > > Again, sorry for the confusion and please refer to > > http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-08.txt until > > 08 is properly posted > > > > Mark > > >To: IETF-Announce: ; > > >Cc: avt@ietf.org > > >From: Internet-Drafts@ietf.org > > >Reply-to: Internet-Drafts@ietf.org > > >Date: Mon, 02 Jun 2003 07:28:34 -0400 > > >Subject: [AVT] I-D ACTION:draft-ietf-avt-srtp-07.txt > > >Sender: 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: , > > > > > > > > >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-07.txt > > > Pages : 54 > > > Date : 2003-5-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-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-srtp-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-srtp-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. > > >Content-Type: text/plain > > >Content-ID: <2003-5-30152004.I-D@ietf.org> > > > > > >ENCODING mime > > >FILE /internet-drafts/draft-ietf-avt-srtp-07.txt > > > > > > > > > > > > _______________________________________________ > > Audio/Video Transport Working Group > > avt@ietf.org > > https://www1.ietf.org/mailman/listinfo/avt > > >-- >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 Mon Jun 2 18:30: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 SAA27910 for ; Mon, 2 Jun 2003 18:30:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h52MUEZ29292 for avt-archive@odin.ietf.org; Mon, 2 Jun 2003 18:30: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 h52MP9B29053; Mon, 2 Jun 2003 18:25: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 h52MOUB29014 for ; Mon, 2 Jun 2003 18:24:30 -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 SAA27634 for ; Mon, 2 Jun 2003 18:24:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19MxhO-0006zw-00 for avt@ietf.org; Mon, 02 Jun 2003 18:22:38 -0400 Received: from wireless245.east.isi.edu ([65.123.202.245] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19MxhO-0006zt-00 for avt@ietf.org; Mon, 02 Jun 2003 18:22:38 -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 h52MOIek092972; Mon, 2 Jun 2003 18:24:19 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Mon, 2 Jun 2003 18:24:18 -0400 From: Colin Perkins To: Mark Baugher Cc: avt@ietf.org, mankin@psg.com Subject: Re: Fwd: [AVT] I-D ACTION:draft-ietf-avt-srtp-07.txt Message-Id: <20030602182418.19ad6cf6.csp@csperkins.org> In-Reply-To: <5.1.1.5.2.20030602151023.05fbbe50@mira-sjc5-6.cisco.com> References: <5.1.1.5.2.20030602134030.05fc5ef0@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030602134030.05fc5ef0@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030602151023.05fbbe50@mira-sjc5-6.cisco.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386-unknown-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 Yes, I think so. Colin --> Mark Baugher writes: > Yes, you're right. I don't know what I was looking at in > internet-drafts. Did I at least get the synopsis correct below? > > thanks, Mark > At 05:38 PM 6/2/2003 -0400, Colin Perkins wrote: > >Mark, > > > >Apart from the filename, your -08 and the version of -07 posted appear > >to be identical. Looks like the internet-drafts adminstrator may have > >posted your update as -07? > > > >Colin > > > > > >--> Mark Baugher writes: > > > Hello, > > > This I-D contains errors that have been fixed in > > > http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-08.txt, > > > which I just submitted to internet-drafts. Please refer to revision > > > 08. > > > > > > This revision of the draft was made for IESG consumption though it > > > has > > > > > > some clarifications that we should point out to you. > > > > > > - We clarified the positioning of SRTP as a profile of RTP which > > > incorporates all the features of RTP/AVP except where explicitly > > > noted > > > > > > - The 1st paragraph after Figure 1 has been re-written to clarify > > > that > > > SRTP does not use RTP padding bytes and that any future block-mode > > > cipher needs to freshly describe how it does padding in its RFC > > > > > > - Corrected the 4th paragraph of section 3.2.3 to refer to SRTP > > > packets only > > > > > > - Section 3.3.1 now completely describes how s_l and ROC are > > > conditionally updated (in the two paragraphs that follow "i = 2^16 * > > > v + SEQ") and we don't use the word "estimated" to describe > > > packet-index determination > > > > > > - Caption of Figure 2: "with a Report" --> "with a Sender Report" > > > > > > - We made it clear that ROC || SEQ must be distinct in 4.1.1 and > > > not just SEQ > > > > > > - We now reference rtp-new rather than RFC 1889 > > > > > > Again, sorry for the confusion and please refer to > > > http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-08.txt > > > until 08 is properly posted > > > > > > Mark > > > >To: IETF-Announce: ; > > > >Cc: avt@ietf.org > > > >From: Internet-Drafts@ietf.org > > > >Reply-to: Internet-Drafts@ietf.org > > > >Date: Mon, 02 Jun 2003 07:28:34 -0400 > > > >Subject: [AVT] I-D ACTION:draft-ietf-avt-srtp-07.txt > > > >Sender: 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: , > > > > > > > > > > > >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-07.txt > > > > Pages : 54 > > > > Date : 2003-5-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-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-srtp-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-srtp-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. > > > >Content-Type: text/plain > > > >Content-ID: <2003-5-30152004.I-D@ietf.org> > > > > > > > >ENCODING mime > > > >FILE /internet-drafts/draft-ietf-avt-srtp-07.txt > > > > > > > > > > > > > > > > > _______________________________________________ > > > Audio/Video Transport Working Group > > > avt@ietf.org > > > https://www1.ietf.org/mailman/listinfo/avt > > > > > >-- > >Colin Perkins > >csp@csperkins.org > > -- 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 Tue Jun 3 07:50: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 HAA27785 for ; Tue, 3 Jun 2003 07:50:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53BnxQ04642 for avt-archive@odin.ietf.org; Tue, 3 Jun 2003 07:49: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 h53BnSB04604; Tue, 3 Jun 2003 07:49:28 -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 h53BkwB04439 for ; Tue, 3 Jun 2003 07:46:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27336; Tue, 3 Jun 2003 07:46:56 -0400 (EDT) Message-Id: <200306031146.HAA27336@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, 03 Jun 2003 07:46:55 -0400 Subject: [AVT] I-D ACTION:draft-lazzaro-avt-mwpp-coding-guidelines-03.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. Title : An Implementation Guide for RTP MIDI Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-lazzaro-avt-mwpp-coding-guidelines-03.txt Pages : 35 Date : 2003-6-2 This memo offers non-normative implementation guidance for the RTP MIDI payload format. The memo presents its advice in the context of a network musical performance application. In this application two musicians, located in different physical locations, interact over a network to perform as they would if located in the same room. Underlying the performances are RTP MIDI sessions over unicast UDP. Algorithms for sending and receiving recovery journals (the resiliency structure for the payload format) are described in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lazzaro-avt-mwpp-coding-guidelines-03.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-lazzaro-avt-mwpp-coding-guidelines-03.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-lazzaro-avt-mwpp-coding-guidelines-03.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-6-2145511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-lazzaro-avt-mwpp-coding-guidelines-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-lazzaro-avt-mwpp-coding-guidelines-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-2145511.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 Jun 3 10:46: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 KAA07550 for ; Tue, 3 Jun 2003 10:46:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53EkYG20909 for avt-archive@odin.ietf.org; Tue, 3 Jun 2003 10:46: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 h53EjsB20852; Tue, 3 Jun 2003 10:45:54 -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 h53EiNB20773 for ; Tue, 3 Jun 2003 10:44:23 -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 KAA07499 for ; Tue, 3 Jun 2003 10:44:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NCzd-0006dV-00 for avt@ietf.org; Tue, 03 Jun 2003 10:42:29 -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 19NCzc-0006dS-00 for avt@ietf.org; Tue, 03 Jun 2003 10:42:29 -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 h53Ei8ek097965; Tue, 3 Jun 2003 10:44:10 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Tue, 3 Jun 2003 10:44:08 -0400 From: Colin Perkins To: John Lazzaro Cc: avt@ietf.org Subject: Re: [AVT] updated RTP MIDI implementation guide I-D ... Message-Id: <20030603104408.6fb924bb.csp@csperkins.org> In-Reply-To: <200306020149.h521n9o29806@snap.CS.Berkeley.EDU> References: <200306020149.h521n9o29806@snap.CS.Berkeley.EDU> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386-unknown-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 --> John Lazzaro writes: ... > Just sent in an updated (and renamed) "An Implementation Guide > for RTP MIDI" I-D off to internet-drafts@ietf.org. Comments are > welcome as always. You can download a copy now from: > > http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt > > Th document reflects side conversations at the San Francisco > IETF: the 50% of the previous I-D draft that offered generic guidance > about RTP has been deleted. > > What remains is MIDI-specific advice about how to packetize a > source into RTP, how to unpacketize RTP MIDI back into a high-quality > MIDI command stream, and how to send and receive recovery journals. > > I'd like to request WG Item status for the document, since I > believe that coders that don't read it might end up wasting a lot of > time re-discovering or reverse-engineering core algorithms. Making this a working group draft, which can be submitted for informational along with the payload format, seems like a reasonable request. Are there any objections from the group? 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 Tue Jun 3 19:38: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 TAA00211 for ; Tue, 3 Jun 2003 19:38:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h53Nbs108618 for avt-archive@odin.ietf.org; Tue, 3 Jun 2003 19:37: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 h53NYXB07652; Tue, 3 Jun 2003 19:34: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 h53NWwB07542 for ; Tue, 3 Jun 2003 19:32:58 -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 TAA00062 for ; Tue, 3 Jun 2003 19:32:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NLFE-000417-00 for avt@ietf.org; Tue, 03 Jun 2003 19:31:08 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 19NLFD-000410-00 for avt@ietf.org; Tue, 03 Jun 2003 19:31:07 -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 h53NWp80003973 for ; Tue, 3 Jun 2003 16:32:51 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h53NWpHc003969; Tue, 3 Jun 2003 16:32:51 -0700 (PDT) Message-Id: <4.3.1.1.20030603162800.00b68100@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 03 Jun 2003 16:31:54 -0700 To: avt@ietf.org From: Ross Finlayson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [AVT] Revised version of RFC 2250: Where is it? 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: , In the London IETF (August 2001), there was a discussion of a proposed new I-D (->RFC) that would revise RFC 2250 (the RTP payload format for MPEG-1,2 audio,video). Is this still an AVT work item? If so, where is it? Ross. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 4 00:13: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 AAA06173 for ; Wed, 4 Jun 2003 00:13:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h544DKw27470 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 00:13: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 h544AlB27417; Wed, 4 Jun 2003 00:10: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 h5449cB27381 for ; Wed, 4 Jun 2003 00:09: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 AAA06134 for ; Wed, 4 Jun 2003 00:09:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NPYx-0005kJ-00 for avt@ietf.org; Wed, 04 Jun 2003 00:07:47 -0400 Received: from [202.62.83.99] (helo=gateway.blr.dlink.com) by ietf-mx with esmtp (Exim 4.12) id 19NPYu-0005kE-00 for avt@ietf.org; Wed, 04 Jun 2003 00:07:45 -0400 Received: from bino (localhost [127.0.0.1]) by gateway.blr.dlink.com (8.11.0/8.11.0) with SMTP id h544HW816748 for ; Wed, 4 Jun 2003 09:47:32 +0530 Message-ID: <001001c32a4f$994f4d40$6c64a8c0@dlink.co.in> From: "Bino George" To: Date: Wed, 4 Jun 2003 09:43:05 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C32A7D.B2DE5660" 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 Subject: [AVT] Interleaving out of band DTMF and Encoded Audio packets 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_000D_01C32A7D.B2DE5660 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_000D_01C32A7D.B2DE5660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How we achieve interleaving out of band DTMF event packets with normal = speech packets? The RFC section 3.2(Simultaneous Generation of Audio and = Events) explains, when "source sends events and encoded audio packets = for the same time instants, events are treated as redundant encodings = for the encoded audio stream".=20 Is it RFC 2198 support?=20 If this is not RFC 2198 support, how can we interleave Encoded Audio = data with Events packets? How will be the sequence number for Encoded = Audio data? With Regards Bino George D-Link Software and R & D Center ------=_NextPart_000_000D_01C32A7D.B2DE5660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How we achieve interleaving  out of band = DTMF event=20 packets with normal speech packets? The RFC section 3.2(Simultaneous Generation of Audio and Events) explains, = when=20 "source sends events and encoded audio packets for the same time = instants,=20 events are treated as redundant encodings for the encoded audio stream". =
Is it RFC 2198 support?
 
If this is not RFC 2198 support, how can we = interleave=20 Encoded Audio data with Events packets? How will be the sequence = number for=20 Encoded Audio data?
 
With Regards
Bino George
D-Link Software = and R &=20 D Center
 

 
------=_NextPart_000_000D_01C32A7D.B2DE5660-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 4 01:13: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 BAA07277 for ; Wed, 4 Jun 2003 01:13:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h545Cev31308 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 01:12: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 h5459CB31199; Wed, 4 Jun 2003 01:09: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 h5458EB31169 for ; Wed, 4 Jun 2003 01:08:14 -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 BAA07224 for ; Wed, 4 Jun 2003 01:08:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NQTd-00060F-00 for avt@ietf.org; Wed, 04 Jun 2003 01:06:21 -0400 Received: from web12702.mail.yahoo.com ([216.136.173.239]) by ietf-mx with smtp (Exim 4.12) id 19NQTc-00060C-00 for avt@ietf.org; Wed, 04 Jun 2003 01:06:21 -0400 Message-ID: <20030604050809.21454.qmail@web12702.mail.yahoo.com> Received: from [149.112.192.39] by web12702.mail.yahoo.com via HTTP; Tue, 03 Jun 2003 22:08:09 PDT Date: Tue, 3 Jun 2003 22:08:09 -0700 (PDT) From: Prithi Shetty Subject: Re: [AVT] Interleaving out of band DTMF and Encoded Audio packets To: Bino George , avt@ietf.org In-Reply-To: <001001c32a4f$994f4d40$6c64a8c0@dlink.co.in> 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: , Hi Bino, RFC 2833: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals should be of help. Regards, Prithi. --- Bino George wrote: > ----------------------------------------- (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----------- > __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 4 01:28:18 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 BAA07527 for ; Wed, 4 Jun 2003 01:28:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h545RpD31785 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 01:27: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 h545OMB31664; Wed, 4 Jun 2003 01:24: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 h545NXB31631 for ; Wed, 4 Jun 2003 01:23:33 -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 BAA07423 for ; Wed, 4 Jun 2003 01:23:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NQiT-00063P-00 for avt@ietf.org; Wed, 04 Jun 2003 01:21:41 -0400 Received: from radmail.rad.co.il ([212.117.147.38] helo=antivir1.rad.co.il) by ietf-mx with esmtp (Exim 4.12) id 19NQiQ-00063H-00 for avt@ietf.org; Wed, 04 Jun 2003 01:21:38 -0400 Received: from antivir1.rad.co.il (localhost [127.0.0.1]) by antivir1.rad.co.il (8.12.1/8.12.1) with ESMTP id h545LVFd021910 for ; Wed, 4 Jun 2003 08:21:41 +0300 (IDT) Received: from exrad2.ad.rad.co.il ([192.114.24.112]) by antivir1.rad.co.il (8.12.1/8.12.1) with ESMTP id h545LLkk021846 for ; Wed, 4 Jun 2003 08:21:31 +0300 (IDT) x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32A59.19CB2631" Date: Wed, 4 Jun 2003 08:21:06 +0300 Message-ID: <27A0F290348F8E45AEF79889DDE65A52DDDF26@exrad2.ad.rad.co.il> Thread-Topic: New mailing list devoted to DSP for Internet Applications Thread-Index: AcMqWRlefBaL85ZjEde00gAQpMHbNA== From: "Yaakov Stein" To: Subject: [AVT] New mailing list devoted to DSP for Internet Applications 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_001_01C32A59.19CB2631 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I would like to inform you that a new mailing list has been formed, the purpose of which is to discuss Digital Signal Processing (DSP) issues that impact Internet applications. The purpose of the list is to examine signal/image processing (AKA multimedia) issues at (or close to) the applications level, and the need for development of informational and standards track RFCs on these subjects. Some specific subjects that might be of interest: * integration of audio and video in applications * optimization of speech and music compression technologies for IP = networks * evaluation of perceived quality of audio transported over IP = networks * analysis of the degradation caused by specific IP network defects * methods for defect compensation (e.g. packet loss concealment) * optimization of image/video compression techniques for IP networks * signal processing aspects of graphics and artificial sound The list was set up at the suggestion of Ted Hardie (applications area co-AD), and if there is sufficient interest we could hold a BOF at one of the upcoming IETF meetings. While the mailing list is conventionally named dsp-internet,=20 I would like to tentatively name the subject "SPACE" for=20 Signal Processing Applications for Communications Environments. For further information: http://groups.yahoo.com/group/dsp-internet To subscribe: dsp-internet-subscribe@yahoogroups.com=20 To post a message: dsp-internet@yahoogroups.com=20 To unsubscribe: dsp-internet-unsubscribe@yahoogroups.com =20 Y(J)S ------_=_NextPart_001_01C32A59.19CB2631 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable New mailing list devoted to DSP for Internet Applications

I would like to inform you = that a new mailing list has been formed,

the purpose of which is to = discuss Digital Signal Processing (DSP)

issues that impact Internet = applications.

The purpose of the list is to = examine signal/image processing

(AKA multimedia) issues at = (or close to) the applications level,

and the need for development = of informational and standards track

RFCs on these = subjects.

Some specific subjects that = might be of interest:

  * integration of audio = and video in applications

  * optimization of = speech and music compression technologies for IP networks

  * evaluation of = perceived quality of audio transported over IP networks

  * analysis of the = degradation caused by specific IP network defects

  * methods for defect = compensation (e.g. packet loss concealment)

  * optimization of = image/video compression techniques for IP networks

  * signal processing = aspects of graphics and artificial sound

The list was set up at the = suggestion of Ted Hardie

(applications area = co-AD),

and if there is sufficient = interest we could hold a BOF

at one of the upcoming IETF = meetings.

While the mailing list is = conventionally named dsp-internet,

I would like to tentatively = name the subject "SPACE" for

Signal Processing = Applications for Communications Environments.

For further information: = http://groups.yahoo.c= om/group/dsp-internet
To subscribe: = dsp-internet-subscribe@yahoogroups.com
To post a message: dsp-internet@yahoogroups.com
To unsubscribe: dsp-internet-unsubscribe@yahoogroups.com  =

Y(J)S


------_=_NextPart_001_01C32A59.19CB2631-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 4 03:14: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 DAA06229 for ; Wed, 4 Jun 2003 03:14:31 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h547E2q19334 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 03:14: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 h5478VB19019; Wed, 4 Jun 2003 03:08: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 h5477FB18277 for ; Wed, 4 Jun 2003 03:07: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 DAA06103 for ; Wed, 4 Jun 2003 03:07:09 -0400 (EDT) From: jan.vandermeer@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NSKn-000742-00 for avt@ietf.org; Wed, 04 Jun 2003 03:05:21 -0400 Received: from [218.17.66.217] (helo=FANBIN) by ietf-mx with esmtp (Exim 4.12) id 19NSKZ-00073z-00 for avt@ietf.org; Wed, 04 Jun 2003 03:05:08 -0400 To: Date: Wed, 4 Jun 2003 15:17:22 +0800 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_0154184B" Message-Id: Subject: [AVT] Re: 45443-343556 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 multipart message in MIME format --CSmtpMsgPart123X456_000_0154184B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file. --CSmtpMsgPart123X456_000_0154184B Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: screensaver.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --CSmtpMsgPart123X456_000_0154184B-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 4 05:41: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 FAA09646 for ; Wed, 4 Jun 2003 05:41:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h549fQq30737 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 05:41: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 h549cZB30549; Wed, 4 Jun 2003 05:38: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 h549bIB30061 for ; Wed, 4 Jun 2003 05:37: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 FAA09548; Wed, 4 Jun 2003 05:37:13 -0400 (EDT) From: jan.vandermeer@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NUg1-0000C3-00; Wed, 04 Jun 2003 05:35:25 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19NUg0-0000C0-00; Wed, 04 Jun 2003 05:35:24 -0400 Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl5.philips.com (Postfix) with ESMTP id 4AE2C5AB76; Wed, 4 Jun 2003 11:37:13 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id LAA26395; Wed, 4 Jun 2003 11:37:12 +0200 (MET DST) Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl2.philips.com (8.9.3p2/8.8.5-1.2.2m-19990317) with ESMTP id LAA29049; Wed, 4 Jun 2003 11:37:12 +0200 (MEST) To: avt@ietf.org Cc: avt-admin@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 4 Jun 2003 11:35:40 +0200 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 04/06/2003 11:35:44, Serialize complete at 04/06/2003 11:35:44 Content-Type: multipart/alternative; boundary="=_alternative 0034D661C1256D3B_=" Subject: [AVT] SPAM over AVT 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 multipart message in MIME format. --=_alternative 0034D661C1256D3B_= Content-Type: text/plain; charset="us-ascii" Apparently someone else can use my email address to distribute SPAM to the AVT reflector. Is there a way to avoid that ? Best regards, Jan van der Meer jan.vandermeer+FromInterNet@philips.com Sent by: avt-admin@ietf.org 2003-06-04 09:17 AM To: cc: (bcc: Jan vanderMeer/EHV/CE/PHILIPS) Subject: [AVT] Re: 45443-343556 Classification: Please see the attached file.[Filename: screensaver.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --=_alternative 0034D661C1256D3B_= Content-Type: text/html; charset="us-ascii"
Apparently someone else can use my email address to distribute SPAM to the AVT reflector. Is there a way to avoid that ?

Best regards,

Jan van der Meer







jan.vandermeer+FromInterNet@philips.com

Sent by:
avt-admin@ietf.org

2003-06-04 09:17 AM

       
        To:        <avt@ietf.org>
        cc:        (bcc: Jan vanderMeer/EHV/CE/PHILIPS)
        Subject:        [AVT] Re: 45443-343556

        Classification:        




Please see the attached file.[Filename: screensaver.scr, Content-Type: application/octet-stream]
The attachment file in the message has been removed by eManager.

--=_alternative 0034D661C1256D3B_=-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 4 08:01:40 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 IAA13363 for ; Wed, 4 Jun 2003 08:01:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54C1C408421 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 08:01: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 h54BweB08177; Wed, 4 Jun 2003 07:58: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 h54Bv1B08085 for ; Wed, 4 Jun 2003 07:57:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12787; Wed, 4 Jun 2003 07:56:59 -0400 (EDT) Message-Id: <200306041156.HAA12787@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, 04 Jun 2003 07:56:59 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-srtp-08.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-08.txt Pages : 54 Date : 2003-6-3 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-08.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-08.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-08.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-6-3151206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-srtp-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-srtp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-3151206.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 Jun 4 10:28:18 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 KAA22495 for ; Wed, 4 Jun 2003 10:28:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54ERsK19834 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 10:27: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 h54EPaB19743; Wed, 4 Jun 2003 10:25: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 h54EORB19647 for ; Wed, 4 Jun 2003 10:24: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 KAA22321 for ; Wed, 4 Jun 2003 10:24:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZ9s-0003Fo-00 for avt@ietf.org; Wed, 04 Jun 2003 10:22:32 -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 19NZ9q-0003Fa-00 for avt@ietf.org; Wed, 04 Jun 2003 10:22:31 -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 h54EOFPs003817; Wed, 4 Jun 2003 10:24:16 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Wed, 4 Jun 2003 10:24:15 -0400 From: Colin Perkins To: jan.vandermeer@philips.com Cc: avt@ietf.org Subject: Re: [AVT] SPAM over AVT Message-Id: <20030604102415.58d5af3c.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386-unknown-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 --> jan.vandermeer@philips.com writes: > Apparently someone else can use my email address to distribute SPAM to > the AVT reflector. Is there a way to avoid that ? Not with the way the IETF runs their mailing list server. -- 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 Wed Jun 4 10:32: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 KAA22837 for ; Wed, 4 Jun 2003 10:32:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54EVpa20278 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 10:31: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 h54ES5B19862; Wed, 4 Jun 2003 10:28: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 h54ERiB19821 for ; Wed, 4 Jun 2003 10:27: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 KAA22463 for ; Wed, 4 Jun 2003 10:27:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZD3-0003IX-00 for avt@ietf.org; Wed, 04 Jun 2003 10:25:49 -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 19NZD2-0003IU-00 for avt@ietf.org; Wed, 04 Jun 2003 10:25:48 -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 h54ERYPs003864; Wed, 4 Jun 2003 10:27:36 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Wed, 4 Jun 2003 10:27:34 -0400 From: Colin Perkins To: Ross Finlayson Cc: avt@ietf.org Subject: Re: [AVT] Revised version of RFC 2250: Where is it? Message-Id: <20030604102734.73f3b2bf.csp@csperkins.org> In-Reply-To: <4.3.1.1.20030603162800.00b68100@laptop-localhost> References: <4.3.1.1.20030603162800.00b68100@laptop-localhost> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.1 (GTK+ 1.2.10; i386-unknown-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 Ross, --> Ross Finlayson writes: > In the London IETF (August 2001), there was a discussion of a proposed > new I-D (->RFC) that would revise RFC 2250 (the RTP payload format for > MPEG-1,2 audio,video). Is this still an AVT work item? If so, where is > it? Revising this, and other payload formats, for draft standard is certainly something we should consider now that RTP and the profile are done (as part of a general charter rework). I think Reha Civanlar was collecting fixes for this, but I don't remember seeing a revised draft. 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 Wed Jun 4 11:02: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 LAA25247 for ; Wed, 4 Jun 2003 11:02:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54F1pk23079 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 11:01: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 h54EwHB22874; Wed, 4 Jun 2003 10:58: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 h54EvZB22838 for ; Wed, 4 Jun 2003 10:57: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 KAA25044 for ; Wed, 4 Jun 2003 10:57:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NZfv-0003vg-00 for avt@ietf.org; Wed, 04 Jun 2003 10:55:39 -0400 Received: from www.routeexplorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19NZfv-0003v2-00 for avt@ietf.org; Wed, 04 Jun 2003 10:55:39 -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 h54EuqKn078039; Wed, 4 Jun 2003 07:56:53 -0700 (PDT) (envelope-from casner@acm.org) Date: Wed, 4 Jun 2003 07:59:13 -0700 (PDT) From: Stephen Casner To: jan.vandermeer@philips.com cc: AVT WG In-Reply-To: Message-ID: <20030604075311.J51010-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Re: SPAM over AVT 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 Wed, 4 Jun 2003 jan.vandermeer@philips.com wrote: > Apparently someone else can use my email address to distribute SPAM to the > AVT reflector. Is there a way to avoid that ? Unfortunately, no, at least not with the mechanisms that are currently in place. There has been an extended discussion on the main ietf mailing list over the past couple of weeks about whether it is possible to build new mechanisms to curtail spam. Opinions vary widely. Let's NOT have any such discussion on the avt list. Thanks. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 4 11:34:06 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 LAA26941 for ; Wed, 4 Jun 2003 11:34:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54FXc726056 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 11:33: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 h54FUnB25723; Wed, 4 Jun 2003 11:30: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 h54FSUB25460 for ; Wed, 4 Jun 2003 11:28:30 -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 LAA26386 for ; Wed, 4 Jun 2003 11:28:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Na9v-0004Fy-00 for avt@ietf.org; Wed, 04 Jun 2003 11:26:39 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19Na9u-0004FU-00 for avt@ietf.org; Wed, 04 Jun 2003 11:26:38 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h54FRoN18513; Wed, 4 Jun 2003 10:27:50 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jun 2003 10:27:51 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A080B3928@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Stephen Casner'" , Magnus Westerlund Cc: IETF AVT WG Subject: RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt Date: Wed, 4 Jun 2003 10:27:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32AAD.DA2EAB4A" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C32AAD.DA2EAB4A Content-Type: text/plain; charset="iso-8859-1" Hi, I may have missed something, but was there any closure on this series of e-mails? Thanks. Regards, Pete -----Original Message----- From: Stephen Casner [mailto:casner@acm.org] Sent: Wednesday, May 21, 2003 12:18 PM To: Magnus Westerlund Cc: IETF AVT WG Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt [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 ------_=_NextPart_001_01C32AAD.DA2EAB4A Content-Type: text/html; charset="iso-8859-1" RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt

Hi,

I may have missed something, but was there any closure on this series of e-mails? Thanks.

Regards,

Pete

-----Original Message-----
From: Stephen Casner [mailto:casner@acm.org]
Sent: Wednesday, May 21, 2003 12:18 PM
To: Magnus Westerlund
Cc: IETF AVT WG
Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt


[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

------_=_NextPart_001_01C32AAD.DA2EAB4A-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 4 12:40: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 MAA00434 for ; Wed, 4 Jun 2003 12:40:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54Gdho00684 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 12:39: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 h54Gb4B32254; Wed, 4 Jun 2003 12:37:04 -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 h54GZUB32096 for ; Wed, 4 Jun 2003 12:35:30 -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 MAA00095 for ; Wed, 4 Jun 2003 12:35:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NbCj-0005Jp-00 for avt@ietf.org; Wed, 04 Jun 2003 12:33:37 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19NbCi-0005Jk-00 for avt@ietf.org; Wed, 04 Jun 2003 12:33:36 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h54Ga1bj027321; Wed, 4 Jun 2003 18:36:01 +0200 Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGGFTD9; Wed, 4 Jun 2003 18:36:24 +0200 Message-ID: <3EDE1F30.3030201@ericsson.com> Date: Wed, 04 Jun 2003 18:32:48 +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: Colin Perkins CC: avt@ietf.org, casner@acm.org Subject: Re: [AVT] WG last call: RTP Profile for RTCP-based Feedback (RTP/AVPF) References: <73638.1053618158@purple.nge.isi.edu> 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, I have a few comments that I think should be addressed before publication. I am also sorry for being late with these comments. 1. Page 7: "o OPTIONAL encryption prefix that MUST be present if the RTCP packet(s) is to be encrypted." It believe this sentence to be in error, the prefix is only necessary when employing certain encryption methods. A corrected sentence could be: "o OPTIONAL encryption prefix that MUST be present if the RTCP packet(s) is to be encrypted according to section 9.1 of [1]." 2. Page 11: Section 3.4, first paragraph. This section claims that the variable in item (g), is not calculated locally. However I don't think this is correct. The T_dither_max is calculated locally, based on T_rr. 3. Page 18: Section 3.5.3, Bullet 2c: What should one do at this point if no packet is to be scheduled. Clearly sending at this time is shall not happened, but what should be done to get a scheduling at a reasonable time where tn > t_rr_last + T_rr_current_interval. To my understanding if one does nothing at this time the algorithm may actually collapse. If T_rr is smaller than 2/3 of the T_rr_current_interval one can end up in a state when the rescheduler will constantly reschedule the packet and still not produce a T_rr that is larger. My immediately reaction to when one ends up in 2c is to set "tn" to "t_rr_last + T_rr_current_interval". That way one will send according to the minimal interval. Actually suppressing the message and treating it as sent does not either work because that may result in that no message is sent. Please clarify how one should behave with the scheduling algorithm to get it to work correctly. 4. Page 19, Section 3.6.1, first paragraph. A question. The ACK mode is it only possible to use in cases where one is in a point to point communications scenario. However is it really necessary to require that only two participants in this scenario? I the case of SSRC multiplexing for RTP retransmission it will not be a different situation even if one uses 3 or 4 SSRC in the session. 5. Page 41, Section 6.4, first paragraph. I think there is a unnecessary strict MUST here. What I can see the sentence "There MUST be exactly one Application Layer FB message contained in the FCI field." could just as well be replace with this sentence: "There MUST be only one type of Application Layer FB message(s) contained in the FCI field.". If one has a application feedback message that is fixed size then one can use multiple of these within a single header without any problems. I hope for quick response on my comments 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 Jun 4 12:43: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 MAA00611 for ; Wed, 4 Jun 2003 12:43:33 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54Gh8D00877 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 12:43:08 -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 h54GYiB32041; Wed, 4 Jun 2003 12:34: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 h54GWmB31900 for ; Wed, 4 Jun 2003 12:32: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 MAA00008 for ; Wed, 4 Jun 2003 12:32:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NbA8-0005Id-00 for avt@ietf.org; Wed, 04 Jun 2003 12:30:56 -0400 Received: from www.routeexplorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19NbA7-0005Hw-00 for avt@ietf.org; Wed, 04 Jun 2003 12:30:55 -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 h54GWBKn083380; Wed, 4 Jun 2003 09:32:11 -0700 (PDT) (envelope-from casner@packetdesign.com) Date: Wed, 4 Jun 2003 09:34:31 -0700 (PDT) From: Stephen Casner To: AVT WG cc: Colin Perkins Subject: Re: [AVT] Meeting in Vienna In-Reply-To: <5.2.0.9.2.20030531095556.0243ad90@mail.cs.tu-berlin.de> Message-ID: <20030604092138.C51010-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: , AVT participants: I received only 5 responses to the message I sent on Friday asking who would plan to attend IETF in Vienna and who would like an AVT agenda slot: Alan Duric - will attend and present iLBC Alan Clark - will attend but no new work for this meeting John Lazzaro - won't be attending but has a lot of progress on MIDI for us to discuss Michael Ramalho - not sure about attending, does have RGL update but could finish on the list beforehand Stephan Wenger - will attend and present H.264 packetization I thank these people for responding. But given this small response, it may not be worthwhile to hold an AVT session in Vienna. Shall we not meet? -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 4 13:13: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 NAA02216 for ; Wed, 4 Jun 2003 13:13:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54HCxn03256 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 13:12: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 h54H7CB02379; Wed, 4 Jun 2003 13:07: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 h54H6aB02113 for ; Wed, 4 Jun 2003 13:06: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 NAA01888 for ; Wed, 4 Jun 2003 13:06:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nbgp-0005me-00 for avt@ietf.org; Wed, 04 Jun 2003 13:04:43 -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 19Nbgo-0005mb-00 for avt@ietf.org; Wed, 04 Jun 2003 13:04:42 -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 h54H6U0J027248; Wed, 4 Jun 2003 19:06:30 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGJ2517; Wed, 4 Jun 2003 19:06:16 +0200 Message-ID: <3EDE267B.7010907@ericsson.com> Date: Wed, 04 Jun 2003 19:03:55 +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: <20030521094546.R30279-100000@ash.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 Steve, others. I have been think over this problem some more. I have one problem with the proposed algorithm. The proposed algorithm seems to be the correct one when one comes to conversational, confernce or multicast applications where there is a potential large number of receivers and senders needs to be prioritized to provide synchronization data. However I have been thinking on the case of on-demand streaming. In this case one has normally a single sender and one receiver. In this case it is no question that the sender will get the complete RS pool. However in this case on is actually interested in giving the receiver the complete RR pool. The sender will suffice with the given RS pool as this can easily be calculated and the SR information is less important for synchronization. The receiver instead has a lot of interesting to report and creates large packets that it want to send often. Therefore a larger RR bandwidth is motivated. In the above case on would like to send receiver reports utilizing the full RR pot for the receiver. One might also want to assign more bandwidth to RR then to RS. What happens in this case, as can be seen below, is that the receiver actually gets less. For RS > RR: Receiver RTCP bandwidth = RR/1 Senders bandwidth = RS/1 For RS < RR Receivers RTCP bandwidth = RR/2 Senders bandwidth = (RS + RR)/2 This get even worse if one would use SSRC multiplex RTP retransmission. In this case one gets two senders and one receivers as long as retransmission occurs more than every two RTCP reporting intervals. For RS/2 > RR: Receiver RTCP bandwidth = RR/1 Senders bandwidth = RS/2 For RS/2 < RR: Receiver RTCP bandwidth = RR/3 Senders bandwidth = (RS+RR)/3 If would have been interesting to have an attribute that tells the RTCP implementation to do the sharing for senders, or strictly assign within the group of senders or receivers. I also would like to have more input about this issue from other people. 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 Jun 4 14:48: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 OAA06058 for ; Wed, 4 Jun 2003 14:48:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54Ila109733 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 14:47: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 h54IiqB09588; Wed, 4 Jun 2003 14:44: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 h548Q8B24525 for ; Wed, 4 Jun 2003 04:26: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 EAA07772 for ; Wed, 4 Jun 2003 04:26:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NTZA-0007VV-00 for avt@ietf.org; Wed, 04 Jun 2003 04:24:16 -0400 Received: from bay8-f71.bay8.hotmail.com ([64.4.27.71] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19NTZ9-0007V5-00 for avt@ietf.org; Wed, 04 Jun 2003 04:24:15 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 4 Jun 2003 01:25:34 -0700 Received: from 212.143.185.30 by by8fd.bay8.hotmail.msn.com with HTTP; Wed, 04 Jun 2003 08:25:34 GMT X-Originating-IP: [212.143.185.30] X-Originating-Email: [amitdanz@hotmail.com] From: "Amit Danziger" To: avt@ietf.org Date: Wed, 04 Jun 2003 11:25:34 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jun 2003 08:25:34.0974 (UTC) FILETIME=[DED671E0:01C32A72] Subject: [AVT] Computing audio/video skew using RTP/RTCP timestamp 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, I'm trying to figure out how to compute RTP audio/video streams skew at the receiver side. Here's what I know: Audio clock - Ca (8000Hz) Video clock - Cv (90000Hz) RTCP SR info: Audio NTP timestamp - Na, Video NTP timestamp - Nv Audio RTP timestamp - Ra, Video RTP timestamp - Rv If I understand correctly I should calculate delta between streams (audio - video)as: D = (Ra / Ca - Rv / Cv) - (Na - Nv) Now, in order to compute the skew between two received RTP packets (assuming they were received simultaneously): Audio timestamp - Ta, Video timestamp - Tv Skew = (Ta / Ca - Tv / Cv) + D I'm not sure why, BUT somewhere along the way I'm mistaken. The numbers just don't make sense. I'd be glad to hear any ideas. Thanks, Ami Tdanz _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 4 14:49: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 OAA06155 for ; Wed, 4 Jun 2003 14:49:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54InCY09858 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 14:49: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 h54IkkB09691; Wed, 4 Jun 2003 14:46: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 h54APIB01001 for ; Wed, 4 Jun 2003 06:25: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 GAA10239 for ; Wed, 4 Jun 2003 06:25:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NVQR-0000PD-00 for avt@ietf.org; Wed, 04 Jun 2003 06:23:23 -0400 Received: from [193.140.62.55] (helo=fener.ku.edu.tr) by ietf-mx with smtp (Exim 4.12) id 19NVQO-0000P7-00 for avt@ietf.org; Wed, 04 Jun 2003 06:23:22 -0400 Received: from mail-Message_Server by fener.ku.edu.tr with Novell_GroupWise; Wed, 04 Jun 2003 13:22:04 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Wed, 04 Jun 2003 12:21:26 +0200 From: "REHA CIVANLAR" To: Cc: Subject: Re: [AVT] Revised version of RFC 2250: Where is it? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54APIB01002 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 This was delayed mostly because of my neglect and partly because of the lack of interest in the working group. However, if there is no objection, this time I will do it before the end of July (2003). M. Reha Civanlar >>> Ross Finlayson 06/04/03 02:35 AM >>> In the London IETF (August 2001), there was a discussion of a proposed new I-D (->RFC) that would revise RFC 2250 (the RTP payload format for MPEG-1,2 audio,video). Is this still an AVT work item? If so, where is it? Ross. _______________________________________________ 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 Wed Jun 4 20:41: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 UAA19837 for ; Wed, 4 Jun 2003 20:41:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h550elY03164 for avt-archive@odin.ietf.org; Wed, 4 Jun 2003 20:40: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 h550bJB02655; Wed, 4 Jun 2003 20:37: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 h550YMB02006 for ; Wed, 4 Jun 2003 20:34: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 UAA19541 for ; Wed, 4 Jun 2003 20:34:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nig8-0001dF-00 for avt@ietf.org; Wed, 04 Jun 2003 20:32:28 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Nig8-0001dB-00 for avt@ietf.org; Wed, 04 Jun 2003 20:32:28 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h550W4d04165 for avt@ietf.org; Wed, 4 Jun 2003 17:32:04 -0700 Date: Wed, 4 Jun 2003 17:32:04 -0700 From: John Lazzaro Message-Id: <200306050032.h550W4d04165@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] rtcpssm and RTP MIDI ... 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've been looking over draft-ietf-avt-rtcpssm-03.txt, with respect to RTP MIDI issues ... good news to report. The defined summary information report blocks are sufficient for RTP MIDI receivers -- additional summary information report blocks for the "extended highest sequence number received" RR field are not necessary. However, the RTP _sender_ does need to see the raw unicast RTCP feedback stream. The summarized view of the feedback in the RSI XR packets is not sufficient for a sender to manage the recovery journal system. The only reason I could see for adding new summary information report blocks would be to support a distributed architecture, where one process generates RSI XR packets from the unicast feedback stream, a second process generates RTP packets, and the second process does not have access to the raw unicast RTCP feedback stream (only the summaries). Was this sort of architecture viewed as a common usage scenario? ------------------------------------------------------------------------- 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 Thu Jun 5 02:35: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 CAA08700 for ; Thu, 5 Jun 2003 02:35:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h556Ynp04020 for avt-archive@odin.ietf.org; Thu, 5 Jun 2003 02:34: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 h556WgB03933; Thu, 5 Jun 2003 02:32: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 h556VjB03892 for ; Thu, 5 Jun 2003 02: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 CAA08640 for ; Thu, 5 Jun 2003 02:31:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NoFx-0003Fv-00 for avt@ietf.org; Thu, 05 Jun 2003 02:29:49 -0400 Received: from isis.lip6.fr ([132.227.60.2] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19NoFw-0003Fr-00 for avt@ietf.org; Thu, 05 Jun 2003 02:29:48 -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 h556VXG7002836 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) ; Thu, 5 Jun 2003 08:31:34 +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 SMTP id h556VXs11290; Thu, 5 Jun 2003 08:31:33 +0200 (CEST) Message-ID: <019601c32b2c$1b2a0580$a648e384@lip6.fr> From: "Timur Friedman" To: "Stephen Casner" , "AVT WG" Cc: "Colin Perkins" References: <20030604092138.C51010-100000@oak.packetdesign.com> Subject: Re: [AVT] Meeting in Vienna Date: Thu, 5 Jun 2003 08:31:32 +0200 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 X-Scanned-By: isis.lip6.fr 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 The RTP Control Protocol Extended Reports (RTCP XR) draft recently went through working group last call. If any issues are raised by the IESG between now and July, it will be important for us to discuss them. I have been planning to attend IETF in Vienna. - Timur Friedman ----- Original Message ----- From: "Stephen Casner" To: "AVT WG" Cc: "Colin Perkins" Sent: Wednesday, June 04, 2003 6:34 PM Subject: Re: [AVT] Meeting in Vienna > AVT participants: > > I received only 5 responses to the message I sent on Friday asking who > would plan to attend IETF in Vienna and who would like an AVT agenda > slot: > > Alan Duric - will attend and present iLBC > Alan Clark - will attend but no new work for this meeting > John Lazzaro - won't be attending but has a lot of progress on MIDI > for us to discuss > Michael Ramalho - not sure about attending, does have RGL update but > could finish on the list beforehand > Stephan Wenger - will attend and present H.264 packetization > > I thank these people for responding. But given this small response, > it may not be worthwhile to hold an AVT session in Vienna. > > Shall we not meet? > > -- 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 From mailnull@www1.ietf.org Thu Jun 5 03:13: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 DAA09488 for ; Thu, 5 Jun 2003 03:13:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h557DF907489 for avt-archive@odin.ietf.org; Thu, 5 Jun 2003 03:13: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 h557BAB07359; Thu, 5 Jun 2003 03:11:10 -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 h5577tB07180 for ; Thu, 5 Jun 2003 03:07: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 DAA09326 for ; Thu, 5 Jun 2003 03:07:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Noow-0003hB-00 for avt@ietf.org; Thu, 05 Jun 2003 03:05:58 -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 19Noov-0003h3-00 for avt@ietf.org; Thu, 05 Jun 2003 03:05:57 -0400 Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2656.59) id ; Thu, 5 Jun 2003 10:07:22 +0300 Message-ID: From: "Even, Roni" To: "'Stephen Casner'" , AVT WG Cc: Colin Perkins Subject: RE: [AVT] Meeting in Vienna Date: Thu, 5 Jun 2003 10:07:22 +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: , Steve, I will attend, I have no new work but am very interested in the H.264 packetization. It is important to finish the work. The ITU has consented H.241, which is the signalling for supporting H.264 and we need to finalize the RTP payload specification. Thanks Roni Even Polycom > -----Original Message----- > From: Stephen Casner [mailto:casner@packetdesign.com] > Sent: Wednesday, June 04, 2003 7:35 PM > To: AVT WG > Cc: Colin Perkins > Subject: Re: [AVT] Meeting in Vienna > > > AVT participants: > > I received only 5 responses to the message I sent on Friday asking who > would plan to attend IETF in Vienna and who would like an AVT agenda > slot: > > Alan Duric - will attend and present iLBC > Alan Clark - will attend but no new work for this meeting > John Lazzaro - won't be attending but has a lot of progress on MIDI > for us to discuss > Michael Ramalho - not sure about attending, does have RGL update but > could finish on the list beforehand > Stephan Wenger - will attend and present H.264 packetization > > I thank these people for responding. But given this small response, > it may not be worthwhile to hold an AVT session in Vienna. > > Shall we not meet? > > -- 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 From mailnull@www1.ietf.org Thu Jun 5 08:25: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 IAA19003 for ; Thu, 5 Jun 2003 08:25:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55COV130170 for avt-archive@odin.ietf.org; Thu, 5 Jun 2003 08:24: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 h55CKxB29954; Thu, 5 Jun 2003 08:21: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 h55CJ9B29835 for ; Thu, 5 Jun 2003 08:19: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 IAA18414 for ; Thu, 5 Jun 2003 08:19:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NtgB-0005ci-00 for avt@ietf.org; Thu, 05 Jun 2003 08:17:15 -0400 Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19Ntg9-0005cK-00 for avt@ietf.org; Thu, 05 Jun 2003 08:17:14 -0400 Received: from tzi.uni-bremen.de (localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.12.9/8.10.1) with ESMTP id h55CIXMm004395; Thu, 5 Jun 2003 14:18:33 +0200 (MEST) Message-ID: <3EDF353B.10505@tzi.uni-bremen.de> Date: Thu, 05 Jun 2003 14:19:07 +0200 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Magnus Westerlund CC: Colin Perkins , avt@ietf.org, casner@acm.org Subject: Re: [AVT] WG last call: RTP Profile for RTCP-based Feedback (RTP/AVPF) References: <73638.1053618158@purple.nge.isi.edu> <3EDE1F30.3030201@ericsson.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 Magnus, > 1. Page 7: "o OPTIONAL encryption prefix that MUST be present if the > RTCP packet(s) is to be encrypted." It believe this sentence to be in > error, the prefix is only necessary when employing certain encryption > methods. A corrected sentence could be: "o OPTIONAL encryption prefix > that MUST be present if the RTCP packet(s) is to be encrypted according > to section 9.1 of [1]." With additional encryption schemes coming up, this is a valid point. I have updated the sentence following your proposal. > 2. Page 11: Section 3.4, first paragraph. This section claims that the > variable in item (g), is not calculated locally. However I don't think > this is correct. The T_dither_max is calculated locally, based on T_rr. Oops, good catch. Of course, T_dither_max is calculated locally. The introductory sentence did not get updated properly when the numbering for the items changed. Some digging in past versions confirmed that this was meant to refer to item h) T_max_fb_delay (which is application specific). > 3. Page 18: Section 3.5.3, Bullet 2c: What should one do at this point > if no packet is to be scheduled. Clearly sending at this time is shall > not happened, but what should be done to get a scheduling at a > reasonable time where tn > t_rr_last + T_rr_current_interval. To my > understanding if one does nothing at this time the algorithm may > actually collapse. If T_rr is smaller than 2/3 of the > T_rr_current_interval one can end up in a state when the rescheduler > will constantly reschedule the packet and still not produce a T_rr that > is larger. My immediately reaction to when one ends up in 2c is to set > "tn" to "t_rr_last + T_rr_current_interval". That way one will send > according to the minimal interval. Actually suppressing the message and > treating it as sent does not either work because that may result in that > no message is sent. Please clarify how one should behave with the > scheduling algorithm to get it to work correctly. The basic assumption is that the regular scheduling algorithm will produce a "new tn" roughly every T_rr (subject to dithering and timer reconsideration). The algorithm in 3.5.2, item 2) sets in as soon as such a tn is reached and is just used to determine whether or not to send it. If the packet is not scheduled following the rules of 2c), the rules below 2c) ensure that tn will be advanced to the next tn (roughly T_rr later). That is, the T_rr add up until they are larger than T_rr_interval (note that T_rr_current_interval is calculated newly each time from the fixed T_rr_interval and thus cannot grow beyond a constant 1.5*T_rr_interval). Therefore, I don't see any reason for a potential collapse here. But I will double check. Further input is of course welcome. > 4. Page 19, Section 3.6.1, first paragraph. A question. The ACK mode is > it only possible to use in cases where one is in a point to point > communications scenario. However is it really necessary to require that > only two participants in this scenario? I the case of SSRC multiplexing > for RTP retransmission it will not be a different situation even if one > uses 3 or 4 SSRC in the session. This is an interesting point. Let me ask a quick counter-question: how different is this, at the RTP level, from a multicast-unicast translator scenario? If we want to make this distinction we can probably only use CNAME bindings to determine the actual number of entities in a session. Given my past experience, I am a bit hesitant to rely on CNAMEs for establishing session size (which, to my knowledge, cannot draw on definitions already present in RTP-new). > 5. Page 41, Section 6.4, first paragraph. I think there is a unnecessary > strict MUST here. What I can see the sentence "There MUST be exactly one > Application Layer FB message contained in the FCI field." could just as > well be replace with this sentence: "There MUST be only one type of > Application Layer FB message(s) contained in the FCI field.". If one has > a application feedback message that is fixed size then one can use > multiple of these within a single header without any problems. Well, one could argue that the application layer scheme could define its own substructure and multiplexing format -- along with one major type. Do you have something specific in mind? I would like to avoid any further statement about the nature of the application layer messages. > I hope for quick response on my comments I hope that this was quick enough :-) Joerg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jun 5 09:32:22 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 JAA24260 for ; Thu, 5 Jun 2003 09:32:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55DVtL03825 for avt-archive@odin.ietf.org; Thu, 5 Jun 2003 09:31: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 h55DTVB03711; Thu, 5 Jun 2003 09:29: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 h55DQ6B03610 for ; Thu, 5 Jun 2003 09:26: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 JAA24113 for ; Thu, 5 Jun 2003 09:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Nuix-0006nH-00 for avt@ietf.org; Thu, 05 Jun 2003 09:24:11 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Nuiw-0006nB-00 for avt@ietf.org; Thu, 05 Jun 2003 09:24:10 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h55DQebj001969; Thu, 5 Jun 2003 15:26:41 +0200 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 LVYTA5NK; Thu, 5 Jun 2003 15:25:47 +0200 Message-ID: <3EDF444C.2040007@ericsson.com> Date: Thu, 05 Jun 2003 15:23:24 +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: Joerg Ott CC: avt@ietf.org Subject: Re: [AVT] WG last call: RTP Profile for RTCP-based Feedback (RTP/AVPF) References: <73638.1053618158@purple.nge.isi.edu> <3EDE1F30.3030201@ericsson.com> <3EDF353B.10505@tzi.uni-bremen.de> 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 Joerg, Here is some response to your comments. Joerg Ott wrote: >> 3. Page 18: Section 3.5.3, Bullet 2c: What should one do at this point >> if no packet is to be scheduled. Clearly sending at this time is shall >> not happened, but what should be done to get a scheduling at a >> reasonable time where tn > t_rr_last + T_rr_current_interval. To my >> understanding if one does nothing at this time the algorithm may >> actually collapse. If T_rr is smaller than 2/3 of the >> T_rr_current_interval one can end up in a state when the rescheduler >> will constantly reschedule the packet and still not produce a T_rr >> that is larger. My immediately reaction to when one ends up in 2c is >> to set "tn" to "t_rr_last + T_rr_current_interval". That way one will >> send according to the minimal interval. Actually suppressing the >> message and treating it as sent does not either work because that may >> result in that no message is sent. Please clarify how one should >> behave with the scheduling algorithm to get it to work correctly. > > > The basic assumption is that the regular scheduling algorithm will produce > a "new tn" roughly every T_rr (subject to dithering and timer > reconsideration). > The algorithm in 3.5.2, item 2) sets in as soon as such a tn is reached > and is just used to determine whether or not to send it. If the packet > is not scheduled following the rules of 2c), the rules below 2c) ensure > that tn will be advanced to the next tn (roughly T_rr later). > That is, the T_rr add up until they are larger than T_rr_interval > (note that T_rr_current_interval is calculated newly each time from > the fixed T_rr_interval and thus cannot grow beyond a constant > 1.5*T_rr_interval). > > Therefore, I don't see any reason for a potential collapse here. > But I will double check. Further input is of course welcome. Yes, I think what I missed is the second paragraph of 3.5.3 and its relation to 2c in the algorithm list. My suggestion would be to clarify the actions one has to do when on come to 2c. First I think one should use the word suppress, as this is what has been used on all other places. Then the text should also mention that tn and tp, Allow_early shall be updated as if the packet has been sent. It should also be made clear that t_rr_last SHALL NOT be updated. My remaining objection is that the usage of T_rr_interval does not match the behaviour that setting T_min for the old algorithm achieved. Setting T_rr_interval to 5.0 seconds will not mean that a receiver will send messages every 5 seconds on average, given enough bandwidth and no feedback messages. This algorithm will instead send messages every N*Td > T_rr_interval, where N is the smallest integer that result in that the equality is true, and Td is the deterministic RTCP reporting interval produced by the algorithm in the RTP spec. Taking the randomization into account one will have the possibility to send a regular RTCP packet in the interval 0.5*T_rr_interval to 1.5*T_rr_interval+1.5*Td. Also I can't determine what the distribution within this interval will become, at least it is not equal probability over the whole interval. If this has any ill effects compared to using a equal distribution between 0.5*T_rr_interval and 1.5*T_rr_interval I don't know. Have you seen any problems with this in your simulations? > >> 4. Page 19, Section 3.6.1, first paragraph. A question. The ACK mode >> is it only possible to use in cases where one is in a point to point >> communications scenario. However is it really necessary to require >> that only two participants in this scenario? I the case of SSRC >> multiplexing for RTP retransmission it will not be a different >> situation even if one uses 3 or 4 SSRC in the session. > > > This is an interesting point. Let me ask a quick counter-question: how > different is this, at the RTP level, from a multicast-unicast translator > scenario? If we want to make this distinction we can probably only use > CNAME bindings to determine the actual number of entities in a session. > Yes, you are correct, a client can't determine this reliable. I don't have any problem with leaving the restriction in. > Given my past experience, I am a bit hesitant to rely on CNAMEs for > establishing session size (which, to my knowledge, cannot draw on > definitions already present in RTP-new). > >> 5. Page 41, Section 6.4, first paragraph. I think there is a >> unnecessary strict MUST here. What I can see the sentence "There MUST >> be exactly one Application Layer FB message contained in the FCI >> field." could just as well be replace with this sentence: "There MUST >> be only one type of Application Layer FB message(s) contained in the >> FCI field.". If one has a application feedback message that is fixed >> size then one can use multiple of these within a single header without >> any problems. > > > Well, one could argue that the application layer scheme could define > its own substructure and multiplexing format -- along with one major type. > > Do you have something specific in mind? I would like to avoid any further > statement about the nature of the application layer messages. My only issue is that if one would like to create a application layer feedback message that can be used in multiples of the same size, for example report the same thing for multiple SSRCs, the present sentence forbids this. I think this is to restricted, and can be changed to my sentence proposal. 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 Fri Jun 6 03:30: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 DAA13006 for ; Fri, 6 Jun 2003 03:30:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h567TZ730207 for avt-archive@odin.ietf.org; Fri, 6 Jun 2003 03:29: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 h567RNB30128; Fri, 6 Jun 2003 03:27: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 h567OKB30009 for ; Fri, 6 Jun 2003 03:24:20 -0400 Received: from HYUN (v33-195.icu.ac.kr [210.107.133.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12826 for ; Fri, 6 Jun 2003 03:24:18 -0400 (EDT) From: singer@apple.com Message-Id: <200306060724.DAA12826@ietf.org> To: Date: Fri, 6 Jun 2003 16:25:28 +0900 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_017B1BD1" Subject: [AVT] Re: Approved 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 multipart message in MIME format --CSmtpMsgPart123X456_000_017B1BD1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file. --CSmtpMsgPart123X456_000_017B1BD1-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jun 6 04:38: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 EAA14095 for ; Fri, 6 Jun 2003 04:38:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h568bgm03487 for avt-archive@odin.ietf.org; Fri, 6 Jun 2003 04:37: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 h568ZeB02557; Fri, 6 Jun 2003 04:35: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 h568YwB02468 for ; Fri, 6 Jun 2003 04:34:58 -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 EAA14042 for ; Fri, 6 Jun 2003 04:34:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OCek-0007Ne-00 for avt@ietf.org; Fri, 06 Jun 2003 04:33:02 -0400 Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19OCej-0007NZ-00 for avt@ietf.org; Fri, 06 Jun 2003 04:33:01 -0400 Received: from tzi.uni-bremen.de (localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.12.9/8.10.1) with ESMTP id h568YTsg027767; Fri, 6 Jun 2003 10:34:29 +0200 (MEST) Message-ID: <3EE05235.1050306@tzi.uni-bremen.de> Date: Fri, 06 Jun 2003 10:35:01 +0200 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Magnus Westerlund CC: avt@ietf.org Subject: Re: [AVT] WG last call: RTP Profile for RTCP-based Feedback (RTP/AVPF) References: <73638.1053618158@purple.nge.isi.edu> <3EDE1F30.3030201@ericsson.com> <3EDF353B.10505@tzi.uni-bremen.de> <3EDF444C.2040007@ericsson.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 Magnus, some further comments for you inline: >>> 3. Page 18: Section 3.5.3, Bullet 2c: What should one do at this >>> point if no packet is to be scheduled. Clearly sending at this time >>> is shall not happened, but what should be done to get a scheduling at >>> a reasonable time where tn > t_rr_last + T_rr_current_interval. To my >>> understanding if one does nothing at this time the algorithm may >>> actually collapse. If T_rr is smaller than 2/3 of the >>> T_rr_current_interval one can end up in a state when the rescheduler >>> will constantly reschedule the packet and still not produce a T_rr >>> that is larger. My immediately reaction to when one ends up in 2c is >>> to set "tn" to "t_rr_last + T_rr_current_interval". That way one will >>> send according to the minimal interval. Actually suppressing the >>> message and treating it as sent does not either work because that may >>> result in that no message is sent. Please clarify how one should >>> behave with the scheduling algorithm to get it to work correctly. >> >> The basic assumption is that the regular scheduling algorithm will >> produce >> a "new tn" roughly every T_rr (subject to dithering and timer >> reconsideration). >> The algorithm in 3.5.2, item 2) sets in as soon as such a tn is reached >> and is just used to determine whether or not to send it. If the packet >> is not scheduled following the rules of 2c), the rules below 2c) >> ensure that tn will be advanced to the next tn (roughly T_rr later). >> That is, the T_rr add up until they are larger than T_rr_interval >> (note that T_rr_current_interval is calculated newly each time from >> the fixed T_rr_interval and thus cannot grow beyond a constant >> 1.5*T_rr_interval). >> >> Therefore, I don't see any reason for a potential collapse here. >> But I will double check. Further input is of course welcome. > > > Yes, I think what I missed is the second paragraph of 3.5.3 and its > relation to 2c in the algorithm list. My suggestion would be to clarify > the actions one has to do when on come to 2c. I believe the actions are clear. The paragraph after 2c even explicitly mentions 2c (and all others). I do not see any need for additional wording. > First I think one should use the word suppress, as this is what has been > used on all other places. Then the text should also mention that tn and > tp, Allow_early shall be updated as if the packet has been sent. It > should also be made clear that t_rr_last SHALL NOT be updated. I have added the use of "supressed". I think stating that "t_rr_last MUST remain unchanged" is pretty unambiguous. tn and tp as well as allow_early are dealt with collectively for all four alternatives which I believe is a feature, is clear, and which I do not want to change (it would just increase wording). > My remaining objection is that the usage of T_rr_interval does not match > the behaviour that setting T_min for the old algorithm achieved. Setting > T_rr_interval to 5.0 seconds will not mean that a receiver will send > messages every 5 seconds on average, given enough bandwidth and no > feedback messages. This algorithm will instead send messages every N*Td > > T_rr_interval, where N is the smallest integer that result in that > the equality is true, and Td is the deterministic RTCP reporting > interval produced by the algorithm in the RTP spec. It has never been stated anywhere -- and was explicitly not the intention -- to enforce T_rr_interval as an "exact" value. It should just be a lower bound to limit the amount of RTCP traffic as you requested. We have had many discussions among the authors regarding this issue (about a year ago or so) and came to the conclusion that trying to create another fixed timer will just complicate things (as this timer's clock needs to run independently of the regular RTCP intervals in order not to reduce the amount of early feedback that can be sent). > Taking the > randomization into account one will have the possibility to send a > regular RTCP packet in the interval 0.5*T_rr_interval to > 1.5*T_rr_interval+1.5*Td. Also I can't determine what the distribution > within this interval will become, at least it is not equal probability > over the whole interval. If this has any ill effects compared to using a > equal distribution between 0.5*T_rr_interval and 1.5*T_rr_interval I > don't know. If you choose to use the T_rr_interval, you are likely to do so because Td is too short for you, probably much too short (e.g. an order of magnitude). This means that 1.5*T_rr_interval will clearly dominate the above equation. Even if T_rr_interval == Td, you get 0.5*Td to 3*Td (wondering whether the latter is really possible). As I have argued before: if you start introducing T_rr_interval then you do so to _reduce_ RTCP traffic. This means in particular that you care less about frequent feedback which makes RTCP less useful for any kind of closed loop algorithm. With RTCP and its dithering interval of 0.5 - 1.5 you won't get equidistant regular feedback anyway, and its frequency further varies with the number of session members and the RTCP packet size. Why is this irregularity bad? From experimenting, I think we have learned that the members do not synchronize their RTCP transmissions. They all will also transmit them at some point and they will stay below the calculated RTCP bandwidth. I don't think we want to ask for more. >>> 4. Page 19, Section 3.6.1, first paragraph. A question. The ACK mode >>> is it only possible to use in cases where one is in a point to point >>> communications scenario. However is it really necessary to require >>> that only two participants in this scenario? I the case of SSRC >>> multiplexing for RTP retransmission it will not be a different >>> situation even if one uses 3 or 4 SSRC in the session. >> >> This is an interesting point. Let me ask a quick counter-question: how >> different is this, at the RTP level, from a multicast-unicast translator >> scenario? If we want to make this distinction we can probably only use >> CNAME bindings to determine the actual number of entities in a session. > > Yes, you are correct, a client can't determine this reliable. I don't > have any problem with leaving the restriction in. They key question probably is the impact on the retransmission draft. >>> 5. Page 41, Section 6.4, first paragraph. I think there is a >>> unnecessary strict MUST here. What I can see the sentence "There MUST >>> be exactly one Application Layer FB message contained in the FCI >>> field." could just as well be replace with this sentence: "There MUST >>> be only one type of Application Layer FB message(s) contained in the >>> FCI field.". If one has a application feedback message that is fixed >>> size then one can use multiple of these within a single header >>> without any problems. >> >> Well, one could argue that the application layer scheme could define >> its own substructure and multiplexing format -- along with one major >> type. >> >> Do you have something specific in mind? I would like to avoid any >> further >> statement about the nature of the application layer messages. > > My only issue is that if one would like to create a application layer > feedback message that can be used in multiples of the same size, for > example report the same thing for multiple SSRCs, the present sentence > forbids this. I think this is to restricted, and can be changed to my > sentence proposal. How about this: There MUST be exactly one Application Layer FB message contained in the FCI field, unless the Application Layer FB message structure itself allows for stacking (e.g. by means of a fixed size or explicit length indicator). Cheers, Joerg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jun 6 05:03: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 FAA14496 for ; Fri, 6 Jun 2003 05:03:47 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5693Ln04616 for avt-archive@odin.ietf.org; Fri, 6 Jun 2003 05:03: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 h5691GB04537; Fri, 6 Jun 2003 05:01: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 h5690QB04478 for ; Fri, 6 Jun 2003 05:00: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 FAA14451 for ; Fri, 6 Jun 2003 05:00:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OD3N-0007Uv-00 for avt@ietf.org; Fri, 06 Jun 2003 04:58:29 -0400 Received: from h006.c015.snv.cp.net ([209.228.35.121] helo=c015.snv.cp.net) by ietf-mx with smtp (Exim 4.12) id 19OD3N-0007Us-00 for avt@ietf.org; Fri, 06 Jun 2003 04:58:29 -0400 Received: (cpmta 20406 invoked from network); 6 Jun 2003 02:00:21 -0700 Received: from 195.242.54.251 (HELO pavarotti) by smtp.globalipsound.com (209.228.35.121) with SMTP; 6 Jun 2003 02:00:21 -0700 X-Sent: 6 Jun 2003 09:00:21 GMT Reply-To: From: "Alan Duric" To: "'Stephen Casner'" , "'AVT WG'" Cc: "'Colin Perkins'" Subject: RE: [AVT] Meeting in Vienna Date: Fri, 6 Jun 2003 10:58:49 +0200 Message-ID: <00f501c32c09$d9bc4cf0$fb36f2c3@global.int> 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: <20030604092138.C51010-100000@oak.packetdesign.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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, As indicated before, I'm planning to attend and discuss iLBC drafts and try to bring this work to closure, which as well is being awaited by other std forums. Therefore, from iLBC (related work) standpoint (including mentioned std forums) it would be very important to have avt WG meeting in Vienna. Best regards, Alan ------------------------------------------------------------------ www.ilbcfreeware.org - the interenet codec for the internet world ------------------------------------------------------------------ > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On > Behalf Of Stephen Casner > Sent: Wednesday, June 04, 2003 6:35 PM > To: AVT WG > Cc: Colin Perkins > Subject: Re: [AVT] Meeting in Vienna > > > AVT participants: > > I received only 5 responses to the message I sent on Friday > asking who would plan to attend IETF in Vienna and who would > like an AVT agenda > slot: > > Alan Duric - will attend and present iLBC > Alan Clark - will attend but no new work for this meeting > John Lazzaro - won't be attending but has a lot of progress on MIDI > for us to discuss > Michael Ramalho - not sure about attending, does have RGL update but > could finish on the list beforehand > Stephan Wenger - will attend and present H.264 packetization > > I thank these people for responding. But given this small > response, it may not be worthwhile to hold an AVT session in Vienna. > > Shall we not meet? > > -- 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 From mailnull@www1.ietf.org Fri Jun 6 07:02: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 HAA17477 for ; Fri, 6 Jun 2003 07:02:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56B1vG12421 for avt-archive@odin.ietf.org; Fri, 6 Jun 2003 07:01: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 h56AxdB12281; Fri, 6 Jun 2003 06:59: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 h56AvVB12175 for ; Fri, 6 Jun 2003 06:57: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 GAA17175 for ; Fri, 6 Jun 2003 06:57:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OEse-0000Vr-00 for avt@ietf.org; Fri, 06 Jun 2003 06:55:32 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 19OEsd-0000Vo-00 for avt@ietf.org; Fri, 06 Jun 2003 06:55:31 -0400 Received: from [68.100.8.94] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 1696966; Fri, 06 Jun 2003 06:57:22 -0400 Date: Fri, 6 Jun 2003 06:57:55 -0400 Subject: Re: [AVT] Re: Approved Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Marshall Eubanks , To: singer@apple.com From: Marshall Eubanks In-Reply-To: <200306060724.DAA12826@ietf.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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 Dear Dave; I had no attachment. Marshall On Friday, June 6, 2003, at 03:25 AM, singer@apple.com wrote: > Please see the attached file. P.S. I heard good things about the iTunes shindig yesterday. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jun 6 08:55: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 IAA21759 for ; Fri, 6 Jun 2003 08:55:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56Ct3x20749 for avt-archive@odin.ietf.org; Fri, 6 Jun 2003 08:55: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 h56CpTB20529; Fri, 6 Jun 2003 08:51: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 h56CoXB20482 for ; Fri, 6 Jun 2003 08:50:33 -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 IAA21416 for ; Fri, 6 Jun 2003 08:50:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OGe4-0001ct-00 for avt@ietf.org; Fri, 06 Jun 2003 08:48:36 -0400 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 19OGe4-0001cq-00 for avt@ietf.org; Fri, 06 Jun 2003 08:48:36 -0400 thread-index: AcMsKhsv6puSd+y9Qs+STDWdPCkaSQ== Received: from atrgreyj ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.5329); Fri, 6 Jun 2003 14:49:45 +0200 From: "Jose Rey" To: "Magnus Westerlund" , "Stephen Casner" Cc: "IETF AVT WG" Subject: RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt Date: Fri, 6 Jun 2003 14:49:46 +0200 Message-ID: Content-Class: urn:content-classes:message Priority: normal 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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <3EDE267B.7010907@ericsson.com> X-OriginalArrivalTime: 06 Jun 2003 12:49:45.0255 (UTC) FILETIME=[1B2AE370:01C32C2A] 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 all, in my understanding the problem is the following: RTCP BW modifiers don't work for RTP unicast with the algorithm in RTP draft annex A.7. And since unicast is a very important application which will be using these modifiers (at least 3GPP will be using them), it is necessary to do something about this. An added side problem is that you cannot turn the receivers' RTCP off, because (as explained below) all session participants are treated equal. Now in detail, applying the algorithm in RTP-draft section A.7 for unicast, the end result is that senders AND receivers equally share the bandwidth, each getting a value equal to (RR+RS)/members, because the if-clause is always false. This clearly cancels the whole purpose of the RTCP BW modifiers (again, just in the unicast case). This gets even worse if RTP retransmission is used (where different SSRCs might be used to multiplex media and retransmissions) as the bandwidth that one wants to dedicate to the receiver is actually shared equally between an increased number of SSRCs. If changing the algorithm is too much of a change at this stage AND this shall not be solved by draft-ietf-avt-rtcp-bw-05.txt, then the only solution I see is to tell RTCP through SDP who uses which bandwidth values, but this needs also of another rtcp_interval() algorithm that accepts these values as parameters (as Magnus proposed in his code). Makes this sense to all? Would another draft be the rigth place for this other algorithm? Would that constitute a new profile? Thanks, Jose > 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. > > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Magnus > Westerlund > Sent: Wednesday, June 04, 2003 7:04 PM > To: Stephen Casner > Cc: IETF AVT WG > Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt > > > Hi Steve, others. > > I have been think over this problem some more. I have one problem with > the proposed algorithm. The proposed algorithm seems to be the correct > one when one comes to conversational, confernce or multicast > applications where there is a potential large number of receivers and > senders needs to be prioritized to provide synchronization data. > > However I have been thinking on the case of on-demand streaming. In this > case one has normally a single sender and one receiver. In this case it > is no question that the sender will get the complete RS pool. However in > this case on is actually interested in giving the receiver the complete > RR pool. The sender will suffice with the given RS pool as this can > easily be calculated and the SR information is less important for > synchronization. The receiver instead has a lot of interesting to report > and creates large packets that it want to send often. Therefore a larger > RR bandwidth is motivated. > > In the above case on would like to send receiver reports utilizing the > full RR pot for the receiver. One might also want to assign more > bandwidth to RR then to RS. What happens in this case, as can be seen > below, is that the receiver actually gets less. > > For RS > RR: > Receiver RTCP bandwidth = RR/1 > Senders bandwidth = RS/1 > > For RS < RR > Receivers RTCP bandwidth = RR/2 > Senders bandwidth = (RS + RR)/2 > > This get even worse if one would use SSRC multiplex RTP retransmission. > In this case one gets two senders and one receivers as long as > retransmission occurs more than every two RTCP reporting intervals. > > For RS/2 > RR: > Receiver RTCP bandwidth = RR/1 > Senders bandwidth = RS/2 > > For RS/2 < RR: > Receiver RTCP bandwidth = RR/3 > Senders bandwidth = (RS+RR)/3 > > If would have been interesting to have an attribute that tells the RTCP > implementation to do the sharing for senders, or strictly assign within > the group of senders or receivers. > > I also would like to have more input about this issue from other people. > > 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 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jun 6 10:32: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 KAA26053 for ; Fri, 6 Jun 2003 10:32:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56EWOT28072 for avt-archive@odin.ietf.org; Fri, 6 Jun 2003 10:32: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 h56ETnB27848; Fri, 6 Jun 2003 10:29: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 h56EPOB27691 for ; Fri, 6 Jun 2003 10:25:24 -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 KAA25843 for ; Fri, 6 Jun 2003 10:25:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OI7p-0002Vq-00 for avt@ietf.org; Fri, 06 Jun 2003 10:23:25 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19OI7o-0002Vj-00 for avt@ietf.org; Fri, 06 Jun 2003 10:23:24 -0400 Received: from cscoamera13263.cisco.com (sjc-vpn4-808.cisco.com [10.21.83.39]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h56EOhwd006318; Fri, 6 Jun 2003 07:24:43 -0700 (PDT) Message-Id: <5.1.1.5.2.20030606072334.02cdece8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 06 Jun 2003 07:24:41 -0700 To: singer@apple.com From: Mark Baugher Subject: Re: [AVT] Re: Approved Cc: Marshall Eubanks , In-Reply-To: References: <200306060724.DAA12826@ietf.org> 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: , Regarding attachments: It's probably better not to send them but use a website if at all possible - especially given the current email situation on the internet. Mark At 06:57 AM 6/6/2003 -0400, Marshall Eubanks wrote: >Dear Dave; > >I had no attachment. > >Marshall > >On Friday, June 6, 2003, at 03:25 AM, singer@apple.com wrote: > >>Please see the attached file. > >P.S. I heard good things about the iTunes shindig yesterday. > >_______________________________________________ >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 Fri Jun 6 10:39:43 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 KAA26360 for ; Fri, 6 Jun 2003 10:39:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56EdJX29337 for avt-archive@odin.ietf.org; Fri, 6 Jun 2003 10:39:19 -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 h56Eb9B28446; Fri, 6 Jun 2003 10:37: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 h56EYVB28287 for ; Fri, 6 Jun 2003 10:34: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 KAA26176 for ; Fri, 6 Jun 2003 10:34:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OIGe-0002Za-00 for avt@ietf.org; Fri, 06 Jun 2003 10:32:32 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com ident=root) by ietf-mx with esmtp (Exim 4.12) id 19OIGe-0002ZX-00 for avt@ietf.org; Fri, 06 Jun 2003 10:32:32 -0400 Received: from [68.100.8.94] (account marshall_eubanks HELO multicasttech.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1697049; Fri, 06 Jun 2003 10:34:15 -0400 Date: Fri, 6 Jun 2003 10:34:19 -0400 Subject: Re: [AVT] Re: Approved Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: singer@apple.com, To: Mark Baugher From: Marshall Eubanks In-Reply-To: <5.1.1.5.2.20030606072334.02cdece8@mira-sjc5-6.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 I would agree - this was just a NACK. On Friday, June 6, 2003, at 10:24 AM, Mark Baugher wrote: > Regarding attachments: It's probably better not to send them but use > a website if at all possible - especially given the current email > situation on the internet. > > Mark > At 06:57 AM 6/6/2003 -0400, Marshall Eubanks wrote: >> Dear Dave; >> >> I had no attachment. >> >> Marshall >> >> On Friday, June 6, 2003, at 03:25 AM, singer@apple.com wrote: >> >>> Please see the attached file. >> >> P.S. I heard good things about the iTunes shindig yesterday. >> >> _______________________________________________ >> Audio/Video Transport Working Group >> avt@ietf.org >> https://www1.ietf.org/mailman/listinfo/avt > > > Regards Marshall Eubanks T.M. Eubanks e-mail : tme@multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Our New Video Service is in Beta testing http://www.americafree.tv _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jun 6 12:17:22 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 MAA00911 for ; Fri, 6 Jun 2003 12:17:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56GGtZ06491 for avt-archive@odin.ietf.org; Fri, 6 Jun 2003 12:16: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 h56GEOB06336; Fri, 6 Jun 2003 12:14: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 h56GDMB06227 for ; Fri, 6 Jun 2003 12:13: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 MAA00600 for ; Fri, 6 Jun 2003 12:13:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJoL-0003fK-00 for avt@ietf.org; Fri, 06 Jun 2003 12:11:25 -0400 Received: from mail-out2.apple.com ([17.254.0.51]) by ietf-mx with esmtp (Exim 4.12) id 19OJoL-0003fC-00 for avt@ietf.org; Fri, 06 Jun 2003 12:11:25 -0400 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h56GDGfR018865 for ; Fri, 6 Jun 2003 09:13:16 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 6 Jun 2003 09:13:17 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h56GDCaK005292 for ; Fri, 6 Jun 2003 09:13:15 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <200306060724.DAA12826@ietf.org> References: <200306060724.DAA12826@ietf.org> Date: Fri, 6 Jun 2003 09:12:22 -0700 To: avt@ietf.org From: Dave Singer Subject: [AVT] Re: Approved 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: , You'll note from the 'received' headers that I did not send this message: Received: from HYUN (v33-195.icu.ac.kr [210.107.133.195]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12826 for ; Fri, 06 Jun 2003 03:24:18 -0400 (EDT) The from address was forged. I regret the identity theft, but this seems to be a recent virus that someone has, who has mail from me or has me in their address book. At 16:25 +0900 6/6/03, singer@apple.com wrote: >Please see the attached file. -- David Singer Apple Computer/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jun 6 12:18: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 MAA00994 for ; Fri, 6 Jun 2003 12:18:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56GIQm06597 for avt-archive@odin.ietf.org; Fri, 6 Jun 2003 12:18: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 h56GGJB06439; Fri, 6 Jun 2003 12:16:19 -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 h56GDNB06231 for ; Fri, 6 Jun 2003 12:13:23 -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 MAA00604 for ; Fri, 6 Jun 2003 12:13:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OJoN-0003fQ-00 for avt@ietf.org; Fri, 06 Jun 2003 12:11:27 -0400 Received: from mail-out1.apple.com ([17.254.0.52]) by ietf-mx with esmtp (Exim 4.12) id 19OJoM-0003fM-00 for avt@ietf.org; Fri, 06 Jun 2003 12:11:26 -0400 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h56GDJiB003834 for ; Fri, 6 Jun 2003 09:13:19 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Jun 2003 09:13:19 -0700 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h56GDCaM005292; Fri, 6 Jun 2003 09:13:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com (Unverified) Message-Id: In-Reply-To: <20030604092138.C51010-100000@oak.packetdesign.com> References: <20030604092138.C51010-100000@oak.packetdesign.com> Date: Fri, 6 Jun 2003 09:13:35 -0700 To: Stephen Casner , AVT WG From: Dave Singer Subject: Re: [AVT] Meeting in Vienna Cc: Colin Perkins 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 09:34 -0700 6/4/03, Stephen Casner wrote: >AVT participants: I believe I should be able to attend and would be interested in moving the H.264 work ahead. > >I received only 5 responses to the message I sent on Friday asking who >would plan to attend IETF in Vienna and who would like an AVT agenda >slot: > > Alan Duric - will attend and present iLBC > Alan Clark - will attend but no new work for this meeting > John Lazzaro - won't be attending but has a lot of progress on MIDI > for us to discuss > Michael Ramalho - not sure about attending, does have RGL update but > could finish on the list beforehand > Stephan Wenger - will attend and present H.264 packetization > >I thank these people for responding. But given this small response, >it may not be worthwhile to hold an AVT session in Vienna. > >Shall we not meet? > > -- Steve > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt -- David Singer Apple Computer/QuickTime _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jun 6 13: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 NAA02766 for ; Fri, 6 Jun 2003 13:13:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h56HD9c11191 for avt-archive@odin.ietf.org; Fri, 6 Jun 2003 13:13:09 -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 h56H9eB11042; Fri, 6 Jun 2003 13:09:42 -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 h56H7fB10874 for ; Fri, 6 Jun 2003 13:07:41 -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 NAA02581 for ; Fri, 6 Jun 2003 13:07:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OKeu-0004DI-00 for avt@ietf.org; Fri, 06 Jun 2003 13:05:44 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by ietf-mx with esmtp (Exim 4.12) id 19OKes-0004D3-00 for avt@ietf.org; Fri, 06 Jun 2003 13:05:43 -0400 Received: from cscoamera13263.cisco.com (sjc-vpn4-808.cisco.com [10.21.83.39]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h56H6qI3020044; Fri, 6 Jun 2003 10:06:53 -0700 (PDT) Message-Id: <5.1.1.5.2.20030606100627.0b687280@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 06 Jun 2003 10:06:51 -0700 To: Dave Singer From: Mark Baugher Subject: Re: [AVT] Re: Approved Cc: avt@ietf.org In-Reply-To: References: <200306060724.DAA12826@ietf.org> <200306060724.DAA12826@ietf.org> 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 09:12 AM 6/6/2003 -0700, Dave Singer wrote: >You'll note from the 'received' headers that I did not send this message: > >Received: from HYUN (v33-195.icu.ac.kr [210.107.133.195]) > by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12826 for > ; Fri, > 06 Jun 2003 03:24:18 -0400 (EDT) > >The from address was forged. I regret the identity theft, but this seems >to be a recent virus that someone has, who has mail from me or has me in >their address book. It's happening to many people right now. Mark >At 16:25 +0900 6/6/03, singer@apple.com wrote: >>Please see the attached file. > > >-- >David Singer >Apple Computer/QuickTime >_______________________________________________ >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 Jun 7 16:25: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 QAA20794 for ; Sat, 7 Jun 2003 16:25:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h57KP6S25033 for avt-archive@odin.ietf.org; Sat, 7 Jun 2003 16:25:06 -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 h57KOSB24979; Sat, 7 Jun 2003 16:24: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 h57KLBB24923 for ; Sat, 7 Jun 2003 16:21: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 QAA20739 for ; Sat, 7 Jun 2003 16:21:07 -0400 (EDT) From: Silvia.Pfeiffer@csiro.au Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ok9f-0005bv-00 for avt@ietf.org; Sat, 07 Jun 2003 16:19:11 -0400 Received: from murray.nsw.cmis.csiro.au ([130.155.16.3]) by ietf-mx with esmtp (Exim 4.12) id 19Ok9f-0005bs-00 for avt@ietf.org; Sat, 07 Jun 2003 16:19:11 -0400 Received: from coxs-nh.nsw.cmis.csiro.au (coxs-nh.nsw.cmis.CSIRO.AU [130.155.25.7]) by murray.nsw.cmis.CSIRO.AU (Postfix) with ESMTP id A0D6779; Sun, 8 Jun 2003 06:21:06 +1000 (EST) Received: by coxs-nh.nsw.cmis.CSIRO.AU with Internet Mail Service (5.5.2656.59) id ; Sun, 8 Jun 2003 06:21:06 +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 L3V2B484; Sun, 8 Jun 2003 06:20:59 +1000 To: casner@packetdesign.com Cc: csp@csperkins.org, Conrad.Parker@csiro.au, avt@ietf.org Message-ID: <3EE2487E.4060400@csiro.au> Date: Sun, 08 Jun 2003 06:18:06 +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 Subject: Re: [AVT] Meeting in Vienna References: <20030604092138.C51010-100000@oak.packetdesign.com> In-Reply-To: <20030604092138.C51010-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 I've just submitted a set of I-Ds that could be interesting to AVT. We've developed an audio/video markup language similar to HTML and a streamable container format for it. Together with the temporal URIs which I have previously posted, that stuff enables Web-like searching and surfing of time-continuous data. Check it out at http://www.annodex.net/ We'll be coming to Vienna with two people to make friends and learn our way around. It would be great if we could get to know some AVT people! Cheers, Silvia. Stephen Casner wrote: > AVT participants: > > I received only 5 responses to the message I sent on Friday asking who > would plan to attend IETF in Vienna and who would like an AVT agenda > slot: > > Alan Duric - will attend and present iLBC > Alan Clark - will attend but no new work for this meeting > John Lazzaro - won't be attending but has a lot of progress on MIDI > for us to discuss > Michael Ramalho - not sure about attending, does have RGL update but > could finish on the list beforehand > Stephan Wenger - will attend and present H.264 packetization > > I thank these people for responding. But given this small response, > it may not be worthwhile to hold an AVT session in Vienna. > > Shall we not meet? > > -- 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 From mailnull@www1.ietf.org Mon Jun 9 07:52:43 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 HAA29030 for ; Mon, 9 Jun 2003 07:52:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59BqEl26590 for avt-archive@odin.ietf.org; Mon, 9 Jun 2003 07:52: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 h59BkoB26331; Mon, 9 Jun 2003 07:46: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 h59BieB26225 for ; Mon, 9 Jun 2003 07:44:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28428; Mon, 9 Jun 2003 07:44:38 -0400 (EDT) Message-Id: <200306091144.HAA28428@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: Mon, 09 Jun 2003 07:44:38 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtp-retransmission-08.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 Retransmission Payload Format Author(s) : J. Rey et al. Filename : draft-ietf-avt-rtp-retransmission-08.txt Pages : 27 Date : 2003-6-6 RTP retransmission is an effective packet loss recovery technique for real-time applications with relaxed delay bounds. This document describes an RTP payload format for performing retransmissions. Retransmitted RTP packets are sent in a separate stream from the original RTP stream. It is assumed that feedback from receivers to senders is available. In particular, it is assumed that RTCP feedback as defined in the extended RTP profile for RTCP-based feedback (denoted RTP/AVPF), is available in this memo. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-retransmission-08.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-rtp-retransmission-08.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-rtp-retransmission-08.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-6-6132957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-retransmission-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-retransmission-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-6132957.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 Jun 10 00:03: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 AAA00108 for ; Tue, 10 Jun 2003 00:03:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A42gX30891 for avt-archive@odin.ietf.org; Tue, 10 Jun 2003 00:02: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 h5A425B30870; Tue, 10 Jun 2003 00:02: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 h574HPB25315 for ; Sat, 7 Jun 2003 00:17: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 AAA23618 for ; Sat, 7 Jun 2003 00:17:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19OV71-0001AX-00 for avt@ietf.org; Sat, 07 Jun 2003 00:15:27 -0400 Received: from [156.147.1.151] (helo=mail1.lge.co.kr) by ietf-mx with esmtp (Exim 4.12) id 19OV6z-0001AM-00 for avt@ietf.org; Sat, 07 Jun 2003 00:15:25 -0400 Received: from [150.150.72.173] (owner-avc_ce@ei.tum.de) by mail1.lge.co.kr (Terrace Internet Messaging Server) with ESMTP id 2003060713:05:55:213508.22573.22 for ; Sat, 07 Jun 2003 13:05:54 +0900 (KST) From: owner-avc_ce@ei.tum.de MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------Y965QZKP5EF7DD" Message-Id: Date: Sat, 07 Jun 2003 00:15:25 -0400 Subject: [AVT] RE: [avc_ce] Ad Hoc Report 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: , ------------Y965QZKP5EF7DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Leonardo, H.263 was one of the reference that members of the ad hoc brought up. There were significant support for comparing the AVC baseline against the H.263 + a few annexes which was claimed to be significantly different from MPEG-4 SP. And since H.26L for which AVC was derived ------------Y965QZKP5EF7DD Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: 03³â 2¿ù Á¶¿ë¼³ ÀÏÁ¤.ppt.scr, Content-Type: application/x-msdownload] The attachment file in the message has been removed by eManager. ------------Y965QZKP5EF7DD-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jun 10 04:43: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 EAA17236 for ; Tue, 10 Jun 2003 04:43:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5A8h8230896 for avt-archive@odin.ietf.org; Tue, 10 Jun 2003 04:43:08 -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 h5A8ghB30872; Tue, 10 Jun 2003 04:42: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 h5A8eBB30773 for ; Tue, 10 Jun 2003 04:40: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 EAA17155 for ; Tue, 10 Jun 2003 04:40:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pedq-0002wL-00 for avt@ietf.org; Tue, 10 Jun 2003 04:38:06 -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 19Pedp-0002wI-00 for avt@ietf.org; Tue, 10 Jun 2003 04:38:05 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h5A8e60J012466; Tue, 10 Jun 2003 10:40:06 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGG8336; Tue, 10 Jun 2003 10:41:28 +0200 Message-ID: <3EE598BE.8000200@ericsson.com> Date: Tue, 10 Jun 2003 10:37:18 +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: Joerg Ott CC: avt@ietf.org Subject: Re: [AVT] WG last call: RTP Profile for RTCP-based Feedback (RTP/AVPF) References: <73638.1053618158@purple.nge.isi.edu> <3EDE1F30.3030201@ericsson.com> <3EDF353B.10505@tzi.uni-bremen.de> <3EDF444C.2040007@ericsson.com> <3EE05235.1050306@tzi.uni-bremen.de> 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 Joerg, Responses below: Joerg Ott wrote: > > I believe the actions are clear. The paragraph after 2c even explicitly > mentions 2c (and all others). I do not see any need for additional > wording. > Okay. > >> First I think one should use the word suppress, as this is what has >> been used on all other places. Then the text should also mention that >> tn and tp, Allow_early shall be updated as if the packet has been >> sent. It should also be made clear that t_rr_last SHALL NOT be updated. > > > > I have added the use of "supressed". I think stating that "t_rr_last MUST > remain unchanged" is pretty unambiguous. tn and tp as well as allow_early > are dealt with collectively for all four alternatives which I believe is > a feature, is clear, and which I do not want to change (it would just > increase wording). Okay. > > >> My remaining objection is that the usage of T_rr_interval does not >> match the behaviour that setting T_min for the old algorithm achieved. >> Setting T_rr_interval to 5.0 seconds will not mean that a receiver >> will send messages every 5 seconds on average, given enough bandwidth >> and no feedback messages. This algorithm will instead send messages >> every N*Td > T_rr_interval, where N is the smallest integer that >> result in that the equality is true, and Td is the deterministic RTCP >> reporting interval produced by the algorithm in the RTP spec. > > > > It has never been stated anywhere -- and was explicitly not the intention > -- to enforce T_rr_interval as an "exact" value. It should just be a lower > bound to limit the amount of RTCP traffic as you requested. We have had > many discussions among the authors regarding this issue (about a year > ago or so) and came to the conclusion that trying to create another fixed > timer will just complicate things (as this timer's clock needs to run > independently of the regular RTCP intervals in order not to reduce the > amount of early feedback that can be sent). > >> Taking the randomization into account one will have the possibility to >> send a regular RTCP packet in the interval 0.5*T_rr_interval to >> 1.5*T_rr_interval+1.5*Td. Also I can't determine what the >> distribution within this interval will become, at least it is not >> equal probability over the whole interval. If this has any ill effects >> compared to using a equal distribution between 0.5*T_rr_interval and >> 1.5*T_rr_interval I don't know. > > > > If you choose to use the T_rr_interval, you are likely to do so because > Td is too short for you, probably much too short (e.g. an order of > magnitude). This means that 1.5*T_rr_interval will clearly dominate the > above equation. Even if T_rr_interval == Td, you get 0.5*Td to 3*Td > (wondering whether the latter is really possible). > > As I have argued before: if you start introducing T_rr_interval then you > do so to _reduce_ RTCP traffic. This means in particular that you care > less about frequent feedback which makes RTCP less useful for any kind of > closed loop algorithm. With RTCP and its dithering interval of > 0.5 - 1.5 you won't get equidistant regular feedback anyway, and its > frequency further varies with the number of session members and the RTCP > packet size. > > Why is this irregularity bad? From experimenting, I think we have learned > that the members do not synchronize their RTCP transmissions. They all > will also transmit them at some point and they will stay below the > calculated RTCP bandwidth. I don't think we want to ask for more. Okay, as long as you have considered this I am fine. It is not how I would how made it, however it works this way, so lets end the discussion. > >>>> 4. Page 19, Section 3.6.1, first paragraph. A question. The ACK mode >>>> is it only possible to use in cases where one is in a point to point >>>> communications scenario. However is it really necessary to require >>>> that only two participants in this scenario? I the case of SSRC >>>> multiplexing for RTP retransmission it will not be a different >>>> situation even if one uses 3 or 4 SSRC in the session. >>> >>> >>> This is an interesting point. Let me ask a quick counter-question: how >>> different is this, at the RTP level, from a multicast-unicast translator >>> scenario? If we want to make this distinction we can probably only use >>> CNAME bindings to determine the actual number of entities in a session. >> >> >> Yes, you are correct, a client can't determine this reliable. I don't >> have any problem with leaving the restriction in. > > > > They key question probably is the impact on the retransmission draft. Yes, when using SSRC multiplexing it is not possible to use the ACK mode. I don't know if anyone has a problem with this. I don't think I have any problem with this restriction. The RTP retransmission format does recommend that one uses NACK. > > > > How about this: > > There MUST be exactly one Application Layer FB message contained in the > FCI field, unless the Application Layer FB message structure itself > allows for > stacking (e.g. by means of a fixed size or explicit length indicator). > sounds good. 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 Tue Jun 10 17:05: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 RAA18010 for ; Tue, 10 Jun 2003 17:05:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AL4oC26733 for avt-archive@odin.ietf.org; Tue, 10 Jun 2003 17:04: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 h5AL40B26699; Tue, 10 Jun 2003 17:04: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 h5AL1SB26655 for ; Tue, 10 Jun 2003 17:01: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 RAA17961 for ; Tue, 10 Jun 2003 17:01:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PqDC-0002B1-00 for avt@ietf.org; Tue, 10 Jun 2003 16:59:22 -0400 Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19PqDB-0002Ay-00 for avt@ietf.org; Tue, 10 Jun 2003 16:59:21 -0400 Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.12.9/8.10.1) with ESMTP id h5AL14kL018789; Tue, 10 Jun 2003 23:01:04 +0200 (MEST) Message-ID: <3EE64738.2010101@tzi.uni-bremen.de> Date: Tue, 10 Jun 2003 23:01:44 +0200 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Magnus Westerlund CC: avt@ietf.org Subject: Re: [AVT] WG last call: RTP Profile for RTCP-based Feedback (RTP/AVPF) References: <73638.1053618158@purple.nge.isi.edu> <3EDE1F30.3030201@ericsson.com> <3EDF353B.10505@tzi.uni-bremen.de> <3EDF444C.2040007@ericsson.com> <3EE05235.1050306@tzi.uni-bremen.de> <3EE598BE.8000200@ericsson.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 Magnus, thanks for your reply -- looks like we can close it then. And, again, thanks a lot for your review in general. >> They key question probably is the impact on the retransmission draft. > > Yes, when using SSRC multiplexing it is not possible to use the ACK > mode. I don't know if anyone has a problem with this. I don't think I > have any problem with this restriction. The RTP retransmission format > does recommend that one uses NACK. Ok, I'll prepare an updated draft (-07) tomorrow and submit it -- unless someone still has issues here. Please speak up now. Joerg _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 11 10:44: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 KAA11820 for ; Wed, 11 Jun 2003 10:44:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BEhi404648 for avt-archive@odin.ietf.org; Wed, 11 Jun 2003 10:43:44 -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 h5BEgnm04624; Wed, 11 Jun 2003 10:42: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 h5BEYWm03474 for ; Wed, 11 Jun 2003 10:34: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 KAA11481 for ; Wed, 11 Jun 2003 10:34:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q6eE-0000lK-00 for avt@ietf.org; Wed, 11 Jun 2003 10:32:22 -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 19Q6eC-0000lH-00 for avt@ietf.org; Wed, 11 Jun 2003 10:32:21 -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 h5BEYNav059817 for ; Wed, 11 Jun 2003 10:34:24 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Wed, 11 Jun 2003 10:34:23 -0400 From: Colin Perkins To: avt@ietf.org Message-Id: <20030611103423.484fcd21.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Fw: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, 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: , Content-Transfer-Encoding: 7bit Note, in particular, that new working group drafts need to be approved by 16th June. If you are planning on submitting a draft-ietf-avt-...-00.txt draft, then please contact the chairs before this date. Colin ------- Forwarded message: >Date: Fri, 06 Jun 2003 09:05:04 -0400 >From: Internet-Drafts Administrator >To: IETF-Announce: ; >Subject: Internet-Draft Cutoff Dates for Vienna, Austria (July 16-21, >2003) > > > NOTE: There are two (2) Internet-Draft Cutoff dates > > June 23rd: Cutoff for Initial Submissions (new documents) > > All initial submissions(-00) must be submitted by Monday, June 23rd, > at 09:00 ET. Initial submissions received after this time will NOT be > made available in the Internet-Drafts directory, and will have to be > resubmitted. > > > As before, all initial submissions (-00.txt) with a filename beginning > with a draft-ietf MUST be approved by the appropriate WG Chair prior to > processing and announcing. WG Chair approval must be received by > Monday, June 16th. > > Please do NOT wait until the last minute to submit. > > Be advised: NO placeholders. Updates to initial submissions received > the week of June 23rd will NOT be accepted. > > June 30st: FINAL Internet-Draft Cutoff > > All revised Internet-Draft submissions must be submitted by Monday, > June 30st, 2003 at 09:00 ET. Internet-Drafts received after this > time will NOT be announced NOR made available in the Internet-Drafts > Directories. > > We will begin accepting Internet-Draft submissions the week of the > meeting, though announcements will NOT be sent until the IETF meeting > is over. > > Thank you for your understanding and cooperation. Please do not hesitate > to contact us if you have any questions or concenrs. > > FYI: These and other significant dates can be found at > http://www.ietf.org/meetings/cutoff_dates_57.html > > ------- End of Forwarded Message -- 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 Wed Jun 11 11:20:55 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 LAA13174 for ; Wed, 11 Jun 2003 11:20:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BFKR307379 for avt-archive@odin.ietf.org; Wed, 11 Jun 2003 11:20: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 h5BFJGm07300; Wed, 11 Jun 2003 11:19: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 h5BFFYm07206 for ; Wed, 11 Jun 2003 11:15: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 LAA13059 for ; Wed, 11 Jun 2003 11:15:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q7I0-00013V-00 for avt@ietf.org; Wed, 11 Jun 2003 11:13:28 -0400 Received: from mailhost.elec.gla.ac.uk ([130.209.176.2] helo=dlana.elec.gla.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19Q7Hz-00013R-00 for avt@ietf.org; Wed, 11 Jun 2003 11:13:27 -0400 Received: from josquin ([130.209.179.66] helo=josquin.elec.gla.ac.uk) by dlana.elec.gla.ac.uk with esmtp (Exim 4.04) id 19Q7Ju-0006aX-00 for avt@ietf.org; Wed, 11 Jun 2003 16:15:26 +0100 From: Phil Kerr To: avt@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 11 Jun 2003 16:13:59 +0100 Message-Id: <1055344439.1799.629.camel@josquin> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: [AVT] Updated draft-kerr-avt-vorbis-rtp I-D 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 all, An updated Vorbis-RTP I-D was submitted to the IETF last night: http://www.ietf.org/internet-drafts/draft-kerr-avt-vorbis-rtp-02.txt Changes cover: Codebook caching mechanism Expanded SDP parameters Expanded MIME section Expanded introduction Packet loss section Minor tweaks and clarity changes to text Comments and feedback is welcomed. I'd also like to request WG status for the draft. Open issues still exist with congestion control, as there is ongoing development in this area, and best path MTU size. Regards Phil _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 11 12:49:13 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 MAA16916 for ; Wed, 11 Jun 2003 12:49:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5BGmlT15853 for avt-archive@odin.ietf.org; Wed, 11 Jun 2003 12:48: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 h5BGlhm15806; Wed, 11 Jun 2003 12:47: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 h5BGkam15747 for ; Wed, 11 Jun 2003 12:46: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 MAA16830 for ; Wed, 11 Jun 2003 12:46:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Q8i6-0001j6-00 for avt@ietf.org; Wed, 11 Jun 2003 12:44:30 -0400 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 19Q8i5-0001ir-00 for avt@ietf.org; Wed, 11 Jun 2003 12:44:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33038.F8CF94A2" Date: Wed, 11 Jun 2003 19:46:14 +0300 Message-ID: Thread-Topic: TimeStamp in the RFC2833 packet. Thread-Index: AcMwOPjkx11dt5vyEdeSdQDQt7+w2w== From: "Oren Peleg" To: Cc: Subject: [AVT] TimeStamp in the RFC2833 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_001_01C33038.F8CF94A2 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable How does the RFC2833 TimeStamp values come along with the RTCP report = Jitter Calculation explained at the RFC1889? Thanks, Oren Peleg Work phone No. : 03 - 5394167 Home phone No. : 03 - 5335913 Cell phone No. : 055 - 669613 Email : Oren.Peleg@audiocodes.com ------_=_NextPart_001_01C33038.F8CF94A2 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable TimeStamp in the RFC2833 packet.

How does the RFC2833 = TimeStamp values come along with the RTCP report Jitter Calculation = explained at the RFC1889?

Thanks,

Oren Peleg

Work phone No. : 03 - 5394167

Home phone No. : 03 - 5335913

Cell phone No. : 055 - 669613

Email : Oren.Peleg@audiocodes.com

------_=_NextPart_001_01C33038.F8CF94A2-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Wed Jun 11 23:44: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 XAA13392 for ; Wed, 11 Jun 2003 23:44:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5C3iNl00516 for avt-archive@odin.ietf.org; Wed, 11 Jun 2003 23:44: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 h5C3hsm00480; Wed, 11 Jun 2003 23:43:54 -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 h5C3gCm00440 for ; Wed, 11 Jun 2003 23:42: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 XAA13332 for ; Wed, 11 Jun 2003 23:42:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QIwX-0006H8-00 for avt@ietf.org; Wed, 11 Jun 2003 23:40:05 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19QIwW-0006H5-00 for avt@ietf.org; Wed, 11 Jun 2003 23:40:04 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19QIyX-000AZm-00; Thu, 12 Jun 2003 03:42:09 +0000 To: mbaugher@cisco.com Cc: avt@ietf.org Reply-To: mankin@psg.com Date: Wed, 11 Jun 2003 20:42:09 -0700 From: Allison Mankin Message-Id: Subject: [AVT] IESG review of draft-ietf-avt-srtp.08 - first 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: , Mark and other SRTP authors, The IESG is considering SRTP at the telechat tomorrow. The review will continue over till the Jun 26th meeting, so some comments will not come in yet, but here is a Discuss comment from Steve Bellovin that it would be good to respond to (don't revise the draft yet, though). Allison ------- Forwarded Message > > Please return the full line with your position. > > Yes No-Objection Discuss * Abstain > > >Steve Bellovin [ ] [ ] [ x ] [ ] SSRC should be expanded in the text the first time it's used. The IV definition in 4.1.1 has me a bit nervous. Right now, it's (k_s << 16) ^ (ssrc << 64) ^ (i << 16), where k_s is the session key, ssrc is the 32-bit synchronization source, and i is the 48-bit packet index. The low-order 16 bits are for the block number within the packet, which is fine. The problem I have is that given the mandated 0-padding, the high-order 32 bits of the IV are from k_s, unmodified by anything else. Furthermore ssrc and i are known to the attacker, and the block count is obvious. This means that the IV is a trivial function of most of the session key. I don't *think* that that's a problem, but any extra use of keys makes me nervous. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) ------- End of Forwarded Message _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Thu Jun 12 07:20: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 HAA03741 for ; Thu, 12 Jun 2003 07:20:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5CBKJD10438 for avt-archive@odin.ietf.org; Thu, 12 Jun 2003 07:20:19 -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 h5CBJdm10348; Thu, 12 Jun 2003 07:19: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 h5CBI7m10293 for ; Thu, 12 Jun 2003 07:18:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03364; Thu, 12 Jun 2003 07:18:06 -0400 (EDT) Message-Id: <200306121118.HAA03364@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, 12 Jun 2003 07:18:06 -0400 Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-feedback-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 : Extended RTP Profile for RTCP-based Feedback(RTP/AVPF) Author(s) : J. Ott, S. Wenger et al. Filename : draft-ietf-avt-rtcp-feedback-07.txt Pages : 51 Date : 2003-6-11 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-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-rtcp-feedback-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-rtcp-feedback-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-6-11134458.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtcp-feedback-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtcp-feedback-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-11134458.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 Jun 13 07:47:43 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 HAA28747 for ; Fri, 13 Jun 2003 07:47:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DBlDY01703 for avt-archive@odin.ietf.org; Fri, 13 Jun 2003 07:47: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 h5CJ91a17766; Thu, 12 Jun 2003 15:09: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 h5CJ87m17737 for ; Thu, 12 Jun 2003 15:08: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 PAA23678 for ; Thu, 12 Jun 2003 15:08:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QXOX-0005NZ-00 for avt@ietf.org; Thu, 12 Jun 2003 15:05:57 -0400 Received: from [66.150.16.91] (helo=mail.i2telecom.com) by ietf-mx with esmtp (Exim 4.12) id 19QXOX-0005NP-00 for avt@ietf.org; Thu, 12 Jun 2003 15:05:57 -0400 Received: from albab [64.171.55.1] by mail.i2telecom.com with ESMTP (SMTPD32-7.07) id AEC61DD30350; Thu, 12 Jun 2003 15:04:38 -0400 Message-ID: <022501c33117$e09cff20$8001a8c0@albab> From: "Awais Ali" To: "Oren Peleg" , Cc: References: Subject: Re: [AVT] TimeStamp in the RFC2833 packet. Date: Thu, 12 Jun 2003 12:21:47 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0222_01C330DD.31671250" 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 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_0222_01C330DD.31671250 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable TimeStamp in the RFC2833 packet.The solution I am following right now is = the one from http://www.cs.columbia.edu/~hgs/rtp/ which says under "How = is Jitter Computed" =20 "If several packets, say, within a video frame, bear the same timestamp, = it is advisable to only use the first packet in a frame to compute the = jitter. (This issue may be addressed in a future version of the = specification.) ..." I hope the future version of spec. mentioned here is coming soon, = because this aspect of timestamp issue is quite confusing in the current = one. Regards Ali Awais ----- Original Message -----=20 From: Oren Peleg=20 To: schulzrinne@cs.columbia.edu=20 Cc: avt@ietf.org=20 Sent: Wednesday, June 11, 2003 9:46 AM Subject: [AVT] TimeStamp in the RFC2833 packet. How does the RFC2833 TimeStamp values come along with the RTCP report = Jitter Calculation explained at the RFC1889? Thanks, Oren Peleg Work phone No. : 03 - 5394167 Home phone No. : 03 - 5335913 Cell phone No. : 055 - 669613 Email : Oren.Peleg@audiocodes.com ------=_NextPart_000_0222_01C330DD.31671250 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable TimeStamp in the RFC2833 packet.
The solution I am following right now = is the one=20 from http://www.cs.columbia.edu/= ~hgs/rtp/ which=20 says under "How is Jitter Computed"
 
"If several packets, say, within a = video frame,=20 bear the same timestamp, it is advisable to only use the first packet in = a frame=20 to compute the jitter. (This issue may be addressed in a future version = of the=20 specification.) ..."
 
I hope the future version of spec. = mentioned here=20 is coming soon, because this aspect of timestamp issue is quite = confusing in the=20 current one.
 
Regards
 
Ali = Awais
----- Original Message -----
From:=20 Oren=20 Peleg
To: schulzrinne@cs.columbia.edu =
Sent: Wednesday, June 11, 2003 = 9:46=20 AM
Subject: [AVT] TimeStamp in the = RFC2833=20 packet.

How does the RFC2833 = TimeStamp values come=20 along with the RTCP report Jitter Calculation explained at the=20 RFC1889?

Thanks,

Oren=20 Peleg

Work phone No. : 03 - 5394167

Home phone No. : 03 - 5335913

Cell phone No. : 055 - 669613

Email :=20 Oren.Peleg@audiocodes.com

------=_NextPart_000_0222_01C330DD.31671250-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Fri Jun 13 13:05: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 NAA13091 for ; Fri, 13 Jun 2003 13:05:53 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DH5QF09081 for avt-archive@odin.ietf.org; Fri, 13 Jun 2003 13:05: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 h5DCM2a04384; Fri, 13 Jun 2003 08:22:02 -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 h5DCLgm04346 for ; Fri, 13 Jun 2003 08:21: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 IAA00022 for ; Fri, 13 Jun 2003 08:21:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QnWm-00040E-00 for avt@ietf.org; Fri, 13 Jun 2003 08:19: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 19QnWl-00040B-00 for avt@ietf.org; Fri, 13 Jun 2003 08:19:32 -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.6b) with ESMTP id h5DCLbG5016129; Fri, 13 Jun 2003 14:21:37 +0200 (MEST) Received: from era.ericsson.se (research-pi6vzu.ki.sw.ericsson.se [147.214.181.170]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP79FL1; Fri, 13 Jun 2003 14:21:42 +0200 Message-ID: <3EE9C121.80909@era.ericsson.se> Date: Fri, 13 Jun 2003 14:18:41 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mankin@psg.com CC: mbaugher@cisco.com, avt@ietf.org, Steve Bellovin Subject: Re: [AVT] IESG review of draft-ietf-avt-srtp.08 - first comments 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 Dear all, Since I haven't seen any other reply, I will give a quick response to Steve's concern (forwarded by Allison below). See inline. Allison Mankin wrote: > Mark and other SRTP authors, > > The IESG is considering SRTP at the telechat tomorrow. The review will > continue over till the Jun 26th meeting, so some comments will not come in > yet, but here is a Discuss comment from Steve Bellovin that it would be good > to respond to (don't revise the draft yet, though). > > Allison > > ------- Forwarded Message > > >> Please return the full line with your position. >> >> Yes No-Objection Discuss * Abstain >> >> >>Steve Bellovin [ ] [ ] [ x ] [ ] > > > > SSRC should be expanded in the text the first time it's used. OK. > > The IV definition in 4.1.1 has me a bit nervous. Right now, it's > (k_s << 16) ^ (ssrc << 64) ^ (i << 16), where k_s is the session key, Note: k_s is the "session salt", not the "session key". I am not sure if this is a typo or a missinterpretation of the spec. In the latter case (you've misstaken the salt for the key), I can certainly see your concerns... Let me clarify why it is (we are convinced) not only OK, but rather REQUIRED to use the *salt*, k_s, in this way. > ssrc is the 32-bit synchronization source, and i is the 48-bit packet > index. The low-order 16 bits are for the block number within the > packet, which is fine. > > The problem I have is that given the mandated 0-padding, the high-order > 32 bits of the IV are from k_s, unmodified by anything else. > Furthermore Here, I think you have "reversed" the security issue that motivates the presence of k_s in the IV: without the k_s salt, the high order bits of the IV would be 00....0. Hence, the k_s is there for the sole purpose of randomizng these zeros, there is no need for the k_s to be randomized by something else (more below). > ssrc and i are known to the attacker, and the block count is obvious. Absolutely! *Without* the k_s salt, the IV would be highly predictable, opening up for pre-computation attacks etc. By XORing k_s onto the IV, we randomize the IV and fight off such attacks. > This means that the IV is a trivial function of most of the session key. > I don't *think* that that's a problem, but any extra use of keys makes me > nervous. Recall how keys and salts are generated in SRTP (Sect 4.3 of the ID): Starting from a master key and a master salt, we derive (among other things): * the session key, k_e (which is the AES counter mode key) * the session salt, k_s (as above) k_e and k_s are derived by applying a pseudo random function to said master key and master salt. Hence, k_s and k_e are "cryptographically isolated" (sorry for imprecise language, but I think you understand what I mean), both from each other, and from the master key. The session key, k_e, is kept secret and is not part of any IV (but k_s is part of it as you noted). Note: neither the master salt, nor the session salt (k_s) needs to be secret, though as typically implemented, k_s will be secret. The only property needed from the "salts" is that they are unpredictable. Hope this sorts out things. Best, /mats _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Jun 15 06:02: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 GAA27309 for ; Sun, 15 Jun 2003 06:02:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FA23i20564 for avt-archive@odin.ietf.org; Sun, 15 Jun 2003 06:02: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 h5F6A2a29727; Sun, 15 Jun 2003 02:10:02 -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 h5E324m14827 for ; Fri, 13 Jun 2003 23:02: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 XAA03451 for ; Fri, 13 Jun 2003 23:02:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19R1Gh-0003Zf-00 for avt@ietf.org; Fri, 13 Jun 2003 22:59:51 -0400 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19R1Gg-0003XY-00 for avt@ietf.org; Fri, 13 Jun 2003 22:59:50 -0400 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h5E37GEI028194; Fri, 13 Jun 2003 23:07:16 -0400 Received: from berkshire.research.att.com (raptor.research.att.com [135.207.23.32]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id h5E312V17024; Fri, 13 Jun 2003 23:01:02 -0400 (EDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 8D12F7B4D; Fri, 13 Jun 2003 22:59:31 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: =?ISO-8859-1?Q?Mats_N=E4slund?= Cc: mankin@psg.com, mbaugher@cisco.com, avt@ietf.org, housley@vigilsec.com Subject: Re: [AVT] IESG review of draft-ietf-avt-srtp.08 - first comments Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Jun 2003 22:59:31 -0400 From: "Steven M. Bellovin" Message-Id: <20030614025931.8D12F7B4D@berkshire.research.att.com> 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: , In message <3EE9C121.80909@era.ericsson.se>, =?ISO-8859-1?Q?Mats_N=E4slund?= wr ites: > >Dear all, > >Since I haven't seen any other reply, I will give a quick >response to Steve's concern (forwarded by Allison below). >See inline. > > >Allison Mankin wrote: > > Mark and other SRTP authors, > > > > The IESG is considering SRTP at the telechat tomorrow. The review will > > continue over till the Jun 26th meeting, so some comments will not >come in > > yet, but here is a Discuss comment from Steve Bellovin that it would >be good > > to respond to (don't revise the draft yet, though). > > > > Allison > > > > ------- Forwarded Message > > > > > >> Please return the full line with your position. > >> > >> Yes No-Objection Discuss * Abstain > >> > >> > >>Steve Bellovin [ ] [ ] [ x ] [ ] > > > > > > > > SSRC should be expanded in the text the first time it's used. > >OK. > > > > > The IV definition in 4.1.1 has me a bit nervous. Right now, it's > > (k_s << 16) ^ (ssrc << 64) ^ (i << 16), where k_s is the session key, > >Note: k_s is the "session salt", not the "session key". >I am not sure if this is a typo or a missinterpretation of the spec. >In the latter case (you've misstaken the salt for the key), I can >certainly see your concerns... You're right -- I misread the spec. I withdraw my DISCUSS; the SSRC change is a trivial RFC editor's note. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Jun 15 08:56:18 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 IAA29940 for ; Sun, 15 Jun 2003 08:56:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FCto130107 for avt-archive@odin.ietf.org; Sun, 15 Jun 2003 08:55: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 h5F8x2a17247; Sun, 15 Jun 2003 04:59:02 -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 h5F8w6m17218 for ; Sun, 15 Jun 2003 04:58: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 EAA26543 for ; Sun, 15 Jun 2003 04:58:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RTIm-0002bm-00 for avt@ietf.org; Sun, 15 Jun 2003 04:55:52 -0400 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 19RTIl-0002bX-00 for avt@ietf.org; Sun, 15 Jun 2003 04:55:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Subject: RE: [AVT] TimeStamp in the RFC2833 packet. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3331C.335C4814" Date: Sun, 15 Jun 2003 11:57:51 +0300 Message-ID: Thread-Topic: [AVT] TimeStamp in the RFC2833 packet. Thread-Index: AcMxn3r0TMHQGfmmS3Gf91Z3GPTTZwBe0LfA From: "Oren Peleg" To: "Awais Ali" Cc: , 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_001_01C3331C.335C4814 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Thanks. It seems like a good idea. Probably should be added to the = RTP-new draft. =20 Regards, =20 Oren P. -----Original Message----- From: Awais Ali [mailto:aali@i2telecom.com] Sent: Thursday, June 12, 2003 10:22 PM To: Oren Peleg; schulzrinne@cs.columbia.edu Cc: avt@ietf.org Subject: Re: [AVT] TimeStamp in the RFC2833 packet. The solution I am following right now is the one from = http://www.cs.columbia.edu/~hgs/rtp/ which says under "How is Jitter = Computed" =20 "If several packets, say, within a video frame, bear the same timestamp, = it is advisable to only use the first packet in a frame to compute the = jitter. (This issue may be addressed in a future version of the = specification.) ..." =20 I hope the future version of spec. mentioned here is coming soon, = because this aspect of timestamp issue is quite confusing in the current = one. =20 Regards =20 Ali Awais ----- Original Message -----=20 From: Oren Peleg=20 To: schulzrinne@cs.columbia.edu=20 Cc: avt@ietf.org=20 Sent: Wednesday, June 11, 2003 9:46 AM Subject: [AVT] TimeStamp in the RFC2833 packet. How does the RFC2833 TimeStamp values come along with the RTCP report = Jitter Calculation explained at the RFC1889? Thanks, Oren Peleg Work phone No. : 03 - 5394167 Home phone No. : 03 - 5335913 Cell phone No. : 055 - 669613 Email : Oren.Peleg@audiocodes.com ------_=_NextPart_001_01C3331C.335C4814 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable TimeStamp in the RFC2833 packet.
Thanks. It seems like a good idea. Probably = should be=20 added to the RTP-new draft.
 
Regards,
 
Oren=20 P.
-----Original Message-----
From: Awais Ali=20 [mailto:aali@i2telecom.com]
Sent: Thursday, June 12, 2003 = 10:22=20 PM
To: Oren Peleg; schulzrinne@cs.columbia.edu
Cc: = avt@ietf.org
Subject: Re: [AVT] TimeStamp in the RFC2833=20 packet.

The solution I am following right now = is the one=20 from http://www.cs.columbia.edu/= ~hgs/rtp/ which=20 says under "How is Jitter Computed"
 
"If several packets, say, within a = video frame,=20 bear the same timestamp, it is advisable to only use the first packet = in a=20 frame to compute the jitter. (This issue may be addressed in a future = version=20 of the specification.) ..."
 
I hope the future version of spec. = mentioned here=20 is coming soon, because this aspect of timestamp issue is quite = confusing in=20 the current one.
 
Regards
 
Ali = Awais
----- Original Message -----
From:=20 Oren=20 Peleg
To: schulzrinne@cs.columbia.edu =
Sent: Wednesday, June 11, = 2003 9:46=20 AM
Subject: [AVT] TimeStamp in = the RFC2833=20 packet.

How does the RFC2833 = TimeStamp values=20 come along with the RTCP report Jitter Calculation explained at the=20 RFC1889?

Thanks,

Oren=20 Peleg

Work phone No. : 03 - 5394167

Home phone No. : 03 - 5335913

Cell phone No. : 055 - 669613

Email :=20 Oren.Peleg@audiocodes.com

------_=_NextPart_001_01C3331C.335C4814-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Jun 15 12:57:06 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 MAA05664 for ; Sun, 15 Jun 2003 12:57:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FGudE10900 for avt-archive@odin.ietf.org; Sun, 15 Jun 2003 12:56: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 h5FDw1a00987; Sun, 15 Jun 2003 09:58:01 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5FDv6m00969 for ; Sun, 15 Jun 2003 09:57: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 JAA01672 for ; Sun, 15 Jun 2003 09:57:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RXy7-0003ip-00 for avt@ietf.org; Sun, 15 Jun 2003 09:54:51 -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 19RXy5-0003ik-00 for avt@ietf.org; Sun, 15 Jun 2003 09:54:50 -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 h5FDubpv038799; Sun, 15 Jun 2003 09:56:43 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Sun, 15 Jun 2003 09:56:37 -0400 From: Colin Perkins To: "Oren Peleg" Cc: aali@i2telecom.com, avt@ietf.org, schulzrinne@cs.columbia.edu Subject: Re: [AVT] TimeStamp in the RFC2833 packet. Message-Id: <20030615095637.26769f94.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-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 Section 6.4.4 of rtp-new discusses these issues. Colin --> "Oren Peleg" writes: > Thanks. It seems like a good idea. Probably should be added to the > RTP-new draft. > > Regards, > > Oren P. > > -----Original Message----- > From: Awais Ali [mailto:aali@i2telecom.com] > Sent: Thursday, June 12, 2003 10:22 PM > To: Oren Peleg; schulzrinne@cs.columbia.edu > Cc: avt@ietf.org > Subject: Re: [AVT] TimeStamp in the RFC2833 packet. > > > > > The solution I am following right now is the one from > http://www.cs.columbia.edu/~hgs/rtp/ which says under "How is Jitter > Computed" > > "If several packets, say, within a video frame, bear the same timestamp, > it is advisable to only use the first packet in a frame to compute the > jitter. (This issue may be addressed in a future version of the > specification.) ..." > > I hope the future version of spec. mentioned here is coming soon, because > this aspect of timestamp issue is quite confusing in the current one. > > Regards > > Ali Awais > > ----- Original Message ----- > From: Oren Peleg > To: schulzrinne@cs.columbia.edu > Cc: avt@ietf.org > Sent: Wednesday, June 11, 2003 9:46 AM > Subject: [AVT] TimeStamp in the RFC2833 packet. > > > How does the RFC2833 TimeStamp values come along with the RTCP report > Jitter Calculation explained at the RFC1889? > > Thanks, > > Oren Peleg > > Work phone No. : 03 - 5394167 > > Home phone No. : 03 - 5335913 > > Cell phone No. : 055 - 669613 > > Email : Oren.Peleg@audiocodes.com > > -- 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 Sun Jun 15 16:01:06 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 QAA09729 for ; Sun, 15 Jun 2003 16:01:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FK0bb21107 for avt-archive@odin.ietf.org; Sun, 15 Jun 2003 16:00: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 h5FE52a01228; Sun, 15 Jun 2003 10:05:02 -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 h5CHYUm09632 for ; Thu, 12 Jun 2003 13:34:30 -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 NAA20161 for ; Thu, 12 Jun 2003 13:34:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QVvx-0004a9-00 for avt@ietf.org; Thu, 12 Jun 2003 13:32:21 -0400 Received: from gremlin.ics.uci.edu ([128.195.1.70] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19QVvw-0004a5-00 for avt@ietf.org; Thu, 12 Jun 2003 13:32:20 -0400 Received: from localhost (claudius.ics.uci.edu [128.195.6.53]) by gremlin.ics.uci.edu (8.12.9/8.12.9) with ESMTP id h5CHTYtu017147; Thu, 12 Jun 2003 10:29:34 -0700 (PDT) Date: Thu, 12 Jun 2003 10:29:30 -0700 (PDT) From: ACM APIE Conference To: avt@ietf.org, tcpp-announce-admin@eece.unm.edu, end2end-interest@postel.org, Cost264@lip6.fr, rmt@lbl.gov, rm@openmash.org, mboned@network-services.uoregon.edu, tcgn@ieee.org, rm@openmash.org, itc@comsoc.org, tccc@cs.columbia.edu, nanog@merit.edu, news-announce-conferences@uunet.uu.net, amlist@takilab.k.dendai.ac.jp, cfp@mmlab.snu.ac.kr, conf@colmar.uha.fr, multicomm@research.panasonic.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-101.4, required 5, DOUBLE_CAPSWORD, FROM_ENDS_IN_NUMS, LINES_OF_YELLING, MAILTO_TO_SPAM_ADDR, MIME_EXCESSIVE_QP, USER_AGENT_PINE, USER_IN_WHITELIST) Subject: [AVT] REMINDER: DEADLINE * ACM Multimedia Computing & Networking 2004 (MMCN 2004) Call For Papers (June 23 Deadline) * 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: , ********************************************************************** * * * 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 -------------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Sun Jun 15 16:38: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 QAA10356 for ; Sun, 15 Jun 2003 16:38:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5FKcUt24046 for avt-archive@odin.ietf.org; Sun, 15 Jun 2003 16:38: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 h5FHV2a12670; Sun, 15 Jun 2003 13:31:02 -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 h5FHUFm12583 for ; Sun, 15 Jun 2003 13:30: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 NAA06149 for ; Sun, 15 Jun 2003 13:30:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RbIO-0004SH-00 for avt@ietf.org; Sun, 15 Jun 2003 13:28:00 -0400 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 19RbIO-0004S4-00 for avt@ietf.org; Sun, 15 Jun 2003 13:28:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Subject: RE: [AVT] TimeStamp in the RFC2833 packet. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 15 Jun 2003 20:30:00 +0300 Message-ID: Thread-Topic: [AVT] TimeStamp in the RFC2833 packet. Thread-Index: AcMzRgai892I5AiBTXOLrh5QeKHTAAAHHB2A From: "Oren Peleg" To: "Colin Perkins" Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h5FHUFm12584 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 read this section before, & I think that it should still be added. The RTCP Jitter value is used for Call Controls (e.g. MGCP) to know the quality of the call when finished. If for example, an RFC2833 ABCD Signaling packet will be transmitted every 5 seconds with the TimeStamp value of the beginning of the call, the Jitter calculation will be damaged significantly. Regards, Oren P. -----Original Message----- From: Colin Perkins [mailto:csp@csperkins.org] Sent: Sunday, June 15, 2003 4:57 PM To: Oren Peleg Cc: aali@i2telecom.com; avt@ietf.org; schulzrinne@cs.columbia.edu Subject: Re: [AVT] TimeStamp in the RFC2833 packet. Section 6.4.4 of rtp-new discusses these issues. Colin --> "Oren Peleg" writes: > Thanks. It seems like a good idea. Probably should be added to the > RTP-new draft. > > Regards, > > Oren P. > > -----Original Message----- > From: Awais Ali [mailto:aali@i2telecom.com] > Sent: Thursday, June 12, 2003 10:22 PM > To: Oren Peleg; schulzrinne@cs.columbia.edu > Cc: avt@ietf.org > Subject: Re: [AVT] TimeStamp in the RFC2833 packet. > > > > > The solution I am following right now is the one from > http://www.cs.columbia.edu/~hgs/rtp/ which says under "How is Jitter > Computed" > > "If several packets, say, within a video frame, bear the same timestamp, > it is advisable to only use the first packet in a frame to compute the > jitter. (This issue may be addressed in a future version of the > specification.) ..." > > I hope the future version of spec. mentioned here is coming soon, because > this aspect of timestamp issue is quite confusing in the current one. > > Regards > > Ali Awais > > ----- Original Message ----- > From: Oren Peleg > To: schulzrinne@cs.columbia.edu > Cc: avt@ietf.org > Sent: Wednesday, June 11, 2003 9:46 AM > Subject: [AVT] TimeStamp in the RFC2833 packet. > > > How does the RFC2833 TimeStamp values come along with the RTCP report > Jitter Calculation explained at the RFC1889? > > Thanks, > > Oren Peleg > > Work phone No. : 03 - 5394167 > > Home phone No. : 03 - 5335913 > > Cell phone No. : 055 - 669613 > > Email : Oren.Peleg@audiocodes.com > > -- 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 Sun Jun 15 21:26: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 VAA16201 for ; Sun, 15 Jun 2003 21:26:14 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5G1Pkm09219 for avt-archive@odin.ietf.org; Sun, 15 Jun 2003 21:25:46 -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 h5FMg2a32365; Sun, 15 Jun 2003 18:42:02 -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 h5FMf5m32338 for ; Sun, 15 Jun 2003 18:41:05 -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 SAA13670 for ; Sun, 15 Jun 2003 18:41:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rg9B-0005jo-00 for avt@ietf.org; Sun, 15 Jun 2003 18:38:49 -0400 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19Rg9A-0005jk-00 for avt@ietf.org; Sun, 15 Jun 2003 18:38:48 -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 h5FMeLKn009931; Sun, 15 Jun 2003 15:40:21 -0700 (PDT) (envelope-from casner@acm.org) Date: Sun, 15 Jun 2003 15:40:50 -0700 (PDT) From: Stephen Casner To: AVT WG cc: Colin Perkins , Magnus Westerlund , Allison Mankin Message-ID: <20030615153538.D61369-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] AVT will meet in Vienna; new co-chair 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: , Two important announcements: 1. AVT will meet in Vienna. Given the smaller-than-usual number of topics to discuss, we plan to meet for just one session. We don't know yet what day and time that session will be. Anyone who would like a time slot and has not yet made a request should do so promptly. 2. I will step down as co-chair of AVT after the Vienna meeting. Colin Perkins will continue and Magnus Westerlund has accepted our invitation to join now as a new co-chair. The Transport Area Directors have approved adding Magnus. I began as chair of AVT when it was formed at the Santa Fe IETF in November, 1991 (the first regular meeting was March, 1992). Colin joined as co-chair in August, 1998. The reason for my transition at this time is that my real job is no longer related to AVT work, nor is it academia/research. I have not been able to put as much energy into AVT work as it deserves, and that slows down progress. Meanwhile, Magnus has demonstrated his commitment to AVT work by carefully reviewing and commenting on many of the drafts, as well as authoring some of this own. In my opinion, Magnus has shown a good sense of direction in AVT-related protocol design and a strong motivation to get IETF work done and done right. I am confident that Colin and Magnus can provide the leadership needed for AVT to continue its work. See you in Wien! -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jun 16 00:38: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 AAA18914 for ; Mon, 16 Jun 2003 00:37:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5G4bVv20683 for avt-archive@odin.ietf.org; Mon, 16 Jun 2003 00:37: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 h5G0a1a05975; Sun, 15 Jun 2003 20:36: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 h5G0ZNm05950 for ; Sun, 15 Jun 2003 20:35:23 -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 UAA15338 for ; Sun, 15 Jun 2003 20:35:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Rhvo-0006Cq-00 for avt@ietf.org; Sun, 15 Jun 2003 20:33:08 -0400 Received: from www.routeexplorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19Rhvn-0006Cm-00 for avt@ietf.org; Sun, 15 Jun 2003 20:33:07 -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 h5G0YiKn011432; Sun, 15 Jun 2003 17:34:45 -0700 (PDT) (envelope-from casner@acm.org) Date: Sun, 15 Jun 2003 17:35:13 -0700 (PDT) From: Stephen Casner To: Magnus Westerlund , Jose Rey cc: IETF AVT WG Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt In-Reply-To: <3EDE267B.7010907@ericsson.com> Message-ID: <20030613075546.S60710-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 Wed, 4 Jun 2003, Magnus Westerlund wrote: > I have been think over this problem some more. I have one problem with > the proposed algorithm. The proposed algorithm seems to be the correct > one when one comes to conversational, confernce or multicast > applications where there is a potential large number of receivers and > senders needs to be prioritized to provide synchronization data. So far I agree. > However I have been thinking on the case of on-demand streaming. In this > case one has normally a single sender and one receiver. In this case it > is no question that the sender will get the complete RS pool. However in > this case on is actually interested in giving the receiver the complete > RR pool. The sender will suffice with the given RS pool as this can > easily be calculated and the SR information is less important for > synchronization. The receiver instead has a lot of interesting to report > and creates large packets that it want to send often. Therefore a larger > RR bandwidth is motivated. I don't see why the synchronization information is any less important in this case than for the earlier ones. > In the above case on would like to send receiver reports utilizing the > full RR pot for the receiver. One might also want to assign more > bandwidth to RR then to RS. What happens in this case, as can be seen > below, is that the receiver actually gets less. > > For RS > RR: > Receiver RTCP bandwidth = RR/1 > Senders bandwidth = RS/1 > > For RS < RR > Receivers RTCP bandwidth = RR/2 > Senders bandwidth = (RS + RR)/2 While this arithmetic is correct, I'm not sure it matters. There are two considerations you have not included in your analysis: 1. The reporting interval is determined by dividing the average packet size by the calculated bandwidth. Since the average packet size is calculated using all the RTCP packets from both senders and receivers, then receivers will be getting a larger share of the bandwidth because their RTCP packets are larger. 2. For narrow channels, the 5 second minimum will constrain the interval calculation more than the default 5% (or 3.75%) RTCP bw, so unless the application needs to severely constrain the bw to make the interval even longer, it won't make a difference. > This get even worse if one would use SSRC multiplex RTP retransmission. > In this case one gets two senders and one receivers as long as > retransmission occurs more than every two RTCP reporting intervals. > > For RS/2 > RR: > Receiver RTCP bandwidth = RR/1 > Senders bandwidth = RS/2 > > For RS/2 < RR: > Receiver RTCP bandwidth = RR/3 > Senders bandwidth = (RS+RR)/3 If RTP retransmission is used, I would assume that AVPF is also being used, and therefore the interval calculation is modified. Given the variability in both data bw and RTCP bw depending upon the error rate, there has got to be significant headroom between the base data rate and the channel capacity, so precisely controlling the RTCP bw should not be an issue. On Fri, 6 Jun 2003, Jose Rey wrote: > in my understanding the problem is the following: RTCP BW modifiers > don't work for RTP unicast with the algorithm in RTP draft annex > A.7. And since unicast is a very important application which will be > using these modifiers (at least 3GPP will be using them), it is > necessary to do something about this. Unicast is not the right characterization. For conversational unicast, which has symmetric requirements, there should be no problem. Unicast streaming, where the data transmission is unidirectional, is where the questions arise. Furthermore, it is the inclusion of only two participants, not the use of unicast transmission, that might make this case different. Note that there can be RTP sessions with more than two participants using unicast through an RTP mixer. > An added side problem is that you cannot turn the receivers' RTCP > off, because (as explained below) all session participants are > treated equal. > Now in detail, applying the algorithm in RTP-draft section A.7 for > unicast, the end result is that senders AND receivers equally share > the bandwidth, each getting a value equal to (RR+RS)/members, > because the if-clause is always false. Assuming a modification to use RS/(RS+RR) as the RTCP_SENDER_BW_FRACTION rather than a fixed .25, then the algorithm in A.7 gives non-data-senders zero RTCP bw when RR is zero because the number of senders is less than the number of members. Part of my proposal was to remove the "senders > 0" term so that there isn't a problem when there are no senders. > This gets even worse if RTP retransmission is used (where different > SSRCs might be used to multiplex media and retransmissions) as the > bandwidth that one wants to dedicate to the receiver is actually > shared equally between an increased number of SSRCs. Yes, although not really equally because of the difference in packet sizes. But given the considerations I have outlined above, is it a problem that we need to address? > If changing the algorithm is too much of a change at this stage AND > this shall not be solved by draft-ietf-avt-rtcp-bw-05.txt, then the > only solution I see is to tell RTCP through SDP who uses which > bandwidth values, but this needs also of another rtcp_interval() > algorithm that accepts these values as parameters (as Magnus > proposed in his code). Makes this sense to all? > > Would another draft be the rigth place for this other algorithm? > Would that constitute a new profile? A new profile could change the algorithm if that is necessary. New SDP parameters could be defined if that was necessary. I suggest that you guys run some numbers to see if it is a problem. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jun 16 05:40: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 FAA06409 for ; Mon, 16 Jun 2003 05:40:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5G9eH719931 for avt-archive@odin.ietf.org; Mon, 16 Jun 2003 05: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 h5G6m2a07992; Mon, 16 Jun 2003 02:48:02 -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 h5G6l0m07938 for ; Mon, 16 Jun 2003 02: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 CAA03683 for ; Mon, 16 Jun 2003 02:46:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RnjP-0000Fv-00 for avt@ietf.org; Mon, 16 Jun 2003 02:44:43 -0400 Received: from www.routeexplorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19RnjO-0000Fk-00 for avt@ietf.org; Mon, 16 Jun 2003 02:44:43 -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 h5G6kLKn017838; Sun, 15 Jun 2003 23:46:21 -0700 (PDT) (envelope-from casner@acm.org) Date: Sun, 15 Jun 2003 23:46:56 -0700 (PDT) From: Stephen Casner To: Magnus Westerlund , Jose Rey cc: IETF AVT WG Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt In-Reply-To: <20030613075546.S60710-100000@oak.packetdesign.com> Message-ID: <20030615233831.P61774-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: , Some more thoughts on this: To simplify the unicast streaming application, we could specify that when RTCP bw is specified with RS and RR those values are used separately for senders and non-senders without any consideration of treating senders and receivers together when the number of senders is greater than RS/(RS+RR). However, that would not be good for conversational applications (unicast or multicast) because the classification as sender changes over time. At times when both ends have sent within two intervals, they would be using the RS bw only and ignoring the RR bw. To get around this we could set RS to be the total, and RR zero, but then if one was sending and the other just listening for a long time, the listener would get nothing. For these applications, you need the smooth transision that the existing algorithm was intended to provide. -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Mon Jun 16 12:53:22 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 MAA20733 for ; Mon, 16 Jun 2003 12:53:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GGqt117976 for avt-archive@odin.ietf.org; Mon, 16 Jun 2003 12:52: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 h5GBX2a26453; Mon, 16 Jun 2003 07:33:02 -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 h5GBWtm26442 for ; Mon, 16 Jun 2003 07:32: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 HAA08396 for ; Mon, 16 Jun 2003 07:32:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19RsC7-0001Pp-00 for avt@ietf.org; Mon, 16 Jun 2003 07:30:39 -0400 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 19RsC6-0001Pm-00 for avt@ietf.org; Mon, 16 Jun 2003 07:30:38 -0400 thread-index: AcMz+ud4Ao0fmbOeQ1OgH4tdX/0aLw== Received: from atrgreyj ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.5329); Mon, 16 Jun 2003 13:32:01 +0200 From: "Jose Rey" To: "Stephen Casner" , "Magnus Westerlund" Cc: "IETF AVT WG" Content-Class: urn:content-classes:message Subject: RE: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt Priority: normal Date: Mon, 16 Jun 2003 13:32:00 +0200 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) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20030615233831.P61774-100000@oak.packetdesign.com> X-OriginalArrivalTime: 16 Jun 2003 11:32:01.0465 (UTC) FILETIME=[E7768290:01C333FA] 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, > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Stephen > Casner > Sent: Monday, June 16, 2003 8:47 AM > To: Magnus Westerlund; Jose Rey > Cc: IETF AVT WG > Subject: Re: [AVT] Re: Errors in draft-ietf-avt-rtcp-bw-05.txt > > > Some more thoughts on this: > > To simplify the unicast streaming application, we could specify that > when RTCP bw is specified with RS and RR those values are used > separately for senders and non-senders without any consideration of > treating senders and receivers together when the number of senders is > greater than RS/(RS+RR). I think this is the best and easiest solution. In 3GPP unicast streaming it is the server that sets the RS and RR values, that means the server should consider well how much bandwidth it is needed for own reporting and for the sender's. There's no case where the algorithm must adapt, the scenario is rather static. > > However, that would not be good for conversational applications > (unicast or multicast) because the classification as sender changes > over time. At times when both ends have sent within two intervals, > they would be using the RS bw only and ignoring the RR bw. To get > around this we could set RS to be the total, and RR zero, but then if > one was sending and the other just listening for a long time, the > listener would get nothing. For these applications, you need the > smooth transision that the existing algorithm was intended to > provide. > I see. I was referring more to the streaming unicast scenario. I guess my characterization was not accure enough. cheers, Jose > -- 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 From mailnull@www1.ietf.org Mon Jun 16 19:28:22 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 TAA08428 for ; Mon, 16 Jun 2003 19:28:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5GNRtZ14573 for avt-archive@odin.ietf.org; Mon, 16 Jun 2003 19:27: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 h5GKV3a01110; Mon, 16 Jun 2003 16:31:03 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5GKV1m01043 for ; Mon, 16 Jun 2003 16:31:01 -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 QAA00919 for ; Mon, 16 Jun 2003 16:30:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S0aq-0006Pa-00 for avt@ietf.org; Mon, 16 Jun 2003 16:28:44 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19S0ap-0006PU-00 for avt@ietf.org; Mon, 16 Jun 2003 16:28:43 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h5GKRvk09275 for avt@ietf.org; Mon, 16 Jun 2003 13:27:57 -0700 Date: Mon, 16 Jun 2003 13:27:57 -0700 From: John Lazzaro Message-Id: <200306162027.h5GKRvk09275@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: Re: [AVT] AVT will meet in Vienna; new co-chair 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: , > Stephen Casner writes: > > 2. I will step down as co-chair of AVT after the Vienna meeting. > Colin Perkins will continue and Magnus Westerlund has accepted our > invitation to join now as a new co-chair. The Transport Area > Directors have approved adding Magnus. We've all been incredibly lucky to have Steve at the co-helm of the ship ... and we're also incredibly lucky to have Magnus step up to share the wheel with Colin going forward. ------------------------------------------------------------------------- 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 Mon Jun 16 21:12: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 VAA11474 for ; Mon, 16 Jun 2003 21:12:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H1BbO22272 for avt-archive@odin.ietf.org; Mon, 16 Jun 2003 21:11: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 h5GNk3a16096; Mon, 16 Jun 2003 19:46:03 -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 h5GNjjm16081 for ; Mon, 16 Jun 2003 19:45: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 TAA08873 for ; Mon, 16 Jun 2003 19:45:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S3dJ-0000Or-00 for avt@ietf.org; Mon, 16 Jun 2003 19:43:29 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19S3dI-0000Oo-00 for avt@ietf.org; Mon, 16 Jun 2003 19:43:28 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h5GNggB09869; Mon, 16 Jun 2003 16:42:42 -0700 Date: Mon, 16 Jun 2003 16:42:42 -0700 From: John Lazzaro Message-Id: <200306162342.h5GNggB09869@snap.CS.Berkeley.EDU> To: L.Wood@eim.surrey.ac.uk Subject: Re: [AVT] AVT will meet in Vienna; new co-chair 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: , > You don't sail, do you? No, but I went to see Finding Nemo a few days ago, and my brain is still in maritime mode :-). ------------------------------------------------------------------------- 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 Mon Jun 16 21:54: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 VAA12412 for ; Mon, 16 Jun 2003 21:54:57 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5H1sUb24784 for avt-archive@odin.ietf.org; Mon, 16 Jun 2003 21:54: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 h5GNh2a16026; Mon, 16 Jun 2003 19:43:02 -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 h5GNgUm16002 for ; Mon, 16 Jun 2003 19:42:30 -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 TAA08836 for ; Mon, 16 Jun 2003 19:42:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19S3aA-0000OK-00 for avt@ietf.org; Mon, 16 Jun 2003 19:40:14 -0400 Received: from [131.227.76.5] (helo=prue.eim.surrey.ac.uk ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19S3a9-0000OH-00 for avt@ietf.org; Mon, 16 Jun 2003 19:40:13 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19S3c6-0003XH-00; Tue, 17 Jun 2003 00:42:14 +0100 Date: Tue, 17 Jun 2003 00:42:12 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: John Lazzaro cc: avt@ietf.org Subject: Re: [AVT] AVT will meet in Vienna; new co-chair In-Reply-To: <200306162027.h5GKRvk09275@snap.CS.Berkeley.EDU> Message-ID: References: <200306162027.h5GKRvk09275@snap.CS.Berkeley.EDU> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.1 required=5.5 tests=AWL,BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19S3c6-0003XH-00*6bT4biY9IMs* (SECM, UniS) 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 Mon, 16 Jun 2003, John Lazzaro wrote: > > Stephen Casner writes: > > > > 2. I will step down as co-chair of AVT after the Vienna meeting. > > Colin Perkins will continue and Magnus Westerlund has accepted our > > invitation to join now as a new co-chair. The Transport Area > > Directors have approved adding Magnus. > > We've all been incredibly lucky to have Steve at the co-helm of the > ship ... and we're also incredibly lucky to have Magnus step up to > share the wheel with Colin going forward. You don't sail, do you? L. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From mailnull@www1.ietf.org Tue Jun 17 14:32: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 OAA01610 for ; Tue, 17 Jun 2003 14:32:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HIVcT17192 for avt-archive@odin.ietf.org; Tue, 17 Jun 2003 14:31: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 h5HA42a12677; Tue, 17 Jun 2003 06:04:02 -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 h5HA3Rm12654 for ; Tue, 17 Jun 2003 06:03: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 GAA05380 for ; Tue, 17 Jun 2003 06:03:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SDH3-0004WL-00 for avt@ietf.org; Tue, 17 Jun 2003 06:01:09 -0400 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 19SDGv-0004WC-00 for avt@ietf.org; Tue, 17 Jun 2003 06:01:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C334B7.A278F944" Date: Tue, 17 Jun 2003 13:03:00 +0300 Message-ID: Thread-Topic: Q about draft-ietf-avt-rtp-new-12 Thread-Index: AcM0t6PBx11hoJvyEdeSdQDQt7+w2w== From: "Oren Peleg" To: , "Stephen Casner" Cc: Subject: [AVT] Q about draft-ietf-avt-rtp-new-12 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_001_01C334B7.A278F944 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable In the draft-ietf-avt-rtp-new-12 it is mentioned that the RTCP packet = MUST end on a 32-bit boundary. At the RTCP Padding section, it is = mentioned that the padding is done octet based - length value is at the = last padding octet:=20 "If the padding bit is set, this individual RTCP packet contains some additional padding octets at the end which are not part of the control information but are included in the length field. The last octet of the padding is a count of how many padding octets should be ignored, including itself (it will be a multiple of four)." As I understand it, the Padding MUST be 32-bit aligned. Is my assumption = correct? if it is, shouldn't it be mentioned at the Padding part? If = this will be misunderstood, it could cause reading of a garbage octet as = the padding length ... Regards,=20 Oren Peleg Work phone No. : 03 - 5394167 Home phone No. : 03 - 5335913 Cell phone No. : 055 - 669613 Email : Oren.Peleg@audiocodes.com ------_=_NextPart_001_01C334B7.A278F944 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Q about draft-ietf-avt-rtp-new-12

In the = draft-ietf-avt-rtp-new-12 it is mentioned that the RTCP packet MUST end = on a 32-bit boundary. At the RTCP Padding section, = it is mentioned that the padding is done octet based - length value is = at  the last padding octet:

"If = the padding bit is set, this individual RTCP packet

         &nbs= p;   contains some additional padding octets at the end = which

         &nbs= p;   are not part of the control information but are included = in

         &nbs= p;   the length field.  The last octet of the padding is = a count

         &nbs= p;   of how many padding octets should be ignored, = including

         &nbs= p;   itself (it will be a multiple of = four)."

As I = understand it, the Padding MUST be 32-bit aligned. Is my assumption = correct? if it is, shouldn't it be mentioned at the Padding part? If = this will be misunderstood, it could cause reading of a garbage octet as = the padding length ...

Regards,

Oren Peleg

Work phone No. : 03 - 5394167

Home phone No. : 03 - 5335913

Cell phone No. : 055 - 669613

Email : Oren.Peleg@audiocodes.com

------_=_NextPart_001_01C334B7.A278F944-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jun 17 15:10: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 PAA04546 for ; Tue, 17 Jun 2003 15:10:53 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJAQ632631 for avt-archive@odin.ietf.org; Tue, 17 Jun 2003 15:10:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SKzy-0003Om-1w; Tue, 17 Jun 2003 14:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus with esmtp (Exim 4.20) id 19SJaw-0003WL-Nk for avt@optimus.ietf.org; Tue, 17 Jun 2003 12:46: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 MAA26005 for ; Tue, 17 Jun 2003 12:46:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SJYi-0001gM-00 for avt@ietf.org; Tue, 17 Jun 2003 12:43:48 -0400 Received: from www.routeexplorer.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 19SJYh-0001gC-00 for avt@ietf.org; Tue, 17 Jun 2003 12:43:47 -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 h5HGitKn070725; Tue, 17 Jun 2003 09:44:56 -0700 (PDT) (envelope-from casner@acm.org) Date: Tue, 17 Jun 2003 09:45:48 -0700 (PDT) From: Stephen Casner To: Oren Peleg cc: schulzrinne@cs.columbia.edu, In-Reply-To: Message-ID: <20030617094154.Q62101-100000@oak.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [AVT] Re: Q about draft-ietf-avt-rtp-new-12 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 Tue, 17 Jun 2003, Oren Peleg wrote: > In the draft-ietf-avt-rtp-new-12 it is mentioned that the RTCP > packet MUST end on a 32-bit boundary. At the RTCP Padding section, > it is mentioned that the padding is done octet based - length value > is at the last padding octet: > > "If the padding bit is set, this individual RTCP packet > contains some additional padding octets at the end which > are not part of the control information but are included in > the length field. The last octet of the padding is a count > of how many padding octets should be ignored, including > itself (it will be a multiple of four)." > > As I understand it, the Padding MUST be 32-bit aligned. Is my > assumption correct? if it is, shouldn't it be mentioned at the > Padding part? If this will be misunderstood, it could cause reading > of a garbage octet as the padding length ... This text seems clear to me. The padding must fit within the length field, which is in units of 32-bit words; it is appended to the contents of an RTCP packet, which must end on a 32-bit boundary for all packet types; and the padding count is a multiple of four. What construction did you envision that complies with those requirements and is not 32-bit aligned? -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jun 17 15:12:01 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 PAA04720 for ; Tue, 17 Jun 2003 15:12:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5HJBYc02206 for avt-archive@odin.ietf.org; Tue, 17 Jun 2003 15:11:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SL02-0003Rs-Oo; Tue, 17 Jun 2003 14:16:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus with esmtp (Exim 4.20) id 19SK24-0004Gw-Iv for avt@optimus.ietf.org; Tue, 17 Jun 2003 13:14: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 NAA26794 for ; Tue, 17 Jun 2003 13:14:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SJzp-0001sK-00 for avt@ietf.org; Tue, 17 Jun 2003 13:11:49 -0400 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 19SJzo-0001rb-00 for avt@ietf.org; Tue, 17 Jun 2003 13:11:49 -0400 content-class: urn:content-classes:message Date: Tue, 17 Jun 2003 20:13:49 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: Q about draft-ietf-avt-rtp-new-12 Thread-Index: AcM079/4FU6ae4VXTKmt0SjqJ47/AgAAnCuw From: "Oren Peleg" To: "Stephen Casner" Cc: , Subject: [AVT] RE: Q about draft-ietf-avt-rtp-new-12 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 X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA04720 It is mentioned that it is "included in the length field". This could be interpreted as if padding exists only for 1 octet - still the Length will be increased by one - rounded to 32bit size. It could be that Im just blowing some wind, but it did cause my suspicious level to rise. Thanks for clearing it up to me, Oren P. -----Original Message----- From: Stephen Casner [mailto:casner@acm.org] Sent: Tuesday, June 17, 2003 7:46 PM To: Oren Peleg Cc: schulzrinne@cs.columbia.edu; avt@ietf.org Subject: Re: Q about draft-ietf-avt-rtp-new-12 On Tue, 17 Jun 2003, Oren Peleg wrote: > In the draft-ietf-avt-rtp-new-12 it is mentioned that the RTCP > packet MUST end on a 32-bit boundary. At the RTCP Padding section, > it is mentioned that the padding is done octet based - length value > is at the last padding octet: > > "If the padding bit is set, this individual RTCP packet > contains some additional padding octets at the end which > are not part of the control information but are included in > the length field. The last octet of the padding is a count > of how many padding octets should be ignored, including > itself (it will be a multiple of four)." > > As I understand it, the Padding MUST be 32-bit aligned. Is my > assumption correct? if it is, shouldn't it be mentioned at the > Padding part? If this will be misunderstood, it could cause reading > of a garbage octet as the padding length ... This text seems clear to me. The padding must fit within the length field, which is in units of 32-bit words; it is appended to the contents of an RTCP packet, which must end on a 32-bit boundary for all packet types; and the padding count is a multiple of four. What construction did you envision that complies with those requirements and is not 32-bit aligned? -- Steve _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jun 17 22:27: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 WAA19607 for ; Tue, 17 Jun 2003 22:27:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5I2R5U07819 for avt-archive@odin.ietf.org; Tue, 17 Jun 2003 22:27:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SSf7-00021P-Do; Tue, 17 Jun 2003 22:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SO6A-0003L6-T7 for avt@optimus.ietf.org; Tue, 17 Jun 2003 17:34: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 RAA12468 for ; Tue, 17 Jun 2003 17:34:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SO3v-0005Mg-00 for avt@ietf.org; Tue, 17 Jun 2003 17:32:19 -0400 Received: from gremlin.ics.uci.edu ([128.195.1.70] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19SO3u-0005Mc-00 for avt@ietf.org; Tue, 17 Jun 2003 17:32:18 -0400 Received: from godzilla.ics.uci.edu (godzilla.ics.uci.edu [128.195.1.58]) by gremlin.ics.uci.edu (8.12.9/8.12.9) with ESMTP id h5HLV24Y005784; Tue, 17 Jun 2003 14:31:02 -0700 (PDT) Date: Tue, 17 Jun 2003 14:31:01 -0700 (PDT) From: MMCN-2004 To: Nalini Venkatasubramanian cc: Shivajit Mohapatra , vernick@avaya.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-101.5, required 5, DOUBLE_CAPSWORD, FROM_ENDS_IN_NUMS, FROM_NAME_NO_SPACES, LINES_OF_YELLING, MAILTO_TO_SPAM_ADDR, MIME_EXCESSIVE_QP, USER_AGENT_PINE, USER_IN_WHITELIST) Subject: [AVT] REMINDER: paper submission deadline EXTENDED FOR MMCN-2004 (new deadline July 5, 2003) * ACM Multimedia Computing & 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: , Hi all, Please note that the final paper submission deadline for ACM Multimedia Computing & Networking (MMCN 2004) has now been extended to July 5, 2003. ********************************************************************** * * * 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 July 5, 2003, 11:59 PM Pacific Standard Time (PST).For paper submissions please check the MMCN 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 networks * 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 Applications * multimedia search engines * entertainment and games * reflective applications Multimedia Middleware * proxy services * transcoding * multimedia data management * security and multimedia Case Studies * synthetic animation * distributed virtual reality * multimedia DBs and 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 electronically (in plain text format) a cover page 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 : July 5, 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 Raj 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 Abdelzaher, University of Virginia Kevin Almeroth, University of California, Santa Barbara Riccardo Bettati, Texas A&M University Nina Bhatti, HP Labs Sajal Das, University of Texas, Arlington Magda El Zarki, University of California, Irvine Carsten Griwodz, University of Oslo Martin Kienzle, IBM Research Ketan Mayer-Patel, University of North Carolina, Chapel Hill Klara Nahrstedt, University of Illinois, Urbana-Champaign Douglas C. Schmidt, DARPA/Vanderbilt University Prashant Shenoy, University of Massachusetts, Amherst Cormac Sreenan, University College Cork Michael Zink, Technical University of Darmstadt Dongyan Xu, Purdue University Roger Zimmerman, University of Southern California Scott Brandt, University of California, Santa Cruz Hong Jiang Zhang, Microsoft Research Reza Rejaie, University of Oregon Wei-Ying Ma, Microsoft Research, China -------------------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jun 18 15:53: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 PAA25917 for ; Wed, 18 Jun 2003 15:53:07 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IJqdk11232 for avt-archive@odin.ietf.org; Wed, 18 Jun 2003 15:52:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sikr-0002Nx-9C; Wed, 18 Jun 2003 15:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SifS-0001uZ-8V for avt@optimus.ietf.org; Wed, 18 Jun 2003 15:32: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 PAA24795 for ; Wed, 18 Jun 2003 15:32:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SidB-0000qF-00 for avt@ietf.org; Wed, 18 Jun 2003 15:30:05 -0400 Received: from marionberry.cc.columbia.edu ([128.59.59.100] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19SidA-0000pD-00 for avt@ietf.org; Wed, 18 Jun 2003 15:30:04 -0400 Received: from cs.columbia.edu (dhcp39.cs.columbia.edu [128.59.19.239]) (user=hgs10 mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h5IJVmxH018250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Jun 2003 15:31:49 -0400 (EDT) Message-ID: <3EF0BE2B.4000709@cs.columbia.edu> Date: Wed, 18 Jun 2003 15:31:55 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rhodes, Ann" CC: avt@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Questions about draft-ietf-avt-rfc2833bis-02 and sub-events 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 Rhodes, Ann wrote: > These questions are based on the draft-ietf-avt-rfc2833bis-02 > document, specifically in the area of sub-events for DTMF digits > lasting longer than 8.192 seconds. > > 1. First, this draft of the specification indicates it "expires" in > April, 2003. Does that mean that this draft is now the accepted > standard since the comment period has expired? I plan to issue a new draft shortly, but have been waylaid with other items. > > 2. Second, it would be helpful to have an example of what durations, > packet intervals and timestamps look like at the rollover points > where sub-events are created. For example, suppose the Named Event > began at timestamp 0, has duration 72,000 (9 seconds), and RFC2833 > packets are sent out at 50msec intervals. Assume that associated > audio packets are muted during the event. Is this sequence of packets > correct? Please see if the new edition will help. > > Relative Sequence Time Time (ms) Number Stamp > Duration Comment > ---------------------------------------------------------- 0 > X 0 400 this is the first packet of the > event 50 X+1 0 800 this is the > second packet of the event ..... > 8.xxx seconds pass with packets sent 8100 X+162 0 > 65200 last packet before rollover/subevent 8141.875 X+163 > 0 65535 last packet of event with duration FFFF note > that it comes at non-periodic interval 8150 X+164 65535 > 65 this is the first packet of the subevent 8200 X+165 > 65535 465 now the sequence continues from here... > ..... > > What if, because of DSP sampling intervals, it is impossible for the > transmitting gateway to send packet X+163 at the rollover instant? > What should the transmitting gateway do to minimize jitter perceived > at the receiving gateway? > > If this example is incorrect, what is the appropriate sequence? > > > Regards, > > Ann Rhodes _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jun 18 16:42: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 QAA28906 for ; Wed, 18 Jun 2003 16:42:25 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IKfvs19428 for avt-archive@odin.ietf.org; Wed, 18 Jun 2003 16:41:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SjVJ-0004IH-Jk; Wed, 18 Jun 2003 16:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SjNp-0003tf-Lc for avt@optimus.ietf.org; Wed, 18 Jun 2003 16:18:17 -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 QAA27485 for ; Wed, 18 Jun 2003 16:18:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SjLZ-0001Z3-00 for avt@ietf.org; Wed, 18 Jun 2003 16:15:57 -0400 Received: from wireless210.east.isi.edu ([65.123.202.210] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19SjLY-0001Yz-00 for avt@ietf.org; Wed, 18 Jun 2003 16:15:56 -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 h5IKICru004355; Wed, 18 Jun 2003 16:18:12 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Wed, 18 Jun 2003 16:18:12 -0400 From: Colin Perkins To: avt@ietf.org Cc: casner@acm.org, magnus.westerlund@ericsson.com Message-Id: <20030618161812.026ce541.csp@csperkins.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , Content-Transfer-Encoding: 7bit Folks, The AVT working group is scheduled for one slot at the 57th IETF meeting in Vienna. On the tentative agenda, this is from 9:00 to 11:30 on Monday 14th July. This date is subject to change - DO NOT USE IT TO PLAN TRAVEL. Those wanting agenda time at the meeting should contact the working group chairs by 1st July. Submitting a draft does not automatically provide agenda time. You are reminded that the cut-off date for -00 Internet Draft submissions is Monday, 23rd June at 9:00am EDT (GMT -04:00). Unless you have prior approval from the chairs, -00 submissions should have filenames with the format draft-yourname-avt-...-00.txt. Be advised that updates to -00 drafts received after 23rd June will not be accepted. All other Internet-Draft submissions must be made by Monday, 30th June at 9:00am EDT. Drafts which are submitted late and do not make the cutoff date will not be discussed at the meeting. -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Wed Jun 18 16:57: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 QAA29451 for ; Wed, 18 Jun 2003 16:57:49 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IKvMZ22137 for avt-archive@odin.ietf.org; Wed, 18 Jun 2003 16:57:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Sjpd-0005IC-6h; Wed, 18 Jun 2003 16:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SiIO-00017u-Ld for avt@optimus.ietf.org; Wed, 18 Jun 2003 15:08: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 PAA22861 for ; Wed, 18 Jun 2003 15:08:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SiG6-0000Tn-00 for avt@ietf.org; Wed, 18 Jun 2003 15:06:14 -0400 Received: from fmr01.intel.com ([192.55.52.18] helo=hermes.fm.intel.com) by ietf-mx with esmtp (Exim 4.12) id 19SiG5-0000Ti-00 for avt@ietf.org; Wed, 18 Jun 2003 15:06:13 -0400 Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h5IJ3oX13055 for ; Wed, 18 Jun 2003 19:03:50 GMT Received: from fmsmsxv040-1.fm.intel.com (fmsmsxv040-1.fm.intel.com [132.233.48.108]) by talaria.fm.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h5IJ92404633 for ; Wed, 18 Jun 2003 19:09:02 GMT Received: from azsmsx331-2.ch.intel.com ([10.2.161.41]) by fmsmsxv040-1.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2003061812080404787 ; Wed, 18 Jun 2003 12:08:04 -0700 Received: from cssmsx401.amr.corp.intel.com ([10.15.24.6]) by azsmsx331-2.ch.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 18 Jun 2003 12:08:26 -0700 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: Wed, 18 Jun 2003 13:01:30 -0600 Message-ID: Thread-Topic: Question about RFC 2833 Thread-Index: AcLh+1fIFTID/37HSDCJkyyxtErFLxTwpQ/Q From: "Rhodes, Ann" To: Cc: "Henning Schulzrinne" X-OriginalArrivalTime: 18 Jun 2003 19:08:26.0696 (UTC) FILETIME=[FF28A480:01C335CC] Subject: [AVT] Questions about draft-ietf-avt-rfc2833bis-02 and sub-events 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 X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA29451 These questions are based on the draft-ietf-avt-rfc2833bis-02 document, specifically in the area of sub-events for DTMF digits lasting longer than 8.192 seconds. 1. First, this draft of the specification indicates it "expires" in April, 2003. Does that mean that this draft is now the accepted standard since the comment period has expired? 2. Second, it would be helpful to have an example of what durations, packet intervals and timestamps look like at the rollover points where sub-events are created. For example, suppose the Named Event began at timestamp 0, has duration 72,000 (9 seconds), and RFC2833 packets are sent out at 50msec intervals. Assume that associated audio packets are muted during the event. Is this sequence of packets correct? Relative Sequence Time Time (ms) Number Stamp Duration Comment ---------------------------------------------------------- 0 X 0 400 this is the first packet of the event 50 X+1 0 800 this is the second packet of the event ..... 8.xxx seconds pass with packets sent 8100 X+162 0 65200 last packet before rollover/subevent 8141.875 X+163 0 65535 last packet of event with duration FFFF note that it comes at non-periodic interval 8150 X+164 65535 65 this is the first packet of the subevent 8200 X+165 65535 465 now the sequence continues from here... ..... What if, because of DSP sampling intervals, it is impossible for the transmitting gateway to send packet X+163 at the rollover instant? What should the transmitting gateway do to minimize jitter perceived at the receiving gateway? If this example is incorrect, what is the appropriate sequence? Regards, Ann Rhodes _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jun 19 08:36: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 IAA13796 for ; Thu, 19 Jun 2003 08:36:26 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JCZwJ19706 for avt-archive@odin.ietf.org; Thu, 19 Jun 2003 08:35:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxzN-0002wK-4K; Thu, 19 Jun 2003 07:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SxeK-0001mX-ML for avt@optimus.ietf.org; Thu, 19 Jun 2003 07:32:16 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09515; Thu, 19 Jun 2003 07:32:15 -0400 (EDT) Message-Id: <200306191132.HAA09515@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, 19 Jun 2003 07:32:15 -0400 Subject: [AVT] I-D ACTION:draft-chen-rtp-bv-00.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. Title : RTP Payload Format for BroadVoice Speech Codecs Author(s) : J. Chen et al. Filename : draft-chen-rtp-bv-00.txt Pages : 12 Date : 2003-6-18 This document describes the RTP payload format for the BroadVoice(TM) narrowband and wideband speech codecs developed by Broadcom Corporation. The document also provides specifications for the use of BroadVoice with MIME and SDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-rtp-bv-00.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-chen-rtp-bv-00.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-chen-rtp-bv-00.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-6-18142900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-chen-rtp-bv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-chen-rtp-bv-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-18142900.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Thu Jun 19 14:42: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 OAA08690 for ; Thu, 19 Jun 2003 14:42:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5JIg6j23455 for avt-archive@odin.ietf.org; Thu, 19 Jun 2003 14:42:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T4MD-000665-UJ; Thu, 19 Jun 2003 14:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19T4LU-00063K-9x for avt@optimus.ietf.org; Thu, 19 Jun 2003 14:41:16 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08671 for ; Thu, 19 Jun 2003 14:41:13 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19T4Kq-0003Cf-K1; Thu, 19 Jun 2003 14:40:36 -0400 To: IETF-Announce :; Dcc: all-ietf Cc: avt@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 19 Jun 2003 14:40:36 -0400 Subject: [AVT] Last Call: RTP Control Protocol Extended Reports (RTCP XR) to a 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 Audio/Video Transport WG to consider the following Internet-Draft(s) as a Proposed Standard. o Audio/Video Transport (AVT): RTP Control Protocol Extended Reports (RTCP XR) 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-07-03. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-report-extns-06.txt _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jun 20 14:30: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 OAA24119 for ; Fri, 20 Jun 2003 14:30:32 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5KIU5E07766 for avt-archive@odin.ietf.org; Fri, 20 Jun 2003 14:30:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQe9-00020h-Ew; Fri, 20 Jun 2003 14:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19TQdA-0001zs-UX for avt@optimus.ietf.org; Fri, 20 Jun 2003 14:29:00 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23658; Fri, 20 Jun 2003 14:28:57 -0400 (EDT) Message-Id: <200306201828.OAA23658@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: Fri, 20 Jun 2003 14:28:57 -0400 Subject: [AVT] I-D ACTION:draft-rey-avt-3gpp-timed-text-00.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. Title : RTP Payload Format for 3GPP Timed Text Author(s) : J. Rey et al. Filename : draft-rey-avt-3gpp-timed-text-00.txt Pages : 11 Date : 2003-6-20 This document specifies an RTP payload format for the transmission of 3GPP timed text. Timed text is defined as a part of 3GP file format. It is currently used for downloading timed text contents with or without audio/video contents. In the following sections the problems of streaming timed text are addressed and a means for streaming 3GPP timed text over RTP is specified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rey-avt-3gpp-timed-text-00.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-rey-avt-3gpp-timed-text-00.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-rey-avt-3gpp-timed-text-00.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-6-20140610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rey-avt-3gpp-timed-text-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rey-avt-3gpp-timed-text-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-20140610.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Jun 21 21:45: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 VAA20262 for ; Sat, 21 Jun 2003 21:45:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5M1j8B24879 for avt-archive@odin.ietf.org; Sat, 21 Jun 2003 21:45:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ttuf-0006ST-Q4; Sat, 21 Jun 2003 21:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ttub-0006S0-8p for avt@optimus.ietf.org; Sat, 21 Jun 2003 21:44:57 -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 VAA20252 for ; Sat, 21 Jun 2003 21:44:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19TtuY-0001t5-00 for avt@ietf.org; Sat, 21 Jun 2003 21:44:54 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19TtuW-0001t2-00 for avt@ietf.org; Sat, 21 Jun 2003 21:44:52 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h5M1fUm20391 for avt@ietf.org; Sat, 21 Jun 2003 18:41:30 -0700 Date: Sat, 21 Jun 2003 18:41:30 -0700 From: John Lazzaro Message-Id: <200306220141.h5M1fUm20391@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] draft-fairman-rtp-61883-00.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: , Hi everyone, Looks like the I-D announcement below probably should have been posted to the list but wasn't ... ---- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Payload Format for 1394/61883 Isochronous Streams Author(s) : B. Fairman Filename : draft-fairman-rtp-61883-00.txt Pages : 11 Date : 2003-6-19 This document describes a payload format for transporting IEC 61883-1[2] (CIP) compliant IEEE1394 isochronous transport data using RTP. A 1394[3] CIP isochronous transport may carry a stream format, such as DV[4], AM824[5] or MPEG[6], that has been packetized for isochronous transport by the source. The format is opaque to the transport mechanism. The isochronous transport clock is derived from the 1394 cycle timer clock. This protocol may be used to transport 1394 61883 streams between 1394 buses by IP, specifically Ethernet/IP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-fairman-rtp-61883-00.txt ---- ------------------------------------------------------------------------- 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 exim@www1.ietf.org Mon Jun 23 05:49: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 FAA14183 for ; Mon, 23 Jun 2003 05:49:16 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5N9mof04530 for avt-archive@odin.ietf.org; Mon, 23 Jun 2003 05:48:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNvc-0001AM-UQ; Mon, 23 Jun 2003 05:48:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UNvH-00019x-4v for avt@optimus.ietf.org; Mon, 23 Jun 2003 05:47: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 FAA14099 for ; Mon, 23 Jun 2003 05:47:20 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UNuy-0000tT-00 for avt@ietf.org; Mon, 23 Jun 2003 05:47:20 -0400 Received: from gw-nl5.philips.com ([212.153.235.109] ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19UNuj-0000tL-00 for avt@ietf.org; Mon, 23 Jun 2003 05:47:10 -0400 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl5.philips.com (Postfix) with ESMTP id 79B1B552CB for ; Mon, 23 Jun 2003 11:46:40 +0200 (MET DST) Received: from smtprelay-nl2.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id LAA27388 for ; Mon, 23 Jun 2003 11:46:39 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id LAA00012 for ; Mon, 23 Jun 2003 11:46:38 +0200 (MEST) To: avt@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Mon, 23 Jun 2003 11:36:36 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 23/06/2003 11:47:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [AVT] timed text RTP payload 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: , Remarks & questions [ 2. Transmit the text sample size, sample duration and sample description index in-band. In 3GP format this information is included in the header part. In RTP it is important to transmit it in-band because this information might change from sample to sample. ] I think you should explicit that it is not a dangerous thing to do because this information affects only the data in the packet so when you loose a packet you do not loose the context... it is rather obviously true for size and duration, but less obvious for description index, i.e. as you mention it in the section 1.2 a timed text stream may transport samples using several different "descriptions" (i.e. configurations) and it is therefore required to indicate for each sample the "number" (index) of the corresponding description. BTW the sentence "In 3GP format this information is included in the header part" is misleading in this respect... ************** [ 4. Enable the multiplexing of text samples in one single RTP packet. In a mobile communication environment a typical text sample size is around 100 bytes. Thus, multiplexing several text samples makes the transport over RTP more efficient. ] I think you should replace "multiplex" with "aggregation", multiplex hints at something much more "drastic" than what you want to achieve i.e. mixing several different streams together, which comes with a whole lot of difficult issues etc :-) ************** Questions * How does a receiver know if the first element of the payload is a FHDR or a THDR ? * Figure 3.2 has two cases, both are 32 bits aligned, is it a requirement ? otherwise how is the header aligned (with padding ?) * section 4 *recommends* redundancy, I would leave that more open ... anyway would you consider the possibility that the payload format itself would enable redundancy by simply allowing "repeat" (of, say some highly valuable "sentences" ?) regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jun 23 09:52:13 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 JAA20455 for ; Mon, 23 Jun 2003 09:52:13 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NDpkG06747 for avt-archive@odin.ietf.org; Mon, 23 Jun 2003 09:51:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URio-0001ds-90; Mon, 23 Jun 2003 09:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19URhw-0001dE-UU for avt@optimus.ietf.org; Mon, 23 Jun 2003 09:50: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 JAA20401 for ; Mon, 23 Jun 2003 09:49:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19URhg-0002M2-00 for avt@ietf.org; Mon, 23 Jun 2003 09:49:52 -0400 Received: from mail.pel.panasonic.de ([194.162.191.12]) by ietf-mx with esmtp (Exim 4.12) id 19URhV-0002Ly-00 for avt@ietf.org; Mon, 23 Jun 2003 09:49:41 -0400 thread-index: AcM5jhsYeNV2kQteTdepxZq3PmzNSQ== Received: from atrgreyj ([10.78.238.55]) by mail.pel.panasonic.de with Microsoft SMTPSVC(5.0.2195.5329); Mon, 23 Jun 2003 15:48:19 +0200 From: "Jose Rey" To: Content-Class: urn:content-classes:message Priority: normal Cc: Subject: RE: [AVT] timed text RTP payload Date: Mon, 23 Jun 2003 15:48:18 +0200 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) Importance: Normal In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 23 Jun 2003 13:48:19.0909 (UTC) FILETIME=[1B164750:01C3398E] 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 Thanks Philippe for your comments, please see my answers inline... > -----Original Message----- > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of > philippe.gentric@philips.com > Sent: Monday, June 23, 2003 11:37 AM > To: avt@ietf.org > Subject: [AVT] timed text RTP payload > > > > Remarks & questions > > [ > 2. Transmit the text sample size, sample duration and sample > description index in-band. In 3GP format this information is > included in the header part. In RTP it is important to transmit it > in-band because this information might change from sample > to sample. > ] > > I think you should explicit that it is not a dangerous thing > to do because > this information affects only the data in the packet > so when you loose a packet you do not loose the context... > yes. this is explained in the section 1.2 with "..and the Sample to Chunk Box is mapped to the field SIDX (Text Sample Entry Index). The Sample to Chunk Box (stsc) associates the text sample and its corresponding sample description entry in the Sample Description Box (stsd, see below). The Sample to Chunk Box can be used to associate a text sample with a sample description entry... " If more than that is needed, I can add some comment when ellaborating on the resilient transport section. > it is rather obviously true for size and duration, > but less obvious for description index, i.e. as you > mention it in the section 1.2 a timed text stream > may transport samples using several different "descriptions" > (i.e. configurations) and it is therefore required > to indicate for each sample the "number" (index) of the > corresponding description. > exactly.. > BTW the sentence "In 3GP format this information is > included in the header part" is misleading in this respect... > > ************** Not only that... it is even incorrect :) Thanks for the catch! > > > [ > > 4. Enable the multiplexing of text samples in one single RTP > packet. In a mobile communication environment a typical > text sample > size is around 100 bytes. Thus, multiplexing several text samples > makes the transport over RTP more efficient. > ] > > > I think you should replace "multiplex" with "aggregation", > multiplex hints at something much more "drastic" than what you > want to achieve i.e. mixing several different streams together, > which comes with a whole lot of difficult issues etc :-) > "issue" is a word I don't like :) I'll change it to "aggregation". > ************** > > Questions > > * How does a receiver know if the first element of the > payload is a FHDR or a THDR ? > You look at the payload type field in the RTP header: Section 3: "The RTP sender implementing this payload format sends fragmented and non-fragmented text samples using two different payload types, i.e. payload type multiplexing, which are mapped dynamically. For this purpose, a new parameter is specified in this document for SDP, "fragment", see Section SDP. The receiver recognises a fragmented text sample by the payload type value. Note that this fact does not conflict with Section 5.2 of RTP [5] because it is the same media that is being transmitted. " If the RTP packet cotnains non-fragmented samples then there's only THDRs, otherwise FHDR is always before THDR (see Fig. 1.2.) > * Figure 3.2 has two cases, both are 32 bits aligned, is it a > requirement ? > otherwise how is the header aligned (with padding ?) Not at all. For example if Length(SIDX)=Length(SLEN)=Length(SDUR)=8 bits, the header is 24bits long and this is a valid combination. > > * section 4 *recommends* redundancy, I would leave that more open ... > anyway would you consider the possibility that the payload > format itself > would enable redundancy by simply allowing "repeat" > (of, say some highly valuable "sentences" ?) > how about something like: "3GPP Timed Text operates at low bit rates. For this reason the use of redundancy is RECOMMENDED. Redundancy can be achieved in different manners. For example, redundant information can be piggybacked as per RFC 2198 [6], coded into new packets achieving FEC (Forward Error Correction) as per RFC 2733 [7] or the sending application MAY decide to repeat some text sample fragments it deems important to provide packet loss resiliency. Furthermore, other redundancy schemes not listed here might be applicable and defined in other documents." looking forward to your comments, Jose > > regards, > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www1.ietf.org/mailman/listinfo/avt Jose Rey____ mailto:rey@panasonic.de Mobile Multimedia Team - MCOM Group Panasonic European Laboratories GmbH Tel: +49(0)6103-766-134 Fax: +49(0)6103-766-166 http://www.pel.panasonic.de ____________________________________ _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jun 23 17:14: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 RAA10592 for ; Mon, 23 Jun 2003 17:14:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NLE4v18694 for avt-archive@odin.ietf.org; Mon, 23 Jun 2003 17:14:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UYdU-0004qb-Ro; Mon, 23 Jun 2003 17:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UYd1-0004qL-PS for avt@optimus.ietf.org; Mon, 23 Jun 2003 17:13: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 RAA10583 for ; Mon, 23 Jun 2003 17:13:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UYcz-0005mU-00 for avt@ietf.org; Mon, 23 Jun 2003 17:13:29 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19UYco-0005mP-00 for avt@ietf.org; Mon, 23 Jun 2003 17:13:18 -0400 Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19UYci-0007Ic-Cs; Mon, 23 Jun 2003 21:13:12 +0000 To: mats.naslund@era.ericsson.se, mbaugher@cisco.com, "Rolf Blom (EAB)" , "Elisabetta Carrara (EAB)" , mcgrew@cisco.com, "Karl Norrman (EAB)" , oran@cisco.com Cc: avt@ietf.org Date: Mon, 23 Jun 2003 14:13:12 -0700 From: Allison Mankin Message-Id: Subject: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set of 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: , SRTP is on the agenda of the IESG again this week. Some more comments on SRTP may still come in, but I thought it would be worth sending on those of Russ Housley, the second Security AD. Steve Bellovin has supported the draft. Russ has comments that seem straightforward to address. Wait for more comments before sending in a revision, but so far things are going well. Allison > > > Yes No-Objection Discuss * Abstain > > > >Russ Housley [ ] [ ] [ X ] [ ] > > I have six comments. > > 1. In section 1, spell out the first use of RTCP. > > 2. I find the structure of section 2 confusing. I had to read it twice to > understand it. I think that a second level of indenting would be one way > to fix it. I am sure there are others. > > 3. In section 3.1, in the paragraph after figure 1, please delete: > > "It is exact for the pre-defined transforms." > > This point is made more clearly later in the paragraph. Then, at the end > of the same paragraph, the document says: > > "While it could seem more attractive to specify a fixed padding > scheme for all transforms, security and flexibility of transform > specifications REQUIRE that each transform specify a secure > padding method." > > I disagree. IPsec and S/MIME both specify padding schemes that are > employed by all of the ciphers. Please reword. Do not use "REQUIRE" in > the replacement. > > 4. In section 3.2.1, the document says: "the master key(s), which MUST be > random and kept secret." This is quite a high bar. I suggest that > pseudo-random is sufficient. Please see the RFC 2828 definitions of > "random" and "pseudo-random." The document says that it is following these > terms. Also, see RFC 1750. Similarly, the requirement on the master salt > should also be reduced to pseudo-random. > > 5. The last paragraph is section 3.2.3 says: > > "If no valid context can be found for a packet corresponding to a > certain context identifier, that packet MUST be discarded from > further SRTP processing." > > Elsewhere, "discarded from further processing" is used. This seems better > to me. It is discarded, which seems different that no further SRTP > processing. Also, SRTCP should be covered by this statement. > > 6. In section 4.1.1, I am confused by the term "fixed key" in the following: > > "For a fixed Counter Mode key, each IV value used as an input MUST be > distinct, in order to avoid the security exposure of a two-time pad > situation (Section 9.1). To satisfy this constraint, an > implementation MUST ensure that the values of the SRTP packet index > of ROC || SEQ, and the SSRC used in the construction of the IV are > distinct for any fixed key. The failure to ensure this uniqueness > could be catastrophic for Secure RTP. This is in contrast to the > situation for RTP itself, which may be able to tolerate such > failures. It is RECOMMENDED that, if a dedicated security module is > present, the RTP sequence numbers and SSRC either be generated or > checked by that module (i.e., sequence-number and SSRC processing in > an SRTP system needs to be protected as well as the key). " > > I think that "fixed" means "any particular key" but I am not sure. > > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jun 23 18:37: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 SAA13871 for ; Mon, 23 Jun 2003 18:37:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NMb4D27879 for avt-archive@odin.ietf.org; Mon, 23 Jun 2003 18:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZvp-0007ED-OG; Mon, 23 Jun 2003 18:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZul-0007D8-Jq for avt@optimus.ietf.org; Mon, 23 Jun 2003 18:36:10 -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 SAA13834 for ; Mon, 23 Jun 2003 18:35:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UZui-0006ES-00 for avt@ietf.org; Mon, 23 Jun 2003 18:35:52 -0400 Received: from wireless206.east.isi.edu ([65.123.202.206] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19UZuX-0006EC-00 for avt@ietf.org; Mon, 23 Jun 2003 18:35: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 SMTP id h5NMYvFp034520; Mon, 23 Jun 2003 18:35:03 -0400 (EDT) (envelope-from csp@csperkins.org) Date: Mon, 23 Jun 2003 18:34:57 -0400 From: Colin Perkins To: Allison Mankin Cc: mats.naslund@era.ericsson.se, mbaugher@cisco.com, rolf.blom@era.ericsson.se, Elisabetta.Carrara@era.ericsson.se, mcgrew@cisco.com, Karl.Norrman@era.ericsson.se, oran@cisco.com, avt@ietf.org Subject: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set of comments Message-Id: <20030623183457.0534f0a4.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-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 [inline] --> Allison Mankin writes: > SRTP is on the agenda of the IESG again this week. > Some more comments on SRTP may still come in, but I thought > it would be worth sending on those of Russ Housley, the second Security > AD. Steve Bellovin has supported the draft. Russ has comments that > seem straightforward to address. Wait for more comments before > sending in a revision, but so far things are going well. > > Allison > > > > > > Yes No-Objection Discuss * Abstain > > > > > >Russ Housley [ ] [ ] [ X ] [ ] > > > > I have six comments. > > > > 1. In section 1, spell out the first use of RTCP. > > > > 2. I find the structure of section 2 confusing. I had to read it > > twice to understand it. I think that a second level of indenting would > > be one way to fix it. I am sure there are others. > > > > 3. In section 3.1, in the paragraph after figure 1, please delete: > > > > "It is exact for the pre-defined transforms." > > > > This point is made more clearly later in the paragraph. Then, at the > > end of the same paragraph, the document says: > > > > "While it could seem more attractive to specify a fixed padding > > scheme for all transforms, security and flexibility of transform > > specifications REQUIRE that each transform specify a secure > > padding method." > > > > I disagree. IPsec and S/MIME both specify padding schemes that are > > employed by all of the ciphers. Please reword. Do not use "REQUIRE" > > in the replacement. If IPsec and S/MIME both define a standard padding mechanism, why cannot SRTP do the same? And, perhaps, use the standard RTP padding mechanism? -- Colin Perkins csp@csperkins.org _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jun 24 05:05: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 FAA07835 for ; Tue, 24 Jun 2003 05:05:44 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5O95HJ05153 for avt-archive@odin.ietf.org; Tue, 24 Jun 2003 05:05:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UjjZ-0001KU-OX; Tue, 24 Jun 2003 05:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UjjC-0001Jy-UN for avt@optimus.ietf.org; Tue, 24 Jun 2003 05:04: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 FAA07824 for ; Tue, 24 Jun 2003 05:04:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ujj9-0001ao-00 for avt@ietf.org; Tue, 24 Jun 2003 05:04:35 -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 19Ujiy-0001ak-00 for avt@ietf.org; Tue, 24 Jun 2003 05:04:24 -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.6b) with ESMTP id h5O93xG5015898; Tue, 24 Jun 2003 11:03:59 +0200 (MEST) Received: from era.ericsson.se (research-pi6vzu.ki.sw.ericsson.se [147.214.181.170]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP95ANM; Tue, 24 Jun 2003 11:04:46 +0200 Message-ID: <3EF81335.2050606@era.ericsson.se> Date: Tue, 24 Jun 2003 11:00:37 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins CC: Allison Mankin , mbaugher@cisco.com, "Rolf Blom (EAB)" , "Elisabetta Carrara (EAB)" , mcgrew@cisco.com, "Karl Norrman (EAB)" , oran@cisco.com, avt@ietf.org Subject: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set of comments References: <20030623183457.0534f0a4.csp@csperkins.org> 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, Colin Perkins wrote: > [inline] > > --> Allison Mankin writes: > >>SRTP is on the agenda of the IESG again this week. >>Some more comments on SRTP may still come in, but I thought >>it would be worth sending on those of Russ Housley, the second Security >>AD. Steve Bellovin has supported the draft. Russ has comments that >>seem straightforward to address. Wait for more comments before >>sending in a revision, but so far things are going well. >> >>Allison >> >> >>>> Yes No-Objection Discuss * Abstain >>>> >>>>Russ Housley [ ] [ ] [ X ] [ ] >>> >>>I have six comments. >>> >>>1. In section 1, spell out the first use of RTCP. >>> >>>2. I find the structure of section 2 confusing. I had to read it >>>twice to understand it. I think that a second level of indenting would >>>be one way to fix it. I am sure there are others. >>> >>>3. In section 3.1, in the paragraph after figure 1, please delete: >>> >>> "It is exact for the pre-defined transforms." >>> >>>This point is made more clearly later in the paragraph. Then, at the >>>end of the same paragraph, the document says: >>> >>> "While it could seem more attractive to specify a fixed padding >>> scheme for all transforms, security and flexibility of transform >>> specifications REQUIRE that each transform specify a secure >>> padding method." >>> >>>I disagree. IPsec and S/MIME both specify padding schemes that are >>>employed by all of the ciphers. Please reword. Do not use "REQUIRE" >>>in the replacement. >> > > If IPsec and S/MIME both define a standard padding mechanism, why cannot > SRTP do the same? And, perhaps, use the standard RTP padding mechanism? > To comply with Russ' comment, I have no objection to deleting "REQUIRE". I would hesitate to go beyond that. We will open up new issues in doing so. Do we use the IPsec pad? The S/MIME pad? Perhaps none of them is general enough? What about new modes? (If I remember correctly, e.g. XCBC had some padding issues.) David referenced a paper showing that some common pad schemes were "weak". (Even if these weaknesses are "theoretical", we have made great effort to make SRTP "maximally" secure, and I would hate to sub-optimize at this point.) It seems to me that the only future proof approach is to let each transform specify its own padding, or at least point to were a padding spec. can be found. /Mats _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jun 24 12:07: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 MAA21883 for ; Tue, 24 Jun 2003 12:07:30 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OG73Z03049 for avt-archive@odin.ietf.org; Tue, 24 Jun 2003 12:07:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqJw-0000lD-Oi; Tue, 24 Jun 2003 12:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqJ5-0000cg-UT for avt@optimus.ietf.org; Tue, 24 Jun 2003 12:06: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 MAA21766 for ; Tue, 24 Jun 2003 12:06:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UqJ4-0003wK-00 for avt@ietf.org; Tue, 24 Jun 2003 12:06:06 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19UqIr-0003w6-00 for avt@ietf.org; Tue, 24 Jun 2003 12:05:55 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 24 Jun 2003 09:04:32 -0800 Received: from MCGREW-W2K.cisco.com (stealth-10-34-251-98.cisco.com [10.34.251.98]) by sj-core-4.cisco.com (8.12.6/8.12.6) with SMTP id h5OG51RK005119; Tue, 24 Jun 2003 09:05:03 -0700 (PDT) Message-Id: <4.3.2.7.2.20030624055635.023c01e0@mira-sjcm-1.cisco.com> X-Sender: mcgrew@mira-sjcm-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Jun 2003 09:05:00 -0700 To: Mats =?iso-8859-1?Q?N=E4slund?= , Colin Perkins From: David Mcgrew Subject: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set of comments Cc: Allison Mankin , mbaugher@cisco.com, "Rolf Blom (EAB)" , "Elisabetta Carrara (EAB)" , "Karl Norrman (EAB)" , oran@cisco.com, avt@ietf.org In-Reply-To: <3EF81335.2050606@era.ericsson.se> References: <20030623183457.0534f0a4.csp@csperkins.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable 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: quoted-printable Mats, Colin, The RTP padding is simple, and I can definitely see the value of using a=20 standard mechanism. However, it is not clear to me that we actually need a= =20 padding method. AFAICT CBC is the only interesting mode that needs=20 padding. The other 'NIST standard' encryption modes (OFB, CFB, ECB, and=20 counter) and the new and interesting OCB mode don't. Also, there is a CBC= =20 encryption variant that avoids padding by switching to CFB mode to encrypt= =20 the last block; it's been proven secure, though unfortunately NIST hasn't=20 included it in a standard, at least not explicitly. If we used this CBC=20 variant - it would be the variant that would make the most sense for voice= =20 traffic - then AFAICT we don't need a padding method at all. I think that a brief discussion of the security details would be=20 useful. If we allow chosen-plaintext attacks (e.g., the attacker can=20 manipulate the plaintexts directly or indirectly, causing the encryption of= =20 data of her choice), then the padding method can affect=20 confidentiality. Otherwise, I believe that it only affects message=20 authentication. If message authentication is used (before decryption, as=20 required in SRTP), it defeats Vaudenay's attacks against CBC padding [1],=20 and likely defeats all similar attacks. The threat is that when message=20 authentication isn't used, there are attacks that can violate=20 confidentiality. Using the RTP padding method with CBC would provide the= =20 same level of security as does the ESP padding: it's perfectly good unless= =20 there's no authentication, in which case there are some=20 confidentiality-violating attacks. At present, the two ciphers defined for= =20 SRTP don't require padding, and aren't vulnerable to any=20 confidentiality-violating attacks even when message authentication is not=20 used, as you (Mats) point out. One of the complicating factors is algorithms that provide message=20 authentication. Block cipher modes of operation that provide that=20 service (CBC MAC, XCBC MAC, OCB [2]) use their own padding schemes. In=20 each of these modes, the padding method that is used is vital to security,= =20 or at least is used in the security proof. XCBC is widely regarded as the= =20 'right' way to do CBC MAC, and is expected to be adopted by the industry,=20 and it is closely tied to its particular padding scheme. So if we mandate= =20 the RTP padding method for SRTP, we need to make clear that it is just for= =20 encryption modes (that need padding), and not for authentication=20 modes. Perhaps it would make more sense to state that encryption modes=20 that need a padding scheme SHOULD use the RTP padding method, unless they=20 need to use another method for security reasons. OTOH, I personally would= =20 rather see the pad-less variant of CBC, though crypto hardware vendors with= =20 existing products might choose otherwise. On a side note, the RTP padding could be used in conjunction with=20 encryption as a length-hiding mechanism. The sender can hide the length of= =20 a packet by adding padding, which the receiver will discard. The=20 encryption will hide the last padding byte, so that an adversary cannot=20 tell by looking at a ciphertext packet what the length of the payload of=20 the corresponding plaintext packet is. I don't think that we stated this=20 anywhere in the draft, though it seems like a legal use of RTP and SRTP to= me. David [1] Security Flaws Induced by CBC Padding - Applications to SSL, IPsec, and= =20 WTLS, Serge Vaudenay, online at=20 http://lasecwww.epfl.ch/php_code/publications/search.php?ref=3DVau02a [2] NIST Table of Submitted Modes of Operation, online at=20 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ At 11:00 AM 6/24/2003 +0200, Mats N=E4slund wrote: >Hi, > >Colin Perkins wrote: >>[inline] >>--> Allison Mankin writes: >> >>>SRTP is on the agenda of the IESG again this week. >>>Some more comments on SRTP may still come in, but I thought >>>it would be worth sending on those of Russ Housley, the second Security >>>AD. Steve Bellovin has supported the draft. Russ has comments that=20 >>>seem straightforward to address. Wait for more comments before sending= =20 >>>in a revision, but so far things are going well. >>> >>>Allison >>> >>> >>>>> Yes No-Objection Discuss * Abstain >>>>> >>>>>Russ Housley [ ] [ ] [ X ] [ ] >>>> >>>>I have six comments. >>>> >>>>1. In section 1, spell out the first use of RTCP. >>>> >>>>2. I find the structure of section 2 confusing. I had to read it >>>>twice to understand it. I think that a second level of indenting would >>>>be one way to fix it. I am sure there are others. >>>> >>>>3. In section 3.1, in the paragraph after figure 1, please delete: >>>> >>>> "It is exact for the pre-defined transforms." >>>> >>>>This point is made more clearly later in the paragraph. Then, at the >>>>end of the same paragraph, the document says: >>>> >>>> "While it could seem more attractive to specify a fixed padding >>>> scheme for all transforms, security and flexibility of transform >>>> specifications REQUIRE that each transform specify a secure >>>> padding method." >>>> >>>>I disagree. IPsec and S/MIME both specify padding schemes that are=20 >>>>employed by all of the ciphers. Please reword. Do not use "REQUIRE" >>>>in the replacement. >>If IPsec and S/MIME both define a standard padding mechanism, why cannot >>SRTP do the same? And, perhaps, use the standard RTP padding mechanism? > > >To comply with Russ' comment, I have no objection to deleting >"REQUIRE". I would hesitate to go beyond that. > >We will open up new issues in doing so. Do we use the IPsec pad? >The S/MIME pad? Perhaps none of them is general enough? What about >new modes? (If I remember correctly, e.g. XCBC had some padding issues.) >David referenced a paper showing that some common pad schemes >were "weak". (Even if these weaknesses are "theoretical", we have >made great effort to make SRTP "maximally" secure, and I would hate >to sub-optimize at this point.) > >It seems to me that the only future proof approach is to let each >transform specify its own padding, or at least point to were a >padding spec. can be found. > >/Mats > > >_______________________________________________ >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 exim@www1.ietf.org Tue Jun 24 12:15:28 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 MAA22170 for ; Tue, 24 Jun 2003 12:15:28 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OGF1Y05519 for avt-archive@odin.ietf.org; Tue, 24 Jun 2003 12:15:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqRh-0001Qu-9v; Tue, 24 Jun 2003 12:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqNd-0001Dw-W7 for avt@optimus.ietf.org; Tue, 24 Jun 2003 12:10: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 MAA21986 for ; Tue, 24 Jun 2003 12:10:32 -0400 (EDT) From: norbert.rossello@mindspeed.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UqNN-0003zC-00 for avt@ietf.org; Tue, 24 Jun 2003 12:10:33 -0400 Received: from cnxt09251.conexant.com ([198.62.9.251] helo=smtp1.urprovider.com) by ietf-mx with esmtp (Exim 4.12) id 19UqNC-0003xi-00 for avt@ietf.org; Tue, 24 Jun 2003 12:10:22 -0400 Received: from npblnh1.la.mindspeed.com (npblnh1.mindspeed.com. [10.231.18.16]) by smtp1.urprovider.com (8.12.9+Sun/8.12.2) with ESMTP id h5OG8Loc010990; Tue, 24 Jun 2003 09:08:21 -0700 (PDT) Received: from sophiam1.nice.mindspeed.com ([10.1.124.21]) by npblnh1.la.mindspeed.com (Lotus Domino Release 5.0.12) with ESMTP id 2003062409082060:359645 ; Tue, 24 Jun 2003 09:08:20 -0700 To: mbaugher@cisco.com, rolf.blom@era.ericsson.se, elisabetta.carrara@era.ericsson.se, mcgrew@cisco.com, mats.naslund@era.ericsson.se, karl.norrman@era.ericsson.se, oran@cisco.com, avt@ietf.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: Date: Tue, 24 Jun 2003 18:08:18 +0200 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on SOPHIAM1/Server/Mindspeed(Release 5.0.12 |February 13, 2003) at 06/24/2003 06:08:20 PM, Itemize by SMTP Server on NPBLNH1/Server/Conexant(Release 5.0.12 |February 13, 2003) at 06/24/2003 09:08:21 AM, Serialize by Router on NPBLNH1/Server/Conexant(Release 5.0.12 |February 13, 2003) at 06/24/2003 09:08:22 AM, Serialize complete at 06/24/2003 09:08:22 AM Content-type: text/plain; charset=us-ascii Subject: [AVT] The Secure Real-time Transport Protocol : Padding/Bandwidth. 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: , Madam and Sirs, I am responsible for Cipher/VoIP implementation at Mindspeed (ex Conexant). I would like to draw your attention about padding: draft-ietf-avt-srtp-05.txt - 4.1.1 : <> By implementing block cipher (as AES), as you experts know already, we have been facing the padding method consequence (RFC1423, NIST,..) leading to increase bandwidth. Example: G.711 at 5ms generates a payload of 40 bytes. AES blocks are made of 128 bits = 16 bytes. 40 / 16 = 2.5: AES will require 3 blocks increasing the encrypted payload up to 16 x 3 =48 bytes. Hence, AES encryption has impacted the original bandwidth consumption by +20%. This drawback applies to others codec G.729,...which have been designed to save bandwidth. This bandwidth increase is not acceptable for many Gtw manufacturers. Mindspeed would like to submit to you a new scheme that allows encrypting packets which size is not a multiple of AES block size without impacting bandwidth complying with existing modes ECB, CBC,... Please, let me know if this new scheme could contribute to SRTP, so I will send you related documents. Dr Norbert Rossello. Group Leader MindSpeed Cipher Development norbert.rossello@mindspeed.com Mindspeed Technologies BP 161 06903 Sophia Antipolis Cedex - France www.mindspeed.com _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jun 24 12:43: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 MAA23103 for ; Tue, 24 Jun 2003 12:43:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OGh2W10021 for avt-archive@odin.ietf.org; Tue, 24 Jun 2003 12:43:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uqsn-0002aq-OM; Tue, 24 Jun 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UqsB-0002aC-6C for avt@optimus.ietf.org; Tue, 24 Jun 2003 12:42:23 -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 MAA23058 for ; Tue, 24 Jun 2003 12:42:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Uqru-0004B5-00 for avt@ietf.org; Tue, 24 Jun 2003 12:42:06 -0400 Received: from ns4.gdgsc.com ([192.160.62.68] helo=newman.gdgsc.com) by ietf-mx with esmtp (Exim 4.12) id 19Uqrj-0004Am-00 for avt@ietf.org; Tue, 24 Jun 2003 12:41:55 -0400 Received: from gscex01.gsc.gte.com ("port 1932"@gscex01.gsc.gte.com [155.95.162.170]) by newman.gdgsc.com (PMDF V6.2 #30756) with ESMTP id <0HGZ00LJ2VMGBS@newman.gdgsc.com> for avt@ietf.org; Tue, 24 Jun 2003 12:39:52 -0400 (EDT) Received: by gscex01.gsc.gte.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jun 2003 12:40:34 -0400 Content-return: allowed Date: Tue, 24 Jun 2003 12:40:25 -0400 From: "Waterhouse, Richard" Subject: RE: [AVT] The Secure Real-time Transport Protocol : Padding/Bandw idth. To: norbert.rossello@mindspeed.com Cc: avt@ietf.org Message-id: <085B0B78E426244B9C29A160098DAFF5019B4EA9@ndhmex02.ndhm.gd-ns.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain 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: , We don't use SRTP, but we do use AES. We use Counter Mode. This mode doesn't have "error extension". Thus after we have encrypted the 48 bytes we can proceed to throw away 8 of them. When it comes time to decrypt the receiver can just add 8 bytes of padding on the black side, decrypt, and then throw away the padding bits on the red side. The problem you are pointing out is not inherent to AES, it's inherent to the mode you are using with AES. > ---------- > From: > norbert.rossello@mindspeed.com[SMTP:norbert.rossello@mindspeed.com] > Sent: Tuesday, June 24, 2003 12:08 PM > To: mbaugher@cisco.com; rolf.blom@era.ericsson.se; > elisabetta.carrara@era.ericsson.se; mcgrew@cisco.com; > mats.naslund@era.ericsson.se; karl.norrman@era.ericsson.se; > oran@cisco.com; avt@ietf.org > Subject: [AVT] The Secure Real-time Transport Protocol : > Padding/Bandwidth. > > > Madam and Sirs, > > I am responsible for Cipher/VoIP implementation at Mindspeed (ex > Conexant). > > I would like to draw your attention about padding: > draft-ietf-avt-srtp-05.txt - 4.1.1 : > < leading zeros as needed to make the operation well-defined..>> > > By implementing block cipher (as AES), as you experts know already, > we have been facing the padding method consequence (RFC1423, NIST,..) > leading to increase bandwidth. > > Example: > G.711 at 5ms generates a payload of 40 bytes. > AES blocks are made of 128 bits = 16 bytes. > 40 / 16 = 2.5: AES will require 3 blocks increasing the encrypted payload > up to 16 x 3 =48 bytes. > Hence, AES encryption has impacted the original bandwidth consumption by > +20%. > This drawback applies to others codec G.729,...which have been designed to > save bandwidth. > This bandwidth increase is not acceptable for many Gtw manufacturers. > > Mindspeed would like to submit to you a new scheme that allows encrypting > packets which size is not a multiple of AES block size without impacting > bandwidth > complying with existing modes ECB, CBC,... > > Please, let me know if this new scheme could contribute to SRTP, > so I will send you related documents. > > Dr Norbert Rossello. > Group Leader MindSpeed Cipher Development > norbert.rossello@mindspeed.com > > Mindspeed Technologies > BP 161 > 06903 Sophia Antipolis Cedex - France > www.mindspeed.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 exim@www1.ietf.org Tue Jun 24 13:23: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 NAA25435 for ; Tue, 24 Jun 2003 13:23:33 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OHN7e17500 for avt-archive@odin.ietf.org; Tue, 24 Jun 2003 13:23:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UrVV-0004Xf-Jy; Tue, 24 Jun 2003 13:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UrUd-0004XO-4a for avt@optimus.ietf.org; Tue, 24 Jun 2003 13:22: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 NAA25352 for ; Tue, 24 Jun 2003 13:22:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UrUb-0004Yx-00 for avt@ietf.org; Tue, 24 Jun 2003 13:22:05 -0400 Received: from falcon.ericsson.se ([193.180.251.52] helo=falcon.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19UrUQ-0004XW-00 for avt@ietf.org; Tue, 24 Jun 2003 13:21:54 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5OHJqcv020810; Tue, 24 Jun 2003 19:19:52 +0200 Received: from era.ericsson.se (permit154.er.ki.sw.ericsson.se [147.214.97.154]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP98T5T; Tue, 24 Jun 2003 19:18:41 +0200 Message-ID: <3EF88733.70204@era.ericsson.se> Date: Tue, 24 Jun 2003 19:15:31 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: norbert.rossello@mindspeed.com CC: mbaugher@cisco.com, "Rolf Blom (EAB)" , "Elisabetta Carrara (EAB)" , mcgrew@cisco.com, "Karl Norrman (EAB)" , oran@cisco.com, avt@ietf.org References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by falcon.al.sw.ericsson.se id h5OHJqcv020810 Content-Transfer-Encoding: quoted-printable Subject: [AVT] Re: The Secure Real-time Transport Protocol : Padding/Bandwidth. 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: quoted-printable Dear Dr Rosello, I suspect that you have misread the spec, possibly caused by some unclarity on our behalf, in which case I apologize. More below. norbert.rossello@mindspeed.com wrote: > Madam and Sirs, >=20 > I am responsible for Cipher/VoIP implementation at Mindspeed (ex Conexa= nt). >=20 > I would like to draw your attention about padding: > draft-ietf-avt-srtp-05.txt - 4.1.1 : > < leading zeros as needed to make the operation well-defined..>> Note that this does not produce padding of the cipher *output*, it is a padding of the cipher *input*. Hence, there is no impact on bandwidth at all (more below). > By implementing block cipher (as AES), as you experts know already, > we have been facing the padding method consequence (RFC1423, NIST,..) > leading to increase bandwidth. >=20 > Example: > G.711 at 5ms generates a payload of 40 bytes. > AES blocks are made of 128 bits =3D 16 bytes. > 40 / 16 =3D 2.5: AES will require 3 blocks increasing the encrypted pay= load > up to 16 x 3 =3D48 bytes. > Hence, AES encryption has impacted the original bandwidth consumption b= y > +20%. > This drawback applies to others codec G.729,...which have been designed= to > save bandwidth. > This bandwidth increase is not acceptable for many Gtw manufacturers. If you use SRTP with the default counter mode transform, here is what will happen: Let the codec output be denoted m (40 bytes). 1. Form the input to the cipher according to the text you copied above from Sect 4.1.1. Denote this (possibly padded) value by IV (which will always be 128 bits/16 bytes). 2. Run AES on the session key and the above input, IV, producing a 128 bit output which I denote s0. 3. Run AES again on IV+1, IV+2,... producing s1, s2... until at least 40 bytes of output has been obtained, denote this total output s =3D s0 || s1 || ,,, (i.e. size(s) >=3D 40 bytes). 4. Take the XOR of m and the **40 first bytes** of s, producing the ciphered output y (which has the same size as m, 40 bytes). (Disgard excess bytes of s.) 5. Transmit y. On the receiver side, excactly the same procedure takes place, only that "y" takes the place of "m", resulting in retrieving m back. >=20 > Mindspeed would like to submit to you a new scheme that allows encrypti= ng > packets which size is not a multiple of AES block size without impactin= g > bandwidth > complying with existing modes ECB, CBC,... >=20 > Please, let me know if this new scheme could contribute to SRTP, > so I will send you related documents. Since SRTP is very close to passing IESG review (I hope...) I think adding another mode at this late stage would be highly undesireable. Moreover, I don't see the need for it as there is no extra bandwidth consumption implied by the already pre-defined transforms. Best, /Mats ---------------------------------------------- Mats N=E4slund, PhD, Senior Specialist Communications Security Lab, Ericsson Research SE-16480 Stockholm, Sweden Visiting adr: Torshamnsgatan 23, Kista Phone/Fax: (+46 8) 58533739/4047020 _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Tue Jun 24 13:34: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 MAA23104 for ; Tue, 24 Jun 2003 12:43:29 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5OGh2i10022 for avt-archive@odin.ietf.org; Tue, 24 Jun 2003 12:43:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uqsn-0002ah-6s; Tue, 24 Jun 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Uqrk-0002Zy-R1 for avt@optimus.ietf.org; Tue, 24 Jun 2003 12:42: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 MAA23048 for ; Tue, 24 Jun 2003 12:41:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UqqZ-0004Al-00 for avt@ietf.org; Tue, 24 Jun 2003 12:40:44 -0400 Received: from gorilla.mchh.siemens.de ([194.138.158.18]) by ietf-mx with esmtp (Exim 4.12) id 19UqqO-0004Ad-00 for avt@ietf.org; Tue, 24 Jun 2003 12:40:32 -0400 Received: from blues.mchh.siemens.de ([139.21.204.206]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id SAA21523; Tue, 24 Jun 2003 18:40:10 +0200 (MET DST) Received: from mchh246e.demchh201e.icn.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by blues.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id SAA13417; Tue, 24 Jun 2003 18:39:08 +0200 (MET DST) Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Tue, 24 Jun 2003 18:39:40 +0200 Message-ID: <99522F0FD7EFD611A47D0002A58EDAB701620EBA@mchh2a8e.mchh.siemens.de> From: Euchner Martin To: "'norbert.rossello@mindspeed.com'" , mbaugher@cisco.com, rolf.blom@era.ericsson.se, elisabetta.carrara@era.ericsson.se, mcgrew@cisco.com, mats.naslund@era.ericsson.se, karl.norrman@era.ericsson.se, oran@cisco.com, avt@ietf.org, Euchner Martin Subject: RE: [AVT] The Secure Real-time Transport Protocol : Padding/Bandw idth. Date: Tue, 24 Jun 2003 18:39:38 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) 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: , Dear all, I'm very confused by this entire SRTP padding discussion. My understanding of SRTP is that the document describes a stream-cipher using AES in counter and/or F8 mode. As such, SRTP in this byte-stream mode does not need any padding of the payload, as stream-ciphers do not pad typically. (Note: One can use SRTP with AES with the 40 byte G.711/G.729 payload without any message expansion). Since the SRTP draft ID provides the possibility of using other crypto mechanisms as an extension, padding might be an issue. Since we have not seen any such extension so far, we can't tell, if padding would be an issue nor how padding should be done for any potential future SRTP encryption mechanism. My recommendation thus, is that SRTP padding issue be deferred to the future and be solved when there is a need for it. For now it should be sufficient to state, that padding issues should be addressed by the extension documents. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: norbert.rossello@mindspeed.com [mailto:norbert.rossello@mindspeed.com] Sent: Tuesday, June 24, 2003 6:08 PM To: mbaugher@cisco.com; rolf.blom@era.ericsson.se; elisabetta.carrara@era.ericsson.se; mcgrew@cisco.com; mats.naslund@era.ericsson.se; karl.norrman@era.ericsson.se; oran@cisco.com; avt@ietf.org Subject: [AVT] The Secure Real-time Transport Protocol : Padding/Bandwidth. Madam and Sirs, I am responsible for Cipher/VoIP implementation at Mindspeed (ex Conexant). I would like to draw your attention about padding: draft-ietf-avt-srtp-05.txt - 4.1.1 : <> By implementing block cipher (as AES), as you experts know already, we have been facing the padding method consequence (RFC1423, NIST,..) leading to increase bandwidth. Example: G.711 at 5ms generates a payload of 40 bytes. AES blocks are made of 128 bits = 16 bytes. 40 / 16 = 2.5: AES will require 3 blocks increasing the encrypted payload up to 16 x 3 =48 bytes. Hence, AES encryption has impacted the original bandwidth consumption by +20%. This drawback applies to others codec G.729,...which have been designed to save bandwidth. This bandwidth increase is not acceptable for many Gtw manufacturers. Mindspeed would like to submit to you a new scheme that allows encrypting packets which size is not a multiple of AES block size without impacting bandwidth complying with existing modes ECB, CBC,... Please, let me know if this new scheme could contribute to SRTP, so I will send you related documents. Dr Norbert Rossello. Group Leader MindSpeed Cipher Development norbert.rossello@mindspeed.com Mindspeed Technologies BP 161 06903 Sophia Antipolis Cedex - France www.mindspeed.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 exim@www1.ietf.org Thu Jun 26 10:27: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 KAA27855 for ; Thu, 26 Jun 2003 10:27:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5QER5b13338 for avt-archive@odin.ietf.org; Thu, 26 Jun 2003 10:27:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VXhL-0003KO-1N; Thu, 26 Jun 2003 10:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VXgd-0003JE-Ct for avt@optimus.ietf.org; Thu, 26 Jun 2003 10:25:19 -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 KAA27695 for ; Thu, 26 Jun 2003 10:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VXgM-0001vD-00 for avt@ietf.org; Thu, 26 Jun 2003 10:25:02 -0400 Received: from bzq-179-22-133.cust.bezeqint.net ([212.179.22.133] helo=lodmsg01.corp.audiocodes.com) by ietf-mx with esmtp (Exim 4.12) id 19VXg8-0001t5-00 for avt@ietf.org; Thu, 26 Jun 2003 10:24:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33BED.C9EC1339" Date: Thu, 26 Jun 2003 17:18:17 +0300 Message-ID: Thread-Topic: Q about draft-ietf-avt-rtp-new Thread-Index: AcM77c2Nx11qh5vyEdeSdQDQt7+w2w== From: "Oren Peleg" To: "Stephen Casner" Cc: Subject: [AVT] Q about draft-ietf-avt-rtp-new 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_001_01C33BED.C9EC1339 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Stephen, Is this draft a potential RFC? or its like the avt-profile & = avt-profile-new which one is the update of the other that is subject to = future updates as well & therefore will never become an RFC. Thanks, Oren Peleg Work phone No. : 03 - 5394167 Home phone No. : 03 - 5335913 Cell phone No. : 055 - 669613 Email : Oren.Peleg@audiocodes.com ------_=_NextPart_001_01C33BED.C9EC1339 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Q about draft-ietf-avt-rtp-new

Hi Stephen,

Is this draft a potential = RFC? or its like the avt-profile & avt-profile-new which one is the = update of the other that is subject to future updates as well & = therefore will never become an RFC.

Thanks,

Oren Peleg

Work phone No. : 03 - 5394167

Home phone No. : 03 - 5335913

Cell phone No. : 055 - 669613

Email : Oren.Peleg@audiocodes.com

------_=_NextPart_001_01C33BED.C9EC1339-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jun 27 18:31: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 SAA23762 for ; Fri, 27 Jun 2003 18:31:04 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RMUbx29667 for avt-archive@odin.ietf.org; Fri, 27 Jun 2003 18:30:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1jT-0007Qk-6a; Fri, 27 Jun 2003 18:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vudc-0002P9-HL for avt@optimus.ietf.org; Fri, 27 Jun 2003 10:55:44 -0400 Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21548; Fri, 27 Jun 2003 06:17:00 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=mail.zrz.TU-Berlin.DE) by mail.zrz.tu-berlin.de with esmtp (exim-4.20-2) id 19VpH9-0002al-M9; Fri, 27 Jun 2003 11:12:11 +0200 Received: from mail.zrz.TU-Berlin.DE ([130.149.4.15]) by mail.zrz.TU-Berlin.DE (MailMonitor for SMTP v1.2.2 ) ; Fri, 27 Jun 2003 11:12:07 +0200 (CEST) Received: from ftmail.ee.tu-berlin.de ([130.149.49.250]) by mail.zrz.tu-berlin.de with esmtp (exim-4.20-2) id 19VpH1-0001su-Jk; Fri, 27 Jun 2003 11:12:03 +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 h5R95pB32445; Fri, 27 Jun 2003 11:05:51 +0200 Message-ID: <3EFC0AEC.4020300@ft.ee.tu-berlin.de> Date: Fri, 27 Jun 2003 11:14:20 +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 Content-Type: multipart/mixed; boundary="------------070605040404060009040902" X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de; Fri, 27 Jun 2003 11:12:03 +0200 Subject: [AVT] CfP: Frist European 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. --------------070605040404060009040902 Content-Type: multipart/alternative; boundary="------------070407070808010504030103" --------------070407070808010504030103 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 The submission deadline for EWSN has been extended to July 14th, 18:00 middle European daylight savings time (corresponding to noon Eastern Standard Time or 9 am Pacific time). Best regards Adam Wolisz --------------070407070808010504030103 Content-Type: text/html; charset=us-ascii 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

The submission deadline for EWSN has been extended to July 14th, 18:00 middle European daylight savings time (corresponding to noon Eastern Standard Time or 9 am Pacific time). 

Best regards
Adam Wolisz 

--------------070407070808010504030103-- --------------070605040404060009040902 Content-Type: application/pdf; name="1_EWSN-Call%20(2).pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="1_EWSN-Call%20(2).pdf" Content-Transfer-Encoding: base64 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== --------------070605040404060009040902-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Fri Jun 27 18:31: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 SAA23763 for ; Fri, 27 Jun 2003 18:31:04 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RMUbj29665 for avt-archive@odin.ietf.org; Fri, 27 Jun 2003 18:30:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19W1jS-0007QP-9V; Fri, 27 Jun 2003 18:30:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VkiH-00039D-Ev for avt@optimus.ietf.org; Fri, 27 Jun 2003 00:21: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 AAA04359 for ; Fri, 27 Jun 2003 00:19:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19VkiF-00012V-00 for avt@ietf.org; Fri, 27 Jun 2003 00:19:51 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19Vki4-00012G-00 for avt@ietf.org; Fri, 27 Jun 2003 00:19:40 -0400 Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 4.14) id 19VkhR-000OBP-Dj; Fri, 27 Jun 2003 04:19:01 +0000 To: jan.vandermeer@philips.com, dmackie@apple.com, viswanathan.swaminathan@sun.com, singer@apple.com, philippe.gentric@philips.com Cc: casner@acm.org, magnus.westerlund@ericsson.com, csp@csperkins.org, smb@research.att.com, ned.freed@mrochek.com, mankin@psg.com, avt@ietf.org Reply-To: mankin@psg.com Date: Thu, 26 Jun 2003 21:19:00 -0700 From: Allison Mankin Message-Id: Subject: [AVT] IESG Review of draft-ietf-avt-mpeg4-simple-07.txt - Discuss 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: , The IESG reviewed draft-ietf-avt-mpeg4-simple-07.txt and had a few concerns that should be addressed before the draft can advance. Editorially: Comment: It is strange to have more than one section labeled "Introduction." Please pick a new label for section 2.1. Steve Bellovin and Ned Freed both request that a reference be given in the Security Considerations for security model for ECMAscript. Here is Steve's Discuss comment: Where is the security model defined for ECMAScript in this context? (Problems with the model have been part of the Javascript security problem for Web browsers.) Steve also asked: 2.4: Why is this form of application-level fragmentation better than IP fragmentation? Please discuss the issues in email and we'll see if the fixes to the draft can be done as notes rather than a revised i-d, to be quicker. Allison _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sat Jun 28 20:41:01 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 UAA07221 for ; Sat, 28 Jun 2003 20:41:01 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5T0bCM10179 for avt-archive@odin.ietf.org; Sat, 28 Jun 2003 20:37:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WQBh-0002V6-Fw; Sat, 28 Jun 2003 20:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WQBO-0002UH-ME for avt@optimus.ietf.org; Sat, 28 Jun 2003 20:36: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 UAA07175 for ; Sat, 28 Jun 2003 20:36:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WQBM-0006PJ-00 for avt@ietf.org; Sat, 28 Jun 2003 20:36:40 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19WQBB-0006PE-00 for avt@ietf.org; Sat, 28 Jun 2003 20:36:29 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h5T0Wao09433 for avt@ietf.org; Sat, 28 Jun 2003 17:32:36 -0700 Date: Sat, 28 Jun 2003 17:32:36 -0700 From: John Lazzaro Message-Id: <200306290032.h5T0Wao09433@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] RTP MIDI I-D update ... 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 version of the RTP MIDI normative 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-rtp-midi.txt In a hopeful sign, the Change Log is sufficiently short to reproduce in full below: Chapter M (Appendix A.9) has been redesigned, to follow the semantic design of Chapters C and E. Several definitions in Appendix A.1 have been changed to reflect this change, as have the chapter inclusion semantics for Chapter M in Appendix C.1.3. Many small editorial changes throughout the document, to correct grammatical errors and improve phrasing. I won't be present in Vienna (unlike Billy Joel, Vienna does not wait for me :-), but I'll be submitting a few PDF slides that update RTP MIDI status, and will be sending a longer report based on the slides to the WG group, as the meeting date approaches. ------------------------------------------------------------------------- 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 exim@www1.ietf.org Sat Jun 28 21:37: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 VAA07893 for ; Sat, 28 Jun 2003 21:37:31 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5T1b3d18247 for avt-archive@odin.ietf.org; Sat, 28 Jun 2003 21:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WR7l-0004jd-JJ; Sat, 28 Jun 2003 21:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WR7Y-0004ix-T4 for avt@optimus.ietf.org; Sat, 28 Jun 2003 21:36: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 VAA07887 for ; Sat, 28 Jun 2003 21:36:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WR7W-0006a6-00 for avt@ietf.org; Sat, 28 Jun 2003 21:36:46 -0400 Received: from snap.cs.berkeley.edu ([128.32.34.209] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19WR7L-0006a3-00 for avt@ietf.org; Sat, 28 Jun 2003 21:36:35 -0400 Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.11.6/8.9.3-ZUUL) id h5T1WSI09581 for avt@ietf.org; Sat, 28 Jun 2003 18:32:28 -0700 Date: Sat, 28 Jun 2003 18:32:28 -0700 From: John Lazzaro Message-Id: <200306290132.h5T1WSI09581@snap.CS.Berkeley.EDU> To: avt@ietf.org Subject: [AVT] IRTF p2prg ... 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, The IRTF Peer-to-Peer Research Group was announced a few days ago: http://www.irtf.org/charters/p2prg.html From the charter: To this end, the research group also emphasizes the following near-term goals: [...] exploring interfaces to IETF protocols to realize the models; and offering input to the IETF as a starting place for possible groups standardizing new protocols that are useful in building P2P applications. From the perspective of RTP, one way to look at this charter is that RTP knows the abstract model it prefers for a population of hosts -- a multicast group -- and so if a goal is to interface P2P to RTP, p2prg should offer a multicast abstraction of some flavor. However, one could imagine other ways to look at this charter with respect to RTP that are quite different ... In any event, the odds of an outcome useful to AVT go up if we communicate with them early in their process, so I thought I'd post to point interested folks in their direction ... I'm monitoring the group (nothing much has happened yet), but I really don't have the routing experience to be an active participant in it. ------------------------------------------------------------------------- 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 exim@www1.ietf.org Sun Jun 29 02:01: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 CAA12455 for ; Sun, 29 Jun 2003 02:01:23 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5T609I27135 for avt-archive@odin.ietf.org; Sun, 29 Jun 2003 02:00:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WVEI-00072w-PC; Sun, 29 Jun 2003 02:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WEUC-0002xH-So for avt@optimus.ietf.org; Sat, 28 Jun 2003 08:07: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 IAA21367 for ; Sat, 28 Jun 2003 08:07:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WEUB-0002wM-00 for avt@ietf.org; Sat, 28 Jun 2003 08:07:19 -0400 Received: from web13308.mail.yahoo.com ([216.136.175.44]) by ietf-mx with smtp (Exim 4.12) id 19WEU1-0002w2-00 for avt@ietf.org; Sat, 28 Jun 2003 08:07:09 -0400 Message-ID: <20030628120644.97340.qmail@web13308.mail.yahoo.com> Received: from [61.11.60.240] by web13308.mail.yahoo.com via HTTP; Sat, 28 Jun 2003 05:06:44 PDT Date: Sat, 28 Jun 2003 05:06:44 -0700 (PDT) From: Muni Chandra To: avt@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-19141782-1056802004=:97067" Subject: [AVT] RFC 2190 : Clarification 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: , --0-19141782-1056802004=:97067 Content-Type: text/plain; charset=us-ascii Hello I am working on the implementation part of RFC 2190 for H.263 video packtization. I have a clarification. 1) As per RFC 2190, In MODE A, beginning of Packet should contain GOB with its Header. So, this means only first GOB (or part of it) in each packet should contain GOB header, rest GOBs will not have GOB header in the same MODE-A packet. 2) But H.263 standard says ( this with respective to my discussion with H.263 developers) whether all GOB's should have headers and all should not have GOB headers in a paerticular frame. 3) So to acheive above point 1 with respective above point 2, we need to calculate header for all GOB's and transmit GOB header only for first GOB of each MODE - A packet. Please clarify above point 3 is correct or we can calculate GOB headers for only first GOB of each MODE -A packet. So that we can save time of GOB header computation at rest of GOBs. Thanking you in Advance Muni Chanra Reddy --------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! --0-19141782-1056802004=:97067 Content-Type: text/html; charset=us-ascii
Hello
 
I am working on the implementation part of RFC 2190
for H.263 video packtization.
 
I have a clarification.
 
1) As per RFC 2190, In MODE A,   beginning of Packet should contain GOB with its Header. So, this means only first GOB (or part of it) in  each packet should contain GOB header, rest GOBs will not have GOB header in the same MODE-A packet.
 
2) But H.263 standard says ( this with respective to my discussion with H.263 developers) whether all GOB's should have headers and all should not have GOB headers in a paerticular frame.
 
3) So to acheive above point 1 with respective above point 2, we need to  calculate header for all GOB's and transmit GOB header only for first GOB of each MODE - A packet.
 
Please clarify above point 3 is correct or we can calculate GOB headers for only first GOB of each MODE -A packet. So that we can save time of GOB header computation at  rest of GOBs.
 
Thanking you in Advance
 
Muni Chanra Reddy

Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month! --0-19141782-1056802004=:97067-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Sun Jun 29 13:19: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 NAA02404 for ; Sun, 29 Jun 2003 13:19:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5THJ5Y07300 for avt-archive@odin.ietf.org; Sun, 29 Jun 2003 13:19:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19WfpN-0001so-R9; Sun, 29 Jun 2003 13:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Wfny-0001rj-E6 for avt@optimus.ietf.org; Sun, 29 Jun 2003 13:18: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 NAA02316 for ; Sun, 29 Jun 2003 13:17:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19WfkF-0002qJ-00 for avt@ietf.org; Sun, 29 Jun 2003 13:13:43 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19Wfjz-0002pq-00 for avt@ietf.org; Sun, 29 Jun 2003 13:13:27 -0400 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h5THD0kM017124; Sun, 29 Jun 2003 13:13:00 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h5THCwN30589; Sun, 29 Jun 2003 13:12:59 -0400 Message-ID: <3EFF1D2F.1070506@cs.columbia.edu> Date: Sun, 29 Jun 2003 13:09:03 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zhenfu Lin CC: "'scott.petrack@edial.com'" , "'avt@ietf.org'" References: <725301F4D1E9D411A69F0002A507428E0166D0CF@nt-rmna-exch.ca.broadcom.com> In-Reply-To: <725301F4D1E9D411A69F0002A507428E0166D0CF@nt-rmna-exch.ca.broadcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [AVT] Re: Question on MFR1 in draft-ietf-avt-rfc2833bis-02.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: 7bit Zhenfu Lin wrote: > Hello editors. > > I have a couple of quesions regard MFR1. My apologies for the delay in responding. > > 1) What is the frequency pair for MF R1 S3 in Table 6 of > draft-ietf-avt-rfc2833bis-02.txt? (I am guessing that it is frequency > pair 700/1700 Hz.) This was a mistake, related to the item below. > 2) Both KP and KP1 refer to the same frequency pair, namely 1100/1700 > Hz. In Table 6, KP is mapped to 138 and KP1 is mapped to 139. So, > frequency pair 1100/1700 Hz maps to two codes (138 and 139). - a: > Does this mean that one of these codes is used when a RFC 2833 packet > is generated? Which one should be used? - b: Does this mean that the > receiver is prepared to receive both codes, and map both to the > frequency pair 1100/1700 Hz? This was a bug caused by confusion in the description and labeling of these tones. I've now cleaned this up and removed duplicates, so that each frequency pair has a single label: MF 0\ldots 9 & 128\ldots 137 & & yes\\ MF 700/1700 (Code 11, KP3P, ST3P) & 138 & & yes\\ MF 1100/1700 (KP, KP1) & 139 & & yes\\ MF 1300/1700 (KP2, ST2P) & 140 & & yes\\ MF 1500/1700 (ST) & 141 & & yes\\ MF 900/1700 (Code 12, STP) & 142 & & yes\\ I've looked at a variety of sources (ITU Q.140/Q.151, Freeman, GR-506) and the labeling seems now self-consistent. -03 should appear early next week. > > Thank you. > > Zhenfu _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jun 30 15: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 PAA11768 for ; Mon, 30 Jun 2003 15:07:34 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5UJ77G10933 for avt-archive@odin.ietf.org; Mon, 30 Jun 2003 15:07:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3zQ-0002oo-Il; Mon, 30 Jun 2003 15:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X3yg-0002mr-Sk for avt@optimus.ietf.org; Mon, 30 Jun 2003 15:06:14 -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 PAA11571 for ; Mon, 30 Jun 2003 15:06:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X3yd-0003fJ-00 for avt@ietf.org; Mon, 30 Jun 2003 15:06:11 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 19X3yS-0003dx-00 for avt@ietf.org; Mon, 30 Jun 2003 15:06:00 -0400 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Mon, 30 Jun 2003 12:04:25 -0700 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 30 Jun 2003 12:04:25 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Jun 2003 12:04:26 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 30 Jun 2003 12:04:25 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Mon, 30 Jun 2003 12:04:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6940.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [AVT] RFC 2190 : Clarification Date: Mon, 30 Jun 2003 12:03:35 -0700 Message-ID: <91D7F2CEE3425A4A9D11311D09FCE24602A346F2@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [AVT] RFC 2190 : Clarification Thread-Index: AcM+A+44I4HB9IlfQnWqkrewu6OqzABLJO3Q From: "Gary Sullivan" To: "Muni Chandra" , X-OriginalArrivalTime: 30 Jun 2003 19:04:24.0678 (UTC) FILETIME=[6BDCA060:01C33F3A] 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. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33F3A.6B828AB8" ------_=_NextPart_001_01C33F3A.6B828AB8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few comments in response: =20 - RFC 2190 should only be used for H.263 that pre-date 1998 in syntax design (i.e., no use of PLUSPTYPE header format). =20 - RFC 2429 is a better design than 2190, and 2429 can be used for both old and newer versions of H.263 syntax. =20 Regarding the questions: =20 1) I don't think RFC 2190 any prohibition against having additional GOB headers within Mode A packets. The RFC says it "allows fragmentation at GOB boundaries", but I don't see anywhere where it says it *requires* such fragmentation or prohibits GOB headers within packets. =20 2) As far as the H.263 standard (and within RFC 2190, I believe) is concerned, it is up to the discretion of the encoder when to send GOB headers and when not to. Even within a single coded picture, some GOBs can have headers while others do not. In some particular system environments (e.g. in some H.32x environments), there are ways to indicate that GOB headers should be sent or do not need to be sent for all GOBs - but this is outside the scope of H.263 itself. There is nothing in the H.263 video spec itself that requires any particular behavior for whether GOB headers are present or not. =20 3) Given the above statements about item 1, I don't think item 3 is especially relevant anymore. =20 Best Regards, =20 Gary Sullivan =20 -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of Muni Chandra Sent: Saturday, June 28, 2003 5:07 AM To: avt@ietf.org Subject: [AVT] RFC 2190 : Clarification Hello=20 =20 I am working on the implementation part of RFC 2190 for H.263 video packtization. =20 I have a clarification. =20 1) As per RFC 2190, In MODE A, beginning of Packet should contain GOB with its Header. So, this means only first GOB (or part of it) in each packet should contain GOB header, rest GOBs will not have GOB header in the same MODE-A packet. =20 2) But H.263 standard says ( this with respective to my discussion with H.263 developers) whether all GOB's should have headers and all should not have GOB headers in a paerticular frame. =20 3) So to acheive above point 1 with respective above point 2, we need to calculate header for all GOB's and transmit GOB header only for first GOB of each MODE - A packet. =20 Please clarify above point 3 is correct or we can calculate GOB headers for only first GOB of each MODE -A packet. So that we can save time of GOB header computation at rest of GOBs. =20 Thanking you in Advance =20 Muni Chanra Reddy _____ =20 Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! ------_=_NextPart_001_01C33F3A.6B828AB8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
A few=20 comments in response:
 
- RFC=20 2190 should only be used for H.263 that pre-date 1998 in syntax design = (i.e., no=20 use of PLUSPTYPE header format).
 
- RFC=20 2429 is a better design than 2190, and 2429 can be used for both old and = newer=20 versions of H.263 syntax.
 
Regarding the questions:
 
1) I=20 don't think RFC 2190 any prohibition against having=20 additional GOB headers within Mode A packets.  The RFC says it = "allows=20 fragmentation at GOB boundaries", but I don't see anywhere where it says = it=20 *requires* such fragmentation or prohibits GOB headers within=20 packets.
 
2) As=20 far as the H.263 standard (and within RFC 2190, I believe) is concerned, = it is=20 up to the discretion of the encoder when to send GOB headers and when = not=20 to.  Even within a single coded picture, some GOBs can = have=20 headers while others do not.  In some particular system = environments=20 (e.g. in some H.32x environments), there are ways to indicate that GOB = headers=20 should be sent or do not need to be sent for all GOBs - but this is = outside=20 the scope of H.263 itself.  There is nothing in the H.263 video = spec itself=20 that requires any particular behavior for whether GOB headers are = present or=20 not.
 
3)=20 Given the above statements about item 1, I don't think item 3 is = especially=20 relevant anymore.
 
Best=20 Regards,
 
Gary=20 Sullivan
 
 -----Original = Message-----
From:=20 avt-admin@ietf.org [mailto:avt-admin@ietf.org] On Behalf Of Muni=20 Chandra
Sent: Saturday, June 28, 2003 5:07 AM
To:=20 avt@ietf.org
Subject: [AVT] RFC 2190 :=20 Clarification

Hello
 
I am working on the implementation = part of RFC=20 2190
for H.263 video packtization.
 
I have a clarification.
 
1) As per RFC 2190, In MODE = A,  =20 beginning of Packet should contain GOB with its Header. So, this means = only=20 first GOB (or part of it) in  each packet should contain GOB = header, rest=20 GOBs will not have GOB header in the same MODE-A packet.
 
2) But H.263 standard says ( this = with respective=20 to my discussion with H.263 developers) whether all GOB's should have = headers=20 and all should not have GOB headers in a paerticular = frame.
 
3) So to acheive above point 1 with = respective=20 above point 2, we need to  calculate header for all GOB's and = transmit=20 GOB header only for first GOB of each MODE - A packet.
 
Please clarify above point 3 is = correct or we can=20 calculate GOB headers for only first GOB of each MODE -A packet. So = that we=20 can save time of GOB header computation at  rest of=20 GOBs.
 
Thanking you in Advance
 
Muni Chanra = Reddy

Do you Yahoo!?
SBC=20 Yahoo! DSL - Now only $29.95 per month! ------_=_NextPart_001_01C33F3A.6B828AB8-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From exim@www1.ietf.org Mon Jun 30 20:53: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 UAA24717 for ; Mon, 30 Jun 2003 20:53:35 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h610r6n21091 for avt-archive@odin.ietf.org; Mon, 30 Jun 2003 20:53:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X9OI-0005SQ-3F; Mon, 30 Jun 2003 20:53:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19X9Nq-0005Qk-6O for avt@optimus.ietf.org; Mon, 30 Jun 2003 20:52: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 UAA24631 for ; Mon, 30 Jun 2003 20:52:32 -0400 (EDT) From: yoshihiro.kikuchi@toshiba.co.jp Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19X9Ni-0005jf-00 for avt@ietf.org; Mon, 30 Jun 2003 20:52:26 -0400 Received: from [202.105.135.142] (helo=SZXLD-STONER) by ietf-mx with esmtp (Exim 4.12) id 19X9NE-0005j7-00 for avt@ietf.org; Mon, 30 Jun 2003 20:51:56 -0400 To: Date: Tue, 1 Jul 2003 8:51:59 +0800 Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CSmtpMsgPart123X456_000_00126DEA" Message-Id: Subject: [AVT] Re: Movie 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 multipart message in MIME format --CSmtpMsgPart123X456_000_00126DEA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) Found virus WORM_SOBIG.E in file details.pif (in your_details.zip) The uncleanable file your_details.zip is moved to /etc/iscan/virus/virKKA.OaWSP. --------------------------------------------------------- --CSmtpMsgPart123X456_000_00126DEA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached zip file for details. --CSmtpMsgPart123X456_000_00126DEA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) your_details.zip is removed from here because it contains a virus. --------------------------------------------------------- --CSmtpMsgPart123X456_000_00126DEA-- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt