From rem-conf Sat Jul 01 22:56:05 2000 From rem-conf-request@es.net Sat Jul 01 22:56:03 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 138cSP-0004uf-00; Sat, 1 Jul 2000 22:38:17 -0700 Received: from ip156.atlanta11.ga.pub-ip.psi.net (unknown) [38.30.188.156] by mail1.es.net with smtp (Exim 1.81 #2) id 138cSL-0004sb-00; Sat, 1 Jul 2000 22:38:14 -0700 From: Subject: Check Out the Best Prices for Your Toner Cartridges Date: Sun, 2 Jul 2000 01:39:41 Message-Id: <412.149555.150075@unknown> Reply-To: Whihomr6drts@aol.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list D&J PRINTING CORPORATION 3103 LEXINGTON FARMS DR ALPHARETTA, GA 30004 (770) 619-0716 --LASER, FAX AND COPIER PRINTER TONER CARTRIDGES-- *WE ACCEPT GOVERNMENT, SCHOOL AND UNIVERSITY PURCHASE ORDERS* CHECK OUT OUR NEW CARTRIDGE PRICES: APPLE LASER WRITER PRO 600 OR 16/600 $65 LASER WRITER SELECT 300, 310, 360 $65 LASER WRITER 300, 320 $54 LASER WRITER LS, NT, 2NTX, 2F, 2G AND 2SC $54 LASER WRITER 12/640 $75 HEWLETT PACKARD LASERJET SERIES 2, 3 AND 3D (95A) $49 LASERJET SERIES 2P AND 3P (75A) $54 LASERJET SERIES 3SI AND 4SI (91A) $75 LASERJET SERIES 4L AND 4P $45 LASERJET SERIES 4, 4M, 5, 5M, 4+ (98A) $55 LASERJET SERIES 4000 HIGH YIELD (27X) $95 LASERJET SERIES 4V $90 LASERJET SERIES 5SI, 8000 $95 LASERJET SERIES 5L AND 6L $49 LASERJET SERIES 5P, 5MP, 6P, 6MP $59 LASERJET SERIES 5000 (29A) $125 LASERJET SERIES 1100 (92A) $50 LASERJET SERIES 2100 (96A) $80 LASERJET SERIES 8100 (82X) $135 HEWLETT PACKARD LASERFAX LASERFAX 500, 700, FX1 $57 LASERFAX 5000, 7000, FX2 $57 LASERFAX FX3 $67 LASERFAX FX4 $77 LEXMARK OPTRA 4019, 4029 HIGH YIELD $130 OPTRA R, 4039, 4049 HIGH YIELD $135 OPTRA S, 4059 HIGH YIELD $135 OPTRA E $59 OPTRA N $110 EPSON EPL-7000, 8000 $100 EPL-1000, 1500 $100 CANON LBP-430 $49 LBP-460, 465 $59 LBP-8 II $54 LBP-LX $54 LBP-MX $95 LBP-AX $49 LBP-EX $59 LBP-SX $49 LBP-BX $95 LBP-PX $49 LBP-WX $95 LBP-VX $59 CANON FAX L700 THRU L790 (FX1) $59 CANON FAX L5000 THRU L7000 (FX2) $59 CANON COPIERS PC 3, 6RE, 7, 11 (A30) $69 PC 320 THRU 780 (E40) $85 NEC SERIES 2 LASER MODEL 90, 95 $105 PLEASE NOTE: * WE SHIP UPS GROUND. ADD $6.50 FOR SHIPPING AND HANDLING * WE ACCEPT ALL MAJOR CREDIT CARDS OR "COD" ORDERS. * COD CHECK ORDERS ADD $3.50 TO YOUR SHIPPING COST. * OUR STANDARD MERCHANDISE REFUND POLICY IS NET 30 DAYS. * OUR STANDARD MERCHANDISE REPLACEMENT POLICY IS NET 90 DAYS. * WE DO NOT SELL TO RESELLERS OR BUY FROM DISTRIBUTERS. * WE DO NOT CARRY: BROTHER, MINOLTA, KYOSERA, PANASONIC, XEROX, FUJITSU, OKIDATA OR SHARP PRODUCTS. * WE ALSO DO NOT CARRY: COLOR PRINTER SUPPLIES, DESKJET/INKJET OR BUBBLEJET SUPPLIES. * WE DO NOT BUY FROM OR SELL TO RECYCLERS OR REMANUFACTURERS. -PLACE YOUR ORDER AS FOLLOWS- 1) BY PHONE (770) 619-0716 2) BY MAIL: D AND J PRINTING CORPORATION 3103 LEXINGTON FARMS DR ALPHARETTA, GA 30004 INCLUDE THE FOLLOWING INFORMATION WHEN YOU PLACE YOUR ORDER: 1) YOUR PHONE NUMBER 2) COMPANY NAME 3) SHIPPING ADDRESS 4) CONTACT NAME 5) ITEMS NEEDED WITH QUANTITIES 6) METHOD OF PAYMENT (COD OR CREDIT CARD) 7) CREDIT CARD NUMBER WITH EXPIRATION DATE **** IF YOU ARE ORDERING BY PURCHASE ORDER, PLEASE INCLUDE A SEPARATE BILLING ADDRESS AND SHIPPING ADDRESS WHEN NEEDED. From rem-conf Sun Jul 02 06:45:53 2000 From rem-conf-request@es.net Sun Jul 02 06:45:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 138k0j-0003Py-00; Sun, 2 Jul 2000 06:42:13 -0700 Received: from net128-007.mclink.it (mail1.mclink.it) [195.110.128.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 138k0i-0003Po-00; Sun, 2 Jul 2000 06:42:12 -0700 Received: from net144-226.mclink.it (net144-226.mclink.it [195.110.144.226]) by mail1.mclink.it (8.9.1/8.9.0) with ESMTP id PAA19167 for ; Sun, 2 Jul 2000 15:41:39 +0200 (CEST) Date: Sun, 2 Jul 2000 15:40:31 +0200 From: Massimo Fubini X-Mailer: The Bat! (v1.44) UNREG / CD5BF9353B3B7091 Reply-To: Massimo Fubini X-Priority: 3 (Normal) Message-ID: <179106241557.20000702154031@studenti.ing.uniroma1.it> To: rem-conf@es.net Subject: PSQM (P.861), PSQM+, PAMS Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I would like to know if there are free, or not too expensive, implementation of an algorithms to have an objective measurement for voice quality. It is for a research, and non commercial activity! I was thinking about PSQM, PSQM+ or PAMS. Do you know if the ITU-T P.861 (PSQM) standard also contain an implementation of the algorithms (on the itu web site it is written it contains a floppy disk, but I can't understand what is in it) Best regards, Massimo Fubini mailto:mfubini@studenti.ing.uniroma1.it University of Rome La Sapienza - Netlab CNR From rem-conf Sun Jul 02 06:45:53 2000 From rem-conf-request@es.net Sun Jul 02 06:45:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 138k0c-0003Pm-00; Sun, 2 Jul 2000 06:42:06 -0700 Received: from net128-007.mclink.it (mail1.mclink.it) [195.110.128.7] by mail1.es.net with esmtp (Exim 1.81 #2) id 138k0a-0003Pc-00; Sun, 2 Jul 2000 06:42:04 -0700 Received: from net144-226.mclink.it (net144-226.mclink.it [195.110.144.226]) by mail1.mclink.it (8.9.1/8.9.0) with ESMTP id PAA19149 for ; Sun, 2 Jul 2000 15:41:30 +0200 (CEST) Date: Sun, 2 Jul 2000 15:27:20 +0200 From: Massimo Fubini X-Mailer: The Bat! (v1.44) UNREG / CD5BF9353B3B7091 Reply-To: Massimo Fubini X-Priority: 3 (Normal) Message-ID: <155105450209.20000702152720@studenti.ing.uniroma1.it> To: rem-conf@es.net Subject: VoIP & packet loss Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm working on the influence of network condition on the perceived quality of a VoIP "telephone" call. I would like to know if there are studies on how the distribution of packet loss (not only the average packet loss, but the complete distribution ) influence the perceived quality of a VoIP call. Best regards, Massimo Fubini mailto:mfubini@studenti.ing.uniroma1.it University of Rome La Sapienza - Netlab CNR From rem-conf Sun Jul 02 20:15:34 2000 From rem-conf-request@es.net Sun Jul 02 20:15:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 138wdy-0005LA-00; Sun, 2 Jul 2000 20:11:34 -0700 Received: from mail0.yrp.nttdocomo.co.jp [202.245.184.18] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 138wdw-0005L0-00; Sun, 2 Jul 2000 20:11:32 -0700 Received: from spg.yrp.nttdocomo.co.jp (spg.yrp.nttdocomo.co.jp [172.21.48.130]) by mail0.yrp.nttdocomo.co.jp (8.9.0/YRPHUB0-8819980304) with ESMTP id MAA18676; Mon, 3 Jul 2000 12:11:17 +0900 (JST) Message-Id: <4.2.0.58.J.20000703120946.00cfb2a0@spg.yrp.nttdocomo.co.jp> X-Sender: kawahara@spg.yrp.nttdocomo.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Date: Mon, 03 Jul 2000 12:11:13 +0900 To: "Yoshihiro Kikuchi" , "Toshiro Kawahara" From: Toshiro Kawahara Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format Cc: "4on2andIP-sys" <4on2andIP-sys@advent.ee.columbia.edu>, "IETF AVT" , "Yoshihiro Kikuchi" In-Reply-To: <007101bfe1ab$780df0e0$4f51c485@eel.rdc.toshiba.co.jp> References: <85077463E51D6A498C453073E16779400BC568@clu2k02a.cselt.it> <3959C561.6A7BCE42@irisa.fr> <4.2.0.58.J.20000629131321.00d12250@spg.yrp.nttdocomo.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Kikuchi-san and all, Thank you for your consideration on our request. Yes! Your modification below meet our request, and please apply them into the draft. Regards, Toshiro At 18:21 00/06/29 +0900, Yoshihiro Kikuchi wrote: >Dear Kawahara-san and all, > >Thank you very much for your comment. > >I agree with Kawahara-san that the interworking between the systems is the >matter to be covered in this Internet-Draft. Does the following minor >revision on section 5 meet your request? > > >- In section 5.1 "MIME type registration for MPEG-4 Visual", add the >following parameter to "Optional parameters": > >config: A hexadecimal representation of an octet string that expresses the >MPEG-4 Visual configuration information, as defined in subclause 6.2.1 Start >codes of ISO/IEC14496-2[2][4][9]. The configuration information is mapped >onto the octet string in an MSB-first basis. The first bit of the >configuration information SHALL be located at the MSB of the first octet. >The >configuration information indicated by this parameter SHALL be the same as >the configuration information in the corresponding MPEG-4 Visual stream, >except for first_half_vbv_occupancy and latter_half_vbv_occupancy which may >vary in the repeated configuration information inside an MPEG-4 Visual >stream (See 6.2.1 Start codes of ISO/IEC14496-2). > >- In section 5.2 "SDP usage of MPEG-4 Visual", replace the description for >"a=fmtp" parameter with the following: > >o The optional parameter "profile-level-id" and "config" MAY go >in the "a=fmtp" line to indicate the coder capability and configuration. >These parameters are expressed as a MIME media type string, in the form of >as a semicolon separated list of parameter=value pairs. > > >Best regards, >Yoshihiro > >----- Original Message ----- >From: Toshiro Kawahara >To: Yoshihiro Kikuchi ; Christine Guillemot > >Cc: 4on2andIP-sys <4on2andIP-sys@advent.ee.columbia.edu>; IETF AVT >; Yoshihiro Kikuchi >Sent: Thursday, June 29, 2000 1:21 PM >Subject: Re: Updated I/D for MPEG-4 Audio/Visual RTP payload format > > >> Kikuchi-san and all, >> >> I have an comment on the MIME parameters for MPEG-4 visual, or a >> request to add another important parameter to them. >> >> That is decoderConfiguraitonInformation, which indicates the >> configuration of the transmitted bitstream (i.e., VO/VOL headers). >> H.245 have this field for the use of MPEG-4 Visual, and thus >> considering interworking with systems using H.245 as H.323 or H.324, >> this field should also be supported by SIP with MIME parameters. >> >> Regards, >> Toshiro >> --- >> Toshiro Kawahara >> NTT DoCoMo, Inc. >> (We have changed our corporate name from April!) >> Multimedia Laboratories, Multimedia Signal Processing Laboratory >> TEL: +81 468 40 3518 FAX: +81 468 40 3788 >> $B2O86(B $BIRO/(B (in Japanese) >> > > --- Toshiro Kawahara NTT DoCoMo, Inc. (We have changed our corporate name from April!) Multimedia Laboratories, Multimedia Signal Processing Laboratory TEL: +81 468 40 3518 FAX: +81 468 40 3788 $B2O86(B $BIRO/(B (in Japanese) From rem-conf Sun Jul 02 21:50:39 2000 From rem-conf-request@es.net Sun Jul 02 21:50:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 138y9k-0007Ad-00; Sun, 2 Jul 2000 21:48:28 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 138y9j-0007AT-00; Sun, 2 Jul 2000 21:48:27 -0700 Received: from purple.east.isi.edu (purple.east.isi.edu [38.245.76.9]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id AAA09039; Mon, 3 Jul 2000 00:48:41 -0400 (EDT) Received: from purple.east.isi.edu (localhost [127.0.0.1]) by purple.east.isi.edu (8.9.3/8.8.7) with ESMTP id XAA30571; Sun, 2 Jul 2000 23:38:17 +0100 Message-Id: <200007022238.XAA30571@purple.east.isi.edu> To: rem-conf@es.net Subject: Working group last call: DV audio/video cc: casner@acm.org Date: Sun, 02 Jul 2000 18:38:17 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is to announce a two week working group last call on the RTP payload formats for DV audio and video: draft-ietf-avt-dv-audio-02.txt draft-ietf-avt-dv-video-03.txt If no substantive comments are received by Friday 14th July these drafts will be submitted to the IESG for publication as proposed standard RFCs. Any comments should be sent to the rem-conf@es.net mailing list. Thanks, Colin From rem-conf Mon Jul 03 03:09:40 2000 From rem-conf-request@es.net Mon Jul 03 03:09:39 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13932R-0004KW-00; Mon, 3 Jul 2000 03:01:15 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13932P-0004K5-00; Mon, 3 Jul 2000 03:01:13 -0700 Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 3 Jul 2000 11:00:36 +0100 From: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: Massimo Fubini cc: rem-conf@es.net Subject: Re: PSQM (P.861), PSQM+, PAMS In-reply-to: Your message of "Sun, 02 Jul 2000 15:40:31 +0200." <179106241557.20000702154031@studenti.ing.uniroma1.it> Date: Mon, 03 Jul 2000 11:00:34 +0100 Message-ID: <692.962618434@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <179106241557.20000702154031@studenti.ing.uniroma1.it>Massimo Fubini writes: > I would like to know if there are free, or not too expensive, > implementation of an algorithms to have an objective measurement for > voice quality. It is for a research, and non commercial activity! > > I was thinking about PSQM, PSQM+ or PAMS. > > Do you know if the ITU-T P.861 (PSQM) standard also contain an implementation > of the algorithms (on the itu web site it is written it contains a > floppy disk, but I can't understand what is in it) No, it doesn't. The P.861 (02/98) disk is labelled as 'C implementation of ...', but only contains reference vectors. My experience from implementing P.861 is that it contains a couple of vagueries that make it difficult to implement. I was able to get the short-term verification tests work, but not the longer term ones. I failed to connect with anyone in the ITU capable of providing clarification. I have an implementation of Stephen Voran's MNB algorithm http://www.cs.ucl.ac.uk/staff/O.Hodson/misc/mnb-0.1e.tar.gz. This algorithm, it's callibration, and performance, are described in two papers by Voran in IEEE Trans. speech and audio processing, Vol7, No4, July, 1999. You can modify this source to form P861-appendix2-mnb without too much effort. The implemention builds cleanly for Solaris, FreeBSD, Irix, Linux, porting to other platforms should be trivial. Commercially interested parties should contact Stephen Voran if they want to use or implement this algorithm. Wonho Yang, Majid Benbouchta and Rober Yantorno have an algorithm Modified Bark Spectal Distortion (MBSD) and will provide source code if you ask (wonho@astro.temple.edu,ryantorn@nimbus.temple.edu). The algorithm is described in ICASSP98, Vol1, pp541-544, Seattle, 1998. A problem in most of these algorithm's is thresholding. They involve a thresholding step of the reference and modified signal. Only frames that have energy above the threshold's are included in the final score computation. This is a problem if you have packet losses and are using silence substitution. Yhe silence substituted frames do not get included in the calculation, but are perceptually noticeable. An algorithm that takes this into account is described in 'Advances in objective estimation of perceived speech quality', Stephen Voran, Proc. 1999 IEEE Workshop on Speech Coding for Telecommunications, Porvoo, Finland, June 1999. Does anybody know the situation with PAMS? I used to be sponsored by BT, but they weren't interested in making it available without a fee. cheers - Orion Orion Hodson Research Student =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Networked Multimedia Research Group Tel: ++(0)171 419 3704 Department of Computer Science Fax: ++(0)171 419 1397 University College London, Gower Street, London, WC1E 6BT, UK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "In the fight between you and the world, back the world." --Frank Zappa From rem-conf Mon Jul 03 03:21:35 2000 From rem-conf-request@es.net Mon Jul 03 03:21:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1393LC-0005Pa-00; Mon, 3 Jul 2000 03:20:38 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 1393LA-0005PL-00; Mon, 3 Jul 2000 03:20:36 -0700 Received: from scary.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 3 Jul 2000 11:20:31 +0100 From: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: Massimo Fubini cc: rem-conf@es.net Subject: Re: VoIP & packet loss In-reply-to: Your message of "Sun, 02 Jul 2000 15:27:20 +0200." <155105450209.20000702152720@studenti.ing.uniroma1.it> Date: Mon, 03 Jul 2000 11:20:32 +0100 Message-ID: <796.962619632@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <155105450209.20000702152720@studenti.ing.uniroma1.it>Massimo Fubini writes: > I'm working on the influence of network condition on the perceived > quality of a VoIP "telephone" call. > > I would like to know if there are studies on how the distribution of > packet loss (not only the average packet loss, but the complete > distribution ) influence the perceived quality of a VoIP call. > Checkout Henning Schulzrinne's netbib http://www.cs.columbia.edu/~hgs/netbib/ Some references get started... @InProceedings{bolot93, author = {Jean-Chrysostome Bolot}, title = {End-to-End Packet Delay and Loss Behaviour in the Internet}, booktitle = {Proceedings of {ACM SIGCOMM'93}}, year = 1993, month = {September}, pages = {289-298} } @INPROCEEDINGS{Bolo9603:Control, AUTHOR="Bolot, Jean-Chrysostome and Garcia, Andres Vega", TITLE="Control Mechanisms for Packet Audio in the {Internet}", BOOKTITLE=infocom, ADDRESS="San Fransisco, California", DAY="24--28", MONTH=mar, YEAR=1996 } @InProceedings{Bore98:Loss, author = {M. S. Borella and D. Swider and S. Uludag and and G. B. Brewster}, title = {Internet Packet Loss: Measurement and Implications for End-to-End {QoS}}, booktitle = {Proceedings, International Conference on Parallel Processing}, year = 1998, month = {August} } @INPROCEEDINGS{Yajn9903:Measurement, AUTHOR="Yajnik, Maya and Moon, Sue and Kurose, Jim and Towsley, Don", TITLE="Measurement and Modelling of the Temporal Dependence in Packet Loss", BOOKTITLE=infocom, ADDRESS="New York", DAYS="23--25", MONTH=mar, YEAR=1999 } M. S. Borella, "Measurement and Interpretation of Internet Packet Loss," Journal of Communications and Networking, Jun. 2000. (http://home.xnet.com/~cathmike/MSB/pubs/jcnloss.ps) Related stuff Vern Paxson's measurements: http://www.aciri.org/vern/papers.html Chapter on Mbone Performance @PhdThesis{Hand9708:Thesis, author = {Mark Handley}, title = {On Scaleable Internet Multimedia Conferencing Systems}, school = {Department of Computer Science}, year = 1997, address = {University College London}, type = {Ph.D.} } Kind Regards - Orion. From rem-conf Mon Jul 03 05:39:14 2000 From rem-conf-request@es.net Mon Jul 03 05:39:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1395Sx-0001HK-00; Mon, 3 Jul 2000 05:36:47 -0700 Received: from nw-smtp.wineasy.se [195.42.198.118] (postfix) by mail1.es.net with esmtp (Exim 1.81 #2) id 1395Sv-0001H8-00; Mon, 3 Jul 2000 05:36:45 -0700 Received: from prodigy (unknown [195.42.214.141]) by nw-smtp.wineasy.se (Postfix) with SMTP id F1CEB400C; Mon, 3 Jul 2000 14:36:37 +0200 (CEST) From: "Alan Duric" To: , "Massimo Fubini" Cc: Subject: RE: PSQM (P.861), PSQM+, PAMS Date: Mon, 3 Jul 2000 14:35:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <692.962618434@cs.ucl.ac.uk> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, In addition to very descriptive answer that Orion provided, I would mention that You should be awaiting a bit until ITU SG 12 releases P.862 (which is basically ready at this point of time). P.862 will replace completely P.861 and it should handle large delays and jitter in adequate way (what You can not say at all for P.861) and it is tailored for VoIP. Unfortunately PAMS is not available in any other way beside commercial and I did not heard from BT guys that they are planning to do so. Regards, Alan Duric Global IP Sound www.globalipsound.com -----Original Message----- From: O.Hodson@cs.ucl.ac.uk [mailto:O.Hodson@cs.ucl.ac.uk] Sent: Monday, July 03, 2000 12:01 PM To: Massimo Fubini Cc: rem-conf@es.net Subject: Re: PSQM (P.861), PSQM+, PAMS <179106241557.20000702154031@studenti.ing.uniroma1.it>Massimo Fubini writes: > I would like to know if there are free, or not too expensive, > implementation of an algorithms to have an objective measurement for > voice quality. It is for a research, and non commercial activity! > > I was thinking about PSQM, PSQM+ or PAMS. > > Do you know if the ITU-T P.861 (PSQM) standard also contain an implementation > of the algorithms (on the itu web site it is written it contains a > floppy disk, but I can't understand what is in it) No, it doesn't. The P.861 (02/98) disk is labelled as 'C implementation of ...', but only contains reference vectors. My experience from implementing P.861 is that it contains a couple of vagueries that make it difficult to implement. I was able to get the short-term verification tests work, but not the longer term ones. I failed to connect with anyone in the ITU capable of providing clarification. I have an implementation of Stephen Voran's MNB algorithm http://www.cs.ucl.ac.uk/staff/O.Hodson/misc/mnb-0.1e.tar.gz. This algorithm, it's callibration, and performance, are described in two papers by Voran in IEEE Trans. speech and audio processing, Vol7, No4, July, 1999. You can modify this source to form P861-appendix2-mnb without too much effort. The implemention builds cleanly for Solaris, FreeBSD, Irix, Linux, porting to other platforms should be trivial. Commercially interested parties should contact Stephen Voran if they want to use or implement this algorithm. Wonho Yang, Majid Benbouchta and Rober Yantorno have an algorithm Modified Bark Spectal Distortion (MBSD) and will provide source code if you ask (wonho@astro.temple.edu,ryantorn@nimbus.temple.edu). The algorithm is described in ICASSP98, Vol1, pp541-544, Seattle, 1998. A problem in most of these algorithm's is thresholding. They involve a thresholding step of the reference and modified signal. Only frames that have energy above the threshold's are included in the final score computation. This is a problem if you have packet losses and are using silence substitution. Yhe silence substituted frames do not get included in the calculation, but are perceptually noticeable. An algorithm that takes this into account is described in 'Advances in objective estimation of perceived speech quality', Stephen Voran, Proc. 1999 IEEE Workshop on Speech Coding for Telecommunications, Porvoo, Finland, June 1999. Does anybody know the situation with PAMS? I used to be sponsored by BT, but they weren't interested in making it available without a fee. cheers - Orion Orion Hodson Research Student =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Networked Multimedia Research Group Tel: ++(0)171 419 3704 Department of Computer Science Fax: ++(0)171 419 1397 University College London, Gower Street, London, WC1E 6BT, UK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "In the fight between you and the world, back the world." --Frank Zappa From rem-conf Mon Jul 03 05:53:14 2000 From rem-conf-request@es.net Mon Jul 03 05:53:13 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1395iJ-0002E8-00; Mon, 3 Jul 2000 05:52:39 -0700 Received: from mailhub.fokus.gmd.de [193.174.154.14] by mail1.es.net with esmtp (Exim 1.81 #2) id 1395iH-0002Dy-00; Mon, 3 Jul 2000 05:52:38 -0700 Received: from fokus.gmd.de (gromit [193.175.132.43]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA27239; Mon, 3 Jul 2000 14:52:20 +0200 (MET DST) Sender: sanneck@fokus.gmd.de Message-ID: <39608C83.7ABB8327@fokus.gmd.de> Date: Mon, 03 Jul 2000 14:52:19 +0200 From: Henning Sanneck Organization: GMD Fokus X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Massimo Fubini CC: Orion Hodson , rem-conf@es.net Subject: Re: VoIP & packet loss References: <796.962619632@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Orion Hodson wrote: > > <155105450209.20000702152720@studenti.ing.uniroma1.it>Massimo Fubini writes: > > I'm working on the influence of network condition on the perceived > > quality of a VoIP "telephone" call. > > > > I would like to know if there are studies on how the distribution of > > packet loss (not only the average packet loss, but the complete > > distribution ) influence the perceived quality of a VoIP call. > > I'd like to add two useful references on loss metrics to Orion's list: @TECHREPORT{JIA99, AUTHOR = {W. Jiang and H. Schulzrinne}, TITLE = {QoS Measurement of Internet Real-Time Multimedia Services}, INSTITUTION = {Columbia University}, YEAR = 1999, TYPE = {{Technical} {Report}}, NUMBER = {CUCS-015-99}, MONTH = {December} } @inproceedings{MIY98, AUTHOR = {T. Miyata and H. Fukuda and S. Ono}, TITLE = {New Network {QoS} measures for {FEC}-based Audio Applications on the {Internet}}, BOOKTITLE = {Proceedings IEEE IPCCC 1998}, YEAR = 1998, PAGES = {355-362}, ADDRESS = {Tempe/Phoenix, AZ, USA}, MONTH = {February} } In a recent paper [Sann0001:Speech-FEC] we have characterized the behaviour of a particular speech codec (G.729) under packet loss in terms of the packet-level metrics of [bolot93] (Gilbert model) linked to objective speech quality metrics (P.861A and EMBSD). While the decoder is relatively insensitive to bursty losses (as described by the conditional loss probability of the Gilbert model), the perceived quality breaks down for losses within unvoiced/voiced transitions within the speech signal. We have concluded that the effect of loss distribution on perceived quality is significant, it is codec-dependent and it cannot necessarily be fully described building just on simple metrics like those of the Gilbert model. @inproceedings{Sann0001:Speech-FEC, AUTHOR = {H. Sanneck and N. Le}, TITLE = {Speech Property-Based {FEC} for {Internet} {Telephony} Applications}, BOOKTITLE = {Proceedings of the SPIE/ACM SIGMM Multimedia Computing and Networking Conference (MMCN)}, YEAR = 2000, ADDRESS = {San Jose, CA}, PAGES = {38-51}, MONTH = {January}, NOTE = {ftp://ftp.fokus.gmd.de/pub/glone/papers/Sann0001:Speech-FEC.ps.gz} } > > Checkout Henning Schulzrinne's netbib http://www.cs.columbia.edu/~hgs/netbib/ > > Some references get started... > > @InProceedings{bolot93, > author = {Jean-Chrysostome Bolot}, > title = {End-to-End Packet Delay and Loss Behaviour in the Internet}, > booktitle = {Proceedings of {ACM SIGCOMM'93}}, > year = 1993, > month = {September}, > pages = {289-298} > } Regards -- Henning ________________________________________________________________________ Henning Sanneck Research Institute for Open Communication Systems GMD FOKUS, Kaiserin-Augusta-Allee 31, D-10589 Berlin, Germany Phone : ++49 / (0)30 / 34 63 - 71 75 Fax : ++49 / (0)30 / 34 63 - 81 75 e-mail : sanneck@fokus.gmd.de WWW : http://www.fokus.gmd.de/usr/sanneck ________________________________________________________________________ From rem-conf Mon Jul 03 06:15:39 2000 From rem-conf-request@es.net Mon Jul 03 06:15:38 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 139637-0003VW-00; Mon, 3 Jul 2000 06:14:09 -0700 Received: from gollum.axion.bt.co.uk [132.146.17.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 139635-0003TY-00; Mon, 3 Jul 2000 06:14:07 -0700 Received: from cbtlipnt01.btlabs.bt.co.uk by gollum (local) with ESMTP; Mon, 3 Jul 2000 14:14:02 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id <3GJL0D8C>; Mon, 3 Jul 2000 14:12:48 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB20516AFFB@mbtlipnt02.btlabs.bt.co.uk> From: antony.rix@bt.com To: rem-conf@es.net Cc: mfubini@studenti.ing.uniroma1.it, O.Hodson@cs.ucl.ac.uk Subject: Re: PSQM (P.861), PSQM+, PAMS Date: Mon, 3 Jul 2000 14:11:08 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Forgive me for joining this discussion, but as the developer of PAMS and co-developer of PESQ (P.862) I hope I can comment. I don't normally read this list, so please cc me in on any further discussions on this thread (antony.rix@bt.com). Beware of using PSQM or MNB straight from P.861. These algorithms don't include time alignment, and PSQM does not include level alignment. Neither PSQM nor MNB take account of filtering that may occur in many systems/networks. For these reasons they are very inaccurate in many testing applications. To fix these problems a much more capable algorithm, PESQ (perceptual evaluation of speech quality) is expected to become a new ITU recommendation P.862 some time early in 2001, at which point P.861 will be withdrawn. PESQ is the result of a long competition and collaboration in the ITU, and has been found to perform well at predicting subjective quality in a very wide range of applications. It is also much better than PSQM and MNB, even for working with speech codecs that have none of the time and level alignment or filtering issues. Like PESQ, PAMS includes time and level alignment and (from release 3) ability to deal with filtering, and is suitable for use with a wide range of telephony codecs and networks. PAMS has been commercially available since 1998 and is now in wide use in areas such as VoIP testing. Unfortunately, as P.862 is only a draft ITU recommendation, PESQ is not yet publicly available. The source code is available to ITU members only, and even then under a restrictive license. So for PESQ I am afraid that you will have to wait some months to obtain the first commercial implementations, likely to be available for purchase in Q4 of this year, or until about February 2001 before you can buy the ITU recommendation (assuming it is approved), which will have C source code attached. If you can't wait this long, I can only suggest that you buy PAMS from one of the companies listed on my website: http://www.labs.bt.com/people/rixa/pams/ . For references on PAMS and PESQ, see my paper list: http://www.labs.bt.com/people/rixa/awr_cv.htm#papers - e-mail me if you would like a copy of any of these papers. Regards, Antony Antony Rix antony.rix@bt.com B54/86, Adastral Park, Ipswich IP5 3RE, UK Tel. +44 (01473) 644 339 http://www.labs.bt.com/people/rixa/ From rem-conf Mon Jul 03 06:57:37 2000 From rem-conf-request@es.net Mon Jul 03 06:57:36 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 1396gU-00053a-00; Mon, 3 Jul 2000 06:54:50 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 1396gT-00053H-00; Mon, 3 Jul 2000 06:54:49 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA19997; Mon, 3 Jul 2000 09:54:47 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA08339; Mon, 3 Jul 2000 09:54:45 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <39609B25.6074A792@cs.columbia.edu> Date: Mon, 03 Jul 2000 09:54:45 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Orion Hodson CC: Massimo Fubini , rem-conf@es.net Subject: Re: PSQM (P.861), PSQM+, PAMS References: <692.962618434@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list See http://www.cs.columbia.edu/~hgs/rtp/quality.html for a listing of a number of references. The paper by Voran, for example, can be found at the http://www.its.bldrdoc.gov/home/programs/audio/audio.htm web site. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Mon Jul 03 10:43:56 2000 From rem-conf-request@es.net Mon Jul 03 10:43:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 139ACy-0002wF-00; Mon, 3 Jul 2000 10:40:36 -0700 Received: from www.fmmo.ca (ns.fmmo.ca) [207.253.160.156] (fm-listproc) by mail1.es.net with esmtp (Exim 1.81 #2) id 139ACw-0002w2-00; Mon, 3 Jul 2000 10:40:34 -0700 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id OAA09990; Mon, 3 Jul 2000 14:09:38 -0400 Date: Mon, 3 Jul 2000 14:09:36 -0400 (EDT) From: fm-listproc To: SVR Anand cc: Colin Perkins , rem-conf@es.net Subject: Re: RTP and CTI In-Reply-To: <200006081758.XAA23444@ece.iisc.ernet.in> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > It depends on your application to a large degree. The implementations I > > know are PC-based, handling a small number of streams. If your system has > > to process a very large number of streams, the trade-off is somewhat > > different. > > Speaking as an ex-designer of soundboards, my personal recollection is that getting data to/from the host across the PCI bus accounts for more latency than processing RTP. When Microsoft went from ACM to DirectSound, the total delay to Netmeeting dropped from 120+ ms to 30 ms. Since PCI is not a synchronous bus, there cannot be any guarantee when there is contention for the PCI BUS. RTP'ing an audio stream on the fast processors of today creates very little delay. I'd worry about a good CODEC driver first. Now, if you want to make a custom ASIC which does everything in hardware, nothing is stopping you. Personally, considering that the RTP debate is far from over (who needs RTP overhead for point to point comms ?), I would not spend any time implementing RTP in hardware. -=Francois=- From rem-conf Mon Jul 03 17:25:12 2000 From rem-conf-request@es.net Mon Jul 03 17:25:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 139GQr-0004NK-00; Mon, 3 Jul 2000 17:19:21 -0700 Received: from tnt.isi.edu [128.9.128.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 139GQq-0004Mm-00; Mon, 3 Jul 2000 17:19:20 -0700 Received: (from touch@localhost) by tnt.isi.edu (8.8.7/8.8.6) id RAA28861 for rem-conf@es.net; Mon, 3 Jul 2000 17:19:16 -0700 (PDT) Date: Mon, 3 Jul 2000 17:19:16 -0700 (PDT) From: Joe Touch Message-Id: <200007040019.RAA28861@tnt.isi.edu> To: rem-conf@es.net Subject: reminder - Sigcomm 2000 student poster application deadline approaching X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Applications for the Student Poster Session - Work-in-progress at Sigcomm 2000 is July 12, 2000. Please see the website below for further information on how to submit a proposal. --------------------------------------------------------------- Call for Papers ACM SIGCOMM 2000 Conference August 28 - September 1, 2000 Grand Hotel, Stockholm, Sweden http://www.acm.org/sigcomm/sigcomm2000 sigcomm2000-info@acm.org >> Student Poster Session - Work-in-progress applications: July 12, 2000 Student Poster Session - Work-in-progress This year, the SIGCOMM 2000 conference will sponsor a poster session aimed at showcasing the "work-in-progess" of students attending the conference. The goal of the poster session is to present students' work in progress and provide an opportunity for informal discussion of the work with the students within the conference venue. Authors should submit a 500 word text file describing the research to be presented in the poster, as well as a draft of the poster material in pdf or postscript format. Send both of the above by July 12, 2000 to sigcomm2000-pcchairs@cs.umass.edu Notification details, further specifics on poster formats, and eligibility information are available at the SIGCOMM 2000 website. Additional information on SIGCOMM 2000 Keynote Address: The SIGCOMM Award is given annually to a person whose career and technical achievements demonstrate a long-term commitment to the field of data commu-nications. ACM SIGCOMM is pleased to announce that the 2000 SIGCOMM Award is being given to Prof. Andre' Danthine of the University of Liege, Belgium. Prof. Danthine will receive the award and give the conference keynote address, entitled "Mutual Cloning Between Network Paradigms," in the opening session on Wednesday. General Co-Chairs Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se) Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se) Program Co-Chairs Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com) Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu) Publicity Chair Joe Touch, USC/ISI, USA (touch@isi.edu) Tutorials Chair Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se) From rem-conf Tue Jul 04 19:24:24 2000 From rem-conf-request@es.net Tue Jul 04 19:24:24 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 139ecY-0005Q3-00; Tue, 4 Jul 2000 19:09:02 -0700 Received: from icsl.icsl.ucla.edu [128.97.90.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 139ecX-0005Pt-00; Tue, 4 Jul 2000 19:09:01 -0700 Received: from scope (Pc119.ICSL.UCLA.EDU [128.97.90.119]) by icsl.icsl.ucla.edu (8.8.8+Sun/8.8.8(ICSL0003)) with SMTP id TAA10322; Tue, 4 Jul 2000 19:08:59 -0700 (PDT) From: "Adam Li" To: "Ietf-Avt" , Cc: "Jeong-Hoon Park" , "John D. Villasenor" , "D.-S. Park" , Subject: draft-li-avt-ulp-00.txt Date: Tue, 4 Jul 2000 19:07:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear I-D manager and AVT group experts, We are submitting an Internet Draft for discussion in the AVT group. Title : An RTP Payload Format for Generic FEC with Uneven Level Protection Authors : A. Li, F. Liu, J. Villasenor, J.H. Park, D.S. Park Filename : draft-li-avt-ulp-00.txt This document specifies a payload format for generic forward error correction to achieve uneven level protection (ULP) of media encapsulated in RTP. The payload format allows end systems to transmit using arbitrary protection length and levels, in additional to using arbitrary block lengths. This ULP scheme is capable of achieving efficient channel usage for protection, which still maintaining the media independent generality and compatibility. This Internet Draft is available by anonymous FTP from ftp://newt.icsl.ucla.edu/pub/ULP/draft-li-avt-ulp-00.txt. Your comments by email are greatly appreciated. We are looking forward to discussing with you at Pittsburg. Adam H. Li ---------- Adam H. Li Image Communication Lab (310) 825-5178 (Lab) University of California, Los Angeles (310) 825-7928 (Fax) From rem-conf Wed Jul 05 14:03:57 2000 From rem-conf-request@es.net Wed Jul 05 14:03:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 139wDE-0001q4-00; Wed, 5 Jul 2000 13:56:04 -0700 Received: from nat131.none.net (doce.paris.none.net) [212.129.0.131] by mail1.es.net with esmtp (Exim 1.81 #2) id 139wDC-0001ny-00; Wed, 5 Jul 2000 13:56:02 -0700 Received: from ppro ([212.129.26.133]) by doce.paris.none.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20000705200913.KFFK29589.doce.paris.none.net@ppro>; Wed, 5 Jul 2000 22:09:13 +0200 Message-ID: <001e01bfe6bc$bff99bf0$01646b83@ppro> From: "Webmaster DeLaMirandole" To: Subject: =?iso-8859-1?Q?Enqu=EAte_nationale_sur_les_pratiques_de_recherche_documen?= =?iso-8859-1?Q?taire?= Date: Wed, 5 Jul 2000 22:05:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2014.211 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Cher collègue du CNRS, Delamirandole.org a pour objet de constituer un portail dédié au chercheur scientifique. Dans ce but, Delamirandole effectue une enquête nationale auprès des praticiens de la recherche, toutes disciplines confondues, afin d'estimer les pratiques et surtout les besoins des chercheurs en matière d'accès à l'information à caractère scientifique. C'est pour cette raison que nous vous adressons ce message. Ce questionnaire vise à connaître le comportement du chercheur et à étudier l'intégration d'Internet dans son activité de recherche. L'administration de ce questionnaire ne dure pas plus de quelques minutes. Les résultats de cette enquête, auxquels vous aurez accès, peuvent contribuer à améliorer substantiellement la qualité de la transmission du savoir scientifique. Le questionnaire d'enquête se trouve en ligne à l'adresse suivante : www.delamirandole.org Il vous suffit de cliquer sur ce lien pour répondre automatiquement et anonymement aux questions. Si vous êtes responsable d'un laboratoire, webmaster d'un groupe de chercheurs ou détenteur d'une liste de diffusion à caractère scientifique, nous vous remercions par avance de bien vouloir diffuser le plus largement possible ce message. La valeur de notre enquête dépend de notre capacité de réaction et de votre degré d'implication. En espérant que notre sollicitation trouve un écho favorable auprès de vous, veuillez accepter l'expression de nos sentiments les plus cordiaux. From rem-conf Thu Jul 06 01:05:10 2000 From rem-conf-request@es.net Thu Jul 06 01:05:09 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13A6OR-0007DX-00; Thu, 6 Jul 2000 00:48:19 -0700 Received: from (ns1.alfanumeric.com.ni) [63.80.132.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13A6OM-0007CL-00; Thu, 6 Jul 2000 00:48:15 -0700 Received: from [158.252.127.207] by ns1.alfanumeric.com.ni (Post.Office MTA v3.5.3 release 223 ID# 583-63040U3000L300S0V35) with SMTP id ni; Thu, 6 Jul 2000 01:48:01 -0600 Message-ID: <00006ca1284a$00005e24$00001690@> To: From: credwwtuthill@earthlink.net Subject: fix your credit From Home... Date: Thu, 06 Jul 2000 03:35:16 -0400 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: credwwtuthill@earthlink.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Credit Repair New Credit File - A totally new approach! Order Your Manual Today! Click here http://www.sites4free.net/members/~creditwizard Credit Repair New Credit File - A totally new approach! From rem-conf Thu Jul 06 18:40:10 2000 From rem-conf-request@es.net Thu Jul 06 18:40:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13AN0Y-0004Ow-00; Thu, 6 Jul 2000 18:32:46 -0700 Received: from acsys.anu.edu.au [150.203.20.41] by mail1.es.net with esmtp (Exim 1.81 #2) id 13AN0W-0004Om-00; Thu, 6 Jul 2000 18:32:45 -0700 Received: from accordion (accordion.anu.edu.au [150.203.20.58]) by acsys.anu.edu.au (8.9.3/8.9.3) with SMTP id LAA21718 for ; Fri, 7 Jul 2000 11:32:41 +1000 (EST) Message-Id: <3.0.32.20000707113216.01147e20@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 07 Jul 2000 11:32:17 +1000 To: rem-conf@es.net From: Markus Buchhorn Subject: sap specs and implementations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list G'day All I've just been working on a (perl) sap listener and decoder, and following the latest sap-v2 (-06) draft. This has led to a couple of questions :-) Firstly - what other sap announcers are out there? I can see plenty of versions of sdr sending sapv0 and sapv1/2 packets, and I think also Peter's mstar stuff, but no others. I'm looking for some to test my decoder against, and also test the authentication parts (which sdr doesn't appear to let me get at). (At the same time what listeners are there? I'm also writing a sap announcer, so need somebody else to check against.) Second - does *anybody* actually use the msg id hash field as they "SHOULD" (and also not set it to zero as they "SHOULD" not)? Finally - a tiny comment on the draft. In section 5 under Session Modification, it says >A pre-announced session can be modified by simply announcing the modified >session description. In this case, the version hash in the SAP header MUST >be changed There is no field called the 'version hash' - there is a 'version' 3-bit and there is a 'msg id hash' - you want the latter, right?. Later in the same paragraph it notes >The session itself, >as distinct from the session announcement, is uniquely identified by the >payload and not by the message identifier hash in the header. so that seems to confirm its use. Cheers, Markus Markus Buchhorn, Advanced Computational Systems CRC | Ph: +61 2 62798810 email: markus@acsys.anu.edu.au, snail: ACSys, RSISE Bldg,|Fax: +61 2 62798602 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 From rem-conf Thu Jul 06 22:12:36 2000 From rem-conf-request@es.net Thu Jul 06 22:12:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13AQDU-0001Df-00; Thu, 6 Jul 2000 21:58:20 -0700 Received: from proxy2.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13AQDS-0001DV-00; Thu, 6 Jul 2000 21:58:18 -0700 Received: from kaipara.live.com (mg132-037.ricochet.net [204.179.132.37]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id VAA15387; Thu, 6 Jul 2000 21:56:11 -0700 (PDT) Message-Id: <4.3.1.1.20000706214335.00bd6e50@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 06 Jul 2000 21:47:36 -0700 To: Markus Buchhorn From: Ross Finlayson Subject: Re: sap specs and implementations Cc: rem-conf@es.net In-Reply-To: <3.0.32.20000707113216.01147e20@acsys.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Firstly - what other sap announcers are out there? I can see plenty of >versions of sdr sending sapv0 and sapv1/2 packets, and I think also Peter's >mstar stuff, but no others. My "liveCaster" application - - also sends out SAP announcements, when run in "audio" mode (to stream MP3 files). So this is another program that you can use for testing. > (At the same time what listeners are there? I'm also >writing a sap announcer, so need somebody else to check against.) There's also "multikit" - . (To get SAP announcements, open the "SDP default" directory.) Ross. From rem-conf Fri Jul 07 02:54:09 2000 From rem-conf-request@es.net Fri Jul 07 02:54:06 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13AUWV-0006Z9-00; Fri, 7 Jul 2000 02:34:15 -0700 Received: from guppy.vub.ac.be [134.184.129.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13AUCo-0004g3-00; Fri, 7 Jul 2000 02:13:55 -0700 Received: from info1.vub.ac.be (info1.vub.ac.be [134.184.1.1]) by guppy.vub.ac.be (8.9.1b+Sun/3.17.0.ap (guppy)) id LAA28489; Fri, 7 Jul 2000 11:12:51 +0200 (MET DST) for Received: from info.vub.ac.be by info1.vub.ac.be (SMI-8.6/SMI-SVR4-INFO-HUB-110196) id LAA21954; Fri, 7 Jul 2000 11:12:34 +0200 Message-ID: <3965A07B.831651CA@info.vub.ac.be> Date: Fri, 07 Jul 2000 11:18:51 +0200 From: Pieter Liefooghe X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Markus Buchhorn CC: rem-conf@es.net Subject: Re: sap specs and implementations References: <3.0.32.20000707113216.01147e20@acsys.anu.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Markus Buchhorn wrote: > G'day All > > I've just been working on a (perl) sap listener and decoder, and following > the latest sap-v2 (-06) draft. This has led to a couple of questions :-) > > Firstly - what other sap announcers are out there? I can see plenty of > versions of sdr sending sapv0 and sapv1/2 packets, and I think also Peter's > mstar stuff, but no others. I'm looking for some to test my decoder > against, and also test the authentication parts (which sdr doesn't appear > to let me get at). (At the same time what listeners are there? I'm also > writing a sap announcer, so need somebody else to check against.) Hi, I've implemented a Session Directory tool for Windows called CastGuide and is available at: http://www.castguide.com/ The version available on the website is only SAPv1 compliant. It has the same functionality as the (Unix) SDR tool but does in addition support Multikit like directories and compressed announcements like the ones made by RealServers when their SAP/SDP packet is larger then 1K, together with many other nifty features ;-) In the version I'm currently working on I support SAPv2 (spec 06) with Authentication and Encryption. This version should be released within a few weeks. > Second - does *anybody* actually use the msg id hash field as they "SHOULD" > (and also not set it to zero as they "SHOULD" not)? In the version I'm implementing I strictly follow the spec...or at least I try ;-) > Finally - a tiny comment on the draft. In section 5 under Session > Modification, it says > > >A pre-announced session can be modified by simply announcing the modified > >session description. In this case, the version hash in the SAP header MUST > >be changed > > There is no field called the 'version hash' - there is a 'version' 3-bit > and there is a 'msg id hash' - you want the latter, right?. Later in the > same paragraph it notes That is how I implemented it. > >The session itself, > >as distinct from the session announcement, is uniquely identified by the > >payload and not by the message identifier hash in the header. > > so that seems to confirm its use. > indeed. Bye, Pieter -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Pieter Liefooghe Research Assistant Vrije Universiteit Brussel (INFO/TW) Digital Telecom Dept. Pleinlaan 2 1050 Brussel BELGIUM Tel: +32-2-629.29.77 Fax: +32-2-629.28.70 pieter@info.vub.ac.be http://infoweb.vub.ac.be/~pliefoog Quote of the day: Any program that runs right is obsolete. From rem-conf Fri Jul 07 04:15:30 2000 From rem-conf-request@es.net Fri Jul 07 04:15:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13AW4c-0000zX-00; Fri, 7 Jul 2000 04:13:34 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13AW2j-0000q4-00; Fri, 7 Jul 2000 04:11:37 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20467; Fri, 7 Jul 2000 07:11:35 -0400 (EDT) Message-Id: <200007071111.HAA20467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-meunier-avt-rtp-dsr-00.txt Date: Fri, 07 Jul 2000 07:11:35 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Payload Format for Distributed Speech Recognition Author(s) : J. Meunier Filename : draft-meunier-avt-rtp-dsr-00.txt Pages : 9 Date : 06-Jul-00 This document specifies an RTP payload format for encapsulating ETSI Standard ES 201 108 Distributed Speech Recognition (DSR) streams in the Real-Time Transport Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-meunier-avt-rtp-dsr-00.txt 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-meunier-avt-rtp-dsr-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-meunier-avt-rtp-dsr-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: <20000706152030.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-meunier-avt-rtp-dsr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-meunier-avt-rtp-dsr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000706152030.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Jul 07 11:38:56 2000 From rem-conf-request@es.net Fri Jul 07 11:38:55 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13AcyQ-0007Ge-00; Fri, 7 Jul 2000 11:35:38 -0700 Received: from penguin.poly.edu [128.238.35.86] by mail1.es.net with esmtp (Exim 1.81 #2) id 13AcyP-0007Fq-00; Fri, 7 Jul 2000 11:35:37 -0700 Received: (from icme2000@localhost) by penguin.poly.edu (8.8.7/8.8.7) id KAA20744; Fri, 7 Jul 2000 10:37:22 -0400 Date: Fri, 7 Jul 2000 10:37:22 -0400 Message-Id: <200007071437.KAA20744@penguin.poly.edu> From: icme2000@penguin.poly.edu Bcc: Subject: ICME 2000 Early registration deadline extended. To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Due to requests from participants, the early registration deadline for ICME 2000 which was originally July 7 has now been extended to July 10. Please register before July 10 to avoid paying late registration fees. For conference program information and for online registration please visit http://www.research.ibm.com/icme2000/ Regards, Conference Organizers Please note that there will a set of 7 tutorials on Sunday July 30. Separate registration for the tutorial is being accepted as well i.e., it is possible to attend tutorial without attending the conference. Also, on site registration for tutorials will be accepted (however, we do recommend pre-registration - otherwise enough copies of the handouts may not be available). From rem-conf Sat Jul 08 09:31:30 2000 From rem-conf-request@es.net Sat Jul 08 09:31:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13AxJ6-0002Hw-00; Sat, 8 Jul 2000 09:18:20 -0700 Received: from (tsmtp2.mail.isp) [195.235.113.141] by mail1.es.net with esmtp (Exim 1.81 #2) id 13AxJ4-0002Gp-00; Sat, 8 Jul 2000 09:18:18 -0700 Received: from cultureta ([195.5.72.104]) by tsmtp2.mail.isp (Netscape Messaging Server 4.1) with SMTP id FXDZU802.KBN; Sat, 8 Jul 2000 18:15:44 +0200 Message-ID: <009501bfe8f7$ec487180$fe00a0be@cultureta> From: "Damos a conocer la Cultura" To: Subject: Damos a conocer la Cultura Latina en Internet Date: Sat, 8 Jul 2000 18:14:29 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0092_01BFE908.5C0B0720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0092_01BFE908.5C0B0720 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable NSI - WHOIS Search Results =20 Si no has conseguido ver la animaci=F3n, podr=E1s verla en = www.elcultural.com/dinamica/dosopciones.htm=20 ------=_NextPart_000_0092_01BFE908.5C0B0720 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable NSI - WHOIS Search Results
 

=20

Si no has conseguido ver la animaci=F3n, podr=E1s verla en www.elcultura= l.com/dinamica/dosopciones.htm=20

------=_NextPart_000_0092_01BFE908.5C0B0720-- From rem-conf Mon Jul 10 02:34:39 2000 From rem-conf-request@es.net Mon Jul 10 02:34:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13BZbe-0003Bq-00; Mon, 10 Jul 2000 02:12:02 -0700 Received: from (imaildtt.deloitte.com.my) [202.188.146.162] by mail1.es.net with esmtp (Exim 1.81 #2) id 13BZbX-0003AT-00; Mon, 10 Jul 2000 02:11:55 -0700 Received: from 169 (ns1.deloitte.com.my [202.188.146.165]) by imaildtt.deloitte.com.my with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 3NRAVJ7H; Mon, 10 Jul 2000 17:34:02 +0800 Message-ID: <00001188288c$000046ad$00003151@126> To: From: HomeLoans@5run.fsnet.co.uk Subject: Home Loans & Refinancing Available Date: Mon, 10 Jul 2000 02:43:32 -0700 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-MSMail-Priority: High X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list

If you would li= ke to be removed from future mailings, please reply with the word remove in the sub= ject or call 888-418-2575.

Let lenders compete for
your business!

Click Here

Cash back refinances
No Equ= ity 2nd Trust Deeds
Debt Consolidation
No Income Verification
The most competitive interest rates!

Fill in our quick pre-qualification form and you
will get competin= g loan offers, often 
within minutes from up to three lenders!

Click Here

There is NEVER any fee to consumers for using this service.

Copyright =FFFFFFA9 1999, 20= 00 eWorld Marketing, Inc.
888-418-2575
This is not a solicitation or offer to lend money. 
eWorld Marketing is not a l= ender, broker or
other financial intermediary.  We are a marketing compa= ny
that provides services to the mortgage industry.

From rem-conf Mon Jul 10 13:30:42 2000 From rem-conf-request@es.net Mon Jul 10 13:30:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Bk1S-0000WP-00; Mon, 10 Jul 2000 13:19:22 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Bk1Q-0000WD-00; Mon, 10 Jul 2000 13:19:20 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id QAA22401; Mon, 10 Jul 2000 16:19:38 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id BAA17094; Tue, 11 Jul 2000 01:19:12 +0500 Message-Id: <200007102019.BAA17094@hafez.east.isi.edu> To: rem-conf@es.net Subject: AVT agenda for Pittsburgh cc: casner@acm.org Date: Mon, 10 Jul 2000 16:19:12 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, The AVT working group has requested two slots at the IETF meeting in Pittsburgh. Anyone wanting to time to discuss their work at this meeting should contact me and Steve, and we'll arrange the agenda. Thanks, Colin From rem-conf Tue Jul 11 03:44:03 2000 From rem-conf-request@es.net Tue Jul 11 03:44:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13BxI3-0003WJ-00; Tue, 11 Jul 2000 03:29:23 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13BxI0-0003VN-00; Tue, 11 Jul 2000 03:29:20 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23140; Tue, 11 Jul 2000 06:29:13 -0400 (EDT) Message-Id: <200007111029.GAA23140@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mpeg4-es-02.txt Date: Tue, 11 Jul 2000 06:29:13 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP payload format for MPEG-4 Audio/Visual streams Author(s) : Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata Filename : draft-ietf-avt-rtp-mpeg4-es-02.txt Pages : 18 Date : 10-Jul-00 This document describes RTP payload formats for carrying of MPEG-4 Audio and Visual bitstreams[2][3]. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for MIME type registrations and the use of SDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg4-es-02.txt 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-mpeg4-es-02.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-mpeg4-es-02.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: <20000710150900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-es-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mpeg4-es-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710150900.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Jul 11 15:31:21 2000 From rem-conf-request@es.net Tue Jul 11 15:31:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13C7yQ-0002OJ-00; Tue, 11 Jul 2000 14:53:50 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13C7yN-0002Nf-00; Tue, 11 Jul 2000 14:53:47 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id RAA06123 for ; Tue, 11 Jul 2000 17:54:10 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id CAA05625 for ; Wed, 12 Jul 2000 02:53:43 +0500 Message-Id: <200007112153.CAA05625@hafez.east.isi.edu> To: rem-conf@es.net Subject: Working group last call: Registration of parityfec MIME types Date: Tue, 11 Jul 2000 17:53:43 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, This is to announce a working group last call on the draft registering the MIME types for the parity FEC coding, draft-ietf-avt-fecmime-01.txt. Please send any final comments by Friday 21st July. Thanks, Colin From rem-conf Wed Jul 12 06:15:47 2000 From rem-conf-request@es.net Wed Jul 12 06:15:46 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13CLfJ-0006Si-00; Wed, 12 Jul 2000 05:31:01 -0700 Received: from okigate.oki.co.jp (titanic.kansai.oki.co.jp) [202.226.91.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 13CLfG-0006QH-00; Wed, 12 Jul 2000 05:30:59 -0700 Received: from kangaroo (dh304.kansai.oki.co.jp [10.173.3.204]) by titanic.kansai.oki.co.jp (8.9.3/8.9.3) with SMTP id VAA25034; Wed, 12 Jul 2000 21:30:39 +0900 (JST) (envelope-from fukunaga444@oki.co.jp) Message-ID: <021e01bfebfd$5d3b8be0$cc03ad0a@kansai.oki.co.jp> From: "Shigeru Fukunaga" To: Cc: =?iso-2022-jp?B?GyRCTFpBNBsoQiBcKE5UVFwp?= Subject: low delay RTCP Date: Wed, 12 Jul 2000 21:33:16 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_021B_01BFEC48.CA962060" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_021B_01BFEC48.CA962060 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Dear all, I would like to start discussing about generic RTCP. I made a draft for the starting point of the discussion. Would you please check it and give me comments? This first draft mainly describes the low-delay RTCP (for NEWPRED of MPEG-4 and H.263+) for the moment. It is possible to add and modify for other tools (FIR or re-transmission, etc), if everyone wants to merge these tools to one draft and we get a consensus after discussion on this reflector or in the Pittsburgh meeting. Best Regards, Shigeru Fukunaga -- Shigeru Fukunaga (fukunaga444@oki.co.jp) Oki Electric Industry Co., LTD. Tel. +81 6 6949 5101; Fax. +81 6 6949 5108 ------=_NextPart_000_021B_01BFEC48.CA962060 Content-Type: text/plain; name="draft-fukunaga-low-delay-rtcp-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-fukunaga-low-delay-rtcp-00.txt" Internet Engineering Task Force Shigeru Fukunaga - Oki Internet Draft Hideaki Kimata - NTT Document: draft-fukunaga-low-delay-rtcp.txt July 11, 2000 Low delay RTCP packet format for backward messages Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a new RTCP packet format for carrying the backward messages for error recovery; such as MPEG-4 Visual upstream messages [2] and H.263 backward messages [3]. As these backward messages are requested to deliver in low delay, a new RTCP profile of low delay is defined. 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [4]. 2. Introduction For real-time video transmission, using the backward messaging functionality from the receiver to the transmitter is very effective for the error recovery or the error resilience. Therefore many technologies are discussed and developed in the past years. And some valuable tools are included into some international standards. For example, "NEWPRED" is one of the error resilience tools using the backward messages, and it is defined in MPEG-4 Advanced Real Time Simple (ARTS) profile [2] and H.263 Annex N [3]. "Intra refresh (IR)" and "re-transmission" are also famous error resilience tools using the backward messages. The backward channel messages of these techniques should be transmitted in the framework of RTCP. The performance of these techniques strongly depends on the delay of the backward message transmission. The longer the transmission delay is, the slower the error recovery is. Therefore it is desirable for the backward messages to be transmitted without any additional delay. On the other hand, however, the normal RTCP packet is defined to send at constant timing with random delay [5]. This rule is an obstacle for the low delay backward messages. This draft defines a new RTCP profile that can transmit the backward messages without any random delay in order to maximize the performance of the error resilient backward messaging tools. The new RTCP will be called "LD-RTCP" in this draft. This draft also describes the congestion control for the LD-RTCP. 3. New profile of low delay RTCP This section specifies the new profile of the low delay RTCP (LD- RTCP). The LD-RTCP SHALL be treated as a completely different RTCP >from the normal RTCP; such as SR, RR and so on, in the following points. - Sending timing rule - Prohibition of Multicast - Congestion Control - Calculation of RTCP sending interval - Compound RTCP packet 3.1. Sending timing rule The performance of the error resilience tools using backward messages (such as NEWPRED, IR and re-transmission) is sensitive to the delay of the backward message. Therefore, LD-RTCP packets SHALL be sent as soon as possible, i.e. as soon as a packet loss is detected, without adding any random delay. 3.2. Prohibition of Multicast As the sending interval of LD-RTCP packet may be smaller than that of the normal RTCP, the number of LD-RTCP packets may be larger than that of the normal RTCP packets. In order to avoid additional congestion, LD-RTCP SHALL NOT be used in multicast. 3.3. Congestion control The total amount of traffic of the backward messages in the error resilience tools can be controlled in the receiver. The total amount of the LD-RTCP SHALL be controlled so that it is lower than 5% of the amount of the forward video data. Even during the congestion, the amount of the LD-RTCP also SHALL be controlled under 5%. To reduce the number of LD-RTCP packets, multiple backward messages can be concatenated in the payload of one LD-RTCP packet. And although a normal RTCP packet is transmitted with random delay, the LD-RTCP packet transmission interval depends on the interval of the receiving and decoding the forward video data. Both the receiving interval of the video RTP packet and the decoding time for each packet data have some jitter associated with them. Therefore the LD-RTCP transmission interval has some jitter by itself. It is effective for the congestion control, and there is no need to add any random delay. This means that the amount of jitter is enough to avoid another congestion in the case of Unicast. 3.4. Calculation of RTCP sending interval LD-RTCP packets SHALL NOT be included for the calculation of the RTCP sending intervals. All LD-RTCP packets SHALL be ignored when analyzing the information in the sender and receiver reports (SR and RR), and only normal RTCP packets SHALL be used. If the LD-RTCP packets were included in the calculation of RTCP sending interval, the RR packets should be generated in the short timing of the LD-RTCP packets. In this case, the interval of the RR packets would be smaller than 5 seconds, and the number of the normal RTCP packets is much increased. This is bad from the view point of the congestion. 3.5. Compound RTCP packet Multiple LD-RTCP packets MAY be concatenated without any intervening separators to form a compound RTCP packet. Although the normal compound RTCP packet SHOULD start with SR or RR packets, in the case of compound LD-RTCP packet, other normal RTCP packets SHALL NOT be included, and only LD-RTCP packets SHALL be included in one compound LD-RTCP packet. 4. LD-RTCP packets definition 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| BMT | PT=LD_RTCP | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Backward Messages Payload (byte aligned) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ version (V): 2 bits Identifies the version of RTP, which is the same in RTCP packets as in RTP data packets. padding (P): 1 bit If the padding bit is set, this LD-RTCP packet contains some additional padding octets at the end which are not part of the control information. The last octet of the padding is a count of how many padding octets should be ignored. In the case several backward messages are mapped onto one LD-RTCP packet, padding should only be required on the last individual message. backward message type (BMT): 5 bits Identifies the type of the backward messages. 0: forbidden 1: NEWPRED in MPEG-4 ARTS Profile 2: NEWPRED in H.263 Annex N 3-63: reserved In this internet-draft, only the NEWPRED is assigned as the candidate of the BMT for the moment. Some other tools using the backward messages may be assigned in the future. packet type (PT): 8 bits The value of the packet type (PT) identifier is the constant LD_RTCP (TBD). SSRC: 32 bits SSRC is the synchronization source identifier for the sender of this packet. Backward Message Payload: variable The syntax and semantics of the backward messages are usually defined in each standard. For example, the backward message of NEWPRED is defined in ISO/IEC 14496-2 [2] and ITU-T H.263 [3]. All messages are byte aligned. Normally one backward message is mapped onto one LD-RTCP packet, and several messages with same BMT could be continuously mapped onto one LD-RTCP packet. One message SHALL NOT be fragmented into different LD-RTCP packets. If the syntax and semantics of some tools are not defined in any standard, the special payload format will be defined here. 5. References 1. Bradner, S., "The Internet Standards Process -- Revision 3," BCP 9, RFC 2026, October 1996. 2. ISO/IEC 14496-2:1999/Amd.1:2000, "Information technology - Coding of audio-visual objects - Part2: Visual", July 2000. 3. ITU-T Recommendation H.263, "Video Coding for Low Bit Rate Communication," January 1998. 4. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5. Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for real-time applications", RFC 1889, January 1996. 6. Author's Addresses Shigeru Fukunaga Oki Electric Industry Co., Ltd. 1-2-27 Shiromi, Chuo-ku, Osaka 540-6025 Japan. Email: fukunaga444@oki.co.jp Hideaki Kimata Nippon Telegraph and Telephone Corporation 1-1, Hikari-no-oka, Yokosuka-shi, Kanagawa 239-0847 Japan. Email: kimata@nttvdt.hil.ntt.co.jp ------=_NextPart_000_021B_01BFEC48.CA962060-- From rem-conf Wed Jul 12 08:36:59 2000 From rem-conf-request@es.net Wed Jul 12 08:36:57 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13COUe-00017Z-00; Wed, 12 Jul 2000 08:32:12 -0700 Received: from (mail.evue.com) [63.86.163.212] by mail1.es.net with esmtp (Exim 1.81 #2) id 13COUc-0000vu-00; Wed, 12 Jul 2000 08:32:11 -0700 Received: by EVUE-MAIL with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jul 2000 11:20:12 -0400 Message-ID: <77CD9266330AD411BAAB0090277A4E210207E0@EVUE-MAIL> From: "Goel, Jiten" To: IETF AVT Subject: MPEG-4: DMIF signal mapping onto RTSP... Date: Wed, 12 Jul 2000 11:20:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Is there any discussion going on how to map DMIF signals onto RTSP? -Jiten From rem-conf Wed Jul 12 08:44:48 2000 From rem-conf-request@es.net Wed Jul 12 08:44:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13COer-0002B8-00; Wed, 12 Jul 2000 08:42:45 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13COep-0002Ao-00; Wed, 12 Jul 2000 08:42:44 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-63.dialup.cs.tu-berlin.de [130.149.145.63]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id RAA16664; Wed, 12 Jul 2000 17:35:17 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000712173201.029ae140@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jul 2000 17:38:10 +0200 To: "Shigeru Fukunaga" , From: Stephan Wenger Subject: Re: low delay RTCP Cc: =?iso-2022-jp?B?GyRCTFpBNBsoQiBcKE5UVFwp?= In-Reply-To: <021e01bfebfd$5d3b8be0$cc03ad0a@kansai.oki.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm currently working on something similar. In fact, there is only one big difference: I (and a few people I consulted with) believe that a hard restriction to unicast is likely not necessary. We are instead thinking of a scheme that allows the use of feedback even in small multicast groups, the size of which depends on factors such as bitrate, network conditions as reported by receiver reports, and such. Reason for this is the observation that especially RPS/Newpred is very effective in small multicast groups, as it takes 1) much fewer bits then true intra pictures, and 2) does not have negative implications compared to intra macroblocks (blocking artifacts around Intra MBs are avoided). Other then that its really language and structure only. I suspect we can merge the drafts during/after the Pittburgh IETF. Stephan The idea is to At 09:33 PM 7/12/00 +0900, Shigeru Fukunaga wrote: >Dear all, > >I would like to start discussing about generic RTCP. I made a draft for >the starting point >of the discussion. Would you please check it and give me comments? > >This first draft mainly describes the low-delay RTCP (for NEWPRED of MPEG-4 >and H.263+) for the moment. It is possible to add and modify for other >tools (FIR or >re-transmission, etc), if everyone wants to merge these tools to one draft >and we get >a consensus after discussion on this reflector or in the Pittsburgh meeting. > >Best Regards, >Shigeru Fukunaga >-- > Shigeru Fukunaga (fukunaga444@oki.co.jp) > Oki Electric Industry Co., LTD. > Tel. +81 6 6949 5101; Fax. +81 6 6949 5108 > From rem-conf Wed Jul 12 13:07:02 2000 From rem-conf-request@es.net Wed Jul 12 13:07:01 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13CShz-0004zA-00; Wed, 12 Jul 2000 13:02:15 -0700 Received: from p-biset.issy.cnet.fr [139.100.0.33] by mail1.es.net with smtp (Exim 1.81 #2) id 13CShq-0004yY-00; Wed, 12 Jul 2000 13:02:07 -0700 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0) id <3JZBJZDH>; Wed, 12 Jul 2000 22:01:36 +0200 Message-ID: From: CURET Dominique FTRD/DMI/REN To: 'Colin Perkins' Cc: casner@acm.org, rem-conf@es.net Subject: contributions to MPEG on 4onIP Date: Wed, 12 Jul 2000 22:01:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFEC3B.FB24CAC2" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 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_000_01BFEC3B.FB24CAC2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable dear Colin, dear all, As Colin suggested to me,=20 as most of the IETF folks dnot belong to MPEG and as only a good collaboration between us=20 will bring palatable standards, Here are two zipped MPEG contributions to which I participated,=20 on the way to declare MPEG signals carriage over RTP in=20 the SDP syntax. One contribution (m6169) is an update of the work initialised by MPEG at the last Geneva meeting (MPEG document N3381): " a framework for the delivery of MPEG-4 over IP based protocols". That N3381 document is also describing quickly a possible SDP solution. The second contribution (m6162), is not at all a framework, it is only focussed=20 on a modification of the SDP syntax. This syntax being more widely studied. Please, if you have time, take a look.=20 comments welcome Dominique _________________________________________ > Dominique Curet > France T=E9l=E9com R&D - DMI/PIA > % + 33 (0)2 99 12 40 05 Fax : + 33 (0)2 99 12 40 98 > ) CCETT B.P. 59 4, rue du Clos Courtel=20 > 35512 Cesson-Sevigne Cedex 09 FRANCE > mailto:dominique.curet@rd.francetelecom.fr _________________________________________ ------_=_NextPart_000_01BFEC3B.FB24CAC2 Content-Type: application/octet-stream; name="m6169.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="m6169.zip" UEsDBBQAAAAIAHex6yiUkVEBpi8AAADAAABFAAAARG9taW5pcXVlL01QRUc0L21lZXRpbmdzL0Jl aWppbi9jb250cmliX25vdXMvdXBkYXRlX3RvXzMzODEvbTYxNjkuZG9j7FtLbxzZdeZMbGsEuJ3Y SbzIIrgRnBkS6S6yRUkjcmQ57SY54kR8gGxZnmhozO3q2901rEe7bhUfg1lkEyBZOo9dFskiPyCb bLIw/AuSpZfOOkEQwFlb+c4591ZVN0lpYsPIA2mAqu6q+zjP7zxu6Z/+8as/+Zu/+61/Xlr4PF76 laWfvby99KXGvTfw98L/+LWlpRN372cvX76kW3+Iv5f///lf9fnXv/3R0odLX/4CVPe1H1aaxQd3 /uG9paWvLA0/GX7y0+c/fb505fPlL3x96fc+W1r6wTff4L/1B3L/j9zzW2/Mj3/58ldf+91/Tvhf pstdm9/p89u4vo3rFj3D9RDX32isMPrCzdeHuP4Vro9w/TGunzWeW/B/B5T/5Ivy+7oriejf3e+b rg8x6E1cN0Wen+v6DVz/8qtLS/+B/f/015eW/h6/v4f7v7l09UNy+NqS7Pe1a54v0vPml0ROX8H1 rSVZlz7/9pZcF+Xr5/mP//0nuH63MW/x+nWs/9GbV9dZ/P3Q7b/4WdTXIl030fmwwc8Ht2p6/Mc/ X5z/8378en7/Aa73cP3rHwePin/54RuLfORviZ3dxPd/z+fg6P3e/u5xb7B7sK929wfbR/v8vfd0 W21tq/2Do73eU/e8tXt8sLq73VcfDPrd1eP+3Y3V5+93u63+wdbu/vvqYEftHXyHvh3u9gfPjraP VW9/S/Webe0etG6au3e4/f7dtbW11b0H3QcbrW+b6JMonbRV/8nufq+tPijjS9VqtQZREZvNW89m I10YVWSqmBq1v77+sKtGWVgmJi021Q96aifXiTnP8lM1znIeNDJxdGbyS5WNFW3Wuacy/Fa7h52h tmakDvOsyMIstn9269ZxoYvSbt7qZ2mRR8OyiLLU73Z/PR8pXkIlxhSgEuPLoZrkWTm7dXxpC5Oo W7d6ZTHNcqyxFfTL3BRt1Qv2dKjLWF+qttoZqKO3t27dAk8f3VH9qU4nRk0jW2T5Jd2hv7Xg/u3b 91fXu6tra7dvj6PcFmqU63HhB+xnhbH+B/11A2X1mVHaqsJcFOo8AhFloeIoNWqYG31q1TIv0ZmZ vDMxqcmjsJMXs87aWpDm2Xi84te6G6gEEiK2tSrT6EINswul0xEk3VY8VnUSq169nHp884Diokhn Q7/feqCymUlZxm15pMZRbJgJdRYF2Fd129+wqx+dfAN/33u6GqgBRKb0aGR52kxPajajwASk/USN jRnZFRqM5cdgxGaJITvgObEOjVXnU5NDbjyBxisLwcUjlWaFmpJIp3oG6vBgOY5OjYqE0NyMMS8N jUp0fmpy2uaYhtPD1JwLB/oVUgKnRTILvBTuMZuhLl43Q31GrAR2WknYwhQxOpmZyb1O5IeC3iw7 VVjwaKffvX9vnT1Cpoqug1msumvBWoRvmVprBXGs3g3u4mdcuC9prp4+bXwfuO+Q+9MdtQWeeW++ cbSjXhySIn73hH/3d2TcE7WbFiZPTaG22Ih58BO4NmxzvavI+2XCkxsZagXTS6JQj1TcCqADfE/H raDQTNBRq9piO53A5iG2dKIG2p6qnSwPze1eOYqyzneikcnUINepnWV5oZ6/r95WB1BZbn+nJeC3 PehsHfV2Brdr5m4i6nZvNoOS+1kyK7F76/YcR7e3L2ZRbuym2jKhSYaAnPVuW561gjGEGJrWLwZY WKeIIApBLRrPbrFnkkx2gKDWgZ1006OkIr9JK5V0WCWBWriBMfAKIovk6Oda7zuvkbZa3t0e7Ky0 VSQLadtm/KCffk1GTYuNCcuwKOw0I0W4B3CrS6Vjm6kRsJGh+Dp64GALhAet1nWssA4bE890HI1Y 5BpbXURJmRBzFiCRAPunlgkmIoZGlRx1Rm14PaMGvmFiNrRZbHBfDS8d7Q3CCixwqYooMSRcFnuU AkrybJZHLoaVthZlR3lq7Ry44GmkY9oPE8KIZYU4I/tBbClN+PhjtiCoG+tPYHQ2eOcdKD5TsdG5 IFZY5jnp31bGQgTOy6oNVIS2MHhqwlOe9vHH3WjU0UMoQYcQL5DlnXcQVywFQBVCVjoidHS4uCj7 46keZedqC54QIsRFQFxE1HExCyIbhFnwqVbLvTFATsNc0igM0iwflQHZ1vJ2CWEZ3E/KNNV5FGSf BrpUy4c6jMZRqI6iBA9HFmZOm9JkmvbsWG1rRMx+hn9XWFWyHwLDqOTnz031HPbivGjLGxrFfDb0 Bbcp0zhKoIFRPafn5KIWvYzCCTtamSAuxbFWdmaYbM3re2cPdQ79AjTJ3MBtrv32zvWTMiYjGkVY AXrFQ7sABzMPB/C3NIwBdFDM0eCwjX+OD8Xzngzot4ZpT8R0yE+EhS7pLM9GZUg7t1puX4IJqDeB QVzMESF5zsjYaEJ6J0ZqxCLCNJwLii4YwIoKaysynT8wqTAHGyLKwdBTSIFER1xAnRBqdBYVl21k AABtEE8ILtyI8UPyRifEyLzosRFNIfrTknGXHLspfdvAWphvbMjTZzOSWy14UJFB5OAI7ndV2Nj2 gLKWyNqSQB7gppJoMi0IMEg6uR7G7OUkKCzhskiwlkT8Gz+gkBIUY9NhOR4LjGosmAio0BDAQEYa XWVJJhGbAJGB5IWSnZSyoMjnqeTScAJGg0+iAputVIq+q55Zzn5gGyQzzns496nFNB+pLTESwiec RSHPCk+R+X4qRmqBEokRYTqhASe1enH/RL14gL938fcQfxsn0LkoycEwZlGCJVq5dGSfAxoILffI 0Dr6nIib33HZBJNADEKNKXDCfGYxJA+4BcCQ+bHUbTns8HOkrmU6InO0K2LSQN80jChuQ3TsJWRR xRSQGLGXU5YXX0pE8uon3j235xHSpCEleWbEULCfEUxDbsglMec6GTF6WIobxbVih5/BNYG6muwe dgB0Da3QoLHd3rPjAWej2O5u0D0haRqmitwSiI60MMyA73C1lHJisbX+4NhHbISBOCLU6z3jvNrB tRDLq97FqrWOgdxPDp493ZIc2JrvlxyPhGQXzof0QBwWhiJmCrQdmZxT7ijHWpdxpkcuBAtK1LFi cU6dCbgBIYUiSdAZgaA1hw6IUmdYSIfsBShSXJi3DNUpGZJjpC04zlojkwPRejRlMiigMsAVUDjs 7kl2TvpuS+RuupvTohMJiRnRrKZ/ZIAEIwiIwht5JObnpsNs0fNITL6N+kP48xOKeQ5QABCJFBIg 9KGBY0lBMTcKNy7dCuCTdbfuLMJ5IRtFqGHjy2GcUSCPQlRGMwJN0JyOVjwrlNwQrGmpoyqLoslt xd5GNYwJY+0UhyG85T1s2YNMLTGSS7oEFzSk4sp4IpIugzKtbvmnF+aVCAhL7Soj4zWCieC7xBQi DFDCO98XZnMjDk15eWy8qXHg1cW1q+8glCXlhTqWwNFY+T4B1PG1nOz1PpxjI7KOAaYFKKe28UwL yX7lWrr2Mg2neZZGn0J8pfVAWphwmkZwKkA4VM6gdTToHzpxUqKJmGlX3lPMhdPrQf+IESqbIJDF ACmKWmLINGrfaU8hnxW8EYX1DwPKy5n/vZr/dnPpnZ97acRBDsfzChDBOfNi9IfRsodyNIzF5qyZ AfEK44BHFkgJ17kiwa0cplvC+NoOMc5MnM1YFT6oI5En2TZWkIgkUUIihvNYkr7cdiC3wsrmzMKN lOSBnbbCGfWiu3bC4cNc0DLMkKT0swwAwXGe3BokWlMFihDZHwRAEINYMPQNjauewOJkgxYT32Hb zWgpZ0858DdiKEEuGbG1+JxLBEPBL4FYRhJ1Ig4BMUcv2L65cOm6rxJoCpVo8j2SIo2SCZc+tpGP FIxFLuOl5Xa2+1QBdZrIyNk1jBUBjzZGtg11VpVJok8d/OmF2FY1YaAHGuLDZGFNPGbPelf9l+Iq UI0Nj4JUJWZn24iPlAOMWCNZGnNNB9EgH6yckomhpGpUwlh83iNm/qLbJbVUSf+62tvd21aDy5lB Cb5O8fg5dZiw+t7hPen8EEyYnGKU2BVjDWXhK1w6kozOI0txzXJMiigaCEFI/LTsUGAH0S99U3fY dle5A3FHLUC4+JgbyBbtBzYckYJp2hTNDMwS3LJM62KukSFUHE015WzwH1siI9LsUAKW5BggPqe0 iXamVmZAgqGUAl7MXTeK5Q5yIoQxrmmHn0gYJVnPMItzKjbdeYmwQhsyCWhVtltatSkhgFbskvzV C9+ryUZ3FoXVIvIQNa+hDhECYR0LkptFYlUsHkn4RD1jF0o4BTC/JMLdJkSDI4ppuo4ZcIOATAbw 59T/Xb1I4r+ot50zAcJG0rSEM92sl9JXqIaq6JoeNc+JhFq3qDSYvrv3VC03wQBFBELkCqFF0+gc ENQ7LduVoMHPXFSoIo/mRGSvd4jMv+oOidEebyGnp7LL1Ras07q6q9aT5BsDOfMyY2adEI27TiFZ xTjPEnECkiRTABSiEmVbh1NPejN2uY3cghTkhtmZ+I7mThYgtuCVsEiN81XgonTlkqvAZhHNZw4u HSJ9OkulZRq2gNrqPK1pFrS4M0f2NTv6wpirRw6EhJCfawMe3tzAA+Q9UgIMpPKdVqsv3ScghFRZ vsqVEie97PnuRgN64Wm0jgAoabZH1RpJkgFplJ2nxIO7t7V93D/a/fa2T+uOAbUsd9TlGUCWSgIf EGSrKoo3ynUJ4xGFXOoGcU+EeI+jMcd96ghySeQLkoU17TWO4W2bluI6xAFtvcbuwZYNXCjxaaiT OxLxvGjko05gC9tKe5E7KpAHBJcYnbomHwuxdhMpsKziwwW4upyXuGKDKpc73Oi5w2dHdKwhlXuh T40UCXy0IivXq9LgzVZLf7OBumrzxSOUH2wBjxW+66GJH5+cUIdWPPj40DMgBudHE30ZC0zHpKWx dAtKAklXRZPMFOsJJBgKtKx3cch6XZKFRPjKPgSUUy6qZpxHMkbeEDoCiu2uDCNBNiMCBXlHE+0j p0uMeCL+ZV9AicW2nRGvXMPsMI4mmgInR1R3BkW1qnp29JSaQHHmoG+UlbDUzvdLOgNsI6JHgCI2 K6blshKO7G4TaiDA+K3vZnNHqUp8tnqD3mZ7PimhPGWzuoV1I6lQiImOq0VB1oo/hqusgJv2qBt0 Xts215PNjGLe0We+dfUar+qllUUoZ0meedkRdIwLZwG12bUd6k7KyCI7V6YGbnvNLswPr171/q2P +dNoQtKgrDrm5C4KpYvPhRwEj9yVgiYBjU9vG5HOujh9V+JaIyRxd8ll+ljvSgns6aqSjLAydV/S MtbA0M5NHPti3hXGsga86HmtggVDblMZzcM6VTiolVoHAMcOpxAsyCrBdlsATgUnvAzOM+mEt13D gjlOKQ1ly6qq9ys8s0VWeVZbRRIbI053apQBcANmlA6GQfjoTMeleawa2m9l+cJgqzaTINrkCe00 ON2cBd/nZqiSY/aabV/nErNzorTvOTOmToocqgqVFfS3FZOiFRbRDju2j3e3qvOzSq/qiwk7fMq1 scvyqK0rOeSlL03E/4ieFXeUxv+e8jSfjKLESlPYpmvSNX0uguhDOsPyewQt6as1AJo8+Qa0UR5t OHgsgo1Upxh//LSRx1kB7qIq/AmIyNIYcXgjXgjp5xDcQfHleOxcitMgmpqAhg7FlsAFAYFOmuww ks7QBF47LhQAIFx1KAgoZx87KL24LSk9aqnWG3KhJaFQC7RgNTGYNzu0KY1LeWyDyXbVQmR0lyTX N6GWXRXtgi4xTvtY6ulm52w6dKrw4F7V5eejAFmDyPTNaTd50+f2jQXol72E61wIe7aZS1tBVU7s IRtwFwK/0kkx5V6ka0PUvHFlLWrwcLX+Orjy1tfAKrNwU1JqgS//hKsIPV9t1dHUtZ182iPFrZXG ea2zs0jXyCW4XPlvoJo40ShdNpv4cP0IEn0l6/ceuUfOvf549fGjcXIhBzY2+tQ8bv0yfKmuMCtl soyWOSX7v+9Yc4bxP8zNxCOoHcqZI+XCC4Ystj5CLOXtlq9LLps1/XW+K5z/gh5c1dFXjgbmQlEj yNeac7EjL2bw/oZnkWPJzc1HvvAlQTxWj5rV+uPVR9wy5u0eV92z+0oS9NLqiWm1+Hsz1+J02eeI VCnlWVwdu0o09ufgkv6JTVentlVWQykPtbt4Bx/Nm6t3FldHAXOfT9cI4q4/Ibl6nh3QJJfU+fZJ VWs4C63XQuZVue+VeiIHhAEqla/xXIkjjSdvpI0j5OocVcdQ4shVppH4csqMco5SkSMlD/cXZPVG bmdyIgScLltjpG+xwrwhAjRO5sZyINlM/OTozeHc8mC7d7R18Hx/RYgggucKst2t6ggVMwrnTSm9 tbicm85KJm/bObts4qPmM+J6HUztMwBW1RIln6nyvXj8zCem8JZOQCRNzIJTpUlt4tzrB769p3gL L6+qZKrOen0DmDT3TAyYldi0rsTQ6pFNJFVPz4DT+EY21SzjzYLqHe5jpDQVWd0+4yZVFlXwrcoV 2tsdM1T7U2mdZmUayolVTY1ebGtvnFCSvTh/ri5z9lt11I9gn2pAXi2HSGRK/nU0OvPnFHiIstF3 VJvSWWjKXcMRCOGMV04YisLX+vLqCYMtCOfSY65vsHD4R5KroN7dw07Neap+j4SOoBJElpy7UlkY Mfgxy80Z/j0TeoMrs+R93OKztW5gwiYVPlz+UgnfVi7qG4PS3PKw35hKFu3F5a2HMqqMYpEcTFVm A8DqNA7t5w9H6NmevLOjOUosiISeH9a8j92Jqcj6ytiBwysfDaj0SYpGWLiRcmmBNoG5fn0qPE2z 89iMJvzWnH+Th18SIVcdAgrGfP40gfSoewixhY13s620IxPqW81M5l4Q8C9B7dELu/2Mz2fb6gOj 004/1iV8a6sENTCuQ+KdXwejk/rTNgEKvqfqiclnBlnVQRydRRjSO9O5e/uIN3MvUSn3ogMF5skU wEtdNPeVxjZp5aYbnXaOSzpg1RXvgizDmRPKl4/8638QyAuEoydw9HBaxp+CxJSO5QGaOg7a6g6p flP1Gm+0HjYDJXlrh721V+cf9k5bzv6Odvqq+/DhBiSj05Jyoe7GxgPKm1/cfd2m2IZ7sLQLv1rL 3Mrrtf0s9a8vshPtISoiRVV9ibbz22+sLWyP3ddfufsrEMgv7d5llPd2I1OMO0lSWn6R2s46axv0 EiMSVzPMed+7tPPDtqpe2O2VEzqWk/tEEXKoPeS74DE2lyACjrCpjh2SbDXw8nNTYkcg5L4Qsg// 4HT4bpd2fLdBycIjJub+ieoHRxlqA4ilqRMHgjv1GxDSHpKW2gW8yIVt9wLAtUTmkzDs6LNCklRX hXTWoKY9nYfIOtc2+B1mOgsnGiGGWaE23HvN9NrXh5mdRtMoz9QfRKdlOI3mybzmRQ1HFhvS6nfk gNG+gkYWJNFIL8b73k5nrcs6VfL+dbsiENp090DfuyS890tkFSZBHvA6ATrK2I5JmHyMv53n7Fw2 Qq2ahpevppHpc9zUcrxCJYuxIvPhiTpS/ehMp7HOayrVq8l8lV6vkdna3bb61rcW6HA3iIiNV8jq Zi06/fVGZ3QYP/JQcT1Vk4atycmy+98Ln09M3TXIKVA7EcR0aSkbuNNTe3SQ8TSztjMA9AMZi5vF ti5G93kktg4DqyhT3bWrhPmbRBhg2/+Hp+69exsPIJh+4xUFhEtKw+tAKP9p6B0GSXqfuHl4Rv/T YUufRSP/HxK2Ex3Fm0r+R8LvU21pAtTHrcF/sncmYFVVax9/9zlwAJFJcUTtqJQ5hiA4pYFoiAma WrcBFARSUhAVckgTyzlNzSEry6xEyyKnygZv3BzuI1fLa1/delDTlJzSHEEc4Pu/aw/szeYIUYa3 yzr+3r3W2mvaa3zXOmdjEnzbdrR3Cuhi79q5kz2oY0igh4fxLQU8aWpCB48BqfxbbfGlJ1fWmDQ8 1uBuQQGB7YOihniEZ2A7gAKOgYYdZu8aHNCxk8dDg8Pk9xY8YloYfybqJtfXxEmT8a/MSytuSjMG tRNTG0cu570oNzf5zRGKrUQAj7oDwyL62GNa2lu0Yls3e6uWrdxbtbDb6zmjghKSdPtaWa0xf10m flqKZstIESck8ncayokSx+4dFtlOPmGRfziYJGs1Yn8ln/crB7rxCePQ08SeiOOJb0zHJ2APozt+ jU8v/cZxCJ8UsZLQTvkilHcjqUmcPS9FyAPF4leVODU5CzH5LEllHSVRSXspr9IeFb7bV2NqTI2p MTWmxtSYGlOucSIaAZLBXPAC2Mt/UcOZqD5oBzqAHqAveBA8BiaAiWASeBr805WopRtRd/AUmAr+ DraD78FPwAkqixvoAnqAa6zCeBJJwAsc8yI6CU6BQvC3OsgHzAMXfREe9KpHFAV+Brb6RGFgaUOi l8FOUAiugJaNEL7o8q+Xiy7/cuKXy/wpop/xOSyk/Dkk+HYPbadPaftGWrdq3fIFasX4SK7TnfpK 5DxyXVSEzaWv3ud9k0/EIxH3G33WmsL0M4Xpa/KJNPkkmtJJUHysPdtI7ve6Tg/vV4f69LWRFXaX vm2klL5urk4syD2Y7/oTO1xg56sVVxfh34QohNu/vZP8V1RGKv0gEywEa0AWWAuygQfa2VPpF9wf eip9YqCDfjEZFOj72hmHjqN6x+HKOQ45dOQ5dHyd4+jOHkOw/pULtrJywfSOXL3DUOpSI/mRtQnV 95dqE8sG/pJl+Why/c6V/6DMGltOc6vw5z++BJvV31KLpVQn0bsErbTLmST3euKPvMDTc0bXEq8Z x4pD7yr1KdJ8Gtzq9ue5YQFYDLLBJvAZ+AJsB+42jH3wNJgGprsQzQSF4BpwRpndgS8oLi6+duXy hV9/Of7ToR/2f7X7y79/sin7nay33njtlZeWLn7h+Tkzn502ZdJT49NSuBKdbV2vl5Q42+4TMlLI KCG/EHK7kDtvsNwtZHAxy65CThdyppBzhXxRyOVCbhbyYyF3C5kr5L8gXS1+ZNsDC7lYJdteWGpb mpBVcq5lO8W+bsJ6EVa+f0l//3rpfVuJfN+lRHe/Q4l2P0S53xlX2We5ZnuthMvyupCrhPxQyB1C 5gl5ANLiTG3+6DZqClqDYHA/eBjEgvFgNlgL3gc39P29xvHnOUoN/3Wupr+lzTaDT8A2V3m9r+Um r/kPgEdBhrL2TwbPgG2KDrBD0QEOKHrAUbAfU9Y3IM8d/sACXcDqIesItUAI6KzoCj1BXxAJrhcV XDx35tTxY0cO5X3/7f6v9+zetT1n26cfb9mYvX7dW6+/vHTh/LmznsucOnlCuuFhnW3XC7jf2wpZ 1hbSQ0hPIbsJGSpkmJC9Cnkse5Ft5BWMOmFL1mxji1TbOM0WfxU2Z9vwqxx7pJCjhcwUcpaQs4Xc JWSukF8J+bWQp4UsErL5NVEuIacKOVvI54VcLORLQr4m5DYh/y3kcSHPClkspJeY7fyEbCVkACS1 /bPb1dAXrzp0XKyCw7F2UcmhcapywariOPF7HZUe3ZKXrBNAUVR0gZzmFhf2saoucd8qxr/fzcba VUVHZ/3cG/iA7WAH6Ab9vDs46iXr7arOfgWE+UBPBxvARmCD/u4CvqyL+CDY94+u3muVC+bYUfR7 HdWSaVUcaE5v0Uvk+f9Wt3MI+ABsAN2hlN4LemHPFg5ebEC0BCzDfm05aI09Wxvet7GSdyr/cN53 3+zbm7sz57OPNr639s3XVix5Ye6MaZMz0kY9ER/javEmm99pMffClq3ZPtBsG39RbZs0m3RWtVk0 m+uvqs1Nsy3VbMs0m+c51eal2aZrtmc1W48Lqq2nZlui2ZZqNstF1WbVbP0viTUk6hLP0I8JGSdk /CVejbiMl9WwtTRbpmabrtmCCkRKncSqFy5kpJD9CpR17Ros/lVtoz92/FbFsdXhnfFkMr29Kdxf 6rMrk7s97+fNQf4kYyjJ2uosCc8DHnxOorZpexAIgkAoKGiMsQ6ugCLg44cFAzQDrcGrIAtsAtvB TpAPToLz4DJoy4cMoDOIAcvAcvASiG5GNBgMAU+AEaDgDJ2mk3T4q530+c7NtPlzenf1itULV8ya ujB91HBxz2RKT0aeNJyVWOCzxuTzgek8ZZDpzOVBgw/Hyjal877J5z3Vh1ynJyCdRJHOCEPKA9SU tTAD1DCaT7Ti0wI+WuJvKYnLQR5QguhSTtKdCvFJ0M1OotSSUktu97agndL+atuHgUfR5o+V6QM7 lHbeBf7pV9qWUc3k9tS35fN3EM0HUXbcA+kgA4xuSZQCUsEYsNmfaAs4BI4ApzuxBhScP3v6xNFD P/zf1+oK8PZqVu/nzcx8+qmxo0cMj4uLwwNYMdeJ+W7xj+rM9+1h1fadZvuPZvtes319VLXt02wF mq1Qs209pto+0WwH88XseiifZ9RzQhbkKzN0Yb4a6v3jqi1bs009odqe0WzTNFumZnvgpLYmaLYo zXZKs53WbNbTokxOp7k0PkI2OK2UqaG2KjbSbI1hu/O3tv+n+oFnmIINjo8cOjbpHdmVc4zQOwz5 lDX3e5PXjHel0hk2qTpnWKtcGlbIxZU1Lp51b581wP23jmmDpl3o0LHBoSNZ7zCkZnAYmtyxo6zh Gi7TByy0pjpr2FSa96q9R1Jpz3TnNp0N5oAD3L6gA+bsINAZDAQJIBWkgylgDpgHHrdjTQexYCQY B3q0wB4SzAULQBZYB34FheAquA5qY973BF7AGzQEd4M2YJSyPkAXKDiWtz9v9358cujjbMqhnDUr l8ybvhKfedOXTFwyfcmYmz1u6Yq32rAGWuFzvFPELKPPzyaffJPPUZNPgcnnmMnnV9VHrPFWLODs M8IQ5idTrCMmn8smn8OmlA+bUv7RFOZHJQzd9XvXaWdQBPzu/vOUfYNji97xZ+09qmDUkWeY+1dX t/5fR23fLHAKRKFdN4EvwXawA+wEu8BukAv+BfaBf4P94AA4qPSLc+A8uAAKwTUgoX9Y7yztL0Eg AkSBh8Hj4Czl43Pgm9x/bP0gNyv3tdwsWnrg2aVb8aFJ+Wkjsip+HtL3+ROGPs8q8yMmPXtubBk9 Wz9U5SCxmp6txYo16fTzYsvuH+bG6rV8HnHH1VGp+Zww+HDKc2LLpjzHkHIFM4mWzqPl7R/UjZAc ZJASpHnZMdwENAXNQB44AIpB79ZEfcDBtmhn8CPo1I4oGCSDJ8EoMBZMA5nAsz3mdxAOeoM7OhDZ Qft7sMaATiAUhIG2HaGDgi9ADsgDB8A1cB20CsT6ADLAU2ACmAoWgBfA7CCsS2A+eBG8DlaBup2I fMFi8CJoGUzkDzaAjSAqBHMeOAPOgqWdsUcFjboQNQafgc/BkK5ED4FnwDSQCWaBt8BasAXsAUfA T6AQ1OuGfTJoDzqAQBAEgsEYkAYWgRtmQ5ovKdZrwtwQWpI8FxWxoSJSpHI1mkKYS2xxttQjD8ki QRm11AU+YudEcTz2YsBQEAcSwGiQAp4GU8A0kAmuKP1E30dagjDQCwwCaWAqmA9+BufBBXARnM0/ kJufm781f+3ry+Y/N5nG4jNyGD0c1Vvfe4ebxtdw0/58qGkXHWeKFWeKFWvyecm0M37V5DMvtmxe vdRxqvnEqMMJsaxPcn3Lo/WkMloD+jUibMkfcpUMc81Jw1yjJmKcj06UH6a0fDGPlJ0j1Cg3SUed +hqXN+YNezzDYVoHvaMd3cyY9jkvVbsWTrrSvHrbnAFy/6owxq0yTjeb46ty9vqh3pFK1WtMrb6s GlvdKhrd2Pbxj1Rj2/MItfG8fAOEo91XgDfAerAZLGgDP5AFOqE/zAULwStgFXgDHGgr95djoDNm hJGKHpCm0wV4rQ9S1vv77pHX7im69ZvX7cW6dZvX2sdABpiqW29n6tZcKqAzx/LozH7aT7tz9lM2 9oW0mBYamDU1fZaw6OfL9aYZ/l2TzzvlnqXyNHrFtAMrdLhLM+hfaiby/PuEWa9UvUpL8YRplUsy 6bAJplgJplUuyeQTr/hQ+6rqcoY1wuDIcOgwLCUGx9jKORwn4NhB5Z26WYlbjarLGEpyuTpL4lFd enklN9qODwgdO6qyoTfozb/b4fgRDMGq8jxVqRCDA2PBp3RMNL0Ve6TffbxSyce/halVJR/D1xzl mt56XeSdaj37Yeqi2au6p3U85Vdlkr6FDtnw894+td+77u1SEg9u66yu5vMJPpsYBxaAF8BisARk gw/AZrAFbAXbwG6QC/aAveAr8D04DApAo+5Ej4IUsABs7S7//7I3lM8VwSk6Qke+O7XryLYt27as 37K+4ge4PU2pLnjBpB2eN/mcUnya3eT04CFXieqZDg74jo/Jt7GDdDgNN77RkK2s19Id5Z1P6c+m uN03gk1Km3+CNvtUazudqaTjqt5h+MrwUhXuGJK+4PCOwfE/aKTGZK1HHf35i2iWvizFnOhZURsX XytmU2EWNea/yWinwS6tyS2AagVIvgFtmgyU6I4N++6xbzjco/kGV5cWoOWiN5z9wZ2G7/BrzF/G 1KGmVAtTwePkRRaeHwC2AKHnSyy41iYbRdMYGkcpFE+jSf4fzX0pvF9DGtZX4pcMncaDdGBOO5DC Qi+UrMa1NvnQQKQzmpIpgZLITmlIbxyuiXSSnoA9g4zva3Sh4gESpvQuiOuK+8Oh1aUjRjzip4ty e5HnjH0WLxALhgInlMuXAkRMixSAmE6INwZ5TBIxvBFjpOQFYsFQoIsh1RExbIiRgXKORinlfHzI a0YTi8+M/iVDcY3DVSmd1ELi0nmKZ0mgUSKGHU+j1le60EQtSMOVBvRzogdBN1G6QKkbYrohXBLC J4lrqqgZzrEucRl9Zqwo5jLG4SqXM5DuCJWol8T16UJ9EKM98jgFOJ4H2sVjlytZDnvnNJcsJMe5 l+yIM0i6F3Fqow2SETZR1LvaCiOU2PXKid1PlHa41A9xa9HfKII64tOehiCddFFH2D1SfX7dwOaP EndG/XS2xPtLaB3lFdMB/Sx4cHSbISKtcdIQURI5hXGiFGGi9UeKeiO0UgPtZYUsG8X7WxvLafki LUJaJF5nRbdzzXClOJHqs1Ic0nTH06Tik0QTkWq6roxNofKgjM6imCLlLk7k+/ZEXge5tI1LS6vm 4IKO7eKEHHpSq9A3abHUEznUoyjRb8eixElaLSag5Cn4cBum436yeC4SdehNHagZWuBNqYMoYbiD sBaUQa7zUOoVJ9EmKZT45ehwUStp6Elqbuni+eQ2dyY/8SpHbUPVhFDxGIm+lLBVRx+Lpl5lcuXc mqgtVF+Lil6aInoyj8Z4UXPTmkML6MyqQgqVbyYN8+rBVxu0CTdJ9uMYdcR/du9LJfzKYgWmh8JQ hWngWb7hJL/Hzb9R4d8p8HeVfF7NexbWTVogSFtwD+gIgohfaCbqrsTldxv5/SZ+x4V/586/deTf u3F6fsp3XXz+yWdgfA7Ce2HWhzltZEfIjloBBKM2AMHEN2ABAHMkBQM8KmYDIj6SRlSMNzlvfq+O 363gPPk79kVKutC76C7QmuQv0AJJfvaSEp5AXeghtNAoMIYmQHph08otlwx7stbrwnEdJ2YbF9xP UubP0XCbW5ANiiDapm7zZchHwkiGkbjluHWi0MbBISKgaG/VnoAYKaCbC/bN4G080UZw2huqtrf8 5kd/cBpcAGlo8kngHdT0R/xWQQM8GfgO/ADaNoQfmOlHNBesQxVvBJvAhyAHbAdhqKK+4GEQC9LA BBCMWuwFVoBVwAtN0xA0Ak1AK9AGfAPyQAs0290gGPQAvmjppiAATRgCuoP7QAG4DpzQjTyAF6gP GoCmIAtsBH5o9rvAy+Bt8CG63GfgIPgFXEBT3gCvoie9BZqhi7QGO8BeEIR6HQcmgafBTLAEvAJW giywCWwGXdGteoKVYDX4vDP3jSa3EKc/MC2zj0VnZ1OEfubHvxxqJXNQITBEriemHxio1JlaV/o6 2gs+UerGivKXIj+NHosolQt6v68YZcZR0wAjqhvFKCNmImwTMJcEYVzzWhcPVwqugRj7iRiNCRWO ygSkEAN7e8zbHGY8QqfCJ0EL0RHzRQh8zOnEYIUZiLU9AjNMjJixk8RKlop1ejx8esGdTE8Knxix 8qSKdTQZesswMW9kiHAZyDtR6CBJ8E+H/zDtmRw93zChoSVW+jm7KPU2BOXlUscInYTvjUD48cr6 rq46dkXLG6PoRsmGVbSiEsUjvcS/cM2nijqobM0/ets/Zwpy7wi61jxTzTPd9s/U4Q+cyfS5V27W +m+s0ZJQa6akrd+JJ6d48ustbGdzULnyTwyF4S2BXYJ+GsqbFqKI+ougWlosNquzk7PF6jTbQgaz SrnyNpEfirc/0cRTpJ0GKRXPvy4KRjoWcnaWLJKLzeLsokRTs2WTyWIwTUIcPgzgQ4ygu0Tu7jYn CxuHuYeJipIPPoLqGEtsNUYhZe+jKzE2Bx0Xqd7COIoTLpqB8+KjAN7YONHYOXMa0rl9KNlIESwy NuL+58GDwEbQt+k/eNoN7TiV+sR7jue8hxnSlnQ5YI94Tl8pNea3mDW2HJcttAVdqU4Ad65GGATy tupISEVx9WaHvTxfufOVlNRR3O1oAPp4BHpfNEWi54ahT0XCLxp9PxKSJ6lBuJb6h1F/+NkxPfQR 44TjRwlfY3zZuCNcPD0lJqHBylTB/a6iaarG/AVNcQlPHWXmP5InjsMzV10oGjDSe/1iV2rbavMP fO6xUiIx+fD9RSR33hUkT237SBx90AGSJ/lzRGK/d53Enx6j2hKfR2EyksT5EAXgymcR/SXulESP 4Fob10SJzyOx85fEnwekKbh64TpDkmf2+RKfOhItleT8jyHTZiSfzwwYFBEWHTk4bEjkgGh7ZPSQ PoOihT2sfx977z726AGDosL6K/epS4eAZsqzEOKxnfPvzX/mWf5b26Tdh1+z/2/v+n2aisLoV5oa NUYbg0jAaFnURGkglgqDSqEFq5ZXSrGSvIREqfqUtgRrglEJo7sGHYhxMk4O/gMy6GjiwuLsYOJq YhgUv3N/4GstERZD4nea23v7+u6P97Oc751zMdszgqm5p6mMzxhPslLy9KTQauJqVQfjilPJQxlj zXiYKbpyvRopVGanItwzJfrR7svvk1hXlZ+fX5z++lZF/qgcnbtty1fvdVS5HDRjQY6bP3L8ANT/ rAgEAoFAIBAIBAKBQFCPjfg/ljStfFhZiraHHz9l/n9y9XWSl4XqlrlMSFsNbwc3vUmaq8+QjgEs cIK8/RHpuAFiBgdJxwzA+V+Q5tCvSPNk6AwRzoTDFDGAZdJtr1It10eb6j9bUULxX4Q+g6YucgTm kH8J71T9kOmvUX44rMe+5fjBnrAelB1Q3qvOFsnS9PW4CBAxCxEvRJWz5jPKiIFMZtPJyeHxdHJ9 KxOcI2R3n1I0RD00QEmK8auHx9mjIvOnuAQ9FpZ3qkh9N6/ZSV38inPqo9NcN8Ytxbh2Lz0kgUAg EAgEAoFAIBD8r7AcFDwVz+7B2UFl8Zwbz+zxvB78FFwZPBycHM/kwfHB28Hp8Swf3B3a6gOkOTg4 fitpkUwbp3ZOhwhOHE2Xj5DmxB2kfRzwW8AbAc8F/BHWdwGfBLwX8HnAL2E9GPB8QI8A3wc8FPB+ WE8GOHa9LwOeEHgz4LUA9/65trbWT5plDxAkWGqCAObLRJiSaZgTJshJm3Uvcn6JU4Y0K3c4ZTmN mu/HCNIvonFOlzkVOF3hNGG+/8HJNWWbtgMgpqsoTWPKKAPhlXMKKoBhsKyzIbvsPR/sT6OLR4+1 4ViHArYtnEM7djXV1MHbs3jLE2gZPn6eOwMdAzw+C4T9lePjlye4+7RXJaHETfMbaA4bYS+fvf7t abhSHc4hNetygeCvmlLSJ+gtf3ukNoc2agrgmtlK/8CJBzoP0ZjqFYJG7Ps09+53EHpKsbkxjnP/ 2OO4djfbP7xeViIZ+mPLNzceKybs5f79+79LqVT97gqidyYFTTAsZ/qH6jVgvGkzfEVdJUxaMMjX UI7PgrxP9erwdZdWcrhR/jblU73uJ8xpqe9Z6H+Yxw/Va4rXvaDquNQI6MnltnSvRYKrNKuuBYg9 teo14zsDMQZ7jyCTZ1JOoYW34G/nnz3vbQ59VLO5mCZ8OdrDcdxn6i3rbMjuN/sZb0uqnqMW+Psv Vrv74m7SyaRH0vPdLv7vfcwtFYtVr3zjjjtQ9G55ZXfQGcnn8PV4Fs1sl3uR4N8jwEc/uFufQ/X3 bvx+JyvX7paK5WqkVsCm/ibIjKHIa6i7AcpRu3q0l771vamZvE2wHfELUEsBAjILFAAAAAgAd7Hr KJSRUQGmLwAAAMAAAEUAAAAAAAAAAQAgALaBAAAAAERvbWluaXF1ZS9NUEVHNC9tZWV0aW5ncy9C ZWlqaW4vY29udHJpYl9ub3VzL3VwZGF0ZV90b18zMzgxL202MTY5LmRvY1BLBQYAAAAAAQABAHMA AAAJMAAAAAA= ------_=_NextPart_000_01BFEC3B.FB24CAC2 Content-Type: application/octet-stream; name="m6162.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="m6162.zip" UEsDBBQAAAAIAF0H7ChLTfahM38AAAAuAwBBAAAARG9taW5pcXVlL01QRUc0L21lZXRpbmdzL0Jl aWppbi9jb250cmliX25vdXMvU0RQX3N5bnRheC9tNjE2Mi5kb2PsWg10HNV1fqt/2V5k2eYnCU0e 4IDkrFaWMAZ0jNu1/izHloS0NgTjOKPdkTR4d2e9sytLtPSEQEoS0oQklJTTlDgESAgkp7SU5HBC Q9uEhPyRkzY/DoRTSA4YlxhicEJsg/rd+97MzuxqbRkTp+3JyN+beTPv3Xffvffde9/z/uCx5v/6 zH1vfkqUXGtFtXhttlHU+d7VAB8P6cpiIW7GM1Vfm52dpVcfQeWjwE3Ax4DZP17/66/n7/xX8S6x iFS75GueZpWy/7ZFiFPE2FVjV7102UuXibJrUc1p4q0boetLQozQcvX+TP396pL2s7NNx3x2r21c 3rJQeHf/M12fx/1c3L+P+yLcf4b7Mh+F/Qsr3y/C/dxFitN1uMd93//lripxf5UQLy5Sdbqfhntd WNXpTvUzdf0w7jlYexqTSKG+p0nRvw50QEa8/64qbjefOwkwd3eVeBn0xu+pEufi0914f6oov0gO S3BvXjzHR1y/DasVe1jz6bZz73frcU9vU/VS+brzcy+qP477g5DHal+/0jvRv+LMcjql9ev0+KVX qb5K+Sq9u/O5zjef99UX+bl1lRBf6IONHAyJrfeW93+9lzueNz/IhfS3eMunPnnjf38tVDqPHREh MLyY+EyVOLO2jNwf6AqHBwbjvSODsfjA0GBsoxwa6Y8NDlzBVdk3NCJH47HBnthIj34XVg1GVYNA 317Z0ysHh0Y2xTbq7+GB0aH2gd5uuSHe3dE+2t15cftl/R0d4e6hnoHBfjnUJzcNbaGn4YHu+OaR 3lGJsWRsdHSoeyAW78Xj5p6BoXAlMpuGe/s7V65c2b5pdcfqzvA607rKykxEZPf6gcFYRG4opGZk OByOW/mU2VU/2jMsnZlM3piW43ZOUue2VTJrzKRsI+nU14/mjXzB6arvtjP5nDVWyFt2RuZtmZ80 5QXn55KSu8i0aeYxCtoXxuREzi5k650ZJ2+m6+tjhfyknQOJnmi/lTMKqXxE9kY3mrLfSKUisifa XciZ+fr6cEe0cXjzyPDQaC+4m7QcmbQThbSZyctszs7ajulIIyOJYSNpZPNmcg7Gk6aTyFlZ4jIi xwwHjYhfMEv9JgpW0kxZGdOJbh3p65ad53deuC0aHEtRGMNg1CtlOXlpj8uMuUsaeSUBfELdTIK2 b2Si7xvdiYbDnVG5Ltb9zv6Roc2DPeFwjNuMWylTOpN2IZWUY6Y0xlCFPN1hd3eFY4WkZWOqSbkF 7NrSTJnEmZGbkU4+ZxppR7bkzHEzB4FTV1dnOZtoO9wzZU6ZKac1bGdMYj9t5yCBjW7/iFQfcurD eMqcThemTXo/nDMdDJaaiXhS01KGtuxdjiw4fnalIXdN2jQj03FY6Ak7TbrC5GbkIOwiaRng16A5 RaZoPpGkkTei0WhrVCqJ6K5yEg0n7LxPzlHZayQmFRGZMKjJlCmtvCPtXRlPNz695G07Gh5QCoeC Sb+yJaj5VjUxxfUcJGALdtbMYALayhMQGVt9mRlEpSctuctkBrmxye2yOWuKnn20XbstKo3siEwl joH0KydrJqxxK6EGdcVOnCTNcStjubzQm/wu8JgzkvzSSMlY+5Y5zCUq4zwVR3WYu1EEepgycyDy MZcRXsAfn8v+jBwbLfQ/bhcySRjtOmucDSNh5NAu75tOAsIMD/UEPyYmjZyRyMOGnbyVcNz59M4x lOPYCcsgse2y8pPSsdOw3LGrzETe68ZjRMPwj8VREnBYtJ6tDBZpmoQZHhjeNFxsMIDvqRTIFDBn 8jBmLj8j00bGmGAmfD0zWBZKmWWyYFEYKcdmw0+ZoDmjdAaGaSWSVYyR7hIpNE1C15dNmtDrPKVc wFKKaFnzCJYB1lgSikCEnKKRxQdtMbSM0B4dI+yfwAwvmbkGyHjea6M002NmMsk+ZdLIu3y7s+L1 XGzfB5exqTAt03DnFhpMo180fH60cfRdg/HY5XB2cxmZ30HCZtjq2TOQK2LnoNd6fiZr0kqk2atJ ZOY2Wz/FMMbviHY0puFjzVRydzjs815Fj4slixWGGREHaXmJXMNjrpVrsnYujxsWVMbRz24gZE+x Fu2ZPaYvp4xUgbkMTiE8jK6QW44GsjNJx3UkciQ+LImuzBQg61zYG0iTKvKIlu2xLcOyhQqePw8x ZTnaWMnTt4YD3JURMWRyJmOkrYQbznWLljEzv8uEDV68mi20o/PCVgkfQWHQbampeG4+72nK5UE3 JE1p/1U6mqtEl4hewEwKYs/ls2kju7vLlfFaFdpdbxllbXY2JpS0w2F2G7KPRU8iOaY9eAGFXYSJ lc2uBndEIDtnKZt2o1y/FyHkVh06toXDCTA6gIxueJVcMzC8DglFLJmEYp217Wvi8Y0oB8di6oUy PywB1z54tmqWxWkpm9ctirpiQ/fHVZMCnzs9b3aum9ISLyXu+kOXPq1hFU547ZqZhM0L3ElMgjCI FPXgU8Marx30aWKKiZSd2CFz8H+oZOG403AIOZqxq2pLB6gSC1B2Llsc05R6Vco27ysZbWs4MJg0 p8mRkbvi8EYWpOekVl7K2mHKy9tise7d0XCRL/9yiyC2w7izKjRHpLv8xolvbh2Ba5frr44S/+5k OF4YVqasO7lP6m6jyElfB7JBtskChoZPZgajckC5Tk7QeOmT4KcpzGGOwVRtd5c0LSarmqkFpj8W 0zjZcnkbdVzVFhveeAmvYSR2qpP2mkfps8XrE6W0X3MQ8w/lTxk56HCiAYOEmOKcoHa2IZGSLarz duZzu+68HX23qzERqq2JDMdOHtFpJQrcqVPHOdni7lo6zr+o46K2jlZ/6hP0b77ZWJkkhTdK+SdJ IRyYkn6P4pBylX8zlPGU8bddUyHXoGzRUpniFjXsECcVctTcWYBRmnK9aSShG52PKXF43K9adfHq NiT4S+O98mwln7Y2mSdpbbeS5aI4W145LuOnho+3PZxKp8SFAE3icONuIOxV/gYzRDoybuUQHtyN 0ABysZYByiOLc+7RXexcqy/LjCq3jnTdH5bdrIQXgG/odClbNFCRWBcTo3dwFkWZag883ZbOmhOr 2iw76QsBcpNOL6gfee4Z0jwUS1bvqQ/eO6L8JVsDwp41jsVHskwZY2Yq4vMOestUbOFmYWoPQqm4 cYmPma6ta+Bk2GbWSjwTvbXbEBjct0gjaemOxEeHi3ugPIVSi/MrO6tTc9+sBrCRQFhyCpS1cXpX lAy2wohMU7RvnTKVg/HTJnkVHJpFT+9o98jAul49aXCRSJhZ3s0oNRVTwnbfhKIS6WfO9MKeL8ll xWieaByVabN/SpvIVGSLGZ2I0vIyeBfLbnQ0Nqx3VJ5EaAc1lrImKMjOUF7h++bPTjaPbKSQlOLd Ikgl7QJWQ9vOgp032Q1brFIsd+Zqpmi9zIeTJk9gU8DWhsGhBLSUgMhuuyJqArss7H0m8/lsF6Vp ak5OweLlx3NpI+k5DvHUqljWK0QtkOL6kCqj8fyjUxhrQ2aPBSEviq5G+O8gDQTdRAesii1HwmyR hMDwHW8ylFaTWJAFIsgT416jHJtKOrAGaPXpUDXXCihJO42Klq71wlyBYe5M7PhSkowFR8jmVRxG p4nBPWrSxnzYonWuMWnvcuf3cUcPonVU0EcDk9YEKUG5d8fMTVnwuH5jpC0McwDFOybt06Q+zGDK fgG7wZo7OkX58UAB8UXZn8Kjwm/5XJNU6RS/DPhOUpR2m+mITq3I33HcV0HE3b0HKKLvzoKVo8jK ZwGBJEfLUE01IBe105nx8h6d9bVYWCUF7m94Z0Mq8OudXKurpuIOzdWz4o6YKNlu7PZpVidnb9SG iJZeOPuGbYNq38CNTpTO4Ugark+EjoIpKDvuZLJ4AHSMLLtSGl0coH1N3krTKYWRMtdubV+T9LyJ FuO2eWbS0bCP6xJf4k2iLGnerSy3uNNPGTPkW8J+tryQrKhBaXaq4D9qIq1ReydvpLMw+vJZuLy7 h2olR7LUDkvK0AdgwcWGVLjIX7GHl06XnkS4h2s+4sqjlXKlzvNUDGZ3mq/QiPyXm1mUCqzY3l2u 9pj2wOAlECKdAhwpQqRvccHxRCjs+F6Ro1Vrm89aipsFzhzUp9bKE/JOz9qCIY8OvFev8kwhGlaL v2g0li+78s5XMKy2JRVie0e3D/R4R2vMi7ZxP6GuNbzI4BK8BCkc9jwAW2TZ5twf2VoGEebV9K1x Lx1xd2FBt836yCjhKO68xZ+yVUZnZxAnfAEimPKVZXleQsKrvUIqIt1UhLkszUS0i08GDQRmqK1s hmM1ZynYRcqeWDzWxQMxIZjaGLIPiKYwPk6xz388Ckll2ugsws0VlUFSZz1xyjdUFtamM0akmGpb r9Oj9fE4koK++LBrR5TGG+owpLidIpKQuQPD4tNUzvn0th1VfKJ2GW7rm2TEW42cBI5ZGdKyjmgt sC5iWmuXJk7jOOpYlINciaHSUJoGsRnRMVZ37sqb0/n26XTKR4Bq6mRPTc8JLhT+fwK4DYv+0wqz SyDRyEzkJyOYoHQsYt03N05MlRqgPl4yrg/zE9V+yExn8zPH5ZjC5YdXJanGpN6zlp5SveFHVJz+ nO/bKpbmQBU2kceRCJXTLmZDYzZv0ObIRpjaXMnS/4P85feTvuj/tfs9Zy96lEAK87oOAcMlFEuO +o6avpBfL/mPh7xtI56Hi1y5w/velGQuUqUugZComaGNxzwio39RuNTd6cwZKH3kuwKBchdvwn1n CycehlxG5nBdf4xJ/8djEgnr6On0HH57t45PwZXTPWlkMnQopl/TK6SQkWjU90r/p966Ah0eRAMR cQ42MA5lz68zNpaGRteOS+PjyfyfnHCYfzzT2LiUtN0rl3V0tK+8sH3lylPxaelwrL9XXnmOPPu8 YWPC7JLnnXPewvPOlnKZqnYsPLU27p4A8gGMlYBEyYtF5ICkoLVDWnkVaDITZs5Wv6mwMlN0ThMM deQOnd1n0R+GPvYvl/54vSFXjRBVQAdwB3An8A3g28B3gF8AS2qFaAFWABcDPcBGYDPgAHmgAEwD fXVCjAJ/1iBEBrhwoRBdwA5gJ+AAVwNfBh4CvgE8AjwHnLFIiDcBbwWiQAwYB2zgvcANwOeAfwbe AwuZAt4P3Ag0niLEauAKYC/Q3oQxgWngLuA+4FngAP1KsxlzWSLEO4DLgXcBVwBbgQ8AHwRuBHYD h185sH/v0/v37n/lyVf2098Te8Qe8QSDyp+IHwb+9ogf7vEq3/v6w19/6IH7H8Cr6qqGaxcB1VeR 0Dc3hERN94ZlQtTjHT0s9r5Rjb430ENmfXONaBjaUC0uBUT1+hVVNen1jTWi+oKGa+vXrwih0rDw AqKxXBSfz+DnejwX353J76h3A9FWTfpJ/yGfDbwbKPhs4avaDp4Cntb2sA9ohK4X1CrbIJvo0nbx zgq2ccRvc4HKoYpfKlde8VcOzq8S6BOoHKhYeebhSl9+EWi2fn7Nds+vmb9S9sP88ivUJKqXiNOW h+iHystDpy8PVd2SEg0/bqCfHz9f8/BZ1fyezGd5Ff9gP7RMcC0k3nSy9P9e4Fqgt075iDiwGbgG eBR4GjgEPFQvRBZ+YyfQ2SjEpcADwI+B5gVCXAlsW6D8SgxYB4wDE/wr21c9oRw69Mqhl/W/Ay88 /9wzLzz15E9/8K1v/NvXvvrAl+667e9u+dgLH3n/+1Tb2ronZmdnm6uqRG2o7iAe60MNb69pDNXW /QaVhqpWUffc4dlZwU/76Km27oIjs7NNdVmUDSvQdAHkKZrqbvLqVVw/6NVJ7Avqlr2q66DwIzzX 1v2Yyw++RuXGWaKZpDFbijSu8eqKxqNuHTR+7fJ3YJa5WjlLdF7mkiZSW4VW8D1N8DNLRHWodkFV NTwPPeAt3E/nvHXjt7jf+CsvV6wE+uz3VwIE7vRXrhTzvLDkFpwrFva11DRdv7em95H3hmDaXe/p H/danF5sPPcvzYNXSHz5xWO3Osp1XByFxLGvE+WorlWEH6mr+kpz9hw1IIy0+frR6tqQYhRvGo+6 7vzE7vdX/mF+FVOczGuDlv8KyP9ITfP1MOg/vA5cmfNgx2Uh1eW0yq4T5q6u1L8G1Gz5K28VZddx S7ymnEbZdcJzOm6uToqkj5urk+Kzqo8VUx/QuTrl6N8E9pbk6pfoHJ3y8mL0xfXbipVA5hPoc0/F L5+rWLndXwn0uc1fCfSp/GWeFX3x2v5CqLba86fuau+rwqvQwr63+1d5aA5Do1fH8kPUJjovbzX3 VfT3ZRFhyfHqeCX2Wh163/UJ4Gag4RS1/7pA78G2ArcDnwWe1fux87DvatF7srv0XmwvcPtiIX4K 7AF+tljtzWgv9iG9B/si8CWgYSnyS6AXOPK7l1781b5nf/nUk4//9Ec//O6jLz7y7w8/eOTL99/3 pXs+f+ftn/7Urbd84qYbP3DdNVfvyu+k7K6f86HruPw5l0+iXKDyvXtfcTO7e1Vm98RhyqmaRN23 j3D9Ss7QtnH5bi5v5nKQc7YhLm/i8jtcnsIjNHE5yOUQl5/g8mYeuVrUVtUtepXpD/P7v+DyGi4P FNs8pNr8FVO+gcvF3OZSLq/m8jYuP83l97l8jMsXufx1kdqNKkv8ML9/nCqRk6nTw36jrFypnF0G fN08KwFqgS8nTHqe8znhyl5/5Zdi7qu6STTBFwnkcXRfeseLYtkd056PotUe9FNN5KfefKy1thk4 TGsOOAsbhrOBS08TYgT4GaLV46eXePcX/JV9/krlaVSu/L2/cuvrqPzN66hUuFyZuRLtI3FWLew7 N+jja+fqyNH8aB4cKTj7+ChaRo/SruLlyzNrq1w9N7Qyq0WfX2odi+mMaxF02+zT907gGq3zd0Df 1dD1W4C3AW1AFBjSNnAZfYMN7Dld2cOhM4RofZMQK4B24E+B9UAamAJuAD4CfBS4CbgNiLwZbYEZ 4Fbgs8AzwAHgnLfA/wDfPFOIbwFL/0SItcBTwHPAvRJjAweB3wAPnoX3wD7gBWAWaDgbfAOrgX5g EBgCtgH7gF8BqyCcOJAA7gb+CVizXAgD2HEefBjwH8AsIFqgS6ARWAAsBpoBpB+HxEFx8MB+/nv2 AFKdg+7fkygOHRTBv58EaoHP/ykeE481eseF6txuEZ3bDW2oEpcCYrH6unLDCrGm4Vo6M1zknhTy uWE9lXZLqKbkFLF4gihG5rvGfw0cAKLQbzvwXeB7wO/OCOq8R+uadPsE8HMgqvW7E8hpHT+jdUs6 fRT4NrDkT5R+LwQu0jp+9W3QFfQ6DFwK3EN69of/x777KML/Qw8Gw/9ff+iG66/9yz+fLhQXSG3d h35Lce9GLj/M5ZNcHvodlZ89ROUdXH6Ly0e5bD5M5RIul3L5lSNUHuRyHecCFpdXcXkvl1/k8jUu Z7l8J0fvDJef5PI+Lv+Ry6e4fLosg7iXyy9y+RyX+6jkeF5bt4P5eYk5eZnLc7jNci4HuNzg5QLN Kgvow2N9VcO5dIQUOdm6DZwJBU5hK58jzbPyxgb35/2VE2Y0QO1/2LsT8JquRYHja59zMiFNIlFE yCimxJDZlJwkKEqj5rZBQwxRYi5RXFPNFNdQSoUaS1FS2mso1RuvvOqtqqd4uC1XW6pBXXPy/mut nakS9fX1e++798vJ91s5J3vvtddee+219tp77ZPSP/yv11P4KtZaFWm1ip8HVHuS403Wsaf8dD17 2q+wro2mbo3BHMzFR/7F61+bWe/KuvYtrAh43FlO6R3G0j/8nrOpJ+yY/rGncMWufpY+5Qk/FEt1 sQJU+Cp6ve/R87780lDtj96/V832NIT2M9RsU2V7+t9oGqTb1JfNdtWtVmHberyE9tWCavBBdSzB 0tr6e2ke3H2SVmD2jGmzZ8+eW3IOPfKyuBrUjx7C1bAY8ur66Tuy5jyjQifVRjirMF2FQ1R4VIUZ qu4dq8K3VbhKhQ9V2EjV/9OKtAtbVfiTCq+pMFbV/HEqnK3C91R4UoU5KryuQj9Vn/ursL0KdS9z jQrfUeFFFV4q0lJYVEtnVWEDFTYkFKH/l/vsjz1af09FcL3ohz826mL9nifsBJW+zD+ebLZfvYx6 oLNt8xBBqY6yrpe1gIM+5j2mdst95Pj3luetVeFt7q8aiEAUohEHO+KL7MeHd2iobt15eOeauPKY 1JS9/t9eurfgWtg/kD0I+VsU61EIWwUf4bt9cn2/7dnx/ttnOgQgcP5MhyDULHYrp+z17/mqKEJE OaqJl4RbwR0Hqnn79Tz9bWSO4jkxRAwXg0WK+nYzOY9NDG5dwZYpDLvB50whr1x0FmliJPP1FX6i EXEOUGFrPqeIVKali/5M6aL+1sgM5e+OxibxBmvw9vvAXDJO9FF/ieOnpfqbIDSEY5ChzmIcRd0g o2Lqg1w6FGtthhfswWwH3dmEuobuINvo6NrEDGFRKZyhtqloCsNUCsNUOvLDR1MTVkJqwoT81jiL To1RkBr3PCG81uYIe7BRmJKnC1LSU1hVSnqytEexlISrlISrNOSHjdQ6rHodloJ1BKl1nGUdlqfM dRTGbxMlxx+h4o9QMeeHOn6bjt9aQvzWR+N3KCX+SBV/pIo5P9TxO+j4bSXEb3s0fsdS4o9S8Uep mPNDHb+jjt+hhPgdfh1/C+Gk4m8h5CWwovFHC3nTzUlYg6zlgh1lXPraWDOicRTlhYrEvN7SSjir WFo9EkuMisVZx+JUPBYn8ZSIMlOjI2orXFQ8bR+Jp7GKx0XH41w8HmfKeJRZsioWXAQKE/H2G3mr Vbn0EB0oqYOIr4+KbSjH3nB+p4ofRD/ej2I9RV/NRAKl8ga/5fc8JqrjfKgYoZaQy48kHKNCeRLh JlPFNuYPHdsict3YCmOL2opO5G07FUeqmn+ccBeu2aNFLR8j2tLJmm6b5bDO8aDTWec7Lp7lG1Ro 69rvqUluK91PVPzZs3yl4KcTKveoklF1kff2akd9Lle3+Nbwa+zfJWBo4JygDTUPBZ+rda92pbqN 6rULEU/2chc6jxzIIweZWptd+LGtFQ27kN8W2YE86ktK87dU5lR/lW5XctE121lYLrgf8Dcsanuf VjGEidwkQwQYMqddqBUT1NYO5qcvtZvMWQt7qLxQg+30IpSL3KQ1opERo9aaSEnWe0TnVp+C3HKj nBUk95XWF23UqLGkN8GQ14IdipQR+clLDd0y1+Sj12RnmwzqL7ve+sfsS12Hye+UVKXbTKuzqKvS mmJwksCUwrS2YakUs1TJDiRlkJP9XDcPMVme8JOeeLY/XcUvt7KyTJ2qqRM5+zzAnMOMycYBIctY 4Zx6iwbxvrOZMiEWiir5HVV7sEtikGFeVzdah/Rzyt+11oKd/ER3RJ2KrNPvN+cu6UW+uPlzlMh8 KR6bLglV9Z1eubHUrblujcQaI+KRecP5i6fw1ncMEg3XbCfjbxZjgOFoLhUvdpSwVIRaqppQ1bRe 6mWrudRzoiE58InxHKE7pSmNva337wVVokepWmAEdWYXpspS4aPrFTJ4olVWlBUKahFZhJJp3wxx 3JAjsCoXi0+WU1nCZSs+SuS3n4PMOUJVPriL6gWxjy8h9ma6tlB1jU2dU+h6xUPUkMvJBVyzaWTo mxQcvYVLJ8ilLRaOOVk2O1Mee6uy46dSpcuR/FZWX9kmFDQGnmvHUHemm+crdhGgal27yuV21In9 1ZGrj0B34qLcOgSZ90ZyOCY5voomQh7Nbv6WihZ9NBemovhZjuB8yp91N1P1tlXGwjrl1gdY7KrE FC6ZiEHqvMqN1JEPrJ8t8FrrJX6Vf8G6JrEEqxgKj84EVeOnCmGuqTvTqDcs3VV+dCR+WW+kqFzS e7L0Or4cZ0luU5OcPaa+f9utYO0DnEU62SdLKSl43hIhitdlHQiHsN1yLYOFTndhRdaE8itzvQmh jS1vL/QZXUURTB4NYFMHGGrHDw20uMotaOo8KVbXStSBXmrZ+kWWDVPprCXylyknl2miq9wQ6jQ5 f0iR+cPV/LUL5ncS5szE6ksNu9BSX5WHluy7UPLhRzMvXEUd3Q7I+2aGPOuNFbXsa8RqSyzvKxG3 3Pph5vGQWnCcFLYHMs91jW2jPLtTf9RgfTss+fVryfNaBH14Wh15vt1HtdkpqqTMq0TfO0jWeTKP S3rl5elv4c4QsvXVL7mETajDv2D6k7yqFaHGfdn0aHgP8wqA/D5iX9Q0p8lRpHIk4fPmKDI5qkDe WZZ3F+QVZnmVSS4nvze5CqrC24y/urkOfzCb6nXIOOXIFHl3Sl6hlMsSlfq+Zj6KQCG3R+4VJ2q3 dPEKhojRhG60rDJn5bGYVrB/Evk9XB0LzkIeazoVcq2evovyFk8UZprk+mXeefp3zls8lfly5LFO LyhHzm9x1v0fmWLDJOOwixrX3VWK5Lx5YuLEifISkrvsUuUsFPKdc46zuUB1m0yANaehSogtp7b6 u0uOu3j0ZRHl1HIyOxzM+WUVWNH8uxy4TavK6UT5HJmQjw25rqOqXcwzZDGyWdkjIs6qrwR55NjM VMiCkZcnn7JxFb04VIZQ2CI4tW5MGMnvaH4aF5sWw18aqZ9w3oU/ZlpEqXHGMEfpy0U+ZlrUY6ZF P2ZazGOmlb59MTStpU8rfRtiqJ5KnxYuRpH1UitKUbSTloDdeJ0dFcWhM5v92ZKSd4aif5ryvixI lwVD6MJn1cVBlQd5GiBPjGRZkPuZxYUcB8/RJ8awwJ/QiYXsTlpffIqFzPwiM29hXZ1Z18+s62aR dXVhuZ5YhfXYgPeQDVm6/gt/x33YiN8FrqgEX/ijFl5GP/RHGoZjLKZgGqZjDuZiKd7EKqzGJuzD ARzEYZzCeVzDbdyDlQxxhSe84A35xEMdhKARmiIRbZCE55GCDIzDeEzHTMzFIizFSmRiNdZiHTbh PezGlziDb3EZ3+MqcnAP9/EQubDZhPqafS/4IBi1bfqhizBEIBIxaIw4tMCzsv5GV3Sz6Qc00pCO cZiJ2ViAJcjERmzGFuy26Yc4snEYx/AVTuEbnLXphzuu2OTDIpQD3MIDuFLIKqMKfFELdRz0g2AN EIYoB/3QRwekYKiDfhBsMqZgFmZjMZZgOd7CKmRiA7YhC0fxNS4iB9dxFx4U9CqoikAEoS4aIBwR iEWco36A4Rm0xbN4DkmyaUJHvIgeSMEIR/2QwwS8jlmYhz9jMZZgFTKxFn/DVziBcziPf+AXPEQu OMMQVjjCCS4oB0/4ozbqIBKt0AHPoxtGIkPWBZiOGZiDN7EG72ATPjaP46P4EsdxCt/gDM7iklw3 FYMHKuJp+CII9RCKaDRDL/TFqxiH8fgTNmAbtiMLe3AQn+BTHMYxfIGTOIdL+AFXcddZV0wGnOAM dwSgDiLRDM3RAm3RDu3RFd3wElIxEIMxEmMxBXNddF22ETuwEx/hCD7HcZzBWVzGTTyU66Hu64AU 9EN/DEY6hmIYRiEDkzAZ0zAd87EAS/EmMuXpDt7DVuzGQWTjMI7gKI7jJM7hPC7hKu4jF45U3E7w hBdqojYaoCHCyusB2rGIQys8g/ZIQkd0wYvogVT0RVp5/fClfPByJMYgA5OxDCuxHpuxH5/gEI7g BL4prwcE38BN3MdDyKfNLHCBZ4XCwcKBCEE4mpqDh2Mr6Ic55b/aaI0kdENaBf1w59QK+uHOGZiL d7ENH2IP9uJgBf2vOG7iF9xDXgX97ziiYMenuIBltGuZeB9Z+AB78Rk+xzF8hR/wM3JwDw/gSHvo hyCEuOkHSRsiGj3QCy8jDeMxDUuwDMuxAiuxDjuwC7uxB/txGF/gLC7gB8Rx8peIFmgFeguiIzoh GX0xGKORgbGYgqmYgZXuetDtFmxHFv6Cs/g7/ok7uOuu7w86wAXl4AZ3VEJlVENzxMGOtngBvfAy eiMNwzAKkzEVMzEL8/AGFmMV3sFabMK72Ipt2IGd+AC7sA/7cQhHcQJf4xucw3e4iKv4CXdgpYvh DR/UgC+C8TY2IAsf4gi+wnXcwj3QLxUGrChvDoD0QyjqIwzRiEUndEU3vIAX0RO9MQBpSMc0zMM2 7MU+HMZFXIMP3XpfBCMEUbAjHm3QAd3xAnrgFaRjCIZhOF7Fa5iA6ZiLN/AmVmEN3sFGbMJ27MCH uIQruIHb8KYfF4BA1EJDRKIZYtEPgzAeUzAV0zBfdkaxDCuxFu9iM97DduzGh/gYh3EMx/E1ruGf uI37eIg8yP6hA1zhCS9URy2EIBwJ6IIX0RNpGIh0DEcGxmIcJmEGZmI+FmApdmIPruI6buIBDPqY 5VEZ/ohCDJojHu3QDd3RCxMwA7MwB3MxHwvwZyzCSqzGRmxCFv6CvyIbR3AUn+MYTuI8fsQV/Iyc ynqA3m3kwY3eaFV4ozpqwA/+crAeQhGGcMSgCWKRgNbogpfQB2kYiHQMwShkYDwmYCpmYwmW4i2s wNtYhe14H7uwH9k4g4u4hMv4Hlche9F3UI6+tjtiYUdLJKEDuiLNHGiYgUlYgMVYguVYjQ3YiK3Y gV34BF/gCn7CL3gAJ2/KFNzgCS9UQVX4IshbD0JuiKaIR0u0RRJ6IAW9MRCvmIMdx2EiJmEGliMT G/ABdmEv9uMTnMJpnMf3+Am3cBcPkQtbNc6T4IVK8EMA6qIBIvEMnkVXvIT+GIIRyMBETMFUzMBS rMBqrMU6bMZW7EQWPsZ/4EscxymcxllcxHXcwD0Y9BUd4AIvVEIVVEU1+MAfgaiJYNRBXYQgFFFo gngkoD3GYBImYxaWIBMXcBnf4wbuwahO3KiNBohEMySiBZ5DErqhO5IxAq9iPF7HNMzCOmzGDuzG aXyL73AZObiFB8hFcA22A82RiBZohSR0Q3ckow/SMBCDMASvYjQmYBrmYgEWYQ02Ywuy8AE+wh7s w34cwlF8ieM4g0v4Edchr8tVQV2EIgKRiEYzJKIFnkU7dEQqBmM4xmI5VmMN1mMrdiILu3AAf8VJ nMUt5CIPhh/nhXBEOVREPYQhHI2Rgn4YjpF4DVMwD4uwBMvxFlYhE+v99KXAncjCHuzFAXyKL/C1 nx7EeA7f4bpf4WDGXOTB0Z+6B16oBB/URwSaog3aogM6oisGIR0jMA6TMNNfD4pcgIV4EyuwEZuQ hV3Yj0P4DGdw3r/w4YT7sAZQP8EVXqiMKvBBPTREJGLQGHFICNAPMrRGJySjL/phENIxFGPwOqZh XoAepLkeG7AVO/ARsvEZjuA/cQLf4gpuIBeugdSdqIyAQD1QsH6gfnAiEtGIQXPEIR4JaIlWaI02 6Iiu6IGeSMM4TMEiLMUKrMN6vI99OAwjiHxBdbRCazyLzkgO0gMUeyMVfdEfAzAMo/AalgTp61xO wqdMmTJlypQpU6bM7+YkLL85h3y1MDi7NkTBnVB51zP/zmf+3U9J3v3MvwMqyVEBhskiz97gAu8i Z4SSHfFFzvKswvYYToSa3gL9zgF5eV5C/OZggjDeNxHJorNoKdqLDiJZDSOR0/qbg6Pk+/xBHn7m EMwhanDHyCIxpqq55MDWKOIMZepoPtfn9wim/Wuk4gXWm8z7UDFUzTNCDRpLFn0K5mgkGhNzcgnx JKt0txTPiAjey5T2NYeb9See/2HnvP+avtcFnoQQ2TOsEEIYMiJ7hBAxhLDCMOxhiBBCWJG9RUSl FhflUmrVUovoQUDFhehBHOVYD3IVUZGioiiOKrUU0arVSvWA97zu677a5/kD7uvU/qK+fZ7vsz7P ZxYJQTD352yC4uPfSP73OVrR3J9lhJSPTz9KP/67+WeVkXN/U0xY+e9nNRUf9f3ZJ/nHG/r/RJ/i /h/49Jcvf/nyly//2b7UkuZ/JFKy6UbhB23CH34RCfM/KKl/8I0RxKrn2OMaFgFia+YYcwu7B2Jr 55jbvbxbEFs3xxKPTYshVjPHNusRPofY/A+dGjmelwuxjfN2GvS8gtimOXZ1ydp/ftD+439Ewrs5 tsPX58P8U9f5dYwygTK3YlH5+ALs/RzLsnp5ANJJ+vfv/qyTQLAjfUl4cXTsAhhraT9BcrDpZ4g1 5FKI8w9LIRahpEPs31thCTEp3ZnopBkugtg5GYfYvdeSArHHyYuJ4vKsHyD2pERAJBJUyRBrLSkh /kZp2w35zl5+hOimObwSYt6eESQiQQPUOZvwmFSz640DxI7RApVGE66C9bJPr1gJs9NCsGqeqUCM Zr1OKZbLuALZKVE7rKSN2PmQ7kaOlkVOQayTFE5ONpWsh1i0NJqsi9jpGJpMnmklgePowqJvyL+1 XC2E7Nzkd46M+T6SxFLmHu7zA2u3PF4Zkzu5rFIZq8Exo1OoHDPslfJLpdOVEDOj/qrsZhJ9A/Kh q5hMOZ/L3gXJ5Rc6UHSR/I3kr6EwO7Y+gVjiqrUUzM77ijqKhydPDWSaHRSK6YgXxPqM+ymJs3or IHZDfIWijHzPPU53ARbPeMaxBVjN/xg2uqAsjeQNxcwoJEzF2L4pBZLb4pWootE3shBiq+JSVOwW hn8JsW2B6SqnGdKzELP1yVGhj5/fA8aluFyFQmVxIMYvrVZpvTb2HGKC1W0qWFz+kdurwvUfAb/H 8rNVxcZKb1WoKpZ3rmqSqjZBVQNihm6SeQbKZZKqUJ0NnhtUm+qTbSHGiB2a1wnWbpTVuGrLs1o9 iMmDf1Cdpia7Q3n/PWyVGmaLvmiNGqXQcABiBYsH1PLUa7+HWLn5pNpslc0hiA3Faan3dY9pQmxh sY269RV+FmTnz/lC9VGyy7cQ6yA9UFdH4qK6kqIxcKHXBWKlMY4aVaN5YL2o0300hlYpwNy+YIRq POiwvAYxRVq8hlMZ3wWy81u74xpYncklIZrYfBumulsTq+ufFj/TbO2IvQwxlWBTLawGjUMZWh1r a76A7HSr5mpRa347DMl97xSjde7e4x5I7kjIci2p4aO1ELusY6Q9tnC4CtK5Ij1aG6vBU9RMbfqe 0KcQC0ol6Qx+ddEEYj5K7TpYDW7mf6cTJDgP9rovygd0jigdeQGxT7PIupsVHuA6q4xsqVuvOtwI sXYXV91RRt8lKC5d2Vm6zMASEcScuAW6WFz2JKzRfWTPTYJYT/opXaxeuDbXUHY667Ie9j3NzEd6 mJyGkpk+5djNYIh16XvqYzqN9Dj62Npts0mL/rkmHyrEOpP36dfQKNEQ286b1rcJL+qD2KS1HxXz 4QC/gMpqLouF8hCj8gkVGw+1S49Q867ofQ7Jbc+Yom7TKQFr4sTiRQZne7kLIFaR7G+A2SmLTjCg xjA+hdjvkhUGWB7Ol+YbYGt9B9dyAyxHkaEGhvSnWaEQ+1Ip19Curd4L8l1uXmGI9jr3TYZS6cY2 iHnHhRm1NBsnQIxufcDIZ+hRMvQ9E51Bo0RCzTcQm/AcN8L8S1xKMT53e+QtxBpCIoyxPEiFB42T VUg1EPtQ7EjrO6VYDbEUeQGNfYkP5kjHcxvttUEPuM+5vfgJbcRzLROSy+HLTDE7A4O2mrJJLmDP WmnQbvr6ouTv0PdCHMdMsfwNkvXorLKtZRAbTXOmN2ZzLkI6R7R20/dk5JlBbAN7io7NqftsX9Gx eUxPQ9Usz04tG2IPV+aYNZtP74XYZ4w2s7s/N4I5Gkr6bzMsnp3sx2aJuUVpkA9XovUYmFz/EktG x3VDFiR30GkNA1tHCmRfM4xz+OA+53jqPgY23qep+xk5O5+CY/Omvro5ZqdeAc38pvr7UohFJsSb i39ggOuztICvzd//rbUZYhs0282xPbM4udcc662rOTfMg/ae2A4xsvW4OTams4KdmNie61djCbOr RUKG7NQOYFv0dsYHQXI1qUkW2Hri1oKNFuQle8AzJD2VegvMv40VSpZv6uQnIHbPJNkS8+9r3UxL bG9YFH7ZEptTc4rVrLC892hpWWExOx1lazX/OyhmIdm+VkSkdgNK+VbYuNWRDFudeEYwg9iwjqN1 VnbJOMQMfeKt3wfzvoXYUr88aw/KxkHIzgnjddYu7TqGYI4yrltjdqrpzFpjMbsQ57cQy9F5imDh IfLVVIg9j4pF5Q5EHlpYbXIa3OdU0x4sxGLd7u5nc1VArYVYZGKgTR+LBa4ZXpcG2WC2uBTl2dTu HL4NsTYvpi22Tv5ZX2TrFGVnAvlQUZFvi/UCM0m77U02QROSa4mytCs7s2MxJBdEt7XTep3cDDF3 fUc7bB5TUdTaYXOxmtoRe2zfqKk4Zo/5YGw3aI/F09jzlv3OwqENENvtYMWKrm7thtgrYhEL03nZ ajfLuKhWALHe6DbWRXtSKRTPhNB9rJmhttcQu273hCWo5fSC9cLvXVRDGvgKkvNJebkIi6c/8c0i rH/2pQY7aO0Ir4B0rrUOcZisntCD2DKteIfXZS/BHrI5LssBG7cPAksdbnLE4L3FElqjQx+hBpxz OGbnHbpK1GQQ8wv7p4ONzVUFxGqDkhyxuJT5JDti88Ot8hJHHXtLJuS7S165I1ZLx/1/clRL4YG9 4Ge7547YObSeQu6keD7zEGL0pUNO2BmSvv5VJyzWpPJ0Z4y9Jkw6d10R74d0Hq3guTyu6LwByTHF m12wM1xZ7JgLNjYriUGu2DiiRaS4xuc1OUO2lIUfc8V6yHPaSTfMv7bgM24CgQi8P9JdqOrOUztU CX1vxsbC3WY41gqSc3dIc29evRkcR05R79yxeeyBPs1D4u3zEvre5SiuB+bDPkGUR7dMDp4nN+h/ 6sHk3gR75ITBHVSnStR9DywP2wKFntie+dfSQk9srNi693uWLAg/BPmnbDzuiX2PbDHhefbpLNgH n7Pue2LxHCa899R4RguH2FMzEttwv3AC0lkRr8bG+mcCk87G+kSb9S72o8qZQojdo7p6YWf+ZjoX vHrZYvC+8UeTC160B7OgnQvYv3jN9LLAPHgxtThbp+jg3W68yJyDxTpcmcPBxua3Yi5n8ugouLaJ S9nLuXOCYQOxuwZEb6w+t0osvCvdDcG7yFtqlt6YnSt8ed6x3VRbKC4yUYG320jrV5AcibfLu3PP hDFYZ5FLubItXHDd+i4mgeuiWgTer+QoNnGxdVa76Hvu5Nmx7yE7i8T9i7HxZ7N4YrGTp9NBiO3g qfvYDfPcIEZki3z2RPcTITbAi/OpDZ5dCbHgRTk+mC0txEIfvRuJkaB//hpLsBwpmXKXbB5VAe/q TJ2PoXLygGNLsD2XUL9/CbafNnCx5qldvrkOHEd+kTzse3kqiTyV/iF/iGn7tvCweUWV3c1rfNdT DLFoj0s8/ibpj1DevXXv8zo7ToPnKEqhD3kzwiDQlkLGFK+veeMliD2nBPpi/aU1U+gbe64S9CE1 LtsX69caWlQ+1lvD7C35k06cQYgVW7jwsflvJDKCr3Z7LXjHkOSZxMd666u4Sj6Wv7tVp/j89fGe UKxX8FT9sg4ydkJyxgS6n1zkcgaSc2XS/WaOssDzMy21Mj/MzlSzk37WOyPLIcYrGvfDfPiHja1A o6jDA/RBjyXAeutgWo4A01npW4syK8c6VOd3ZVcFrdY1JyGmtuypYLiLDPr+qw7BX2xEBt8MjUfp +WO2XGc2+WNjenWWRYCH//o6iDmT3AJ69EfBe8pzOZkB6JlV6FQAXWQDnkFEEbQD106dPwYx03zd wEOurChIp57QLZCTy3cEa6IoNFDYXPcZpHNEVhU43VMNnmfdWfV5IBazRy5tgaPT0g6I0ZmTgcKu GXBNe2DJb6jOuhDTIIx9IrEMwmr+oLYvKqdDPoOyuKB/BvE6RsAzJLbS3aBo1oltEAuxIQa7iGbA fkavpgVjPeuiU0AwZstG9QqUfRGwOpj2wGEPlL/Tui3BTzkOryDWoWhDdVY4vwzG5pV1q9jCWp4U PGfYYlImxObG24wyITaHz+adE062V81CdmYGXhCOblo/DrGz6eQQ7KzymVZlSJXzOVdIblK2PaTS R4sNyT12OB+C7YsL6c9CpkhZ/wUxoSkh9H/WUn9mV6tooVh97tYWhGJ5eJe2IRR7r+FodDD0wcTM FojlR3WFXqTEg/v3H/jHQ7F1MtNRPQzbO1lX64Zh68g678Swp/WUUxALovWE7bS4mgmx1KgLYV3P nZygHDXoB4cfaR3IgOTky+vCsXFUGnAtfKDUmAaxCULuUizWfmVdS2fSRsE3dImh3aico1KESNZY BL5lHKuKEJEbzytDzIpRJdpK5YD3MrG2taKMt0Xg/sgrrkPEvd1lA8kVmU2IJCazOyE2XPpM5ONR vRXSedCKHIGN926RTgQ2pjfQ9CI6bbfFGBFMCDSCKeH/fs8/ximCTz8L1lmSJTcCi+czSnsEltvJ yh5UjiLUicRYjL5e5PDniZsgVmyvH3mibARcTyj7GEVi47bS9nZkkUQKniefzX6H2jIelhCFsSN+ u6Ow86wZZaXo/duZURCTscNiigpyZiGdUbS4mJ5xaiYk1+l+IWb/4q0GEGuVLYjF7FQo74l1y3nT DrG1uYdix65VgO8SRrMnUJ1P7RhxWK8rX+AZN+MflA+xF978OKrVxBrIh0tRp+MCIgWjEFulei/u YtQguEdo4kvisbmK47U3vpPeEg3ppFPNE2Q3TydBbKeKfQJ2R+uon5OAjbH6kkMJg4e2VUOs1Opw wp66oc0QM/QYSjj9UgS+vQu3Lkmc+rpMDjHNJRWJWB7sRQcSH9tXnoT8yy6ZTsTuehqzApdhc+pD p+RlWE2YRH++DMsDr7oRlTuj2Ieys+ZnUeYbZSbGek+xNFP8Xnv9Lsj3TYo6MbpuFR4Rd0dknIPY e+EJMb/whTfEfnHuFysGW+shNuI0KXYIdgHndw8L1yTsfF4kc0vC9uFiBT8pPKy/CWLf08uThG+o 4Nm9c0FDEhazeObhpAKf1+shdsnBQoL1VkkSW2JoOQa+u1DmyCVYLX1pfA/VGW1LXI7liK7utnwk iAueBd1dxF6O1eBbTfFyxeSOT8CY5VQut3my/3coZl/EbkBt6VXsWJ6Y+5gHyeU6HkJtYSV+t9zl ieg+xDSJjGRm0U0exJqNjyc3yinW0PfeOvQnh9rKXSE5d5cPyZgt+9WYKdj+ttBDkELE3jxTy1Mw nREZDSlYzN7630phT+4E9znjyqpSbE3bt9hSqqEiegQx0poh6f7ggV2gf5VvpQ5jasHQ9/ZJDFOx 9XWdVJKKjRWN5Isok4iHUqf2eIBvAaQrrqUKPukG3zkOMG6lSnqkphC7UvRLKvbufjx/qYwjO1cM +WfiskyG7W+74zJl2Fl6f0qmDJv/ZF67ZAN/D78OsXLyuOyF2yNw/bKG+ZMMWy/9zqWkkY/eaYGY p5dRGqFL4weIXdBiprE+e70MsoW2qjkNq89dCafSsLk4OnU6De09tmT52bLGQIjFO/vIsXc6oZRl cmrE6I8QczSokEd+OcqF/GNJt8qxc6mDRQ/kXbPnwbP7SzGz8jelFb9BOp8I9dMf3GNwIbm4BOv0 qfs6tyC5N3ybdCwuw5Xy9M2iqSJILjpGkY6tB5fItDIwnVruZhnYHtaQycqYulAHntM2rA5FdSpS 5RnYuCXnb0fZy4iHGZLOrRYQeyRPyuQYvn5L/yOal1uUmYnt1Qz8azK1CQvA710mfp2JzY3E/M7M 3n154NrmQ0591iDpMbi3d9W5lIX11q2JN7JyvmHVQTqbrB5mHWl/2gSxkaXC7LxV9Etmf1Q5p/MX blj2yJnkb8AxpkjNJp1cD55VtoRnZGN5qNf9JBtbT7wL2JI9ZTotgOy8IqzPpsgf3YVY7eqmbIWY /zdI5/bso9n175LBd9RlFpezsfxFM6azpXtlF8FaMnqTjfWlyAJ1hV3DoTuQnbPqzQpsPHzle1DR 2TOgDY4jj9cKdmJQLMSWOR1dgZ2/pNsOr+husF4EManyzRXY/sEz5skKbE9SUvx2RUO7NXiu75qW m4O+2TMh5kqMKsH5yN09Opc5EHAEYrlhX+VivWBd9EzudAvtHhTrZSxOHrr39a3Jw+bU46S983Kg 702kzjw1cx8Z9L3ryjfysHuuXcVm+ZTCi9MQ2ygMyOd+UQb+/ySTK9flN5ZXwXuLrMP5WA0q5x7O x/a3velGBZgPyhVBBc29j5whuee0ogJM50+KuoI7VQ3gfTgzsLMAu+O7lMYuxHqkiX98oeTgv9i7 FvAoimzdk5kMkxBDIAECBgwP5WEIgUCIEGGAACEECEmAABESCBBCkBAChBAeCquIXDfroqIixF1W gqKyil5UltdykbuiZiUquuDGldVcxRV3cY0rj9vdVTVTp7trprtm8lC6v49v+HPqVFVXn3Pq1DnV 1Ycjtfr5fcTcZTXDj3+uxXdm+ZllwZXnNNdAI4bcVMKyS68Mv71k03Ppqtaksg1tiktYslS5dEvJ w0cOD9KiZaz4TUnavOqpWnVWt/9tCev5vR/+asnKrKpQLb4P2/xQwsw3CkHLWf18OXXRctZ+vqKR 9y9n7ct7dPiW5S9ZAoq0+nJ+woXlz+7YNEGL72BqA7MvBZHxpbPXRmrmc4bMOVb68LJ2mnbi26jv SlnvmS7ouGgFa52zJ2HXCtYc/ouEYytqTi3QnFOH9fjTiuiww99o0WblfrZi57muz2rRNvaKXcnK k2T0TFwZ+nC25v7PtzquW/ne/SGHtMZ62+gHVrLu4ZvuD6/cP/E2zTzlF+13rGTJ2S8nf7ky+HNh rxbt3bLOq17IqTyhRXu8qHAV69luaf/lqov3dP+PFu3BiMgylv5dSPxD2aTX31HdgVR2Z2hNGau9 Ba3OlLHiL5/GW1fHRG17RqvOR6OnrV7wTY5mPqcuesHqQ8921oxRB4y/d3XdizvCtWiHFz29+sC1 s5q+23u9reWsNfqn4xLKWfPRq/Yd5cOXV+Zo0RrCdpSz4gy9Oh0uZ8lLfNH1cpYNecqauYblFwwb f3TNobaf/1lrPK/ZllaMveXkVC2+wkX3VoTWRO/V4svuv6mC9Wyru/6zgrW2L1h4jclXHBy4liVn I0KC1pZ8+dBftWhVc51rWbpyz+JFa7e07vyVFu3y+ofWss51yC3/eO2tsnyq7/1Som0d6x7ujs9j 0j6ZsZZJyxlxfN0HISGaebXTt55Zx3rH6MPEoetZPt+o+WPX1z156qQW7UnHkfUFabWHtepMrji1 nmUHv+pwYT3rGVnwr+oKE4Q2m2oD227afq299PnB2kC7dAZLrBeO12wujtdsujh2Wl0cO626ODYG uDg2BlAcHdXlhdYyh6OVi8PRyj451SJMEf8t7S2y/fclz6xV7iGoCjTGCu/MECu8RQ1W9ugUWFys BRZdowM5FI2hgqzG9ous6Yh1v8VucZW0WLXLO8X7OnpVLu8MsEuFYt1CaA3U5KkReeIQT02APRDz xAoBbr5WWny54vBXXZH5cq3SF61cfLGCleIN0uC9JPKGId5LVnuQgjdWsNH8rdX8G0Q12PCjzL/B Jn0dScUfK3+V3F3HTao6wkTJu/QfuY6wQOlLQZp1xMpfH6fqoZXcJcG5/yES3MZDPbFCK0VdbRV1 xdnbbqr5Qa4rzm5v66WuWPnjftJXJdVXqFyfILQV/8n1CYJd/o60PlF3EMnYfs2LyXC4tThA7qvn ksUOVDLAa0lna1TS6rVkWCgqafNasi4MlQz0WnJ/OCpp91pyQwdUUnoeni+5Bies52YJyvXcLOr6 3+nRZpZMCHCX9HRZhL74k9jqvls1TJMoFOzmC1zNIyY9HdV/S8qSnNaU+aQ0rCmQa4Y9hbaxyexp os20p81kT6X6rILyAZH6KAkS++ZQfD9+qBdpMmfnG1GafDFlTpa9rLNCe0keCbg0GpE4+vjaLR9Y 2apFuSocquW7obbLj1LAj9NUrpavXPJTVWgIj5dCu1OeSw5RljSsddedsLD0tevWct3SanbtVZ3+ DPLe6sRGolEjdbL3hjRMZlHpCYPFm6pYNVRFZNMzETFY9aoLYk8Uxf0UEnfRKxLZjWgMowqjSmPV EHaxGh69YVTFqzqoOin80tAgV+doJVXXrFOTn1x5DS7XJS1s/Nx/D4ZDp5JbXCVZk5RkPv4XqcIQ vZNUtciTjXiqjfh/R0Vz6kTm9Kjd7hCUAsHSOsR9UFyl16NJ6myQPVjFbYM1aExT+4PFfqManK3t IZo1BCpqUU9U1SEu1Q0LtYcya7Era1JPVaFtNyWimsra2MM81tRKVZtyspLiCFiBU9rZ23mtzUFq 9EnqPKzZ+xis3s/eH6NnFqGf3JqWd8qYHdg34w8LYxdvxo5uZo8uC6PPAw/CPKoLqYJG2IE1S/vL m23ysIM4j/nky4r8Pvuy4uT3U14oNoqHqiip3z92l8wO1FvSXWcfmcJhKgxEPRUlyWXB//QPJ9sp z7MznPJGiU+yUkvGOTi7J1kai8bTjaSe7mCHJcEhDO9rGZ3aQZicKoj8guBaSERzdli/sVf2ryaA lEQW0F3Syiwp6bpU0sJo3V1SSldIJUlMwMYsKaUrpJJW1/QVwCgppSvirlqF3qId6INrZZWVHA1U NhCXDWCWlVIWqKzda71S0gKVbeW13vROpKzD99iRv/Mf8m0aEDejvgVblKmAlVJbzSCVGaSiJ3ZT hkwZctXV2FkEao1zlumrhGqwKrcHfOI3g+2tpNuD3EhtOWCtqrynrm2s8KeKCSiQTa1AesOfNrUG MYKPmkpkUyuR0fCnTa1HjGCjR1WyqVWJN/xpU2sTI16pS6FsaoVC1Uk+WuX3cnXFDiPhT55gvEJy pUsaz8mprYR08d/S3hYkh54u78EF1YJPQw3YDjVrzwfvnENxiOJvE8joIi7VnKPJZZc/3zdQ0DPr SLHLsqtEPszYZcuNXd4MFoaCvDAURklrwwhRJWyi9tjI2rCPwF4bmuksMP4s6TTTWbx+9j/lYK1c 5QiybVoWDaanMEe0ImXonuY4aMlqhdm0JUvFRkuWjbBqSpaK1ZinoGL34inoqULLeEbTlWjIlaoS fj9hlcMlV6scvvsJqur0ypUy6NMoaRX93jO7O32t7virXJKpEL4HRpTOk9SL1tSgTE51iLfo8Hfs R3985gbYO/9zSrqI9TT1utrzAnOBOM5PoHFeYNXnjqhYiBQFYDbtSUPFpt8dUbEac0dU7M3mjqiq aTHuiKq6Zthdoz3jeLqkNaY3ug+d1OByXazlbZPtRmjGVIQy6zPElUVBm3+swizxD3choqJWckl/ 9WyaVIsQ76ZJxeKHlZLLqjXGSknFbpom/5kmP6zlfxIS6h4+XaymhLZYCTWWTGivkuXRqZGiFAeJ UhxE71YQNCoglwX/80deg57x5DAAU3M85DXYc91ekWk6YtqryAEVGZ3reHpmZlzoKsyMC0ur2RkX e6DOjIu/JVeDSSt+oCdPYr4tyhVB+Aln5u2oPkF5McTO4irMZy4bwwnSZy6ZTpAfEhrGzCXTCfJj QoPPXDKdIG5z2SiLW+WStaMTNiA5LW3kksflRpDnRDVQLe8T9cnt0uohT3gA5rIVw8BaobDNO2uB 0hLNu9ahH1rmXfBSGhpzgerXz9dse1YQ+s0OT5exONdNmEd5IRPxiFhyMZLGR3T71t+ITG0R0zem b601WZi+tVQl8y0Gfb61ZzuqtZ3Isx2FHMrtRCxLCrcTNeWLkCnoaRx0mJuJ/LeZSEOekPwPFa3T SWSdhroihyTSrJPFdJpvYKdZv1/JNmpauyr1G0zpj8pNGlJJ5B5nyu4F0z127ZPTqMBKNTWqr7zT tA+iKgqTS/qr1fU/eKFhPiYqwQikBMdcL+DGelE4leZ4N+IMRrtAP1SDSqffmDMqMGbPGRpj3KQz KuKz6gzl4zfsDPXTZ9s9XS5/mSmMmjtAcYyFIYrmDtCWYPtb/g5QlkU3z3ozY8GNF1TQ9j0aYUZW MTXJjKxibpYZWVUJ74ysqsiXGVllEn2dkVUV+nFGVoitdrDYeDzVs4k002U3mon0HAOVdq9/gMa5 r2vDrWezp2IhUkQiUNpGT8VGCxLxN7VNnopVKUukw9oGT8Vu7hlqsRtuOV5u8/5ShD83sBo+Vsvz nr2vRdkMR7L5tc4N7yoWffqnYtO/+lKxGlt9qdhN/WuKPXv+OLElABRmbaz2ozJrVQOV2XX4kZ5c tR+3soNj7HxoVYPLdRHfkOvsPmX0s9IlCZVif4qv0c+VVTLaikpaXAcUsUrut6GSAbik8ogod0mn HZVkHdLkLlnTSirp6ZAmd9ncIFKWdUiTu+ylYFKWdUiTu+yGEFKWdUiTu6x0qBQq649DmgyoZyxT V1DH6BM9tEpq5909l9STnWxRc5rbKdTFas5pP8E5zbjSaO28QhPMGzb/e4v6c1eNcr6/GU41YwVy XY3/6QzZ2vqkt8hovCw2MhE18rLuVzG4lppe3UqDb9ujQix7ZH5VzlS+xo2mMEXPPPDQFD/v4idd fjg7Wnk0MLF07J2SP9gMn/fscQs6i1X/8YvN82o8mzVKZL1gdHpTp0B9NTCKRrR9WSkHquuDU6KR aKVwSBGXvi2s+owS7wZW+A1PYyYJ8ho3SZCfzyTBOvhNEqzHN5ME6/J9d4npUZlTmg75ceo1jeYh 96yyLeGQe69TvrH0RtNFMFkGRkcE00FY+SKY7gCoGcE0anJ8jGCaITlzDmuOOcxgdNvBqNxraEx/ XFurep9eWeYJoXudPPyVvRZgNfJlOquE31R0L4reKCGAPjZFMpgppFo5M1k+NeqO1NIOD2psetfN 6117ulznUjrh3yVT24YytapTKbDnrRhcc+MJKdt0G0+0ZsnW1KNTzOKYSYBM0sUI97qZmuncUI2u qsJKZnZDwW/OrvTsavCwBsHDJVlM6XEYTJh4jjpslBIh6GlttOmLOqhY9O2bUrHp3zelYjUWdVCx awk1VYVG1EFVBV/UQVXNz2HflHvC2G9R+1ie9uvynPav5S+ap7OZB014F3GugyY8XeTodT9ksLU1 wdPl47nuBtVRUZIjVGFQR6m2zSNnqSqMaemNdCwWpyLg/L+K1ZRLUy7p6viPKdIQLrYro98uo7nJ FFxTcBtJcM3oKatsi9+bYHBSs5DCijHneWVLWVLXvjyOrHQzHSrRnF9xM8NpKrnzcOYfU0JV52IL 6qvpP0rF/vKX/kZc4XZpmcli5V6Z+mncUEHYiHzJrObpMqYh4DEEPN904/v6W7BMU8sv0isP53ub r3YJppY0nZZ4uryfB6ZfN1SuIVM3OPxOo9FQ/f5BS3/BWutODG+R0779QEZJQ1vkmmT8/HDUPc+e JDO9bxpYX92QDJdZ9GELSz+mSDO2wnUQKLugb0cr32ksrH756fglo2u6xnD6lAPj51dDdRhLZDdg /6TLe4jXXC2ZZopvtcQlbmZGgarCzCj4Hr3z42sVfvfOzYyxqSaNpibSxRnw9UGkfWAVDLGqOty8 zl+jx+9967hUZ7DGoryDR9eeww33HNPMFs1MNTIz2a4vdaHCLIOmYmn0DZQq1ibfQGl+rYU572uI lqChZp7kCpVHZwDL5YfoXb5UizzZiKe6aT8oWI8WMGeDzA8K+uWDgtypF70CiMI1IQwO780wHTzz C66mg8ezHG+W3d2N0p1GYW2swJsPrEjoeIwH8yn441B9yNEoabGfzZuWZoRTv6PZUiKc5mZVVtmW sFnVqwHw6zfNVQc/K0p6TaULGkzkkv7q+ZXa42Klw9HNHqdsPBpHloOoYrIJRPBd36nSZFS5iOZ3 /dwV/Ry+68cSNvb8aMXd0MPhFjNX571xGZohpUV0GZIw0eU2F9HNv4j20VKzRdHckmg6ak2z9vV4 MBUreoNYJX/s6GViD0BCAl9ONat0EXlunsUoW+vUS75Yg+PMLulta5A/ch4Gd0X7S4S4RtyqwbrU zPCy/DozAOi7EfRd8d1KqvxC209xC7Sv5oat1nViyWjUnTrX7nSy9tLJYmY5vTs0vEqtf6HWDFlO v2yp/5m9KutLRNR8VZaqy7ijjQaHZenuE8WxHJmt+8wMpunAGHRgpAevDLerX0mwyHuOLB5eSWDH fO2BBl7u8fpSFGVW3bFsh9usKr8I1CKNqRm1+MlHLfzo7zZXllatE1prEaswSJCSKI3WU66j9VvS SJqnV7PKNuHp1QIcBfnSEC+wdjT3HJiTgiBNCrKcKfTIQwaaKWs3xHkn5mqOqsu4rOF8rqC8kA9/ THy2I9CzPaZzd76KpaXHrVTszRa3+hl+N6xRwsB06siqUVLXyq0FJsyQRLB08aoop1Ykp1dduohc EpYuqliILpJdHNq6qGKjdbE1YdXURRWrMV1UsZu62BTf8IMhYDNmYboM3mRJn0HzdEmnKpkvw5ih 5EYLJTvkCtTCpbU2srhKmhvKTDPnz/PVuY5W07/dnKck39GUnMPB5DDPQTOVUKcS8qgU5wZPz6we V4ZyOUVXyWXB/1raO46NsdTV4LBqcOj058y9jaY/18jhJL8cwOzbLkEtlZJKaWUCeHYq+nAOI7O3 xrMLpg9t+tB0fb5FS6U/+vmFiVCNbo3qG2BoSvXBvWjUlzx0jamny9i53q0wj/JChlRzP7TnWLa5 H9qbI6BhS3gdAQ1z0iixbO5Tnzg1AT0nllR+Ldr9cGT3v7YSqSSpEp0s+qRSxUZLZTBh1ZRKFasx qVSxmxkW/2RYPF1N+z1VDfn2Mt8yV1+7RY4cxLHbXH1pifeNtDFbayWi+yUUT5enL2xwHPruSwCH cflDgzX00vSGBJVimt5QoFFviD/W7w4mSKNLggn6ww5YSgXlhW7ohCgzSUhmTri2rNgQC0OwVSzm 9rEb1KHyLK6q2JeGEPKmptgcAbo4rMIskXCXF9X0X2pPe1TQxbrHn0z0ztyH3qzRO2PnQUqXlotk 1eCQp4N+vKrIVBb9y6EGsaQD1d1gZqAhv6kEQAkU0ma+UkXKNu8rVQyzoieyYeaVzcgGUvBQuQKW cJmbUAVTuPiFi8tyebqMf123hZ3EZBcbsaNG9qCPECoa0V7N4MOSlG2wPUtSmG8CaIxAgz4dbcwI mjEdbYoIGp+OMgMNfv16nPGvI/GsQprnhXD3KoQls+YahK7np/LGjfRH9nteVNCnyvhRX+b2rRtR 7nxKprGM3g1xMoEpfFRdLfhoJJ5TgjUkG3kgZi5Xlydq5nL9bG9ZUilosPqUA2NqpDJL5UeNdJ/e t9PKOr3P8J34cgSYTd2YXYMVnVQolZXLh6gtAJvLW8hIxSlqMuIMFLx792xuvaZAVYOox6gGHdbA Ffa1O9y1IG6+KY/qh1gp/5QH6/FtyoN1+XW7vMsFGuBFKelpkrX5VdVbl5ogcW05H3sxv5jqrqll fOyFLU+mi2+6+H6zd7y5f/0lDfeC8w0glhH2mBDwvH5QMXk3xYxlwA38eTeV+9+iPu+mWk3os9Do NlnCZqY2XUNHVWGmNg0sVpvfFAcwODzaU0+XlGB14P8pLw8hHparbIZ4As0Qj0JrWuxnyRSN+OWb SBp1ej8PyZAJkC+nBoeA6vGtw/44N6lRYnrmAstcYOmxNr58SsCAHvr8mW5dx5PKsmTkeFIYhNMn 85BHv8xDPmMyD3mNyzzkv+GDqE4ouGwjrtza7WV+QlJu7rAwDXTjJbk9vc6lfXl6f9rIJ6zcl2l3 BX2ibNpd46LMLaqCE0pboo0cQIAWmyiDiE4GoD4LFy+QL0ax5wXlCWm+ZId1NWKTSMww20t21zEt L9npgEEAZtMOGKjYaCVqR1g1AwYqVmNhtqt212r/qp0vzKaqgi/MNt/hMujzHb6F2VRV+RZmezvI FTB4O6ipw2y+neXr+VzEbLHuauSDZOv8NIWKxYyI3cARsUYJWh2nphzz9RHz9RHv8suVB5EvhRCS S/pra9f/4IWaNL+XLADhM5NwhoTPs/H06qo2aWxQ/+KgcZakzRT+NqMrLfQVAr9madQyp1IGUYBs QqaQLrgMPLNryjN5Oc5UaZTt17o/nm4sP6l97rJvKcomee3ZDASbpsp/psqvrz1o7ef2LHTm6UY3 nth5uowdNYE3QCkrYfqETWil2asvxv6wlqdZ5saLn545b/Y3+bzLODPC4Dm8ZUYYbqwIgz/yD3RJ rq8seY6jeZJyRZ84TxX3PeDhj02HbB/xBxvDR/RjKtNrltbzGwd9xfnlAzS/9HV9YMNznkjFQgwR 9jcYhkjFpj/OTrHyxNlVLTdbnugGOA+6RhIeh3vmQUKIHgtLW3160VWO4ZC+ohZU7psml10YKHIM FPQsjaRXXcuuErMvOelwbFgCiLjNV11Zwodq433VtUk21jepz6jc+yjNOmg7Taa8UYX5PQ9pSvR0 uVeO6v06wZr7dcAmHQM3wj4bFouyhd4kb3GVNANv5krNLyu15mHVZ1BYIRk0CR8TxXYEEttjAW6P 2bM7pmJSzoa6V4Y38LvGqopa1LvGqgr9cRoEM2zBFOSNAXBmZAuy+T6mF5Pv11WFufuM3+nqK/k/ YVd60oUXtDpTRuOg1bLH7bqCg/f3ofGWqQUxNP7x+vXrNL5HgR9Q4Nzyj9fSeKOCvlmB1yvwvQq8 QYEbwnaUa+HK2CMWaayu4fJ1GN9k6TqbLk9wUn9E33pH9gSaTvBWTJ/S4zxQGILP9YftxcQhHJRw YDhdnuDNmF4Y+Jssmk7wWUx/L6wfeH4E9x6A6H8Z9kVnmk5wGaavLeiWTNMJPoXpXcLeHELTCY4c iOi7pr8xj6YTXIDpK3q8OJ2mE3wQ06Oi68fQdIId8XC8shX4AMaVg+8H433CPupWLRwxCJX/PmLu MppOcD6mr7R1p5w4Nz6A6a/aoTwRbBuM6Hc7ssHzJDgL058v+Vs+TSd492B4f5cx/jp8Ui+6fLuQ oC5aOD0Blb+z88NAHwmuwvSjkSftNJ3gS5geHzMvnqYT7ByC6PVzHxtP0wmuxPTK8HFpNJ3gOkz/ xr5nMk3P6/LaSBqHhEY4abx//F2hNK6NrZ9J449Wlfaj8fTUvX1pnJFZOF8LxyWi/qxqNXgqTSd4 A6a/EbGQXiG4cA2mdxj0DpBvgqPvQPRXRn8F+kdwMaYvnfJSKk0n+CimT5o7cBZNJzhsKKJ3Gj0N yDPBuZj+do+nwXgQvB/Ttw9vnUTTXXgYog+Yt6SIphOcjul1kfcA+0NwFaY/Gj1tNU0n+BKmv7fi m0k0vTZ9spPG0WP2FdP4nVn/C+Q/ueLUehp3bJcYTuOve38Lxr9dYT54eW1jr9iVNL5j8OQAGj8+ 4vlCLexMQv2fmzG9PU0nuBLTbxtWN4ymE1yH6QHDd91B0wmOuxPRW0clgfmX4A2Y/q/+J4E+EFyD 6Ql37bfQ9M0pyUtpPHV6T6Afo+Y+2ZXGz6W/AOwpwdHDj1gkw/tWx3Vg/Db0HA/sD8FFuPz5pRPn 0vTi4EAw/387JQu094fCvTNoPKNv4t00Hr7uYUC3LX1sAY37Zv/xLhp/XDEZyNsHi+rA/Grref4W GhN7fHA4Gs89k94fStMJjhiB7m95tzgnTT8T+CHoL8G5I1B9/YsrgX5/OPNdYJ8rx0+OpPHhWw6D +80TgpbT+NyaX4H59OqENcE0Llh4rYLGdcKSiTT+KLg7kMfqwmfG0Th7zQbQv5v7v3wnjZ/puSuB xp/eVA3KHwwN7UHjgnGx0TQm8rFfHB9JEd/KvALmS4JPKOhnMSbyexE/jyvTPwf6/NeIAcCfeTl1 ERi/aV1fBgumbqPWgEXb9eX9gD9F5CPRCefvTRgndjkB9CE35XnwPAm+hMu3j+sJ/AdSX85IWH81 xh8mDgX2j9ysbdQRi4MqnzIK8u/GuFdSEdh289Wwb0Bo7bPVRcDe7okfeRuNA9a/kyv/ZzSqL9U+ AzwvgtMx/Y8ra0bR9LF5AWE0vjz5M6C/I0KCgH2YmzAhk8avDrsd2N8fYk4C/53gKtx+Vq/7gP5X t/9tCY1HrX0GjEfZ7NGg/k4ZvwL695euK1No/HhR4Soa/2b6euBPPnfnf4B+fjJj7ToaX0q0AXzT nWXZNP7WPmYEjWvnVoD60gITE0H5qO9KaXx0+Spwf/fmzepG43YpA0F9oy0Nt9N41S31wJ4s63oR yGv/gIFgPdE3dxuQh5yZ7+TReGfkK+B5WVM/A/U9ULgVzG+FeflAPh6MiATr1fryg8C/XBb1DfBX X69IBeuFT9pbgL07MHUhmJ/2jpoyiMYfd3wDBGNOzysC8vx+1Cpgz59vM2IsjT+NtwJ/qEe/rYA/ b8qbYH156/LbQPDkEeuSDjRenrsQjA+xnyHJyB7Whj4dRdM7RPcF43d1qB2s3yKFqJE0LoiMB/LT 0KYY6MvW3BzwPPf2+g60FzvlR7CecIy7GfjzP4z+aA6N34/NBPQ7pk4A8ZA3Q6NBfztPnjOAxl1y 9oD1Up9JzwH9yRj0FpAvMn9E4/Fam3oRyO8rw28H90vwILG8NDFcSPwDkL/04tbAXyT0dEX5IgXe jPGvk9eC+fZJxxFg33t0rQD26/2icuDf3Ly0LdDfHzOnA38lYPy9QP6upbwK5Cej6z8W0XiyNQz4 jydWLAX28JOKN5w07hV/cjCNbd3qAP6ySwDwDwjeje+/cN404O+usp0H+vhj8oOgf18vTQH6UdKl DozP4UVPg/v9pvvDwF99P/xV8HwTh/xuGo3zSlLBeK5uv+dmGr+b8hDoz+AhHYF8Th37P0D/LwVa M2jcKew0kO9jt/UC9uC98nzgny8eMRzYqyt3Hwfzzz0Zl5bQeF7yk8CfHTb+6Boa//MOJ1j/du55 D/B37u/cDtjTN29/ykbjk3d2B+uFIVOrwfj/XycYPyL9O4r1rV/7MjA/TJt0C5i/BnUbAOwpwbXJ aD7PCX4R9Hdxu75g/KbO+R2ob/H8DLCejx1aDObnf68YC/ybwMjzQH6f6PFZAY0zVvwGyM/fwjuD +SKq53Pg+ZJ4S88xqP8kvlKKMaGfUNAjxkJ6/lhIPzAW+ne2cbB8rgLvHwf5hRTIn45xVMQtIL5B 4qf7MJ3gKwqcNh7iHeNh/RcV9JRUhEm8bnsqLF+fCssnT4D0bRPg/VzCmMSnnGkIk/VXZRpsry4N 1h83EeHiYaeAv0PwhomwfM1E2J/oSQhfiHsG2I/siXbg/1cu3QLkh+AKzE/waQWOmgyfZ9FkeP+H FPSQdEjPSYf0fQr6FQU9bQrEO6bA8hcV9KQMSN+K8ciVL4H1JsHnFPSYTIgrMmH9pzNh/VFZcPyL smD5U1mwfORUSC+YCukHFXTHNEjPngbp1Qp6g4KeMh3St0+H9HoFPTEb3s/mbEi/kA35B82A9E0z IL1WQe85E9JLZ0L6iZmw/YhZCOcGnl0sUBfBpQp67SzIPygH4kqMf182PI6uj+CLCnraXRDvU+CQ 2QgvKv0H8PcILlLQTytwzByIt2L8lDUTzJcEX1TQ03IRjiu5G8wfBO/D9K8Kt4J4Znmvv6Rr4ZA8 OF45GPcOeIQu7o5PYfqYsduAf0KwYy6i1y5dD+IxBGdj+tMxPUC8eEA0XA8QXI3Lz8r9bAVNJ7gB 08/0/gLUR3DKPESPnvAdWE8RvB3TA8vGgvEiuB7T61ffA+KZBCfmI3o/K4z3EbwZ0x8b/g8QL363 5F95WvgsLn/NthTEzwjuPR8+rzIFrlXguAUIr5k6B6zHCd6K6c+W/5BL01sl/Av4UwSfw+U7JE0D 8XiCYxYi+n91fQbEcwiuwPRfFNiAP0RwLabPHbIL+OME9yxA9F9O/hL41wSXYvqhtlVgfUPmzxOY TvKtEYsQJvnVfIxJPvXAIjietkKESf40F2OSL92PsStfuhhhkg9Nx5jkP6swJvnOSxiT/KazCGGS z6zEmOQv64oUz3sJxFsxJv7HRYxJPjLpboRJ/nErxiTfeA5jkl+MWYowySdWYEzyg6cxJvnAqGKE Xf4Dxi7/AWPiP4UsQ5jk83IwJvm0fRiT/NkVjEm+LK0EYZIf24ExyYddxJjkv5KWI0zyXVsxJvmt cxiTfFZMKcIkf1WBMclXncaY5KeiViBM8lFFGJP8ziGMST4nZCXCJH+TgzHJ1+zDmORnrmBM8jFp qxAm+ZMdq1B8muRH6jF2zZdlqDzJL1SWITrxX89hOon3xKyG8XCnAmethvHxgtWwvQOrUX0EC+UI k/h0UTmkn8WYxJt7roHx5oI1sPwJjEm8OLoCYRIfLsaYxGuPVijub63i/jAm8ZistTCeUqzAWxW4 GmMSfziBccCq+f0F6iL9r1uL+rOy29tgvd9+9L0LafxNaDmINx5e9COY3++OzwPx3fMTpk+hsT0l DJTP6GUB8Z2i5cFy/iRpHZbn9ufk9eZ2jOPjrsvjdxnjwMT8HJr/4YIxIH5dlbYA3M9DbTcCHHf3 KpA//TzmBLi/yMEfgf1Aj0T+FbQ3a/AsJ43n5BeD/MlbMd1A+fvGzoL5/OgoEC962/IkGO+NOd1B fKWmojPIp8cXXQf7NZLmXAbx7MCkjmC8Q4NXjqTxW/MSQH7dUXhfbxp/2OYHsH57bUa57L+kr0fj v6TfC/Lz24dxh4hVcrzTsQHhcbcXyfYqH+NJBS/K/stRjJf3CQf9I/uhou5BdIJ7Y+xaD2BM7Pcm Bb0WY2LPe94L6aUKfEKBIzZCnK/ABxTYtgniLIwHhL0F4ikE71bQL2Mc1csG4kUEJ/8C0rcp8AUF HnQfwltT9oP4J8GbML1qrlPOP9Vi3HnNTnn+j7sf4U9uT5Cf71aM8+MfAPH53MV/zqNxu04WEJ9b E/RXEH/b0qkK+KOnhk8F+zNO29qB+Pr3YcJoGr8zNRTEQx9b9Hugz8fnJlpo/J5wDcS3Rk74H5Cv /CIlHMQfg2d8CeJrBNfj+yc4cTPCozNjQfxwRWY/EN8dMucYyC8sHh40ksbhk9aD+Ms9axJAvHNt 7kkaCseWvA786QTrJ8A+dBw/AdDPT7gA8r8Plb4A4l3bcrqBeOtNCy/IB5duxvd3Nry1HF+9gPEX 7XfI/q7zAYQzCvPA+DtXrAPtfz57GHgeW5x/BPnQfw2dAPh/kXAMrLeGRIeC+GbKzQKwf29PGSrP Dztwf+b3eg+s39N6loL18r7Ze4H8XS96COgn8dcbcH2u/PIWhIn/vhtj4r9fxpj478kPQv5tGBP/ /RLGxH93bkWY+O+VGBP/vQ5j4r/H/RfCxH/fgDHx32swJv579EPYPmD/vfgh2L+jChz1S4SJ/16B MfHfT2NM/PeoSoSJ/16EMfHfD2FM/PeQX8H2cjAm/vxBjIk/73gYYWJfszEm/nw1xmQ+aMCY2P+U X2N5xf78doyJP1+PMfHnE7chTPz5zRgTf/4sxsSf7/0IwsSfL8OY+POnMCb+fOSjCBN/vgBj4s8f xJj4847HECb+fDbGxJ+vxpj48w0YE38+ZTvCxJ/fjjHx5+sxJv584uMIE39+8+PQn699HPrX0U+g 8sSfr3gC+vOnMJ34u5FPQn83RoGdT0J/PutJ2F7Vk1B+LmJM/PnsHZB+QoHDnsLjIaCr6Cno3+9/ CpYP2YnLY/++AGPi3x/EmPj3jl3wfkt3wfvbvAv69zt2Qf/9oALXKvClXdC/D6lCmOSfeleh+kk+ KakKy0fWxyAeef9Ne26hcVnZUpBfdq3nMf/enA55NP3vzleAPa7u+k8QPzoycyiw3xl5/wD5w89i ZwN/fVr/JOD/PNl2YXca3zdxfwSNn3MWA3w0bxyY318v3A7WFy8tKgDxn+8jc6JpPHHk3SC+1PbW IJDfj0ztCvL3C8e8CebrwkX3gvvflv0hmF8+mNcf+DcjhtwE/Ov07DEgvlo3+DzIr4UNfhSsL/5v wgdgP9fO0BqQr/+/kelgP8DW8TcDfyGy92mwvpnSeSrYf7R7biuwfzC7/yZwfwdTG4B/EWb7A6j/ i9JRFhovDKgA+1Mq16YuoPHTbUYBedozOgTsv/trp9lAHt6cOhLsp3RM+RTkJycvqJxD4+El50fS +IGRx0G+9865oaA/hwrebkfjcstYsB+jwXkb8B+/s5SAePDm1mUgHhiwahqIB8/qPhT4j99NLXfS eMmEx4E//afYZFDf+SntgH9cHfA34B+nT58G9Jvocz3W59BB/wb7OT4t3Ari52M7HwT7dZ4Z94eB NK7vORLoH6k/+WlUf/5dW8F++R/n3Q+e7ysBvwP7Rx8dMx/4jy57j+vrmvUOkB+Cryjoab9BeGah E+TXa2f1BeNP6Dtw+Zc7jwH5doIvKugNCmz7LcLpqe3B+ojgMAU9F+Np0S+C/u1ttxy0n516AOQT SX/3Y/6SmSfR/uvdCBc558r5kByMS5f/APzhdST+ha+1ClyhwLtLS4H+ftv5Nfn5H8T1P+HMkfeT RPwO4aG3/Vm2r8UYh4fXyPvRT2O8pf2XYP9gVOuBwD5P6NPdSeP71j4B1gefRQ0E+mpLnwj2/5zq +hGYn9oVdwbyHx+fAfQpyboHrEcyw9uBeMRbUw6B9Wtl+C+AfcnomQjyAZVL5Nfehd7PoPu93LFB 7v8mjN/NaCf7M3UYx09tK9vvpD0IW28eCuxdXfQCsL9n98KUETT+4aaZYPzOLD8D4jltkhO60fjB IdlAv/YFpIHxPDj/Dfn5bcf96RQ3A+RDvhxxL9DXX2fdD9q/ppCf84FBuTSeEPS0vP/2Mq7/0TEp YH0e3a81sDe1E1PA839swUVgb6LWdQb28EL+LBA/e3T4FjA/kf6lV0P/bh/G66O/Avf7/YploH/P BkeD+WRl0mz4/oXjITDeM2e/DuTveNFCsP9u4LqhwJ/IdGwE9/debyuI7+VNXQSe/7+FehDP3T/y aRBvJfcXuRfd37JBo0D//+18HcQLy6YFg3jkoSm9etD48vqHwH7ljNwMID+kvVLc3qXbugH/aYrQ BuwX6RLxPbDHObMSQLy0akp3EI8c1uNPID5A2qvF7eWMOA7izwTHPYvno3F/B/NH1MR3wPsylqX7 gPzEDFgF9gPes3gRuP+XltvAfHlH20+Bv0XwhmehvNVgPCN0GvBXCY55DtIrMD7S+xUQX+qXOhuM /9xJxSCeQ9o7jfnXJn4I5LFo5P2a+hG1D5UfNX/seppOcJmCfkqBI59HOCznPSA/BBco6AcV2PEC xNkYHx3WPZeuj+BqBb1BgVNeRPhqzmLwPAnejukp4SeB/Q2xdgHxolfy9oL9gGeinwD+156EXUA+ n+9hA/5d/i1lwD9w+WO4/W2jHwDzyeXbFwJ57BdeBOJ3BCfvR/wE78B4w5IXgP9O8GUFPev3EB/A +G9jVgD5/GfXVCB/BEe8hMrHh/cD+tqr02Fgv8b3+xjs3+g7shfQx7L+l4E9bzOiCujTyrSXgf99 f8JFsJ76qNXmbjTOzxkP3vcgOB/3d9fyLmB/BcHFCnqNAse9DHElxmOjeoH7J8/30stQ/9MOQFyt wLZXEM6N6m+h6yM4F9PJ++j7X0HxkT1xA8D6luArmP76/I5gv8kTAfvAfP52WEewf5TglFdRe1WW ZSBeT/D2V2H/6zHe4egD5HVo0CzwvJ+PXQ/0iez3GPTfiP/kHPi+woKOi4B+XWm9E6xfQuO7gPVb z3VtgT9RVPgA8BfXdf4bWD/+etUp4A8+MyQaxEPGLxoB7Fm7BWdAvCBk9p/yaPxt30+B/9BhYA64 //IR94F8Q/TMLSA+MzjzC+C/f9m7K/BHH+wE38/JT4bvq33buQQ876XLYsB8FbjkRSD/m8usYH19 YFIYsF+vZzwD1rcrkv8M1nfk+W/Cz29G7O9B//t1fB6s/wiuw+W/6nABzDfvlnUG64URU7qAfFby Cid4Hi+FDwb22pIwCcjrTYUvg3jH+NsswN58Oi4B2Kt98W+CeMi+hM/B/qJ/RDwL5Lck7W0wfqdv PQP8kcPzbSC/fN3Ha0fsEUu0gM/FcAJTwTjWUuK6KHLlCovQcRxOwCRztaa4FMdwkIZT+ktVRKMA qu6GpWu7yBktHQpjmLNe4jwZaPBmE+OOWKpC7JO1btZ9wmaMDZ2wqXmz26QqxAJaDbvP0Oljc5+h QzgvxEnPp40mp/aXCgnnoAESp/a5PZ45N8mc2r31zFk7gEeapKvnQEkcVnL0tnQgEiTjbZ6QOUu9 iCD93RHCGREv3ed4g23mx7tHRylIF0TDhwTpwrW2m6IsGoJ0NF7q7nym0rWR2b+Sh2i06FUxZFG6 ogfxPqdibs6j3Jxhg3k5c7k594ucdeKvMU4hQXxERUKm1iNSH8bLfDw5CVK34zm6vU/mHMjBeUXq ujCIgzNtCG9vdwzhfTwXZc4BHJyerqRE3v5sTUTiYnw2O8fdZswdvJwVHjg9T0en79CjFlpmOmqo JF8lXnqrxVk0lLfNQ3Kb3qZArREKGaZnbLXazNHFqam7mNP4dHSFu029V1qSNJJzeXQ8iVvHuTmT 7uTWY27Oc3fyjpDykgqH1UbINU1JRUcNZvTuKf+GC7vlXynGK/22x78d8G/HMPSbfWGPQ1UnLtMW /7bDv+H4l1kn/pX2RbD6zLpODBfH05YYIdfjFMAljQpcKASL9xusnBCloqqu49vMzAiTV321cTGo 66LBkruOh286Hr5scfjobhWNaGyFYV2tFHdD/k76YMH/yN+kslaqrPS3mn7obtviu22H7zYT320W Fpb2WFiMPshkJ9tPVRoiCx6bSqck/jlMHq8HVQfIx1TT3bjiZD+kAleV9EchNM6+jqUqLRgp9fFu +TBOLe9MoCqUvssn8RwYiTohMHiQANcEePDoyGMkj1x+ZIJ+3ZPqyBqlpxvSCZ2a3dg/yvMTRexo 6eDBLyVXyGg9/gN9tjHhzOHmZF37RrP9Ci4p+SleRMSkIaOtij+uYEHbYtE00q5U5r2eIaCMQ6NM OyEkkKY5ME36zQg8G6rFJ/0+3K0g8rqPl3Z/Ngd752y8y+5hjKWrLhmpjby1wy9qo7zixkgt1I3S UiP2jLhB5pqjqXxsrhqutqLH8rRVPJanraNcbYWN8ykqWjSOp6uHxvGs20NSeG4wJ8XnsO/BFB7P yzGehyubi6uai6thvE9Dk5XK0+huLq7LIleVkKWzq4FiVwPprqZP4Gm0aoJP43NFbtRojCktjaer O7i4LnJxJU3kXqlOlAY0Rp7G2JzKaME5rvZiJkltFXl5eKityakB4sMLYLmPmyexA2Xumey4YiY7 i7k8z39Krt6T0c3aDHGVTeYxw6cm8xjUyHSetgrSedo6yNWWYwpPW9lTeNqq5uJq4OphSgZPW9sz eNqSrnqRM3dL9W3GOBMzZQlua4xrc6aeUKuS62wmz4j0zuIZkbIsaQryth4ls0Fr0aC0pg1KbRZP V3tO5elq6VSetk5wtRUxjaet/Gk8bR3gass2naetrOk8be3mausyV1vJ2TxtbZO4nEKAVIBDjC9x NeqcwXODlTN42qrjaituJk9bG2bytFXD1Vb0LMmfuLcV68G1obhQuEhzMbNBquZdtjPj8dur8vjO 8uzXeK3AmSNPEII+CVTdxA6ZPUGTXWd0syFHmmyWClpjoO4BuIU+8i1k34VuQWsMdFVwEFeg5ebp qiByNqogkLcC6SqTKnk2JoBbFs7OlubEIzZuWUicI/bAdsTGcne9VrBdrKCq1RGb1jjoqkCWhzlo MLnHITuXLQ+6e3FQriSIvxfkisyTxHuepn1hR94K8qTmz3nRK4/7QE7ksTVbuqS39BisEXPdrPr7 LF353JzSdYCb2zaPlzOLm3M3N+dlbs7kfF7Obdyc0nUhX5Ji7fCJZ+5B85F51+LU/pyzxLVpvtTb gZrC6/4E+k6rxifQJfY6mT1Ok32nlbDXBrbdNPeKBnvSAon9Dk3212yEPdjRdtO4HxkqtH0BugGW /fA83PUy9yAO7sSF7OFmuzPStXmhZ0fISnGO6iu/2++evOoWog4bbzaugC1Znjk3FPDeak0BWxc8 +HyL0D5RrYfC5ioWuaINbzY+KnEZ3mgcVujTRuOiQp5NxocKpcE0usE4ZLHEZXRzcY7MZXRj8b7F PI/7ymLpcRvdUJxWhITEWFs7ZC6jG4kvFkn3ZXQTcdIStl+gYxPx9iVSV33aRNywhOd5pNzNw7Wd i6ueiytxKQ/X5qU8G4XPym0ZNZu9i93Tqn6usmKeDOGpYp4eRi7jGcMCmcvobt6DXG05Snh26maX 8LRVzcXV4IGLbcdTlvPskt2+nGdXbj1XW4mlPLtxN5fqGUNlW2d1can0awXiMmbHy1bwtHVqBc9+ 0ciVXPrFxXWQi8uxiocrexXPaEgEf+2UlevCNF93yDrLjviy61Uq5q8dr/VlPI9Da5cq4bXgf/Sg NdYO1aOr2c6OUiHJTtSQcr/tRC0r92yJDe0tvFBufPcpGV/yHOSxFPQLpVRH6f+3dy7wUVRXHD67 eQCCNKVAEVFHRY28BHkFRQETHlFAJFFQUdhsJmQ1uxt2N0IE5A2Rl+ElURGCBgUB5REVWypYsdoW W1rRgqVtbG21lbZoaUXFpv9z70422exudu5KS3VOft/OZGbOfc+dOfeemZkuM8Gi4Dp6aHrsKmjC dbTbjHguZuGm8AwlrYMzvkJXUKPoOXijaUdyhYzlAtk8wr5EXR8jhxlyXzw+M576MvqeJNFvivoa RLVxyIgHogffeGSzXvCyOVQlpk6zElI/kzJBJC3ymFXjpCUjacn1k7ZnVuiWSkG97WwzBdNIvRjq NUnK6gcTi722NnS6ha8PnsNBm57tnKNy1atRiqvnXBXjZfZclbgOKWlp81S0ipW09itppc1X0Zqk pMWyY75K+6AFKlosY6BZQ+OTzGlWCq3mJrVOCK09dnNagxeyVqFJLZZy1uxa3kQqw42mmoWxx6Fa 1tOK4FI4cFFC6hWJqSciJxdJv01zxZVVxlqVCk3PrKwuM1M0jbyDT5TJoVBF9ZEPJhR7U7L5qw0+ ebFKh5C7mBOh7Aq9Y7HKPAYtQVJNz2OMYS3T8xiVSxKaxzi9RGUeY+RSrguz8xjrhJbZeYzjQsvs PMbAZSqtZekylXmMY8tU5jG6LVeZx5ixnPNldh7j4PLo94xxzGOkP5TwPEbZQyr1cURJK71cRWua ktYbSlodVqjMYxRCK4EXnhxYwUk1O8nQdiVrmZ0GyV+pMg1SvVIlhcmrlC4Mq1QsiSqluE6uUpkG yVqtEtdqJa33Y2hFvwz0WaMyNTF/jco0yGGluDo/rDINEng4njIMj+tAXFqNzq+1UsvcZSB/rUpc 1WtVBv6TK5TOLyWtKiWtk0paWY98naZBuj2672yZBjn8qEp1nC3TINsei36vFH5CGtMgpx77yqZB 8tfF7olNjasfWmd+GqTT4zIBFEVHNqSobupG9RjVKKqC4m/THMbeuJIQdRalw/rYNdjELEpgfewa qF9o9Xp/Ja22G77hsyiRXsYwolIWpfoLGCoqo7eAUAPqEjSKU1GYqbIFHDnjUxdno5ys5FbobOKE Ma4ddW0v1kDQmI3xTLFURLNVwmXbRk6ho4kUGmNJEeeimj+hclUar6RlyGZoV35wnc28tnEux1pn 6fSkSvqKWKu1SroM2fukSs5aVcXTMxvV2KhVFFZxK3i9iUcAo6pHkgNVZgYpGwWpbTIzAttIfcYm eX1WVD+SmLqq9HkqoWjLE1M/Hpd6/2jqI55m9aZerxBVvSmpMhV8XGPqtPmMpXjC5ujn46q6oFfh LHY3DPplEfSeGOrcyZ/f6O7l+i50Qxdb5o1tY70w2Yx03sKFM+3c+BpTo6eCo8nsLbFz1rpezm7o kmoiMzVNhNzEIB7LwGdUbjVjydIYIYZ687F1Ax7yYZZjzySclYytHETk8ZnoWSnbmmgBHNkaPeks MR74Y0nfxuqR+6CNdTl/FwmYGC3n80UQ/ZrIwzx7wzwc3hZ9qiG6VuftKlosge3x1E+45gGhZTtk Tqvtsypx5StpsVRDk23I2JoZYWOeyc8hvtSkJuIL18plLYo8YRZdi6VKxNcygbYeLidFWiaKEKKf tvOiGfj1ZcyOeiciNUyckLRQ4trx1GahLTWUyM0JabPQTm7Y3qgvHWrYA0V48njSTnn7p/wU9v5g ClJVAzBE28WFUZNhvh3HI+eivnORTOP/GbtCMxLJ5pId7Pt3hV6moBTAwN0ygGTVANYFA0hRDYDl 9O7oZmocz86Orw5NL4Srx/HsbDXUaza8E1E9jmdn056H+hOR1WNef9+rO5GLnpenIJdK/L0L70jD 0bwMH+PLGXFK2Gd1Y3yDbcJbKXy4dTyOM1IhwqNmEcN7a50M73Bw2Y4ih9fh8VB4huS+EMpdpCYS ve+sekGlXE4GtVgiVUik4db6MvhF1ld5lPm/JeUvcoOP7E4TanIZsT7Pw3JcZHSECEZt/MGcLLST KUkhB+7uPLgwNPg+tyWWWGLJ10hqB9tmh/rfQ59+TPKy3lDsacGVis7or7l7xg9/SnR4+3Icbben JqUkp9iTkheFdbQbgstcXDPc6E79pNFoLKdiORb3o27R0RL1RTh2Skmx2W3NUu0pzYJqRrQss/kn h0qhkwfNIvzX+3IRe8vUZDtL1NiHkA/xO4RO/17lDfLX4APuFDJDMhFHidDT8Ut0bZxxjaChNJJu w28uZSOUIdg2qK/QbZbUwm5PsSdH1W0Yp1FSiDtVlA6FSaPSGQdND02m/OCSPxbc99vltjn1DpT5 S20RUm4ufl+io/QavUKv0l7WuiS+UuL68FMA6eQPtfdu07A1RNMKtYb4YxqO4/mCfB/qEbXYJj6t XMTjF23NLdrZJTAVp5SVdSA6gDrYIg57667hw66ZNLzgKJbNRGn0RVHvuIBD4c+pJlNS2qAGYdvq xdA5PGpLTMim1P3NqqkazbdNT27Q56HtEn6JShp8qbUp+aLBd3ANkadZbW2b4P9/QHsoRBvScHYW iTbLbSqAFuVDO9bQmgNY0/G/m9jJ1iNato8KsMUp9NKhmYM97K3hEi3LAZw4bz3iiGJolIieRhPn YLh+APE78KtBtxhbnDiqQJzvHNZU7HVhWyHW88VxHDq3eh3/s7YXv3kiJL41dYrQ+EyX+3lPAKHo Il8yNj2YPjfi84l4/IjDK/YXQbtUpPA8zS/C5BS7QKnIq0Mc1XBrKAeTg2ekT/wvc6BHLFd/vXLl o7yidyvButSS6XSLUuU48+ulnXsYLlsNvaqRWimtUA852DoEvxr6To6tCGH7cdZmiRxzDbhoCmLS xRElIhWBSE3lfyL/ruXepbFtYgM1CzZ88tnNhWlbVzSnrlfsPorTgwrtIbu4gmT7riTZ+y21yZcy VtjkuxV3YMmDUnux5MvpGzbZ0x/Bkt2BTthkWKexZIeQDnY56t3ZLq/sPbHkj28PxLI1liOw5JNs jF1eeMbbpT/PJLtMx/uInD+u+z7ILdS1oUW6W/cEHL5SLSfg0x1uLdsT0H0FDqeupQ/Nyb5Sc/k1 h+b0epx6caDEUaS56vYHCh0BzV+sO10FLt2vTS10OQu1fEfAoXl0PV8LeLU8XdOnOQsdnsn4P08P TNV1D9R0hOcu9ul+v8vr0YocpbpvpV9DMlyBUi3d4TFWRQSTdY/ucwQQgR5Kq1+k1a95fVqJH7sQ pvtKzeHJF6HnlHqc2kgOVuSV64Gwmde5rLJzRg7J0TIdviKvn5DvumOwPXyd62S01+d24CTk/7lM s7xul8c1pUTXMkt8ekDEwWXbn9wuXufyHuVy+rx+b0FAG+f15WsZPXqSYzCH27PjhRy+WF//0dQH PtpnE+ufj9s401hvdaxkCdaTgmnhJV/reMnXO+tSZoklllhiiSWWWGKJJZZYcmYkmv3PW+xvv/n2 uh7np61aC/u/22fPZmFbSti2TnZpz7O9zvZcIUkbvZjkGEAZyTGAcpLz6jxmwPPllSRt/c0k7c4d JG3LPSTn1feTtGffIBn2HltDG5/HAzJHD83VumtaZubQ3FxyCNuRR0mTgmngJY/h8fLDtOYiPgrG G2l5YfBhs2/K+EGrNFmmXJ5cR7kuaJJhmcu6MuxxLbi1H0md64P/8zqP3Uwck501cfit2Vl1tTQE y9FgOvXEXxbIpGH4603daYBY74e1XvjLEtsycEQv6oM1Pr6foD/29KS+OL43mEmWWGKJJZZYYokl llhiiSWWqIphw4mHKEja7GwL8twwz9XzPD3bd2wjsx3ONjnb3mxfs93ONj3P4bPtzv727Uja72zj 8+tM2I+mIzgfdAIXkLQ3LyJpU15M7BFFdClgd5vLwOXE4xK1tenEz0kQdQFdQTfQndgVm+gqwP4I vcDVoDfoA/qStFH7gwwwAFwDrgUDwXUkbVceJxhM0kq9gdjvjYjHN4aCYcS+XuxHR5QNbgQ3gZFg FEmr9mYwBtwCxhJ7obGnF9Gt4DZiPzii8eB2cAe4E0wAd4G7AT/7NAk4QB5wAvY70kEBmExyLMUF 7gH3AvYdZB839iLzkhxjmQLYG4X92NirpATcB9hnjx3HS8H9xFY40QzANvQDYBZJh705YC6YB+aD BWAhWERy7OZBsBgsAUvBMrAcPERyTGcFWAlWgdVgDXgYrCU5fvAIeBQ8BtaBx8F6kv6GlWAjeAI8 CarAJvAUeJrk2NAW8AzYCraB7eBZ8BzJMaOdYBfYDarB8+AF8CLJsaSXwPfA9wF7Ff4AvAz2kRxj egX8ELwKDoDXwI/A6yTHnn4MfgJ+Cg6CN8HPwM/BIfAL8EvwFjgM3gbvgF+BI+AoeBf8GhwDvwG/ Bb8DNeA98HtivzA57vRH8CfwAfgQ/Bn8BXwEjoO/gr+Bv4MT4GPwCfgHOAn+Cf4FPgWnwGfgc/AF OA2+BP8GtYBPfn57Aj/Uwg+0JIMUkAr4U7nNQQtwDmjJY3yAn3JuDb4F0gB/qrwN+A7gFz+1A+3B d0EHcB7oaJOPVHQCFwB2ErkIaOBicAm4FHQGlwH+aPoVIB1cCbqArqAb6A56gKtAT9ALXA16gz6g L+gH+gN+kG0AuAZcCwaC68D1YJBNPvUxBPALpTNBFhgKhoHhYATIBjeCm8BIMAqMBvyy0zHgFjAW 8BsRc8Gt4DYwDowHt4M7wJ1gArgL3A0mgknAAfKAE+QDHRSAyTb5NIsL3APuBUXADTzAC4rBFOAD fhAAJeA+MBVMA6XgfjAdzAAzbbJvnYUle13PAXPBPMCPhi4I7l+EZRl4ECwGS2zSv2tZcP+XYawK bjew5P9D2APeK3wphwp/SZ+4YsQv7dFjGGHxPURqCzmXsF/u5ksp7c3Ie2XsB/ts+3eeqmDfrzW2 oLM48fWbR+7zhM+mirTG3Uv9/DStgb4FLN0u0zlOeILmC29NJ66eht9ovNIRvSffM5mJn+XCkXKZ gjsHjtUd9FRlj98CkSa38GmVfrLRJR3xc0743i3e+B9A+Rue+ymNcm4uPRmI32z5L6wXv008ccCe wTejFdwTUy+StEH8HBzfs5opfyMmGSt7QQdwP+cNPtURv7RHDprKv9HujWWkYxIRs+VfXzgxVn/9 zRUbaj/pHNmGwvtutt+yvM4SnljUGjr9CptwVA6v4ghxMvN6D+PwHhl0csCuKZHbnCVnj/wHUEsB AjILFAAAAAgAXQfsKEtN9qEzfwAAAC4DAEEAAAAAAAAAAAAgALaBAAAAAERvbWluaXF1ZS9NUEVH NC9tZWV0aW5ncy9CZWlqaW4vY29udHJpYl9ub3VzL1NEUF9zeW50YXgvbTYxNjIuZG9jUEsFBgAA AAABAAEAbwAAAJJ/AAAAAA== ------_=_NextPart_000_01BFEC3B.FB24CAC2-- From rem-conf Wed Jul 12 13:16:49 2000 From rem-conf-request@es.net Wed Jul 12 13:16:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13CSrc-0005if-00; Wed, 12 Jul 2000 13:12:12 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 13CSra-0005iG-00; Wed, 12 Jul 2000 13:12:10 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id EC1964CE44; Wed, 12 Jul 2000 16:12:05 -0400 (EDT) Received: from research.att.com (anniepc [135.207.130.90]) by surfcity.research.att.com (8.8.7/8.8.7) with ESMTP id QAA07764; Wed, 12 Jul 2000 16:10:45 -0400 (EDT) Message-ID: <396CD105.BB653AE9@research.att.com> Date: Wed, 12 Jul 2000 16:11:49 -0400 From: Barry Haskell X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Cc: garysull@microsoft.com Subject: letter from ITU video coding experts group Content-Type: multipart/mixed; boundary="------------A250A2209BBAD0E6982DD34D" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------A250A2209BBAD0E6982DD34D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To IETF AVT group Here's a communication from the ITU-T SG16 Q15 experts group on video coding. They are responsible for the H.263 video coding algorithm. The latest version, to be finalized in November, contains optional profiles and levels, which is the subject of this communication. It proposes a MIME registration with optional parameters "profile" and "level" in order to enable their use in SDP. -- Barry G. Haskell AT&T Labs - Research bgh@research.att.com http://www.research.att.com/info/bgh (also B.Haskell@IEEE.ORG) AT&T Labs NSL 3-223 tel: +1 732 345 3300 100 Schultz Drive - Middletown fax: +1 732 345 3033 Red Bank, NJ 07701-7033 --------------A250A2209BBAD0E6982DD34D Content-Type: text/plain; charset=iso-8859-1; name="ietf liaison txt.txt" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="ietf liaison txt.txt" ITU - Telecommunications Standardization Sector STUDY GROUP 16 Video Coding Experts Group (Question 15/16) Document Q15-J-76 Filename: q15j76.doc Generated: 11 July 00 Source: Video Coding Experts Group (Question 15/16) ITU Contact: Gary Sullivan, ITU-T Rapporteur of Advanced Video Coding (Q.15/16) Microsoft Corporation One Microsoft Way Redmond, CA 98052 USA Tel: Fax: Email: +1 425 703 5308 +1 425 936 7329 Gary.Sullivan@itu.ch Title: Specifying H.263 Profiles in IETF Environments Purpose: Liaison and Collaboration with IETF AVT IETF Contacts Stephen Casner, Colin Perkins, Joerg Ott Specifying H.263 Profiles in IETF Environments 1. Introduction We understand that the IETF is progressing rapidly with the latest revision of the Session Initiation Protocol (SIP), formally known as RFC 2543bis. In order to specify the multimedia streams that may be used during the session, SIP uses the Session Description Protocol (SDP), formally known as RFC 2327. For real-time streams, the IETF uses the Real Time Protocol (RTP) [formally known as RFC 1889], and for this, several RTP “payload formats” were defined [RFC 1890, draft-ietf-avt-profile-new-08], including one for the original version of H.263 [RFC 2190]. Later a payload format for the 1998 version of H.263 (known as H.263+) was also defined [RFC 2429], which was sufficient for use with capability exchange using ITU-T’s H.245. However, RFC 2429 had no mention of H.263 profiles. For email attachments the MIME specification is used to describe the content. MIME descriptions are registered with IANA (Internet Assigned Numbers Authority). At the ITU-T SG16 Q15 meeting concluded in May, we prepared a nearly final draft of definitions of profiles and levels for H263 video coding. These will appear in the next version of H263 (aka H263-2000) to be finalized in November. Currently we have drafted definitions of profiles numbered 0 through 4, and levels 0 through 2. The most recent tentative version is in Table II.2/H.263 below. For maximum interoperability with simplified capability exchange, this contribution proposes that H.263 profile and level specification be included in MIME and SDP messages. In particular, the profile designed specifically for Broadband Internet use is profile 4. 2. Possible Ways of Proceeding The most visible way to proceed would be to define a new RTP payload formats for each H.263 profile and level as it comes to be used in the market. But that's a lot of payload formats – and also, the process for progressing from draft to RFC is fairly lengthy in the IETF. And as far as the packetization format is concerned, RFC 2429 appears adequate for all of these profiles. H.263 bitstreams themselves are also self-contained in that they contain all information necessary to decode them. An alternative would be to define new SDP attributes "profile" and "level". Again, however, revising SDP would be a long process and might have backward compatibility implications. Still another way would be to register optional parameters "profile" and "level" under MIME, and use them in the existing SDP fmtp attribute. This has the benefit of backward compatibility, and can be implemented easily. They could also be useful in specifying MPEG profiles and levels. 3. Proposal for MIME registration We therefore propose consideration of registering with IANA the new optional parameters "profile" and "level" to be used with the MIME subtype H263-2000. A current IETF draft [draft-ietf-avt-rtp-mime-02.txt] is in the process of registering many multimedia payload formats, including H263+ (aka H263-1998). Perhaps two optional parameters, "profile" and "level", could be added to a H263-2000 registration. A typical MIME specification for say profile 4, level 2 would look like… video/H263-2000;profile=4;level=2 4. Proposal for SDP to use fmtp attributes profile and level We ask consideration of using the MIME optional parameters "profile" and "level" under the existing SDP fmtp attribute as described in draft-ietf-avt-rtp-mime-02.txt. For example, to specify profile 4, level 2 the SDP entries would be (using say dynamic payload number 98 and UDP port 49232) m=video 49232 RTP/AVP 98 a=rtpmap:98 H263-2000 a=fmtp:98 profile=4;level=2 For interactive sessions, an endpoint could indicate all profiles and levels it was capable of handling by including multiple entries. For example, a coder that could handle profiles 3 and 4 at level 2 could indicate this by… m=video 49232 RTP/AVP 98 99 a=rtpmap:98 H263-2000 a=rtpmap:99 H263-2000 a=fmtp:98 profile=3;level=2 a=fmtp:99 profile=4;level=2 5. Conclusion We look forward to progress on these issues. --------------A250A2209BBAD0E6982DD34D Content-Type: application/msword; name="ietf liaison.4.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ietf liaison.4.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAVwAAAAAA AAAAEAAAWQAAAAEAAAD+////AAAAAFYAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAcQAJBAAAABK/AAAAAAAAEAAAAAAABAAA hR8AAA4AYmpianQrdCsAAAAAAAAAAAAAAAAAAAAAAAAJBBYAMV4AABZBAQAWQQEAGBsAAAAA AABsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAF0AAAAAAJQHAAAAAAAAlAcAAJQHAAAAAAAAlAcAAAAAAACUBwAA AAAAAJQHAAAAAAAAlAcAABQAAAAAAAAAAAAAAKgHAAAAAAAAqAcAAAAAAACoBwAAAAAAAKgH AAA4AAAA4AcAABwAAAD8BwAAtAAAAKgHAAAAAAAAryYAADIBAADcCAAAAAAAANwIAAA6AAAA FgkAAAAAAAAWCQAAAAAAABYJAAAAAAAAFgkAAHIBAACICgAAbAAAAPQKAAA4AAAASh8AAAIA AABMHwAAAAAAAEwfAAAAAAAATB8AADIAAAB+HwAAfAMAAPoiAAB8AwAAdiYAACQAAADhJwAA 9AEAANUpAAD6AAAAmiYAABUAAAAAAAAAAAAAAAAAAAAAAAAAlAcAAAAAAAAsCwAAAAAAAAAA AAAAAAAAAAAAAAAAAAAWCQAAAAAAABYJAAAAAAAALAsAAAAAAAAsCwAAAAAAAJomAAAAAAAA FA0AAAAAAACUBwAAAAAAAJQHAAAAAAAAFgkAAAAAAAAAAAAAAAAAABYJAAAAAAAA3AgAAAAA AAAUDQAAAAAAABQNAAAAAAAAFA0AAAAAAAAsCwAAQgEAAJQHAAAAAAAAFgkAAAAAAACUBwAA AAAAABYJAAAAAAAASh8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAqAcAAAAAAACoBwAAAAAAAJQH AAAAAAAAlAcAAAAAAACUBwAAAAAAAJQHAAAAAAAALAsAAAAAAABKHwAAAAAAABQNAAAyBAAA FA0AAAAAAABGEQAA4gAAAKYdAACOAQAAlAcAAAAAAACUBwAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASh8AAAAAAAAWCQAA AAAAALAIAAAsAAAAQHyyuHHrvwGoBwAAAAAAAKgHAAAAAAAAbgwAAKYAAAA0HwAAFgAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADUlUVSAtIFRlbGVjb21tdW5pY2F0aW9ucyBTdGFu ZGFyZGl6YXRpb24gU2VjdG9yDVNUVURZIEdST1VQIDE2DVZpZGVvIENvZGluZyBFeHBlcnRz IEdyb3VwIChRdWVzdGlvbiAxNS8xNikNB0RvY3VtZW50ICBRMTUtSi03Ng1GaWxlbmFtZTog cTE1ajc2LmRvYw1HZW5lcmF0ZWQ6IDExIEp1bHkgMDAHBw1Tb3VyY2U6B1ZpZGVvIENvZGlu ZyBFeHBlcnRzIEdyb3VwIChRdWVzdGlvbiAxNS8xNikHBwcHSVRVIENvbnRhY3Q6B0dhcnkg U3VsbGl2YW4sC0lUVS1UIFJhcHBvcnRldXIgb2YgQWR2YW5jZWQgVmlkZW8gQ29kaW5nIChR LjE1LzE2KQtNaWNyb3NvZnQgQ29ycG9yYXRpb24LT25lIE1pY3Jvc29mdCBXYXkLUmVkbW9u ZCwgQ0EgOTgwNTIgVVNBB1RlbDoNRmF4Og1FbWFpbDoHKzEgNDI1IDcwMyA1MzA4DSsxIDQy NSA5MzYgNzMyOQ1HYXJ5LlN1bGxpdmFuQGl0dS5jaAcHVGl0bGU6B1NwZWNpZnlpbmcgSC4y NjMgUHJvZmlsZXMgaW4gSUVURiBFbnZpcm9ubWVudHMHB1B1cnBvc2U6B0xpYWlzb24gYW5k IENvbGxhYm9yYXRpb24gd2l0aCBJRVRGIEFWVCAHB0lFVEYgQ29udGFjdHMHU3RlcGhlbiBD YXNuZXIsIENvbGluIFBlcmtpbnMsIEpvZXJnIE90dAcHDQ0NU3BlY2lmeWluZyBILjI2MyBQ cm9maWxlcyBpbiBJRVRGIEVudmlyb25tZW50cw0xLglJbnRyb2R1Y3Rpb24NV2UgdW5kZXJz dGFuZCB0aGF0IHRoZSBJRVRGIGlzIHByb2dyZXNzaW5nIHJhcGlkbHkgd2l0aCB0aGUgbGF0 ZXN0IHJldmlzaW9uIG9mIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCks IGZvcm1hbGx5IGtub3duIGFzIFJGQyAyNTQzYmlzLiAgSW4gb3JkZXIgdG8gc3BlY2lmeSB0 aGUgbXVsdGltZWRpYSBzdHJlYW1zIHRoYXQgbWF5IGJlIHVzZWQgZHVyaW5nIHRoZSBzZXNz aW9uLCBTSVAgdXNlcyB0aGUgU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCAoU0RQKSwg Zm9ybWFsbHkga25vd24gYXMgUkZDIDIzMjcuICBGb3IgcmVhbC10aW1lIHN0cmVhbXMsIHRo ZSBJRVRGIHVzZXMgdGhlIFJlYWwgVGltZSBQcm90b2NvbCAoUlRQKSBbZm9ybWFsbHkga25v d24gYXMgUkZDIDE4ODldLCBhbmQgZm9yIHRoaXMsIHNldmVyYWwgUlRQIJNwYXlsb2FkIGZv cm1hdHOUIHdlcmUgZGVmaW5lZCBbUkZDIDE4OTAsIGRyYWZ0LWlldGYtYXZ0LXByb2ZpbGUt bmV3LTA4XSwgaW5jbHVkaW5nIG9uZSBmb3IgdGhlIG9yaWdpbmFsIHZlcnNpb24gb2YgSC4y NjMgW1JGQyAyMTkwXS4gIExhdGVyIGEgcGF5bG9hZCBmb3JtYXQgZm9yIHRoZSAxOTk4IHZl cnNpb24gb2YgSC4yNjMgKGtub3duIGFzIEguMjYzKykgd2FzIGFsc28gZGVmaW5lZCBbUkZD IDI0MjldLCB3aGljaCB3YXMgc3VmZmljaWVudCBmb3IgdXNlIHdpdGggY2FwYWJpbGl0eSBl eGNoYW5nZSB1c2luZyBJVFUtVJJzIEguMjQ1LiAgSG93ZXZlciwgUkZDIDI0MjkgaGFkIG5v IG1lbnRpb24gb2YgSC4yNjMgcHJvZmlsZXMuICANRm9yIGVtYWlsIGF0dGFjaG1lbnRzIHRo ZSBNSU1FIHNwZWNpZmljYXRpb24gaXMgdXNlZCB0byBkZXNjcmliZSB0aGUgY29udGVudC4g IE1JTUUgZGVzY3JpcHRpb25zIGFyZSByZWdpc3RlcmVkIHdpdGggSUFOQSAoSW50ZXJuZXQg QXNzaWduZWQgTnVtYmVycyBBdXRob3JpdHkpLg1BdCB0aGUgSVRVLVQgIFNHMTYgIFExNSBt ZWV0aW5nIGNvbmNsdWRlZCBpbiBNYXksIHdlIHByZXBhcmVkIGEgbmVhcmx5IGZpbmFsIGRy YWZ0IG9mIGRlZmluaXRpb25zIG9mIHByb2ZpbGVzIGFuZCBsZXZlbHMgZm9yIEgyNjMgdmlk ZW8gY29kaW5nLiAgVGhlc2Ugd2lsbCBhcHBlYXIgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiBI MjYzIChha2EgSDI2My0yMDAwKSB0byBiZSBmaW5hbGl6ZWQgaW4gTm92ZW1iZXIuICBDdXJy ZW50bHkgd2UgaGF2ZSBkcmFmdGVkIGRlZmluaXRpb25zIG9mIHByb2ZpbGVzIG51bWJlcmVk IDAgdGhyb3VnaCA0LCBhbmQgbGV2ZWxzIDAgdGhyb3VnaCAyLiAgVGhlIG1vc3QgcmVjZW50 IHRlbnRhdGl2ZSB2ZXJzaW9uIGlzIGluIFRhYmxlIElJLjIvSC4yNjMgYmVsb3cuDUZvciBt YXhpbXVtIGludGVyb3BlcmFiaWxpdHkgd2l0aCBzaW1wbGlmaWVkIGNhcGFiaWxpdHkgZXhj aGFuZ2UsIHRoaXMgY29udHJpYnV0aW9uIHByb3Bvc2VzIHRoYXQgSC4yNjMgcHJvZmlsZSBh bmQgbGV2ZWwgc3BlY2lmaWNhdGlvbiBiZSBpbmNsdWRlZCBpbiBNSU1FIGFuZCBTRFAgbWVz c2FnZXMuICBJbiBwYXJ0aWN1bGFyLCB0aGUgcHJvZmlsZSBkZXNpZ25lZCBzcGVjaWZpY2Fs bHkgZm9yIEJyb2FkYmFuZCBJbnRlcm5ldCB1c2UgaXMgcHJvZmlsZSA0Lg0NUG9zc2libGUg V2F5cyBvZiBQcm9jZWVkaW5nDVRoZSBtb3N0IHZpc2libGUgd2F5IHRvIHByb2NlZWQgd291 bGQgYmUgdG8gZGVmaW5lIGEgbmV3IFJUUCBwYXlsb2FkIGZvcm1hdHMgZm9yIGVhY2ggSC4y NjMgcHJvZmlsZSBhbmQgbGV2ZWwgYXMgaXQgY29tZXMgdG8gYmUgdXNlZCBpbiB0aGUgbWFy a2V0LiAgQnV0IHRoYXQncyBhIGxvdCBvZiBwYXlsb2FkIGZvcm1hdHMgliBhbmQgYWxzbywg dGhlIHByb2Nlc3MgZm9yIHByb2dyZXNzaW5nIGZyb20gZHJhZnQgdG8gUkZDIGlzIGZhaXJs eSBsZW5ndGh5IGluIHRoZSBJRVRGLiAgQW5kIGFzIGZhciBhcyB0aGUgcGFja2V0aXphdGlv biBmb3JtYXQgaXMgY29uY2VybmVkLCBSRkMgMjQyOSBhcHBlYXJzIGFkZXF1YXRlIGZvciBh bGwgb2YgdGhlc2UgcHJvZmlsZXMuICBILjI2MyBiaXRzdHJlYW1zIHRoZW1zZWx2ZXMgYXJl IGFsc28gc2VsZi1jb250YWluZWQgaW4gdGhhdCB0aGV5IGNvbnRhaW4gYWxsIGluZm9ybWF0 aW9uIG5lY2Vzc2FyeSB0byBkZWNvZGUgdGhlbS4gIEFuIGFsdGVybmF0aXZlIHdvdWxkIGJl IHRvIGRlZmluZSBuZXcgU0RQIGF0dHJpYnV0ZXMgInByb2ZpbGUiIGFuZCAibGV2ZWwiLiBB Z2FpbiwgaG93ZXZlciwgcmV2aXNpbmcgU0RQIHdvdWxkIGJlIGEgbG9uZyBwcm9jZXNzIGFu ZCBtaWdodCBoYXZlIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaW1wbGljYXRpb25zLg1TdGls bCBhbm90aGVyIHdheSB3b3VsZCBiZSB0byByZWdpc3RlciBvcHRpb25hbCBwYXJhbWV0ZXJz ICJwcm9maWxlIiBhbmQgImxldmVsIiB1bmRlciBNSU1FLCBhbmQgdXNlIHRoZW0gaW4gdGhl IGV4aXN0aW5nIFNEUCBmbXRwIGF0dHJpYnV0ZS4gIFRoaXMgaGFzIHRoZSBiZW5lZml0IG9m IGJhY2t3YXJkIGNvbXBhdGliaWxpdHksIGFuZCBjYW4gYmUgaW1wbGVtZW50ZWQgZWFzaWx5 LiAgVGhleSBjb3VsZCBhbHNvIGJlIHVzZWZ1bCBpbiBzcGVjaWZ5aW5nIE1QRUcgcHJvZmls ZXMgYW5kIGxldmVscy4NDVByb3Bvc2FsIGZvciBNSU1FIHJlZ2lzdHJhdGlvbg1XZSB0aGVy ZWZvcmUgcHJvcG9zZSBjb25zaWRlcmF0aW9uIG9mIHJlZ2lzdGVyaW5nIHdpdGggSUFOQSB0 aGUgbmV3IG9wdGlvbmFsIHBhcmFtZXRlcnMgInByb2ZpbGUiIGFuZCAibGV2ZWwiIHRvIGJl IHVzZWQgd2l0aCB0aGUgTUlNRSBzdWJ0eXBlIEgyNjMtMjAwMC4gIEEgY3VycmVudCBJRVRG IGRyYWZ0IFtkcmFmdC1pZXRmLWF2dC1ydHAtbWltZS0wMi50eHRdIGlzIGluIHRoZSBwcm9j ZXNzIG9mIHJlZ2lzdGVyaW5nIG1hbnkgbXVsdGltZWRpYSBwYXlsb2FkIGZvcm1hdHMsIGlu Y2x1ZGluZyBIMjYzKyAoYWthIEgyNjMtMTk5OCkuICBQZXJoYXBzIHR3byBvcHRpb25hbCBw YXJhbWV0ZXJzLCAicHJvZmlsZSIgYW5kICJsZXZlbCIsIGNvdWxkIGJlIGFkZGVkIHRvIGEg SDI2My0yMDAwIHJlZ2lzdHJhdGlvbi4gIA1BIHR5cGljYWwgTUlNRSBzcGVjaWZpY2F0aW9u IGZvciBzYXkgcHJvZmlsZSA0LCBsZXZlbCAyIHdvdWxkIGxvb2sgbGlrZYUNCXZpZGVvL0gy NjMtMjAwMDtwcm9maWxlPTQ7bGV2ZWw9Mg0NUHJvcG9zYWwgZm9yIFNEUCB0byB1c2UgZm10 cCBhdHRyaWJ1dGVzIHByb2ZpbGUgYW5kIGxldmVsDVdlIGFzayBjb25zaWRlcmF0aW9uIG9m IHVzaW5nIHRoZSBNSU1FIG9wdGlvbmFsIHBhcmFtZXRlcnMgInByb2ZpbGUiIGFuZCAibGV2 ZWwiIHVuZGVyIHRoZSBleGlzdGluZyBTRFAgZm10cCBhdHRyaWJ1dGUgYXMgZGVzY3JpYmVk IGluIGRyYWZ0LWlldGYtYXZ0LXJ0cC1taW1lLTAyLnR4dC4gIEZvciBleGFtcGxlLCB0byBz cGVjaWZ5IHByb2ZpbGUgNCwgbGV2ZWwgMiB0aGUgU0RQIGVudHJpZXMgd291bGQgYmUgKHVz aW5nIHNheSBkeW5hbWljIHBheWxvYWQgbnVtYmVyIDk4IGFuZCBVRFAgcG9ydCA0OTIzMikN CW09dmlkZW8gNDkyMzIgUlRQL0FWUCA5OA0JYT1ydHBtYXA6OTggSDI2My0yMDAwDQlhPWZt dHA6OTggcHJvZmlsZT00O2xldmVsPTINRm9yIGludGVyYWN0aXZlIHNlc3Npb25zLCBhbiBl bmRwb2ludCBjb3VsZCBpbmRpY2F0ZSBhbGwgcHJvZmlsZXMgYW5kIGxldmVscyBpdCB3YXMg Y2FwYWJsZSBvZiBoYW5kbGluZyBieSBpbmNsdWRpbmcgbXVsdGlwbGUgZW50cmllcy4gIEZv ciBleGFtcGxlLCBhIGNvZGVyIHRoYXQgY291bGQgaGFuZGxlIHByb2ZpbGVzIDMgYW5kIDQg YXQgbGV2ZWwgMiBjb3VsZCBpbmRpY2F0ZSB0aGlzIGJ5hQ0JbT12aWRlbyA0OTIzMiBSVFAv QVZQIDk4IDk5DQlhPXJ0cG1hcDo5OCBIMjYzLTIwMDANCWE9cnRwbWFwOjk5IEgyNjMtMjAw MA0JYT1mbXRwOjk4IHByb2ZpbGU9MztsZXZlbD0yDQlhPWZtdHA6OTkgcHJvZmlsZT00O2xl dmVsPTINDUNvbmNsdXNpb24NQmVsb3cgaXMgdGhlIG1vc3QgcmVjZW50IGRyYWZ0IG9mIHRo ZSBILjI2MyBwcm9maWxlcyBhbmQgbGV2ZWxzLiAgV2UgbG9vayBmb3J3YXJkIHRvIHByb2dy ZXNzIG9uIHRoZXNlIGlzc3Vlcy4gIA0NDA1UYWJsZSBJSS4xL0guMjYzIJYgU3VtYXJ5IG9m IFByb2ZpbGVzICAgKFggaW5kaWNhdGVzIGluY2x1c2lvbiBpbiBwcm9maWxlKQ1ILjI2MyBB bm5leC9zdWJwYXJ0B1Byb2ZpbGUgMAdQcm9maWxlIDEHUHJvZmlsZSAyB1Byb2ZpbGUgMwdQ cm9maWxlIDQHB0MNQ29udGludW91cyBQcmVzZW5jZSBNdWx0aXBvaW50IGFuZCBWaWRlbyBN dXgHBwcHBwcHRC4xICAoVVVJPTEpDU1vdGlvbiB2ZWN0b3JzIG92ZXIgcGljdHVyZSBib3Vu ZGFyaWVzB1gNKGR1ZSB0byBGKQdYDShkdWUgdG8gSikHWAdYB1gNKGR1ZSB0byBKKQcHRC4y ICAoVVVJPTEpDUV4dGVuc2lvbiBvZiB0aGUgbW90aW9uIHZlY3RvciByYW5nZQcHB1gHWAcH B0UNU3ludGF4LWJhc2VkIEFyaXRobWV0aWMgQ29kaW5nBwcHBwcHB0YuMg1Gb3VyIG1vdGlv biB2ZWN0b3JzIHBlciBtYWNyb2Jsb2NrB1gHWA0oZHVlIHRvIEopB1gNKGR1ZSB0byBKKQdY B1gNKGR1ZSB0byBKKQcHRi4zDU92ZXJsYXBwZWQgYmxvY2sgbW90aW9uIGNvbXBlbnNhdGlv bgdYBwcHWAdYBwdHDVBCLUZyYW1lcwcHBwcHBwdIDUZvcndhcmQgRXJyb3IgQ29ycmVjdGlv bgcHBwcHBwdJDUFkdmFuY2VkIEludHJhIENvZGluZwcHWAdYB1gHWAcHSg1EZWJsb2NraW5n ICBGaWx0ZXIHB1gHWAdYB1gHB0sNU2xpY2UgU3RydWN0dXJlZCBDb2RpbmcgliBXaXRoIGFs bCBzdWJtb2RlcwcHB1gHWAcHB0wuNA1TdXBwbGVtZW50YWwgRW5oYW5jZW1lbnQgRnVsbCBw aWN0dXJlIGZyZWV6ZQcHWAdYB1gHWAcHTA1TdXBwbGVtZW50YWwgRW5oYW5jZW1lbnQgliBP dGhlciBTRUkgZmVhdHVyZXMHBwcHBwcHTQ1JbXByb3ZlZCBQQi1GcmFtZXMHBwcHWAcHB04g liBtZXRob2QgMQ1SZWZlcmVuY2UgUGljdHVyZSBTZWxlY3Rpb24gliBNZXRob2QgTkVJVEhF UgcHBwcHWAcHTg1SZWZlcmVuY2UgUGljdHVyZSBTZWxlY3Rpb24gliBPdGhlciBSUFMgbWV0 aG9kcwcHBwcHBwdPDVRlbXBvcmFsLCBTTlIsIGFuZCBTcGF0aWFsIFNjYWxhYmlsaXR5BwcH BwcHB1AgKElGbzQgbW9kZSkNUmVmZXJlbmNlIFBpY3R1cmUgUmVzYW1wbGluZyAtLSBJbXBs LiBGYWN0b3Igb2YgNAcHB1gHWAdYBwdQDVJlZmVyZW5jZSBQaWN0dXJlIFJlc2FtcGxpbmcg liBPdGhlciBSUFIHBwcHBwcHUQ1SZWR1Y2VkIFJlc29sdXRpb24gVXBkYXRlBwcHBwcHB1IN SW5kZXBlbmRlbnQgU2VnbWVudCBEZWNvZGluZwcHBwdYBwcHUw1BbHRlcm5hdGl2ZSBJbnRl ciBWTEMHBwcHWAcHB1QNTW9kaWZpZWQgUXVhbnRpemF0aW9uBwdYB1gHWAdYBwdVDUVuaGFu Y2VkIFJlZmVyZW5jZSBQaWN0dXJlIFNlbGVjdGlvbiwgd2l0aG91dCBzdWItcGljdHVyZSBw cnVuaW5nBwcHBwdYBwdVDUVuaGFuY2VkIFJlZmVyZW5jZSBQaWN0dXJlIFNlbGVjdGlvbiwg d2l0aCBzdWItcGljdHVyZSBwcnVuaW5nBwcHBwcHB1YNRGF0YSBQYXJ0aXRpb25lZCBTbGlj ZXMHBwcHBwcHVw1BZGRpdGlvbmFsIFNFSSBTcGVjaWZpY2F0aW9uBwcHBwcHB0N1c3RvbSBQ aWN0dXJlIEZvcm1hdAcHBwcHBwdDdXN0b20gUGljdHVyZSBDbG9jayBGcmVxdWVuY3kHBwcH BwcHSFJEIEJ1ZmZlciBNdWx0aXBsaWVyICAgWEhSRAcxBzEHMQcxBzIHBw1UYWJsZSBJSS4y L0guMjYzIJYgTGV2ZWxzIG9mIEJpdHN0cmVhbSBPcGVyYXRpb24NB0xldmVsIDAHTGV2ZWwg MQdMZXZlbCAyBwdNYXggcGljdHVyZSBmb3JtYXQHUUNJRiAoMTc2KDE0NCkHQ0lGICgzNTIo Mjg4KQdDSUYgKDM1MigyODgpBwdNYXggRnJhbWUgcmF0ZSAoZnJhbWVzL3MpBzE1BzE1BzMw BwdNYXggQml0IHJhdGUgKGtiaXRzL3MpBzY0BzEyOAcxIDkyMAcHTWF4IFJlZiBwaWN0dXJl IGJ1ZmZlcnMHNQc1BzUHB0JQUG1heEtiDShzZWUgYWJvdmUgZm9yIFhIUkQpB1hIUkQgKCA2 NAdYSFJEICggMjU2B1hIUkQgKCAyNTYHB0hSRCBCdWZmZXIgU2l6ZQ0oc2VlIGFib3ZlIGZv ciBYSFJEKQdYSFJEICggNzQwNzcgYml0cwdYSFJEICggMjc5MjI3IGJpdHMHWEhSRCAoIDUx ODQwMCBiaXRzBwcNTk9URTogVGhlIG51bWJlciBvZiByZWZlcmVuY2UgcGljdHVyZSBidWZm ZXJzIGFzIHNob3duIGFib3ZlIGFwcGx5IG9ubHkgdG8gUHJvZmlsZSA0LiAgVGhlIG1heGlt dW0gdmFsdWVzIGFyZSBmb3IgYml0c3RyZWFtcy4gIEZvciBkZWNvZGVycyB0aGVzZSBhcmUg bWluaW11bSB2YWx1ZXMgdGhhdCBuZWVkIHRvIGJlIGFjY29tbW9kYXRlZC4gDQ0NRmlsZToT IEZJTEVOQU1FICBcKiBNRVJHRUZPUk1BVCAUcTE1ajEyFQlQYWdlOiATIFBBR0UgFDEVCURh dGUgUHJpbnRlZDogEyBEQVRFICBcKiBNRVJHRUZPUk1BVCAUMDQvMjYvMDAVDQ0NDQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAEEAAAxBAAAbAQAAG0E AACqBAAArAQAAK0EAACjBQAAtwUAAFsGAABdBgAAXgYAAIwGAACSFgAAuhYAANwWAADxFgAA IxcAACQXAAAmFwAAUxcAAFkXAABmFwAAjBcAAI0XAACPFwAAmRcAAJwXAACmFwAArRcAALcX AAC5FwAAxhcAAOoXAADrFwAA8xcAAPUXAAAUGAAAGhgAAB4YAABAGAAAQRgAAEUYAABPGAAA UhgAAFwYAABhGAAAaxgAAG0YAABxGAAAlhgAAJ8YAAChGAAAqxgAALEYAACzGAAAzBgAANIY AADUGAAA6RgAAOoYAAD0GAAA9hgAAAgZAAAJGQAAExkAABUZAABBGQAASRkAAE0ZAAB5GQAA ehkAAIQZAACGGQAAtBkAALoZAAC8GQAAzxkAAAD38Pfw9+vw4vDcAPAA2dUA0c/RAM/Ry9HP x8/Hz8fP0cvRz9EAz9HL0c/Hz8fPx8/RAM/RAM/RAM/Ry9HP0cvRz9EAz9HL0c/RAM/RAAAA AAAGNgiBQioBAAY1CIE2CIEAA0IqAQY1CIFCKgEABzUIgUNKFgAEQ0oWAAALPioBT0oCAFFK AgAQMEogAENKFgBPSgIAUUoCAAAIT0oCAFFKAgAADENKFgBPSgIAUUoCAAAPNQiBQ0oWAE9K AgBRSgIAAE4ABAAAAQQAADEEAABABAAAbAQAAG0EAACABAAAlQQAAKsEAACsBAAArQQAALUE AADhBAAA4gQAAOMEAAD0AAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADn AAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAA AAAAAAAAAAAAAMcAAAAAAAAAAAAAAAC6AAAAAAAAAAAAAAAArAAAAAAAAAAAAAAAAJ8AAAAA AAAAAAAAAACsAAAAAAAAAAAAAAAArAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADAAAE6Q8ABSkPAAWJAENxggAAggHkCQAAg4AAAMkAxOkPAAUpDwAFiQBDcYIAAIIB5Ak AAIADAAAAyQDE6Q8ABSkPAANxggAAggHkCQAAiAAABYkARckAQKWbAAI1jAAApT/Bxr8JAAG cxoAAAAAAAAAAAAAAAAAAAAAAAb1CgAAAAAAAAAAAAAAAAAAAAAADAAAAyQDE6Q8ABSkPAAW JAENxgUAASAcAAsAAAMkAxOkPAAUpDwADcYFAAHwE4AADgAEAAABBAAAMQQAAEAEAABsBAAA bQQAAIAEAACVBAAAqwQAAKwEAACtBAAAtQQAAOEEAADiBAAA4wQAAOQEAADxBAAAcgUAAHcF AAB8BQAAgwUAAJMFAACjBQAAuAUAALkFAADABQAA7wUAAPAFAAD5BQAAIgYAACMGAAAxBgAA WgYAAFsGAABcBgAAXQYAAF4GAACNBgAAnQYAALgJAABZCgAA5wsAAPAMAADxDAAADQ0AALQP AADVEAAA1hAAAPUQAACQEgAA2RIAAPwSAAD9EgAANxMAAFwUAAB2FAAAjRQAAKoUAACNFQAA qhUAAMEVAADYFQAAAP39/f39/f37AP39/f37/f39/f39/f37/f37/f37/f37AAAA+fbz8Ovm 4dvY1dLKx8TBvrazsK2qp6ShngAAAAAAAAAFBjz9//8FBlP9//8FBnD9//8FBlP+//8FBnD+ //8FBof+//8FBqH+//8FBsb///8PAgIABQEICwAJAQoCAAAABQba/f//BQb9/f//BQZG/v// BQbh////DwICAAUBCAsACQEKAQAAAAUGHPz//wUGPf3//wUG5P///woCAgAFAQgLAAkBAAgC FgAGnfn//wAIAhYABqb6//8ACAIWAAY0/P//AAUG1fz//wUG8P///wUCAgAFAQMCHQACAwEA BAMBBQo94wQAAOQEAADxBAAAcgUAAHcFAAB8BQAAgwUAAJMFAACjBQAAuAUAALkFAADABQAA 7wUAAPAFAAD5BQAAIgYAACMGAADJVAMAAAAAAAAAAAAAuwAAAAAAAAAAAAAAAK4AAAAAAAAA AAAAAAC7AAAAAAAAAAAAAAAAuwAAAAAAAAAAAAAAALsAAAAAAAAAAAAAAAC7AAAAAAAAAAAA AAAAuwAAAAAAAAAAAAAAALsAAAAAAAAAAAAAAADJ3AAAAAAAAAAAAAAAuwAAAAAAAAAAAAAA ALsAAAAAAAAAAAAAAACOzAAAAAAAAAAAAAAAuwAAAAAAAAAAAAAAALsAAAAAAAAAAAAAAACO 4AAAAAAAAAAAAAAAAAAAAAAAAAAgAAAWJAEXJAEClmwACNYwAAKU/24E/CQABtoEAAAAAAAA AAAAAAAAAAAAAAAGjiAAAAAAAAAAAAAAAAAAAAAAAAwAABOkPAAUpDwAFiQBDcYIAAIIB5Ak AAIOAAADJAMTpDwAFKQ8ABYkAQ3GCAACCAeQJAACNgAAFiQBFyQBApZsAAjWXAAElP9uBDgX 4BoAJQAG2gQAAAAAAAAAAAAAAAAAAAAAAAbKEgAAAAAAAAAAAAAAAAAAAAAABqgDAAAAAAAA AAAAAAAAAAAAAAAGIAoAAAAAAAAAAAAAAAAAAAAAABAjBgAAMQYAAFoGAABbBgAAXAYAAF0G AABeBgAAjQYAAJ0GAAC4CQAAWQoAAOcLAADwDAAA8QwAAA0NAAC0DwAA1RAAAPEAAAAAAAAA AAAAAADxAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAAMEAAAAAAAAAAAAAAAC0AAAAAAAAAAAA AAAArQAAAAAAAAAAAAAAAKYAAAAAAAAAAAAAAAChAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAA AK0AAAAAAAAAAAAAAACbAAAAAAAAAAAAAAAAmwAAAAAAAAAAAAAAAJsAAAAAAAAAAAAAAACS AAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAK0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAgCAAMkAwomAAtGCwATpDwAAAUWABOkPAAUpDwABQIAAyQDE6Q8AAcdAAMkAxOkPAAUpDwA BwAAAyQDE6Q8ABSkPAAADAAAAyQDE6Q8ABSkPAANxggAAggHkCQAAgAPAAADJAMTpDwAFKQ8 ACZkDAEAAQ3GCAACCAeQJAACIAAAFiQBFyQBApZsAAjWMAAClP9uBPwkAAbaBAAAAAAAAAAA AAAAAAAAAAAABo4gAAAAAAAAAAAAAAAAAAAAAA4AAAMkAxOkPAAUpDwAFiQBDcYIAAIIB5Ak AAIAENUQAADWEAAA9RAAAJASAADZEgAA/BIAAP0SAAA3EwAAXBQAAHYUAACNFAAAqhQAAI0V AACqFQAAwRUAANgVAAD1FQAAEhYAABMWAAAeFgAAjxYAAJAWAACSFgAA3RYAAPEWAAD7FgAA BRcAAPgAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA +AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgA AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAA AAAAAAAAAOwAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAN8AAAAAAAAA AAAAAADfAAAAAAAAAAAAAAAAAwAAFiQBAwYAFiQBBwQAAyQBE6TgARSkeAADBAADJAMACAIA AyQDCiYAC0YLABOkPAAHAAADJAMTpDwAFKQ8AAAa2BUAAPUVAAASFgAAExYAAB4WAACPFgAA kBYAAJIWAADdFgAA8RYAAPsWAAAFFwAADxcAABkXAAAjFwAAJBcAACYXAABTFwAAVBcAAFUX AABWFwAAVxcAAFgXAABZFwAAZhcAAI0XAACPFwAAmhcAAJwXAACnFwAAqRcAAKsXAACtFwAA uBcAALkXAADGFwAA6xcAAOwXAADtFwAA7xcAAPEXAADyFwAA8xcAAPUXAAAUGAAAFRgAABYY AAAXGAAAGBgAABkYAAAaGAAAHhgAAEEYAABDGAAARRgAAFAYAABSGAAAXRgAAF8YAABhGAAA bBgAAG0YAABxGAAAlhgAAJgYAACZGAAAmhgAAJwYAACeGAAAnxgAAKEYAACrGAAArBgAAK0Y AACuGAAArxgAALAYAACxGAAAsxgAAMwYAADNGAAAzhgAAM8YAADQGAAA0RgAANIYAAD8+fbu 6+jl5eHe3t7e3tze2N7e3t7e3N7e3t7e3t7e3t7c3t7e3t7e3tze2N7e3t7e3N7e3t7e3t7e 3t7c3tje3t7e3tze2N7e3t7e3N7Y3t7e3t7cAAAABwIHAAMBBQoCAwEABAMBBQoABwIGAAMB BQoFAgQABQMFBn7///8FBu////8PAgIABQEICwAJAQoDAAAABQbr/P//BQYI/f//BQYl/f// AFUFFwAADxcAABkXAAAjFwAAJBcAACYXAABTFwAAVBcAAFUXAABWFwAAVxcAAFgXAABZFwAA ZhcAAI0XAACPFwAAmhcAAJwXAACnFwAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAA AAAAAAAAAAAAotQAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAACfAAAAAAAAAAAAAAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAACigAEAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAAAAAAAAAAAADBwAW JAEAWQAAFiQBFyQBApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWiAAGpv/gEBgV UBkuHQwh6iQABjoRAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAAAAAAAAAAAAAAAAAAAAY4BAAA AAAAAAAAAAAAAAAAAAAABt4DAAAAAAAAAAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAA AAbeAwAAAAAAAAAAAAAAAAAAAAADAAAWJAEAEqcXAACpFwAAqxcAAK0XAAC4FwAAuRcAAMYX AADrFwAA7BcAAO0XAADvFwAA8RcAAPIXAADzFwAA9RcAABQYAAAVGAAAFhgAABcYAAD8AAAA AAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAougAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAACinAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAJ8AAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAAAAAAAAAAAAAMHABYkAQBZAAAWJAEXJAEClmwABdYYBAEAAAQBAAAE AQAABAEAAAQBAAAEAQAACNaIAAam/+AQGBVQGS4dDCHqJAAGOhEAAAAAAAAAAAAAAAAAAAAA AAY4BAAAAAAAAAAAAAAAAAAAAAAABjgEAAAAAAAAAAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAA AAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAAAAAABt4DAAAAAAAAAAAAAAAAAAAAAAMAABYkAQAS FxgAABgYAAAZGAAAGhgAAB4YAABBGAAAQxgAAEUYAABQGAAAUhgAAF0YAABfGAAAYRgAAGwY AABtGAAAcRgAAJYYAACYGAAAmRgAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAokwBAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAACiyAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA AJ8AAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAwcAFiQB AFkAABYkARckAQKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1ogABqb/4BAYFVAZ Lh0MIeokAAY6EQAAAAAAAAAAAAAAAAAAAAAABjgEAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAA AAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAAAAAABt4DAAAAAAAAAAAAAAAAAAAAAAAG 3gMAAAAAAAAAAAAAAAAAAAAAAwAAFiQBABKZGAAAmhgAAJwYAACeGAAAnxgAAKEYAACrGAAA rBgAAK0YAACuGAAArxgAALAYAACxGAAAsxgAAMwYAADNGAAAzhgAAM8YAADQGAAA/AAAAAAA AAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAokgAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAACfAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAACihAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA AJ8AAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAAAAAAAAAAAAADBwAWJAEAWQAAFiQBFyQBApZsAAXWGAQBAAAEAQAABAEA AAQBAAAEAQAABAEAAAjWiAAGpv/gEBgVUBkuHQwh6iQABjoRAAAAAAAAAAAAAAAAAAAAAAAG OAQAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAABt4DAAAAAAAAAAAAAAAA AAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAAAAADAAAWJAEAEtAY AADRGAAA0hgAANQYAADqGAAA6xgAAO0YAADvGAAA8RgAAPMYAAD0GAAA9hgAAAkZAAAKGQAA DBkAAA4ZAAAQGQAAEhkAABMZAAD8AAAAAAAAAAAAAAAAoogAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAACifAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAKLYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABZ AAAWJAEXJAEClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNaIAAam/+AQGBVQGS4d DCHqJAAGOhEAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAABjgEAAAAAAAA AAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAAAAAABt4D AAAAAAAAAAAAAAAAAAAAAAMAABYkAQAS0hgAANQYAADqGAAA6xgAAO0YAADvGAAA8RgAAPMY AAD0GAAA9hgAAAkZAAAKGQAADBkAAA4ZAAAQGQAAEhkAABMZAAAVGQAAQRkAAEIZAABDGQAA RRkAAEcZAABIGQAASRkAAE0ZAAB6GQAAexkAAH0ZAAB/GQAAgRkAAIMZAACEGQAAhhkAALQZ AAC1GQAAthkAALcZAAC4GQAAuRkAALoZAAC8GQAAzxkAANAZAADRGQAA0hkAANQZAADVGQAA 1hkAAOMZAAAQGgAAERoAABIaAAATGgAAFBoAABYaAAAXGgAAGRoAAEkaAABKGgAASxoAAEwa AABNGgAAThoAAE8aAABRGgAAeBoAAHkaAAB6GgAAexoAAHwaAAB9GgAAfhoAAIwaAAC+GgAA vxoAAMAaAADCGgAAxBoAAMYaAADHGgAAyRoAAPIaAADzGgAA9BoAAPUaAAD2GgAA9xoAAPga AAD6GgAAFBsAABUbAAAWGwAAFxsAABgbAAAZGwAAGhsAABwbAAA5GwAA/f39/f39/fv9/f39 /f39+/33/f39/f37/f39/f39/fv99/39/f39+/33/f39/f37/f39/f39/fv99/39/f39+/39 /f39/f37/f39/f39/fv9/f39/f39+/33/f39/f37/f0HAgcAAwEFCgIDAQAEAwEFCmITGQAA FRkAAEEZAABCGQAAQxkAAEUZAABHGQAASBkAAEkZAABNGQAAehkAAHsZAAB9GQAAfxkAAIEZ AACDGQAAhBkAAIYZAAC0GQAA/AAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA AJ/sAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAn9gA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAAAAAAAAAAAWQAAFiQBFyQB ApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWiAAGpv/gEBgVUBkuHQwh6iQABjoR AAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAA AAAABt4DAAAAAAAAAAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAA AAAAAAAAAAADBwAWJAEDAAAWJAEAErQZAAC1GQAAthkAALcZAAC4GQAAuRkAALoZAAC8GQAA zxkAANAZAADRGQAA0hkAANQZAADVGQAA1hkAAOMZAAAQGgAAERoAABIaAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAA AKJwAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAnwAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAogQB AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAAAAAAAAAAAAAMHABYkAQBZAAAWJAEXJAEClmwABdYYBAEAAAQBAAAEAQAABAEA AAQBAAAEAQAACNaIAAam/+AQGBVQGS4dDCHqJAAGOhEAAAAAAAAAAAAAAAAAAAAAAAY4BAAA AAAAAAAAAAAAAAAAAAAABjgEAAAAAAAAAAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAA AAbeAwAAAAAAAAAAAAAAAAAAAAAABt4DAAAAAAAAAAAAAAAAAAAAAAMAABYkAQASzxkAANYZ AADjGQAAEBoAABcaAAAZGgAASRoAAE8aAABRGgAAdxoAAHgaAAB+GgAAjBoAAL4aAADHGgAA yRoAAPIaAAD4GgAA+hoAABQbAAAaGwAAHBsAADgbAAA5GwAAQBsAAEIbAABYGwAAXxsAAGEb AAB2GwAAdxsAAIEbAACDGwAAxRsAAMwbAADOGwAADRwAABMcAAAVHAAALRwAADMcAAA1HAAA UhwAAFgcAABuHAAAdBwAAJMcAACZHAAAthwAAMEcAADCHAAA8xwAAAQdAAAMHQAAIB0AACkd AAAqHQAANx0AADgdAABFHQAARh0AAEwdAABmHQAAcB0AAIcdAACVHQAArB0AAK0dAAC0HQAA vR0AANEdAADSHQAA1x0AANgdAADhHQAA4h0AAOwdAADtHQAA8x0AAAMeAAAYHgAAHR4AAB4e AAD9+fT9+QD9+fD5/fn0/fn0/fkA/fnw+f35AP358Pn9+QD9+QD9+QD9+QD9AP30/fT96QDl AOXi3OLc4tzi5eLl4uXW4gDPAOLc4tzi3OLpz+LcDENKEgBPSgIAUUoCAAAKNQiBNgiBQ0oW AAAKCWoBALTwQ0oWAAAEQ0oWAAAHNQiBQ0oWAAxDShYAT0oCAFFKAgAABjUIgTYIgQAJNQiB NgiBQioBBjUIgUIqAQADQioBAFISGgAAExoAABQaAAAWGgAAFxoAABkaAABJGgAAShoAAEsa AABMGgAATRoAAE4aAABPGgAAURoAAHgaAAB5GgAAehoAAHsaAAB8GgAA/AAAAAAAAAAAAAAA APwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAouAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAACf AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAACivAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAAAAAAAAAAAAADBwAWJAEAWQAAFiQBFyQBApZsAAXWGAQBAAAEAQAABAEAAAQBAAAE AQAABAEAAAjWiAAGpv/gEBgVUBkuHQwh6iQABjoRAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAA AAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAABt4DAAAAAAAAAAAAAAAAAAAAAAAG 3gMAAAAAAAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAAAAADAAAWJAEAEnwaAAB9GgAA fhoAAIwaAAC+GgAAvxoAAMAaAADCGgAAxBoAAMYaAADHGgAAyRoAAPIaAADzGgAA9BoAAPUa AAD2GgAA9xoAAPgaAAD8AAAAAAAAAAAAAAAAoiQBAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAACixAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAKKIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABZAAAWJAEX JAEClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNaIAAam/+AQGBVQGS4dDCHqJAAG OhEAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAABjgEAAAAAAAAAAAAAAAA AAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAAAAAABt4DAAAAAAAA AAAAAAAAAAAAAAMAABYkAQAS+BoAAPoaAAAUGwAAFRsAABYbAAAXGwAAGBsAABkbAAAaGwAA HBsAADkbAAA6GwAAOxsAADwbAAA+GwAAPxsAAEAbAABCGwAAWBsAAPwAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAACfmAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAJ98AAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA+QAAAAAAAAAA AAAAAAAAAAAAAAAAAFkAABYkARckAQKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI 1ogABqb/4BAYFVAZLh0MIeokAAY6EQAAAAAAAAAAAAAAAAAAAAAABjgEAAAAAAAAAAAAAAAA AAAAAAAGOAQAAAAAAAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAAAAAABt4DAAAAAAAA AAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAAAwcAFiQBAwAAFiQBABI5GwAAOhsAADsb AAA8GwAAPhsAAD8bAABAGwAAQhsAAFgbAABZGwAAWhsAAFsbAABdGwAAXhsAAF8bAABhGwAA dxsAAHgbAAB6GwAAfBsAAH4bAACAGwAAgRsAAIMbAADFGwAAxhsAAMcbAADIGwAAyRsAAMsb AADMGwAAzhsAAA0cAAAOHAAADxwAABAcAAARHAAAEhwAABMcAAAVHAAALRwAAC4cAAAvHAAA MBwAADEcAAAyHAAAMxwAADUcAABSHAAAUxwAAFQcAABVHAAAVhwAAFccAABYHAAAbhwAAG8c AABwHAAAcRwAAHIcAABzHAAAdBwAAJMcAACUHAAAlRwAAJYcAACXHAAAmBwAAJkcAAC2HAAA uBwAALocAAC8HAAAvhwAAMAcAADBHAAAwhwAAPMcAAD0HAAA/BwAAAQdAAAMHQAADR0AACAd AAAvHQAAPR0AAEsdAABMHQAAZh0AAGkdAABsHQAAbx0AAHAdAACHHQAAih0AAI4dAAD9/f39 /fv99/39/f39+/39/f39/f37/ff9/f39/fv99/39/f39+/33/f39/f37/ff9/f39/fv3/f39 /f37/f39/f39+/39/f39/fsA9f39/fH7/f39/fv9/f39+/39/QAAAAcCCAADAQUKAwIVAAcC BwADAQUKAgMBAAQDAQUKX1gbAABZGwAAWhsAAFsbAABdGwAAXhsAAF8bAABhGwAAdxsAAHgb AAB6GwAAfBsAAH4bAACAGwAAgRsAAIMbAADFGwAAxhsAAMcbAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAKKIAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAoiwBAAAAAAAA AAAAAPwAAAAAAAAAAAAAAACfAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAAAAAAAAAAAAAMHABYkAQBZAAAWJAEXJAEClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAE AQAACNaIAAam/+AQGBVQGS4dDCHqJAAGOhEAAAAAAAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAA AAAAAAAAAAAABjgEAAAAAAAAAAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAAAAbeAwAA AAAAAAAAAAAAAAAAAAAABt4DAAAAAAAAAAAAAAAAAAAAAAMAABYkAQASxxsAAMgbAADJGwAA yxsAAMwbAADOGwAADRwAAA4cAAAPHAAAEBwAABEcAAASHAAAExwAABUcAAAtHAAALhwAAC8c AAAwHAAAMRwAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAKIcAQAA AAAAAAAAAAD8AAAAAAAAAAAAAAAAnwAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAooAAAAAAAAAA AAAAAPwAAAAAAAAAAAAAAACfAAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAwcAFiQBAFkAABYkARckAQKW bAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1ogABqb/4BAYFVAZLh0MIeokAAY6EQAA AAAAAAAAAAAAAAAAAAAABt4DAAAAAAAAAAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAA AAbeAwAAAAAAAAAAAAAAAAAAAAAABt4DAAAAAAAAAAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAA AAAAAAAAAwAAFiQBABIxHAAAMhwAADMcAAA1HAAAUhwAAFMcAABUHAAAVRwAAFYcAABXHAAA WBwAAG4cAABvHAAAcBwAAHEcAAByHAAAcxwAAHQcAACTHAAA/AAAAAAAAAAAAAAAAKKUAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAAnwAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAAonAAAAAAAAAA AAAAAJ8AAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAKKUAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA AAAAAAAAAAADBwAWJAEAWQAAFiQBFyQBApZsAAXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEA AAjWiAAGpv/gEBgVUBkuHQwh6iQABjoRAAAAAAAAAAAAAAAAAAAAAAAGOAQAAAAAAAAAAAAA AAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAABt4DAAAAAAAAAAAAAAAAAAAAAAAG3gMAAAAA AAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAAAAADAAAWJAEAEpMcAACUHAAAlRwAAJYc AACXHAAAmBwAAJkcAAC2HAAAuBwAALocAAC8HAAAvhwAAMAcAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAKKgAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAA AAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABZAAAWJAEXJAEClmwA BdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNaIAAam/+AQGBVQGS4dDCHqJAAGOhEAAAAA AAAAAAAAAAAAAAAAAAY4BAAAAAAAAAAAAAAAAAAAAAAABjgEAAAAAAAAAAAAAAAAAAAAAAAG 3gMAAAAAAAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAAAAAABt4DAAAAAAAAAAAAAAAA AAAAAAMAABYkAQAMwBwAAMEcAADCHAAA8xwAAPQcAAD8HAAABB0AAAwdAAANHQAApQAAAAAA AAAAAAAAAKIAAAAAAAAAAAAAAACWAAAAAAAAAAAAAAAAkQAAAAAAAAAAAAAAAJEAAAAAAAAA AAAAAACRAAAAAAAAAAAAAAAAjgAAAAAAAAAAAAAAAEr8AAAAAAAAAAAAAAAAAAAAAAAAAABD AAAWJAEXJAEClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNZcAASU/+YK/BKiGzYk AAaeCgAAAAAAAAAAAAAAAAAAAAAABnAIAAAAAAAAAAAAAAAAAAAAAAAGAAkAAAAAAAAAAAAA AAAAAAAAAAaUCAAAAAAAAAAAAAAAAAAAAAADCAAWJAEABAAAAyQDFiQBDBUAE6TgARSkeAAN xgoEGgOnBDQGwQcAAwAAAyQDAFkAABYkARckAQKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEA AAQBAAAI1ogABqb/4BAYFVAZLh0MIeokAAY6EQAAAAAAAAAAAAAAAAAAAAAABt4DAAAAAAAA AAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAAAAbeAwAAAAAAAAAAAAAAAAAAAAAABt4D AAAAAAAAAAAAAAAAAAAAAAAG3gMAAAAAAAAAAAAAAAAAAAAAAAgNHQAAIB0AAC8dAAA9HQAA Sx0AAEwdAABmHQAAaR0AAGwdAABvHQAAcB0AAIcdAACKHQAAjh0AAJQdAACVHQAArR0AAK8d AACxHQAAsx0AALQdAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAAtpAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAC2lAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAALZ8AAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAtvwAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMAABYkARckAQKWbAAF1hgEAQAABAEAAAQBAAAE AQAABAEAAAQBAAAI1lwABJT/5gr8EqIbNiQABp4KAAAAAAAAAAAAAAAAAAAAAAAGcAgAAAAA AAAAAAAAAAAAAAAAAAYACQAAAAAAAAAAAAAAAAAAAAAABpQIAAAAAAAAAAAAAAAAAAAAAAAE AAADJAMWJAEAFI4dAACUHQAAlR0AAK0dAACvHQAAsR0AALMdAAC0HQAAvR0AANIdAADcHQAA 5x0AAPIdAADzHQAAAx4AABgeAAAqHgAAPR4AAFAeAABRHgAAUh4AABYfAAAXHwAAGB8AAE8f AABQHwAAgh8AAIMfAACEHwAAhR8AAP37/f39/fv3/f39/fv9/f39/fsA9QAA8/Pz8/MAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAIBAQADAh8ABwIIAAMBBQoCAwEABAMBBQodtB0AAL0dAADSHQAA3B0AAOcd AADyHQAA8x0AAAMeAAAYHgAAKh4AAD0eAABQHgAAUR4AAFIeAAAWHwAAFx8AABgfAAD8AAAA AAAAAAAAAAAA+QAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAA AAAAAAAAALB4AQAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAPQAAAAAAAAA AAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAACtAAAAAAAAAAAA AAAAqwAAAAAAAAAAAAAAAJ4AAAAAAAAAAAAAAACXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAHAAADJAMTpDwAFKQ8AAAMAAADJAMTpDwAFKQ8AA3GCAACCAeQJAAC AAEfAAMAAAMkAwBDAAAWJAEXJAEClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAACNZc AASU/+YK/BKiGzYkAAaeCgAAAAAAAAAAAAAAAAAAAAAABnAIAAAAAAAAAAAAAAAAAAAAAAAG AAkAAAAAAAAAAAAAAAAAAAAAAAaUCAAAAAAAAAAAAAAAAAAAAAAABAAAAyQDFiQBAwAAFiQB AwgAFiQBABAeHgAALx4AADAeAABCHgAAQx4AAFIeAAAWHwAAGB8AAB0fAAAeHwAAOB8AADkf AAA/HwAAQB8AAEcfAABIHwAATh8AAE8fAABQHwAAUR8AAGAfAABhHwAAdx8AAHgfAACAHwAA gR8AAIIfAACFHwAA/ff99/3yAOvg6+DX4NLLyMvDy8jLyMvDy9IAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAIMEoRAG1IAAQABDBKEQAADQNqAAAAADBKEQBVCAEIT0oD AFFKAwAAEENKEABPSgMAUUoDAG1IAAQAFQNqAAAAAENKEABPSgMAUUoDAFUIAQxDShAAT0oD AFFKAwAACE9KAABRSgAAAAoJagEAtPBDShYAAARDShYAGxgfAACCHwAAgx8AAIQfAACFHwAA +AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAADJAMTpDwAFKQ8AAABAAAABhAADcYHAcAh AZAkAgAELwAUMAgmUAEAHFABAB+w0C8gsOA9IbCgBSKwoAUjkGADJJBgAyWwAAAXsLABGLCw AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASACEACgABAFsADwACAAAAAAAAADAA AEDx/wIAMAAMAAYATgBvAHIAbQBhAGwAAAACAAAAEABfSAEEbUgJBHNICQR0SAkERgABAAEA AgBGAAwACQBIAGUAYQBkAGkAbgBnACAAMQAAABAAAQAGJAETpOABFKQ8AEAmABIANQiBQ0oc AEtIHAB0SAkEdQgARgACQAEAAgBGAAwACQBIAGUAYQBkAGkAbgBnACAAMgAAABAAAgAGJAET pPAAFKQ8AEAmAREANQiBNgiBQ0oYAHRICQR1CAAAZAADAAEAAgBkAAwACQBIAGUAYQBkAGkA bgBnACAAMwAAADYAAwADJAMFJAEGJAENxg4ABBoDpwQ0BsEHAAAAAA+EGgMRhOb8E6S1AEAm Al6EGgNghOb8YSQDCgA1CIF0SAkEdQgAMAAEQAEAAgAwAAwACQBIAGUAYQBkAGkAbgBnACAA NAAAAAgABAAGJAFAJgMDADUIgQA+AAUAAQACAD4ADAAJAEgAZQBhAGQAaQBuAGcAIAA1AAAA FgAFAAMkAQYkAROkUAAUpFAAQCYEYSQBAwA1CIEAMgAGQAEAAgAyAAwACQBIAGUAYQBkAGkA bgBnACAANgAAAAgABgAGJAFAJgUGADUIgUIqATYAB0ABAAIANgAMAAkASABlAGEAZABpAG4A ZwAgADcAAAAIAAcABiQBQCYGCQA1CIE2CIFCKgEAOAAIQAEAAgA4AAAACQBIAGUAYQBkAGkA bgBnACAAOAAAAAsACAADJAMGJAFAJgcABwA1CIFDShYAAAAAPABBQPL/oQA8AAwAFgBEAGUA ZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAACwA HwABAPIALAAMAAYASABlAGEAZABlAHIAAAANAA8ADcYIAALgEMAhAQIAAAAsACBAAQACASwA DAAGAEYAbwBvAHQAZQByAAAADQAQAA3GCAAC4BDAIQECAAAAJgApQKIAEQEmAAwACwBQAGEA ZwBlACAATgB1AG0AYgBlAHIAAAAAAEYAQwABACIBRgAMABAAQgBvAGQAeQAgAFQAZQB4AHQA IABJAG4AZABlAG4AdAAAAAgAEgADJANhJAMLAENKFgB0SAkEdQgAADQAQgABADIBNAAMAAkA QgBvAGQAeQAgAFQAZQB4AHQAAAACABMADgA2CIFDShYAdEgJBHUIAEoA/g8BAAIASgAMAAkA QQBuAG4AZQB4AF8AUgBlAGYAAAAdABQAAyQBDcYOAAQaA6cENAbBBwAAAAATpIgAYSQBAAcA dEgJBHUIAABYAP5PAQBCAVgADAALAEEAbgBuAGUAeABfAFQAaQB0AGwAZQAAACEAFQADJAEN xg4ABBoDpwQ0BsEHAAAAABOkUAAUpBQAYSQBAA4ANQiBQ0oYAHRICQR1CAAwAFBAAQBiATAA DAALAEIAbwBkAHkAIABUAGUAeAB0ACAAMgAAAAgAFgADJANhJAMAAE4A/g8BAIIBTgAMAAgA RgBpAGcAdQByAGUAXwAjAAAAJAAXAAMkAQYkAQ3GDgAEGgOnBDQGwQcAAAAAE6Q3AhSkcQBh JAEHAHRICQR1CAAAVgD+DwEAAgBWAAwADABGAGkAZwB1AHIAZQBfAFQAaQB0AGwAZQAAACEA GAADJAENxg4ABBoDpwQ0BsEHAAAAABOkiAAUpNACYSQBAAoANQiBdEgJBHUIAC4AUQABAJIB LgAMAAsAQgBvAGQAeQAgAFQAZQB4AHQAIAAzAAAAAgAZAAQAQ0oWAFgA/g8BAKIBWAAMAAcA SQBuAGYAbwBkAG8AYwAAACAAGgAFJAEGJAENxgUAAacEwA+EpwQRhFn7XoSnBGCEWfsXAENK FgBPSgIAUUoCAG1ICQhzSAkIdQgAAFoA/g8BALIBWgAMAAgAZQBuAHUAbQBsAGUAdgAxAAAA JwAbAA3GDgAEGgOnBDQGwQfAwMDAD4QaAxGE5vwTpFAAXoQaA2CE5vwADwBDShgAbUgJCHNI CQh1CAAANAD+D7EBwgE0AAwACABlAG4AdQBtAGwAZQB2ADIAAAASABwAD4SnBBGEc/5ehKcE YIRz/gAAYAD+T1EBAgBgAAwADgBBAHAAcABlAG4AZABpAHgAXwBUAGkAdABsAGUAAAAhAB0A BSQBBiQBE6TwABSkGAENxg4ABBoDpwQ0BsEHwMDAwAAPAENKHABtSAkIc0gJCHUIAABwAP4P AQACAHAADAAKAEEAcABwAGUAbgBkAGkAeABfACMAAAA3AB4AAyQBBSQBBiQBDcYOAAQaA6cE NAbBB8DAwMATpOABFKRQADUkADckADgkADlEAgBIJABhJAEAEgA7CIFDShgAbUgJCHNICQh1 CABaAFJAAQDyAVoADAASAEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQAIAAyAAAA GAAfAAMkAw+E0AIRhDD9XoTQAmCEMP1hJAMMAENKFgBPSgIAUUoCACgAVUCiAAECKAAMAAkA SAB5AHAAZQByAGwAaQBuAGsAAAAGAD4qAUIqAgAAAACFGwAABgAAXgAAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGsAAABrAAAAawAAAG4AAAAABAAA zxkAAB4eAACFHwAAEQAAACAAAAAtAAAAAAQAAOMEAAAjBgAA1RAAAAUXAACnFwAAFxgAAJkY AADQGAAAExkAALQZAAASGgAAfBoAAPgaAABYGwAAxxsAADEcAACTHAAAwBwAAA0dAAC0HQAA GB8AAIUfAAASAAAAFAAAABUAAAAWAAAAGAAAABkAAAAaAAAAGwAAABwAAAAeAAAAHwAAACEA AAAiAAAAIwAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACwAAAAuAAAAAAQAANgVAADSGAAA ORsAAI4dAACFHwAAEwAAABcAAAAdAAAAJAAAACsAAAAFAAAAIAAAACcAAAAvAAAANgAAADgA AABIAAAAXwAAAGgAAABuAAAAEx2U/5WAEyGU/5WAEx+U/5WA//8NAAAADQBfAFQAbwBjADMA OQA5ADkAMAA4ADQANwAzAA0AXwBUAG8AYwA0ADEAOQA3ADgAMAAwADQAMgANAF8AVABvAGMA NAAyADgAOQA0ADgAOAAwADIADQBfAFQAbwBjADQAMwAyADgAMwA1ADkAMAA5AA0AXwBUAG8A YwA0ADMAMgA4ADMANwA0ADIAMwANAF8AVABvAGMANAAzADIAOAAzADgANQAyADQADQBfAFQA bwBjADQAMwAyADgANAA0ADQAOAA2AA0AXwBUAG8AYwA0ADEAOQA3ADgAMAAwADQANAANAF8A VABvAGMANAAyADgAOQA0ADgAOAAwADQADQBfAFQAbwBjADQAMwAyADgAMwA1ADkAMQAxAA0A XwBUAG8AYwA0ADMAMgA4ADMANwA0ADIANQANAF8AVABvAGMANAAzADIAOAAzADgANQAyADYA DQBfAFQAbwBjADQAMwAyADgANAA0ADQAOAA4AI0CAACNAgAAjQIAAI0CAACNAgAAjQIAAI0C AAANCQAADQkAAA0JAAANCQAADQkAAA0JAACGGwAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAA BgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAJwCAACcAgAAnAIAAJwCAACcAgAAnAIAAJwC AADUDAAA1AwAANQMAADUDAAA1AwAANQMAACGGwAAAAAAAAYBAAAQAQAAOQIAAD8CAABQAgAA VQIAAFYCAABZAgAAGQcAABwHAAAyCgAAPwoAADIMAAA2DAAAGQ4AABwOAAAVDwAAGQ8AAJ8P AACjDwAApRIAAKsSAAA6EwAARBMAAE8TAABSEwAANhQAAEAUAADdFAAA4hQAAPYUAAAAFQAA OBUAAEAVAACeFgAAqBYAAKwWAACwFgAA2xYAAOUWAABqFwAAdhcAAN8YAADoGAAAfhkAAIMZ AAC0GQAAvBkAAMQaAADOGgAAGBsAAIMbAACGGwAABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcABwACAAAAAABkBgAAawYAAG8IAABxCAAAdA4AAHUO AADaDgAA3w4AAF0QAABeEAAAdxAAAHgQAACOEAAAjxAAAI4RAACPEQAAqxEAAKwRAADCEQAA wxEAANkRAADaEQAA9hEAAPcRAAAYGwAAgxsAAIYbAAAHABoABwAaAAcAGgAHABoABwAaAAcA GgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHAAcAAgD//xQAAAANAEIAYQByAHIAeQAgAEgA YQBzAGsAZQBsAGwANQBDADoAXABXAEkATgBEAE8AVwBTAFwAVABFAE0AUABcAEEAdQB0AG8A UgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAGkAZQB0AGYAIABsAGkAYQBpAHMA bwBuAC4AYQBzAGQADQBCAGEAcgByAHkAIABIAGEAcwBrAGUAbABsACQARAA6AFwASQBUAFUA XABPAHMAYQBrAGEAIABkAG8AYwBzAFwAaQBlAHQAZgAgAGwAaQBhAGkAcwBvAG4ALgAyAC4A ZABvAGMADQBHAGEAcgB5ACAAUwB1AGwAbABpAHYAYQBuABoAQwA6AFwAVABlAG0AcABcAGkA ZQB0AGYAIABsAGkAYQBpAHMAbwBuAC4AMgAuAGQAbwBjAA0AQgBhAHIAcgB5ACAASABhAHMA awBlAGwAbAAkAEQAOgBcAEkAVABVAFwATwBzAGEAawBhACAAZABvAGMAcwBcAGkAZQB0AGYA IABsAGkAYQBpAHMAbwBuAC4AMwAuAGQAbwBjAA0AQgBhAHIAcgB5ACAASABhAHMAawBlAGwA bAAkAEQAOgBcAEkAVABVAFwATwBzAGEAawBhACAAZABvAGMAcwBcAGkAZQB0AGYAIABsAGkA YQBpAHMAbwBuAC4AMwAuAGQAbwBjAA0AQgBhAHIAcgB5ACAASABhAHMAawBlAGwAbAAkAEQA OgBcAEkAVABVAFwATwBzAGEAawBhACAAZABvAGMAcwBcAGkAZQB0AGYAIABsAGkAYQBpAHMA bwBuAC4ANAAuAGQAbwBjAA0AQgBhAHIAcgB5ACAASABhAHMAawBlAGwAbAAkAEQAOgBcAEkA VABVAFwATwBzAGEAawBhACAAZABvAGMAcwBcAGkAZQB0AGYAIABsAGkAYQBpAHMAbwBuAC4A NAAuAGQAbwBjAA0AQgBhAHIAcgB5ACAASABhAHMAawBlAGwAbAA1AEMAOgBcAFcASQBOAEQA TwBXAFMAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAA bwBmACAAaQBlAHQAZgAgAGwAaQBhAGkAcwBvAG4ALgBhAHMAZAANAEIAYQByAHIAeQAgAEgA YQBzAGsAZQBsAGwAJABEADoAXABJAFQAVQBcAE8AcwBhAGsAYQAgAGQAbwBjAHMAXABpAGUA dABmACAAbABpAGEAaQBzAG8AbgAuADQALgBkAG8AYwANAEIAYQByAHIAeQAgAEgAYQBzAGsA ZQBsAGwAJABEADoAXABJAFQAVQBcAE8AcwBhAGsAYQAgAGQAbwBjAHMAXABpAGUAdABmACAA bABpAGEAaQBzAG8AbgAuADQALgBkAG8AYwAIAKgJ5hta4rxh/w8AAAAAAAAAAAAAAAAAAAAA AQCEJfEicLvi6/8P/w//D/8P/w//D/8P/w//DwEA+RasJIAklO7/D/8P/w//D/8P/w//D/8P /w8AAPA0UTR4m7ol/w//D/8P/w//D/8P/w//D/8PAACof/ZVYv9SJf8P/w//D/8P/w//D/8P /w//DwEA32j4WKKMEgH/D/8P/w//D/8P/w//D/8P/w8AAAleh2SIgC6l/w//D/8P/w//D/8P /w//D/8PAADWXCl5CwAJBP8P/w//D/8P/w//D/8P/w//DwEAAQAAAABAAQAAAAAAAAAAAAAA AAAbAQAAABAAAA+EGwERhOX+XoQbAWCE5f4CAAAALgADAAAAAAABAAAAAAAAAAAAAAAAAAAA AAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygAAgAAAC4AAwAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAAxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/m8oAAEAAAABAAAAAAABAwAA AAAAAAAAAAAAAAAAAAADGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+bygAAwAAAC4AAQAB AAAAAAABAwUAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygA BQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAAxgAAA+E0AIRhDD9FcYFAAHQ AgZehNACYIQw/W8oAAcAAAAuAAEALgACAC4AAwABAAAAAAABAwUHCQAAAAAAAAAAAAAAAAAD GAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7bygACQAAAC4AAQAuAAIALgADAC4ABAABAAAA AAABAwUHCQsAAAAAAAAAAAAAAAADGAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7bygACwAA AC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAAxgAAA+EoAUR hGD6FcYFAAGgBQZehKAFYIRg+m8oAA0AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAA AAABAwUHCQsNDwAAAAAAAAAAAAADGAAAD4SgBRGEYPoVxgUAAaAFBl6EoAVghGD6bygADwAA AC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAAD GAAAD4SgBRGEYPoVxgUAAaAFBl6EoAVghGD6bygAEQAAAC4AAQAuAAIALgADAC4ABAAuAAUA LgAGAC4ABwAuAAgAAgAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+EwgERhD7+FcYFAAHC AQZehMIBYIQ+/m8oAAEAAAABAAAAAAABAwAAAAAAAAAAAAAAAAAAAAADGAAAD4TCARGEPv4V xgUAAcIBBl6EwgFghD7+bygAAwAAAC4AAQABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAADGAAA D4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygABQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAA AAAAAAAAAAAAAxgAAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw/W8oAAcAAAAuAAEALgACAC4A AwABAAAAAAABAwUHCQAAAAAAAAAAAAAAAAADGAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7 bygACQAAAC4AAQAuAAIALgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAADGAAAD4Q4 BBGEyPsVxgUAATgEBl6EOARghMj7bygACwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAA AQMFBwkLDQAAAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAA0AAAAu AAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAADGAAAD4Sg BRGEYPoVxgUAAaAFBl6EoAVghGD6bygADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4A BwABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAADGAAAD4QIBxGE+PgVxgUAAQgHBl6ECAdghPj4 bygAEQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgAAgAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAAxgAAA+EGwMRhOX8FcYFAAEbAwZehBsDYITl/G8oAAIAAAAuAAMAAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAMYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5vKAABAAAAAQAA AAAAAQMAAAAAAAAAAAAAAAAAAAAAAxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/m8oAAMA AAAuAAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAAxgAAA+E0AIRhDD9FcYFAAHQAgZehNAC YIQw/W8oAAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw /RXGBQAB0AIGXoTQAmCEMP1vKAAHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAA AAAAAAAAAxgAAA+EOAQRhMj7FcYFAAE4BAZehDgEYITI+28oAAkAAAAuAAEALgACAC4AAwAu AAQAAQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAAAxgAAA+EOAQRhMj7FcYFAAE4BAZehDgEYITI +28oAAsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMY AAAPhKAFEYRg+hXGBQABoAUGXoSgBWCEYPpvKAANAAAALgABAC4AAgAuAAMALgAEAC4ABQAu AAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg +m8oAA8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAA AAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oABEAAAAuAAEALgACAC4AAwAu AAQALgAFAC4ABgAuAAcALgAIAAMAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhGgBEYSY /hXGBQABaAEGXoRoAWCEmP5vKAABAAAAAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAAxgAAA+E aAERhJj+FcYFAAFoAQZehGgBYISY/m8oAAMAAAAuAAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAA AAAAAxgAAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw/W8oAAUAAAAuAAEALgACAAEAAAAAAAED BQcAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAAHAAAALgAB AC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAAxgAAA+EOAQRhMj7FcYFAAE4BAZe hDgEYITI+28oAAkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAA AxgAAA+EOAQRhMj7FcYFAAE4BAZehDgEYITI+28oAAsAAAAuAAEALgACAC4AAwAuAAQALgAF AAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMYAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCEYPpv KAANAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAA AxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+m8oAA8AAAAuAAEALgACAC4AAwAuAAQALgAF AC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZe hKAFYIRg+m8oABEAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAIAAAAXAAAA AAAAAAAAAAAAAAAAAAAAAA4YAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP41CABPSgQAUUoE AG8oAAEA2PALAAAA8DRRNAAAAAAAAAAAAAAAAKgJ5hsAAAAAAAAAAAAAAACoCeYbAAAAAKQv /QABAAAAqAnmGwAAAAD8L/0AAQAAAKgJ5hsAAAAAVJL9AAEAAAAJXodkAAAAAAAAAAAAAAAA +RasJAAAAAAAAAAAAAAAAN9o+FgAAAAAAAAAAAAAAACEJfEiAAAAAAAAAAAAAAAA1lwpeQAA AAAAAAAAAAAAAKh/9lUAAAAAAAAAAAAAAAD///////////////+wL/0AIAAAAAEAAAAAQAEA AAAAAAAAAAAAAAAAGwEAAAAQAAAPhBsBEYTl/l6EGwFghOX+AgAAAC4A//////CV/QAgAAAA AQAAAABAAQAAAAAAAAAAAAAAAAAbAQAAABAAAA+EGwERhOX+XoQbAWCE5f4CAAAALgD///// HJb9ACAAAAABAAAAAEABAAAAAAAAAAAAAAAAABsBAAAAEAAAD4QbARGE5f5ehBsBYITl/gIA AAAuAP//////////////////////////////////CAAAAAAAAAAAAAAAAAAAAAAAAAD/QDMt MjEwLTEAXFxQQ0FUVE5KUzAwMVxucy0zLTIxMC0xAEFET0JFUFM0ADMtMjEwLTEAMy0yMTAt MQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAMElADoAh93AAABAAEA6gpvCGQAAQAHAFgC AQACAFgCAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAwBIAAMgZ AAABAAAAAAAAAAEAAAABAAAAAAAAAAAAAAAAAAAAAAAAACA9UdL8vMnMppcRAAEAAQAAAAAA AQAAAAAAAgABAAEAUgMAAMIBAAAAAAAAAABkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD//wAA//8BAP//AAD//wAA//8AAP//AAD//wAA//8BAP//AQD//wAA//8BAP//AAD//wEA //8AAP//AAD//wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//Q3VzdG9tIHBhZ2UgMQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkEIAAJBCAAAAAAAAAAAAAAAA AABDdXN0b20gcGFnZSAyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACQQgAAkEIAAAAAAAAAAAAAAAAAAEN1c3RvbSBwYWdlIDMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJBCAACQQgAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAADMtMjEwLTEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAQDBJQA6AIfdwAAAQABAOoKbwhkAAEABwBYAgEAAgBYAgMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAACAAAAMASAADIGQAAAQAAAAAAAAABAAAAAQAAAAAAAAAAAAAA AAAAAAAAAAAgPVHS/LzJzKaXEQABAAEAAAAAAAEAAAAAAAIAAQABAFIDAADCAQAAAAAAAAAA ZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8AAP//AQD//wAA//8AAP//AAD//wAA //8AAP//AQD//wEA//8AAP//AQD//wAA//8BAP//AAD//wAA//8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//0N1 c3RvbSBwYWdlIDEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAJBCAACQQgAAAAAAAAAAAAAAAAAAQ3VzdG9tIHBhZ2UgMgAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkEIAAJBCAAAAAAAA AAAAAAAAAABDdXN0b20gcGFnZSAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACQQgAAkEIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALLAEA dBgAAJkYAACYfv0ABgAHAJgYAAAMAAAAmBgAAOokwHsCEAAAAAAAAACFGwAAYAAACABAAAAF AAAARxaQAQAAAgIGAwUEBQIDBIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAFQAaQBtAGUAcwAg AE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAA AACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBIc6AAAAAAAAAAAAAAAAAAD/ AAAAAAAAAEEAcgBpAGEAbAAAAD81kAEAAAIHAwkCAgUCBASHOgAAAAAAAAAAAAAAAAAA/wAA AAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAA7BpABAgAFAAAAAAAAAAAAAAAAAAAAABAA AAAAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMAAAAiAAQAQQCIAADw0AIAAGgBAAAA ABlURyb1W0dGXdREZgUADgAAAOsDAABXFgAAAQALAAAABACDEC8AAAAAAAAAAAAAAAEAAQAA AAEAAAAAAAAAxAMA8BCEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAApQbAB7QAtACAADIwAAAQABkAZAAAABkAAABvGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAHhIAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAP//EgAA AAAAJQBEADoAXABHAGEAcgB5AFMAdQBsAGwAXAA5ADkAMQAwAF8AcQAxADUAXwBSAGUAZABC AGEAbgBrAFwAcQAxADUAaQAuAGQAbwB0ACkASQBUAFUALQBUACAAVgBpAGQAZQBvACAAQwBv AGQAaQBuAGcAIABFAHgAcABlAHIAdABzACAARwByAG8AdQBwACAARABvAGMAdQBtAGUAbgB0 AAAAAAAAAA0AQgBhAHIAcgB5ACAASABhAHMAawBlAGwAbAANAEIAYQByAHIAeQAgAEgAYQBz AGsAZQBsAGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZ MAAAALABAAASAAAAAQAAAJgAAAACAAAAoAAAAAMAAADUAAAABAAAAOAAAAAFAAAA+AAAAAYA AAAEAQAABwAAABABAAAIAAAAIAEAAAkAAAA4AQAAEgAAAEQBAAAKAAAAYAEAAAsAAABsAQAA DAAAAHgBAAANAAAAhAEAAA4AAACQAQAADwAAAJgBAAAQAAAAoAEAABMAAACoAQAAAgAAAOQE AAAeAAAAKgAAAElUVS1UIFZpZGVvIENvZGluZyBFeHBlcnRzIEdyb3VwIERvY3VtZW50AHJk HgAAAAEAAAAAVFUtHgAAAA4AAABCYXJyeSBIYXNrZWxsAGRpHgAAAAEAAAAAYXJyHgAAAAEA AAAAYXJyHgAAAAUAAABxMTVpACBIYR4AAAAOAAAAQmFycnkgSGFza2VsbABkaR4AAAACAAAA NQBych4AAAATAAAATWljcm9zb2Z0IFdvcmQgOC4wAEVAAAAAANSt9AEAAABAAAAAALaTb8av vwFAAAAAAHa966zqvwFAAAAAAHa+nXHrvwEDAAAAAQAAAAMAAADrAwAAAwAAAFcWAAADAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3V nC4bEJOXCAArLPmuXAEAABgBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACEAAAABgAAAIwA AAARAAAAlAAAABcAAACcAAAACwAAAKQAAAAQAAAArAAAABMAAAC0AAAAFgAAALwAAAANAAAA xAAAAAwAAAD6AAAAAgAAAOQEAAAeAAAACgAAAEFUJlQgTGFicwBlAAMAAAAvAAAAAwAAAAsA AAADAAAAbxsAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAA AQAAACoAAABJVFUtVCBWaWRlbyBDb2RpbmcgRXhwZXJ0cyBHcm91cCBEb2N1bWVudAAMEAAA AgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAACYAAAAAwAAAAAAAAAgAAAAAQAAADYAAAACAAAA PgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA5AQAAEEAAABOAAAAewBDAEUAMQA3ADEA NQAwADEALQA1ADYAMwBEAC0AMQAxAEQANAAtADkARAAyAEIALQAwADAANAAwADAANQBBADQA NwA3ADcAQgB9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIA AAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0A AAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAA KwAAACwAAAAtAAAALgAAAC8AAAD+////MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgA AAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAA /v///0cAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAAD+////TwAAAFAAAABRAAAAUgAAAFMA AABUAAAAVQAAAP7////9////WAAAAP7////+/////v////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAwAAAAAAA AEYBAAAAAAAAAIMAAACXHQsAOgEAAG2acAEEAAAAFgAFAf//////////AwAAAAYJAgAAAAAA wAAAAAAAAEYAAAAAYFO976zqvwEgRcO4ceu/AVoAAACAAAAALMpEADEAVABhAGIAbABlAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAM8q AAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABoAAgEFAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAABT5 RQAGBADwAAAAAAEAAAAAAAAAMV4AAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEYAAAAAEAAAAAAAAAUARABvAGMA dQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA TgAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAIEXDuHHrvwEgRcO4ceu/AQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8BAP7/AwoAAP// //8GCQIAAAAAAMAAAAAAAABGGAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dv cmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA== --------------A250A2209BBAD0E6982DD34D-- From rem-conf Wed Jul 12 19:26:55 2000 From rem-conf-request@es.net Wed Jul 12 19:26:53 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13CYcX-0004Ih-00; Wed, 12 Jul 2000 19:21:01 -0700 Received: from c017-h014.c017.sfo.cp.net (c017.sfo.cp.net) [209.228.12.228] by mail1.es.net with smtp (Exim 1.81 #2) id 13CYcV-0004Gs-00; Wed, 12 Jul 2000 19:20:59 -0700 Received: (cpmta 19298 invoked from network); 12 Jul 2000 19:19:59 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO dhcp-168-0-6.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 12 Jul 2000 19:19:59 -0700 X-Sent: 13 Jul 2000 02:19:59 GMT Date: Wed, 12 Jul 2000 19:56:03 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net cc: Colin Perkins Subject: New addresses for AVT co-chairs Message-ID: Sender: casner@mail.packetdesign.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: As some of you may have noticed, the email addresses for both of your working group co-chairs have changed recently. The new addresses are: Colin Perkins USC Information Sciences Institute 4350 N. Fairfax Drive #620 Arlington VA 22203 USA email: csp@isi.edu Stephen Casner Packet Design, Inc. 66 Willow Place Menlo Park, CA 94025 USA email: casner@acm.org (You may also see casner@packetdesign.com, but I decided to use an indirect address for unaffiliated business.) In addition, I should also explain that I have taken a leave / sabbatical / vacation / whatever, including from email, for the past three months starting right after the last IETF meeting. Although it wasn't part of my plan when I began the leave, it turns out that I changed jobs as well. I thank Colin for handling the AVT chair role mostly by himself during that time. -- Steve From rem-conf Wed Jul 12 21:00:46 2000 From rem-conf-request@es.net Wed Jul 12 21:00:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ca6E-0000CN-00; Wed, 12 Jul 2000 20:55:46 -0700 Received: from pluto.anglia.ac.uk [193.63.55.3] by mail1.es.net with smtp (Exim 1.81 #2) id 13Ca5C-000097-00; Wed, 12 Jul 2000 20:55:43 -0700 Received: by pluto.anglia.ac.uk (5.65/DEC-Ultrix/4.3) id AA22702; Thu, 13 Jul 2000 04:52:22 +0100 Date: Thu, 13 Jul 2000 04:52:22 +0100 From: mike898@yybecker234.mx Message-Id: <10007130352.AA22702@pluto.anglia.ac.uk> To: Subject: ADV: High Search Engine Placement Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Length: 483 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Removal instructions below I saw your listing on the internet. I work for a company that specializes in getting clients web sites listed as close to the top of the major search engines as possible. Our fee is only $29.95 per month to submit your site at least twice a month to over 350 search engines and directories. To get started and put your web site in the fast lane, call our toll free number below. Mike Bender 888-532-8842 To be removed call: 888-800-6339 X1377 From rem-conf Thu Jul 13 11:57:41 2000 From rem-conf-request@es.net Thu Jul 13 11:57:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13CnyO-0007nG-00; Thu, 13 Jul 2000 11:44:36 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 13CnyM-0007n6-00; Thu, 13 Jul 2000 11:44:34 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id 738644CE4A; Thu, 13 Jul 2000 14:44:33 -0400 (EDT) Received: from VTPC3 (mtjukebox [135.207.130.81]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id OAA14294; Thu, 13 Jul 2000 14:43:11 -0400 (EDT) Message-ID: <012901bfecfa$91c020d0$5182cf87@VTPC3> From: "M. Reha Civanlar" To: Cc: Subject: draft-ietf-avt-rtp-mpeg4-03 Date: Thu, 13 Jul 2000 14:45:51 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0126_01BFECD9.0A83A040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0126_01BFECD9.0A83A040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I am enclosing an updated version (03) of the ID entitled: RTP Payload Format for MPEG-4 Streams - draft-ietf-avt-rtp-mpeg4-03 This document describes a payload format for transporting MPEG-4 encoded data using RTP. Thanks. ---------------------------------------------------------------------------- ---------- M. Reha Civanlar Division Manager, AT&T Labs - Research 100 Schultz Drive, 3-215, Red Bank, NJ 07701, U.S.A Ph: +1 732 345 3305 Fax: +1 732 345 3033 civanlar@research.att.com http://www.research.att.com/info/mrc ------=_NextPart_000_0126_01BFECD9.0A83A040 Content-Type: text/plain; name="draft-ietf-avt-rtp-mpeg4-03.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-avt-rtp-mpeg4-03.txt" Internet Engineering Task Force Civanlar-AT&T/Basso-AT&T INTERNET DRAFT Casner-Packet Design File: draft-ietf-avt-rtp-mpeg4-03.txt Herpel-Thomson/Perkins-ISI July 13, 2000 Expires: Jan 13, 2001 RTP Payload Format for MPEG-4 Streams STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a payload format for transporting MPEG-4 encoded data using RTP. MPEG-4 is a recent standard from ISO/IEC for the coding of natural and synthetic audio-visual data. Several services provided by RTP are beneficial for MPEG-4 encoded data transport over the Internet. Additionally, the use of RTP makes it possible to synchronize MPEG-4 data with other real-time data types. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force and ISO/IEC MPEG-4 ad hoc group on MPEG-4 over Internet. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. Civanlar/Basso/Casner/Herpel/Perkins [Page 1] =0C INTERNET-DRAFT RTP Payload Format for MPEG-4 Streams July 2000 1. Introduction MPEG-4 is a recent standard from ISO/IEC for the coding of natural and synthetic audio-visual data in the form of audiovisual objects that are arranged into an audiovisual scene by means of a scene description [1][2][3][4]. This draft specifies an RTP [5] payload format for transporting MPEG-4 encoded data streams. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. The benefits of using RTP for MPEG-4 data stream transport include: i. Ability to synchronize MPEG-4 streams with other RTP payloads ii. Monitoring MPEG-4 delivery performance through RTCP iii. Combining MPEG-4 and other real-time data streams received from multiple end-systems into a set of consolidated streams through RTP mixers iv. Converting data types, etc. through the use of RTP translators. 1.1 Overview of MPEG-4 End-System Architecture Fig. 1 below shows the general layered architecture of MPEG-4 terminals. The Compression Layer processes individual audio-visual media streams. The MPEG-4 compression schemes are defined in the ISO/IEC specifications 14496-2 [2] and 14496-3 [3]. The compression schemes in MPEG-4 achieve efficient encoding over a bandwidth ranging from several Kbps to many Mbps. The audio-visual content compressed by this layer is organized into Elementary Streams (ESs). The MPEG-4 standard specifies MPEG-4 compliant streams. Within the constraint of this compliance the compression layer is unaware of a specific delivery technology, but it can be made to react to the characteristics of a particular delivery layer such as the path-MTU or loss characteristics. Also, some compressors can be designed to be delivery specific for implementation efficiency. In such cases the compressor may work in a non-optimal fashion with delivery technologies that are different than the one it is specifically designed to operate with. The hierarchical relations, location and properties of ESs in a presentation are described by a dynamic set of Object Descriptors (ODs). Each OD groups one or more ES Descriptors referring to a single content item (audio-visual object). Hence, multiple alternative or hierarchical representations of each content item are possible. Civanlar/Basso/Casner/Herpel/Perkins [Page 2] =0C INTERNET-DRAFT RTP Payload Format for MPEG-4 Streams July 2000 ODs are themselves conveyed through one or more ESs. A complete set of ODs can be seen as an MPEG-4 resource or session description at a stream level. The resource description may itself be hierarchical, i.e. an ES conveying an OD may describe other ESs conveying other ODs. The session description is accompanied by a dynamic scene description, Binary Format for Scene (BIFS), again conveyed through one or more ESs. At this level, content is identified in terms of audio-visual objects. The spatiotemporal location of each object is defined by BIFS. The audio-visual content of those objects that are synthetic and static are described by BIFS also. Natural and animated synthetic objects may refer to an OD that points to one or more ESs that carry the coded representation of the object or its animation data. By conveying the session (or resource) description as well as the scene (or content composition) description through their own ESs, it is made possible to change portions of the content composition and the number and properties of media streams that carry the audio-visual content separately and dynamically at well known instants in time. One or more initial Scene Description streams and the corresponding OD streams has to be pointed to by an initial object descriptor (IOD). The IOD needs to be made available to the receivers through some out-of- band means which are not defined in this document. A homogeneous encapsulation of ESs carrying media or control (ODs, BIFS) data is defined by the Sync Layer (SL) that primarily provides the synchronization between streams. The Compression Layer organizes the ESs in Access Units (AU), the smallest elements that can be attributed individual timestamps. Integer or fractional AUs are then encapsulated in SL packets. All consecutive data from one stream is called an SL-packetized stream at this layer. The interface between the compression layer and the SL is called the Elementary Stream Interface (ESI). The ESI is informative. The Delivery Layer in MPEG-4 consists of the Delivery Multimedia Integration Framework defined in ISO/IEC 14496-6 [4]. This layer is media unaware but delivery technology aware. It provides transparent access to and delivery of content irrespective of the technologies used. The interface between the SL and DMIF is called the DMIF Application Interface (DAI). It offers content location independent procedures for establishing MPEG-4 sessions and access to transport channels. The specification of this payload format is considered as a part of the MPEG-4 Delivery Layer. Civanlar/Basso/Casner/Herpel/Perkins [Page 3] =0C INTERNET-DRAFT RTP Payload Format for MPEG-4 Streams July 2000 media aware +-----------------------------------------+ delivery unaware | COMPRESSION LAYER | 14496-2 Visual |streams from as low as Kbps to multi-Mbps| 14496-3 Audio +-----------------------------------------+ = Elementary Stream = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DInterface (ESI) +-------------------------------------------+ media and | SYNC LAYER | delivery unaware | manages elementary streams, their synch- | 14496-1 Systems | ronization and hierarchical relations | +-------------------------------------------+ DMIF = Application = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DInterface (DAI) +-------------------------------------------+ delivery aware | DELIVERY LAYER | media unaware |provides transparent access to and delivery| 14496-6 DMIF | of content irrespective of delivery | | technology | +-------------------------------------------+ Figure 1: General MPEG-4 terminal architecture 1.2 MPEG-4 Elementary Stream Data Packetization The ESs from the encoders are fed into the SL with indications of AU boundaries, random access points, desired composition time and the current time. The Sync Layer fragments the ESs into SL packets, each containing a header which encodes information conveyed through the ESI. If the AU is larger than an SL packet, subsequent packets containing remaining parts of the AU are generated with subset headers until the complete AU is packetized. The syntax of the Sync Layer is not fixed and can be adapted to the needs of the stream to be transported. This includes the possibility to select the presence or absence of individual syntax elements as well as configuration of their length in bits. The configuration for each individual stream is conveyed in an SLConfigDescriptor, which is an integral part of the ES Descriptor for this stream. 2. Analysis of the alternatives for carrying MPEG-4 over IP 2.1 MPEG-4 over UDP Considering that the MPEG-4 SL defines several transport related Civanlar/Basso/Casner/Herpel/Perkins [Page 4] =0C INTERNET-DRAFT RTP Payload Format for MPEG-4 Streams July 2000 functions such as timing, sequence numbering, etc., this seems to be the most straightforward alternative for carrying MPEG-4 data over IP. One group of problems with this approach, however, stems from the monolithic architecture of MPEG-4. No other multimedia data stream (including those carried with RTP) can be synchronized with MPEG-4 data carried directly over UDP. Furthermore, the dynamic scene and session control concepts can't be extended to non-MPEG-4 data. Even if the coordination with non-MPEG-4 data is overlooked, carrying MPEG-4 data over UDP has the following additional shortcomings: i. Mechanisms need to be defined to protect sensitive parts of MPEG-4 data. Some of these (like FEC) are already defined for RTP. ii. There is no defined technique for synchronizing MPEG-4 streams from different servers in the variable delay environment of the Internet. iii. MPEG-4 streams originating from two servers may collide (their sources may become unresolvable at the destination) in a multicast session. iv. An MPEG-4 backchannel needs to be defined for quality feedback similar to that provided by RTCP. v. RTP mixers and translators can't be used. The backchannel problem may be alleviated by developing a reception reporting protocol like RTCP. Such an effort may benefit from RTCP design knowledge, but needs extensions. 2.2 RTP header followed by full MPEG-4 headers This alternative may be implemented by using the send time or the composition time coming from the reference clock as the RTP timestamp. This way no new feedback protocol needs to be defined for MPEG-4's backchannel, but RTCP may not be sufficient for MPEG-4's feedback requirements which are still in the definition stage. Additionally, due to the duplication of header information, such as the sequence numbers and time stamps, this alternative causes unnecessary increases in the overhead. Scene description or dynamic session control can't be extended to non-MPEG-4 streams also. 2.3 MPEG-4 ESs over RTP with individual payload types This is the most suitable alternative for coordination with the existing Internet multimedia transport techniques and does not use MPEG-4 systems Civanlar/Basso/Casner/Herpel/Perkins [Page 5] =0C INTERNET-DRAFT RTP Payload Format for MPEG-4 Streams July 2000 at all. Complete implementation of it requires definition of potentially many payload types, as already proposed for audio and video payloads [7], and might lead to constructing new session and scene description mechanisms. Considering the size of the work involved which essentially reconstructs MPEG-4 systems, this may only be a long term alternative if no other solution can be found. 2.4 RTP header followed by a reduced SL header The inefficiency of the approach described in 2.2 can be fixed by using a reduced SL header that does not carry duplicate information following the RTP header. 2.5 Recommendation Based on the above analysis, the best compromise is to map the MPEG-4 SL packets onto RTP packets, such that the common pieces of the headers reside in the RTP header that is followed by an optional reduced SL header providing the MPEG-4 specific information. The details of this payload format are described in the next section. 3. Payload Format The RTP Payload consists of a single SL packet, including an SL packet header without the sequenceNumber and compositionTimeStamp fields. Use of all other fields in the SL packet headers that the RTP header does not duplicate (including the decodingTimeStamp) is OPTIONAL. Packets SHOULD be sent in the decoding order. If the resulting, smaller, SL packet header consumes a non-integer number of bytes, zero padding bits MUST be inserted at the end of the SL header to byte-align the SL packet payload. The size of the SL packets SHOULD be adjusted such that the resulting RTP packet is not larger than the path-MTU. To handle larger packets, this payload format relies on lower layers for fragmentation which may not be desirable. Civanlar/Basso/Casner/Herpel/Perkins [Page 6] =0C INTERNET-DRAFT RTP Payload Format for MPEG-4 Streams July 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|P|X| CC |M| PT | sequence number | RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : contributing source (CSRC) identifiers : +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+= =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ |SL Packet Header (variable # of bytes) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP | | | SL Packet Payload (byte aligned) | = Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | :...OPTIONAL RTP padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - An RTP packet for MPEG-4 3.1 RTP Header Fields Usage: Payload Type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done then a payload type in the dynamic range shall be chosen. Marker (M) bit: Set to one to mark the last fragment (or only fragment) of an AU. Extension (X) bit: Defined by the RTP profile used. Sequence Number: Derived from the sequenceNumber field of the SL packet by adding a constant random offset. If the sequenceNumber has less than 16-bit length, the MSBs MUST initially be filled with a random value that is incremented by one each time the sequenceNumber value of the SL packet returns to zero. If the value sequenceNumber=3D0 is encountered = in multiple consecutive SL packets, indicating a deliberate duplication of the SL packet, the sequence number SHOULD be incremented by one for each of these packets after the first one. In implementations where full SL packets are generated first and then packetised in RTP, the sequenceNumber MUST be removed from the SL packet header by bit-shifting the subsequent header elements towards the beginning of the header. When unpacking the RTP packet this process can Civanlar/Basso/Casner/Herpel/Perkins [Page 7] =0C INTERNET-DRAFT RTP Payload Format for MPEG-4 Streams July 2000 be reversed with the knowledge of the SLConfigDescriptor. For using this payload format, MPEG-4 implementations that do not produce the full SL packet in the first place, but rather produce the RTP header and stripped down (perhaps null) SL header directly are preferable. However, the choice between generating SL packets and converting, or generating RTP directly is an implementation detail, and does not affect what goes on the wire. Both forms will interwork. If no sequenceNumber field is configured for this stream (no sequenceNumber field present in the SL packet header), then the RTP packetizer MUST generate its own sequence numbers. Timestamp: Set to the value in the compositionTimeStamp field of the SL packet, if present. If compositionTimeStamp has less than 32 bits length, the MSBs of timestamp MUST be set to zero. Although it is available from the SL configuration data, the resolution of the timestamp may need to be conveyed explicitly through some out- of-band means to be used by network elements which are not MPEG-4 aware. If compositionTimeStamp has more than 32 bits length, this payload format cannot be used. In case compositionTimeStamp is not present in the current SL packet, but has been present in a previous SL packet, this same value MUST be taken again as the compositionTimeStamp of the current SL packet. If compositionTimeStamp is never present in SL packets for this stream, the RTP packetizer SHOULD convey a reading of a local clock at the time the RTP packet is created. Similar to handling of the sequence numbers in implementations that generate full SL packets, the compositionTimeStamp, if present, MUST then be removed from the SL packet header by bit-shifting the subsequent header elements towards the beginning of the SL packet header. When unpacking the RTP packet this process can be reversed with the knowledge of the SLConfigDescriptor and by evaluating the compositionTimeStampFlag. Timestamps are recommended to start at a random value for security reasons [5, Section 5.1]. SSRC: set as described in RFC1889 [5]. A mapping between the ES identifiers (ESIDs) and SSRCs should be provided through out-of-band means. CC and CSRC fields are used as described in RFC 1889 [5]. Civanlar/Basso/Casner/Herpel/Perkins [Page 8] =0C INTERNET-DRAFT RTP Payload Format for MPEG-4 Streams July 2000 RTCP SHOULD be used as defined in RFC 1889 [5]. RTP timestamps in RTCP SR packets: according to the RTP timing model, the RTP timestamp that is carried into an RTCP SR packet is the same as the CTS that would be applied to an RTP packet for data that was sampled at the instant the SR packet is being generated and sent. The RTP timestamp value is calculated from the NTP timestamp for the current time which also goes in the RTCP SR packet. To perform that calculation, an implementation needs to periodically establish a correspondence between the CTS value of a data packet and the NTP time at which that data was sampled. 4. Multiplexing Since a typical MPEG-4 session may involve a large number of objects, that may be as many as a few hundred, transporting each ES as an individual RTP session may not always be practical. Allocating and controlling hundreds of destination addresses for each MPEG-4 session may pose insurmountable session administration problems. The input/output processing overhead at the end-points will be extremely high also. Additionally, low delay transmission of low bitrate data streams, e.g. facial animation parameters, results in extremely high header overheads. To solve these problems, MPEG-4 data transport requires a multiplexing scheme that allows selective bundling of several ESs. This is beyond the scope of the payload format defined here. MPEG-4's Flexmux multiplexing scheme may be used for this purpose by defining an additional RTP payload format for "multiplexed MPEG-4 streams." On the other hand, considering that many other payload types may have similar needs, a better approach may be to develop a generic RTP multiplexing scheme usable for MPEG-4 data. The multiplexing scheme reported in [8] may be a candidate for this approach. For MPEG-4 applications, the multiplexing technique needs to address the following requirements: i. The ESs multiplexed in one stream can change frequently during a session. Consequently, the coding type, individual packet size and temporal relationships between the multiplexed data units must be handled dynamically. ii. The multiplexing scheme should have a mechanism to determine the ES identifier (ES_ID) for each of the multiplexed packets. ES_ID is not a part of the SL header. iii. In general, an SL packet does not contain information about its size. The multiplexing scheme should be able to delineate the Civanlar/Basso/Casner/Herpel/Perkins [Page 9] =0C INTERNET-DRAFT RTP Payload Format for MPEG-4 Streams July 2000 multiplexed packets whose lengths may vary from a few bytes to close to the path-MTU. 5. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [5]. This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied end-to-end, encryption may be performed on the compressed data so there is no conflict between the two operations. This payload type does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing to cause a potential denial-of-service threat. 6. References [1] ISO/IEC 14496-1 FDIS MPEG-4 Systems November 1998 [2] ISO/IEC 14496-2 FDIS MPEG-4 Visual November 1998 [3] ISO/IEC 14496-3 FDIS MPEG-4 Audio November 1998 [4] ISO/IEC 14496-6 FDIS Delivery Multimedia Integration Framework, November 1998. [5] Schulzrinne, Casner, Frederick, Jacobson RTP: A Transport Protocol for Real Time Applications RFC 1889, Internet Engineering Task Force, January 1996. [6] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, March 1997. [7] Y. Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata, RTP payload format for MPEG-4 Audio/Visual streams, work in progress, draft-ietf-avt-rtp-mpeg4-es-02.txt, July 2000. [8] B. Thompson, T. Koren, D. Wing, Tunneling multiplexed Compressed RTP ("TCRTP"), work in progress, draft-ietf-avt-tcrtp-00.txt, March 2000. Civanlar/Basso/Casner/Herpel/Perkins [Page 10] =0C INTERNET-DRAFT RTP Payload Format for MPEG-4 Streams July 2000 7. Authors' Addresses M. Reha Civanlar AT&T Labs - Research 100 Schultz Drive Red Bank, NJ 07701 USA e-mail: civanlar@research.att.com Andrea Basso AT&T Labs - Research 100 Schultz Drive Red Bank, NJ 07701 USA e-mail: basso@research.att.com Stephen L. Casner Packet Design, Inc. 66 Willow Place Menlo Park, CA 94025 USA casner@acm.org Carsten Herpel THOMSON multimedia Karl-Wiechert-Allee 74 30625 Hannover Germany e-mail: herpelc@thmulti.com Colin Perkins USC Information Sciences Institute 4350 N. Fairfax Drive #620 Arlington, VA 22203 USA e-mail: csp@isi.edu Civanlar/Basso/Casner/Herpel/Perkins [Page 11] =0C ------=_NextPart_000_0126_01BFECD9.0A83A040-- From rem-conf Thu Jul 13 16:03:48 2000 From rem-conf-request@es.net Thu Jul 13 16:03:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Cruh-0007CY-00; Thu, 13 Jul 2000 15:57:03 -0700 Received: from (tsmtp4.mail.isp) [195.235.113.151] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Cruf-000776-00; Thu, 13 Jul 2000 15:57:01 -0700 Received: from cultureta ([195.5.71.133]) by tsmtp4.mail.isp (Netscape Messaging Server 4.1) with SMTP id FXNRN201.SMH; Fri, 14 Jul 2000 00:54:38 +0200 Message-ID: <00c801bfed1d$7f2c2fe0$fe00a0be@cultureta> From: "Damos a conocer la Cultura" To: Subject: Actualidad Cultural diaria Date: Fri, 14 Jul 2000 00:51:01 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00A8_01BFED2D.94B40440"; type="multipart/alternative" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_00A8_01BFED2D.94B40440 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A9_01BFED2D.94B40440" ------=_NextPart_001_00A9_01BFED2D.94B40440 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 =20 Otros Titulares=20 n Sonidos c=E1lidos para el verano malague=F1o =20 n El litoral andaluz propone un rico programa de actividades = culturales =20 n Diego Carrasco: un inquilino con muchas guasa=20 n XX Festival de la Guitarra de C=F3rdoba=20 n Cursos de verano: de vacaciones en las aulas=20 -------------------------------------------------------------------------= - Portada=20 Noticias culturales=20 Versi=F3n multimedia=20 Cr=EDtica de eventos=20 Rese=F1as de discos=20 Rese=F1as de libros=20 Cartelera de Andaluc=EDa=20 Espacio Virtual de las Artes=20 Andaluc=EDa Cultural=20 Entrevistas=20 Reportajes=20 Eventos=20 Denominaci=F3n de Origen=20 Temas de Actualidad =20 PEPA D=CDAZ-MECO, triunfadora en la Feria de Palma de teatro =20 Bajo los pies de Pepa D=EDaz-Meco se acumula una monta=F1a de = trajes, trapos de abrigo y de verano con los que esta manchega afincada = en Sevilla ha ido disfrazando m=E1s de dos d=E9cadas dedicadas al = teatro. =20 M=E1s Informaci=F3n =20 =20 -------------------------------------------------------------------------= - =20 -------------------------------------------------------------------------= - =20 Ruta por los festivales de teatro cl=E1sico que se celebran = durante el verano en Espa=F1a =20 El corral de comedias de Almagro, el patio de los Guzmanes del = castillo mud=E9jar de Niebla o el anfiteatro romano de M=E9rida acogen = durante el verano una atractiva programaci=F3n que combina las obras de = teatro con los espect=E1culos de m=FAsica y danza.=20 M=E1s Informaci=F3n =20 =20 -------------------------------------------------------------------------= - =20 Denominaci=F3n de origen=20 Mar=EDa Esther Guzm=E1n Entrevista=20 Antonio Orejudo =20 =20 portada / contenidos multimedias de la semana / sugerencias / = sobre elcultural.com/ dossier de prensa=20 =20 Si no quieres volver a recibir mensajes de elcultural.com pincha = aqu=ED y b=F3rrate de la Secci=F3n Contenidos de Actualidad=20 =20 =20 =20 ------=_NextPart_001_00A9_01BFED2D.94B40440 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 

Otros=20 Titulares

 n = Sonid= os=20 c=E1lidos para el verano malague=F1o =20

 n = El= =20 litoral andaluz propone un rico programa de actividades=20 culturales =20

 n = D= iego=20 Carrasco: un inquilino con muchas guasa=20

 n = XX = Festival=20 de la Guitarra de C=F3rdoba=20

 n = Curs= os=20 de verano: de vacaciones en las aulas=20

Portada =
Noticias = culturales=20
Versi=F3n=20 multimedia
Cr=EDtica=20 de eventos
Rese=F1as de=20 discos
Rese=F1as = de=20 libros
Cartelera de = Andaluc=EDa=20
Espacio Virtual = de las=20 Artes
Andaluc=EDa=20 Cultural
Entr= evistas=20
Repor= tajes=20
Eventos<= /A>=20
De= nominaci=F3n=20 de Origen
Temas de=20 Actualidad
PEPA D=CDAZ-MECO, = triunfadora en la Feria=20 de Palma de teatro 
Bajo=20 los pies de Pepa D=EDaz-Meco se acumula una monta=F1a de trajes, = trapos de=20 abrigo y de verano con los que esta manchega afincada en Sevilla = ha ido=20 disfrazando m=E1s de dos d=E9cadas dedicadas al = teatro. =20
M=E1= s=20 Informaci=F3n
Ruta por los festivales de = teatro=20 cl=E1sico que se celebran durante el verano en = Espa=F1a
El corral de comedias de = Almagro, el=20 patio de los Guzmanes del castillo mud=E9jar de Niebla o el = anfiteatro=20 romano de M=E9rida acogen durante el verano una atractiva = programaci=F3n que=20 combina las obras de teatro con los espect=E1culos de m=FAsica y=20 danza.
M=E1s= =20 Informaci=F3n

Denominaci=F3n de = origen=20
Mar=EDa=20 Esther Guzm=E1n		 Entrevista=20
Ant= onio=20 Orejudo



portada / contenidos=20 multimedias de la semana / sugerencias / sobre=20 elcultural.com/ dossier de=20 prensa
 =20

Si no quieres = volver a recibir=20 mensajes de elcultural.com pincha aqu=ED y = b=F3rrate=20 de la Secci=F3n Contenidos de Actualidad =

 
------=_NextPart_001_00A9_01BFED2D.94B40440-- ------=_NextPart_000_00A8_01BFED2D.94B40440 Content-Type: image/jpeg; name="elcultural.jpg" Content-Transfer-Encoding: base64 Content-ID: <00a301bfed1c$d1220c80$fe00a0be@cultureta> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAATQAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAADFwAABh8AAAgyAAAK3//bAIQAAwICAgICAwICAwQDAgMEBQQDAwQFBgUFBQUFBgcG BgYGBgYHBwgJCQkIBwsLDAwLCw0MDAwNDg4ODg4ODg4ODgEDAwMGBQYLBwcLEA0KDRATDg4ODhMR Dg4ODg4REQ4ODg4ODhEODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O/8IAEQgADQB7AwERAAIR AQMRAf/EAMsAAQEBAQAAAAAAAAAAAAAAAAYEBQcBAAMBAQEAAAAAAAAAAAAAAAECBAMFABAAAAUE AQIFBQAAAAAAAAAAAQIEBQYAERIDIhMUECEVFgcgMDEjFxEAAQIEBAUDAgUFAAAAAAAAAQIDERIE BQAhExQxQTIVBlFhIkIz8HGBoSSxI0MlFhIAAgIBAwMFAAAAAAAAAAAAABEBAjEhYYFBwRJQoSIy ghMAAgMAAgIBBAIDAQAAAAAAAREAITFBUWFxoRCBkbHw0SDB4fH/2gAMAwEAAhEDEQAAAejdnMXc jaF7s/GagOtXqvJc7QEE5E3L2LjaAegl+Zydhn6DSyIa9d6cl6l08ibpDKNitS7mBuQi7V6hynAd FLczYnpm9ch//9oACAEBAAEFAnv5CIhdZLMlD/G980ctq5TNFCda7zrcqa1sglaJDqm2wzwb5M3E aF8sfG5G4z/e7QpiMdDGU06fXLW6TdURy3fJpPRzfJjqUf6SPauRGw0pXlY/VR1pRXyQrSLyQka9 nSMjaaSvRGcX9ISOd3JCIBnvTjPsnaVB7mY9eoEjyRvNIiliQqxIx9jjGOh//9oACAECAAEFAtaS 4aU+BwTBYE1w1pbCXUQRFNx7LkXQURIlx2bfM4pSloiYLAi5dkWuz8yXwLlbztpyx59TTfDXlibO 2m/S59QL4bfzrvh+y3K/Ov/aAAgBAwABBQK9CNXq9Xq9XrKr1fwvV6yrKsvoHwHxH7H/2gAIAQIC Bj8CckvVDtKZaXgruWtJEvJMPBpJEEoU21HaUTDwR8smeq7kPjJcr5LYthEYwWK42Lm3PY6YISzy T9fIq1sXZT2P0f/aAAgBAwIGPwL0D//aAAgBAQEGPwJ+z21hl5+kQVVLtRUJp0RH0Im6lYtLloU9 QVdfXaKw2shQkyICkwiIrGKy2+M2pVzTbPjVvqdCPkMpU5GY5YsluXblN1l2P91l1cFMfKXkDHme WPJm6Zrbi2Qp2qtLnyUtxZbiMhDhHjjxyyUOq5U1rKKhx0ujVqJ1TacyolOXPFxtbtGEJtlFuql3 Uj8ghKlN9PqYRxbLl2yZ+5vuNNUyXc5WyExBlziTimXWWtmnq6hSpw9WNoaaSD8ZlniT7YutYy2a KuYdbpkuNORBK1dSFgJPAHFG7cXVKW3SJdqXnCVHpmUSTnjuVp8fcqbIXdNLodGqqHFQbh+PXFRa rBbjX1NE1q1qlOBpLYhGXnE4tlypaBTr9wfUxtZ4FKkQjKYZ9Q9MXNk2M7m25vDXTK2mMDOYf0jj ddvy7V3GXU+rcbeTp4c4/ti8G0P1jdTH/YJSzSLTNz0lVDqDGPoI48TNQ5Vghz+MktsmL06Y6ykr ABjDpBxe1ePP3lNu1z3NFIyyr5THoUp1K+MeUYYsBpnbui4ikTtktNpW8UxV1F5aSF8Y5HFzCX7j t+4t7tSmW9aMDKJS7CEecYx5Y8e2b1aivFK1sgw00tJbz5rcRAwjHjjyEtvXcCCu4pp2WigCI4qL oJRH2GPDoO1ekEnYgtNyqXqGOodTIzekcRQ9Wouu3TBCWqZSCmX/AAqqHEwP6ceGFDXuGw7t/IVo ta2ppZBQ1YS+8ePLF3VXOXE0Hb1zokhRhnSRHSUFmJl9sUBbfvyvGNwduhtltImjnOpl1Tkv6fli +mzvXVBkPek0rLK0S/VKpbqFft68seImicqRQhStiiRBSXtQTayisEKmhwBx5kFPVuuX0dxOi1OB rK+0NWBEfWGWPuVWl/y0Pto+xrdXX9yflw98f//aAAgBAQMBPyEXpiVAC4CbEhzGTDFLfUhPHqas LgPIJIwvJINd5+eRQJEjpToIYU+0moQ6GoUa96YY+OQQDHnoQ712HGgUotlpqbUShkuskAh7lS2k tmoAGhIFWyoUgEsQFAJGT/QnehK4JFdFIiTBQ9p1B1uh6gEBIRaXdBowEnf2oG5uUVq1Ae+lAXx2 OIXX1OWe3ftHzqN4BLmzLZ2GqUMIMJnzej0FKleFNdaYLuVP04EZPr8TUgV/dGVjIICRZ061fTEF Erh6qHfOD1CPYVBCnK6XaIjVoeNxTx8C5OS8M3gNG2Rz0XHyQFKk99wqGmNucyfz/wCahtLuoEG3 MlyRy0R4R969kVOAksVKaoqdNDkMyRdPpbM3/9oACAECAwE/IV5ijiDgsMD/AJ+ICHTBBYD5QDd6 Xq5joCsoLnzAo6If3AHAA37h80gdAswJawncBQOamUvj+YcKg0OXLBQG5ox4fqcX8AtCrwvL5IGH WXncXEdC60T80oVja+vgZCcDYuv1CuAJ2yd/Bh4vcT/WwsI8/jiuofALd/JI+Ns2VvqFyT5Hz94R sFFsn/YUOp9pP9GE4D59Lj7R5Qly8c1G3H916xf+T//aAAgBAwMBPyEywTx+k7jV9YlC4gyPD/hB 2FVPX0UpoQ7KqalKcwQ7KqVcr4n/2gAMAwEAAhEDEQAAEMY0ruocW5X5FYtd8v/aAAgBAQMBPxA5 QiD9pBaGhaJCbpq7Ai4oGoGkAjBXTCmYGCDSCCMEJyA0bfIELDCaJQMFsuS4kogkCjCiF/gRvLEV hBawlrUoeiBVRt6IMRlrzFRly6Bw3Ar2s2hgCDaiZf13BFA4gxEG6rbui6YzXsSShDiON+AxRgQW WwLSLp33bEgEBG8AaVRAQSxKLs5EoB/69goSfsKDH8oh8z/5Bgf8DQMMSDI4aJapwovsuZTFASo5 cCQ1K0cOWCsKrreHO2lJIJQ4NmbGpcWbDHaesZnVGLEV3BOIXueJnVFV22Ib733rk8F7Cu8wwmmG oCfUWJQAhU4tEWwBXA4MC5vD3IpSRb3Yslbrule+DOkcoqCoFJUiThh0aLlNF4WJ/BrEZ2hNqChc hBGvoR7P/9oACAECAwE/EDBYVAY/ZWCBgAlMVfKLRtBHjuAOuz1o8eYKonEgMVfdcDmEM2vIUAGr vrIugFAOCVBTdL5MAaCuXBJA14a8wqnCIhyBKN9CDUABNE5Q4Hv9XC4PJQ6GEXyoIJAEwArlCGF0 NKni3/fEcDNIby8D+VDlOAo4L26wvYDeoWZKdP7Sifp/HmbwvmDsvgD4QTOyvvKFzy5CUhkJ6RAI RGwSkMAunKeQRYm2KZDGA4ViX2woXR34cJLmAvr6g46YGlkvug1M4GE8mcgHzLAx2DyUBQlZZAW+ JK+4CTlT4IOh5PhZzEcKSL5GFnsaUKABoIpUgJur91AGW8QvhgA+VnMoKnmeRKixZMjzc8kmiNfQ V4Nzpv5n1ftbH//aAAgBAwMBPxBZQhQKmYSZANQkCAtjx4QgADmCxCwTIK2BCx8xqZUHAawKhGgG oagrY91kxnDiMv8AUsimbLmIxrgt3YlDcVtgtCd39p7U4UzaUyNUVk/M2kxr6H//2Q== ------=_NextPart_000_00A8_01BFED2D.94B40440 Content-Type: image/gif; name="logo2.gif" Content-Transfer-Encoding: base64 Content-ID: <00a401bfed1c$d1220c80$fe00a0be@cultureta> R0lGODlhRAA4AOZ/AGlhp9fV6EtCoUY/j0tEmU9Jk1hSnWhjmXhzrpOPuklDlkZBjU5ImVROolJN nlZRpVVRmbWz0cbF3lRTleXl8E9Sl0xSiVNchVlkgl+DdVmMXFqcO+r15VWkKZjAg1O9ElasIlqy Jlu0J2O9LF21KlqjLeXx3ly8HFOtGlGkGlqyHmG/IVKlHVu1IGG+JV+6JFGhH2G6JV21JVqrI2K2 Kl2sKmnBMGq7NpnOdtXqx1e2FVq0GE+gF1anHV60IGXAI2K5Il6xImW+J2W5JmO1Jl+yJlehI4DD To2+a8DiqLnWpcnktt/v1FS7AEacAFSxC0yeC1m2Dl3AEFu5ElSpE02ZElKkFEmPEmXCHFOgGGO9 HV2tG1mmG2a9IlahHWa5IlyiI2q9KmKtJ2inNXa5QK7UkUmeAkyjA1q7Bl6+CVGlClSpDVGeDl21 ElqtFWS0HFegGVWYG2q4J1atAEmWAF21B1qrDWO6E2KzFFmjFGi8G2GqHnC4KlGiAFikDP///yH5 BAEAAH8ALAAAAABEADgAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRiSZKYzNWUGdmm2ZOTmY8cGBjSDmS p4g5Q1RnZ2tUPUZgYFy1XF5eMCw8UFB0Zn5IHKinHGN9e7QztTMzRs/Qz6Jg0TA8V2PEkEp5a27N 4M20tuTUXlk8WVm4a05VS9qMZH0qM1vgIChUapqbnv59zKixkoIFixReWLCqwiReojJ+2tSoAWLL Fj9+8owpY6oQBxNLPGzwUoUNLmgwssRxiEjNxC1iQOhQM6YhJA9VzqSIA4cLnCoeWBYiQ0VMkHsq /ChBxWEDj2dVjFCBI5RQHx8Wg8zwA08bFDgdYJRIQaejUCVzSGzxUcRNtnhK/+LAsAIDBtCqf4pM ARGkrx8TLOOksGKlgxUweJ8UCUFkRhA/Qsesy+UFSlUTT4LQKDKjDRmhZdjksZOHi5OqSJ68CQKC yJyuDpVomL0hjpOlkAIkaKBAAiEyLfC00NxHkoQICSY4KKBAwQAHDaJPuIAhQSPdAJozgGBAwYQI gsSEkBOCho85iyggR0BAOwMG0KM/4G4AAoQK+CEg8L0oe4MHBkwwgQEPMFBABkSQ8IYMWL1RSADr MUeAAxT+94B8BtQ3AQTRNZBhfdw9oEAB1ilCwQELRGdABRc6kMEPNODxAhA+zIABBAwsMAB8FdoH wYYGNOAABMwtsIAC8NnnnP8CDlwoIIENLFBiIhQgIAABEDzwgAMaSEHCFwwOUcMF8QH444YdNkDA AAogkEAEASQiAXv/BRiiAwqAt8icCwjAQAZptHDHCz4MMYYFWm4pJAPtKQDAmxRIkgAB8znAAJJu RnpdBB6c8AMeI/hARAkWDMCmA27CydKJJPJ3Sg5PfEkDDTuIoSleuC4RxYxAEKEDDrgG+4euvA7x q7C4JjFFDF8AYSywyFalLLPOHhutUNMC4ewU0F7r0BLLNjsEt96yBC61z5b7bbjVdqsuU0248IMP YZxww7vxxNuFs/biq028QwhBxAth4MrBMILY5BAaLgQ8RMN4eQDFJmf0cQX/wvHc4YIcQowgxA54 4UBFECrUMIMZGGsTxgp8uDCCC1HghcQaW3yzxRkpE3PECXys4AIQdSjsEBkoUGTyGULhwLPPP6QB m0NiuCHGPW6wIZQJaHThcxdC3CtUCzuA801VUWAhxA9CrOCgUGyoEHUNW7zF0hBYjID2D20kwVIO dsD0Rg1WlFEVDlKMoMcKI3ThA0tjtBFEDUepgRcHdQixsgs2TPGZNkz4sYMPIYRgh9xC8YGFDWFo 8cMKH9wAGCp7+ECCCiK04EfODjGxwwlhrG6DEFjcQYZZjTBxBBUqxCCCDz70gISwNkihxxArCCGE FlicUEcUcpBRRhJL5MDEufg5LFHGEXzsscYOO9C6QxFriBEtGXWYfUMYQ3Txw+onnDDFFFFAQx0G WIcntOFzMiACDUhQhBZMgSbeKkMd0rCCFaBNCAHrQheGwEEN9ooIHKSRD2IQgxBoTynqYsIN2jAF 1e3PejGAobaAQEItAIEGIxgBENpQBy48z18cwMENVNCGO9xBD9ProAa/8IUhvOEOdZhDHm7gLn8N ggllIMMNRtC/Kejgi/8bAQ28JzQrmvGMaEwjIgIBADs= ------=_NextPart_000_00A8_01BFED2D.94B40440 Content-Type: image/gif; name="transparent.gif" Content-Transfer-Encoding: base64 Content-ID: <00a501bfed1c$d1220c80$fe00a0be@cultureta> R0lGODlhAQABAPAAAAAAAP///yH5BAEAAAEALAAAAAABAAEAAAICTAEAOw== ------=_NextPart_000_00A8_01BFED2D.94B40440 Content-Type: image/jpeg; name="ppPepaMini.jpg" Content-Transfer-Encoding: base64 Content-ID: <00a601bfed1c$d1220c80$fe00a0be@cultureta> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAHpQAAC0UAABIYAAAb7P/bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAM DAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/8IAEQgAcQCWAwERAAIR AQMRAf/EANAAAAIDAQEBAAAAAAAAAAAAAAQFAgMGAQAHAQADAQEAAAAAAAAAAAAAAAAAAQIDBBAA AQMDAgUEAQQDAAAAAAAAAQACAxESBBAFIDAyExQhMUEiNFAjMxVAQgYRAAEDAgMGAwUHAgcAAAAA AAEAEQIhAzFBEhBRYSIyE3GBkSChQlIEMLHB4fGSM/By0WKCsiMUJBIAAgMAAAAAAAAAAAAAAAAA ECEAQIATAQACAgEDBAICAwEAAAAAAAEAESExQRBRYSBxgaGRscHRMPDh8f/aAAwDAQACEQMRAAAB wisl57io0doidcXxb3UwdsmMmcaWFu4pboFK9FC65DaEihhwjN7w6CbzBphzWJ0tl0rOaZJW1zUB WDiB6pjOv0jPI8S7HSDEmsFZ2Hc1jGSNmitZ+Z7ZVMtCtUUVST4H+Wn1Uh04xGW1GkD5mitB53XD oNCHGf6M/n2kaRbPVc1Y6fgRViI8/r0kIYUlFu+ImnLO1G+dMXeJHpOS1W8npPYPN1pwFQGfrn32 mcOd15bNrz5tz9QKgCOi9zRLxGs1VewW1jXldY4IpBO8D6z0CqrHQLG7Ojk6Hm3U1YIcfza0yrRm UkrK9avZvPuA3maPRooUdx27leZ6ee1hwa+DqMnRk9JdGuqNETRCprNZdz5xohrXhqpYOVTDEbZ3 BxN7FhmqukkvnYF7hdFIyFMxKJptpmI4yyn6DKvbCzaIUhzNeKwhp7hXpzdT3q6ojvUnXmnmzqhG RnZvSzT+svSVy6zWpUINU0rvIO8RSdculmrvcFUhZZFZ4tISbbR0OCDawFneSY4BNL3IFZCVFYji 9TOxDLHVZnN54hTwtzn0NE6K5656KxDVHDO0QTAHI7mwbxbHAWC1yzaxSiwbiOhrNDVkAXWSQZsp nzIjU7UlnIotxGhbdDUhRFm3nYNxO7OaoIU0eIcznMcgrbh0Xmcsm62fc2jS7z2mfKlcRBArTBaH K6iP/9oACAEBAAEFApmMaJZoJZtv3La/Mzty25zYd228Nznsn3eMfXGfFFur91z8sZm6SkY25SQn +9T9yvdHlxl0UGDO1+3sp4DqSYTmrxH1x8GHyBjbcsrCw3RYWFjdnxNtTcOFkzWOa3KfZMZ8d8Dm AaU9PnvSSHGfLHLgMfkxPwXWuDY1fBWNgMr55DmRlzo8lmQ14dPSPuln1ZFPkOnmAqvZdtyiZVOY Wlqwjc7Zg4Ysv8eRk+U52P8AvOwXqPFxWtmgeWskyUMhzzbMxu9yN8KJtTBhBwhxWNDomrx46ugY RkYVFjylj8GdzIJ82W91gN7r5cPJllxsfJjBuX9dnhQ4WWHM2/KD9/7ccOI2skA9Ph2hRWbGGv2K s+Lugtkiy5sjIlA74lXdKkNTJjlz2NdG2CIsduz7n7ZDfJfHGhkwElwVUSESFuXo3Z8x8cUrHPe6 ZrG+RKF3MYEvgChnJeCviTp3Khm2YfTIYbpYG+VBe1xaQ2eeW9rZ3qPFky34z8WN00rXNdfYIg6E S7gr8+uI/IOWCFJlY8Yyt4CnldItlf6zR3tlZMJMeGQqToka9romvUFIIf8Any0NmxIZR4svc7BB 9gE/+NgFnZhjWY1tn+u1uplNej7x0umBIZ1530E84i2zbsjsuZJciao90v8A6xhXgRtDYWMTlM/6 vdcz2WO+zIBUrvrG2qnp28dgfkbsL8vfpPWLpwcntDGlkeHd3yzJTRxT3KZyJ0K2/Jvj7lHQS/Se Rhi251cl1Jd13OW+eP2YseUsL5h5QejInSp8ie5OR0xH0dDICYgazNNuK/tugd28LKdXIiPrGUz2 MpOZ3EZU6QqNskpdiPT4ntTxozqJNI5nl80ru3FKa7gbGONXR9caj6T+Tci9Rw11eRbkQjt09Wxk EQvKGNPQuc1YMYfk5sply/mPrHuw+jj+6UzrCCPs7pyvxIv5flnXIsvrwfyHLA65vyWJiPX/AP/a AAgBAgABBQLUIqRR+2lFRU09Vcrlcr1enyGl70yR1ZJHVveg8lN5lVROCARFNLU3kFNVNLRr66VR cm8ddGouXzVURVFYrUWpnICajx1RTeQNKInS9XqvA3kkqqdpY1WNVBrRDl2q3/Eqq/qI/QCNaqvP dqEUNTw//9oACAEDAAEFAtAEdGJyK9lVV19OCiogFREIBUCATubVBHWqPJdrXjOlOEjQqmlNAqq9 XK5EocbkeUU3jdqNLVaqcBTeE8I5LdKaBFUR1qruCiojo3jPFRU1Og4SvgoK3UcgHgOo0I5Q4Haj X51rzBr88RHBThHKdwBHVvD/AP/aAAgBAgIGPwKmg4g8C//aAAgBAwIGPwLDv//aAAgBAQEGPwIa bkbjj4Xp4uArGMLduMROTOaY0ULnd7YiJPrDYmgUSPqovByIA9VMChq+rtUGGoblfuW5xuW9EQJR LjZG9dDxtQuXPRaoy7dsVPbO7xb3oxH1Jk7jSGZj5IYeLA+SP/nsy8mXJAR4fqgLsTHiE9q4TvC5 SVUoVx2T7pe1HpempdMEe1phcFQ2fBCV/rl8MizLCHr+aPZnyXAzYsXWmRcjNmVwnA2px/cUIc0Z ZnIqkn2uKJ5VO9Axod29a2arIlAyDgrpQi5izsx+91dsFzCPLZoNz1KBkTUSqOBWsdJYAZ0CxWoi h5dS1npbUSpTOBNBw2MAsE22MWFM80f7ipPQMhG2NOktHzUbfcqcVGHfiLozmTV92aI7spHe9QhG 3MxEXcnErWLf8dCfvUbQYk9IzUhK3pEs1LRHtiWmIjtw2O1VULVD0XEJgwGp3PhuUrfKY8d3hgrA A06YtqNHKy7nzZIGDwp1xxCHeBlMiWqRzrRNJg9AGzUj/wBiP+KeH1EOXNdw3o3IDr4q1btgASOo gcP1Q9vUM1A6dRDgk8FLSRqoCKvRWzd040iMsq+isUzl/tVFghRuKejeKMYAVqS6mSwfcyiPlgAn yiuYsmEh7MCoxFRGb6W/HyUrt06ImojifyX/ABMH9V1l5ZvXyT6rvrJcs7p85q2ObmJdySMOO0on eBirniFQB5ZldiJr83FadRB+U4Kq0wxUi5JjirNnVy1kScojFXbX0kP4hzXMSZbgu4QJE0Vty/Dd 5o3NVYHp934r4v2rGQ8vyVvuvpqzjhsrME7onUfciIxxTyLlXI+B2anGr5mqtUvLY8cUREadXUVf +o+G3b0jz/RXNXVIqorvCYCMh/mf8FUQeVAHlVts/wC0sovuFFyxZURTbwm2B1TBMrMd1oH91VEk fyAy0n0CD4ZlRlCTx2R5hymlF1SXVL1VPU7SEVCWT12cUJZbBmF2hjLRbHmPzWgdIaIHAbNORUtd K8tXUGI7TVCbP7ARl1RTAOq/0ykSVHOLt60WoF42BK5I+AaK9/rt4K2HqYmnr9iztuTYTU48X9Vi nGIwX1F6WN6WgeCmm2jcBp93sUoN66guYbYpwajBCRxXki+a+l+n3DVIInf7A2vLyG0pxQjLYHWC qEYlQEsHc+AV24fhpsG2OwePsei/1fgo+wPBeRV/zRRQ2RX/2gAIAQEDAT8h5OyAfYMiOfegDKgc 58ywLRdVqoee8pCim89gvELwULwMKj7hpUbL1cp+cwqGubOK83BgElwHKrtcbtUyGob0zdCmEAMH KZXusqNS3GtSfg/uJQ46Cp8WX7hw7nL9J/cuhjbVn0SytPF1EG1vYJhFvZGr/UonKdhbz45i5rKF bfDkeZi+5rFPBVmZ/wC1imgBQmErd4fMNaEohXG4NYFa+Ax5lAx3clfDRpPnowA/9lcjLLwyJlF/ je2oqeu+xFrxut3oH+YBxgFlVdkLnYIur/3BO5eplUZKU8BadpkpvZWQD6YtuLyu1VoHtD3ValDe k3HffvBY2bsFcal3mjYAYN69oh/4VewlyuIOVm+Y23cnB0zNCKnGIuNruPY7edyoAp/UTkMi2d08 jxTL+IgJZLIdlx+I0oVdqWaQaER7WrCndBh+SAGlXgHshvEAGGULZg9nEtgK6Q79fceNHboziehx zz71Ap7sEtUTR990j+OkFaFmq+8Hqwg/jczAdj6EaGWEvYSt1EGfs5joGVhXZ87nLOynXw71N+0L wU/TAcgs7ktzdVGcImlUtgRYGC2tVkVnNSmi1MStYaTNDPL+C0A+/KxXURF5OeXmCuMEBxLqFbOI 2pluH8P8pZliuqqB9yo62MGGqxqYihfim9l5i6U9qB4XUulUuF2x25iUrp2F1eOeahM1ip3i8V4m XOWH7K37sdSrw3dyw37X7lTCfLL004szmtzLGWeaLM8S56tg4tX4TE91Thzb9MQjSw2/uzWtwCVK zlxdQyDnk2thzfNSkpQivFinljtAmeEwa6aYwl7FKdV/EOzn+CVlpq4win+hfCHHw1sXtCrgxFv4 RNNR3T+JfzZJZL/ogJ8zpDm/mULAIWwz++8Iqxmq/A7pjFFdct4U/L8RCfp/xEhUEFJdiF28Esb+ ZrvrCJ9pnbtWaz78/EDOIXM95/ogUunmUalKsWnvE94ZTu4msMVlt7hkFY5XHNS0MJTyxl5WEF81 /wBYzxewbhhAilgY/K5jxYXSss54Jmnvzn/yHF5+oDmsTTdeJyZsXtqKlIrff4zGnnzK/NKfg5+M xPZCUvlqIArO2CXEuUWbqy8RX+fE1Zy74hgBTCzWl73DBi8bavmoOpe+K/uALl4bkScEpHOZzvyR z3tQBjn3GYdBd3xHR2K+Yb7QNvDhl04HkfGZZflVHmMjgrPwQhTgfJEva+XgfUHXeeKb/knL5qMl OZzzEIAbU0TvgO9dPj2gYIXlywIFSwZWJFG/PRdrFV9zhisoVdwjgDX0lqABD3g4dgfz/tFpVArP /SjjfZXy/oj28zPw94V79kPX3B/p4hkOB3nnl8dx0xnJjlLu9jueJmemw9spfBQc1PFk/tf1EU4y 8039y7dkPwT2p6eqPdGG77l37ssRu/TfLA5gU1+Kn1o8fmVxg8WYE12tG5ugFL3lInI/aStbVz7R mMfMP9uJ38v5ZiPeCv7nP3hB+5v4Y9I/a/L8woaMY0SzDcJaXjUKtCvvO5G1Da4I5DW52774gsEr WYxu1STRZ+yP6j/YuPg/uVCr34rw1z0QX+/66m0PeaPR/Z+01e79J9qGnvP3/wAk16P/AKfifu/e fS6XWNJ+9+p//9oACAECAwE/IfTKKCUsrHpgxi3pOh5M92F5CYjTogYZIsQ6X6XMIkMSkrOx0AEx M4Mf4DNIxQuZg1Oeiy2wUSa9L6XLlwhLhxEIvQ2l4tjNGUEFH+EqmbKzHcpmY+Zc0iuDEetSpUro YRXqDKSkq9L6LHqJUJR1TU8E8EQ11IFR9DB6HRI90p6jo+l9F562lpfU9IRh1ZcJz6j/ABMYPpro eq/QY+ipXS/8BHq9OOt+inrTov8Aym+p9cGvR//aAAgBAwMBPyG4Eo6FOnacIpA4d0qY6E9PllId Q6z0Bm0YI7ieglURxB6Uwhd4u0u5TMIutSoEroM2hMhL9LhUe3QOkhFSpUrojN4CBjouIlepvLPQ PQOknENTExCGonUOlwely+gLlTKV1yvoEHUhFLieiuZb3Jb3J8+hildQg9BfRb0EBh6bdEiQeh0B 1qVCD0iz1WEUOpYeg9DF64utZ6SL0ku6V1uLH0RgwYoR6T0ljF9Hodbjn0DquLF9UHpPUdHcY+g3 08+kOp3Do7n/2gAMAwEAAhEDEQAAEA6YzcarcLZyOpC5ltFinp/kYUe9sJ7gEPfebKUSCNQ8Vqlr GUV+Vn4AwWmYjMlr0oM4Vm8cAVlp3m87EWEfgHE72tV1qpcxv9mRbOAY08+73EMkHAgxbz9qNlAX zDmYTHSVvf4HgXY1Sill/9oACAEBAwE/EFBBxA/8CLgeWCEGuIpgHy8QzdPVRaRtVrtEr6ixIAAt sszCqhVwg4ZHYZh4kZ4qINDdhBEoptj47S27t5H2shUcfYWdWYZUrY4IRnAkOxsLexXzFstUAwBB Q1jFnDKFwAYO2xSE2tpR5pRe8OA1Ylh5yA9od/8Af0l/4gUC6Ul+UJXZRS8Y8rCVsvbXzNsK93bt DYqkm4l0Pi5gGGDC2/3HzBa1QtlbwoTNy0By7guQpYyr3i5TDCiEd5cYHs+yBHbkAEKGSVzEy3Ap kzZYqYTqEGNtSgxTTzELAPAC/uDytI0OH1mOVfaX3lTEXA8812mTkATSUKCqAAoDETKricg0/EF7 aBRsLgEFs+C4DhALtTj8xpv6ZiZUsjqjCruxeJsPAihIRHkWzEuPgVvhwzki0FI8RbQVtLXtByuM Kq+53gFXc3hxQ3CtUuksZpTYCfkXHsLLNE6H7j2BpyEQpPkLiUzOcjDyJyl94qGHTjD5uJZb2NQV uFciQiqB/epVpMeviFEEkuKqs5Y1WWqm7RYYoinJaCzWccl5Fxxv6D9jgYOQqFQfFTGD8jmB8wVV BpgKKvEWKr6cJS3axergchw2GCFCjYGLPUuNEAoHGsLeYFyfRFTnQxYuy+6WiuwRYpNzGHBoP8TY H2oqGBJ4R4QfBCC4oX2IvC6RxY7D7ku+oHVRBFz7V5l5BsCmAG+aWxXeLWru5SxW3zC42hbOBCm2 sqH5gu0VxQ2VgTRe+I7imBpyaWQCXALWnQVJN0O6ItFd5SMiNccx2+jIWBQDzBvcFDO8AyKo7FnF 1crLqIQImqFgi0A2nLcpNgYIWz8tYghT/EQ2r3gcqzAXMrxBDvv2obhPDQgqxfgfU2p9+WHdGx54 mVRCXMou4F4Iq1VlpYW5qGwK2MOPzEri96P+wvosKDhws1ELAmHULIwFQSepWt2CAtY3eYaBXYbr lgV7jGcs4xAHZm85iaVNNO21H1KR1QAFrsRCtrV1+5ezElQ6rzMGx4QWIHEQG0kPguM4N+QEoAXg xfexFkbXXRotpLlQjl28mbe8ArfCZlPJ5HeGQgbKT4cwZYLoh7nBNpTDltpVsj8oQz3sYXVK+7GN PgsVhhq7tkCx3DwbB+E/zMIasRVyWMr4ahwhso3V8/OoVVSFauM3UDu0yR4q7VG38yzjqKEN0quv EGeVGAVeXIeTKZzIWOKBVWz6Q3RJYB4arG/LiFdPIVQBsKK7kF4dPYBsMbtQLYD2VkSA02F+oeyF +ws7IMiA7kA8q0EXthBoN0L7NQiJAHoDVoEGP7SlQGjNGQYQxlAeKY3DAAWImdmpX2KPGrvxzHA3 aOvKVxFAhZj6h52rcybjt4yGtwrRcZj3nLqHlAQg3l0CtW5YBFlm/cu2sPzAHEzLg7zwmogXV2ZG 63YlcxdyrdwmuLikJBXb+bG0trMGlsb3Bicu9LFo86imxAVqPBTgldTLSgg23eh4ID7Xu5oP1Kuj Ssy7USwuau6p9469WsUQzV1NZ2BU5Pi4IzkFBe4NBCYgsCRmlMsJnF5B5JdhuYLu7S8w7jxFQmzD bHLcEdEzZsSOz6wn4w2nvDkKnS/uDLrxZb9zMh7x+JdfEDm7lVOSMkpbOWeIHdQLcW3K1BOxkPwz ARqjcoRZGA3f/CI+VV7q0fxAB2bvHAnxHmqpGMlgfMLOIbOP2IhMaZdDDXzDdQbWXiI1Lgqo0UNZ lSeAGXGU1kgBAVwl69m2+6WmVhjYe9MBbbcrD+3aAydSgD3qNYbYIV7l8yqvvCUm1XDj3AwxpvwO Ba5h2+AYLS7GO0sNbKWr7fhj3fE1MAk5aLRO9wlQdl8q4S7l4J4cR8BDSGwL9EeCZOE5UrO95I/w uJlxl9pV5teZS37wdm0BP0mZT3ipzEbNZ/cot/mU9it819o+UcxwLn2doJ4C3xh1/McJoDg2EVs1 fNiKvjF8F24St78p/EqJwT4oKmLyLrskyV2jFOab/UXVvKhz7zNtRJuUUIy8xgYfcHx3m83UVl2v MVbwyDlewmd2xT/ECKLjf4jNTav5uKICwQY7tCNgAVaRB4rFvX8ioBls9gvivmZHDm7sWnveK3K6 /JMTWFX8ksU4r6TILYwdjiUC3vuCmi9zYXmU146QS38COsAAGHmKDWbMcdvMwAOxYrgK94f19XWX Bc+XJGrlqBzMedjlZiBia7B6d42UKVr5uF2mQ/kqcJQ/9a8JhsFfQMfuyl6xapPaVmURs2+ZjhoJ 8C/tNWfXdM/Rn8P7n+949Nv3c+s/c2eyX80/3vL0pr/ozn+95n2f4n1X+J+mfY/ZP//aAAgBAgMB PxDMsuKVHVjWee0A6lASz5R7hZtohImEE2xjVMo2UwUaEB2lO0xx3vE8v0hANvtjzLscecZj5/wQ bsPyVLr1WYquVWoKVLlxhBmC8kxMRm9JRYlXTEBaSALqVSIz498yuhK6XLjLlSoWB0icwDpjMMqB hDjcuYvE7HU1TMs5Kiu1V0YtioqDnclSp9mMIQaVVVK14g+MPZGA4uBxUoa+5atR6VjNsY1K6qEU e8Fna5pqDCEKmwXF6QuFKZY4zKoUCJ6gaYnemuItLPOTzzity44SxlmEYSjowdTsJgXUqnmAvMkA MGYVGpUtgijouX6Ms74y2WLwhV4lSowYty/UMqoJEamkdHR3LPhEjuulfFO4sM9SQjMkOIeI7j0Y Md3EJrrUCDqzmA8TNQnmVnqVMrNx6kB0HRiQajOVxh0CVU4idBDRAwRh6AlYjp6COuhlxUCNOoZ9 BGaGIIQRYxjKgY6Gox9M0m82mnTkmnoDU//aAAgBAwMBPxCEBibTJE495iVqvuZXDBukx3MsXUFa ineD5wt3IhniXOYW5nug2vU8cRhuA7k8UIucVAGHaC06AE0wQj0DxLUPPEzVAub10qqhXBi8IilT JBabmS2XbA6Ly7EUQal7KbRl4jY7zywqpSV7pgKywxK3CGxm1XcMOBgYGJZzkoYBhR5jWvvEXEhN 65WNbg5Yx3hol+4cwIEEvoyhuFaRrEWomUeUuLgW0RIjvEa8Sg0RZmS5cD0LhDGsuShAQm4oipeu JA6VMwMTEthTMUUg1jNReCNrTDmYBHpBC9jHotR3MSdAZ4gdEoypDvDujUKlkQqASoqwkOtSsR6d LqiEySrh2+YsTBEhAZlYLDIHTIjiVBhHXReZUXHUaVBZLjG4Kaly3MCoS4pUR6WeUWUsJBCouO0u YsdBDz1V0egdx6KnoIM8MaHFzaLMUWdkuLKYkvLuCM3I3LzBjDDgCXmbR9EK+o5mUES5SymXcxJU GXx02ilzT6BnM0Tb4hBvprN5tOH09on/2Q== ------=_NextPart_000_00A8_01BFED2D.94B40440 Content-Type: image/jpeg; name="20000713_jacara2.jpg" Content-Transfer-Encoding: base64 Content-ID: <00a701bfed1c$d1220c80$fe00a0be@cultureta> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAR4AAAIMgAAFij/2wCEABALCwsMCxAMDBAXDw0PFxsUEBAUGx8XFxcXFx8eFxoaGhoX Hh4jJSclIx4vLzMzLy9AQEBAQEBAQEBAQEBAQEABEQ8PERMRFRISFRQRFBEUGhQWFhQaJhoaHBoa JjAjHh4eHiMwKy4nJycuKzU1MDA1NUBAP0BAQEBAQEBAQEBAQP/CABEIAHIAlgMBIgACEQEDEQH/ xADNAAACAwEBAQAAAAAAAAAAAAAEBQADBgIBBwEAAwEBAQAAAAAAAAAAAAAAAQIDAAQFEAACAgIC AQMCBQIHAAAAAAACAwEEAAUREgYhExQxNBAgIjMVMiNBQjVFFgcXEQACAQMDAgQDBAcGBQUAAAAB AgMAERIhMQRBIlFhMhNxgUKRoSMUscFSYnI0BRDR4YIzNSDwkkNEorLCJBUSAAEDAgMFBQgDAQAA AAAAAAEAEQIhMRBBElFxgZEyYcEiQgMg8KHRUnKCQ7HxE2P/2gAMAwEAAhEDEQAAANz5Iy1gVppW 16gYfbUzPUbahXyv2f5WwZWv9XdVRjrPk+2DaieetD2VQHyc9EZHL6dNLoru6tD1U1WupXNJs38r PEZEonNtJjtQ6jvqRqmieazuAy1MtM11ipprBXA0hzhzh8L2StnOhVBi7nunB0ajq5aXp+eK6deg cQ69RGc6OLA8rCJm2rpQ7WV0s2x9aq9M6rKFRvCqqktADA68/wBEwr1MlFGvCf2m5klOX5Rc7xc+ jRpxGq3OA8syi386BxRVUTlsYCVyszU1WMtffchZqfhybQ1kGloWfLtrkQlOszehTrBq6I0TXKp2 ejK+ld6ZHIZE2g/Xd580lr+a+hJTt1AkkFasJ9nXdHn/AC1zs0WfOCviCAmwtLs/xh6nLts+9Tzc QkXllepWKOdDNhg9NeOhmdhpuOZOeU8k2nMm3SSRsr0cgZAFIw45kWhKyQ7x9JaBck5u7//aAAgB AgABBQDCZEF7oznvDzLI4JkTgxPQIn8OYznI9SZEc8DGFEQXEQUn+kS5hpwMcRnaPwKJnOYiCL9U MnuBDId8ZBTHtZMcYuJzkYzoWcTEkuZyILnnsfADOcds6yOdfQJ9WfRZRJM4kY4kgrevWMGOIZ9Z LjE4ZeigPu2S9tcfqebILoeCzjJISnkMCBjCiImtEnDeJNIxOcTz1b+QcP618n+tX1/wz//aAAgB AwABBQDATJBCCjPYngVTyKCjPSDsEJznE5ORPAhM5HMwM+nM8QMyRx1lS5MuZyRmcieMiOM4mZge YhcdWjIsgOZTADnvYr1lkxn65nsPMYDfSeJgAkRMm9eMGRGV9TmbPMmMzgTzjQ9FKkSMukE6SjqW fWURHtKT7k2IgZWvmbBh1RAwbyghTwQdh5mMA5ERIxk2EWQRcWZgJXJQLCkYWUjPr+Ufra/r/wAr sj9zP//aAAgBAQABBQDtOdpx9gUJp7R1p3acs+QFXv8AM5zOczlbeqsXdhb+HTtXbh6+t5I2iDfJ dqJaTfuU2rbTaTE/l8kuRXpVX3wn+R2+VWkG6uXLE2kvvqPXXxTVfds/y1x2yvxZQwpUEDYOVNWz 59d/jx1qhx+APE2/h5n/AHwS1dcE7JwBbji07c2SaO/szlO5ctjcl1a/pbTLO03xOqbN+2ESbtbB zNt3eht4kvH7zLlOy9dc1F0rdYTM5s4G1ubNOrMTXrk/YoBtmKKikaSggqMC7d0Zsn45qKiblqiq xe29A6FrQ68bjdnXSFTVajZbNnj3j0alezeq43qv+H2MB7knEiu98u/ZUNRPRrE2gtlXs2CYK3uh lBZuGyRtbrhYoLLkMu7uo+za0t2zVdsrbbxePbE9Qmz5O5Iraw5gT/4/s2BfnY760utoWrVG8qOY XzCFYs2DhKtKXprGsqNUvlKdAnLAdnAyRtahGx1ZQidHU12itFxY2NkhtaeGWy9lfsHaA7ASN63d pIRY8gs7OtryYtK6eweltGBZQgi4qVVNHuQlDbMALpbrlgRNdds09oZJva6ZWw7xqLPFdHNfIMeL rUKvJaycfBum1vL1iRp3bAP0yP4lmzfSiltJuOuU6ShIFe3puLhaP3iY4+WbWYSek2Hv6Rq5maep rLzVhMJ6FxdJbLVSypSYup60NbDDc2RXSdYVNvpejU04TWiufzkOSC9XTq0X6rVU419utoem6r1d keqhlF14wmKoGTkJGoY7syK74iMTOzcQxdGcci78Kx/ahX8Ys667OxuJpOqLp2Sdv07Kmd0Vg5l0 mpm0spJBpCLaBtVJ12tTpSo7E7g6RxCMVC0XlmyChqOklilMEj92tWbYkntFI2tY5YEqHHnQF7wK nXd69LWXDQ2/td1VOi65TiymO7atm77Wgqn8hULAwCQPUf8AY0nLKrFLYLO77ZR7Y9pesVWbyU/I LoQlFUmbS1Ee4nexUPX7OU5sbU2rjTIhVSt1n+RrsV1+M24brgYPKawje88Q+wLAkMTzJlb5TdvV hr1NnYrZR3QeynyGpfN4JKNtsHxfpMOro1T2IjP5mzvtqht9khNbbbNe1qeNvgWrp2XjOojHKW3H eOaV2T4tqYzc+KsCKfhN+yn/AM+sxDNOvWpVraPw79Nakp1donXWQOvqv7vdE/L3vX4+wr1n6bgg VrOfdm3tbVZWvVCS+v5Jwc2v7+m/1XafZXvtaP3LPudz9P8Aa4/Z1v3VP7SPtv/aAAgBAgIGPwBM gxaueAIO8YBEEvs9iT/V8kKM7p24Mg1pI0AotWSdVzsr+TAlnDpyefdgDs2IzKET7lM2mhYqJJdX /XoW9bWTGqJuCVd0SA7VZeKPVRaGr0oRcahliwpqwYZJhkiDIxll3rVGUyYEXydCRJB1CNNqBdXz a+AfAqQRkBaNFU1BFs5IRO3VxWnUWyC6ZW1WTEKoTGq8Oac7FIks8lGHli/NOOqL3QMQCTYnJdX9 +yUN5XNfkh9xX5r/2gAIAQMCBj8AWqlTmUSQJUyKd+CkCMqGyrp5qwWqMdFK78PjhFvp+aPBMDxR LWuFd6rTmmVLC6f/AKN3YAOxYB+xW5d6pnsTUcohk4yyTnxVAIU2Glrq37v9FtzWwFOxHemN1sQj LgfmnjLpYo+oMiCBvUpE9QruwcG6M5DWPTDsgREgfdT+EJyDGXu6rmgYj3NkI+pGDTBoKuyMRFwz 7uxEAMCrZ7MPVPYyEbX5KIGUG5IP9S0iXmCAIfUDfywbvRnG1QUC1Qri7/DAxB6rhPE6UNVSFpG1 RAAoEfU8xblZGJHgldu3NGPFW9mO9fiuS/FR+0Yf/9oACAEBAQY/AN63p5pCcEFzYEn7BXHXECOZ JXJBa4EbYDQ+Nb1+WaGQIpIbQlnB9LR26aH5Ct63Nb0sCh1R17clYMGBHq8BrUvIOpQdo8WOgqOR pHEs8rGSTLH0jsVRvsenWoIgnumS7a3u9xZddzr/AHVJ9ClAUVl63ORRvhten/NOXgwZ2kYm627r m/jtSTwtkkiq6+OLC4/4vbEqwvIdHY2xCn+/Skk48yN7UPtx2UkAMbkjt17hSg2FvUQmp06XFLzO bOSWTSMYkhsStsdO3XSml4hZUIxuT1ta4U6Uz3ax0IzyvcefnWPJLmXI5fVvtUk3FkFipCxtiW1A GRHQaUkEkostiy2Auw+o6UkkrIAi2BcGygC3aLWA0o8meX32VbQEekAjtPxr2pblPpYepSfqFP8A 01X95JyMW07l/i+nzqHj+5Y+37TAHtL+q/nrcD+2SMbxWDHzbX+2aMC7RCKJd7XlObaD4CpIzNIr RkoqqzKCR+ig7cmYxroQXOQPiLDWuE3vSEHjvyCzN33Pp18aAfkSRoPSIyoN7aZHqPHSsW5Mqgeo qFNj9lBBzJY3ILJcqbkbrqNd9Kt75RookDT7OfcJc5HrUccnKkkyDH22PYcR4DShBK8jwSlpWjZy UVd1xG3lVwMr1Ze34UGdtR02oK5selEysHZHKg37iLA60jyMEDAqCTYX9Qqfll7rKyuD0CrZcv10 FyJzYkX6X1/sn47HtPL4wPwWLI1LIy3eWRWt+yuV/ssKkeVGhZAbxgD21UjQNb0t16gV7bCwh4C2 K+LOg3prBktdwTfFUb07+NqLMVgjaxMbHvdeuliBptemjjlOgDRMm46G217GuQ2RDmWNNuiRXP3m onds5WRyqg6BR25HzqWDlyNjLMVikU3ABOia7EVLx75rGxAfa9OzHIKpuo9QpZkDKxfCzeQ8wPnW PCgaSxsX2Rfix0oTcmT3eXiQSCcEU2JA8dt6MzjOKJSkMZ2Jbdz5npWN+z8vbf8AcrjyMw/CYtgb d2mO58L0G2uAdfOv6py4thIxQ+VvYBt1JB0pOU7+2XfsVQC+IFrrvqTotT8pSY5IAcYozfAN0k/a yvqT8qbnP+HKzCGXjMVATjqwC+e9XZlLSt2qNSdcbnwFJLJaWWRybNrcWCqCD5mg2WODXht0W/eo J8L7dRTpGuTHkyAg7HBFFz5CvzD9nuDtU+rHfuP6qV1Qe2GX3CwPcUYEY2+pelTTIFZJCSpHxuA3 mak48bCOR2UoSLj3ENsf8wNvspI+QiApcCKEWALG7bX+2l4YgjDSG7Nc5m+1/G1PE8aMzLcMLhRk bY7m51pcdXbVV6DzNEX1xuG8s9/hSLI0Zm47MRGT2MG0F/A6VKCntAoI1S4LKSAt7r91ciMk/isq IvUlTmf0V/8Aohl/J8aPKxuFUN2gDzta1SLCwiTkBc40GOQHd3fCvy0c0skssmaQk5An/Glg/qKo J4gCW42JxJF7PqNR8Kb6ygIRhqDfK1QKCws4LsRYHXYCi7C6GbkM/wDDmq3+GlD2xcEEgj4dfhUk eJEbiyN1B3D/ABvUa5gs13Zz5XbL9FR8qV8uXMGk9pVsogF/UbasaWXC8yhXkB9T5CzBvt+VRBTi qMSth6U1I+O1KYXV+OyXxXQK53NLxkexlIEgA1sP3q/L2/Cxwt+7a1SGNwD7jX11spPTrUXH5X4g YNIxHXEADbzox8RMSPSw9V2/vrj/ANNlOcUndM372QIW/W1qJU5NGcEDeC9ftvSmD8Nwe+du4heo 2sPlR5ckpDSlnAscsczdgTpeu0hmIuHxufLS3nUbCcFnU5BbqwbotgaIzNowVuCwN23ByP21Phmv tg5uP2SKjjhuZwwultSTYaHw0rj8drjNZle/i3pXW+nbauM3JXOFUUop1vE+p162uaPtteOeI4Ns O4aGvdkFgr+3J0JtkAB12FNHCvaraMdyBS87lPeSwaNFOgy+okb6UTfQb1ySzEHNmJABsWa4vQ5E Zxe2IdAD2k3I7vGsi7PbXMLg2nnoa/KzYuqMVDkdxXzPWmmQXRdSpIuR5A1x+ZxpWykxWRPVkzXv bQWxttScNow8cSgBSzDQnYihCkGDHXMOFCgdToKjYkQswLtgVB3BI9R+NPIJFKL3WBBKr+mp4opZ EWNQEeMqGLPftbPdRapXYXSK4BOrAjS3nRlkAGZXIA/tE/Zoa4bS3kRFYhSQTYGxxyGgvtSMoKBA 6AlsiSCdb1FBYD3Xvnsciba+NGPATMdy1r0eKhKNFYRm+6X/APjesctTsanzRUfNlJU6MAx3BvrX tk2I+IUjxuRRuwNx0p+RODizMI1+d7nypYIo1CrqQpAF/MGmM0ShxqjZDqb6Yg003ttHMNLtax8i aGcLSvySM12BW5VEv5nel4HLezRRB2bLIiwv7YuOgPjXMVSdsENt7GxqSSSR40VfxMbnNQMyv+NS SNKUPIvKYwwtEra2+yjOpUGIpdbmz4W3Vt6Zo0sqd0UgONwQMkC/EVJ/TpPROgkT91+o+yorkCVX XDUC7XplUAyEKyqPVjavd5EscDLqC7DY+ZNNJ3WVb5XX27XAvfK3WuTyvzFioklC46aXa1AOpK9B fSgGVgL62saSWKU5kgLGosLHw60iJD7vEYAyIGJ/E65SEZHbShPzOMfZ48qe9EuuynS/gTTchLJ7 kl1jQBFs50UAaUknIKyQiQyqqtYxyWsBj1v0pZZn7TIyzubWt3aD5aVzoZ40WJrxcBFUL2Z9zX6t 11qWNtS7BdOlxjUcQkJSRrY2F8RvrTAscSBcg0rSn8O6lU6m+gIrkTN/rCTGGxtYmyio+ZHH+LjG xkYliGzXLc+NSmJXODMolJI0B/aNGblzElfpUlm/6mpuOXb2Uj7e43wJVrZfGphvLybwRi9vUO4/ IVqLFenkaRl0LHQ1FLGQp+hfLrpRETmL3VJmhQYqoBvbXfK5qeOcyL7/AOJJqLWYggqBfXWhKsXt IiuVW9jcIbG560J5QVKKGRQAcgV9Xmx2oRsuatMxItpfU7UvJdQOOii4I9Jyta3jRn9y64k+yLY3 P1H7bClihOka9xI7U1sTSwmQSmbboQote60XU4uqhRbwqPiQsUZ2BDjcFRe/3U/AkcnlpIwZbHpJ le+1QzbxSxq9xvlazA/MU8YUDIFQ25GmmtSLfvjT2gvmzKP01wlxvHaQ/wCa4oNISFTUKLE/AXFR uVA7h2j49tFSciq2UeHjTTDSNlwXTc3ubVLKO5QFUf5ANq9nbPt18zakSKPEQqFNzdsfpFRcuM/h NPa51Y2Xu+QOlEL1JS48iSfs1osvHyiYABySt7eFxU/KRQH5DDEtqABckW+JpZXsZA2II22AFMig iy6dLt6QPhrULTFMDcDEkm+DEbgUxZ1MMkmSKB3XPd3VHG5s0LMp/hY3X76+O9Tx5fhyAN5Yh0b7 dK41k/8ArpnnJcdrki17620qzdutgOnxpWX1Rt/6b3pppsVUduNyWuflQSE+7OwsZCLLGv7KD9dE qA19Nen2V7sqlJQ2mIve2u9GN2EMK2yLg3mZfMaAeV647wFLZ9trWAxPhtUiRSnENsDsdrVGjorx CIti4DAFrnY+ZpVGoJPTx20osv8A29gbDUg2Otq4xXFklUKxIYEfAsf0VHLG6yOrXCKwvqrC/wB9 K6KUaKzODsb6aUFb0liD8xp99IY1shOrE2Hy8aWT3B+YxKbWGpB23O1FJEEim9wwDD767+JGP4br /wC0ivw4mjt+y5/XepF4iSSxlTKLWJ9y4FjtftoPJaAkkEPodDvjVxy4wfDE17HJjMroNZRGzIbm 5AIHypY7atMgcg9d2UeFSHjIQ0b6KCSSp0NhSAxSDNh3MrAAdbm1ML9AtvLrSRpsb6AW0A8aZVsQ WF7i+w2tp4VxFRBGqkrgRi+l9SNtaRuPGkbsY7lVANjoakUY6C5x2IFhoflUqpuVDqP4TrSiDlmD jKuTBRZsge4X0NTcg8mUzmMESlu4dy7fZR2r6a+mvpr6aHo+ddPlTf7d6f8AyfV8/Oo/9v3/APG3 60/o6b7b9fKh/Leob7fOl/k/S3p3pP5P/W6evf8AT4VD/I+r/u+vbrQ/lPo9X+lv1qX/AG/1Db0d aT+R+r0b7H7qk/lt229Ow/5NH+W/0jt6fUu/lX//2Q== ------=_NextPart_000_00A8_01BFED2D.94B40440-- From rem-conf Thu Jul 13 19:48:27 2000 From rem-conf-request@es.net Thu Jul 13 19:48:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13CvQu-0005is-00; Thu, 13 Jul 2000 19:42:32 -0700 Received: from okigate.oki.co.jp (titanic.kansai.oki.co.jp) [202.226.91.194] by mail1.es.net with esmtp (Exim 1.81 #2) id 13CvQr-0005iD-00; Thu, 13 Jul 2000 19:42:29 -0700 Received: from kangaroo (dh304.kansai.oki.co.jp [10.173.3.204]) by titanic.kansai.oki.co.jp (8.9.3/8.9.3) with SMTP id LAA46804; Fri, 14 Jul 2000 11:42:25 +0900 (JST) (envelope-from fukunaga444@oki.co.jp) Message-ID: <00ad01bfed3d$879a7d60$cc03ad0a@kansai.oki.co.jp> From: "Shigeru Fukunaga" To: , "Stephan Wenger" References: <4.3.2.7.2.20000712173201.029ae140@mail.cs.tu-berlin.de> Subject: Re: low delay RTCP Date: Fri, 14 Jul 2000 11:45:09 +0900 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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Stephan and all, Thank you for your comments. > I'm currently working on something similar. In fact, there is only > one big difference: I (and a few people I consulted with) believe that > a hard restriction to unicast is likely not necessary. We are instead > thinking of a scheme that allows the use of feedback even in small > multicast groups, the size of which depends on factors such as > bitrate, network conditions as reported by receiver reports, and such. > Reason for this is the observation that especially RPS/Newpred is > very effective in small multicast groups, as it takes 1) much fewer bits > then true intra pictures, and 2) does not have negative implications > compared to intra macroblocks (blocking artifacts around Intra MBs > are avoided). As you indicated, FIR and NEWPRED can work on small multicast group. I agree with your investigation. On the other hand, the performances of these tools also strongly depend on the delay, because the delay leads the slow error recovery, In this case, the degraded pictures are displayed for long time, or the video is freezed. If possible, I would like to realize both small multicast and low delay. However it seems not possible because of the flood of backward messages. Therefore we have to select one from 2 items. You selected the small multcast and not low delay. While I selected the low delay on unicast. As our 2 types of selection have some reasons respectively, it seems not easy to marge 2 drafts. I think it is not so good these 2 types of rule are defined in one profile. I think there are following alternatives: 1. You or I will change one's mind and integrate to one profile. 2. 2 profiles will be defined for 2 ruls respectively. 3. We will find good reason (condition) to be compatible both small multicast and low delay. 4. 2 types of rule will be defined in one profile. I would like to get comments. Best Regards, Shigeru Fukunaga -- Shigeru Fukunaga (fukunaga444@oki.co.jp) Oki Electric Industry Co., LTD. Tel. +81 6 6949 5101; Fax. +81 6 6949 5108 From rem-conf Thu Jul 13 20:23:30 2000 From rem-conf-request@es.net Thu Jul 13 20:23:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Cw0c-0001hy-00; Thu, 13 Jul 2000 20:19:26 -0700 Received: from c017-h021.c017.sfo.cp.net (c017.sfo.cp.net) [209.228.12.235] by mail1.es.net with smtp (Exim 1.81 #2) id 13Cw0b-0001fw-00; Thu, 13 Jul 2000 20:19:25 -0700 Received: (cpmta 18644 invoked from network); 13 Jul 2000 20:18:25 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO dhcp-168-0-6.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 13 Jul 2000 20:18:25 -0700 X-Sent: 14 Jul 2000 03:18:25 GMT Date: Thu, 13 Jul 2000 20:54:43 -0700 (Pacific Daylight Time) From: Stephen Casner To: Barry Haskell cc: rem-conf@es.net, garysull@microsoft.com Subject: Re: letter from ITU video coding experts group In-Reply-To: <396CD105.BB653AE9@research.att.com> Message-ID: Sender: casner@mail.packetdesign.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Wed, 12 Jul 2000, Barry Haskell wrote: > To IETF AVT group > > Here's a communication from the ITU-T SG16 Q15 experts group on video > coding. They are responsible for the H.263 video coding algorithm. The > latest version, to be finalized in November, contains optional profiles > and levels, which is the subject of this communication. It proposes a > MIME registration with optional parameters "profile" and "level" in > order to enable their use in SDP. I have added the optional parameters proposed above into the next revision of draft-ietf-avt-rtp-mime-03.txt which I will submit for posting tomorrow morning before the deadline. The new next is included below for your review. Please note that I have added these optional parameters to the existing registration for media type video/H263-1998 rather than adding a registration for a new media type video/H263-2000. I did so because video/H263-1998 indicates the payload format specified in RFC 2429, and that payload format will continue to be used with the November, 2000 version of the H.263 specification. If we defined a new media type, that might prevent interoperation between a 1998 and a 2000 implementation even though they are operating at a profile and level which is common to both. That is, my understanding is that the 2000 version is the same as the 1998 version with additional annexes. I assume that some of the profiles reduce to the 1998 version. If you disagree with this reasoning, please speak up. -- Steve 4.2.6. Registration of MIME media type video/H263-1998 MIME media type name: video MIME subtype name: H263-1998 Required parameters: None Optional parameters: profile: H.263 profile number, in the range 0 through 4, spec- ifying the supported H.263 annexes/subparts. level: Level of bitstream operation, in the range 0 through 2. Published specification: RFC 2429 Profile and level specifications may be found in the November, 2000 version of ITU Recommendation H.263, "Video coding for low bit rate communication". > > -- > Barry G. Haskell AT&T Labs - Research > bgh@research.att.com http://www.research.att.com/info/bgh > (also B.Haskell@IEEE.ORG) > > AT&T Labs NSL 3-223 tel: +1 732 345 3300 > 100 Schultz Drive - Middletown fax: +1 732 345 3033 > Red Bank, NJ 07701-7033 > > -- Steve From rem-conf Thu Jul 13 21:57:31 2000 From rem-conf-request@es.net Thu Jul 13 21:57:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13CxUn-0002hb-00; Thu, 13 Jul 2000 21:54:41 -0700 Received: from c017-h014.c017.sfo.cp.net (c017.sfo.cp.net) [209.228.12.228] by mail1.es.net with smtp (Exim 1.81 #2) id 13CxUk-0002a7-00; Thu, 13 Jul 2000 21:54:38 -0700 Received: (cpmta 1046 invoked from network); 13 Jul 2000 21:53:38 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO dhcp-168-0-6.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 13 Jul 2000 21:53:38 -0700 X-Sent: 14 Jul 2000 04:53:38 GMT Date: Thu, 13 Jul 2000 22:29:56 -0700 (Pacific Daylight Time) From: Stephen Casner To: Orion Hodson cc: rem-conf@es.net, Scott Keagy , Craig Telke Subject: Re: RTP payload types in draft-ietf-avt-profile-new-08.txt In-Reply-To: <20736.956267174@cs.ucl.ac.uk> Message-ID: Sender: casner@mail.packetdesign.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Referring back to a discussion in April: On Thu, 20 Apr 2000, Orion Hodson wrote: > G.729 is different because the frame type is not included within each > frame and several distinct frame types exist between the original > recommendation and it's annexes (audio at 6.4, 8, and 11.8 kbit/s, and > CNG). Distinct payload identifiers must be advertised and negotiated > for each of the available encodings as receivers cannot decode the > data otherwise. The RTP profile currently only specifies G.729/A at 8kb/s, in which the data frames are 10 bytes and the CNG frames are 2 bytes. Frame packing rules are specified to allow the CNG frames to be distinguished by the overall payload length. I presume that the frame sizes are different for the G.729 annexes with specify operation at 6.4 and 11.8kb/s, and I agree that different payload identifiers must be used for these. It would be possible to select operation at one of these other rates using an SDP a=fmtp attribute with a bitrate=6.4 parameter, but I agree that it would be more appropriate to use a different encoding name such as G729C (or whatever the annex letter is). However, I don't know even know what the annex letters are because I don't track this activity in the ITU. Nobody has proposed the addition of these encodings in the RTP profile nor provided the frame size description and packing rules. Does Freg Burg (who provided the existing G.729 information) or anyone else want to do this? It may be best to do in a separate payload format specification rather than trying to add it to the existing profile draft. Another part of that same discussion was about G.723 for which the bitrate can change on the fly. As was discussed, it may be desired to specify a preference for one bitrate and/or use of VAD in a capability negotiation. Therefore, I have added to the rtp-mime draft optional parameters for G.723 to specify bitrate and annexa=yes/no. Similarly, I have added an optional parameter annexb=yes/no for G.729 to specify that VAD is used or desired. Or has some other convention been proposed in the SIP community? -- Steve From rem-conf Fri Jul 14 01:52:46 2000 From rem-conf-request@es.net Fri Jul 14 01:52:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D1AQ-0000j5-00; Fri, 14 Jul 2000 01:49:54 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13D1AP-0000hh-00; Fri, 14 Jul 2000 01:49:53 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-160.dialup.cs.tu-berlin.de [130.149.145.160]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id KAA14910; Fri, 14 Jul 2000 10:43:47 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000714102944.027c0f00@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 10:44:07 +0200 To: Stephen Casner , Barry Haskell From: Stephan Wenger Subject: Re: letter from ITU video coding experts group Cc: rem-conf@es.net, garysull@microsoft.com In-Reply-To: References: <396CD105.BB653AE9@research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Steve, Group, Please note that I have added these optional parameters to the >existing registration for media type video/H263-1998 rather than >adding a registration for a new media type video/H263-2000. >If you disagree with this reasoning, please speak up. The problem here is that H.263's Appendix 1 of 1998 (which defines recommended mode combinations) was replaced by a new Appendix 1 in H.263 of 2000 (which defines profiles/levels). The reason why I asked Barry to change to H.263-2000 was to avoid confusion by people, who see in their copy of H.263-1998 the recommended mode combos, say "hmm, the keyword profile/level does not appear here, but the Appendix implements something very similar" and implement those mode combos, which are not compatible with the mode combos of H.263-2000. Interoperability would not be achieved. I understand that you clarify the issue in the descriptions, but the source of confusion remains. This is, by the way, just an example for the problem of registering/ referencing non-normative information in a normative document. I hope, Steve, that you are aware that ITU-T's Appendixes are non normative, and can be changed in a non compatible way at any working party meeting. For several reasons Q.15/16 of the ITU-T decided against making the profile/level Appendix a normative Annex (which would have solved the problem completely). Even referencing explicitly the November 2000 version of H.263 does not solve the problem, because people who buy H.263 in 2001 (with a potentially changed Appendix 1) would still receive a paper with the identical title, but containing the changed Appendix. Stephan > -- Steve > > > > >4.2.6. Registration of MIME media type video/H263-1998 > > MIME media type name: video > > MIME subtype name: H263-1998 > > Required parameters: None > > Optional parameters: > profile: H.263 profile number, in the range 0 through 4, spec- > ifying the supported H.263 annexes/subparts. > > level: Level of bitstream operation, in the range 0 through 2. > > Published specification: RFC 2429 > > Profile and level specifications may be found in the November, > 2000 version of ITU Recommendation H.263, "Video coding for > low bit rate communication". > > > > > > -- > > Barry G. Haskell AT&T Labs - Research > > bgh@research.att.com http://www.research.att.com/info/bgh > > (also B.Haskell@IEEE.ORG) > > > > AT&T Labs NSL 3-223 tel: +1 732 345 3300 > > 100 Schultz Drive - Middletown fax: +1 732 345 3033 > > Red Bank, NJ 07701-7033 > > > > > > -- Steve From rem-conf Fri Jul 14 01:52:46 2000 From rem-conf-request@es.net Fri Jul 14 01:52:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D1AE-0000hy-00; Fri, 14 Jul 2000 01:49:42 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13D1AC-0000hh-00; Fri, 14 Jul 2000 01:49:40 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-160.dialup.cs.tu-berlin.de [130.149.145.160]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id KAA15329; Fri, 14 Jul 2000 10:47:55 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000714104421.02894490@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 10:50:41 +0200 To: "Shigeru Fukunaga" , From: Stephan Wenger Subject: Re: low delay RTCP In-Reply-To: <00ad01bfed3d$879a7d60$cc03ad0a@kansai.oki.co.jp> References: <4.3.2.7.2.20000712173201.029ae140@mail.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >If possible, I would like to realize both small multicast and low delay. >However it seems not possible because of the flood of backward messages. I believe we have found a way to avoid this to a certain extend by dithering and preventing other receivers of sending their own upstream messages for a identical reason (by listening to all messages sent RTCP is multicasted, too). >I think there are following alternatives: > 1. You or I will change one's mind and integrate to one profile. > 2. 2 profiles will be defined for 2 ruls respectively. > 3. We will find good reason (condition) to be compatible both small > multicast and low delay. > 4. 2 types of rule will be defined in one profile. Looks like 3, or maybe 4 to me. See you in Pittsburgh. Stephan From rem-conf Fri Jul 14 03:39:42 2000 From rem-conf-request@es.net Fri Jul 14 03:39:40 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D2rA-0004L4-00; Fri, 14 Jul 2000 03:38:08 -0700 Received: from sunheger1.nm.informatik.uni-muenchen.de [129.187.214.1] by mail1.es.net with esmtp (Exim 1.81 #2) id 13D2r6-0004KP-00; Fri, 14 Jul 2000 03:38:04 -0700 Received: (from vogt@localhost) by sunheger1.nm.informatik.uni-muenchen.de (8.9.3+Sun/8.9.3) id MAA20947; Fri, 14 Jul 2000 12:26:45 +0200 (MET DST) Date: Fri, 14 Jul 2000 12:26:45 +0200 (MET DST) Message-Id: <200007141026.MAA20947@sunheger1.nm.informatik.uni-muenchen.de> From: USM 2000 Organization Committee To: usm2000@informatik.uni-muenchen.de Subject: USM 2000 Call for Participation X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Please accept our apologies if you receive this mail more than once...] USM 2000 - Announcement and Call for Participation It is just another two months until the USM 2000 will take place here in Munich. Therefore, we want to invite you to join us and participate at the conference. The discounted, early bird registration rates are valid until August 1st. You can save 50 Euro! So don't wait - register today. Below you find more detailed information on the conference and the preliminary program. You also find all this information on our web server. In particular, you will find the registration forms there. WWW: http://usm2000.informatik.uni-muenchen.de/ Registration: http://usm2000.informatik.uni-muenchen.de/registration.shtml We are looking forward to seeing you! Best regards, Claudia Linnhoff-Popien and Heinz-Gerd Hegering ------------------------------------------ Prof. Dr. Claudia Linnhoff-Popien Institut fuer Informatik Ludwig-Maximilians-Universitaet Muenchen Oettingenstr. 67, D-80538 Muenchen Tel.: +49 (89) 2178 2149 (FAX: -2147) http://www.informatik.uni-muenchen.de mailto:linnhoff@informatik.uni-muenchen.de ----------------------------------------------------------------------------- 3rd IFIP/GI International Conference on Trends towards a Universal Service Market Munich, Germany September 12-14, 2000 sponsored and supported by International Federation for Information Processing (IFIP) Gesellschaft für Informatik e.V. (GI) Ludwig-Maximilians-Universität München (LMU) Leibniz-Rechenzentrum München (LRZ) BWM AG DG Bank Siemens AG Munich Network Management Team (MNM-Team) Redwood Technologies Ltd. Software-Offensive Bayern General Information USM 2000 is the third event in a series of international IFIP conferences on Trends in Distributed Systems. It continues TreDS'96, held in Aachen, Germany and TrEC'98 with special focus on Electronic Commerce in Hamburg, Germany. The technological progress in the internet and telecommunication domains as well as deregulation efforts of the telecommunication markets currently under way in many countries enable an integration of data and telecommunication. Distributed platforms get adapted to the needs of telecommunication networks. This leads to a global distributed system with millions of objects, running on top of middleware platforms and interacting with each other to provide services. USM 2000 brings together researchers, service vendors and users in the field of universal service markets. USM 2000 takes place in Munich, Germany, the city of the famous Oktoberfest, which will start two days after the conference on September 16, 2000. Topics The USM 2000 considers services of a universal market in relation to middleware, distributed applications and management. Areas of special interest include: Component Based Systems, Service Creation Service Market Models, Accounting and Customer Care Quality of Service for Distributed Applications Trading, Brokering and Information Management Management of Virtual Networks Service and Application Management Ubiquitous Services and Nomadic Computing Distributed and Mobile Objects Agent Technology for Integrated Management Advances in Middleware Architectures, e.g. CORBA, DCOM, Jini Telecommunication Architectures related to Distributed Systems USM 2000 Preliminary Program Tuesday 12 September 2000 09.30 - 10.00 Welcome Claudia Linnhoff-Popien / Heinz-Gerd Hegering Conference Chairs Prof. Dr. rer. nat. Axel Schenzle Prorector Ludwig-Maximilians-University (LMU) Munich 10.00 - 11.00 Invited Talk "Beyond the TINA lesson: distributed processing for integrated fixed and mobile communications" Dr Sebastiano Trigila Telecommunications Network Department at Fondazione Ugo Bordoni, Rome, Italy 11.00 - 11.30 Coffee Break 11.30 - 13.00 Session Electronic Auctions and Trading Chair: Lea Kutvonen, University of Helsinki, Finland "Market-Skilled Agents for Automating the Bandwidth Commerce" Monique Calisti, Boi Faltings, EPFL Lausanne, Switzerland Sandro Mazziotta, Swisscom AG, Bern, Switzerland "Integrating Trading and Load Balancing for Efficient Management of Services in Distributed Systems" Dirk Thißen, RWTH Aachen, Germany Helmut Neukirchen, Medical University of Lübeck, Germany "Mapping Enterprise Roles to CORBA Objects using Trader" Alistair Barros, Keith Duddy, Michael Lawley, Zoran Milosevic, Kerry Raymond, Andrew Wood, DSTC, Brisbane, Australia 13.00 - 14.30 Lunch Break 14.30 - 16.00 Session Internet-Based Service Markets Chair: Winfried Lamersdorf, University of Hamburg, Germany "A Scheme for Component Based Service Deployment" Steve Rudkin, Alan Smith, BT Laboratories, United Kingdom "Performance Modeling of a Service Provisioning Design" Mohamed El-Darieby, Jerome Rolia, Carleton University, Ottawa, Canada "Correlation DialTone - Building Internet-Based Distributed Event Correlation Services" Gabriel Jakobson, Girish Pathak, GTE Laboratories, Waltham, USA 16.00 - 16.30 Coffee Break 16.30 - 18.00 Poster Session Mobile Agents and Applications Chair: Otto Spaniol, RWTH Aachen, Germany "Towards Context-Aware User Modeling" Michael Samulowitz, Siemens AG, München, Germany "Context notification in mobile environment to find the right person in time" Cora Burger, University of Stuttgart, Germany "Automated Adaption for Mobile Computing Based on Mobile Agents" Thomas Springer, Alexander Schill, University of Technology, Dresden, Germany "How to Efficiently Deploy Mobile Agents for an Integrated Management" Steffen Lipperts, RWTH Aachen, Germany "A Scalable Location Aware Service Platform for Mobile Applications based on Java RMI" Olaf Droegehorn, Kirti Singh-Kurbel, Markus Franz, Roland Sorge, Rita Winkler, Klaus David, IHP GmbH, Frankfurt (Oder), Germany Wednesday 13 September 2000 09.00 - 10.00 Invited Talk "Quality of Service and Service Provisioning on a Competitive Market" Prof Dr Lambert J.M. Nieuwenhuis KPN Research/University Twente, Netherlands 10.00 - 10.30 Coffee Break 10.30 - 12.00 Session Quality of Service Chair: Gerd Schürmann, GMD FOKUS, Berlin, Germany "Programming Internet Quality of Service" John Vicente, Intel Corporation, USA Michael Kounavis, Daniel Villela, Columbia University, USA Michah Lerner, AT&T Labs, USA Andrew Campbell, Columbia University, USA "Monitoring Quality of Service across Organizational Boundaries" Rainer Hauck, Helmut Reiser, University of Munich, Germany "Automated Allocation of Multiprovider Service Demands" Monique Calisti, Boi Faltings, EPFL Lausanne, Switzerland 12.00 - 13.30 Lunch Break 13.30 - 15.00 Session Mobile and Distributed Services Chair: Axel Küpper, RWTH Aachen, Germany "A Vehicular Software Architecture Enabling Dynamic Alterability of Services Sets" Volker Feil, Ulrich Gemkow, University of Stuttgart, Germany Matthias Stümpfle, DaimlerChrysler AG, Stuttgart, Germany "JBSA: An Infrastructure for Seamless Mobile Systems Integration" Stefan Müller-Wilken, Winfried Lamersdorf, University of Hamburg, Germany "Mobtel - A Mobile Distributed Telemedical System for Application in the Neuropsychological Therapy" Hendrik Schulze, Klaus Irmscher, University of Leipzig, Germany 15.00 - 15.30 Coffee Break 15.30 - 17.00 Poster session Trends in Data- and Telecommunications Chair: Sebastian Abeck, University of Karlsruhe, Germany "Design-Aspects for the integration of CORBA-based Value Added Services and Intelligent Networks" Frank Imhoff, Marcos dos Santos Rocha, RWTH Aachen, Germany "Experiences Building a Service Execution Node for Distributed IN Systems" Menelaos K. Perdikeas, Fotis G. Chatzipapadopoulos, Iakovos S. Venieris, Nation Technical University of Athens, Greece "Leasing in a Market for Computing Capacity" Spyros Lalis, Alexandros Karipidis, University of Crete, Greece "Virtual Malls for Web Commerce: Observations and Case Study" Anton Nijholt University of Twente, Netherlands "A QoS Meta Model to Define a Generic Environment for QoS Management" Jérôme Daniel, Bruno Traverson, EDF Division R&D, Clamart, France Sylvie Vignes, ENST, Paris, France 17.00 - 17.30 Break 17.30 - Social Event Thursday 14 September 2000 09.00 - 10.00 Invited Talk "The TAO of Patterns - Understanding Middleware and Component Architectures" Michael Stal Siemens AG, München, Germany 10.00 - 10.30 Coffee Break 10.30 - 12.00 Session Middleware Architectures Chair: John Vicente, Intel Corporation, USA "Trade-offs in a Secure Jini Service Architecture" Peer Hasselmeyer, Roger Kehr, Marco Voß, University of Technology, Darmstadt, Germany "Loadable Smart Proxies and Native-Code Shipping for CORBA" Rainer Koster, Thorsten Kramp, University of Kaiserslautern, Germany "A Middleware Architecture for Scalable, QoS-Aware and Self-Organizing Global Services" Franz J. Hauck, Erich Meier, Ulrich Becker, Martin Geier, Uwe Rastofer, Martin Steckermeier, University of Erlangen-Nürnberg, Germany 12.00 - 13.30 Lunch Break 13.30 - 15.00 Session Service Management Chair: Bernhard Neumair, DeTeSystem, Munich, Germany "Fuzzy Modeling of Cooperative Service Management" Pradeep Ray, University of New South Wales, Sydney, Australia Seyed A. Shahrestani, University of Western Sydney, Australia "Customer Service Management: An Information Model for Communication Services" Michael Langer, Michael Nerb, Leibniz Supercomputing Center, Munich, Germany "Specification of a Service Management Architecture to Run Distributed and Networked Systems" Christian Mayerl, Zoltan Nochta, Markus Müller, Martin Schauer, Andreas Uremovic, Sebastian Abeck, University of Karlsruhe, Germany 15.00 - 15.15 Conclusions From rem-conf Fri Jul 14 03:50:30 2000 From rem-conf-request@es.net Fri Jul 14 03:50:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D32W-0006CC-00; Fri, 14 Jul 2000 03:49:52 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13D32T-0006Bh-00; Fri, 14 Jul 2000 03:49:50 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08532; Fri, 14 Jul 2000 06:49:48 -0400 (EDT) Message-Id: <200007141049.GAA08532@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtptest-03.txt Date: Fri, 14 Jul 2000 06:49:47 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 Testing Strategies Author(s) : C. Perkins, J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-rtptest-03.txt Pages : 20 Date : 13-Jul-00 This memo describes a possible testing strategy for RTP implementations. It is intended as an aid to implementors and does not specify a standard of any kind. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtptest-03.txt 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-rtptest-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-ietf-avt-rtptest-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: <20000713144930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtptest-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtptest-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713144930.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Jul 14 03:50:31 2000 From rem-conf-request@es.net Fri Jul 14 03:50:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D32a-0006Cj-00; Fri, 14 Jul 2000 03:49:56 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13D32Y-0006CJ-00; Fri, 14 Jul 2000 03:49:54 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08561; Fri, 14 Jul 2000 06:49:52 -0400 (EDT) Message-Id: <200007141049.GAA08561@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mib-13.txt Date: Fri, 14 Jul 2000 06:49:52 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 : Real-Time Transport Protocol Management Information Base Author(s) : M. Baugher, I. Suconick, B. Strahm Filename : draft-ietf-avt-rtp-mib-13.txt Pages : 35 Date : 13-Jul-00 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Protocol(RTP) systems [RFC1889]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-13.txt 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-mib-13.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-mib-13.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: <20000713144945.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713144945.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Jul 14 03:50:31 2000 From rem-conf-request@es.net Fri Jul 14 03:50:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D32R-0006Bc-00; Fri, 14 Jul 2000 03:49:47 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13D32P-0006Au-00; Fri, 14 Jul 2000 03:49:45 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08505; Fri, 14 Jul 2000 06:49:43 -0400 (EDT) Message-Id: <200007141049.GAA08505@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mp3-02.txt Date: Fri, 14 Jul 2000 06:49:43 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 : A More Loss-Tolerant RTP Payload Format for MP3 Audio Author(s) : R. Finlayson Filename : draft-ietf-avt-rtp-mp3-02.txt Pages : Date : 13-Jul-00 While the RTP payload format defined in RFC 2250 is generally applicable to all forms of MPEG audio or video, it is less suitable for MPEG 1 or 2, layer III audio (commonly known as 'MP3'). The reason for this is that an MP3 frame is not a true 'Application Data Unit' - it contains a back-pointer to data in earlier frames, and so cannot be decoded independently of these earlier frames. Because RFC 2250 defines that packet boundaries coincide with frame boundaries, it handles packet loss inefficiently when carrying MP3 data. The loss of an MP3 frame will render some data in previous (or future) frames useless, even if they are received without loss. In this document we define an alternative RTP payload format for MP3 audio. This format uses a data-preserving rearrangement of the original MPEG frames, so that packet boundaries now coincide with true MP3 'Application Data Units', which can also (optionally) be rearranged in an interleaving pattern. This new format is therefore more data-efficient than RFC 2250 in the face of packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mp3-02.txt 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-mp3-02.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-mp3-02.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: <20000713144906.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mp3-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mp3-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000713144906.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Fri Jul 14 06:52:27 2000 From rem-conf-request@es.net Fri Jul 14 06:52:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D5o7-0000r3-00; Fri, 14 Jul 2000 06:47:11 -0700 Received: from rolex.csc.ncsu.edu [152.1.213.197] by mail1.es.net with esmtp (Exim 1.81 #2) id 13D5o6-0000qS-00; Fri, 14 Jul 2000 06:47:10 -0700 Received: (from rhee@localhost) by rolex.csc.ncsu.edu (8.8.4/UC02Jan97) id JAA09263; Fri, 14 Jul 2000 09:46:51 -0400 (EDT) From: "Dr. Injong Rhee" Message-Id: <10007140946.ZM9261@unity.ncsu.edu> Date: Fri, 14 Jul 2000 09:46:50 -0400 In-Reply-To: "Shigeru Fukunaga" "Re: low delay RTCP" (Jul 14, 11:45am) References: <4.3.2.7.2.20000712173201.029ae140@mail.cs.tu-berlin.de> <00ad01bfed3d$879a7d60$cc03ad0a@kansai.oki.co.jp> X-Mailer: Z-Mail (3.2.1 10oct95) To: "Shigeru Fukunaga" , , "Stephan Wenger" Subject: Re: low delay RTCP Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Fukunaga San, > As you indicated, FIR and NEWPRED can work on small multicast > group. I agree with your investigation. Count in retransmission as well. It seems that retransmission and FEC are natural for unicast and multicast. Retransmission and FEC can be made scalable even for large multicast group with appropriate feedback suppression or local recovery shcemes (On the other hand, NEWPRED and FIR seem inherently limited in large multicast groups because the encoder must adapt to each recver's loss patterns). For instance, retransmission with some hierarchical struture for local recovery as discussed in IETF-RMT group would also scale fairly well for a large group. FEC, of course, is scalable for any group size as it does not need as much feedback as other recovery schemes being proposed. > > On the other hand, the performances of these tools also strongly depend > on the delay, because the delay leads the slow error recovery, In this case, > the degraded pictures are displayed for long time, or the video is freezed. > > If possible, I would like to realize both small multicast and low delay. > However it seems not possible because of the flood of backward messages. > > Therefore we have to select one from 2 items. > You selected the small multcast and not low delay. While I selected the > low delay on unicast. As our 2 types of selection have some reasons > respectively, it seems not easy to marge 2 drafts. > I think it is not so good these 2 types of rule are defined in one profile. > I believe that FIR and NEWPRED (retransmission for that matter) are not incompatible as far as feedback is concerned. They all require low delay RTCP and can work for small multicast. They can even work together; FIR can be very useful when NEWPRED fails (which happens when recver or sender frame buffer runs out). > I think there are following alternatives: > 1. You or I will change one's mind and integrate to one profile. > 2. 2 profiles will be defined for 2 ruls respectively. > 3. We will find good reason (condition) to be compatible both small > multicast and low delay. > 4. 2 types of rule will be defined in one profile. > I think 3 or 4 would be a good option as it seems consistent with the general sentiment of this group -- am I wrong? :-) Thanks Injong -- Injong Rhee, Department of Computer Science North Carolina State University, Raleigh, NC 27695 Home page: http://www.csc.ncsu.edu/faculty/rhee Email: rhee@csc.ncsu.edu, Phone: 919-515-3305, Fax: 919-515-7925 From rem-conf Fri Jul 14 07:32:42 2000 From rem-conf-request@es.net Fri Jul 14 07:32:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D6U9-0003yU-00; Fri, 14 Jul 2000 07:30:37 -0700 Received: from mail-blue.research.att.com [135.207.30.102] by mail1.es.net with esmtp (Exim 1.81 #2) id 13D6U8-0003yF-00; Fri, 14 Jul 2000 07:30:36 -0700 Received: from surfcity.research.att.com (surfcity.research.att.com [135.207.128.5]) by mail-blue.research.att.com (Postfix) with ESMTP id AABD14CE1B; Fri, 14 Jul 2000 10:30:35 -0400 (EDT) Received: from research.att.com (anniepc [135.207.130.90]) by surfcity.research.att.com (8.8.7/8.8.7) with ESMTP id KAA14183; Fri, 14 Jul 2000 10:29:12 -0400 (EDT) Message-ID: <396F2406.EC7A2949@research.att.com> Date: Fri, 14 Jul 2000 10:30:30 -0400 From: Barry Haskell X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Casner Cc: Stephan Wenger , rem-conf@es.net, garysull@microsoft.com Subject: Re: letter from ITU video coding experts group References: <396CD105.BB653AE9@research.att.com> <4.3.2.7.2.20000714102944.027c0f00@mail.cs.tu-berlin.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephan Wenger wrote: > The problem here is that H.263's Appendix 1 of 1998 (which defines > recommended mode combinations) was replaced by a new Appendix 1 in H.263 of > 2000 (which defines profiles/levels). Actually, it's Appendix II > The reason why I asked Barry to change to H.263-2000 was to avoid confusion > by people, who see in their copy of H.263-1998 the recommended mode combos, > say "hmm, the keyword profile/level does not appear here, Yes, the problem is that the term "H.263-1998" is overloaded. Sometimes it means packetization, and sometimes it means both packetization and video coding. For this reason, Stephen's registration says look in the 2000 version of H.263 for definitions of profile and level. If more profiles and levels are added, the registration would have to be updated to point to the latest version, which would be backward compatible. > but the Appendix implements something very similar" and implement those mode > combos, which are not compatible with the mode combos of H.263-2000. > Interoperability would not be achieved. The "mode combinations" of 1998 are exactly the same as profiles 1-3 of 2000, so they are compatible. However, there are no levels of bitrate, picture size, etc. specified in 1998, so it's not very useful for SDP capability exchange. > I hope, Steve, that you are aware that ITU-T's Appendixes are non normative, > and can be changed in a non compatible way at any working party meeting. Well it's a little harder than that, but so far, the changes are compatible. We certainly expect that to continue if more profiles and levels are added. > Even referencing explicitly the November 2000 version of H.263 does not > solve the problem, because people who buy H.263 in 2001 (with a potentially > changed Appendix 1) would still receive a paper with the identical title, > but containing the changed Appendix. Perhaps, but it would be backward compatible. PS Any thought of adding profile & level to MPEG2? -- Barry G. Haskell AT&T Labs - Research bgh@research.att.com http://www.research.att.com/info/bgh (also B.Haskell@IEEE.ORG) AT&T Labs NSL 3-223 tel: +1 732 345 3300 100 Schultz Drive - Middletown fax: +1 732 345 3033 Red Bank, NJ 07701-7033 From rem-conf Fri Jul 14 07:47:52 2000 From rem-conf-request@es.net Fri Jul 14 07:47:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D6jI-000563-00; Fri, 14 Jul 2000 07:46:16 -0700 Received: from auemail2.lucent.com (auemail2.firewall.lucent.com) [192.11.223.163] by mail1.es.net with esmtp (Exim 1.81 #2) id 13D6jG-00055i-00; Fri, 14 Jul 2000 07:46:14 -0700 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA12625 for ; Fri, 14 Jul 2000 10:46:12 -0400 (EDT) Received: from hoserve.ho.lucent.com (h135-17-35-10.lucent.com [135.17.35.10]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id KAA12601; Fri, 14 Jul 2000 10:46:11 -0400 (EDT) Received: from qc84.ho.lucent.com by hoserve.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA09911; Fri, 14 Jul 2000 10:51:48 -0400 Received: from qc84 by qc84.ho.lucent.com (8.8.8+Sun/EMS-1.4.1 client sol2) id KAA02159; Fri, 14 Jul 2000 10:49:28 -0400 (EDT) Message-Id: <200007141449.KAA02159@qc84.ho.lucent.com> Date: Fri, 14 Jul 2000 10:49:28 -0400 (EDT) From: chuah Reply-To: chuah Subject: LIPE internet draft To: internet-drafts@ietf.org Cc: rem-conf@es.net MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Unkindness_of_Ravens_251_000 X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --Unkindness_of_Ravens_251_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: dlYGtCGeC+Q2bhjxUdMwlw== Hi, we wish to submit this draft to IETF AVT Working Group. thanks Mooi Choo --Unkindness_of_Ravens_251_000 Content-Type: TEXT/plain; name="draft-ietf-avt-lipe-01.txt"; charset=us-ascii; x-unix-mode=0644 Content-Description: draft-ietf-avt-lipe-01.txt Content-MD5: yVAU9ZFomOwxWJlMS4gxPw== PPP Working Group Mooi C. Chuah Internet Draft Enrique J. Hernandez-Valencia Expires December 2000 Lucent Technologies Bell Laboratories June 2000 A LightWeight IP Encapsulation (LIPE) Scheme Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This document is the product of the Point-to-Point Protocol Extensions Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. Abstract Several application level compression/multiplexing solutions have been proposed in the IETF Audio/Video Transport (AVT) Working Group [1][2][9] to improve the transport efficiency of packet-voice traffic over IP-based networks. These approaches generally assume voice packets are RTP/UDP/IP encapsulated by the communicating end-points (e.g., IP phones, mobile terminal, media gateways, etc.). In some transport scenarios, using RTP/UDP/IP encapsulation for voice packet is unnecessary as only the data transfer service provided by the IP layer is required, not the media control functions. This document describes a lightweight IP encapsulation scheme to multiplex low bit rate audio (or multimedia) packets into a single UDP/IP session or IP session. The decision to multiplexing audio Chuah, et al. expires December 2000 [Page 1] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 packets at the UDP or IP layer is left as a balance between data transport efficiency and implementation complexity among the communicating end-points across a routed IP network. This document is the product of the AVT Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-avt@merit.edu mailing list. Chuah, et al. expires December 2000 [Page 2] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 Applicability These extensions are intended for those implementations which desire to multiplex small data packets together into one IP protocol data unit (PDU). Table of Contents Chuah, et al. expires December 2000 [Page 3] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 1. Introduction As the Internet evolves into a ubiquitous communication infrastruc- ture, IP based technologies have also become more sophisticated. As a consequence of the maturing of the IP technology, it is now evident that the previously separate data and voice networks are converging to provide integrated service, including data, voice and video. While data packets can often be quite large, voice packets are in general rather small. Codecs at the IP telephony gateway which, compress the incoming speech samples, generate packets with sizes ranging from 5 to 20 bytes per speech sample. For example, G723.1 generates a 20 bytes speech packet at 30 ms intervals [3]. Many codecs used in cellular environments generate packets of size less than 10 bytes per speech sample. Such small size packets are subjected to a large transport overhead if transfered in individual IP packets. For example a 10-byte voice packet transmitted using UDP/IP encapsulation incurs an overhead of 28 bytes (20 byte IP header, plus possibly 8 bytes UDP header), or 280%. In addition, if each audio stream uses one UDP media session, the large number of packets will create heavy packet processing load for the intermediate media gateway devices that operate above the IP-layer, even if no processing of the user flow is required. The available UDP port numbers may also become a limiting factor on the maximum number of sessions. Although the relatively high transport overhead may not constitute a critical traffic engineering factor in transport scenarios where net- work bandwidth is plentifull, the situation is quite different for many wireless access networks where the user traffic channel may be restricted to as little as 4K-10K kbps. There, the concept of pooling multiple user flows into a more efficienty multiplexed channel is highly appealing. Fortunately, for many applications, it is possible to multiplex a large number of sessions into a single IP packet to improve effi- ciency and scalability without incurring much multiplexing delay. For example, when long distance telephony is offered over the Inter- net, the IP telephony gateways or the mobile switching centers in a cellular network provide an interface between the existing circuit switched telephone networks (such as PSTN and cellular networks like CDMA/GSM/TDMA network) and the packet switched IP data networks. The voice calls between a pair of IP telephony gateways or the mobile switching centers can be multiplexed into a single UDP session. As another example, in a CDMA based cellular network, an IP network may be used as the access network by the wireless service provider to connect the base stations to the mobile switching centers, part of whose function is to select the reverse direction radio frames and Chuah, et al. expires December 2000 [Page 4] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 duplicate the forward direction radio frames for mobiles in soft handoff. In this case, the radio frames from different mobiles han- dled by the same base station, which can be either voice or data, can also be multiplexed into a single UDP session. Many such applications have specific delay requirements. In the first example above, the usual transfer delay and delay jitter requirements for voice application applies. In the second example, the duplicate radio frames in the reverse direction must be received by the mobile switching center within a small time window for the frame selection. RTP [4] is a protocol designed to provide various real time services to the application layer with no assumption on the underlying network providing timely delivery or quality-of-service commitments. It can be used when the network is not heavily loaded and the application it supports can adapt to the varying network conditions to some extent. To improve the transport efficiency, some multiplexing schemes have been proposed within the framework of RTP [1,2]. Many of the features of RTP are designed to provide media control information to cope with the unavailability of QoS guarantees from the underlying network at the application layer. As such guarantees become available in modern/future IP networks, some of these features become unnecessary. These features are also of limited value to non- RTP applications (e.g., most commercial wireless voice traffic). In this document, we propose to use a lightweight encapsulation scheme based on UDP/IP for multiplexing application sessions. LIPE is designed to support multimedia traffic including both voice and data. We also include some discussions on how UDP/IP header compression can be done to provide even more savings. 2. The Encapsulation Scheme The Lightweight IP Encapsulation (LIPE) uses either UDP/IP or IP as the transport layer. Each LIPE encapsulated payload consists of a variable number of multimedia data packet (MDP). For each MDP, there is a multiplexing header (MH) that conveys protocol and media specific information. The format of an IP packet conveying multiple MDPs over UDP using a minimum size MH is shown in Figure 1 (a). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+ | + + + + + + + + | | IP + UDP* + MH1 + MDP1+ MH2 + MDP2+ ~ + MHn + MDPn| | (20) + (8) + (1) + + (1) + + + (1) + | Chuah, et al. expires December 2000 [Page 5] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+ MH: Multiplexing Header MDP: Multimedia Data Packet (Length expressed in bytes) Figure 1 (a): Lightweight IP/UDP Encapsulation Scheme The format of an IP packet conveying multiple MDPs without UDP is and using a minimum size MH shown in Figure 1 (b). Note that a 1-byte tunnel-identifier (TID) is included when the LIPE PDUs are conveyed direcly over IP. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+ | + + + + + + + + | | IP + TID + MH1 + MDP1+ MH2 + MDP2+ ~ + MHn + MDPn| | (20) + (1) + (1) + + (1) + + + (1) + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+ TID: Tunnel Identifier MH: Multiplexing Header MDP: Multimedia Data Packet (Length expressed in bytes) Figure 1 (b): Lightweight IP Encapsulation Scheme The generic protocol stack for LIPE, assuming PPP in HDLC-like fram- ing [RFC 1662], is as shown in Figure 2: ------ | LIPE | ------ ------ | UDP | | LIPE | ------ ------ | IP | | IP | ------ ------ | PPP | | PPP | ------ ------ | HDLC | | HDLC | ------ ------ (a) IP/UDP/LIPE (b) IP/LIPE Figure 2: Protocol Stacks for LIPE We assume that all LIPE packets on the same PPP link are encapsulated either as in Figure 1 (a) or as in Figure 1 (b), but not both simul- taneously. Section 6 explains how IPCP is used to negotiate for either type of encapsulation format. Chuah, et al. expires December 2000 [Page 6] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 2.1. Basic The Multiplexing Header (MH) comprises of two components: the Header Extension bit (the E bit) and the MDP length field. Optional Exten- sion Headers can be supported via the E bit. The MH format is shown in Figure 3. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | + + |E+ Length + Extension | + + Headers +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 3: Multiplexing Header Format E bit (E bit): The Header Extension bit is the least significant bit of the MH header. It is set to one/zero to indicate the presence/absense of an extension header. If the E-bit is set to one, the first header extension MUST be a UserID header. Length: 7 bit length field. This field indicates the size of the entire MDP packet in bytes, including the E bit, Length field and optional extended headers (if they exist). 2.2. Extension Extension headers are used to convey user specific information. It also facilitates the customization of LIPE to provide additional con- trol information e.g. sequence number, voice/video quality estimator. 2.2.1. User The 16-bit User Identifier is the first field in any Extension Header. It is used to identify MDPs belonging to specific user flows. The format of a LIPE encapsulated payload with a UserID extension header is shown in Figure 4. The least significant bit of the 1st byte of UserID is the X-bit. When set to one, it indicates that the extension header is longer than 2 bytes. Thus, effectively addressing range of the UserID field is 15-bit long. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + | |1+ Length +X+ UserId | | + + + | Chuah, et al. expires December 2000 [Page 7] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <--------------------- MH ---------------------> (3 bytes) Figure 4 : A MH with a UserID field The 15-bit UserID allows up to 32768 flows to be multiplexed into a single UDP/IP session. The seemingly high number for the UserID is chosen for various reasons. First, many applications may be alive, but not active, for quite some time. These "dormant" applications will still hold on to the user identifiers. Therefore, the number of active applications that can actually contribute to the multiplexed channel may be much smaller. Second, in a mobile environment, when a mobile is handed off from one base station to another, the applica- tion on this mobile will have to be multiplexed into another UDP ses- sion in the new base station. Assuming each mobile takes up one iden- tifier, if the UserID space is large enough, it is possible to make the UserID unique to the frame handler in the mobile switching center (or Radio Network Controller). Consequently during soft handoff between base stations controlled by the same frame handler (as shown in Figure 4), there is no need to reassign UserID thus saving signal- ing cost. (IP2) ---- ------- |UE| <----- |NodeB1| SIP DIP UID= UserID ---- -------- ---------------------- ^ |IP1 |IP2|UID1 |payload | ---------------------- -------- | RNC | (IP1) SIP: Source IP address -------- DIP: Destination IP address (IP3) / ------------------------- --------/ |IP1| IP3| UID1 | payload | |NodeB2| -------------------------- -------- Figure 5: Using the same UserID in the softhandoff scenario Note that a service provider may decide to further subdivide the 15 bit UserID field into a user identifier field (e.g. 10 bits) and a Chuah, et al. expires December 2000 [Page 8] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 base station identifier field (e.g. 5 bits). Such subdivision is vendor-specific and can be done transparently (as long as the two peers understand the formats). 2.2.2. Payload If the X-bit in the UserId field is set, it means there is a Paylaod Identifier (PID) extension header following the UserID field. The Payload Identifier field starts with a 4-bit Payload Type Identifier (PTI) , a 4-bit PID Length and any additional payload specific data. The format of the PID field is illustarted in Figure 6. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + | | Type + LNGTH + Header Information | | + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 : Format of the PID field Thus, a MH with 2-byte UserId and the PID extended header will look like Figure 7. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + | |1+ Length +1+ UserId | | + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID + PID + PID + Data | | Type + LnG=2 + Payload + Payload | | 1 + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: A MH with a UserID field and a PID field Note that one can use the PID Type to indicate different wireless access technologies e.g. PID Type = 1 indicates IS95 network, PID Type = 2 indicates UMTS network. 2.3. Examples In this section, we show some specific LIPE examples: In this example, it is assumed that each mobile terminal generates compressed RTP/UDP/IP packets. The MH header is only 1-byte long with Chuah, et al. expires December 2000 [Page 9] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 the E bit set to zero indicating that there is no extended header. The UserID is not used since the context ID [8] within the compressed RTP/UDP/IP header can uniquely identify the user. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + Compressed | + + Compressed | |0+ Length 1 + RTP/UDP/IP |0+ Length 2 + RTP/UDP/IP | | + + PDU 1 | + + PDU 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <--- MH ---> <---Payload ---> (1byte) <----------- MDP 1 ---------------><---------- MDP 2 -----------> <------------- LIPE packet -------> Figure 8(a): Carrying Compressed RTP/UDP/IP packets 2.3.1. Carrying IS95 voice packets In this scenario, the E bit of the first MH header is set to one to indicate that UserId exists. The X-bit is set to one indicating that there is a PID field. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + | |1+ Length +1+ UserId | | + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID + PID + PTI +Timing +Quality+ Seq | | Type + LnG=3 + + Info + + # | | 1 + + + + Ind + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8(b) : Carrying IS95 voice packets In the example, PID Type =1 indicates that this is IS95 voice packets and the additional extended header is 3 bytes long. The additional information carried in the extended header is the IS95 packet type (PTI), some timing information, voice quality indictor, and sequence numbers. Chuah, et al. expires December 2000 [Page 10] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 2.3.2. carrying UMTS conversational/streaming packets 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + | |1+ Length +0+ UserId | | + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | FP PDU | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <--------------------- MH ---------------------> (3 bytes) Figure 8(c): Carrying UMTS conversational/streaming packets In this scenario, the E bit is set to one and the X bit is set to zero. The UserID is used to identify the different user flows. The payload is the frame protocol (FP) PDU described in [TS25.413]. Note that in our encapsulation scheme, no field is provided in the header for error checking. Instead we rely on the IP or UDP checksum to provide for the overall IP or UDP payload error detection. We believe this level of protection is sufficient since the IP packet carrying multiplexed audio (or multimedia) frames are not carried over the air. 3. QoS Besides the traditional best-effort service, other services such as integrated service (including controlled load service and guaranteed service) and differentiated service have been defined. These ser- vices, by reserving certain network resources such as bandwidth, can provide the traffic with certain guarantees such as delay and loss. To support multiple QoS classes, we suggest using the DSCP bits of the IP header e.g. for high quality voice, we can mark the IP packet with multiplexed audio frames with EF code point; for low quality voice, we can mark it with one of the appropriate AF code points. 4. Multiplexing Policy Given the link MTU L_max, a UDP/IP packet can carry payload of up to L_max - H_ip - H_udp, where H_ip is the IP header length (20 bytes Chuah, et al. expires December 2000 [Page 11] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 without option) and H_udp is the UDP header length (8 bytes). To limit the multiplexing delay, a multiplexing timer with a lifetime of T_mux is used. H_mh is the multiplexing header length. The encapsula- tion policy is as follows: a) If the total size of the received radio frames plus that of that of their H_mh exceeds L_max - H_ip - H_udp, send all the MDP frames except the most recently received one (no fragmentation of MDP) in one UDP packet, and restart the multiplexing timer. The newly received MDP is held for multiplexing with upcoming MDPs. b) If the multiplexing timer expires, send the accumulated MDPs in one UDP packet and restart the encapsulation timer. 5. UDP/IP Header Compression Note that if IP headers are not required to do routing (say the underlying network is either ATM or MPLS), one can either remove or compress the UDP/IP (IP) header. That will increase further the bandwidth efficiency of using the LIPE scheme in a radio access net- work where the BSs have IP interfaces that run over ATM/MPLS net- works. When we map a certain UDP, or (IP+TID), tunnel into a particular MPLS/ATM connection, we need to ensure that the quality of service provided by the MPLS/ATM connection matches with the DSCP indicated in the IP header. 6. Comparison of the LIPE scheme with other existing proposals In this section, we compare 3 approaches for carrying multiplexed audio packets in terms of the overhead incurred. The 3 approaches considered are cUDP/PPPMux, tCRTP, and LIPE. We assume that PPP/HDLC is the Layer 2 technology used. Approach 1 cUDP/PPPMux PPP/HDLC 4 bytes PPP ID 1 byte per stream PFF,length 1 byte cUDP/IP 3 byte payload Approach 2 tCRTP PPP/HDLC 4 bytes cIP 3 byte L2TP HC 1 byte PPPMuxID 1 byte PPPID 1 byte per stream PFF,length 1 byte cUDP/IP 3 byte payload Chuah, et al. expires December 2000 [Page 12] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 Approach 3 LIPE PPP/HDLC 4 bytes cUDP/IP 3 byte per stream length 1 byte UID 0-2 bytes payload We see that for approach 3, the per stream overhead is 1-3 bytes while for approaches 1 & 2, the per stream overhead is 4 bytes. 7. PPP A new LCP Configuration Option is used to request LIPE operation for the PPP link. A summary of the LIPE Configuration Option format for the Link Control Protocol (LCP) is shown below. The fields are transmit- ted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 3 The new LCP option is used only as a hint to the peer that LIPE operation is preferred by the sender. Support of LIPE operations is negotiated in each direction independently. Acknowledgement of the LIPE LCP Option (TBD) does not obligate a peer to transmit LIPE frames. Non LIPE-speakers SHOULD instead send LCP Configure- Reject for the option. If either LCP Configure-Nak or LCP Configure-Reject is received for this option, then the next transmitted LCP Configure-Request MUST NOT include this option. If the received LCP Configure-Request message does not contain a LIPE LCP option, an implementation MUST NOT send an unsolicited Configure-Nak for the option. (An implementation of LIPE that is already in LIPE framing mode and receives this option in an LCP Configure-Request message MAY, both for clarity and for convergence reasons, elect to send LCP Configure-Ack. It MUST NOT restart LCP nor change framing modes in this case.) Chuah, et al. expires December 2000 [Page 13] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 The size of a LIPE encapsulated frame MUST NOT exceed the maximum receive unit (MRU) size negotiated during LCP [10]. 8. Negotiating usage of LIPE When the layer 2 protocol is PPP, the usage of various LIPE confi- guration options can be negociated via the IP Compression Protocol option of IPCP: IPCP Option 2: IP configuration protocol Network Protocol: TBD indicates LIPE sub-option 1 enables use of IP session sub-option 2 enables use of UDP/IP session 9. Security This draft does not impose additional security considerations beyond those that apply to PPP and header-compression schemes over PPP. 10. Summary LIPE is designed to support multimedia traffic when certain resource guarantees are available from the underlying network. It is based on UDP/IP or IP; hence is lightweight compared with other proposals based on RTP [1,2]. As IP based networks become more and more sophis- ticated and offer various levels of resource guarantees [5], this scheme is more suitable to the modern/future IP architecture compared with RTP based schemes. The 15-bit UserID field in LIPE facilitates its usage in the third generation wireless system where handoffs may occur during the life- time of a session. By having a larger user space, we can greatly reduce the signalling overhead due to identifier re-negotiation dur- ing a handoff. A multiplexing policy is also outlined for LIPE. 11. References [1] J. Rosenberg, An RTP Payload Format for User Multiplexing work in progress, draft-ietf-avt-aggregation-00.txt [2] B. Subbiah, S. Sengodan, User Multiplexing in RTP payload between Chuah, et al. expires December 2000 [Page 14] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 IP Telephony Gateway, work in progress, draft-ietf-avt-mux-rtp-00.txt, Aug, 1998 [3] ITU-T Recommendation G.723.1 "Dual Rate Speech Coder for Multimedia Communications Transmitting At 5.3 and 6.3 Kbps", 1995 [4] H. Schulzrinne, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, RFC 1889 [5] K. El-Khatib, G. Luo, G. Bochmann, P. Feng, Multiplexing Scheme for RTP flows between access routers, work in progress, draft-ietf-avg-multiplexing-rtp-01.txt Oct 22, 1999 [6] 3G TS 25.413 v3.1.0, 3rd Generation Partnership Project: UTRAN Iu Interface RANAP Signaling, March 2000 [7] W. Simpson, Ed.,"PPP in HDLC-like Framing", STD 5X, RFC 1662, July 1994 [8] M. Engan etc, "IP header compression over PPP", RFC 2509, Feb 1999 [9] T. Koren etc, Enhancements to IP/UDP/RTP Header Compression, work in progress, draft-koren-avt-crtp-enhance-01.txt [10] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. 12. Intellectual Property Considerations Lucent Technologies Inc. may own intellectual property in some on some of the technologies disclosed in this document. The patent licensing policy of Lucent Technologies Inc. with respect to any patents or patent applications relating to this submission is stated in the March 1, 1999, letter to the IETF from Dr Roger E. Stricker, Intellectual Property Vice President, Lucent Technologies, Inc. This letter is on file in the offices of the IETF Secretariat. 13. Acknowledgements 14. Authors' Addresses Mooi C. Chuah Bell Laboratories Lucent Technologies 101, Crawfords Corner Road, Chuah, et al. expires December 2000 [Page 15] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 Holmdel, NJ 07733 chuah@bell-labs.com (732)-949-7206 Enrique J. Hernandez-Valencia Bell Laboratories Lucent Technologies 101, Crawfords Corner Road, Holmdel, NJ 07733 enrique@bell-labs.com (732)-949-6153 0 1 .ti 0 INSERT-THIS Chuah, et al. expires December 2000 [Page 16] Table of Contents 1. Introduction .................................................. 4 2. The Encapsulation Scheme ...................................... 5 2.1. Basic ....................................................... 7 2.2. Extension ................................................... 7 2.2.1. User ...................................................... 7 2.2.2. Payload ................................................... 9 2.3. Examples .................................................... 9 2.3.1. Carrying .................................................. 10 2.3.2. carrying .................................................. 11 3. QoS ........................................................... 11 4. Multiplexing Policy ........................................... 11 5. UDP/IP Header Compression ..................................... 12 6. Comparison of the LIPE scheme with other existing proposals 7. PPP ........................................................... 13 8. Negotiating usage of LIPE ..................................... 14 9. Security ...................................................... 14 10. Summary ...................................................... 14 11. References ................................................... 14 12. Intellectual Property Considerations ......................... 15 13. Acknowledgements ............................................. 15 14. Authors' Addresses ........................................... 15 TO-HERE Chuah, et al. expires December 2000 [Page 1] --Unkindness_of_Ravens_251_000-- From rem-conf Fri Jul 14 07:57:18 2000 From rem-conf-request@es.net Fri Jul 14 07:57:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D6qQ-0005v6-00; Fri, 14 Jul 2000 07:53:38 -0700 Received: from gorilla.mchh.siemens.de [194.138.158.18] by mail1.es.net with esmtp (Exim 1.81 #2) id 13D6qN-0005up-00; Fri, 14 Jul 2000 07:53:36 -0700 Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA14139; Fri, 14 Jul 2000 16:53:02 +0200 (MET DST) From: Bernhard.Wimmer@mch.siemens.de Received: from mchh9ega.mchh.siemens.de (mchh9ega.mchh.siemens.de [139.21.204.219]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA13216; Fri, 14 Jul 2000 16:53:10 +0200 (MET DST) Received: by mchh9ega.mchh.siemens.de with Internet Mail Service (5.5.2650.21) id <3Y4X3BNT>; Fri, 14 Jul 2000 16:54:54 +0200 Message-ID: <910CC38345FDD211943A0008C724DD48F18160@mchg9eca.mchh.siemens.de> To: internet-drafts@ietf.org, rem-conf@es.net Cc: Bernard.Hammer@icn.siemens.de, bernhard.petri@mch.siemens.de, tim.fingscheid@mch.siemens.de Subject: draft-wimmer-amr-01.txt Date: Fri, 14 Jul 2000 16:54:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFEDA3.58D37B10" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 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_000_01BFEDA3.58D37B10 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear I-D-manager and AVT group experts, We are submitting an Internet Draft for discussion in the AVT group. Title: MIME Type Registration of AMR Speech Codec Authors: B. Wimmer, B. Hammer Filename: draft-wimmer-amr-01.txt This document specifies an efficient way to handle AMR speech-coded data wihin the MIME framework. This document defines the required procedures and parameters for both real-time transport over RTP and storage of AMR speech data, e.g. as attachment to an email. In addition optional parameters are described for using enhanced error-detection and correction features. In addition to the attached version of the draft. Any comments by email are highly welcome. We are looking forward to the upcoming discussion with you at the Pittsburg' meeting. Best regards, Bernhard Wimmer <>=20 ************************************************************ Bernhard G. Wimmer Siemens AG, Grillparzerstr. 12, 81675 M=FCnchen Tel: +49-89-722-23247 Fax: +49-89-722-46489 GSM: +49-172-8688920 Email: Bernhard.Wimmer@Mch.Siemens.De PGP-key: Available on request ************************************************************ ------_=_NextPart_000_01BFEDA3.58D37B10 Content-Type: text/plain; name="draft-wimmer-amr-01.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-wimmer-amr-01.txt" Audio/Video Transport Group B. Wimmer, B. = Hammer Internet Draft Siemens = AG Document: =20 Category: Informational = July 14, 2000 Expires: January 14, 2001 MIME Type Registration of AMR Speech Codec Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering=20 Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of=20 six months and may be updated, replaced, or obsoleted by other=20 documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in=20 progress."=20 The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 1. Abstract This document defines MIME-name audio/AMR, encoding format=20 definitions and its parameters for GSM Adaptive Multi Rate (AMR)=20 speech codec for=20 - real-time transport over RTP - storage purpose. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20 this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction GSM Adaptive Multi Rate (AMR) codec [3] is a speech codec developed=20 by the European Telecommunications Standards Institute (ETSI). The=20 AMR codec is the mandatory speech codec for GSM and for third=20 generation systems by 3GPP. Although the AMR-codec was primarily=20 designed for wireless systems it gives excellent speech quality also for wirelined systems.=20 Wimmer & Hammer [Page = 1] INTERNET DRAFT MIME Type Registration of AMR Speech Codec July,14 = 2000 The AMR allows eight different speech coding modes. The bit-rates=20 range from 4.75 to 12.2 kbit/s, see Table 1. The sampling rate is=20 8000 Hz and processing is performed on 20 ms frames. Coding mode bit-rate note -------------------------------------------- 0 4.75 kbit/s 1 5.15 kbit/s 2 5.9 kbit/s 3 6.7 kbit/s PDC-EFR 4 7.4 kbit/s IS-641 [5] 5 7.95 kbit/s 6 10.2 kbit/s 7 12.2 kbit/s GSM EFR [6] Table 1: AMR speech coding modes As noted in Table 1 several rates are equivalent to other standards. Standard-compliant implementations [3] must support all eight coding modes. In addition to this, mode change may occur at any time. Furthermore Discontinuous Transmission / comfort noise (DTX/CN) functionality [7] may be used. Besides [7] for the particular coding modes 3, 4 and 7 specific DTX/CN schemes are defined, see [5][6][8]. 4. Definition of Modes This chapter defines the default and mandatory settings for both modes real-time transport over RTP and storage. 4.1. Real-time Transport over RTP Mode This mode is designed for applications using the real-time transport protocol (RTP), including the AMR RTP profile, e.g. Voice over IP applications. It is possible that the AMR decoder may want to receive certain AMR mode or a subset of AMR modes. In the end to end transmission parts of the chain may have limitations in the number of modes in the=20 active codec set, e.g. the GSM radio link can only use a subset of maximum four modes. Therefore, it is possible to request specific=20 set of AMR modes in capability description and it is mandatory for ARM encoder to abide this request. If request for mode set is not given, AMR encoder can freely decide which AMR mode to use. Although in principle AMR codec can perform a mode change at any time between any two modes, it is possible to set limitations for mode changes. The decoder has possibility to define the minimum number of frames between mode changes and to limit the mode change to happen into neighboring modes only. Wimmer & Hammer [Page = 2] INTERNET DRAFT MIME Type Registration of AMR Speech Codec July,14 = 2000 In addition to AMR DTX/CN scheme, the three codec standards that are part of the AMR also have their own DTX/CN schemes ([6][7][12]). To enable interoperability with terminals supporting these=20 standards, AMR can optionally be extended to support also these CN schemes. The CN capabilities are signaled in capability description. If no CN capabilities are reported, it is assumed that AMR CN is=20 supported. If CN capabilities are reported, all supported CN types (including AMR CN) must be signaled. It is also possible to limit the number of frames, both AMR and redundancy frames, encapsulated into one RTP packet. This is an optional feature and if no parameter is given in capability description, the transmitter can encapsulate any number of AMR/redundancy frames into one RTP packet. If both parameters 'redundancy' and 'maxframes' are signaled in the capability description then 'maxframes' denotes the couple of AMR and redundancy frames as one unit, e.g. if maxframes =3D 4 and = redundancy is present then the RTP payload covers four times the couple of=20 (AMR & redundancy) frames. If only the parameter 'maxframes' is signaled then no redundancy frames are used and the number of AMR frames are denoted by the 'maxframes' parameter. There is also an option 'redundancy' to transmit also redundancy frames to help the receiver to recover from AMR frame packet losses in difficult transmission conditions. This is defined by section=20 4.3 of [10]. If this capability 'redundancy' is signalled then an RTP payload always contains at least one couple of AMR and=20 redundancy frames, whereby the redundancy frame follows the AMR frame. If the 'maxframes' parameter is signaled then the RTP payload covers maxframes time this couple. 4.2. Storage Mode =20 This mode targets applications that use stored AMR speech data, e.g. AMR speech data attached to an e-mail or AMR speech file download. The AMR frames of this mode SHALL be coded by the = following rules that are based on [10]: - the AMR speech frames is coded as defined in section 4.2.1. and 4.2.2 of [10]. - each AMR frame header SHALL contain the L-bit field. =20 In this mode the AMR speech data will be coded without the=20 particular knowledge of the receiver capabilities. Therefore the AMR speech coder SHALL expect that only the following AMR modes are supported by the receiver:=20 - all eight speech coding modes (index 0-7 of Table 1 of [10]) - AMR DTX/CN mode [7] (index 8 of Table 1 of [10]), all other DTX/CNs are not mandatory. - no-transmission mode (index 15 of Table 1 of [10]) =20 This implies that each decoder that uses this Storage Mode, SHALL at least support these 3 rules. During speech pauses AMR frames SHALL be generated containing no-transmission mode indication. In Storage Mode no Payload Block Sorting Algorithmn SHALL be = applied. Wimmer & Hammer [Page = 3] INTERNET DRAFT MIME Type Registration of AMR Speech Codec July,14 = 2000 5. MIME Registration MIME-name for the AMR codec is allocated from IETF tree since AMR is expected to be the widely used speech codec in wireless and = wirelined Internet messaging and email applications. This MIME type shall be=20 used for stored AMR data only, e.g. attachment in an email message. It may be also used by the 3G Multimedia Messaging Service (MMS) = [8]. Media Type name: audio Media subtype name: AMR Required parameters: none Optional parameters: Real-time Transport over RTP: ptime: Definition as usual in RTP audio. mode: AMR mode. Possible values are: 0,...,7 (see Table 1a [2]). mode-change-period: Defines a number N which restricts the mode changes in such a way that mode changes are only allowed on multiples of N, initial state of the phase is arbitrary. If this parameter is not present, mode change can happen at any time. mode-change-neighbor: If present, mode changes SHALL be made to neighboring modes only. If not present, change between any two modes is allowed. amr-cn: If present, GSM AMR DTX/CN is supported. Note that if no CN capabilities are reported, AMR DTX/CN is assumed to be supported, i.e. this parameter is only sent together with one of the following CN parameters. pdc-efr-cn:If present, PDC-EFR DTX/CN is supported, otherwise not supported. is-641-cn: If present, IS-641 DTX/CN is supported, otherwise not supported. gsm-efr-cn:If present, GSM EFR DTX/CN is supported, otherwise not supported. maxframes: Maximum number of AMR frames in one RTP payload packet. The receiver may set this parameter in order to limit the buffering requirements or delay. redundancy:If present, transmission of redundancy frames is supported, otherwise not supported. Storage Mode: none Encoding considerations: Please refer to section 4. Security considerations: none Interoperability considerations: none Public specification: please refer to chapter 5 "references". Wimmer & Hammer [Page = 4] INTERNET DRAFT MIME Type Registration of AMR Speech Codec July,14 = 2000 Additional information: Magic number: none File extensions: amr, AMR Macintosh file type code: none Object identifier or OID: none Personal information Bernhard Wimmer, Siemens AG Bernard Hammer, Siemens AG E-Mail: bernhard.wimmer@mch.siemens.de, bernard.hammer@icn.siemens.de Intended usage: COMMON. It is expected that many Internet=20 applications (as well as mobile applications) will use this type. Author/Change controller: bernhard.wimmer@mch.siemens.de 6. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate=20 Requirement Levels", BCP 14, RFC 2119, March 1997 [3] GSM 06.90: Adaptive Multi-Rate (AMR) Speech Transcoding [4] RCR STD-27H, Personal Digital Cellular Telecommunication System RCR Standard [5] TIA/EIA -136-Rev.A, part 410 - TDMA Cellular/PCS - Radio=20 Interface, Enhanced Full Rate Voice Codec (ACELP). Formerly IS-641. TIA published standard, 1998 [6] GSM 06.60: Enhanced Full Rate (EFR) Speech Transcoding [7] GSM 06.92: Comfort noise aspects for Adaptive Multi-Rate (AMR) speech traffic channels [8] 3G TS 23.140, "Multimedia Messaging Service (MMS)", Functional Description [9] 3G TS 26.101 (V.3.0.0) - Mandatory Speech Codec Speech=20 Processing Functions, AMR Speech Codec Frame Structure [10] IETF draft-fingscheid-avr-rtp-amr-00.txt, "RTP Payload Format=20 for AMR" Wimmer & Hammer [Page = 5] INTERNET DRAFT MIME Type Registration of AMR Speech Codec July,14 = 2000 6. Contact Person Bernhard Wimmer Siemens AG Grillparzer Street 12A 81675 Muenchen Germany Phone: +49-89-722-23247 Email: bernhard.wimmer@mch.siemens.de Bernard Hammer Siemens AG Hofmann Street 51 81000 Muenchen Germany Phone: - Email: bernard.hammer@icn.siemens.de Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES; EXPRESS OR IMPLIED; INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Wimmer & Hammer [Page = 6] ------_=_NextPart_000_01BFEDA3.58D37B10-- From rem-conf Fri Jul 14 08:07:02 2000 From rem-conf-request@es.net Fri Jul 14 08:07:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D71c-0007Bz-00; Fri, 14 Jul 2000 08:05:12 -0700 Received: from gorilla.mchh.siemens.de [194.138.158.18] by mail1.es.net with esmtp (Exim 1.81 #2) id 13D71Y-0007Bh-00; Fri, 14 Jul 2000 08:05:09 -0700 Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA15442; Fri, 14 Jul 2000 17:04:35 +0200 (MET DST) From: Bernhard.Wimmer@mch.siemens.de Received: from mchh9eea.mchh.siemens.de (mchh9eea.mchh.siemens.de [139.21.204.218]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA10715; Fri, 14 Jul 2000 17:01:59 +0200 (MET DST) Received: by mchh9eea.mchh.siemens.de with Internet Mail Service (5.5.2650.21) id <3RC462FT>; Fri, 14 Jul 2000 17:05:04 +0200 Message-ID: <910CC38345FDD211943A0008C724DD48F18161@mchg9eca.mchh.siemens.de> To: internet-drafts@ietf.org, rem-conf@es.net Cc: Bernard.Hammer@icn.siemens.de, bernhard.petri@mch.siemens.de, tim.fingscheid@mch.siemens.de, hans-peter.huth@mchp.siemens.de Subject: draft-finscheidt-avt-rtp-amr-00.txt Date: Fri, 14 Jul 2000 17:05:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFEDA4.E424F530" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 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_000_01BFEDA4.E424F530 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear I-D-manager and AVT group experts, We are submitting an Internet Draft for discussion in the AVT group. Title: MIME Type Registration of AMR Speech Codec Authors: B. Wimmer, T. Fingscheid Filename: draft-finscheidt-avt-rtp-amr-00.txt This document specifies an highly efficient way to the new RTP profile = for transmission of AMR speech frames. This draft includes the mapping of the speech to RTP payload frames, error-detection and = error-correction methods for packet loss, interleaving of payload data for future UDP methods (UDP lite) and the required signaling. These particular features can be dynamically adapted to varying channel conditions to achieve a very efficient transmission of AMR speech over IP or for AMR speech storage.=20 This draft has to be seen in combination with = for particular usage within the MIME concept. In addition to the attached version of the draft. Any comments by email are highly welcome. We are looking forward to the upcoming discussion with you at the Pittsburg' meeting. Best regards, Bernhard Wimmer <>=20 ************************************************************ Bernhard G. Wimmer Siemens AG, Grillparzerstr. 12, 81675 M=FCnchen Tel: +49-89-722-23247 Fax: +49-89-722-46489 GSM: +49-172-8688920 Email: Bernhard.Wimmer@Mch.Siemens.De PGP-key: Available on request ************************************************************ ------_=_NextPart_000_01BFEDA4.E424F530 Content-Type: text/plain; name="draft-fingscheidt-avt-rtp-amr-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-fingscheidt-avt-rtp-amr-00.txt" Internet Engineering Task Force Tim Fingscheidt, Siemens = AG Audio Video Transport WG Bernhard Wimmer, Siemens = AG INTERNET-DRAFT = Germany July 14, 2000 Expires: January 14, 2001 RTP Payload Format for AMR Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that = other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This document proposes a real-time transport protocol (RTP) [1] payload format for AMR speech encoded [2] signals. It supports all=20 8 modes of the AMR speech codec and is as well prepared for future=20 extensions, such as AMR wideband. Mode adaptation and discontinuous=20 transmission (DTX) are supported as well. =20 The proposed payload format allows large flexibility with a minimum of bitrate overhead. One or multiple speech frames can be trans- mitted in a single packet. Redundant transmission of previously=20 transmitted frames (or parts thereof) is possible as well as parity code transmission. With one speech frame per packet the additional=20 parity code transmission allows reconstruction of N previous lost speech frames when N consecutive correct packets are buffered in the receiver. This means a very high robustness while the receiver=20 buffer size can be chosen according to the application. For implementation of this draft, please consider also the requirements of [12]. Fingscheidt & Wimmer [Page = 1] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 1. Conventions used The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [11]. 2. Introduction The European Telecommunications Standards Institute (ETSI) as well as the Third Generation Partnership Project (3GPP) standardized the adaptive multi-rate (AMR) speech codec. In third generation systems the AMR codec will be mandatory. Three of the AMR modes are earlier standards like the 6.7 kbps mode (PDC-EFR [3]), the 7.4 kbps mode=20 (IS-641 codec in TDMA [4]), and the 12.2 kbps mode (GSM-EFR [5]). =20 The AMR codec comprises 8 modes with different bit rates ranging = from 4.75 to 12.2 kbps. In systems with a fixed gross bit rate like e.g. GSM, this allows assigning different amounts of error protection in order to preserve high speech quality over a wide range of channel qualities. The sampling frequency is 8 kHz, speech frames are=20 processed in 20 ms frames. The AMR modes are closely related to each other and use the same coding framework.=20 AMR implementations must support all 8 speech coding modes, and mode switching can occur to any mode at any speech frame boundary. The=20 mode information must therefore be transmitted together with the=20 speech encoded bits to indicate the mode. Furthermore, the decoder=20 may give an indication to the encoder of what mode it prefers to=20 receive. This is called a codec mode request (CMR) and is useful to adjust the ratio of speech coder bits to error protection bits in=20 order to ensure a certain speech quality. =20 Along with the AMR codec, voice activity detection (VAD) and comfort noise generation (CNG) have been standardized. This allows a reduction of the number of transmitted bits in silence periods. The three earlier codec standards [3-5] however have different=20 DTX/VAD/CNG schemes if they are not used in the AMR framework. For=20 Interoperability reasons the proposed payload format supports also=20 these CNG formats. =20 To address the transmission over networks with high packet loss rates extra redundancy is built into the RTP payload format for AMR This is done in a very flexible manner by the optional transmission of parity bit blocks generated from previously transmitted AMR=20 encoded frames. Dependent on how many previous frames are covered=20 by this parity bit computation, a certain number of consecutive past lost frames can be reconstructed at the receiver. Since this may require buffering, the AMR payload format allows flexible=20 tradeoff between robustness, bit rate, and receiver delay. =20 The speech encoded bits have different perceptual sensitivity to bit errors. Accordingly, unequal error protection (UEP) is employed in cellular systems. A frame is considered as lost or damaged if=20 errors are detected in the most sensitive bits. Unequal error=20 detection (UED) can also be employed on RTP if e.g. UDP lite is used as transport layer protocol (UDP lite [6] is work in progress). The Fingscheidt & Wimmer [Page = 2] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 payload then has to be ordered in sensitivity order. The sensitivity order for the AMR encoded bits are defined in [7]. The different=20 sensitivity can also be exploited by a parity check covering only=20 the most sensitive bits, as is proposed as an option for the AMR=20 payload format. =20 To improve quality in circuit-switched GSM networks connected to=20 IP networks also frames disturbed on the wireless GSM link should=20 be transmitted to the decoder in the IP network. Consequently, such frames must be accompanied by a frame quality information in the=20 IP network.=20 This proposal of an RTP payload format for AMR is the third in a=20 series of internet drafts (works in progress) related to this topic. In [8] the transmission of multiple speech frames in a single RTP packet is supported. The advantage of [9] as compared to [8] is mainly the possibility to transmit redundant speech frames (or=20 parts thereof). =20 The present proposal incorporates the abilities of [8,9] with the addition that there is an option for reconstruction of a larger=20 number of past lost frames. For the purpose of clarity and simpler comparison, in the sequel we will follow the structure and the notation of [9] as far as possible. 3. Requirements The AMR payload format for RTP was designed to meet the following requirements: o Different levels of robustness must be supported: - no redundancy at all - past frames (partly) repeated - parity bits generated over several past frames to yield extreme robustness capable of handling very high packet loss rates with = no or small speech quality degradation. o Fast, frame-wise AMR mode adaptation must be supported. This means that it must be possible to send codec mode requests (CMRs) = back from the receiving side to the transmitting side with=20 information on the preferred mode. Slower AMR mode adaptation may also be accomplished with external signaling. o Discontinuous transmission (DTX) and comfort noise generation (CNG) as specified in AMR must be supported. 4. RTP Payload Format Specification This RTP payload format is designed to be flexible, ranging from very low overhead (minimal) to an extended format with room for future AMR extensions, e.g. wide band modes, and the possibility to send extra redundancy information and several speech frames in one RTP payload packet. Fingscheidt & Wimmer [Page = 3] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 Each RTP payload consists of an - RTP payload header followed by the=20 - RTP payload data. =20 The RTP payload data is generated by the interleaving of one or=20 several RTP payload frames, see section 4.4. An RTP payload frame may be generated from - AMR frames or=20 - redundancy frames.=20 Each RTP payload frame must not be octet-aligned, however the RTP payload shall be octet-aligned. If the last octet of an RTP payload covers unused bits, these bits shall be set to zero. 4.1. The RTP Payload Header The payload header has dynamic length, 3 or 8 bits. The bits in the=20 Header are specified as follows: Q (1 bit): The payload quality bit indicates, if not set, that the=20 Payload is severely damaged and the receiver should set the RX_TYPE, see [10], to SPEECH_BAD or SID_BAD depending on the frame type (FT). I (1 bit): If I=3D1, it indicates the existence LEN/DEPTH indicator bit (L) in each RTP payload frame. If I=3D0 the LEN/DEPTH indicator = do not exist. R (1 bit): Indicates if the codec mode request (CMR) is sent or not. CMR (5 bits): OPTIONAL field, depending on the R bit. Requested codec mode for the other communication direction. The interpretation is equal to the FT field, see Table 1. 0 0 1 2 +-+-+-+ |Q|I|R| +-+-+-+ Figure 1: RTP payload header, R=3D0 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |Q|I|R| CMR | +-+-+-+-+-+-+-+-+ Figure 2: RTP payload header, R=3D1 Fingscheidt & Wimmer [Page = 4] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 4.2. RTP Payload AMR Frame The RTP payload AMR frame is designed for covering AMR encoded=20 speech data and is generated by=20 - AMR frame header that is followed by the - AMR frame payload. The AMR frame must not be octet-aligned.=20 =20 4.2.1. AMR Frame Header Format Each AMR frame header includes several specified fields as follows: F (1 bit): Indicates if this frame is followed by further frames. F=3D1 further frames follow, F=3D0 last frame. =20 L (1 bit): (OPTIONAL) If the RTP payload header bit I=3D1 this field = exists. If I=3D0 this field is not existing. If set to L=3D1 the AMR frame header includes the LEN field. If L=3D0 no LEN field exists in this AMR frame header. FT (5 bits): Frame type indicator, indicating the AMR speech coding mode or comfort noise (CN) mode. The mapping of existing AMR modes is given in Table 1. This implies that the number of bits of the AMR frame payload can be derived from Table 1. If FT=3D15 (No=20 transmission) L for both AMR and redundancy frames SHOULD be set=20 to 0. LEN (7 bits): OPTIONAL field, exists if the AMR header bit L is set, L=3D1. LEN specifies the number of octets in the current AMR frame payload. The following situations may occur and shall be treated as=20 follows: =20 - If LEN*8 <=3D number of speech bits indicated by FT, as shown in=20 Table. 1, the number of bits of the AMR frame payload shall be derived by=20 8*LEN and not by the FT field. This implies that the encoded AMR data was shortend to 8*LEN. - otherwise the LEN field SHOULD be ignored. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|L| FT | LEN | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + / AMR frame payload / / / + +-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: AMR frame format, I=3D1 and L=3D1 =20 Fingscheidt & Wimmer [Page = 5] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|L| FT | | +-+-+-+-+-+-+-+ + | | + + / AMR frame payload / / / + +-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: AMR frame format, I=3D1 and L=3D0 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| FT | | +-+-+-+-+-+-+ + | | + + / AMR frame payload / + +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: AMR frame format, I=3D0 4.2.2. AMR Frame Payload Format The AMR speech encoder produces AMR speech frames, as defined by = [2]. The currently defined AMR speech frame types can be found in Table = 1.=20 =20 speech Index Mode bits ---------------------------------- 0 AMR 4.75 95 1 AMR 5.15 103 2 AMR 5.9 118 3 AMR 6.7 134 4 AMR 7.4 148 5 AMR 7.95 159 6 AMR 10.2 204 7 AMR 12.2 244 8 AMR CNG 39 9 GSM EFR CNG 43 10 IS-641 CNG 38 11 PDC-EFR CNG 37 12 - 14 For future use - 15 No transmission 0 16 - 31 For future use - Table 1: AMR speech frame types (taken from [9]) Fingscheidt & Wimmer [Page = 6] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 The bit order of frame type 0 - 11 is given in [7]. Frame type 15,=20 no transmission, is needed to indicate not transmitted frames or lost frames, e.g. when multiple frames are sent in each payload=20 and comfort noise starts. A frame type sequence in a payload with 8 frames, AMR mode 7, and CNG starts in the fifth frame, could look like: {7,7,7,7,8,15,15,8}. The AMR DTX (also called "source con- trolled rate operation", SCR) is described in [10]. Another reason for the no transmission frame type is a possible need to send an urgent codec mode request in a silence period with comfort noise. =20 Before the AMR encoded speech frames are copied to the AMR frame payload the speech bits shall be ordered to the descending bit-error sensitivity. This re-ordering process is defined in [7]. =20 After this re-ordering process the AMR encoded speech frame is=20 copied to the AMR frame payload, according to the particular=20 setting of the AMR frame header, e.g. copying of the first 8*LEN=20 bits, see section 4.2.1. 4.3. RTP Payload - Redundancy Frame The RTP payload redundancy frame is designed for covering redundancy data for error-correction of lost AMR frames. The redundancy frame=20 is generated by=20 - redundancy frame header that is followed by the - redundancy frame payload. The redundancy frame must not be octet-aligned.=20 =20 =20 4.3.1. Redundancy Frame Header Format Each redundancy frame header includes several specified fields as=20 follows: F (1 bit): Indicates if this frame is followed by further frames.=20 F=3D1 further frames follow, F=3D0 last frame. =20 L (1 bit): (OPTIONAL) If the RTP payload header bit I=3D1 this field exists. If I=3D0 this field is not existing. If set to L=3D1 the=20 redundancy frame header includes the LEN field. If L=3D0 no R_LEN=20 field exists in this redundancy frame header. R_FT (5 bits): This field indicates the FT-fields of the past DEPTH AMR frame headers by the following coding rule. R_FT(n) =3D FT(n-1) EXOR ... EXOR FT(n-DEPTH(n)) (Eq. 1) whereby n is set to the current AMR frame number. FT(n) is defined as the AMR frame header field FT of=20 frame n. R_FT(n) denotes the redundancy frame header field R_FT of=20 frame n. EXOR is defined as the bit-wise exclusive OR operation. DEPTH(n) denotes the redundancy frame header field DEPTH of=20 frame n. Fingscheidt & Wimmer [Page = 7] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 R_LEN (7 bits): OPTIONAL field, exists if the redundancy header=20 bit L is set, L=3D1. R_LEN specifies the number of octets in the=20 current redundancy frame payload. Depending on R_LEN several=20 different operational modes are used that will be described in=20 section 4.3.2. R_LEN may be changed from redundancy frame to=20 redundancy frame. If L=3D0 or/and I=3D0, R_LEN(n) is set to FT(n),=20 whereby n denotes the current AMR frame number. DEPTH (4 bits): OPTIONAL field, exists if the redundancy header=20 bit L is set, L=3D1. DEPTH specifies the number of previous AMR = frame payload pakets that are used for the generation of the redundancy frame payload. The detailed description can be found in section 4.3.2. DEPTH =3D 0 is currently unused and may be used for future extension. If L=3D0 or/and I=3D0 then DEPTH is set to the default=20 value 15. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|L| R_FT | R_LEN | DEPTH | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + / redundancy frame payload / / / + +-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Redundancy frame format, I=3D1 and L=3D1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|L| R_FT | | +-+-+-+-+-+-+-+ + | | + + / redundancy frame payload / / / + +-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Redundancy frame format, I=3D1 and L=3D0 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| R_FT | | +-+-+-+-+-+-+ + | | + + / redundancy frame payload / + +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Redundancy frame format, I=3D0 Fingscheidt & Wimmer [Page = 8] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 4.3.2. Redundancy Frame Payload Format The generation of the redundancy payload is based on parity bit=20 calculation of one or several previous AMR frame payload pakets. This number of AMR frames is determined by the redundancy frame header field DEPTH. The general rules for generating of the parity bits can be found in section 4.3.3. The value of R_LEN can in principle be changed during transmission. Let's assume R_LEN changes from R_LEN1 to R_LEN2, with DEPTH being constant. In that case for a number of DEPTH AMR frame packets only=20 min(R_LEN1,R_LEN2) AMR frame payload bits can be reconstructed.=20 Although adaptation of R_LEN for redundancy frames works seamlessly, it is RECOMMENDED not to perform such an adaptation on a=20 frame-by-frame basis. =20 The value of DEPTH can also be adapted during transmission. Let's=20 assume DEPTH changes from DEPTH1 to DEPTH2. It is RECOMMENDED to=20 choose a maximum value of DEPTH dependent on the application=20 (e.g. streaming services: large DEPTH, VoIP: low DEPTH) and to adapt it only on a long term basis, since reconstruction capabilities are reduced in transition regions for a number of min(DEPTH1,DEPTH2)=20 AMR frames. 4.3.3. Encoding Rules for the Parity Bits This section describes the encoding rules for the parity bits. Notation: n : number of the current AMR frame; n is increased for each sent AMR frame packet. n denotes also the current=20 redundancy frame number. o : number of AMR frame that covers less AMR frame payload=20 bits than required by current redundancy frame header field R_LEN(n) > LEN(o). g(n,m) : bit m in the AMR frame payload of frame n p(n,m) : bit m in the redundancy frame payload of frame n XOR : exclusive OR operation R_LEN(n) : denotes the R_LEN field of the redundancy frame header of = frame n The parity bits SHALL be calculated by the following equation: =20 p(n,m) =3D g(n-1,m) EXOR ... EXOR g(n-DEPTH+1, m) EXOR g(n-DEPTH, = m)=20 (eq.2) for m =3D 0 ... R_LEN(n)-1; =20 Eq. 2 requires that all LEN(i) with i =3D (1, ... , DEPTH) of the = AMR frames are at least as large as R_LEN(n). In the event that this is not valid the missing AMR frame payload bits SHALL be virtually=20 generated by the following rule. Fingscheidt & Wimmer [Page = 9] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 if (o =3D n-DEPTH) =20 g(o, LEN(o)+i) =3D 0, for i=3D0...(R_LEN(n)-LEN(o)-1); =20 else =20 if (R_LEN(n)-LEN(o) <=3D LEN(o-1)) g(o, LEN(o)+i) =3D g(o-1, i), for = i=3D0...(R_LEN(n)-LEN(o)-1); =20 else { =20 g(o, LEN(o)+i) =3D g(o-1, i), for i =3D 0 ... (LEN(o-1)-1); g(o, LEN(o)+LEN(o-1)+i) =3D 0,=20 for i =3D 0 ... (R_LEN(n)-LEN(o)-LEN(o-1)-1);=20 } This rule implies that virtuell data SHALL be copied from the most sensitive bits of the previous AMR frame payload of the AMR frame o. However if the previous AMR frame number (o-1) is outside the window defined by the DEPTH parameter of the current redundancy frame the virtual data is set to 0. In the case that the AMR frame payload=20 (o-1) contains less bits than required to achieve all virtual bits of AMR frame payload (o) then first all AMR frame payload bits of (o-1) SHALL be taken and then the missing virtual bits of AMR frame payload (o) SHALL be set to 0. Example: In this example, see Figure 9, it can be seen that the AMR frame=20 payload contains not enough bits. Therefore the most sensitive bits of AMR frame payload (n-3) are virtually appended to AMR frame pay- load (n-2) until the desired length is reached.=20 time: n-3 n-2 n-1 n =20 +----------+ +-----------+ +----------+ +--------+ | |- XOR -| g(n-2,m), |- XOR -| | =3D | | | g(n-3,m) |- XOR -| fill with |- XOR -| g(n-1,m) | =3D | p(n,m) | | |- XOR -| g(n-3,m) |- XOR -| | =3D | | +----------+ +-----------+ +----------+ +--------+ =20 Figure 9: Example of parity bit generation for p(n,m) with DEPTH=3D3 = and the number of AMR frame payload bits in frame n-2 being smaller=20 than 8*R_LEN(n).=20 =20 4.3.4. Decoding of Redundancy Frame Payload Decoding of these parity codes is intended in the following manner. Imagine one frame of AMR encoded bits and one parity bit block per frame. Every value of DEPTH >=3D 1 allows the reconstruction of a=20 single lost frame among the last DEPTH frames. DEPTH =3D 2 allows = the reconstruction of two consecutive lost frames, once two good frames are received. In general, a number of DEPTH buffered packets allows for the reconstruction of a number of DEPTH lost frames preceding them. The set of equations given by the XOR operations is solved at Fingscheidt & Wimmer [Page = 10] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 first for the last (!) lost frame (unknowns), using the DEPTH=20 buffered frames as knowns. Then everything is solved for the last=20 but first lost frame, taking into account the already reconstructed last lost frame's bits. And so forth. Here the tremenduous strength of using parity codes instead of frame repetition becomes obvious: Especially for streaming applications a large value of DEPTH allows to reconstruct error bursts of the same large number of DEPTH consecutive frames. =20 4.3.5. Implications for DTX and the choice of DEPTH For delay reasons it is not advisable to store a large number (DEPTH) of CNG frames in the receiver buffer before previous lost CNG AMR frames or AMR frame payload packets, containing speech data, can be reconstructed.=20 Thus the follwing rules SHALL apply: o Starting with the second AMR frame containing one/several CNG=20 frames, DEPTH SHALL be set maximally to 1 for all consecutive redundancy frames containing CNG AMR frames. o In the first and the second AMR frame containing no CNG after a=20 speech pause, DEPTH SHALL be set maximally to 1. These rules allow optimal recovery of lost AMR frames in DTX=20 operation, while keeping delay at a minimum. =20 4.4. Payload Block Sorting In general a bit error in a more sensitive bit is subjectively more annoying than in a less sensitive bit. To be able to protect the most sensitive bits in a AMR and redundancy frames with a forward error detection code, e.g. a CRC outside RTP, the full RTP payload data MUST be sorted in sensitivity order. The protection MAY then cover an appropriate=20 number of octets from the beginning of the AMR and/or redundancy frames. How many octets depends on the channel and application. This can for example be accomplished by UDP lite [6] (work in=20 progress). To maintain sensitivity ordering inside the AMR payload when more than one speech frame is transmitted in one packet reordering of the data is needed. The reordering to maintain the sensitivity ordered AMR payload SHALL be performed on bit level. The AMR payload header SHALL still be placed unchanged in the beginning of the payload. Thereafter, the payload frames are sorted with one bit alternating from each payload frame. Fingscheidt & Wimmer [Page = 11] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 +-------------+ | h(0)-h(H-1) | +------------------------+ | f(0,0) _ f(0,F(0)) | +----------------------------+ | f(1,0) _ f(1,F(1)) | +----------------------------+ | f(2,0) _ f(2,F(2)) | +----------------------+ \ \ +-------------------------------+ | f(N-1,0) _ f(N-1,F(N-1)) | +-------------------------------+ Figure 10: The payload header and N AMR/redundancy frames before=20 sorting. The sorting algorithm can be described in C-code. b(m) : bit m of RTP final payload f(n,m) : bit m in AMR/redundancy frame payload of frame n F(n) : number of bits in AMR/redundancy frame n, defined by FT or by LEN/R_LEN h(m) : bit m of RTP payload header H : number of RTP payload header bits, 3 or 8 bits N : number of AMR/redundancy frames in the RTP payload S : number of unused bits Payload frames f(n,m) are ordered in consecutive order, where frame n=3D1 is preceding frame n=3D2. The sorting algorithm is defined in C-style as: for (i =3D 0; i < H; i++) b(i) =3D h(i); max =3D max(F(0),..,F(N-1)); k =3D H; for (i =3D 0; i < max; i++){ for (j =3D 0; j < N; j++){ if (i < F(j)){ b(k++) =3D f(j,i); } } } S =3D 8 - k%8; if (S < 8){ for (i =3D 0; i < S; i++) b(k++) =3D 0; } Fingscheidt & Wimmer [Page = 12] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 5. RTP header usage The RTP header marker bit (M) is used to mark (M=3D1) the packages containing the first speech frame after CN. In all other packages the marker bit is set to 0 (M=3D0). The time-stamp corresponds to the sampling time of the first sample encoded for the first encoded speech frame in the AMR frame. The timestamp unit is in samples, i.e. one AMR speech frame is 20 ms=20 and sampling frequency is 8 kHz corresponds to 160 encoded speech samples per frame, i.e. the timestamp is increased by 160 for each AMR speech consecutive frame.=20 Due to DTX functionality each RTP packet SHALL contain the appropriate time-stamp of the first AMR frame, covered by the RTP payload. Each AMR frame containg CNG data or the first AMR frame containing speech data after CNG SHALL start with a new RTP packet. This is required to achieve the correct timing information. Please consider also [12] for setting of particular parameters. 6. Examples 6.1. Simple example In the simple example we just send one full (I=3D0) frame in each = RTP packet, no codec mode request CMR is sent (R=3D0), the payload was = not damaged at IP origin (Q=3D1). In this example we transmit one frame encoded with the 5.9 kbps mode (FT=3D2). The speech encoded bits are put into f(0) to f(117) in descending sensitivity order according to [7]. | Bit no. = | Oct.| 0 1 2 3 4 5 6 7 = | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 0 | Q=3D1 | I=3D0 | R=3D0 | F=3D0 | 0 | 0 | 0 = | 1 | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 1 | 0 | f(0) | f(1) | f(2) | ... | ... | ... | ... = | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 16 | ... | ... | ... | ... | f(115)| f(116)| f(117)| 0 = | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ Figure 11: One frame per packet example. 6.2. Example with parity bits In this example a AMR frame with 6.7 kbps mode (FT=3D3) is sent with one redundancy frame packet. =20 - The RTP payload header is set to Q=3D1, I=3D1, R=3D1 and CMR =3D = 6. A mode=20 request is sent(R=3D1), requesting the 10.2 kbps mode for the = other link (CMR=3D6). - The AMR frame header uses F=3D1, L=3D0 (this implies NO LEN field) = and FT =3D 3. The AMR frame header is followed by the AMR frame = payload, denoted by f(0) to f(133). Fingscheidt & Wimmer [Page = 13] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 - The redundancy frame header is set to=20 - F =3D 0 (no following frames), - L =3D 1 (R_LEN and DEPTH exist) - R_FT =3D 3 (the 3 previous AMR frame header fields FT were 3), = - R_LEN =3D 2 (number of redundancy frame payload bits =3D 2*8 = =3D 16) - DEPTH =3D 3 (the 3 previous AMR frame payload packets are = taken=20 for redundancy frame payload calculation) The redundancy frame paylaod covers 16 bits and is denoted by the value r(.). | Bit no. = | Oct.| 0 1 2 3 4 5 6 7 = | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 0 | Q=3D1 | I=3D1 | R=3D1 | 0 | 0 | 1 | 1 | = 0 | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 1 | F=3D1 | F=3D0 | L=3D0 | L=3D1 | 0 | 0 | 0 = | 0 | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 2 | 0 | 0 | 1 | 1 | 1 | 1 | f(0) | 0 = | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 3 | f(1) | 0 | f(2) | 0 | f(3) | 0 | f(4) | 0 = | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 4 | f(5) | 1 | f(6) | 0 | f(7) | 0 | f(8) | 0 = | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 5 | f(9) | 1 | f(10) | 1 | f(11) | r(0) | f(12) | r(1) = | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 6 | f(13) | r(2) | f(14) | r(3) | ... | ... | ... | ... = |=20 = ----+-------+-------+-------+-------+-------+-------+-------+-------+ .. | ... | ... | ... | ... | ... | ... | ... | ... = | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 9 | ... | ... | ... | r(15) | f(27) | r(16) | f(28) | f(29) = | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ .. | ... | ... | ... | ... | ... | ... | ... | ... = | = ----+-------+-------+-------+-------+-------+-------+-------+-------+ 33 | ... | ... | ... | ... | f(130)| f(131)| f(132)| = f(133)| = ----+-------+-------+-------+-------+-------+-------+-------+-------+ Figure 12: Example with 1 AMR frame and 1 redundancy frame Fingscheidt & Wimmer [Page = 14] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 7. References [1] IETF RFC1889, "RTP: A Transport Protocol for Real-Time Applications" [2] GSM 06.90, "Adaptive Multi-Rate (AMR) speech transcoding" [3] ARIB, RCR STD-27H, Section 5.4, "ACELP Speech CODEC" [4] TIA/EIA IS-641-A, "TDMA Cellular/PCS _Radio interface, Enhanced Full-Rate Voice Codec" =20 [5] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding" [6] IETF draft-larzon-udplite-02.txt, "The UDP Lite Protocol" [7] 3G TS 26.101, "AMR Speech Codec Frame Structure" =20 [8] IETF draft-lakaniemi-avt-rtp-amr-00.txt, "RTP Payload Format=20 for AMR" [9] IETF draft-sjoberg-avt-rtp-amr-00.txt, "RTP payload format=20 for AMR" =20 [10] 3G TS 26.093, "AMR Speech Codec; Source Controlled Rate=20 Operation" [11] RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels" [12] IETF draft-wimmer-amr-01.txt, "MIME Type Registration for AMR Speech Codec" =20 8. Authors' addresses Tim Fingscheidt Siemens AG, ICP CD Grillparzerstrasse 10-18 D - 81675 Munich Germany Phone: ++49 89 722 57658 Fax: ++49 89 722 46489 E-mail: Tim.Fingscheidt@mch.siemens.de Bernhard Wimmer (contact person) Siemens AG, ICP CD Grillparzerstrasse 10-18 D - 81675 Munich Germany Phone: ++49 89 722 23247 Fax: ++49 89 722 46489 E-mail: Bernhard.Wimmer@mch.siemens.de This Internet-Draft expires January, 14, 2001. Fingscheidt & Wimmer [Page = 15] INTERNET-DRAFT RTP Payload Format for AMR July 14, = 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES; EXPRESS OR IMPLIED; INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Fingscheidt & Wimmer [Page = 16] ------_=_NextPart_000_01BFEDA4.E424F530-- From rem-conf Fri Jul 14 09:18:03 2000 From rem-conf-request@es.net Fri Jul 14 09:18:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D87T-0003Ol-00; Fri, 14 Jul 2000 09:15:19 -0700 Received: from relay.eecs.berkeley.edu [169.229.34.228] by mail1.es.net with esmtp (Exim 1.81 #2) id 13D87S-0003Ob-00; Fri, 14 Jul 2000 09:15:18 -0700 Received: from huginn.CS.Berkeley.EDU (huginn.CS.Berkeley.EDU [169.229.60.60]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id JAA18904; Fri, 14 Jul 2000 09:15:18 -0700 (PDT) Received: from fielder (1Cust250.tnt8.sfo3.da.uu.net [63.23.23.250]) by huginn.CS.Berkeley.EDU (8.9.1a/8.9.1) with SMTP id JAA06768; Fri, 14 Jul 2000 09:16:00 -0700 (PDT) Date: Mon, 14 Aug 2000 09:19:06 -0700 From: Koichi Yano To: "Dr. Injong Rhee" Cc: rem-conf@es.net Subject: Re: low delay RTCP In-Reply-To: <10007140946.ZM9261@unity.ncsu.edu> References: <10007140946.ZM9261@unity.ncsu.edu> Reply-To: yano@EECS.Berkeley.EDU Message-Id: <39981BFA37A.9601YANO@pop.cs.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.25.06 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Injong and Fukunaga-san, We have already presented RTCP retransmission request profile for unicast session at former IETF meetings and got agreement as a work item of AVT WG. I will submit a revised draft today. (draft-ietf-avt-rtprx-00.txt) I believe, all concerns about feedback (I mean low delay) are the same as this case, although our proposal focus on retransmission. I think we can realize FIR or NEWPRED messages on top of our proposal (RTCP_NACK). 1) You can use a payload specific field of RTCP_NACK for these. Anyways, you should send NACKs when packet loss is detected for the congestion control use. So send these messages in tandem with NACK packet since these messages are necessary in the case where loss is detected. 2) Or new RTCP packet types are defined for these. (the profile needs to be changed) Koichi On Fri, 14 Jul 2000 09:46:50 -0400 "Dr. Injong Rhee" wrote: > Fukunaga San, > > > As you indicated, FIR and NEWPRED can work on small multicast > > group. I agree with your investigation. > > Count in retransmission as well. It seems that retransmission and FEC are > natural for unicast and multicast. > > Retransmission and FEC can be made > scalable even for large multicast group with appropriate feedback > suppression or local recovery shcemes (On the other hand, > NEWPRED and FIR seem inherently limited in large multicast groups > because the encoder must adapt to each recver's loss > patterns). For instance, retransmission with some hierarchical > struture for local recovery as discussed in IETF-RMT group would also scale > fairly well for a large group. FEC, of course, is scalable for any > group size as it does not need as much feedback as other recovery > schemes being proposed. > > > > > On the other hand, the performances of these tools also strongly depend > > on the delay, because the delay leads the slow error recovery, In this case, > > the degraded pictures are displayed for long time, or the video is freezed. > > > > If possible, I would like to realize both small multicast and low delay. > > However it seems not possible because of the flood of backward messages. > > > > Therefore we have to select one from 2 items. > > You selected the small multcast and not low delay. While I selected the > > low delay on unicast. As our 2 types of selection have some reasons > > respectively, it seems not easy to marge 2 drafts. > > I think it is not so good these 2 types of rule are defined in one profile. > > > > I believe that FIR and NEWPRED (retransmission for that matter) are not > incompatible as far as feedback is concerned. They all require low delay > RTCP and can work for small multicast. They can even work together; FIR > can be very useful when NEWPRED fails (which happens when recver or > sender frame buffer runs out). > > > I think there are following alternatives: > > 1. You or I will change one's mind and integrate to one profile. > > 2. 2 profiles will be defined for 2 ruls respectively. > > 3. We will find good reason (condition) to be compatible both small > > multicast and low delay. > > 4. 2 types of rule will be defined in one profile. > > > > I think 3 or 4 would be a good option as it seems consistent with the > general sentiment of this group -- am I wrong? :-) > > Thanks > Injong > > > -- > Injong Rhee, Department of Computer Science > North Carolina State University, Raleigh, NC 27695 > Home page: http://www.csc.ncsu.edu/faculty/rhee > Email: rhee@csc.ncsu.edu, Phone: 919-515-3305, Fax: 919-515-7925 > > > From rem-conf Fri Jul 14 09:56:45 2000 From rem-conf-request@es.net Fri Jul 14 09:56:44 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D8ij-0006N6-00; Fri, 14 Jul 2000 09:53:49 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 13D8ig-0006MY-00; Fri, 14 Jul 2000 09:53:46 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Jul 2000 17:53:25 +0100 From: Orion Hodson Reply-To: Orion Hodson X-Organisation: University College London, CS Dept. X-Phone: +44 (0)20 7679 3704 To: Bernhard.Wimmer@mch.siemens.de cc: rem-conf@es.net, tim.fingscheid@mch.siemens.de Subject: Re: draft-finscheidt-avt-rtp-amr-00.txt In-reply-to: Your message of "Fri, 14 Jul 2000 17:05:04 +0200." <910CC38345FDD211943A0008C724DD48F18161@mchg9eca.mchh.siemens.de> Date: Fri, 14 Jul 2000 17:53:25 +0100 Message-ID: <10817.963593605@cs.ucl.ac.uk> Sender: O.Hodson@cs.ucl.ac.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Quick comments: 1) Have you considered the use of generic FEC (RFC2733) and redundant audio (RFC2198) rather than putting parity FEC directly into the media stream? This might simplify your design, provide greater flexibility in choice of FEC scheme, and might make implementation easier. 2) Is document [10] available to AVT group? My reading of R and CMR (sec 4.1.) is that they exist for signalling the codec used by the opposite direction? Can you clarify the motivation? Most RTP audio tools only concern themselves with this when the packets arrive. 3) The F bit (sec 4.2.1) signifies follow on frames. Is this follow on frames within this packet or in the stream/talkspurt? 4) Spelling virtuell -> virtual. Open question for the group: This draft includes bit sorting for the codec. With uneven level protection (ULP) now a draft is it worth considering methods for specifying bit re-arrangements so codecs that weren't designed with bit-error sensitivity in mind might benefit from ULP? Maybe an end-system filter language, where these shuffling operations could be succinctly described... Kind Regards - Orion Bernhard.Wimmer@mch.siemens.de writes: > 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_000_01BFEDA4.E424F530 > Content-Type: text/plain; > charset="ISO-8859-1" > Content-Transfer-Encoding: quoted-printable > > Dear I-D-manager and AVT group experts, > > We are submitting an Internet Draft for discussion in the AVT group. > > Title: MIME Type Registration of AMR Speech Codec > Authors: B. Wimmer, T. Fingscheid > Filename: draft-finscheidt-avt-rtp-amr-00.txt > > This document specifies an highly efficient way to the new RTP profile = > for > transmission of AMR speech frames. This draft includes the mapping > of the speech to RTP payload frames, error-detection and = > error-correction > methods for packet loss, interleaving of payload data for future > UDP methods (UDP lite) and the required signaling. These particular > features can be dynamically adapted to varying channel conditions to > achieve a very efficient transmission of AMR speech over IP or for > AMR speech storage.=20 > This draft has to be seen in combination with = > > for particular usage within the MIME concept. > > In addition to the attached version of the draft. > > Any comments by email are highly welcome. We are looking forward to the > upcoming discussion with you at the Pittsburg' meeting. > > > Best regards, > Bernhard Wimmer > > <>=20 > ************************************************************ > Bernhard G. Wimmer > Siemens AG, Grillparzerstr. 12, 81675 M=FCnchen > Tel: +49-89-722-23247 > Fax: +49-89-722-46489 > GSM: +49-172-8688920 > Email: Bernhard.Wimmer@Mch.Siemens.De > PGP-key: Available on request > ************************************************************ > > > > > ------_=_NextPart_000_01BFEDA4.E424F530 > Content-Type: text/plain; > name="draft-fingscheidt-avt-rtp-amr-00.txt" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: attachment; > filename="draft-fingscheidt-avt-rtp-amr-00.txt" > > Internet Engineering Task Force Tim Fingscheidt, Siemens = > AG > Audio Video Transport WG Bernhard Wimmer, Siemens = > AG > INTERNET-DRAFT = > Germany > July 14, 2000 > Expires: January 14, 2001 > > > > RTP Payload Format for AMR > > > > Status of this memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that = > other > groups may also distribute working documents as Internet-Drafts. > Internet-Drafts are draft documents valid for a maximum of six = > months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or cite them other than as "work in progress". > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/lid-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html > > This document is an individual submission to the IETF. Comments > should be directed to the authors. > > > Abstract > > This document proposes a real-time transport protocol (RTP) [1] > payload format for AMR speech encoded [2] signals. It supports all=20 > 8 modes of the AMR speech codec and is as well prepared for future=20 > extensions, such as AMR wideband. Mode adaptation and discontinuous=20 > transmission (DTX) are supported as well. > =20 > The proposed payload format allows large flexibility with a minimum > of bitrate overhead. One or multiple speech frames can be trans- > mitted in a single packet. Redundant transmission of previously=20 > transmitted frames (or parts thereof) is possible as well as parity > code transmission. With one speech frame per packet the additional=20 > parity code transmission allows reconstruction of N previous lost > speech frames when N consecutive correct packets are buffered in the > receiver. This means a very high robustness while the receiver=20 > buffer size can be chosen according to the application. > > For implementation of this draft, please consider also the > requirements of [12]. > > > > > > > > Fingscheidt & Wimmer [Page = > 1] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > 1. Conventions used > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC2119 [11]. > > > 2. Introduction > > The European Telecommunications Standards Institute (ETSI) as well > as the Third Generation Partnership Project (3GPP) standardized the > adaptive multi-rate (AMR) speech codec. In third generation systems > the AMR codec will be mandatory. Three of the AMR modes are earlier > standards like the 6.7 kbps mode (PDC-EFR [3]), the 7.4 kbps mode=20 (IS-641 codec in TDMA [4]), and the 12.2 kbps mode (GSM-EFR [5]). > =20 > The AMR codec comprises 8 modes with different bit rates ranging = > from > 4.75 to 12.2 kbps. In systems with a fixed gross bit rate like e.g. > GSM, this allows assigning different amounts of error protection in > order to preserve high speech quality over a wide range of channel > qualities. The sampling frequency is 8 kHz, speech frames are=20 > processed in 20 ms frames. The AMR modes are closely related to each > other and use the same coding framework.=20 > > AMR implementations must support all 8 speech coding modes, and mode > switching can occur to any mode at any speech frame boundary. The=20 > mode information must therefore be transmitted together with the=20 > speech encoded bits to indicate the mode. Furthermore, the decoder=20 > may give an indication to the encoder of what mode it prefers to=20 > receive. This is called a codec mode request (CMR) and is useful to > adjust the ratio of speech coder bits toerror protection bits in=20 > order to ensure a certain speech quality. > =20 > Along with the AMR codec, voice activity detection (VAD) and > comfort noise generation (CNG) have been standardized. This allows a > reduction of the number of transmitted bits in silence periods. > The three earlier codec standards [3-5] however have different=20 > DTX/VAD/CNG schemes if they are not used in the AMR framework. For=20 > Interoperability reasons the proposed payload format supports also=20 > these CNG formats. > =20 > To address the transmission over networks with high packet loss > rates extra redundancy is built into the RTP payload format for AMR > This is done in a very flexible manner by the optional transmission > of parity bit blocks generated from previously transmitted AMR=20 > encoded frames. Dependent on how many previous frames are covered=20 > by this parity bit computation, a certain number of consecutive > past lost frames can be reconstructed at the receiver. Since this > may require buffering, the AMR payload format allows flexible=20 > tradeoff between robustness, bit rate, and receiver delay. > =20 > The speech encoded bits have different perceptual sensitivity to bit > errors. Accordingly, unequal error protection (UEP) is employed in > cellular systems. A frame is considered as lost or damaged if=20 > errors are detected in the most sensitive bits. Unequal error=20 > detection (UED) can also be employed on RTP if e.g. UDP lite is used > as transport layer protocol (UDP lite [6] is work in progress). The > > > Fingscheidt & Wimmer [Page = > 2] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > payload then has to be ordered in sensitivity order. The sensitivity > order for the AMR encoded bits are defined in [7]. The different=20 > sensitivity can also be exploited by a parity check covering only=20 > the most sensitive bits, as is proposed as an option for the AMR=20 > payload format. > =20 > To improve quality in circuit-switched GSM networks connected to=20 > IP networks also frames disturbed on the wireless GSM link should=20 > be transmitted to the decoder in the IP network. Consequently, such > frames must be accompanied by a frame quality information in the=20 > IP network.=20 > > This proposal of an RTP payload format for AMR is the third in a=20 > series of internet drafts (works in progress) related to this topic. > In [8] the transmission of multiple speech frames in a single RTP > packet is supported. The advantage of [9] as compared to [8] is > mainly the possibility to transmit redundant speech frames (or=20 > parts thereof). > =20 > The present proposal incorporates the abilities of [8,9] with the > addition that there is an option for reconstruction of a larger=20 > number of past lost frames. For the purpose of clarity and simpler > comparison, in the sequel we will follow the structure and the > notation of [9] as far as possible. > > > 3. Requirements > > The AMR payload format for RTP was designed to meet the following > requirements: > > o Different levels of robustness must be supported: > - no redundancy at all > - past frames (partly) repeated > - parity bits generated over several past frames to yield extreme > robustness capable of handling very high packet loss rates with = > > no or small speech quality degradation. > > o Fast,frame-wise AMR mode adaptation must be supported. This > means that it must be possible to send codec mode requests (CMRs) = > > back from the receiving side to the transmitting side with=20 > information on the preferred mode. Slower AMR mode adaptation may > also be accomplished with external signaling. > > o Discontinuous transmission (DTX) and comfort noise generation > (CNG) as specified in AMR must be supported. > > > 4. RTP Payload Format Specification > > This RTP payload format is designed to be flexible, ranging from > very low overhead (minimal) to an extended format with room for > future AMR extensions, e.g. wide band modes, and the possibility > to send extra redundancy information and several speech frames in > one RTP payload packet. > > > > > > Fingscheidt & Wimmer [Page = > 3] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > Each RTP payload consists of an > - RTP payload header followed by the=20 > -RTP payload data. > =20 > The RTP payload data is generated by the interleaving of one or=20 > several RTP payload frames, see section 4.4. An RTP payload frame > may be generated from > - AMR frames or=20 > - redundancy frames.=20 > > Each RTP payload frame must not be octet-aligned, however the RTP > payload shall be octet-aligned. If the last octet of an RTP payload > covers unused bits, these bits shall be set to zero. > > > 4.1. The RTP Payload Header > > The payload header has dynamic length, 3 or 8 bits. The bits in the=20 > Header are specified as follows: > > Q (1 bit): The payload quality bit indicates, if not set, that the=20 > Payload is severely damaged and the receiver should set the RX_TYPE, > see [10], to SPEECH_BAD or SID_BAD depending on the frame type (FT). > > I (1 bit): If I=3D1, it indicates the existence LEN/DEPTH indicator > bit (L) in each RTP payload frame. If I=3D0 the LEN/DEPTH indicator = > do > not exist. > > R (1 bit): Indicates if the codec mode request (CMR) is sent or not. > > CMR (5 bits): OPTIONAL field, depending on the R bit. Requested > codec mode for the other communication direction. The interpretation > is equal to the FT field, see Table 1. > > 0 > 0 1 2 > +-+-+-+ > |Q|I|R| > +-+-+-+ > > Figure 1: RTP payload header, R=3D0 > > 0 > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |Q|I|R| CMR | > +-+-+-+-+-+-+-+-+ > > Figure 2: RTP payload header, R=3D1 > > > > > > > > > > > Fingscheidt & Wimmer [Page = > 4] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > 4.2. RTP Payload AMR Frame > > The RTP payload AMR frame is designed for covering AMR encoded=20 > speech data and is generated by=20 > - AMR frame header that is followed by the > - AMR frame payload. > > The AMR frame must not be octet-aligned.=20 > =20 > > 4.2.1. AMR Frame Header Format > > Each AMR frame header includes several specified fields as follows: > > F (1 bit): Indicates if this frame is followed by further frames. > F=3D1 further frames follow, F=3D0 last frame. > =20 > L (1 bit): (OPTIONAL) If the RTP payload header bit I=3D1 this field = > > exists. If I=3D0 this field is not existing. If set to L=3D1 the AMR > frame header includes the LEN field. If L=3D0 no LEN field exists in > this AMR frame header. > > FT (5 bits): Frame type indicator, indicating the AMR speech coding > mode or comfort noise (CN) mode. The mapping of existing AMR modes > is given in Table 1. This implies that the number of bits of the AMR > frame payload can be derived from Table 1. If FT=3D15 (No=20 > transmission) L for both AMR and redundancy frames SHOULD be set=20 > to 0. > > LEN (7 bits): OPTIONAL field, exists if the AMR header bit L is set, > L=3D1. LEN specifies the number of octets in the current AMR frame > payload. The following situations may occur and shall be treated as=20 > follows: > =20 > - If LEN*8 <=3D number of speech bits indicated by FT, as shown in=20 > Table. 1, > the number of bits of the AMR frame payload shall be derived by=20 > 8*LEN and not by the FT field. This implies that the encoded AMR > data was shortend to 8*LEN. > - otherwise the LEN field SHOULD be ignored. > =20 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |F|L| FT | LEN | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > | | > + + > / AMR frame payload / > / / > + +-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 3: AMR frame format, I=3D1 and L=3D1 > =20 > > > Fingscheidt & Wimmer [Page = > 5] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |F|L| FT | | > +-+-+-+-+-+-+-+ + > | | > + + > / AMR frame payload / > / / > + +-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 4: AMR frame format, I=3D1 and L=3D0 > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |F| FT | | > +-+-+-+-+-+-+ + > | | > + + > / AMR frame payload / > + +-+-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 5: AMR frame format, I=3D0 > > > 4.2.2. AMR Frame Payload Format > > The AMR speech encoder produces AMR speech frames, as defined by = > [2]. > The currently defined AMR speech frame types can be found in Table = > 1.=20 > =20 > speech > Index Mode bits > ---------------------------------- > 0 AMR 4.75 95 > 1 AMR 5.15 103 > 2 AMR 5.9 118 > 3 AMR 6.7 134 > 4 AMR 7.4 148 > 5 AMR 7.95 159 > 6 AMR 10.2 204 > 7 AMR 12.2 244 > 8 AMR CNG 39 > 9 GSM EFR CNG 43 > 10 IS-641 CNG 38 > 11 PDC-EFR CNG 37 > 12 - 14 For future use - > 15 No transmission 0 > 16 - 31 For future use - > > Table 1: AMR speech frame types (taken from [9]) > > > > Fingscheidt & Wimmer [Page = > 6] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > The bit order of frame type 0 - 11 is given in [7]. Frame type 15,=20 > no transmission, is needed to indicate not transmitted frames or > lost frames, e.g. when multiple frames are sent in each payload=20 > and comfort noise starts. A frame type sequence in a payload with8 > frames, AMR mode 7, and CNG starts in the fifth frame, could look > like: {7,7,7,7,8,15,15,8}. The AMR DTX (also called "source con- > trolled rate operation", SCR) is described in [10]. Another reason > for the no transmission frame type is a possible need to send an > urgent codec mode request in a silence period with comfort noise. > =20 > Before the AMR encoded speech frames are copied to the AMR frame > payload the speech bits shall be ordered to the descending bit-error > sensitivity. This re-ordering process is defined in [7]. > =20 > After this re-ordering process the AMR encoded speech frame is=20 > copied to the AMR frame payload, according to the particular=20 > setting of the AMR frame header, e.g. copying of the first 8*LEN=20 > bits, see section 4.2.1. > > > 4.3. RTP Payload - Redundancy Frame > > The RTP payload redundancy frame is designed for covering redundancy > data for error-correction of lost AMR frames. The redundancy frame=20 > is generated by=20 > - redundancy frame header that is followed by the > - redundancy frame payload. > > The redundancy frame must not be octet-aligned.=20 > =20 > =20 > 4.3.1. Redundancy Frame Header Format > > Each redundancy frame header includes several specified fields as=20 > follows: > > F (1 bit): Indicates if this frame is followed by further frames.=20 > F=3D1 further frames follow, F=3D0 last frame. > =20 > L (1 bit): (OPTIONAL) If the RTP payload header bit I=3D1 this field > exists. If I=3D0 this field is not existing. If set to L=3D1 the=20 > redundancy frame header includes the LEN field. If L=3D0 no R_LEN=20 > field exists in this redundancy frame header. > > R_FT (5 bits): This field indicates the FT-fields of the past DEPTH > AMR frame headers by the following coding rule. > R_FT(n) =3D FT(n-1) EXOR ... EXOR FT(n-DEPTH(n)) (Eq. 1) > whereby > n is set to the current AMR frame number. > FT(n) is defined as the AMR frame header field FT of=20 > frame n. > R_FT(n) denotes the redundancy frame header field R_FT of=20 > frame n. > EXOR is defined as the bit-wise exclusive OR operation. > DEPTH(n) denotes the redundancy frame header field DEPTH of=20 > frame n. > > > > > Fingscheidt & Wimmer [Page = > 7] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > R_LEN (7 bits): OPTIONAL field, exists if the redundancy header=20 > bit L is set, L=3D1. R_LEN specifies the number of octets in the=20 > current redundancy frame payload. Depending on R_LEN several=20 > different operational modes are used that will be described in=20 > section 4.3.2. R_LEN may be changed from redundancy frame to=20 > redundancy frame. If L=3D0 or/and I=3D0, R_LEN(n) is set to FT(n),=20 > whereby n denotes the current AMR frame number. > > DEPTH (4 bits): OPTIONAL field, exists if the redundancy header=20 > bit L is set, L=3D1. DEPTH specifies the number of previous AMR = > frame > payload pakets that are usedfor the generation of the redundancy > frame payload. The detailed description can be found in section > 4.3.2. DEPTH =3D 0 is currently unused and may be used for future > extension. If L=3D0 or/and I=3D0 then DEPTH is set to the default=20 > value 15. > =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |F|L| R_FT | R_LEN | DEPTH | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + > | | > + + > / redundancy frame payload / > / / > + +-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 6: Redundancy frame format, I=3D1 and L=3D1 > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |F|L| R_FT | | > +-+-+-+-+-+-+-+ + > | | > + + > / redundancy frame payload / > / / > + +-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: Redundancy frame format, I=3D1 and L=3D0 > > 0 1 2 3 > 0 1 2 34 5 6 78 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |F| R_FT | | > +-+-+-+-+-+-+ + > | | > + + > / redundancy frame payload / > + +-+-+-+-+-+-+-+-+-+ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 8: Redundancy frame format, I=3D0 > > Fingscheidt & Wimmer [Page = > 8] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > 4.3.2. Redundancy Frame Payload Format > > The generation of the redundancy payload is based on parity bit=20 > calculation of one or several previous AMR frame payload pakets. > This number of AMR frames is determined by the redundancy frame > header field DEPTH. > > The general rules for generating of the parity bits can be found > in section 4.3.3. > > The value of R_LEN can in principle be changed during transmission. > Let's assume R_LEN changes from R_LEN1 to R_LEN2, with DEPTH being > constant. In that case for a number of DEPTH AMR frame packets only=20 > min(R_LEN1,R_LEN2) AMR frame payload bits can be reconstructed.=20 > Although adaptation of R_LEN for redundancy frames works seamlessly, > it is RECOMMENDED not to perform such an adaptation on a=20 > frame-by-frame basis. > =20 > The value of DEPTH can also be adapted during transmission. Let's=20 > assume DEPTH changes from DEPTH1 to DEPTH2. It is RECOMMENDED to=20 > choose a maximum value of DEPTH dependent on the application=20 > (e.g. streaming services: large DEPTH, VoIP: low DEPTH) and to adapt > it only on a long term basis, since reconstruction capabilities are > reduced in transition regions for a number of min(DEPTH1,DEPTH2)=20 > AMR frames. > > > 4.3.3. Encoding Rules for the Parity Bits > > This section describes the encoding rules for the parity bits. > > Notation: > n : number of the current AMR frame; n is increased for each > sent AMR frame packet. n denotes also the current=20 > redundancy frame number. > o : number of AMR frame that covers less AMR frame payload=20 > bits than required by current redundancy frame header > field R_LEN(n) > LEN(o). > g(n,m) : bit m in the AMR frame payload of frame n > p(n,m) : bit m in the redundancy frame payload of frame n > XOR : exclusive OR operation > R_LEN(n) : denotes the R_LEN field of the redundancy frame header of = > > frame n > > The parity bits SHALL be calculated by the following equation: > =20 > p(n,m) =3D g(n-1,m) EXOR ... EXOR g(n-DEPTH+1, m) EXOR g(n-DEPTH, = > m)=20 > (eq.2) > for m =3D 0 ... R_LEN(n)-1; =20 > > Eq. 2 requires that all LEN(i) with i =3D (1, ... , DEPTH) of the = > AMR > frames are at least as large as R_LEN(n). In the event that this is > not valid the missing AMR frame payload bits SHALL be virtually=20 > generated by the following rule. > > > > > > Fingscheidt & Wimmer [Page = > 9] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > if (o =3D n-DEPTH) > =20 > g(o, LEN(o)+i) =3D 0, for i=3D0...(R_LEN(n)-LEN(o)-1); > =20 > else > =20 > if (R_LEN(n)-LEN(o) <=3D LEN(o-1)) > > g(o, LEN(o)+i) =3D g(o-1, i), for = > i=3D0...(R_LEN(n)-LEN(o)-1); > =20 > else { =20 > > g(o, LEN(o)+i) =3D g(o-1, i), for i =3D 0 ... (LEN(o-1)-1); > g(o, LEN(o)+LEN(o-1)+i) =3D 0,=20 > for i =3D 0 ... (R_LEN(n)-LEN(o)-LEN(o-1)-1);=20 > } > > This rule implies that virtuell data SHALL be copied from the most > sensitive bits of the previous AMR frame payload of the AMR frame o. > However if the previous AMR frame number (o-1) is outside the window > defined by the DEPTH parameter of the current redundancy frame the > virtual data is set to 0. In the case that the AMR frame payload=20 > (o-1) contains less bits than required to achieve all virtual bits > of AMR frame payload (o) then first all AMR frame payload bits of > (o-1) SHALL be taken and then the missing virtual bits of AMR frame > payload (o) SHALL be set to 0. > > Example: > > In this example, see Figure 9, it can be seen that the AMR frame=20 > payload contains not enough bits. Therefore the most sensitive bits > of AMR frame payload (n-3) are virtually appended to AMR frame pay- > load (n-2) until the desired length is reached.=20 > > time: n-3 n-2 n-1 n > =20 > +----------+ +-----------+ +----------+ +--------+ > | |- XOR -| g(n-2,m), |- XOR -| | =3D | | > | g(n-3,m) |- XOR -| fill with |- XOR -| g(n-1,m) | =3D | p(n,m) | > | |- XOR -| g(n-3,m) |- XOR -| | =3D | | > +----------+ +-----------+ +----------+ +--------+ > =20 > Figure 9: Example of parity bit generation for p(n,m) with DEPTH=3D3 = > > and the number of AMR frame payload bits in frame n-2 being smaller=20 > than 8*R_LEN(n).=20 > =20 > > 4.3.4. Decoding of Redundancy Frame Payload > > Decoding of these parity codes is intended in the following manner. > Imagine one frame of AMR encoded bits and one parity bit block per > frame. Every value of DEPTH >=3D 1 allows the reconstruction of a=20 > single lost frame among the last DEPTH frames. DEPTH =3D 2 allows = > the > reconstruction of two consecutive lost frames, once two good frames > are received. In general, a number of DEPTH buffered packets allows > for the reconstruction of a number of DEPTH lost frames preceding > them. The set of equations given by the XOR operations is solved at > > > Fingscheidt & Wimmer [Page = > 10] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > first for the last (!) lost frame (unknowns), using the DEPTH=20 > buffered frames as knowns. Then everything is solved for the last=20 > but first lost frame, taking into account the already reconstructed > last lost frame's bits. And so forth. > > Here the tremenduous strength of using parity codes instead of frame > repetition becomes obvious: Especially for streaming applications a > large value of DEPTH allows to reconstruct error bursts of the same > large number of DEPTH consecutive frames. > > =20 > 4.3.5. Implications for DTX and the choice of DEPTH > > For delay reasons it is not advisable to store a large number > (DEPTH) of CNG frames in the receiver buffer before previous lost > CNG AMR frames or AMR frame payload packets, containing speech data, > can be reconstructed.=20 > > Thus the follwing rules SHALL apply: > > o Starting with the second AMR frame containing one/several CNG=20 > frames, DEPTH SHALL be set maximally to 1 for all consecutive > redundancy frames containing CNG AMR frames. > o In the first and the second AMR frame containing no CNG after a=20 > speech pause, DEPTH SHALL be set maximally to 1. > > These rules allow optimal recovery of lost AMR frames in DTX=20 > operation, while keeping delay at a minimum. > =20 > > 4.4. Payload Block Sorting > > In general a bit > error in a more sensitive bit is subjectively more annoying than in > a less sensitive bit. To be able to protect the most sensitive bits > in a AMR and redundancy frames with a forward error detection code, > e.g. a CRC outside RTP, the full RTP payload data MUST be sorted in > sensitivity order. The protection MAY then cover an appropriate=20 > number of octets from the beginning of the AMR and/or redundancy > frames. How many octets depends on the channel and application. > This can for example be accomplished by UDP lite [6] (work in=20 > progress). To maintain sensitivity ordering inside the AMR payload > when more than one speechframe is transmitted in one packet > reordering of the data is needed. > > The reordering to maintain the sensitivity ordered AMR payload SHALL > be performed on bit level. The AMR payload header SHALL still be > placed unchanged in the beginning of the payload. Thereafter, the > payload frames are sorted with one bit alternating from each payload > frame. > > > > > > > > > > Fingscheidt & Wimmer [Page = > 11] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > +-------------+ > | h(0)-h(H-1) | > +------------------------+ > | f(0,0) _ f(0,F(0)) | > +----------------------------+ > | f(1,0) _ f(1,F(1)) | > +----------------------------+ > | f(2,0) _ f(2,F(2)) | > +----------------------+ > \ \ > +-------------------------------+ > | f(N-1,0) _ f(N-1,F(N-1)) | > +-------------------------------+ > > Figure 10: The payload header and N AMR/redundancy frames before=20 > sorting. > > The sorting algorithm can be described in C-code. > > b(m) : bit m of RTP final payload > f(n,m) : bit m in AMR/redundancy frame payload of frame n > F(n) : number of bits in AMR/redundancy frame n, defined by FT > or by LEN/R_LEN > h(m) : bit m of RTP payload header > H : number of RTP payload header bits, 3 or 8 bits > N : number of AMR/redundancy frames in the RTP payload > S : number of unused bits > > Payload frames f(n,m) are ordered in consecutive order, where frame > n=3D1 is preceding frame n=3D2. > > The sorting algorithm is defined in C-style as: > > for (i =3D 0; i < H; i++) > b(i) =3D h(i); > max =3D max(F(0),..,F(N-1)); > k =3D H; > for (i =3D 0; i < max; i++){ > for (j =3D 0; j < N; j++){ > if (i < F(j)){ > b(k++) =3D f(j,i); > } > } > } > S =3D 8 - k%8; > if (S < 8){ > for (i =3D 0; i < S; i++) > b(k++) =3D 0; > } > > > > > > > > > > > Fingscheidt & Wimmer [Page = > 12] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > 5. RTP header usage > > The RTP header marker bit (M) is used to mark (M=3D1) the packages > containing the first speech frame after CN. In all other packages > the marker bit is set to 0 (M=3D0). > > The time-stamp corresponds to the sampling time of the first sample > encoded for the first encoded speech frame in the AMR frame. The > timestamp unit is in samples, i.e. one AMR speech frame is 20 ms=20 > and sampling frequency is 8 kHz corresponds to 160 encoded speech > samples per frame, i.e. the timestamp is increased by 160 for each > AMR speech consecutive frame.=20 > > Due to DTX functionality each RTP packet SHALL contain the > appropriate time-stamp of the first AMR frame, covered by the RTP > payload. Each AMR frame containg CNG data or the first AMR frame > containing speech data after CNG SHALL start with a new RTP packet. > This is required to achieve the correct timing information. > > Please consider also [12] for setting of particular parameters. > > > 6. Examples > > 6.1. Simple example > > In the simple example we just send one full (I=3D0) frame in each = > RTP > packet, no codec mode request CMR is sent (R=3D0), the payload was = > not > damaged at IP origin (Q=3D1). In this example we transmit one frame > encoded with the 5.9 kbps mode (FT=3D2). The speech encoded bits are > put into f(0) to f(117) in descending sensitivity order according to > [7]. > > | Bit no. = > | > Oct.| 0 1 2 3 4 5 6 7 = > | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 0 | Q=3D1 | I=3D0 | R=3D0 | F=3D0 | 0 | 0 | 0 = > | 1 | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 1 | 0 | f(0) | f(1) | f(2) | ... | ... | ... | ... = > | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 16 | ... | ... | ... | ... | f(115)| f(116)| f(117)| 0 = > | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > > Figure 11: One frame per packet example. > > > 6.2. Example with parity bits > > In this example a AMR frame with 6.7 kbps mode (FT=3D3) is sent with > one redundancy frame packet. > =20 > - The RTP payload header is set to Q=3D1, I=3D1, R=3D1 and CMR =3D = > 6. A mode=20 > request is sent(R=3D1), requesting the 10.2 kbps mode for the = > other > link (CMR=3D6). > > - The AMR frame header uses F=3D1, L=3D0 (this implies NO LEN field) = > and > FT =3D 3. The AMR frame header is followed by the AMR frame = > payload, > denoted by f(0) to f(133). > > Fingscheidt & Wimmer [Page = > 13] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > - The redundancy frame header is set to=20 > - F =3D 0 (no following frames), > - L =3D 1 (R_LEN and DEPTH exist) > - R_FT =3D 3 (the 3 previous AMR frame header fields FT were 3), = > > - R_LEN =3D 2 (number of redundancy frame payload bits =3D 2*8 = > =3D 16) > - DEPTH =3D 3 (the 3 previous AMR frame payload packets are = > taken=20 > for redundancy frame payload calculation) > The redundancy frame paylaod covers 16 bits and is denoted by the > value r(.). > > | Bit no. = > | > Oct.| 0 1 2 3 4 5 6 7 = > | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 0 | Q=3D1 | I=3D1 | R=3D1 | 0 | 0 | 1 | 1 | = > 0 | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 1 | F=3D1 | F=3D0 | L=3D0 | L=3D1 | 0 | 0 | 0 = > | 0 | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 2 | 0 | 0 | 1 | 1 | 1 | 1 | f(0) | 0 = > | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 3 | f(1) | 0 | f(2) | 0 | f(3) | 0 | f(4) | 0 = > | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 4 | f(5) | 1 | f(6) | 0 | f(7) | 0 | f(8) | 0 = > | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 5 | f(9) | 1 | f(10) | 1 | f(11) | r(0) | f(12) | r(1) = > | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 6 | f(13) | r(2) | f(14) | r(3) | ... | ... | ... | ... = > |=20 > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > .. | ... | ... | ... | ... | ... | ... | ... | ... = > | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 9 | ... | ... | ... | r(15) | f(27) | r(16) | f(28) | f(29) = > | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > .. | ... | ... | ... | ... | ... | ... | ... | ... = > | > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > 33 | ... | ... | ... | ... | f(130)| f(131)| f(132)| = > f(133)| > = > ----+-------+-------+-------+-------+-------+-------+-------+-------+ > > Figure 12: Example with 1 AMR frame and 1 redundancy frame > > > > > > > > > > > > > > > > > > > > > > > Fingscheidt & Wimmer [Page = > 14] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > 7. References > > [1] IETF RFC1889, "RTP: A Transport Protocol for Real-Time > Applications" > > [2] GSM 06.90, "Adaptive Multi-Rate (AMR) speech transcoding" > > [3] ARIB, RCR STD-27H, Section 5.4, "ACELP Speech CODEC" > > [4] TIA/EIA IS-641-A, "TDMA Cellular/PCS _Radio interface, Enhanced > Full-Rate Voice Codec" > =20 > [5] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding" > > [6] IETF draft-larzon-udplite-02.txt, "The UDP Lite Protocol" > > [7] 3G TS 26.101, "AMR Speech Codec Frame Structure" > =20 > [8] IETF draft-lakaniemi-avt-rtp-amr-00.txt, "RTP Payload Format=20 > for AMR" > > [9] IETF draft-sjoberg-avt-rtp-amr-00.txt, "RTP payload format=20 > for AMR" > =20 > [10] 3G TS 26.093, "AMR Speech Codec; Source Controlled Rate=20 > Operation" > > [11] RFC 2119, "Key words for use in RFCs to Indicate Requirement > Levels" > > [12] IETF draft-wimmer-amr-01.txt, "MIME Type Registration for AMR > Speech Codec" > > > =20 > 8. Authors' addresses > > Tim Fingscheidt > Siemens AG, ICP CD > Grillparzerstrasse 10-18 > D - 81675 Munich > Germany > Phone: ++49 89 722 57658 > Fax: ++49 89 722 46489 > E-mail: Tim.Fingscheidt@mch.siemens.de > > Bernhard Wimmer (contact person) > Siemens AG, ICP CD > Grillparzerstrasse 10-18 > D - 81675 Munich > Germany > Phone: ++49 89 722 23247 > Fax: ++49 89 722 46489 > E-mail: Bernhard.Wimmer@mch.siemens.de > > > This Internet-Draft expires January, 14, 2001. > > > Fingscheidt & Wimmer [Page = > 15] > INTERNET-DRAFT RTP Payload Format for AMR July 14, = > 2000 > > > Full Copyright Statement > "Copyright (C) The Internet Society (date). All Rights Reserved. > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph > are included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES; EXPRESS OR IMPLIED; INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INFORMATION HEREIN > WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Fingscheidt & Wimmer [Page = > 16] > > ------_=_NextPart_000_01BFEDA4.E424F530-- > From rem-conf Fri Jul 14 10:19:55 2000 From rem-conf-request@es.net Fri Jul 14 10:19:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13D95x-0000Nz-00; Fri, 14 Jul 2000 10:17:49 -0700 Received: from beamer.mchh.siemens.de [194.138.158.163] by mail1.es.net with esmtp (Exim 1.81 #2) id 13D95v-0000Nk-00; Fri, 14 Jul 2000 10:17:47 -0700 Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id TAA06928 for ; Fri, 14 Jul 2000 19:17:13 +0200 (MET DST) From: Bernhard.Wimmer@mch.siemens.de Received: from mchh9eea.mchh.siemens.de (mchh9eea.mchh.siemens.de [139.21.204.218]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id TAA24206 for ; Fri, 14 Jul 2000 19:14:36 +0200 (MET DST) Received: by mchh9eea.mchh.siemens.de with Internet Mail Service (5.5.2650.21) id <3RC46JBV>; Fri, 14 Jul 2000 19:17:41 +0200 Message-ID: <910CC38345FDD211943A0008C724DD48F18170@mchg9eca.mchh.siemens.de> To: rem-conf@es.net Subject: WG: draft-lnt-avt-uxp-00.txt Date: Fri, 14 Jul 2000 19:17:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFEDB7.6B880E60" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 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_000_01BFEDB7.6B880E60 Content-Type: text/plain > Dear I-D-manager and AVT group experts, > > We are submitting an Internet Draft for discussion in the AVT group. > > Title: An RTP Payload Format for Erasure-Resilient Transmission of > Progressive Multimedia Streams > Authors: M. Nguyen, G. Liebl, B. Wimmer, F. Burkert, J. Pandel > Filename: draft-lnt-avt-uxp-00.txt > > This document specifies an efficient way to ensure erasure-resilient > transmission of progressively encoded multimedia sources via RTP > using Reed-Solomon codes. The level of erasure protection can be > explicitly adapted to the importance of the respective parts in the > source stream, thus allowing a graceful degradation of application > quality with increasing packet loss rate on the network. Hence, this > type of unequal erasure protection (UXP) schemes is intended to cope > with the rapidly varying channel conditions on wireless access links > to the Internet backbone. Nevertheless, backward compatibility to > currently standardized non-progressive multimedia codecs is ensured, > since equal erasure protection (EXP) represents a subset of generic > UXP. By defining a comparably simple payload format, the proposed > scheme can be easily integrated into the existing framework for RTP. > > > In addition to the attached version of the draft, it is also available > via anonymous FTP from > ftp://ftp.lnt.e-technik.tu-muenchen.de/pub/UXP/draft-lnt-avt-uxp-00.txt > > Any comments by email are highly welcome. We are looking forward to the > upcoming discussion with you at the Pittsburg' meeting. > > > Best regards, > Guenther Liebl (Bernhard Wimmer) > > -- > ======================================================== > Dipl.-Ing. Guenther Liebl > > Institute for Communications Engineering (LNT) > Munich University of Technology (TUM) > D-80290 Muenchen > > Tel. (work): +49 89 289-25010 > Fax. (work): +49 89 289-23490 > > e-mail: guenther.liebl@ei.tum.de > URL: http://www.ei.tum.de/~liebl > ======================================================== > <> ------_=_NextPart_000_01BFEDB7.6B880E60 Content-Type: text/plain; name="draft-lnt-avt-uxp-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-lnt-avt-uxp-00.txt" Internet Engineering Task Force M. Nguyen, G. Liebl Internet Draft LNT, Munich Univ. of Technology Document: draft-lnt-avt-uxp-00.txt July 2000 B. Wimmer, F. Burkert, J.Pandel Expires: January 2001 Siemens AG, Munich An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document specifies an efficient way to ensure erasure-resilient transmission of progressively encoded multimedia sources via RTP using Reed-Solomon codes. The level of erasure protection can be explicitly adapted to the importance of the respective parts in the source stream, thus allowing a graceful degradation of application quality with increasing packet loss rate on the network. Hence, this type of unequal erasure protection (UXP) schemes is intended to cope with the rapidly varying channel conditions on wireless access links to the Internet backbone. Nevertheless, backward compatibility to currently standardized non-progressive multimedia codecs is ensured, since equal erasure protection (EXP) represents a subset of generic UXP. By defining a comparably simple payload format, the proposed scheme can be easily integrated into the existing framework for RTP. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page1] =0C Internet Draft Unequal Erasure Protection July 2000 2. Conventions used in this document The following terms are used throughout this document: 1.) Message block: a higher layer transport unit (e.g. an IP packet), that enters/leaves the segmentation/reassembly stage at the interface to wireless data link layers. 2.) Segment: denotes a link layer transport unit. 3.) CRC: Cyclic Redundancy Check, usually added to transport units at the sender to detect the existence of erroneous bits in a transport unit at the receiver. 4.) Segmentation/Reassembly Process: If the size of the transport units at the link layer is smaller than that at the upper layers, message blocks have to be split up into several parts, i.e. segments, which are then transmitted subsequently over the link. If nothing is lost, the original message block can be restored at the receiving entity (reassembly). 5.) Quality-of-service: application-dependent criterion to define a certain desired operation point. 6.) Codec: denotes a functional pair consisting of a source encoding unit at the sender and a corresponding source decoding unit at the receiver; usually standardized for different multimedia applications like audio or video. 7.) Progressive source coding: results in a stream of coded data whose distinct elements are of different importance to the reconstruction process at the decoder. Elements are commonly ordered from highest to least importance, where the latter elements depend on the previous. 8.) Reed-Solomon (RS) code: belongs to the class of linear nonbinary block codes, and is uniquely specified by the block length n, the number of parity symbols t, and the symbol alphabet. 9.) n: is a variable, which denotes both the block length of a RS codeword, and the number of columns in a TB (see 15). 10.) k: is a variable, which denotes the number of information symbols in a RS codeword. 11.) t: is a variable, which denotes the number of parity symbols in a RS codeword. 12.) Erasure: When a packet is lost during transmission, an erasure is said to have happened. Since the position of the erased packet in a sequence is usually known, a corresponding erasure marker can be set at the receiving entity. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 2] =0C Internet Draft Unequal Erasure Protection July 2000 13.) Base layer: comprises the first and most important elements in a progressively encoded bitstream, without which all subsequent information is useless. 14.) Enhancement layer: comprises one or more sets of the less important subsequent elements in a progressively encoded bitstream. A specific enhancement layer can be decoded, if and only if the base layer and all previous enhancement layer data (of higher importance) is available. 15.) Transmission block (TB): denotes a memory array of L rows and n columns. Each row of a TB represents a RS codeword, whereas each column represents the payload of an RTP packet. 16.) L: is a variable, which denotes both the number of rows in a TB and the payload length of an RTP packet in bytes. 17.) Unequal erasure protection (UXP): denotes a specific strategy which varies the level of erasure protection across a TB according to a given redundancy profile. 18.) Equal erasure protection (EXP): is a subset of UXP, for which the level of erasure protection is kept constant across a TB. 19.) Redundancy profile: describes the size of the different erasure protection classes in a TB, i.e. the number of rows (codewords) per class. 20.) Erasure protection class: contains a set of rows (codewords) of the TB with same erasure correction capability. 21.) i: is a variable, which denotes the number of parity bytes for each row in erasure protection class i. 22.) CA_i: is a variable, which denotes the set of rows contained in erasure protection class i. 23.) A_i: is a variable, which denotes the total number of rows contained in erasure protection class i, i.e. the cardinality of CA_i. 24.) T: is a variable, which denotes the number of parity bytes for each row in the highest erasure protection class (with respect to application data) in a TB. 25.) AV: denotes the erasure protection vector of length (T+1) used to describe a certain redundancy profile. 26.) Stuffing: insertion of predefined symbol patterns. Stuffing is performed, if the information part of an erasure protection class cannot be filled completely with (application) payload data. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 3] =0C Internet Draft Unequal Erasure Protection July 2000 27.) Interleaver: performs the spreading of a codeword, i.e. a row in the TB, over n successive packets, such that the probability of an erasure burst in a codeword is kept small. 28.) UXP header: is the additional header information contained in each RTP packet after UXP has been applied. 29.) X: denotes a currently not used extension field of 1 bit in the UXP header. 30.) P: is a variable which denotes the number of parity symbols per row used to protect the inband signaling of the redundancy profile. 31.) ceil(.): denotes the ceiling function, i.e. rounding up to the next integer. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. 3. Introduction Due to the increasing popularity of high-quality multimedia applications over the Internet and the high level of public acceptance of existing mobile communication systems, there is a strong demand for a future combination of these two techniques: One possible scenario consists of an integrated communication environment, where users can set up multimedia connections anytime and anywhere via radio access links to the Internet. For this reason, several packet-oriented transmission modes have been proposed for next generation wireless standards like EGPRS (Enhanced General Packet Radio Service) or UMTS (Universal Mobile Telecommunications System), which are mostly based on the same principle: Long message blocks, i.e. IP packets, that enter the wireless part of the network are split up into segments of desired length, which can be multiplexed onto link layer packets of fixed size. The latter are then transmitted sequentially over the wireless link, reassembled, and passed on to the next network element. However, compared to the rather benign channel characteristics on today's fixed networks, wireless links suffer from severe fading, noise, and interference conditions in general, thus resulting in a comparably high residual bit error rate after detection and decoding. By use of efficient CRC-mechanisms, these bit errors are usually detected with very high probability, and every corrupted segment, i.e. which contains at least one erroneous bit, is discarded to prevent error propagation through the network. But if only one single segment is missing at the reassembly stage, the upper layer IP packet cannot be reconstructed anymore. The result is a significant increase in packet loss rate at IP level. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 4] =0C Internet Draft Unequal Erasure Protection July 2000 Since most multimedia applications can only recover from a very limited number of lost message blocks, it is vitally necessary to keep packet loss at IP level within a certain acceptable range depending on the individual quality-of-service requirements. However, due to the delay constraints typically imposed by most audio or video codecs, the use of ARQ-schemes is often prohibited both at link level and at transport level. In addition, retransmission strategies cannot be applied to any broadcast or multicast scenarios. Thus, forward erasure correction strategies have to be considered, which provide a simple means to reconstruct the content of lost packets at the receiver from the redundancy that has been spread out over a certain number of subsequent packets. There already exist some previous studies and proposals regarding erasure-resilient packet transmission, of whom the most important one with respect to RTP is described in [1]. Since most of them are based on the assumption that all parts in a message block are equally important to the receiver, i.e. the respective application cannot operate on partly complete blocks, they were optimized with respect to assigning equal erasure protection over the whole message block. However, recent developments both in audio and video coding have introduced the notion of progressively encoded source streams, for which unequal erasure protection strategies seem to be more promising, as it will be explained in more detail below. Although the scheme defined in [1] is in principle capable of supporting some kind of unequal erasure protection, possible implementations seem to be quite complex with respect to the gain in performance. Finally, in [1] it is assumed that subsequent RTP packets can have variable length, which would cause significant segmentation overhead at the link layer of almost all wireless systems. This document defines a payload format for RTP, such that different elements in a progressively encoded multimedia stream can be protected against packet erasures according to their respective quality-of-service requirement. The general principle, including the use of Reed-Solomon codes together with an appropriate interleaving scheme for adding redundancy, follows the ideas already presented in [2], but allows for finer granularity in the structure of the progressive source stream. The proposed scheme is generic in the way that it (1) is independent of the type of multimedia stream, be it audio or video, and (2) can be adapted to varying transmission quality very quickly by use of inband-signaling. 4. Reed-Solomon Codes Reed-Solomon (RS) codes are a special class of linear nonbinary block codes, which are known to offer maximum erasure correction capability with minimum amount of redundancy. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 5] =0C Internet Draft Unequal Erasure Protection July 2000 An arbitrary t-erasure-correcting (n,k) RS code defined over Galois field GF(q) has the following parameters [3]: - Block length: n=3Dq-1 - No. of information symbols in a codeword: k - No. of parity-check symbols in a codeword: n-k=3Dt - Minimum distance: d=3Dt+1 In what follows, only systematic RS codes over GF(2^8) shall be considered, i.e. the symbols of interest can be directly related to a tuple of eight bits, which is commonly called a byte in packet transmission. The principle structure of a codeword is shown in Fig. 1. By shortening the initial (n=3D255,n-t) RS code, any desired = (n',n'-t) RS code for a given erasure correction capability t may be obtained. block of n bytes <-----------------> +-+-+-+-+-+-+-+-+-+ |&|&|&|&|&|&|&|*|*| +-+-+-+-+-+-+-+-+-+ <------------><---> k=3Dn-t t (&:info) (*:parity) Fig. 1: Structure of a systematic RS codeword 5. Progressive Source Coding If the output of a multimedia codec, be it audio or video, is said to be progressive, the encoded bitstream must consist of several distinct elements, often organized in separate layers. The latter shall be defined via their relative importance with respect to the quality of the reconstruction process at the receiver. Hence, there exists at least one layer, often called base layer, without which reconstruction fails at all, whereas all the other layers, often called enhancement layers, just help to continually improve the quality. Consequently, the different layers shall be mapped on the bitstream in decreasing order of importance, i.e. the base layer data is followed by the various enhancement layers. An example can be found in the fine granular scalability modes which have been proposed to various standardization bodies like MPEG-4 [4] or ITU (H.26L) [5], where the resolution of the scaling process in the progressive source encoder is as low as one symbol in the enhancement layer. From the above definition, it is quite obvious that the most important base layer data must be protected as strongly as possible against packet loss during transmission. However, the protection of the enhancement layers could be continually lowered, since a loss at this stage has only minor consequences for the reconstruction Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 6] =0C Internet Draft Unequal Erasure Protection July 2000 process. Thus, by using a suitable unequal erasure protection strategy across the message block, which contains the progressively encoded source stream, the overhead due to redundancy spent per block is reduced. Furthermore, if channel conditions get worse during transmission, only more and more enhancement layers are lost, i.e. a graceful degradation in application quality at the receiver is achieved [6]. 6. General Structure of UXP schemes Fig. 1 already illustrated the structure of a systematic codeword, which shall be represented by a single row and n successive columns that contain the information and the parity bytes. This structure shall now be extended by forming a transmission block (TB) consisting of L codewords of length n bytes each, which amounts to a total of L rows and n columns [7]: Each column shall represent the payload of an RTP packet, i.e. the whole data of a TB is transmitted via a sequence of n RTP packets all carrying a payload of length L bytes. The value of L should be chosen in such a way that the whole length of the resulting IP packet (i.e. RTP payload plus sum of UXP, RTP, UDP, and IP header) equals a multiple of the segment size on the wireless link to avoid stuffing at the data link layer. As depicted in Fig. 2, the rows of the block shall be partitioned into T+1 different classes CA_i, where i=3D0...T, such that each = class contains exactly A_i=3D|CA_i| consecutive rows of the matrix, where the A_i have to satisfy the following relationship: A_0+A_1+...+A_T=3DL Transmission Block (TB) T <-------> /\ +-+-+-+-+-+-+-+-+-+ /\ | |&|&|&|&|&|*|*|*|*| | | +-+-+-+-+-+-+-+-+-+ | A_T=3D3 | |&|&|&|&|&|*|*|*|*| | | +-+-+-+-+-+-+-+-+-+ | L bytes | |&|&|&|&|&|*|*|*|*| \/ payload | +-+-+-+-+-+-+-+-+-+ /\ per packet | +%|%|%|%|%|%|*|*|*| | A_(T-1)=3D1 | +-+-+-+-+-+-+-+-+-+ \/ | |$|$|$|$|$|$|$|*|*| . | +-+-+-+-+-+-+-+-+-+ . | |=A7|=A7|=A7|=A7|=A7|=A7|=A7|=A7|*| . | +-+-+-+-+-+-+-+-+-+ /\ | |#|#|#|#|#|#|#|#|#| | A_0=3D1 \/ +-+-+-+-+-+-+-+-+-+ \/ <-----------------> n packets Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 7] =0C Internet Draft Unequal Erasure Protection July 2000 &,%,$,=A7,# : info bytes belonging to a certain source coding layer = in decreasing order of importance * : parity bytes gained from Reed-Solomon coding Fig. 2: General structure for coding with unequal erasure protection Furthermore, all rows in a particular class CA_i shall contain exactly the same number of parity bytes, which is equal to the index i of the class. For each row in a certain class CA_i, the same (n,n- i) RS code shall be applied. As can be observed from Fig. 2, class CA_T contains the largest number of parity bytes per row, i.e. offers the highest erasure protection capability in the block. Consequently, all base layer data must be assigned to class CA_T, where the value of T should be chosen according to the desired outage threshold of the base layer given a certain packet erasure rate on the link. All other classes CA_(T-1)...CA_0 shall be sequentially filled with enhancement layer data in decreasing order of importance, where the optimal choice for the size of each class (0 or more rows), i.e. the structure of the redundancy profile, should depend on the quality- of-service requirements for the various layers. The following set of rules contains a compact description of all the operations that must be performed for each transmission block: 1.) The total number of columns n of the TB shall be chosen according to the actual delay constraints of the application. 2.) The maximum erasure correction capability T should be chosen according to the desired outage threshold of the base layer given the actual packet erasure rate on the link. 3.) The redundancy profile for the rest of the TB should depend on the size and number of the various layers in the progressive source stream, as well as the desired probability of successful decoding for each of them (quality-of-service requirement). 4.) Beginning with the base layer, each layer in the progressive source stream shall be assigned to exactly one class CA_T...CA_0 in decreasing order of importance. 5.) For each nonempty class CA_i, i=3DT...0, the following steps = have to be performed: a) All rows of this specific class shall be filled from left to right and top to bottom with data bytes of the corresponding layer. If the size of the layer is less than the available space for this class, the empty positions may be filled with the first bytes of the next layer (in decreasing order of importance), such that there is no overhead due to stuffing. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 8] =0C Internet Draft Unequal Erasure Protection July 2000 b) For each row in the class, the required i parity-check bytes are computed from the same set of codewords of an (n,n-i) RS code, and filled in the empty positions at the end of each row. Thus, every row in the class constitutes a valid codeword of the chosen RS code. 6.) If the total length of the progressively encoded source stream exceeds the number of available info byte positions in the TB for the chosen redundancy profile, the final bytes of the least important enhancement layer shall be cut off until the remaining parts fit completely into the TB. 7.) If the total length of the progressively encoded source stream is less than the number of available info byte positions in the TB for the chosen redundancy profile, byte-stuffing shall be applied to the empty positions in the last class such that the stuffing value does not influence the performance of the multimedia decoder at the receiver. 8.) After having filled the whole TB with information and parity bytes, each column is read out byte-wise from top to bottom and mapped onto the payload part of one and only one RTP packet. 9.) The n resulting RTP packets shall be transmitted subsequently to the remote host, starting with the leftmost one. 10.) At the corresponding protocol entity at the remote host, the payload of all successfully received RTP packets belonging to the same sending TB shall be filled into a similar receiving TB column- wise from top to bottom and left to right. 11.) For every erased packet of a received TB, the respective column in the TB shall be filled with a suitable erasure marker. 12.) Given the redundancy profile assigned by the sender, for each row a decoding operation shall be performed by applying any suitable algorithm for erasure decoding. 13.) For all rows for which the decoding operation has been successful, the reconstructed data bytes are read out from left to right and top to bottom, and appended to the reconstructed version of the progressive data stream. 14.) For all rows for which the decoding operation has not been successful, a sufficient number of suitable dummy symbols may be added to the reconstructed data stream to inform the source decoder about the missing symbols. One can easily realize that the above rules describe an interleaver, i.e. at the sender a single codeword of a TB is spread out over n successive packets. Thus, each codeword of a transmitted TB experiences the same number of erasures at exactly the same positions. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 9] =0C Internet Draft Unequal Erasure Protection July 2000 Two important conclusions can be drawn from this: a) Since the same RS code is applied to all rows contained in a specific class, either all of them can be correctly decoded or not. Hence, there exist no partly decodable classes at the receiver. b) If decoding is successful for a certain class CA_i, all the classes CA_(i+1)...CA_T can also be decoded, since they are protected by at least one more parity byte per row. Together with rule 4, it is therefore always ensured, that in case a decodable enhancement layer exists, the base layer it depends on can also be reconstructed! Given the maximum erasure protection value T, the redundancy profile for a TB of size (L x n) shall be denoted by a so-called erasure protection vector AV of length (T+1), where AV:=3D(A_0,A_1,...,A_(T-1),A_T) From the above definition, it is easy to realize that the trivial cases of no erasure protection and EXP are a subset of UXP: a) no erasure protection at all: all application data is mapped onto class CA_0, i.e. AV=3D(L,0,0,...,0). b) EXP: all application data is mapped onto class CA_T, i.e. AV=3D(0,0,...,0,A_T=3DL). Hence, backward compatibility to currently standardized non- progressive multimedia codecs is definitely achieved. 7. RTP payload structure For every packet whose payload results from reading out a column of the TB, the RTP header must be followed by an UXP header. 7.1. Specific settings in the RTP header The timestamp of each RTP packet resulting from reading out a TB is set to the time instant when the first byte of the progressive source data stream has been written into the TB. This results in the TS value being the same for all RTP packets belonging to a specific TB. The payload type is of dynamic type, and obtained through out-of- band signaling similar to [1]. The signaling protocol must establish a payload length to be associated with the payload type value. End systems, which cannot recognize a payload type, must discard it. All other fields in the RTP header are set to those values proposed for regular multimedia transmission using the same source codecs, but no erasure protection scheme enabled. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 10] =0C Internet Draft Unequal Erasure Protection July 2000 7.2. Structure of the UXP header The UXP header shall consist of 2 octets, and is shown in Fig. 3: 0 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X| block PT | block length n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 3: Proposed UXP header The fields in the header shall be defined as follows: - X (bit 0): extension bit, reserved for future enhancements, currently not in use -> default value: 0 - block PT (bits 1-7): regular RTP payload type to indicate the primary source encoding of the media - block length n (bits 8-15): indicates total number of RTP packets resulting from one TB (which equals the number of columns of the TB) Based on the RTP sequence number and the repetition of the block length n in each UXP header, the receiving entity is able to recognize both TB boundaries and the actual position of lost packets in the TB. Furthermore, the specific choice of equal TS values for all RTP packets belonging to a TB allows for overcoming possible sequence number overflow. 7.3. Inband signaling of the structure of the redundancy profile To enable a dynamic adaptation to varying link conditions, the actual redundancy profile used for a specific TB must be signaled to the receiving entity. Since out-of-band signaling either results in excessive additional control traffic, or prevents quick changes of the profile between successive TBs, an inband signaling procedure is desired. At this stage, only a very simple, and thus not very efficient, strategy is shown. There definitely exist better solutions, which will be included in a future version of this draft. As without knowledge of the correct redundancy profile, the decoding process cannot be applied to any of the erasure protection classes, it has to be protected as least as strongly as the base layer data against packet loss. Therefore, a new class CA_P is added to the beginning of the TB, where the number of parity symbols is by default set to the following value: P=3Dceil(n/2) Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 11] =0C Internet Draft Unequal Erasure Protection July 2000 Hence, up to 50% of the RTP packets can be lost, before the redundancy profile cannot be recovered anymore. This seems to be a reasonable value for the lowest point of operation over a lossy link. Consequently, since all other classes must have equal or less erasure protection capability, the maximum allowable value for class CA_T is now limited to T<=3DP. The data to be filled into class CA_P shall consist of a sequence of L bytes, where each byte shall contain the number of parity bytes used for each row in the TB, starting from top to bottom. The total number of rows A_P included in class CA_P is now implicitly known to the receiving entity (since it knows the value of n from interpreting the UXP header): A_P=3D ceil(L/(n-p)) The complete structure of the TB is now depicted in Fig. 4. To avoid stuffing overhead, empty positions in class CA_P may be filled up with the first bytes of the base layer. Transmission Block (TB) P <---------> /\ +-+-+-+-+-+-+-+-+-+ /\ | |?|?|?|?|*|*|*|*|*| | A_P=3D1 | +-+-+-+-+-+-+-+-+-+ \/ | |&|&|&|&|&|*|*|*|*| /\ | +-+-+-+-+-+-+-+-+-+ | A_T=3D3 | |&|&|&|&|&|*|*|*|*| | | +-+-+-+-+-+-+-+-+-+ | L bytes | |&|&|&|&|&|*|*|*|*| \/ payload | +-+-+-+-+-+-+-+-+-+ /\ per packet | +%|%|%|%|%|%|*|*|*| | A_(T-1)=3D1 | +-+-+-+-+-+-+-+-+-+ \/ | |$|$|$|$|$|$|$|*|*| . | +-+-+-+-+-+-+-+-+-+ . | |=A7|=A7|=A7|=A7|=A7|=A7|=A7|=A7|*| . | +-+-+-+-+-+-+-+-+-+ /\ | |#|#|#|#|#|#|#|#|#| | A_0=3D1 \/ +-+-+-+-+-+-+-+-+-+ \/ <-----------------> n packets ? : inband signaling of redundancy profile &,%,$,=A7,# : info bytes belonging to a certain source coding layer in decreasing order of importance * : parity bytes gained from Reed-Solomon coding Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 12] =0C Internet Draft Unequal Erasure Protection July 2000 Fig. 4: General structure for UXP with inband signaling of redundancy profile 8. Security Considerations The issues addressed in this IETF draft are not subject to any security considerations. 9. References [1] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", Request for Comments 2733, Internet Engineering Task Force, Dec. 1999. [2] A. Albanese, J. Bloemer, J. Edmonds, M. Luby, and M. Sudan, "Priority encoding transmission", IEEE Trans. Inform. Theory, vol. 42, no. 6, pp. 1737-1744, Nov. 1996. [3] Shu Lin and Daniel J. Costello, Error Control Coding: Fundamentals and Applications, Prentice-Hall, Inc., Englewood Cliffs, N.J., 1983. [4] W. Li: "Fine Granularity Scalability Using Bit-Plane Coding of DCT Coefficients", ISO/IEC JTC1/SC29/WG11, Doc. MPEG98/M4204, Dec. 1998. [5] G. Blaettermann, G. Heising, and D. Marpe: "A Quality Scalable Mode for H.26L", ITU-T SG16, Q.15, Q15-J24, Osaka, May 2000. [6] F. Burkert, T. Stockhammer, and J. Pandel, "Progressive A/V coding for lossy packet networks - a principle approach", Tech. Rep., ITU-T SG16, Q.15, Q15-I36, Red Bank, N.J., Oct. 1999. [7] Guenther Liebl, "Modeling, theoretical analysis, and coding for wireless packet erasure channels", Diploma Thesis, Inst. for Communications Engineering, Munich University of Technology, 1999. 10. Acknowledgments Many thanks to Thomas Stockhammer, who initially came up with the idea of unequal erasure protection to improve progressive video transmission over lossy networks. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 13] =0C Internet Draft Unequal Erasure Protection July 2000 11. Author's Addresses Minh-Ha Nguyen, Guenther Liebl Institute for Communications Engineering (LNT) Munich University of Technology D-80290 Munich Germany Email: {nguyen,liebl}@lnt.ei.tum.de Bernhard Wimmer, Frank Burkert Siemens AG - ICM CD MP D-81675 Munich Germany Email: {bernhard.wimmer,frank.burkert}@mch.siemens.de Juergen Pandel Siemens AG - Corporate Technology ZT IK2 D-81730 Munich Germany Email: juergen.pandel@mchp.siemens.de Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 14] =0C Internet Draft Unequal Erasure Protection July 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES; EXPRESS OR IMPLIED; INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Nguyen, Liebl, Wimmer, Burkert, Pandel [Page 15] =0C ------_=_NextPart_000_01BFEDB7.6B880E60-- From rem-conf Fri Jul 14 13:40:42 2000 From rem-conf-request@es.net Fri Jul 14 13:40:42 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13DC7K-0003Zb-00; Fri, 14 Jul 2000 13:31:26 -0700 Received: from c017-h014.c017.sfo.cp.net (c017.sfo.cp.net) [209.228.12.228] by mail1.es.net with smtp (Exim 1.81 #2) id 13DC7J-0003TH-00; Fri, 14 Jul 2000 13:31:25 -0700 Received: (cpmta 2940 invoked from network); 14 Jul 2000 13:30:21 -0700 Received: from dnai-216-15-46-10.cust.dnai.com (HELO dhcp-168-0-6.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 14 Jul 2000 13:30:21 -0700 X-Sent: 14 Jul 2000 20:30:21 GMT Date: Fri, 14 Jul 2000 14:06:43 -0700 (Pacific Daylight Time) From: Stephen Casner To: Barry Haskell cc: Stephan Wenger , rem-conf@es.net, garysull@microsoft.com Subject: Re: letter from ITU video coding experts group In-Reply-To: <396F2406.EC7A2949@research.att.com> Message-ID: Sender: casner@mail.packetdesign.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephan, Barry, OK, perhaps I looked at the interoperability question from the wrong direction. If there are bitstreams that an H.263-2000 encoder would send that an H.263-1998 decoder can't handle because of additional appendices / annexes, then a new encoding name is required. I will add H263-2000 in the RTP MIME draft. > > Even referencing explicitly the November 2000 version of H.263 does not > > solve the problem, because people who buy H.263 in 2001 (with a potentially > > changed Appendix 1) would still receive a paper with the identical title, > > but containing the changed Appendix. If necessary, we can continue to define additional MIME types. That is why we reached the conclusion that we should make no more static RTP payload type number assignments. > PS Any thought of adding profile & level to MPEG2? Not sure what you are asking. There are some parameters specified for the MPEG audio and video MIME registrations in the rtp-mime draft. -- Steve From rem-conf Fri Jul 14 14:52:19 2000 From rem-conf-request@es.net Fri Jul 14 14:52:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13DDKc-0007Q3-00; Fri, 14 Jul 2000 14:49:14 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13DDKa-0007Pr-00; Fri, 14 Jul 2000 14:49:13 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-56.dialup.cs.tu-berlin.de [130.149.145.56]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id XAA23459; Fri, 14 Jul 2000 23:46:22 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000714233437.0289e690@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 14 Jul 2000 23:47:02 +0200 To: Stephen Casner , Barry Haskell From: Stephan Wenger Subject: Re: letter from ITU video coding experts group Cc: rem-conf@es.net, garysull@microsoft.com In-Reply-To: References: <396F2406.EC7A2949@research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Steve, Group, > > > Even referencing explicitly the November 2000 version of H.263 does not > > > solve the problem, because people who buy H.263 in 2001 (with a > potentially > > > changed Appendix 1) would still receive a paper with the identical title, > > > but containing the changed Appendix. > >If necessary, we can continue to define additional MIME types. That >is why we reached the conclusion that we should make no more static >RTP payload type number assignments. I fail to see the point here. Of course you can add MIME types. But what happens if WP3/16 decides to change Appendix II, but not to issue a 2001 version of H.263? They can do that any time they want. And you buy in 2002 something from the ITU-T that is still called H.263-2000, but is different from what was H.263-2000 in 2000. I agree with Barry and others that this is VERY unlikely to happen, but no procedure is in place to prevent such a change. Changes to appendices don't need to be upward/downward compatible or anything. They are in their very nature like informational RFCs or even less. For all those reasons there is no simplified negotiation system for H.32x systems. Well, there is one, sort of: In H.320's cap exchange protocol H.242, there is a shortcut for certain mode combinations that correspond to some of the profiles/levels. But the optional modes identified by those profiles/levels are spelled out again here, in a normative and unchangeable way. Stephan > > PS Any thought of adding profile & level to MPEG2? > >Not sure what you are asking. There are some parameters specified for >the MPEG audio and video MIME registrations in the rtp-mime draft. > > -- Steve From rem-conf Sat Jul 15 12:29:37 2000 From rem-conf-request@es.net Sat Jul 15 12:29:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13DXYA-0005BW-00; Sat, 15 Jul 2000 12:24:34 -0700 Received: from cs.columbia.edu [128.59.16.20] by mail1.es.net with esmtp (Exim 1.81 #2) id 13DXY9-0005BL-00; Sat, 15 Jul 2000 12:24:33 -0700 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA01930; Sat, 15 Jul 2000 15:24:32 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA13207; Sat, 15 Jul 2000 15:24:31 -0400 (EDT) Sender: hgs@cs.columbia.edu Message-ID: <3970BA6F.F122BF5F@cs.columbia.edu> Date: Sat, 15 Jul 2000 15:24:31 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com, rem-conf@es.net Subject: RFC 2833 ("tones") implementations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I would appreciate if implementors of RFC 2833 ("tones over RTP") could get in touch with me. I'd like to start identifying implementations and what features are used. Also, if anybody wants to support (or is already implementing) RTP (e.g., RFC 2833) over TCP, please let me know. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From rem-conf Sat Jul 15 21:34:11 2000 From rem-conf-request@es.net Sat Jul 15 21:34:10 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13DfuZ-0002EZ-00; Sat, 15 Jul 2000 21:20:15 -0700 Received: from (mail.bcb.com.my) [202.188.140.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13DfuW-0002E9-00; Sat, 15 Jul 2000 21:20:12 -0700 Received: from yo (ip240.birmingham8.mi.pub-ip.psi.net [38.27.137.240]) by mail.bcb.com.my with SMTP id MAA11172; Sun, 16 Jul 2000 12:20:27 -0500 (CDT) From: homecareer@aussiemail.com.au Message-Id: <200007161720.MAA11172@mail.bcb.com.my> To: Subject: Home Career Opportunity 990 Date: Sat, 15 Jul 2000 19:27:16 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_583A_0000490F.00003836" X-Priority: 3 X-MSMail-Priority: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ------=_NextPart_000_583A_0000490F.00003836 Content-Type: text/html; LOOKING FOR GEMS!

It's So Simple To Earn $2,000 - $5,000 Per Week Nowadays...
We're searching for only 10 elite individuals with the work ethic necessary to generate a cash-flow for themselves of $2,000 - $5,000per week, and to increase that to over $20,000 per month, in as little as four to six months. And you know what? If you really have a burning desire and commitment, we guarantee you that you'll reach this explosive income!

Can you read a short script to our qualified leads, and then turn the interested prospects over to our electronic sales medium? (you will not be required to do any selling.)Do you have the self-discipline to ignore the TV for a couple of hours per day? Are you looking for a legitimate home-based business opportunity, that is not multi-level marketing, or a chain-letter scheme?

If you would like to build an amazing income that will grow lightning-fast and have you profit $1,000.00 every time only one prospect makes a purchase, then this is for you! You can build the business under our guidance and support without having to attend meetings or sell people things they don't need.

Call NOW our TOLL FREE, PRE-RECORDED Message:1-800-320-9895 ext. 6215

We market a real product, that pays real commissions to you,$1,000.00 per sale, just for making the initial contacts. With our turn-key lead generation systems you'll always talk to people who actually WANT to talk to you.

You have nothing to lose, there's no risk involved, nor is there any obligation whatsoever, and you may be qualified to earn thousands of extra dollars per month! So call now!

The call is FREE, and there is absolutely no obligation, So what have you got to lose?

Call Toll Free 1-800-320-9895 ext. 6215

P.S. You literally have a once-in-a-lifetime opportunity to GET INVOLVED NOW! Don't let this one go by. You have absolutely nothing to lose! This could be the most fascinating and profitable business of your life!

Please, serious inquiries only.







To be removed from future mailings send a blank email with remove in the subject line and
the email address or addresses to be removed in the body to
homecareer@aussiemail.com.au

LOOKING FOR GEMS!


From rem-conf Sat Jul 15 23:15:14 2000 From rem-conf-request@es.net Sat Jul 15 23:15:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13DhcA-0003uo-00; Sat, 15 Jul 2000 23:09:22 -0700 Received: from (sky.bitband.com) [192.117.100.99] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Dhc7-0003ue-00; Sat, 15 Jul 2000 23:09:20 -0700 Received: from bitband.com (leonid [192.117.100.101]) by sky.bitband.com (8.8.8+Sun/8.8.8) with ESMTP id JAA28706; Sun, 16 Jul 2000 09:05:15 +0300 (IDT) Message-ID: <397154A6.4DA89AF5@bitband.com> Date: Sun, 16 Jul 2000 08:22:30 +0200 From: Leonid Rosenboim Reply-To: leonid@bitband.com Organization: BitBand Technologies Ltd. http://www.bitband.com X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "M. Reha Civanlar" CC: internet-drafts@ietf.org, rem-conf@es.net Subject: Re: draft-ietf-avt-rtp-mpeg4-03 References: <012901bfecfa$91c020d0$5182cf87@VTPC3> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I have a couple of comments: 1. The following goal is stated in the ID: i. Ability to synchronize MPEG-4 streams with other RTP payloads Could someone explain which other multimedia streams could be appropriate and are not supported as part of the MPEG-4 framework ? In toehr words, my impression is that MPEG-4 defines everything one could imagine, even a replacement to HTML for navigating content, so what else is there to synchronize with other then MPEG-4 ? 2. Regarding security: It has been quite a while since the security paragraph of the RTP specification has been written, and neother RTP nor this draft are addressing the security issues which are now central to every Internet service. In toehr words, following security issues should be addressed: A. How does this RTP profile handle pakcet filters and firewalls traversed by this payload traffic? B. What are (if any) the volnurabilities to Denial Of Service attacks exposed by implementing this payload format for a client or server ? One could reasonably argue that these issues do not belong in a payload specification, but rather in the RTP spec itself, but the is no work that I am aware of for revising the RTP spec, so how shall we address these issues? Hope this helps, Leonid Rosenboim Chief Technical Officer BitBand Technologies Ltd. "M. Reha Civanlar" wrote: > I am enclosing an updated version (03) of the ID entitled: > > RTP Payload Format for MPEG-4 Streams - draft-ietf-avt-rtp-mpeg4-03 > > This document describes a payload format for transporting MPEG-4 > encoded data using RTP. > > Thanks. > > ---------------------------------------------------------------------------- > ---------- > M. Reha Civanlar > Division Manager, AT&T Labs - Research > 100 Schultz Drive, 3-215, Red Bank, NJ 07701, U.S.A > Ph: +1 732 345 3305 > Fax: +1 732 345 3033 > civanlar@research.att.com > http://www.research.att.com/info/mrc > > ------------------------------------------------------------------------ > Name: draft-ietf-avt-rtp-mpeg4-03.txt > draft-ietf-avt-rtp-mpeg4-03.txt Type: Plain Text (text/plain) > Encoding: quoted-printable From rem-conf Mon Jul 17 00:26:50 2000 From rem-conf-request@es.net Mon Jul 17 00:26:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13E55n-0006Cc-00; Mon, 17 Jul 2000 00:13:31 -0700 Received: from (sky.bitband.com) [192.117.100.99] by mail1.es.net with esmtp (Exim 1.81 #2) id 13E55k-0006CS-00; Mon, 17 Jul 2000 00:13:29 -0700 Received: from bitband.com (leonid [192.117.100.101]) by sky.bitband.com (8.8.8+Sun/8.8.8) with ESMTP id KAA02149; Mon, 17 Jul 2000 10:09:52 +0300 (IDT) Message-ID: <3972B543.D1BF3095@bitband.com> Date: Mon, 17 Jul 2000 09:26:59 +0200 From: Leonid Rosenboim Reply-To: leonid@bitband.com Organization: BitBand Technologies Ltd. http://www.bitband.com X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: rem-conf@es.net CC: fukunaga444@oki.co.jp Subject: Re: low delay RTCP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Although I am new to this forum, I would like to contribute to this thread from my past experience: I agree with Shigeru san, Low Delay is contrary to Multicast, here is an additional reason: Many of today's switches, such as Layer2 Ethernet or ATM switches, implement Multicast in software, while switching normail unicast traffic in hardware. This leads to significant additional delay (as well as a potential throughput bottleneck) for any Multicast traffic when compared to Unicast traffic going through the same route. It is my understanding that for NEWPRED to be effective, low delay is essential, hence it is my opinion that the NEWPRED specification, as well as any other error handling mechanism which is sensitive to round-trip delay should be limitted to Unicast transport, and recommend the use of a dedicated reflector (a.k.a. MCU) for multiple participant applications. Hopt this input is useful. Leonid From rem-conf Mon Jul 17 03:41:24 2000 From rem-conf-request@es.net Mon Jul 17 03:41:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13E8IM-0001H8-00; Mon, 17 Jul 2000 03:38:42 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13E8IL-0001Gw-00; Mon, 17 Jul 2000 03:38:41 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24430; Mon, 17 Jul 2000 06:38:39 -0400 (EDT) Message-Id: <200007171038.GAA24430@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-interop-03.txt Date: Mon, 17 Jul 2000 06:38:39 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 Interoperability Statement Author(s) : C. Perkins Filename : draft-ietf-avt-rtp-interop-03.txt Pages : 6 Date : 14-Jul-00 It is required to demonstrate interoperability of RTP implementations in order to move the RTP specification to draft standard. This memo outlines those features to be tested, as the first stage of an interoperability statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-interop-03.txt 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-interop-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-ietf-avt-rtp-interop-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: <20000714143127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-interop-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-interop-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714143127.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Jul 17 03:41:24 2000 From rem-conf-request@es.net Mon Jul 17 03:41:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13E8IV-0001HX-00; Mon, 17 Jul 2000 03:38:51 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13E8IU-0001HM-00; Mon, 17 Jul 2000 03:38:50 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24486; Mon, 17 Jul 2000 06:38:48 -0400 (EDT) Message-Id: <200007171038.GAA24486@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-smpte292-video-00.txt Date: Mon, 17 Jul 2000 06:38:48 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for SMPTE 292M Author(s) : L. Gharai, G. Goncher, D. Richardson Filename : draft-ietf-avt-smpte292-video-00.txt Pages : 7 Date : 14-Jul-00 This document specifies a packetization scheme for encapsulating uncompressed HDTV as defined by SMPTE 292M [1] into a payload format for the Real-Time Transport Protocol (RTP). The RTP packet counter is extended to 26 bits to accommodate SMPTE 292M's 1.485Gb/s data rate, and additional positioning information is added to the payload header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-smpte292-video-00.txt 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-smpte292-video-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-ietf-avt-smpte292-video-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: <20000714142506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-smpte292-video-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-smpte292-video-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714142506.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Jul 17 03:41:24 2000 From rem-conf-request@es.net Mon Jul 17 03:41:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13E8IQ-0001HK-00; Mon, 17 Jul 2000 03:38:46 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13E8IP-0001HA-00; Mon, 17 Jul 2000 03:38:45 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24470; Mon, 17 Jul 2000 06:38:44 -0400 (EDT) Message-Id: <200007171038.GAA24470@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mpeg4-03.txt Date: Mon, 17 Jul 2000 06:38:44 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for MPEG-4 Streams Author(s) : R. Civanlar, A. Basso, S. Casner, C. Herpel, C. Perkins Filename : draft-ietf-avt-rtp-mpeg4-03.txt Pages : 11 Date : 14-Jul-00 This document describes a payload format for transporting MPEG-4 encoded data using RTP. MPEG-4 is a recent standard from ISO/IEC for the coding of natural and synthetic audio-visual data. Several services provided by RTP are beneficial for MPEG-4 encoded data transport over the Internet. Additionally, the use of RTP makes it possible to synchronize MPEG-4 data with other real-time data types. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force and ISO/IEC MPEG-4 ad hoc group on MPEG-4 over Internet. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mpeg4-03.txt 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-mpeg4-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-ietf-avt-rtp-mpeg4-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: <20000714143143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mpeg4-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mpeg4-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714143143.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Jul 17 03:44:26 2000 From rem-conf-request@es.net Mon Jul 17 03:44:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13E8NR-0001si-00; Mon, 17 Jul 2000 03:43:57 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13E8NQ-0001sP-00; Mon, 17 Jul 2000 03:43:56 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26644; Mon, 17 Jul 2000 06:43:54 -0400 (EDT) Message-Id: <200007171043.GAA26644@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-profile-interop-01.txt Date: Mon, 17 Jul 2000 06:43:54 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 Audio/Video Profile Interoperability Statement Author(s) : C. Perkins Filename : draft-ietf-avt-profile-interop-01.txt Pages : 5 Date : 14-Jul-00 It is required to demonstrate interoperability of implementations in order to move the RTP audio/video profile to draft standard. This memo outlines those features to be tested, as the first stage of an interoperability statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-interop-01.txt 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-profile-interop-01.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-profile-interop-01.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: <20000714142412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-interop-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-interop-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000714142412.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Jul 17 05:59:22 2000 From rem-conf-request@es.net Mon Jul 17 05:59:21 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EAPY-0006u7-00; Mon, 17 Jul 2000 05:54:16 -0700 Received: from soleil.uvsq.fr [193.51.24.1] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13EAPW-0006tx-00; Mon, 17 Jul 2000 05:54:14 -0700 Received: from lucifer.prism.uvsq.fr (lucifer.prism.uvsq.fr [193.51.25.7]) by soleil.uvsq.fr (8.9.3/jtpda-5.3.3) with ESMTP id OAA38597 for ; Mon, 17 Jul 2000 14:54:08 +0200 (CEST) Received: from ens.uvsq.fr (mac28.prism.uvsq.fr [193.51.25.228]) by lucifer.prism.uvsq.fr (8.9.3/jtpda-5.3.2) with ESMTP id OAA16114 for ; Mon, 17 Jul 2000 14:54:06 +0200 (MET DST) Message-ID: <397301F0.CC50EC74@ens.uvsq.fr> Date: Mon, 17 Jul 2000 14:54:08 +0200 From: AHMED Toufik X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: "'rem-conf@es.net'" Subject: ES_ID in RTP paquet for MPEG-4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi everyone, I would like to know why we can not used ES-ID just after RTP Header, if we assume that RTP/UDP/IP multiplexing scheme is used. I don't know if ES-ID already exists in the reduced SL-Header. best regards. From rem-conf Mon Jul 17 06:29:55 2000 From rem-conf-request@es.net Mon Jul 17 06:29:54 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EAx9-0000QR-00; Mon, 17 Jul 2000 06:28:59 -0700 Received: from uni02mr.unity.ncsu.edu [152.1.1.165] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EAx7-0000QG-00; Mon, 17 Jul 2000 06:28:57 -0700 Received: from yiyung (ppp20343.unity.ncsu.edu [152.1.245.33]) by uni02mr.unity.ncsu.edu (8.8.8/8.8.8/UR01Feb99) with SMTP id JAA29726; Mon, 17 Jul 2000 09:28:30 -0400 (EDT) Reply-To: From: "Injong rhee" To: , Subject: RE: low delay RTCP Date: Mon, 17 Jul 2000 09:35:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3972B543.D1BF3095@bitband.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I believe NEWPRED does not work with reflectors. However, retransmission can. There is some work in IETF-RMT that tries to come up with logical structure among receivers to handle feedback suppression and aggregation in multicast environments. I am not sure that it is wise to limit the low delay feedback to unicast only since it may not be the inherent feature of low delay feedback (i.e., well designed systems can handle it without hurting scalability). -----Original Message----- From: Leonid Rosenboim [mailto:leonid@bitband.com] Sent: Monday, July 17, 2000 3:27 AM To: rem-conf@es.net Cc: fukunaga444@oki.co.jp Subject: Re: low delay RTCP Although I am new to this forum, I would like to contribute to this thread from my past experience: I agree with Shigeru san, Low Delay is contrary to Multicast, here is an additional reason: Many of today's switches, such as Layer2 Ethernet or ATM switches, implement Multicast in software, while switching normail unicast traffic in hardware. This leads to significant additional delay (as well as a potential throughput bottleneck) for any Multicast traffic when compared to Unicast traffic going through the same route. It is my understanding that for NEWPRED to be effective, low delay is essential, hence it is my opinion that the NEWPRED specification, as well as any other error handling mechanism which is sensitive to round-trip delay should be limitted to Unicast transport, and recommend the use of a dedicated reflector (a.k.a. MCU) for multiple participant applications. Hopt this input is useful. Leonid From rem-conf Mon Jul 17 06:57:22 2000 From rem-conf-request@es.net Mon Jul 17 06:57:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EBKj-0001VO-00; Mon, 17 Jul 2000 06:53:21 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EBKh-0001VE-00; Mon, 17 Jul 2000 06:53:19 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id JAA05024; Mon, 17 Jul 2000 09:53:40 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id SAA27776; Mon, 17 Jul 2000 18:53:15 +0500 Message-Id: <200007171353.SAA27776@hafez.east.isi.edu> To: leonid@bitband.com cc: rem-conf@es.net, fukunaga444@oki.co.jp Subject: Re: low delay RTCP In-Reply-To: Your message of "Mon, 17 Jul 2000 09:26:59 +0200." <3972B543.D1BF3095@bitband.com> Date: Mon, 17 Jul 2000 09:53:14 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Leonid Rosenboim writes: >Although I am new to this forum, I would like to contribute to this >thread from my past experience: > > I agree with Shigeru san, Low Delay is contrary to Multicast, here is >an additional reason: > >Many of today's switches, such as Layer2 Ethernet or ATM switches, >implement Multicast in software, while switching normail unicast traffic >in hardware. This leads to significant additional delay (as well as a >potential throughput bottleneck) for any Multicast traffic when compared >to Unicast traffic going through the same route. Whilst this is undoubtably true, it's a temporary implementation limitation rather than an inherent feature of multicast. > It is my understanding that for NEWPRED to be effective, low delay is >essential, hence it is my opinion that the NEWPRED specification, as well >as any other error handling mechanism which is sensitive to round-trip >delay should be limitted to Unicast transport, and recommend the use of a >dedicated reflector (a.k.a. MCU) for multiple participant applications. I disagree. It's true that NEWPRED should be restricted to small numbers of participants (due to the difficulty of getting timely feedback), but this does not necessarily imply that it cannot be used with multicast (just that such use must be carefully controlled). Colin From rem-conf Mon Jul 17 07:29:42 2000 From rem-conf-request@es.net Mon Jul 17 07:29:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EBq6-0002ds-00; Mon, 17 Jul 2000 07:25:46 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EBq4-0002dg-00; Mon, 17 Jul 2000 07:25:44 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id KAA05549; Mon, 17 Jul 2000 10:26:06 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id TAA27917; Mon, 17 Jul 2000 19:25:40 +0500 Message-Id: <200007171425.TAA27917@hafez.east.isi.edu> To: leonid@bitband.com cc: rem-conf@es.net, 4on2andIP-sys@advent.ee.columbia.edu Subject: Re: draft-ietf-avt-rtp-mpeg4-03 In-Reply-To: Your message of "Sun, 16 Jul 2000 08:22:30 +0200." <397154A6.4DA89AF5@bitband.com> Date: Mon, 17 Jul 2000 10:25:40 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [4-on-IP list cc'd for comments...] --> Leonid Rosenboim writes: >I have a couple of comments: > >1. The following goal is stated in the ID: > i. Ability to synchronize MPEG-4 streams with other RTP payloads >Could someone explain which other multimedia streams could be appropriate and >are not supported as part of the MPEG-4 framework ? In toehr words, my >impression is that MPEG-4 defines everything one could imagine, even a >replacement to HTML for navigating content, so what else is there to synchronize >with other then MPEG-4 ? The installed base of H.323 terminals, SIP terminals, RealAudio, etc., none of which support MPEG-4. >2. Regarding security: > >It has been quite a while since the security paragraph of the RTP specification >has been written, and neother RTP nor this draft are addressing the security >issues which are now central to every Internet service. In toehr words, >following security issues should be addressed: > > A. How does this RTP profile handle pakcet filters and firewalls traversed by >this payload traffic? > B. What are (if any) the volnurabilities to Denial Of Service attacks exposed >by implementing this payload format for a client or server ? Indeed, the current security considerations section is lacking for this payload format, given the broad range of content MPEG-4 may transport (the second paragraph in particular is not accurate). At the least, we should discuss the different types of content which may be transported in MPEG-4 and their risks (e.g. streaming java code in MPEG-4 via MPEG-J). The points you raise are also important - I wonder if the correct place to handle them is in the RTP payload format, or in the MPEG specification (or, more likely, both)? Does MPEG discuss the security implications of it's framework? I note that draft-ietf-avt-mpeg4streams-00.txt has similar deficiencies in its security considerations section. And someone more familiar with MPEG-4 should view draft-ietf-avt-rtp-mpeg4-es-02.txt and check that it is okay. >One could reasonably argue that these issues do not belong in a payload >specification, but rather in the RTP spec itself, but the is no work that I am >aware of for revising the RTP spec, so how shall we address these issues? The RTP specification is in the process of being revised, see http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-07.txt http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-08.txt (I believe there is a new revision of these due for this meeting). We would welcome additions to the security considerations section of this, or of any payload format. Cheers, Colin From rem-conf Mon Jul 17 07:40:49 2000 From rem-conf-request@es.net Mon Jul 17 07:40:48 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EC3W-0003bT-00; Mon, 17 Jul 2000 07:39:38 -0700 Received: from (sky.bitband.com) [192.117.100.99] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EC3U-0003bD-00; Mon, 17 Jul 2000 07:39:36 -0700 Received: from bitband.com (leonid [192.117.100.101]) by sky.bitband.com (8.8.8+Sun/8.8.8) with ESMTP id RAA03973; Mon, 17 Jul 2000 17:35:58 +0300 (IDT) Message-ID: <39731DD3.A0B2D5B6@bitband.com> Date: Mon, 17 Jul 2000 16:53:07 +0200 From: Leonid Rosenboim Reply-To: leonid@bitband.com Organization: BitBand Technologies Ltd. http://www.bitband.com X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: rhee@eos.ncsu.edu CC: rem-conf@es.net Subject: Re: low delay RTCP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list By reflectors I mean application-specific units, a.k.a. MCUs which not only reflect but TRANSCODE the streams, switch between sources and all sorts of intelligent media-aware functionality which makes a video conferense a paletable experience. There is much experience already around such units developed for the H.320 (VideoConf over ISDN) environment. Media-aware MCUs which do transcoding can definitely be NEWPRED peers to every client. Leonid Injong rhee wrote: > I believe NEWPRED does not work with reflectors. However, retransmission > can. There is some work in IETF-RMT that tries to come up with logical > structure among receivers to handle feedback suppression and aggregation > in multicast > environments. I am not sure that it is wise to limit the low delay > feedback to unicast only since it may not be the inherent feature of > low delay feedback (i.e., well designed systems can handle it without > hurting scalability). > > -----Original Message----- > From: Leonid Rosenboim [mailto:leonid@bitband.com] > Sent: Monday, July 17, 2000 3:27 AM > To: rem-conf@es.net > Cc: fukunaga444@oki.co.jp > Subject: Re: low delay RTCP > > Although I am new to this forum, I would like to contribute to this > thread from my past experience: > > I agree with Shigeru san, Low Delay is contrary to Multicast, here is > an additional reason: > > Many of today's switches, such as Layer2 Ethernet or ATM switches, > implement Multicast in software, while switching normail unicast traffic > in > hardware. This leads to significant additional delay (as well as a > potential > throughput bottleneck) for any Multicast traffic when compared to > Unicast traffic > going through the same route. > > It is my understanding that for NEWPRED to be effective, low delay is > essential, > hence it is my opinion that the NEWPRED specification, as well as any > other error > handling mechanism which is sensitive to round-trip delay should be > limitted to Unicast > transport, and recommend the use of a dedicated reflector (a.k.a. MCU) > for multiple > participant applications. > > Hopt this input is useful. > > Leonid From rem-conf Mon Jul 17 07:48:27 2000 From rem-conf-request@es.net Mon Jul 17 07:48:27 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ECAy-0004ID-00; Mon, 17 Jul 2000 07:47:20 -0700 Received: from (sky.bitband.com) [192.117.100.99] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ECAv-0004Hj-00; Mon, 17 Jul 2000 07:47:18 -0700 Received: from bitband.com (leonid [192.117.100.101]) by sky.bitband.com (8.8.8+Sun/8.8.8) with ESMTP id RAA03992; Mon, 17 Jul 2000 17:43:43 +0300 (IDT) Message-ID: <39731FA4.7EEF3EAE@bitband.com> Date: Mon, 17 Jul 2000 17:00:53 +0200 From: Leonid Rosenboim Reply-To: leonid@bitband.com Organization: BitBand Technologies Ltd. http://www.bitband.com X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Colin Perkins CC: rem-conf@es.net, fukunaga444@oki.co.jp Subject: Re: low delay RTCP References: <200007171353.SAA27776@hafez.east.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin Perkins wrote: > [snip] > >Many of today's switches, such as Layer2 Ethernet or ATM switches, > >implement Multicast in software, while switching normail unicast traffic > >in hardware. This leads to significant additional delay (as well as a > >potential throughput bottleneck) for any Multicast traffic when compared > >to Unicast traffic going through the same route. > > Whilst this is undoubtably true, it's a temporary implementation limitation > rather than an inherent feature of multicast. > You should better ask some people who actually design switches for a living before making such a statement. Personally I do not believe that Multicast is EVER going to be implemented in hardware, but I am not a switch impelentor myself, I just talk to other people who are. > > [snip] > > I disagree. It's true that NEWPRED should be restricted to small numbers of > participants (due to the difficulty of getting timely feedback), but this > does not necessarily imply that it cannot be used with multicast (just that > such use must be carefully controlled). > > Colin I am not saying that you can not use NEWPRED on Multicast, I am only suggesting not to STANDARDIZE it for the time being. If you FOCUS the spec on practical needs and application, the spec will be ready sooner and will yield more interoperable implementations thus. And NEWPRED on MC certainly does not look practical for the foreseeable future. Leonid From rem-conf Mon Jul 17 07:59:30 2000 From rem-conf-request@es.net Mon Jul 17 07:59:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ECLY-0005Jv-00; Mon, 17 Jul 2000 07:58:16 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ECLX-0005Jk-00; Mon, 17 Jul 2000 07:58:15 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id KAA06049; Mon, 17 Jul 2000 10:58:36 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id TAA28092; Mon, 17 Jul 2000 19:58:10 +0500 Message-Id: <200007171458.TAA28092@hafez.east.isi.edu> To: leonid@bitband.com cc: rem-conf@es.net, fukunaga444@oki.co.jp Subject: Re: low delay RTCP In-Reply-To: Your message of "Mon, 17 Jul 2000 17:00:53 +0200." <39731FA4.7EEF3EAE@bitband.com> Date: Mon, 17 Jul 2000 10:58:10 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Leonid Rosenboim writes: >Colin Perkins wrote: ... >> I disagree. It's true that NEWPRED should be restricted to small numbers of >> participants (due to the difficulty of getting timely feedback), but this >> does not necessarily imply that it cannot be used with multicast (just that >> such use must be carefully controlled). > >I am not saying that you can not use NEWPRED on Multicast, I am only suggesting >not to STANDARDIZE it for the time being. If you FOCUS the spec on practical >needs and application, the spec will be ready sooner and will yield more >interoperable implementations thus. And NEWPRED on MC certainly does not >look practical for the foreseeable future. If supporting multicast significantly complicates the spec, and there is a tight deadline, then I agree with you. Just lets not blind ourselves with NEWPRED is unicast only, and accidently design something which prohibits multicast use in future. Colin From rem-conf Mon Jul 17 08:02:07 2000 From rem-conf-request@es.net Mon Jul 17 08:02:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ECOE-0005Zi-00; Mon, 17 Jul 2000 08:01:02 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ECOC-0005Yv-00; Mon, 17 Jul 2000 08:01:01 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id LAA06140; Mon, 17 Jul 2000 11:01:23 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id UAA28126; Mon, 17 Jul 2000 20:00:58 +0500 Message-Id: <200007171500.UAA28126@hafez.east.isi.edu> To: Henning Schulzrinne cc: sip@lists.bell-labs.com, rem-conf@es.net Subject: Re: RFC 2833 ("tones") implementations In-Reply-To: Your message of "Sat, 15 Jul 2000 15:24:31 EDT." <3970BA6F.F122BF5F@cs.columbia.edu> Date: Mon, 17 Jul 2000 11:00:58 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Henning Schulzrinne writes: >I would appreciate if implementors of RFC 2833 ("tones over RTP") could >get in touch with me. I'd like to start identifying implementations and >what features are used. > >Also, if anybody wants to support (or is already implementing) RTP >(e.g., RFC 2833) over TCP, please let me know. And whilst you're doing this, please review the drafts discussing RTP interoperability requirements (draft-ietf-avt-rtp-interop-03.txt and draft-ietf-avt-profile-interop-01.txt), and send me a brief report on your implementtion, so we can advance RTP to draft standard. Thanks! Colin From rem-conf Mon Jul 17 08:15:26 2000 From rem-conf-request@es.net Mon Jul 17 08:15:25 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ECam-00073O-00; Mon, 17 Jul 2000 08:14:00 -0700 Received: from bettina.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ECak-00073A-00; Mon, 17 Jul 2000 08:13:59 -0700 Received: from cabo2 (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e6HFDYx25004; Mon, 17 Jul 2000 17:13:37 +0200 (MET DST) From: "Dr. Carsten Bormann" To: , "Colin Perkins" Cc: , Subject: RE: low delay RTCP Date: Mon, 17 Jul 2000 17:13:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <39731FA4.7EEF3EAE@bitband.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Personally I do not believe that > Multicast is EVER > going > to be implemented in hardware, This whole discussion is a red herring. Of course there are switches where multicast is a few hundred microseconds slower than unicast. NEWPRED becomes less effective when you delay it on the order of complete frames, i.e. multiples of 20 ms or up. Conclusion: Switch performance should be entirely irrelevant at this order of magnitude. Gruesse, Carsten PS.: I'm not talking about historic switches that are totally defective in the multicast area such as the 3com switch 1000. (Please remind me of other switches where the above conclusion is not true -- I'll make sure not to buy them...) From rem-conf Mon Jul 17 11:38:15 2000 From rem-conf-request@es.net Mon Jul 17 11:38:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EFgf-0002GO-00; Mon, 17 Jul 2000 11:32:17 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13EFgd-0002GE-00; Mon, 17 Jul 2000 11:32:15 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-190.dialup.cs.tu-berlin.de [130.149.145.190]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id UAA20522 for ; Mon, 17 Jul 2000 20:26:28 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000717200830.02a7cf00@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jul 2000 20:09:44 +0200 To: rem-conf@es.net From: Stephan Wenger Subject: Fwd: Submission of draft-wenger-avt-rtcp-feedback-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Group, Apologies for sending this draft to rem-conf late. It was submitted as an individual contribution to the I-D editor last Friday. Stephan > INTERNET-DRAFT Stephan > Wenger > draft-wenger-avt-rtcp-feedback-00.txt TU > Berlin > >Joerg Ott > Universitaet > Bremen TZI > > July 14, > 2000 > Expires December > 2000 > > > RTCP-based Feedback for Predictive Video Coding > > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with all > provisions of Section 10 of RFC 2026. Internet-Drafts are working > documents of the Internet Engineering Task Force (IETF), its areas, and > its working groups. Note that other groups may also distribute working > documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet- Drafts as reference > material > or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > > > 0. Open Issues > > 1) Should the draft limit itself to supporting feedback for video only > or should it target a more general solution for feedback? At the > moment, the draft covers only video. > > 2) Should the feedback be restricted to point-to-point scenarios or > should we support (small group) multicast. At the moment, the draft > is designed to scale to (small) group. > > 3) Feedback traffic explosion is prevented by a) dithering and b) > damping. a) somewhat poses constraints on timely transmission of > feedback. b) prevents that the encoder can learn about the > _severeness_ of a loss problem (e.g. how many receivers have now a > bad picture). This prevents adaptive encoder reaction based on the > > perceived quality of the whole group. At the moment, a) and b) are > both to be used to be network friendly. Which mechanisms (besides > flooding the network which we want to avoid) are conceivable to > support an approach that is able to achieve a better perceived > picture quality? > > > > > Wenger/Ott Expires December 2000 [Page 1] > > > > > > Internet Draft July 14, 2000 > > > 4) Is the maximum number of MBs 8191 for SLI sufficient? Yes for MPEG- > 1, MPEG-2 and ITU-T H.261, H.263. What about MPEG-4? > > 5) Should there be a special mode (possibly optimized for > point-to-point > communication) that allows UMs packets without RR (see section 3)? > > 6) RPS/NEWPRED also make use of positive acknowledgements. Obviously, > this does inherently not scale to multicast. Should there be a > point-to-point mode that allows positive ACKs? > > 7) We have not yet considered the use of layered codecs. When > transporting each layer in its own RTP stream, everything should be > ok. If not, then we can foresee problems. > > 8) Section 7 on NEWPRED needs more work (probably based on Fukunaga et. > al draft). > > 9) Further work is needed on maximum group size estimation for using > feedback and on more detailed guidelines on calculating the maximum > dithering delay for Early RRs (T_dither_max) per UM type. > > 10) > Further investigations are desirable for the Early RR/UM scheduling > and damping and the relationship of Early RR/UM scheduling to > regular > RTCP report scheduling. > > > 1. Abstract > > Predictive video coding is not loss resilient. Any loss of coded > data leads to annoying artifacts not only in the reproduced picture > in which the loss occurred, but also in subsequent pictures. Error > resilience can be achieved by spending bits to convey redundant > information using source coding based mechanisms or transport based > mechanisms. This can be done without the use of any feedback > between > the decoder(s) and the encoder. > > Alternatively, where applicable, decoders can inform the encoder > through a feedback channel about a loss situation, and the encoder > can react accordingly. This approach provides better picture > quality > and is more efficient with respect to the bandwidth used by the > encoder to achieve a given quality. However, using feedback > mechanisms is limited to certain application scenarios identified by > encoder characteristics, delay constraints, and/or the number of > recipients. This document discusses various types of feedback > information (called _upstream messages_, UMs) for predictive video > coding and defines an RTCP packet format to transmit UMs in an RTP > environment. It can be used in conjunction with all payload > specifications for predictive video coding schemes currently > available for RTP. To reflect the need for very low delay for the > > transmission of the UMs, which is necessary to make them efficient, > the rules for sending receiver reports are enhanced to support Early > Receiver Report (Early RRs) and an algorithm is specified that > allows > > > > > Wenger/Ott Expires December 2000 [Page 2] > > > > > > Internet Draft July 14, 2000 > > > for low delay in small multicast groups, but prevents network > flooding. > > 2. Introduction > > 2.1. Video Encoder-decoder synchronicity > > Most current video coding schemes for compressed video, such as the > ITU-T H.261 and H.263 and ISO/IEC MPEG[124] employ a mechanism known > as Inter Picture Prediction. Each picture is divided into > macroblocks of uniform size. For each macroblock, one or more > motion vectors may be identified and transmitted. The residual > signal after motion compensation is DCT-transformed, quantized, > entropy coded, and transmitted as well. The encoder reconstructs, > based on this information, a so-called reference picture, which is > used to perform the motion compensation and residual signal coding > steps for the subsequent picture. Since the reference picture is > generated using only such information that is also available at the > decoder, the reference picture is identical to the reconstructed > picture at the decoder. Having identical reference pictures at the > encoder and decoder is referred to as encoder-decoder-synchronicity. > > Whenever data is damaged or lost on the way between the encoder and > the decoder, the reconstructed picture at the decoder is no more > identical with the encoder's reference picture -- the > encoder-decoder > synchronicity is lost. > > Any loss of the encoder-decoder synchronicity results in annoying > artifacts at the decoder. Because the prediction of subsequent > pictures in the decoder is based on a damaged reference picture, the > annoying artifacts are present not only in the picture in which the > loss occurred; they propagate to all subsequent pictures, until, > through source coding based mechanisms, the encoder-decoder > synchronicity is restored. Therefore, the goal of systems employing > predictive video coding in a lossy environment must be to keep the > encoder-decoder synchronicity, or, if this is not possible, to > regain > that synchronicity as quickly as possible. > > 2.2. Non-feedback based mechanisms > > Avoiding the loss of the encoder-decoder synchronicity > corresponds to > avoiding the loss of coded picture data. Such a task can be > performed on the transport layer. In RTP environments, the use of > packet-based FEC is a good example for such a technique. (The use of > TCP or reliable multicast as the transport for media streams > would be > an even better one but is inappropriate for low-delay (interactive) > real-time systems.) FEC schemes, interleaving, and other means for > > repairing real-time media streams may also add additional delay and > significant bit rate overhead without being able to guarantee > compensation of virtually all packet losses. > > > > > > > Wenger/Ott Expires December 2000 [Page 3] > > > > > > Internet Draft July 14, 2000 > > > Once the encoder-decoder synchronicity is lost, only source coding > oriented mechanisms can help to regain it. One common way is to > send > a non predictively coded picture (known as Intra picture). Intra > pictures have the disadvantage of being several times bigger than > predictively coded pictures (Inter pictures). Therefore, sending > Intra pictures has negative implications both on the bandwidth and > (in bandwidth limited environments) delay. Another way is to use > Intra macroblock refresh. Here, certain parts of the picture (those > affected by a packet loss) are coded non predictively in order to > resynchronize the encoder and decoder over time. Intra macroblock > refresh has better delay characteristics then full Intra pictures > because the picture size can be kept constant, but is less efficient > in terms of bit rate/distortion than full Intra pictures. More > sophisticated means such as Reference Picture Selection (RPS) are > also available in modern video coding standards. > > Systems not employing feedback channels may use any combination of > the mechanisms described above to add error resilience -- at the > cost > of added bit rate and, sometimes, added delay. The number of > additional bits spent for error resilience can be adapted using the > long-term packet loss rate information in the RTCP receiver reports. > But, even when using such adaptive means, it is still likely that > systems spend many more bits then theoretically necessary to achieve > error resilience in order to be on the safe side. Plus, as regular > RTCP feedback is aimed at longer terms, reactivity to sudden losses > is limited. In all practical applications today this means that > fewer bits are available for non redundant picture data, and hence > the overall picture quality suffers. > > 2.3 Feedback based systems > > Feedback-based systems try to avoid spending too many bits for > redundant information by informing the encoder about a loss > situation > at the decoder(s). The encoder can then react accordingly and spend > redundant bits only when needed possibly only for the part of the > picture that was effected by the loss -- thereby reducing the number > of redundant bits and leaving more bits for useful > information. As a > result, a higher reproduced picture quality can generally be > expected > when feedback channels are available. > > Similar to the observations of section 2.2, transport and source > coding based mechanisms can be distinguished that react on loss > > situations reported by feedback. > > Transport based systems employing feedback react media unaware, by > re-transmitting lost packets. TCP is a good example for a protocol > following such a scheme. Transport-based feedback in real-time > and/or multicast environments is a complex matter and subject of a > lot of engineering and research in and outside of the IETF. This > specification is not concerned with pure transport-based feedback. > > > > > > > Wenger/Ott Expires December 2000 [Page 4] > > > > > > Internet Draft July 14, 2000 > > > Source coding based mechanisms may react upon the arrival of an > upstream message indicating a loss situation by adding bits that > restore, or at least make an effort to restore, the encoder-decoder > synchronicity. This process has to be performed by a real-time > encoder. However, schemes were reported, that allow the use of > feedback also for non-real-time encoders by storing multiple > representations of the same data (e.g. Inter and Intra coded), and > dynamically switching between those representations. > > Several types of feedback messages, called Upstream Messages or UMs, > are defined in this specification. A UM can be as simple as a > Boolean condition, indicating for example the loss of a full picture > (and, therefore, the need of a full Intra picture transmission). > Other feedback messages may contain more complex information such as > information about the damage of a spatial region of the picture. A > special form consists of a message the format and semantics of which > are not known at the transport level, because they are defined > in the > video codec standards. > > Most UMs contain negative acknowledge information, indicating an > erroneous situation at the decoder. In others, the nature of the > acknowledge (positive, negative, or both) is part of the feedback > message itself. When used in multicast environments, positive > acknowledge MUST NOT be used. > > This document assumes that feedback messages are transmitted using > RTCP packets. RTCP messages from the receivers to the sender cannot > be send at any possible time, in order to prevent traffic explosion > in case of large multicast groups. Instead, the bit rate for all > RTCP messages of all receivers together has to obey a maximum > fraction of the total RTP session bit rate, yielding a very limited > bit rate budget for a single receiver when having a large multicast > group. This, in turn, leads to an increased average delay when the > size of the receiving multicast group grows. (see section 6 of > draft-ietf-avt-rtp-new-06.txt for details) > > This specification defines an algorithm that adheres to the bit rate > limitations for the feedback channel on the long term, but allows > short-term overdrafting for any receiver (but not all of them > > simultaneously). Thus, the algorithm allows for better real-time > performance then the one specified in draft-ietf-avt-rtp-new-06.txt. > Traffic explosion in such cases in which many receivers identify a > picture damage simultaneously is prevented by dithering. > > As this specification assumes a real-time encoder that has full > control over its transmission bit rate, there is no scaling problem > on the forward channel. Any reaction to negative feedback generates > additional bits, which have to be conveyed but this is taken > from the > sender's total bit rate budget. The encoder can take this into > account by, for example, sending fewer pictures per second, > lower the > quality and bit rate by changing quantization parameters and so > forth. The sender is also free to simply ignore feedback messages. > > > > > Wenger/Ott Expires December 2000 [Page 5] > > > > > > Internet Draft July 14, 2000 > > > Adjusting the tradeoff between the reproduced picture quality of all > receivers of a multicast group and the amount of bits spent for > encoder-decoder re-synchronization is a very complex task and is not > covered in this specification. > > This document currently covers feedback messages for a Picture Loss > Indication (PLI), Slice Loss Indication (SLI), and Reference Picture > Selection Indication (RPSI). PLI indicates the loss of a full > picture and roughly corresponds to the Fast Intra Request known from > H.320 systems and from RFC 2032 (H261 packetization). Algorithms > using SLI can be found under the acronym Automatic Repeat Request > (ARQ) in the signal processing literature. Reference Picture > Selection, aka NEWPRED, is available in certain profiles of MPEG-4 > (version 2 and later) and as an optional mode in H.263 (version > 2 and > later). The packet format specified in this document is open to > extensions so that future feedback mechanisms can easily be > integrated. > > > 2.4. Applications and Relationships to other Standards > > This specification is based on RTCP, which implies its use in an RTP > environment. RTP itself is used in a variety of systems such as in > SIP- or H.323-based multimedia conferencing/telephony. > > As for the video codecs, there is currently a small set of standards > that are, for the purpose of this discussion, roughly comparable. > Many mechanisms for regaining encoder-decoder synchronicity are > applicable to all video codecs. Others require certain tools (such > as Reference Picture Selection, aka NEWPRED) that are available only > in certain versions of the standards, and/or optional tools > whose use > must be negotiated prior to being used. > > A few RTP payload specifications such as RFC 2032 already define a > feedback mechanism for some of the coding algorithms considered in > this specification. An application capable of performing both > > schemes MUST use the feedback mechanism defined in this > specification, although, for backward compatibility reasons, it MUST > also be capable to conform to the feedback scheme defined in the > respective RTP payload format, if this is required by that payload > format. > > 2.5 Remarks on the size of the multicast group > > This specification makes an attempt to prevent traffic explosion on > the feedback channel in a very similar way as RTP does, with the > exception of allowing individual receivers to overdraft their bit > rate budget from time to time. This is necessary in order to allow > for low delay, which is needed by the algorithms reacting to UMs. > > This scaling, however, limits the usefulness of this mechanism in > multicast groups from a certain size upwards (where the size > > > > > Wenger/Ott Expires December 2000 [Page 6] > > > > > > Internet Draft July 14, 2000 > > > threshold depends on a number of parameters including loss rate, > frame rate). The maximum size of the multicast group is not > specified here (which is soft and also depends on application > requirements). The authors have done some rough calculations (for > which it is too early to present them here in detail) that suggest > that feedback is not expected to yield acceptable results for group > sizes larger then 10 receivers (often less than five), assuming > today's network conditions (RTT, loss rate) and common bit rates. > > 2.6 Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119 [xxx] > > > 3. Low delay RTCP Feedback > > UMs are part of the RTCP control streams and are thus subject to the > same bandwidth constraints as other RTCP traffic. This means in > particular, that it may not be possible to report a packet loss at a > receiver immediately back to the sender. However, the value of > feedback given to a sender typically decreases over time -- in terms > of the media quality as perceived by the user at the receiving end > and/or the cost required to achieve media stream repair. > > RFC1889bis (i.e. draft revision draft-ietf-avt-rtp-new-06.txt) > specifies rules when RTCP receiver reports (RRs) should be sent. > This specification modifies those rules in order to allow > applications to timely report damaged pictures, since most > algorithms > that use UMs are very critical to the UM timing. See section 5 and > following for a discussion of the impact of delay on the performance > of each UM type. > > The modified algorithm can be outlined as follows: Normally, when no > UMs have to be conveyed, RRs are sent following the rules of > RFC1889bis. If one or more receivers detect the need for an UM, the > > receiver first checks whether it has already seen a corresponding UM > from any other receiver (which it can do as UMs are transmitted via > multicast). If this is the case then the receiver refrains from > sending the UM, and continues to follow the regular RR sending > schedule. If the receiver has not yet seen a similar UM from any > other receiver, it checks whether it has already overdrafted its > RTCP > bit rate budget before (without waiting for its regularly scheduled > RR time). Only if this is not the case, it sends the UM, after > waiting a short, random dithering interval period. Note that always > a complete RR is sent in addition to the UM, in order to a) follow > the rules for compound packets, and b) make sure that a sufficiently > large number of RRs from each receiver is transmitted. Considering > the overhead for IP and UDP packets, it is believed that these > advantages outweigh the disadvantage of preventing RTCP packets that > contain only UMs. > > > > > Wenger/Ott Expires December 2000 [Page 7] > > > > > > Internet Draft July 14, 2000 > > > > 3.1. Definitions > > [Note: not all are used in this first revision of the draft.] > > a) Let the video stream be transmitted at a (roughly) constant frame > rate f (in frames per second). This results in an inter-frame > time period of tau=1/f if frame are sent in regular intervals. > > b) For timing considerations, we assume that a single frame is > always > carried in a single packet. If a frame does not fit into the > MTU, > then the frame is split across several packets. Gaps are then > measured between always the first or always the last packet of a > frame. For later considerations on feedback delay, if a frame is > split its packets are paced for transmission (rather than sent as > a burst) over some time period T_split, this can be modeled as a > _constant_ added to the overall transmission delay from the > sender > to the receiver. > > c) Let T_rtt be the maximum round trip time as measured by RTCP. > Note that this may be asymmetric. > > d) Let T_jitter be the maximum jitter measured from a sender to a > receiver. > > e) Let t_rr and t_(rr-1) be the time for the next (last) scheduled > RTCP RR transmission calculated prior to reconsideration. > Let T_rr + t_(rr-1) = t_rr. (In the RFC1889bis draft these are > termed tp, tn, respectively). > > f) Let t_e be the time for which a feedback packet is scheduled. > > g) Let t_dither_max be the maximum interval for which an RTCP > feedback packet may be additionally delayed (to prevent > implosions). > > h) Let T_fd be the delay for the feedback message that a certain > packet to return to the sender after. > > > i) Let S be the number of active senders in the RTP session. > > j) Let N be the current estimate of the number of receivers in the > RTP session. > > > 3.2. RTCP Feedback > > The feedback situation for a packet loss at a receiver is > depicted in > figure 1 below. At time t0, a packet loss is detected at the > receiver. The receiver decides -- based upon current T_rtt, group > size, and other (application-specific) parameters -- that a certain > type of feedback information shall be sent back to the sender. > > > > > Wenger/Ott Expires December 2000 [Page 8] > > > > > > Internet Draft July 14, 2000 > > > > To avoid an implosion of immediate feedback packets, the receivers > delays transmission of the feedback packet(an Early RTCP RR/FB > packets) by a random amount T_fd (with the random number evenly > distributed in the interval [0, T_dither_max]. Transmission of > the RTCP RR/FB is then scheduled for t_e = t0 + T_fd. > > The T_dither_max parameter depends on the feedback algorithm used > (PLI, SLI, RPSI) and needs to take into account a number of other > parameters (such as the estimated round-trip time) to limit the > upper > bound for the feedback in a way that ensures that the feedback > information still makes sense when it reaches the sender. > > If an RTCP feedback packet is scheduled, the time slot for the next > scheduled RTCP RR is updated accordingly to a new t_rr taken from > the interval [t_(rr-1) + 2*T_rr, t_e + 2*T_rr] (with T_rr being the > newly calculated deterministic RTCP interval. > > > pkt loss > detected > | > | RTCP feedback > vXXXXXXXXXXXXXXXXXXXX ) ) > |---+--------+-------------+-----+------------| |--------+---------> > | | | | ( ( | > | t0 te | > t_(rr-1) t_rr > \_______ ________/ > \/ > T_dither_max > > > Figure 1: Packet loss and parameters for Early RR scheduling > > > > 3.3. Early RR/UM Algorithm > > Assume an active sender S0 (out of S senders) and a number N of > receivers with R being one of these receivers. > > Assume further that R has verified that using feedback mechanisms is > reasonable at the current constellation (which is highly application > specific and hence not specified in this document at the moment; a > future revision may contain more detailed guidelines to this end). > > Then, the following rules apply to transmitting an Upstream Messages > (UM) as compound packet with RTCP RR and possibly other information. > This compound RTCP packet is referred to as _RTCP RR/UM_. > > > Initially, R sets allow_early=TRUE. > > > > > Wenger/Ott Expires December 2000 [Page 9] > > > > > > Internet Draft July 14, 2000 > > > > At a point in time t0, R has transmitted the last RTCP RR packet at > t_(rr-1) and has scheduled the next transmission (prior to > reconsideration) for t_rr. > > If R detects a packet loss at time t0 then R should check first > whether its next regularly scheduled RTCP RR is within the time > bounds for the RTCP UM (t_e + t_dither_max > t_rr). If so, no Early > RR is scheduled; instead the UM is appended to the regular RTCP RR. > Otherwise, R should check whether it is allowed to transmit an Early > RR/FB packet (allow_early==TRUE). > > If so, R creates a UM unit, calculates t_dither_max and then > schedules an early RR/UM packet for t_e = t0 + RND * t_dither_max > with the RND function evenly distributed between 0 and 1. > > If R receives an RR/UM packet (indicating the same or a superset > of the feedback information R wanted to transmit) before t_e is > reached, the FB information is discarded and the transmission > schedule for the next RR packet is reset to t_rr as calculated > before. > (Note: if the UM is piggybacked onto a regularly scheduled > RTCP RR > message, this should not affect transmission of the RR; but > should the UM then be removed from the compound RR/UM?) > > Otherwise, when t_e is reached, R creates an RR, appends the UM > information, and transmits the RR/UM packet. R then sets > allow_early=FALSE and recalculates t_rr += T_rr (possibly > t_rr = t_e + 2*T_rr or some value in between; this needs further > work). As soon as R sends its next regularly scheduled RTCP RR > (at the new t_rr), it sets allow_early=TRUE again. > > Option: R also starts a timer T_allow (e.g. T_allow=T_rr). > If T_rr expires before an Early RR/UM is received from > another participant in the RTP session, R sets > allow_early=TRUE. If an Early RR/UM is received from > another participant before T_allow expires, T_allow > is cancelled. > > If allow_early==FALSE then R calculates t_dither_max and checks the > time for the next scheduled RR: if t_rr - t0 < t_dither_max then R > creates an FB unit for transmission along with the RR packet at t_rr > (see above). Otherwise, R does not send an RTCP RR/UM. > > Note: A bit in the UM unit is required to indicate whether the > transmission occurs as an Early RR/FB or as a regularly > scheduled RR/FB packet. This E-bit is to be set accordingly. > See section 4 for details. > > Note: Numerous variations spring to mind on RTCP RR/UM scheduling, > dithering, damping, etc. Right now, this is deliberately kept > simple for an easy starting point and to provoke further > > > > Wenger/Ott Expires December 2000 [Page 10] > > > > > > Internet Draft July 14, 2000 > > > discussions. > > > 3.4. Summary of decision steps > > Before even considering whether or not to send RTCP UM > information an > application has to determine whether this mechanism is applicable: > > 1) An application has to decide whether -- for the current ratio of > frame rate with the associated (application-specific) maximum > feedback delay and the currently observed round-trip time -- > feedback mechanisms can be applied at all. > > 2) The application has to decide whether -- for a certain observed > error rate, assigned bandwidth, frame rate, and group size -- > (and > which) feedback mechanisms can be applied. > > 3) If these tests pass, the application has to follow the rules for > transmitting early RTCP RRs or regularly scheduled RTCP RRs with > piggybacked UMs. > > > 4. Format of RTCP Feedback messages > > The general format of an UM is outlined below. Compound packets > including UMs are possible. All UMs concerning any given picture of > any given receiver MUST be conveyed in a single compound packet, in > order to prevent the loss of parts of such a combined message. It > SHOULD be avoided to combine different types of UMs for any given > picture of any given receiver. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V=2| UMT |E| PT=RTCP-Feedb | length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRC | > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > | Upstream Control Information (UCI) > | > | +-+-+-+-+-+-+-+-+-+-+-+-+-+ > | : padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > version (V): 2 bits > Identifies the version of RTP, which is the same in RTCP packets as > in RTP data packets. > > Upstream Message Type (UMT): 5 bits > Identifies the type of the upstream message. > > 0: forbidden > > > > > Wenger/Ott Expires December 2000 [Page 11] > > > > > > Internet Draft July 14, 2000 > > > 1: Picture Loss Indication > 2: Slice Lost Indication > 3: Reference Picture Selection Indication > 4-31: reserved > > Packet Type (PT): 8 bits > Constant value (TBD) identifying RTCP Upstream messages. > > Early Upstream Message (E): 1 bit > A bit that, when set, indicates that the UM is sent early, i.e. did > not follow the regular schedule for sending RTCP Receiver Reports. > > Length: 16 bits: Number of bits valid in the UCI field. A zero > value > indicates that the UCI field is not present (e.g. in case of a > Picture Intra Request). > > SSRC: 32 bits > SSRC is the synchronization source identifier for the sender of this > packet. > > Upstream Control Information (UCI): variable > Format and semantics of the UCI defer for the various upstream > message types. Fragmentation of an upstream message into > several UCI > fields is prohibited. See the following sections for their > definition. > > > 5. Message Type 1: Picture Loss Indication (PLI) > > 5.1 Semantics > > With the Picture Loss Indication message a decoder informs the > encoder about the loss of one or more full pictures > > 5.2 Format > > PLI does not require parameters. Therefore, the length field > MUST be > 0, and there MUST NOT be Upstream Control Information. > > 5.3 Timing Rules > > The timing follows the rules outlined in section 3. In systems that > employ both PLI and other UM types it may be advisable to follow the > regular RTCP RR timing rules, since PLI is not as delay critical as > other UM types. > > 5.4 Remarks > > PLI messages typically trigger the sending of full Intra pictures. > Intra Pictures are several times larger then predicted (Inter) > pictures. Their size is independent of the time they are generated. > In most environments, especially when employing bandwidth-limited > > > > > Wenger/Ott Expires December 2000 [Page 12] > > > > > > Internet Draft July 14, 2000 > > > links, the use of an Intra picture implies an allowed delay that > is a > significant multitude of the typical frame duration. An example: If > the sending frame rate is 10 fps, and an Intra picture is assumed to > be 10 times as big as an Inter picture (not an unrealistic > assumption, see [] for details), then a full second of latency > has to > be accepted. In such an environment there is no need for a > particular short delay in sending the upstream message. Hence > waiting for the next possible time slot allowed by RFC1889bis RTCP > timing rules does not negatively influence system performance. > > 6. Message Type 2: Slice Lost Indication > > 6.1 Semantics > > With the Slice Lost Indication a decoder can inform an encoder that > it was unable to decode one, or several consecutive, macroblocks. > The encoder can take appropriate action in order to re-synchronize > encoder and decoder by means of its choice, typically by sending the > lost macroblocks in Intra mode. This upstream message SHALL NOT be > used for video codecs with non-uniform, dynamically changeable > macroblock sizes such as H.263 with enabled Annex Q. In such a > case, > an encoder cannot always identify the corrupted spatial region. > > > 6.2 Format > > When UMT indicates a Slice Lost Indication, then there is one > additional UCI field the content of which is in the following > format: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | First | Number | TR | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > First: 13 bits > The macroblock (MB) address of the first lost macroblock. The MB > numbering is done such that the macroblock in the upper left corner > of the picture is considered macroblock number 1 and the number for > each macroblock increases from left to right and then from top to > bottom in raster-scan order (such that if there is a total of N > macroblocks in a picture, the bottom right macroblock is considered > macroblock number N). > > Number: 13 bits > The number of lost macroblocks, in scan order as discussed above. > > TR: 6 bits > The six least significant bits of the Temporal Reference of the > picture. > > 6.3 Timing Rules > > > > > > Wenger/Ott Expires December 2000 [Page 13] > > > > > > Internet Draft July 14, 2000 > > > The efficiency of algorithms using the Slice Lost Indication is > reduced greatly when the Indication is not transmitted in a timely > fashion. Motion compensation propagates corrupted pixels that are > not reported as being corrupted. Therefore, the use of the > algorithm > discussed in section 3 is highly recommended. > > Constraints on T_dither_max to be discussed. > > 6.4 Remarks > > The First field of the UCI defines the first macroblock of a picture > as 1 and not, as one could suspect, as 0. This was done to align > this specification with the comparable mechanism available in H.245. > The maximum number of macroblocks in a picture (2**13 or 8192) > corresponds to the maximum picture sizes of the ITU-T and ISO/IEC > video codecs. If future video codecs offer larger picture sizes > and/or smaller macroblock sizes, then an additional upstream message > has to be defined. The six least significant bits of the Temporal > Reference field are deemed to be sufficient to indicate the picture > in which the loss occurred. > > Algorithms were reported that keep track of the regions effected by > motion compensation, in order to allow for a transmission of Intra > macroblocks to all those areas, regardless of the timing of the UM > [TBP.]. While, when those algorithms are used, the timing of the UM > is less critical then without, it has to be observed that those > algorithms correct large parts of the picture and, therefore, > have to > transmit many for bits in case of delayed UMs. > > 7. Message Type 3: Reference Picture Selection Indication > > 7.1 Semantics > > Modern video coding standards such as MPEG-4 visual version 2 or > H.263 version 2 allow the use of older reference pictures then the > most recent one. Typically, a first-in-first-out queue of reference > pictures is maintained. If an encoder has learned about a loss of > encoder-decoder synchronicity, a known-as-correct reference picture > can be used. As this reference picture is temporally further away > then usual, the resulting predictively coded picture will use more > bits. > > Both MPEG-4 and H.263 define a binary format for the _payload_ of an > RPSI message that includes information such as the temporal ID > of the > damaged picture and the size of the damaged region. This bit string > is typically small _- a couple of dozen bits -_, of variable length, > and self-contained, i.e. contains all information that is necessary > to perform reference picture selection. > > Note that both MPEG-4 and H.263 allow the use of RPSI with positive > feedback information as well. That is, all corrected pictures are > > > > > Wenger/Ott Expires December 2000 [Page 14] > > > > > > Internet Draft July 14, 2000 > > > reported. Any form of positive feedback MUST NOT be used when in a > multicast environment (reporting positive feedback about individual > reference pictures at RTCP intervals is not expected to be of much > use anyway). For point-to-point communication, positive > feedback MAY > be used but, again, the bit rate budget of RTCP feedback will > prevent > the use in most scenarios anyway. > > 7.2 Format > > When UM indicates an RPSI, then the length field is set to the > number > of bits of the following bit string that contains the RPS > information. This bit string follows byte aligned in the UCI field. > Bit padding is used to achieve 32-bit word alignment of the UCI > message (and the whole packet). > > 7.3 Timing Rules > > RPS is even more critical to delay then algorithms using SLI. This > is due to the fact that the older the RPS message is, the more bits > the encoder has to spend to achieve encoder-decoder synchronicity. > See [TBP.] for some information about the overhead of RPS for > certain > bit rate/frame rate/loss rate scenarios. > > Therefore, RPS messages should typically be sent as soon as > possible, > employing the algorithm of section 3. > > Constraints on T_dither_max to be discussed. > > 7.4 Remarks > > [To Do] > > > 8. Security considerations > > RTP packets transporting information with the proposed payload for- > mat are subject to the security considerations discussed in the RTP > specification [1]. This implies that confidentiality of the media > streams is achieved by encryption. > > > If the entire stream (extension data and AU data) is to be secured > and all the participants are expected to have the keys to decode the > entire stream, then the encryption is performed in the usual manner, > and there is no conflict between the two operations (encapsulation > and encryption). > > The need for a portion of stream (e.g. extension data) to be > encrypted with a different key, or not to be encrypted, would > require > application level signaling protocols to be aware of the usage of > the XT field, and to exchange keys and negotiate their usage on the > media and extension data separately. > > > > > > Wenger/Ott Expires December 2000 [Page 15] > > > > > > Internet Draft July 14, 2000 > > > 9. Acknowledgements > > Large parts of the syntax and the text concerned with RPS and > NEWPRED > were borrowed from an early I-D from Fukunaga et. al. that was > concerned with MPEG-4 ES packetization. > > 10. Full Copyright Statement > > Copyright (C) The Internet Society (1999). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this > paragraph are > included on all such copies and derivative works. > > However, this document itself may not be modified in any way, > such as > by removing the copyright notice or references to the Internet Soci- > ety or other Internet organizations, except as needed for the > purpose > of developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be fol- > lowed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assigns. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MER- > CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." > > 11. Authors' Addresses > > Stephan Wenger (stewe@cs.tu-berlin.de) > TU Berlin > Sekr. FR 6-3 > Franklinstr. 28-29 > D-10587 Berlin > Germany > > Joerg Ott (jo@tzi.uni-bremen.de) > Universitaet Bremen TZI > MZH 5180 > Bibliothekstr. 1 > D-28359 Bremen > Germany > > 12. Bibliography: TODO > > > > > Wenger/Ott Expires December 2000 [Page 16] From rem-conf Mon Jul 17 11:38:15 2000 From rem-conf-request@es.net Mon Jul 17 11:38:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EFhj-0002HS-00; Mon, 17 Jul 2000 11:33:23 -0700 Received: from mail.cs.tu-berlin.de [130.149.17.13] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13EFhh-0002GE-00; Mon, 17 Jul 2000 11:33:22 -0700 Received: from kraftbus.cs.tu-berlin.de (130-149-145-190.dialup.cs.tu-berlin.de [130.149.145.190]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id UAA20507; Mon, 17 Jul 2000 20:26:22 +0200 (MET DST) Message-Id: <4.3.2.7.2.20000717200116.02b96240@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Jul 2000 20:28:43 +0200 To: "Dr. Carsten Bormann" , , "Colin Perkins" From: Stephan Wenger Subject: RE: low delay RTCP Cc: , In-Reply-To: References: <39731FA4.7EEF3EAE@bitband.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_206372863==_" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --=====================_206372863==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all: I want to throw in some video-related facts into this discussion, along with a few numbers (in the attached excel spreadsheet -- sorry for using MS tools :-) What Reference Picture Selection (aka NEWPRED) does is to take a known-as-correct old reference picture instead of a (corrupted) recent one for prediction. The knowledge what reference picture to use is established through feedback. Necessarily, the longer the delay on the feedback channel, the older the reference picture will be. See our feedback I-D for a more verbose discussion. Using an older reference picture corresponds roughly to coding pictures at a lower frame rate. What I have done in the spreadsheet is to calculate the average picture size for two video sequences (foreman, trevor) at fixed quality level and skip factors between 0 and 50. The results are as follows: In order to keep the size of an RPS picture smaller then 200% of the typical picture size, your maximum delay for the feedback message is roughly Trevor: a) at 30 fps: 2 pictures delay, corresponding to 66 ms b) at 15 fps: 5 pictures delay, corresponding to 300 ms c) at 10 fps: 5 pictures delay, corresponding to 500 ms d) at 7.5 fps: 5 pictures delay, corresponding to ~670 ms Foreman: a) at 30 fps: 2 pictures delay, corresponding to 66 ms b) at 15 fps: 5 pictures delay, corresponding to 300 ms c) at 10 fps: 7 pictures delay, corresponding to 700 ms d) at 7.5 fps: 6 pictures delay, corresponding to 800 ms Intra pictures are in case of Foreman roughly 1.5 times as big as a one second old RPS picture; in case of trevor its about 1.3. Meaning that even at 1 second delay RPS is still outperforming a full intra picture. This assumes of course a sufficiently deep picture buffer for RPS. Conclusion a) At the full frame rate you need to be incredibly fast -- faster then what can be achieved in todays network (or am I too pessimistic there?) b) For "typical" frame rates of today's video telephony equipment, your delay demands are somewhat more relaxed, but still too tough to use the regular RR report mechanisms of RTP (at least in case of Multicast). c) In any case RPS is better then INTRA (if all systems are capable of using it). For the video folks: Video Coding Standard: H.263+ Optional Modes: I, T, (N) QP: fixed, 13 Foreman Trevor resulting bitrates for full frame rate: ~100 kbit/s ~60 kbit/s resulting bitrate for intra-only: ~ 640 kbit/s ~460 kbit/s --=====================_206372863==_ Content-Type: application/vnd.ms-excel; name="bits_vs_skip.xls" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="bits_vs_skip.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAHwAAAAAAAAAA EAAA/v///wAAAAD+////AAAAAB4AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8J CBAAAAYFAK8YzQdBQAAABgEAAOEAAgCwBMEAAgAAAOIAAABcAHAADgAAU3RlcGhhbiBXZW5nZXIg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEIAAgCwBGEBAgAAAMABAAA9AQgA BAABAAIAAwCcAAIADgAZAAIAAAASAAIAAAATAAIAAACvAQIAAAC8AQIAAAA9ABIAeAA8AEw7gSQ4 AAEAAAABAFgCQAACAAAAjQACAAAAIgACAAAADgACAAEAtwECAAAA2gACAAAAMQAaAMgAAAD/f5AB AAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/ f5ABAAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAAAAAABQFBAHIAaQBhAGwAMQAaAMgA AAD/f5ABAAAAAAAABQFBAHIAaQBhAGwAMQAaAMgAAAD/f5ABAAAAAAAABQFBAHIAaQBhAGwAHgQc AAUAFwAAIiQiIywjIzBfKTtcKCIkIiMsIyMwXCkeBCEABgAcAAAiJCIjLCMjMF8pO1tSZWRdXCgi JCIjLCMjMFwpHgQiAAcAHQAAIiQiIywjIzAuMDBfKTtcKCIkIiMsIyMwLjAwXCkeBCcACAAiAAAi JCIjLCMjMC4wMF8pO1tSZWRdXCgiJCIjLCMjMC4wMFwpHgQ3ACoAMgAAXygiJCIqICMsIyMwXyk7 XygiJCIqIFwoIywjIzBcKTtfKCIkIiogIi0iXyk7XyhAXykeBC4AKQApAABfKCogIywjIzBfKTtf KCogXCgjLCMjMFwpO18oKiAiLSJfKTtfKEBfKR4EPwAsADoAAF8oIiQiKiAjLCMjMC4wMF8pO18o IiQiKiBcKCMsIyMwLjAwXCk7XygiJCIqICItIj8/Xyk7XyhAXykeBDYAKwAxAABfKCogIywjIzAu MDBfKTtfKCogXCgjLCMjMC4wMFwpO18oKiAiLSI/P18pO18oQF8p4AAUAAAAAAD1/yAAAAAAAAAA AAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAEAAAD1/yAAAPQAAAAAAAAAAMAg4AAU AAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAIAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAA APQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAA AMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAA AAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQA AAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg4AAUAAAAAAD1/yAAAPQAAAAAAAAAAMAg 4AAUAAAAAAABACAAAAAAAAAAAAAAAMAg4AAUAAEAKwD1/yAAAPgAAAAAAAAAAMAg4AAUAAEAKQD1 /yAAAPgAAAAAAAAAAMAg4AAUAAEALAD1/yAAAPgAAAAAAAAAAMAg4AAUAAEAKgD1/yAAAPgAAAAA AAAAAMAg4AAUAAEACQD1/yAAAPgAAAAAAAAAAMAgkwIEABCAA/+TAgQAEYAG/5MCBAASgAT/kwIE ABOAB/+TAgQAAIAA/5MCBAAUgAX/YAECAAAAhQAOAIMGAAAAAAYAU2hlZXQ0hQAOAIoHAAAAAAYA U2hlZXQxhQAOAKMZAAAAAAYAU2hlZXQyhQAOAKoaAAAAAAYAU2hlZXQzjAAEAAEAAQCuAQQABAAB BBcACAABAAAAAQABAMEBCADBAQAAYGkBAOsAWgAPAADwUgAAAAAABvAYAAAAAgQAAAIAAAACAAAA AQAAAAEAAAACAAAAMwAL8BIAAAC/AAgACACBAQkAAAjAAUAAAAhAAB7xEAAAAA0AAAgMAAAIFwAA CPcAABD8ACsABAAAAAQAAAAHAABGb3JlbWFuBgAAVHJldm9yBAAAU2tpcAYAAEkgT25sef8ACgAI AE4GAAAMAAAACgAAAAkIEAAABhAArxjNB0FAAAAGAQAACwIQAAAAAAAAAAAAAAAAADsHAAANAAIA AQAMAAIAZAAPAAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIAAQCA AAgAAAAAAAAAAAAlAgQAAAD/AIEAAgDBBBQAAAAVAAAAgwACAAAAhAACAAAAoQAiAAAA/wABAAEA AQAEAAAAAAAAAAAAAADgPwAAAAAAAOA/AABVAAIACAAAAg4AAAAAAAAAAAAAAAAAAAA+AhIAtgAA AAAAQAAAAAAAAAAAAAAAHQAPAAMAAAAAAAABAAAAAAAAAO8ABgAAADcAAAAKAAAACQgQAAAGEACv GM0HQUAAAAYBAAALAhQAAAAAAAAAAAAYAAAARggAAMQMAAANAAIAAQAMAAIAZAAPAAIAAQARAAIA AAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIAAQCAAAgAAAAAAAAAAAAlAgQAAAD/ AIEAAgDBBBQAAAAVAAAAgwACAAAAhAACAAAAoQAiAAAA/wABAAEAAQAEAAAAAAAAAAAAAADgPwAA AAAAAOA/AABVAAIACAAAAg4AAAAAABgAAAAAAAMAAAAIAhAAAAAAAAMA/wAAAAAAAAEPAAgCEAAB AAAAAwD/AAAAAAAAAQ8ACAIQAAIAAAADAP8AAAAAAAABDwAIAhAAAwAAAAMA/wAAAAAAAAEPAAgC EAAEAAAAAwD/AAAAAAAAAQ8ACAIQAAUAAAADAP8AAAAAAAABDwAIAhAABgAAAAMA/wAAAAAAAAEP AAgCEAAHAAAAAwD/AAAAAAAAAQ8ACAIQAAgAAAADAP8AAAAAAAABDwAIAhAACQAAAAMA/wAAAAAA AAEPAAgCEAAKAAAAAwD/AAAAAAAAAQ8ACAIQAAsAAAADAP8AAAAAAAABDwAIAhAADAAAAAMA/wAA AAAAAAEPAAgCEAANAAAAAwD/AAAAAAAAAQ8ACAIQAA4AAAADAP8AAAAAAAABDwAIAhAADwAAAAMA /wAAAAAAAAEPAAgCEAAQAAAAAwD/AAAAAAAAAQ8ACAIQABEAAAADAP8AAAAAAAABDwAIAhAAEgAA AAMA/wAAAAAAAAEPAAgCEAATAAAAAwD/AAAAAAAAAQ8ACAIQABQAAAADAP8AAAAAAAABDwAIAhAA FQAAAAMA/wAAAAAAAAEPAAgCEAAXAAAAAwD/AAAAAAAAAQ8A/QAKAAAAAAAPAAIAAAD9AAoAAAAB AA8AAAAAAP0ACgAAAAIADwABAAAAvQAYAAEAAAAPAAAAAAAPAADWqUAPAADAn0ACAL0AGAACAAAA DwAAAPA/DwAAk7JADwAAuqdAAgC9ABgAAwAAAA8AAAAAQA8AAKW2QA8AAGStQAIAvQAYAAQAAAAP AAAACEAPAACFuUAPAAArsUACAL0AGAAFAAAADwAAABBADwAAQbxADwAApLNAAgC9ABgABgAAAA8A AAAUQA8AABq+QA8AAC+2QAIAvQAYAAcAAAAPAAAAGEAPAAADwEAPAADft0ACAL0AGAAIAAAADwAA ABxADwAAucBADwAAF7pAAgC9ABgACQAAAA8AAAAgQA8AAG3BQA8AAK+7QAIAvQAYAAoAAAAPAAAA IkAPAIDXwUAPAACJvEACAL0AGAALAAAADwAAACRADwCAzsJADwAAGr5AAgC9ABgADAAAAA8AAAAo QA8AALHDQA8AAMHAQAIAvQAYAA0AAAAPAAAALEAPAAA4xUAPAADhwEACAL0AGAAOAAAADwAAAC5A DwAAxcRADwAAEMJAAgC9ABgADwAAAA8AAAAwQA8AgOvEQA8AgITCQAIAvQAYABAAAAAPAAAAMkAP AIBrxUAPAIC9w0ACAL0AGAARAAAADwAAADRADwAAScZADwAA5cNAAgC9ABgAEgAAAA8AAAA5QA8A AJ/HQA8AALvGQAIAvQAYABMAAAAPAAAAPkAPAAAdykAPAABkx0ACAL0AGAAUAAAADwAAAERADwCA sMlADwAAtMpAAgC9ABgAFQAAAA8AAABJQA8AgFrMQA8AQD3QQAIA/QAKABcAAAAPAAMAAAC9ABIA FwABAA8AAKbUQA8AgBLOQAIA1wAyAGYEAAC4ASoAHAAcABwAHAAcABwAHAAcABwAHAAcABwAHAAc ABwAHAAcABwAHAAcABwA7ADIAA8AAvDAAAAAEAAI8AgAAAACAAAAAQQAAA8AA/CoAAAADwAE8CgA AAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8HAAAACSDArwCAAA AAEEAAAACgAAkwAL8DYAAAB/AAQBBAG/AAgACACBAU4AAAiDAU0AAAi/ARAAEQDAAU0AAAj/AQgA CAA/AgAAAgC/AwAACAAAABDwEgAAAAAAAwBQAwgA4gALAAACGgCIAAAAEfAAAAAAXQAaABUAEgAF AAEAEWAAAAAAsAlUAQAAAAAAAAAACQgQAAAGIACvGM0HQUAAAAYBAAAUAAAAFQAAAIMAAgAAAIQA AgAAAKEAIgAAABIAAQABAAEABAAAALAJAAAAAAAA4D8AAAAAAADgPw8AMwACAAMAYBAKAD4cDRHI AAAABQBgEAoAPhwNEcgAAQAGABIAAgAAAAEQAgAAAAIQEADQPwUA0D8FAAAAcQHQv+EAMxAAAKAA BAABAAEAZBAIAAAAAQAAAAEAMhAEAAAAAgAzEAAABxAMAAAAAAAAAAAACQBNAAoQEAD///8AAAAA AAEAAQBOAE0ANBAAAAMQDAABAAEAFQAVAAEAAAAzEAAAURAPAAACAAAAAAcAOgAAAAABAA0QEgAA AAcBRgBvAHIAZQBtAGEAbgBREBMAAQIAAAAACwA7AAABABUAAQABAFEQEwACAgAAAAALADsAAAEA FQAAAAAAURAIAAMBAAAAAAAABhAIAP//AAAAAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAAAxAM AAEAAQAVABUAAQAAADMQAABREA8AAAIAAAAABwA6AAAAAAIADRAQAAAABgFUAHIAZQB2AG8AcgBR EBMAAQIAAAAACwA7AAABABUAAgACAFEQEwACAgAAAAALADsAAAEAFQAAAAAAURAIAAMBAAAAAAAA BhAIAP//AQABAAAAMxAAAF8QAgAAADQQAABFEAIAAAA0EAAARBAEAAoAAAAkEAIAAgAlECAAAgIB AAAAAACc////W////wAAAAAAAAAAsQBNAIAgAAAzEAAATxAUAAIAAgAAAAAAAAAAAAAAAAAAAAAA JhACAAUAURAIAAABAAAAAAAANBAAACQQAgADACUQIAACAgEAAAAAAJz///9b////AAAAAAAAAACx AE0AgCAAADMQAABPEBQAAgACAAAAAAAAAAAAAAAAAAAAAAAmEAIABgBREAgAAAEAAAAAAAA0EAAA RhACAAEAQRASAAAA2QEAACEBAAAVCgAATAwAADMQAABPEBQAAgACAFMAAACJAAAA5gsAAI0OAAAd EBIAAAAAAAAAAAAAAAAAAAAAAAAAMxAAAB8QKgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAHwEeEB4AAgADAQAAAAAAAAAAAAAAAAAAAAAAAAAAIwBNAAAANBAAAB0QEgAB AAAAAAAAAAAAAAAAAAAAAAAzEAAAHxAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAfAR4QHgACAAMBAAAAAAAAAAAAAAAAAAAAAAAAAAAjAE0AAAAhEAIAAQAHEAwAAAAA AAAA//8JAE0ANBAAADUQAAAyEAQAAAADADMQAAAHEAwAgICAAAAAAAAAABcAChAQAMDAwAAAAAAA AQAAABYATwA0EAAAFBAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAMxAAABsQBgBkAAEAAAAiEAoAAAAA AAAAAAAPABUQFACUDAAAHwYAAOsCAABBAgAAAwEfADMQAABPEBQABQACAJQMAAAfBgAAAAAAAAAA AAAlECAAAgIBAAAAAACc////W////wAAAAAAAAAAsQBNALAsAAAzEAAATxAUAAIAAgAAAAAAAAAA AAAAAAAAAAAAURAIAAABAAAAAAAANBAAADQQAAAGEAgAAAAAAP3/AAAzEAAAXxACAAAABxAMAAAA AAAAAP//CQBNAAoQEAAAAAAAAAAAAAAAAQBNAE0ACxACAAAAXRACAAEACRAUAAAAAAAAAAAAAgAB AE0ATQA8AAAANBAAADQQAAA0EAAANBAAAAACDgAAAAAAFQAAAAAAAgAAAGUQAgACAAMCDgAAAAAA AAAAAAAAAAAAAAMCDgAAAAEAAAAAAAAAAAAAAAMCDgABAAAAAAAAAAAAAADwPwMCDgABAAEAAAAA AAAAAADwPwMCDgACAAAAAAAAAAAAAAAAQAMCDgACAAEAAAAAAAAAAAAAQAMCDgADAAAAAAAAAAAA AAAIQAMCDgADAAEAAAAAAAAAAAAIQAMCDgAEAAAAAAAAAAAAAAAQQAMCDgAEAAEAAAAAAAAAAAAQ QAMCDgAFAAAAAAAAAAAAAAAUQAMCDgAFAAEAAAAAAAAAAAAUQAMCDgAGAAAAAAAAAAAAAAAYQAMC DgAGAAEAAAAAAAAAAAAYQAMCDgAHAAAAAAAAAAAAAAAcQAMCDgAHAAEAAAAAAAAAAAAcQAMCDgAI AAAAAAAAAAAAAAAgQAMCDgAIAAEAAAAAAAAAAAAgQAMCDgAJAAAAAAAAAAAAAAAiQAMCDgAJAAEA AAAAAAAAAAAiQAMCDgAKAAAAAAAAAAAAAAAkQAMCDgAKAAEAAAAAAAAAAAAkQAMCDgALAAAAAAAA AAAAAAAoQAMCDgALAAEAAAAAAAAAAAAoQAMCDgAMAAAAAAAAAAAAAAAsQAMCDgAMAAEAAAAAAAAA AAAsQAMCDgANAAAAAAAAAAAAAAAuQAMCDgANAAEAAAAAAAAAAAAuQAMCDgAOAAAAAAAAAAAAAAAw QAMCDgAOAAEAAAAAAAAAAAAwQAMCDgAPAAAAAAAAAAAAAAAyQAMCDgAPAAEAAAAAAAAAAAAyQAMC DgAQAAAAAAAAAAAAAAA0QAMCDgAQAAEAAAAAAAAAAAA0QAMCDgARAAAAAAAAAAAAAAA5QAMCDgAR AAEAAAAAAAAAAAA5QAMCDgASAAAAAAAAAAAAAAA+QAMCDgASAAEAAAAAAAAAAAA+QAMCDgATAAAA AAAAAAAAAABEQAMCDgATAAEAAAAAAAAAAABEQAMCDgAUAAAAAAAAAAAAAABJQAMCDgAUAAEAAAAA AAAAAABJQGUQAgABAAMCDgAAAAAAAAAAAAAAANapQAMCDgAAAAEAAAAAAAAAAMCfQAMCDgABAAAA AAAAAAAAAJOyQAMCDgABAAEAAAAAAAAAALqnQAMCDgACAAAAAAAAAAAAAKW2QAMCDgACAAEAAAAA AAAAAGStQAMCDgADAAAAAAAAAAAAAIW5QAMCDgADAAEAAAAAAAAAACuxQAMCDgAEAAAAAAAAAAAA AEG8QAMCDgAEAAEAAAAAAAAAAKSzQAMCDgAFAAAAAAAAAAAAABq+QAMCDgAFAAEAAAAAAAAAAC+2 QAMCDgAGAAAAAAAAAAAAAAPAQAMCDgAGAAEAAAAAAAAAAN+3QAMCDgAHAAAAAAAAAAAAALnAQAMC DgAHAAEAAAAAAAAAABe6QAMCDgAIAAAAAAAAAAAAAG3BQAMCDgAIAAEAAAAAAAAAAK+7QAMCDgAJ AAAAAAAAAAAAgNfBQAMCDgAJAAEAAAAAAAAAAIm8QAMCDgAKAAAAAAAAAAAAgM7CQAMCDgAKAAEA AAAAAAAAABq+QAMCDgALAAAAAAAAAAAAALHDQAMCDgALAAEAAAAAAAAAAMHAQAMCDgAMAAAAAAAA AAAAADjFQAMCDgAMAAEAAAAAAAAAAOHAQAMCDgANAAAAAAAAAAAAAMXEQAMCDgANAAEAAAAAAAAA ABDCQAMCDgAOAAAAAAAAAAAAgOvEQAMCDgAOAAEAAAAAAAAAgITCQAMCDgAPAAAAAAAAAAAAgGvF QAMCDgAPAAEAAAAAAAAAgL3DQAMCDgAQAAAAAAAAAAAAAEnGQAMCDgAQAAEAAAAAAAAAAOXDQAMC DgARAAAAAAAAAAAAAJ/HQAMCDgARAAEAAAAAAAAAALvGQAMCDgASAAAAAAAAAAAAAB3KQAMCDgAS AAEAAAAAAAAAAGTHQAMCDgATAAAAAAAAAAAAgLDJQAMCDgATAAEAAAAAAAAAALTKQAMCDgAUAAAA AAAAAAAAgFrMQAMCDgAUAAEAAAAAAAAAQD3QQGUQAgADAAoAAADtABgAAAAZ8RAAAAABAAAAAAAA AAEEAAABBAAAPgISALYGAAAAAEAAAAAAAAAAAAAAAB0ADwADDQAMAAAAAQANAA0ADAzvAAYAAAA3 AAAACgAAAAkIEAAABhAArxjNB0FAAAAGAQAACwIQAAAAAAAAAAAAAAAAAFsaAAANAAIAAQAMAAIA ZAAPAAIAAQARAAIAAAAQAAgA/Knx0k1iUD9fAAIAAQAqAAIAAAArAAIAAACCAAIAAQCAAAgAAAAA AAAAAAAlAgQAAAD/AIEAAgDBBBQAAAAVAAAAgwACAAAAhAACAAAAoQAiAAAA/wABAAEAAQAEAQAM DAwAAAAAAADgPwAAAAAAAOA/DwBVAAIACAAAAg4AAAAAAAAAAAAAAAAAAAA+AhIAtgAAAAAAQAAA AAAAAAAAAAAAHQAPAAMAAAAAAAABAAAAAAAAAO8ABgAAADcAAAAKAAAACQgQAAAGEACvGM0HQUAA AAYBAAALAhAAAAAAAAAAAAAAAAAAYhsAAA0AAgABAAwAAgBkAA8AAgABABEAAgAAABAACAD8qfHS TWJQP18AAgABACoAAgAAACsAAgAAAIIAAgABAIAACAAAAAAAAAAAACUCBAAAAP8AgQACAMEEFAAA ABUAAACDAAIAAACEAAIAAAChACIAAAD/AAEAAQABAAQAAAAAAAAAAAAAAOA/AAAAAAAA4D8PAFUA AgAIAAACDgAAAAAAAAAAAAAAAAAAAD4CEgC2AAAAAABAAAAAAAAAAAAAAAAdAA8AAwAAAAAAAAEA AAAAAAAA7wAGAAAANwAAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAA AAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAsAAAAAcAAAABAAAAQAAAAAQAAABIAAAA CAAAAGAAAAASAAAAeAAAAAwAAACQAAAADQAAAJwAAAATAAAAqAAAAAIAAADkBAAAHgAAAA8AAABT dGVwaGFuIFdlbmdlcgAAHgAAAA8AAABTdGVwaGFuIFdlbmdlcgAAHgAAABAAAABNaWNyb3NvZnQg RXhjZWwAQAAAAIAGTXwX8L8BQAAAAAB11PAY8L8BAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAECgIAAAAAAAAAAAAAAAAAAAAA AAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAOwAAAAJAAAAAQAAAFAAAAAPAAAAWAAAABcAAABsAAAA CwAAAHQAAAAQAAAAfAAAABMAAACEAAAAFgAAAIwAAAANAAAAlAAAAAwAAADIAAAAAgAAAOQEAAAe AAAACgAAAFRVIEJlcmxpbgB0MwMAAACgCgkACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAAeEAAABAAAAAcAAABTaGVldDQABwAAAFNoZWV0MQAHAAAAU2hlZXQyAAcAAABTaGVldDMADBAA AAIAAAAeAAAACwAAAFdvcmtzaGVldHMAAwAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAA AAkAAAAKAAAACwAAAAwAAAANAAAA/v///w8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAD+//// FwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAP7////9/////v////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8CAAAAIAgCAAAAAADA AAAAAAAARgAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAVwBvAHIAawBiAG8AbwBrAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH///////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsRsAAAAAAAAFAFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAKAACAQEAAAADAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4A AAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAFgAAAAAQAAAAAAAA --=====================_206372863==_ Content-Type: text/plain; charset="us-ascii"; format=flowed --=====================_206372863==_-- From rem-conf Mon Jul 17 13:46:56 2000 From rem-conf-request@es.net Mon Jul 17 13:46:56 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EHik-0005DH-00; Mon, 17 Jul 2000 13:42:34 -0700 Received: from bettina.informatik.uni-bremen.de [134.102.224.3] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EHii-0005D7-00; Mon, 17 Jul 2000 13:42:32 -0700 Received: from cabo2 (dienstmann.informatik.uni-bremen.de [134.102.224.51]) by bettina.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id e6HKgNx26477; Mon, 17 Jul 2000 22:42:23 +0200 (MET DST) From: "Dr. Carsten Bormann" To: "Stephan Wenger" , , "Colin Perkins" Cc: , Subject: RE: low delay RTCP Date: Mon, 17 Jul 2000 22:42:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.2.7.2.20000717200116.02b96240@mail.cs.tu-berlin.de> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > a) At the full frame rate you need to be incredibly fast -- faster > then what can be achieved in todays network (or am I too > pessimistic there?) Just remember that while we design things to not break in the general Internet, there is a sizable area of application (sometimes called Business TV) typically with managed networks where RTTs in the dozens of milliseconds are quite achievable. (Only, of course, if you are geographically close -- you can't beat the speed of light.) Coincidentally, this is also the only area of application where multicast is widely deployed. Gruesse, Carsten From rem-conf Mon Jul 17 18:25:02 2000 From rem-conf-request@es.net Mon Jul 17 18:25:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EM4F-00017a-00; Mon, 17 Jul 2000 18:21:03 -0700 Received: from beanix.metronet.com (metronet.com) [192.245.137.3] (tmcgrath) by mail1.es.net with smtp (Exim 1.81 #2) id 13EM4D-00017K-00; Mon, 17 Jul 2000 18:21:01 -0700 Received: by metronet.com id AA06839 (5.67a/IDA1.5hp for rem-conf@es.net); Mon, 17 Jul 2000 20:20:38 -0500 Message-Id: <200007180120.AA06839@metronet.com> Subject: Looking for H261/H263 Codecs for Windows To: rem-conf@es.net Date: Mon, 17 Jul 2000 20:20:37 -0500 (CDT) From: "Timothy G. McGrath" Cc: tmcgrath@metronet.com (Tim McGrath) X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Does anybody know of or can recommend commercial/freeware h.261/h.263 codecs for MS Windows (9x and NT platforms). I need to use one of these in a custom application which compresses streaming video over RTP. Unfortunately, the compressors installed with Netmeeting don't appear to be usable outside of that particular app. I've found a handful of ancient, freeware codecs on the net, but I don't have the time to re-engineer these according to recent standards. Ideally, I'd like to find compressors which are written to conform to the MS Video Compressor DDK specifications, but I'll take any API as long it's simple to use and well-documented. Thanks for any help/suggestions. -- Tim McGrath ----- tmcgrath@metronet.com From rem-conf Mon Jul 17 23:19:31 2000 From rem-conf-request@es.net Mon Jul 17 23:19:29 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EQbZ-0003qv-00; Mon, 17 Jul 2000 23:11:45 -0700 Received: from habanero.marratech.com [195.196.47.9] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EQbX-0003ql-00; Mon, 17 Jul 2000 23:11:44 -0700 Received: from marratech.com (dhcp164.sthlm.marratech.com [195.196.47.164]) by habanero.marratech.com (8.9.3/8.9.3) with ESMTP id IAA99350; Tue, 18 Jul 2000 08:11:31 +0200 (CEST) Message-ID: <3973F45C.6A86998C@marratech.com> Date: Tue, 18 Jul 2000 08:08:28 +0200 From: Serge Lachapelle Organization: Marratech AB - The e-meeting company! X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: "Timothy G. McGrath" CC: rem-conf@es.net, Tim McGrath Subject: Re: Looking for H261/H263 Codecs for Windows References: <200007180120.AA06839@metronet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You should take a look at the Java Media Framework, at: http://java.sun.com/products/java-media/jmf/index.html It has a few codecs for Solaris, Windows and Linux that might interest you. /Serge "Timothy G. McGrath" wrote: > Does anybody know of or can recommend commercial/freeware h.261/h.263 > codecs for MS Windows (9x and NT platforms). I need to use one of these in > a custom application which compresses streaming video over > RTP. Unfortunately, the compressors installed with Netmeeting don't appear > to be usable outside of that particular app. > > I've found a handful of ancient, freeware codecs on the net, but I don't > have the time to re-engineer these according to recent standards. Ideally, > I'd like to find compressors which are written to conform to the MS Video > Compressor DDK specifications, but I'll take any API as long it's simple to > use and well-documented. > > Thanks for any help/suggestions. > -- > Tim McGrath ----- tmcgrath@metronet.com From rem-conf Mon Jul 17 23:29:00 2000 From rem-conf-request@es.net Mon Jul 17 23:28:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EQnh-0004A7-00; Mon, 17 Jul 2000 23:24:17 -0700 Received: from lukla.sun.com [192.18.98.31] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EQng-00049v-00; Mon, 17 Jul 2000 23:24:16 -0700 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05031; Tue, 18 Jul 2000 00:24:12 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA20224; Mon, 17 Jul 2000 23:24:11 -0700 (PDT) Received: from columbine (columbine [129.146.100.26]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id XAA02831; Mon, 17 Jul 2000 23:24:09 -0700 (PDT) Date: Mon, 17 Jul 2000 23:23:59 -0700 (PDT) From: "michael.speer@eng.sun.com" Reply-To: "michael.speer@eng.sun.com" Subject: Re: Looking for H261/H263 Codecs for Windows To: "Timothy G. McGrath" Cc: rem-conf@es.net In-Reply-To: "Your message with ID" <200007180120.AA06839@metronet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Maybe you should take a peak at JMF2.1 (http://java.sun.com/products/java-media/jmf/index.html) Michael > Does anybody know of or can recommend commercial/freeware h.261/h.263 > codecs for MS Windows (9x and NT platforms). I need to use one of these in > a custom application which compresses streaming video over > RTP. Unfortunately, the compressors installed with Netmeeting don't appear > to be usable outside of that particular app. > > I've found a handful of ancient, freeware codecs on the net, but I don't > have the time to re-engineer these according to recent standards. Ideally, > I'd like to find compressors which are written to conform to the MS Video > Compressor DDK specifications, but I'll take any API as long it's simple to > use and well-documented. > > Thanks for any help/suggestions. > -- > Tim McGrath ----- tmcgrath@metronet.com > > > From rem-conf Mon Jul 17 23:40:31 2000 From rem-conf-request@es.net Mon Jul 17 23:40:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EQyu-00053c-00; Mon, 17 Jul 2000 23:35:52 -0700 Received: from penguin-ext.wise.edt.ericsson.se [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EQyt-000533-00; Mon, 17 Jul 2000 23:35:51 -0700 Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6I6ZjM01658 for ; Tue, 18 Jul 2000 08:35:45 +0200 (MEST) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0FXV00C01RNKWD@mbb1.ericsson.se> for rem-conf@es.net; Tue, 18 Jul 2000 08:35:45 +0200 (MET DST) Received: from ericsson.com (ior.ericsson.se [147.214.173.142]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0FXV00B9NRNK3I@mbb1.ericsson.se> for rem-conf@es.net; Tue, 18 Jul 2000 08:35:44 +0200 (MET DST) Date: Tue, 18 Jul 2000 08:35:44 +0200 From: Johan =?iso-8859-1?Q?Sj=F6berg?= Subject: AMR payload format for AMR Sender: erasgjn@mbb1.ericsson.se To: rem-conf@es.net Message-id: <3973FABF.7D4BE15E@ericsson.com> MIME-version: 1.0 X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_(ID_2SCANejE9DIv3wZM94wSCg)" X-Accept-Language: en X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --Boundary_(ID_2SCANejE9DIv3wZM94wSCg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin.wise.edt.ericsson.se id e6I6ZjM01658 Hi, As a result of the request from the Adelaide meeting to merge the AMR drafts we have submitted the attached draft, draft-sjoberg-avt-rtp-amr-01.txt. It was submitted last Friday and I'm sorry for distributing it to rem-conf this late. Johan -- Johan Sj=F6berg Audio Technology, Ericsson Research ----------------------------------------------------------------- Ericsson Radio Systems AB | Phone: +46 8 50878230 Torshamnsgatan 23 | Fax: +46 8 7575550 S-164 80 Stockholm, SWEDEN | mailto:johan.sjoberg@ericsson.com --Boundary_(ID_2SCANejE9DIv3wZM94wSCg) Content-type: text/plain; charset=us-ascii; name=draft-sjoberg-avt-rtp-amr-01.txt Content-disposition: inline; filename=draft-sjoberg-avt-rtp-amr-01.txt Content-Transfer-Encoding: 7BIT Internet Engineering Task Force Johan Sjoberg, Ericsson Audio Video Transport WG Magnus Westerlund, Ericsson INTERNET-DRAFT Ari Lakaniemi, Nokia July 14, 2001 Petri Koskelainen, Nokia Expires: January 14, 2000 RTP payload format for AMR Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Abstract This document describes a proposed real-time transport protocol (RTP) [8] payload format for AMR speech encoded [1] signals. The AMR payload format is designed to be able to interoperate with existing AMR transport formats. This document also includes a MIME type registration for AMR. The MIME type is specified for both real-time transport and storage. Sjoberg [Page 1] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 1. Introduction The adaptive multi-rate (AMR) speech codec was developed by the European Telecommunications Standards institute (ETSI). The AMR codec is standardized for GSM, and is also chosen by 3GPP as the mandatory codec for third generation systems. It is currently under standardization for TDMA. I.e. the AMR codec will be widely used in cellular systems. The AMR codec is developed to preserve high speech quality under a wide range of transmission conditions. The AMR codec is a multi-mode codec with 8 narrow band modes with bit rates between 4.75 and 12.2 kbps. The sampling frequency is 8000 Hz and processing is done on 20 ms frames, i.e. 160 samples per frame. The AMR modes are closely related to each other and uses the same coding framework. Three of the AMR modes are already adopted and used standards of there own, the 6.7 kbps mode as PDC-EFR [7], the 7.4 kbps mode as IS-641 codec in TDMA [6], and the 12.2 kbps mode as GSM- EFR [5]. AMR implementations must support all 8 speech coding modes, and mode switching can occur to any mode at any time. The mode information must therefore be transmitted together with the speech encoded bits, to indicate the mode. It is possible for the decoder to signal to the encoder the mode it prefers to receive. The reason can be e.g. transmission bandwidth or quality. The AMR codec is designed with a voice activity detector (VAD) and generation of comfort noise (CN) parameters during silence periods. Hence, the AMR codec can reduce the number of transmitted bits and packets during silence periods to a minimum. The operation to send CN parameters at regular intervals during silence periods is usually called discontinuous transmission (DTX) or source controlled rate (SCR) operation. The three codec standards that are part of AMR [5][6][7] also have SCR/CN functionality specified. To enable interoperability with terminals supporting these standards the AMR can optionally be extended to support also these CN schemes, see [2]. Due to the flexibility and robustness of AMR, it is suitable also for other purposes than circuit switched cellular systems. Other suitable applications are real-time services over packet switched networks, e.g. over RTP. To be optimized for transmission over networks with high packet loss rates, the possibility to use extra redundancy is built into the RTP payload format for AMR. The speech encoded bits have different perceptual sensitivity to bit errors and cellular systems exploit this by using unequal error protection and detection (UEP and UED). This mechanism concentrates the correction and detection of corrupted bits to the perceptually most sensitive bits. A frame is only regarded as lost or damaged if errors are detected in the most sensitive bits. The UED can also be employed on RTP if UDP Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 2] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 lite is used as transport layer protocol (UDP lite [10] is work in progress). To enable this, the bits in the payload have to be ordered in sensitivity order. The AMR encoded bits are defined in sensitivity order in [2]. If the receiver supports option to retransmit redundant frames, the different sensitivity could also be used for transmitting only the most sensitive bits of a redundant frame. The special problems with IP real-time traffic over cellular access networks are further discussed in [9]. Other AMR scenarios are possible, e.g. one end is circuit switched GSM, which is connected through a gateway to IP network and an IP terminal in the other end. To improve quality, also frames damaged by the GSM radio should be transmitted to the decoder in the IP network. To make this possible, frame quality information has to be transmitted over the IP network. The quality bit is also needed for the AMR RTP payload format to interwork with for example the ATM AAL2 AMR profile. 2. Requirements The AMR payload format for RTP was designed to meet the following requirements: o Different levels of robustness must be supported, from no redundant data to extreme robustness capable of handling very high packet loss rates with no or small speech quality degradation. o Fast, frame-wise AMR mode adaptation must be supported. This means that it must be possible to send Codec Mode Requests back from the receiving side to the transmitting side with information on the preferred mode. Slower AMR mode adaptation may also be accomplished with external signaling. o Source controlled rate operation (SCR) and comfort noise parameter (CN) transmission defined in AMR must be supported. 3. Payload format The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [3]. The AMR payload format is designed to be flexible, ranging from very low overhead to an extended format with the possibility to send redundancy information and several speech frames in one packet. The payload format consists of payload header and zero or more payload frames. Neither the payload header nor the payload frames are Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 3] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 octet aligned on their own but the full payload is. If the option to transmit redundant information is enabled and employed, the full payload SHALL finally be ordered in descending bit error sensitivity order to be prepared for unequal error protection or unequal error detection schemes, e.g. UDP lite. The AMR encoded bit streams are defined in sensitivity order in Annex B of [2], the original order as delivered from the speech encoder is defined in [1]. The last octet of an AMR payload packet is padded with zeroes at the end if not all bits are used. The AMR frame types, or modes, are defined in [2]. Frame type 15, no transmission, is needed to indicate not transmitted frames or lost frames. Not transmitted could mean both no data produced by the speech encoder for this frame or no data transmitted in this payload, i.e. valid data for this frame could be sent in another payload. For example, when multiple frames are sent in each payload and comfort noise starts. A frame type sequence in a payload with 8 frames, speech frames with AMR mode 7 are interrupted by CN in the fifth frame, could look like: {7,7,7,7,8,15,15,8}. The AMR SCR is described in [4]. The AMR payload format supports robust transmission, multiple frames in one payload packet, and the use of fast codec mode adaptation. The robust behavior is accomplished by using the optional possibility to retransmit previously transmitted frames together with the current frame or frames. The redundant frames could be transmitted in their entirety or only partly. If only a part of the redundant frame is transmitted, the least sensitive bits are omitted. A partially transmitted redundant frame SHALL fill the number of used octets for that frame. The bits in the payload are sorted in descending sensitivity order to support UED, like in UDP lite [10], if partial redundancy is used. When bits in redundant frames are not transmitted, the not transmitted/received bits MUST be reconstructed on the receiver side. It is RECOMMENDED to produce the non received bits with state of the art ECU actions. Nothing giving worse quality than using a random generated bits SHOULD be used. To use a fixed pattern SHOULD be avoided for speech quality reasons. Note that the possibility to transmit partial redundant frames can be employed only if the receiver has signaled support for this in capability description. A frame quality indicator is included for interoperability with the ATM payload format described in ITU-T I.366.2 and the UTRAN Iu interface [14]. The speech quality is significantly increased if damaged frames are forwarded to the speech decoder error concealment unit and not dropped. Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 4] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 3.1. The payload header The payload header has dynamic length, 3 or 7 bits. The bits in the header are specified as follows: Q (1 bit): The payload quality bit indicates, if not set, that the payload is severely damaged and the receiver should set the RX_TYPE, see [4], to SPEECH_BAD or SID_BAD depending on the frame type (FT). L (1 bit): Indicates the existence of LEN fields in the payload frames and that sensitivity sorting is used. Note that this bit can be set only if the receiver has signaled support for option to transmit redundant data. R (1 bit): Indicates, if set, that the Codec Mode Request (CMR) is sent. CMR (4 bits): OPTIONAL field, depending on the R bit. Requested codec mode for the other communication direction. The mapping of existing AMR modes are given in Table 1a in [2]. 0 0 1 2 +-+-+-+ |Q|L|R| +-+-+-+ Figure 1: AMR payload header, R=0 0 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+ |Q|L|R| CMR | +-+-+-+-+-+-+-+ Figure 2: AMR payload header, R=1 3.2. AMR payload frame An AMR payload frame represent one encoded speech frame. Each payload frame includes several specified fields as follows: F (1 bit): Indicates if this frame is followed by further frames. F=1 further frames follow, F=0 last frame. LEN (5 bits): OPTIONAL field, exists if the payload header bit L is set, L=1. LEN specifies the number of octets in the FT field and AMR encoded bits field in this frame. If LEN indicates more bits than the AMR mode information in the FT field, the implicit knowledge of the number of bits for the AMR mode indicated by FT is the valid number Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 5] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 of AMR encoded bits. If LEN indicates fewer bits than given by the mode information in the FT field, LEN gives the number of encoded bits. If a frame is transmitted only partially the least sensitive bits at the end of the frame are omitted. This use is intended for partial redundant data. FT (4 bits): Frame type indicator, indicating the AMR speech coding mode or comfort noise (CN) mode. The mapping of existing AMR modes are given in Table 1a in [2]. If FT=15 (No transmission) no LEN or AMR encoded bits follow. AMR encoded bits: This is the speech codec encoded data field. The length of this field is either defined implicitly by the AMR mode in the FT field, or by the LEN field. The last payload frame SHALL always contain a full AMR frame, i.e. no LEN field is needed. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| LEN | FT | | +-+-+-+-+-+-+-+-+-+-+ + | | + + / AMR encoded bits / + +-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Payload frame format, F=1 and L=1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| FT | | +-+-+-+-+-+ + | | + + / AMR encoded bits / + +-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Payload frame format, F=0 or L=0 3.3. Payload block sorting A bit error in a more sensitive bit is subjectively more annoying than in a less sensitive bit. Therefore, to be able to protect the most sensitive bits in a payload packet with a forward error detection code, e.g. a CRC outside RTP, the bits inside a frame are Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 6] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 ordered into sensitivity order. If the option to transmit redundant data is employed, the full RTP payload MUST be further sorted into sensitivity order. The protection MAY then cover an appropriate number of octets from the beginning of the payload. How many octets depend on the channel and application. This can for example be accomplished by UDP lite [10] (work in progress). To maintain sensitivity ordering inside the AMR payload when more than one speech frame is transmitted in one packet reordering of the data is needed. The reordering is only performed if partial redundancy is used, i.e. L=1. The reordering to maintain the sensitivity ordered AMR payload SHALL be performed on bit level. The AMR payload header SHALL still be placed unchanged in the beginning of the payload. Thereafter, the payload frames are sorted with one bit alternating from each payload frame. +-------------+ | h(0)-h(H-1) | +------------------------+ | f(0,0) _ f(0,F(0)) | +----------------------------+ | f(1,0) _ f(1,F(1)) | +----------------------------+ | f(2,0) _ f(2,F(2)) | +----------------------+ \ \ +-------------------------------+ | f(N-1,0) _ f(N-1,F(N-1)) | +-------------------------------+ Figure 5: The payload header and N payload frames before sorting. The sorting algorithm can be described in C-code. b(m) - bit m of RTP final payload f(n,m) - bit m in payload frame n F(n) - number of bits in payload frame n, defined by FT or by LEN h(m) - bit m of payload header H - number of payload header bits, 3 or 7 bits N - number of payload frames in the payload S - number of unused bits Payload frames f(n,m) are ordered in consecutive order, where frame n=1 is preceding frame n=2. The sorting algorithm is defined in C-style as: for (i = 0; i < H; i++){ b(i) = h(i); } Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 7] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 max = max(F(0),..,F(N-1)); k = H; for (i = 0; i < max; i++){ for (j = 0; j < N; j++){ if (i < F(j)){ b(k++) = f(j,i); } } } S = 8 - k%8; if (S < 8){ for (i = 0; i < S; i++){ b(k++) = 0; } } Note that if multiple new frames are encapsulated into the payload and partial redundant data is not transmitted, payload bit-sorting SHALL NOT be performed but the payload is formed by concatenating the payload header and the bits from each AMR frame in the payload. However, the bits inside a frame are ordered into sensitivity order as defined in [2]. In this case the bits are stored into payload according to C-style algorithm below (see the definition of symbols above). for (i = 0; i < H; i++){ b(i) = h(i); } k = H; for (j = 0; j < N; j++){ for (i = 0; i < F(j); i++){ b(k++) = f(j,i); } } } S = 8 - k%8; if (S < 8){ for (i = 0; i < S; i++){ b(k++) = 0; } } 4. RTP header usage The RTP header marker bit (M) is used to mark (M=1) the packages containing the first speech frame after CN. All other packages the marker bit is set to 0 (M=0). The timestamp corresponds to the sampling time of the first sample encoded for the first encoded speech frame in the packet. The Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 8] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 timestamp unit is in samples. The duration of one AMR speech frame is 20 ms and the sampling frequency is 8 kHz, corresponding to 160 encoded speech samples per frame. Thus, the timestamp is increased by 160 for each consecutive frame. All frames in a packet MUST be successive 20 ms frames. 5. Examples 5.1. Simple example In the simple example we just send one full (L=0) frame in each RTP packet, no Codec Mode Request CMR is sent (R=0), the payload was not damaged at IP origin (Q=1). In this example we transmit one frame encoded with the 5.9 kbps mode (FT=2). The speech encoded bits are put into f(0) to f(117) in descending sensitivity order according to [2]. | Bit no. | Oct| 0 1 2 3 4 5 6 7 | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 0 | Q=1 | L=0 | R=0 | F=0 | 0 | 0 | 1 | 0 | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 1 | f(0) | f(1) | f(2) | ... | ... | ... | ... | ... | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 15 | ... | ... | ... | f(115)| f(116)| f(117)| 0 | 0 | ---+-------+-------+-------+-------+-------+-------+-------+-------+ Figure 6: One frame per packet example. 5.2. Example with partial redundancy In this example the 6.7 kbps mode (FT=3) is sent with one redundant frame, also FT=3. Only a part of the redundant frame is sent, in this example 12 octets, (L=1, LEN=12). A mode request is sent(R=1), requesting the 10.2 kbps mode for the other link(CMR=6). The redundant frame (12 octets) is r(0) to r(95) and the current frame (134 bits) is f(0) to f(133). | Bit no. | Oct| 0 1 2 3 4 5 6 7 | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 0 | Q=1 | L=1 | R=1 | 0 | 1 | 1 | 0 | F=1 | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 1 | F=0 | 0 | 0 | 1 | 0 | 1 | 1 | 0 | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 2 | 1 | 0 | f(0) | 0 | f(1) | 0 | f(2) | 1 | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 3 | f(3) | 1 | f(4) | r(0) | f(5) | r(1) | f(6) | r(2) | ---+-------+-------+-------+-------+-------+-------+-------+-------+ Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 9] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 4 | f(7) | r(3) | f(8) | ... | ... | ... | ... | ... | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 26 | f(95) | r(91) | f(96) | f(97) | f(98) | ... | ... | ... | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 30 | ... | ... | ... | ... | ... | f(131)| f(132)| f(133)| ---+-------+-------+-------+-------+-------+-------+-------+-------+ Figure 7: Example with partial redundancy. 5.3. Example with multiple frames per payload In this example two 5.9 kbps mode (FT=2) frames are sent in one packet. No partial redundancy is used (L=0). A mode request is sent(R=1), requesting the 7.95 kbps mode for the other link(CMR=5). The first frame is represented by the 118 bits f(0) to f(117) and the subsequent frame by g(0) to g(117). | Bit no. | Oct| 0 1 2 3 4 5 6 7 | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 0 | Q=1 | L=0 | R=1 | 0 | 1 | 0 | 1 | F=1 | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 1 | 0 | 0 | 1 | 0 | f(0) | f(1) | ... | ... | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 15 | ... | ... | ... | ... | ... | ... | ... | f(115)| ---+-------+-------+-------+-------+-------+-------+-------+-------+ 16 | f(116)| f(117)| F=0 | 0 | 0 | 1 | 0 | g(0) | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 17 | g(1) | g(2) | ... | ... | ... | ... | ... | ... | ---+-------+-------+-------+-------+-------+-------+-------+-------+ 31 | ... | ... | ... | g(116)| g(117)| 0 | 0 | 0 | ---+-------+-------+-------+-------+-------+-------+-------+-------+ Figure 8: Example two frames per payload. 6. The AMR MIME type registration This chapter defines the MIME type for Adaptive Multi-Rate (AMR) speech codec [1]. The data format and parameters are specified for both real-time transport and for storage type applications (e.g. e- mail attachment, multimedia messaging). The former is referred as RTP mode and the latter as storage mode. AMR implementations according to [1] MUST support all eight coding modes. The mode change can occur at any time during operation and therefore the mode information is transmitted in-band together with speech bits to allow mode change without any additional signaling. Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 10] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 In addition to the speech codec, AMR specifications also include Discontinuous Transmission / comfort noise (DTX/CN) functionality [11]. The DTX/CN switches the transmission off during silent parts of the speech and only CN parameter updates are sent in regular intervals. 6.1 RTP mode It is possible that the decoder may want to receive certain AMR mode or a subset of AMR modes. In the end to end transmission parts of the chain may have limitations in the number of modes in the active codec set, e.g. the GSM radio link can only use a subset of maximum four modes. Therefore, it is possible to request specific set of AMR modes in capability description and it is mandatory for encoder to abide this request. If request for mode set is not given, encoder can freely decide which AMR mode to use. Although in principle AMR codec can perform a mode change at any time between any two modes, it is possible to set limitations for mode changes. The decoder has possibility to define the minimum number of frames between mode changes and to limit the mode change to happen into neighboring modes only. In addition to AMR DTX/CN scheme, the three codec standards that are part of the AMR also have their own DTX/CN schemes ([6][7][12]). To enable interoperability with terminals supporting these standards, AMR can optionally be extended to support also these CN schemes. The CN capabilities are signaled in capability description. If no CN capabilities are reported, it is assumed that AMR CN is supported. If CN capabilities are reported, all supported CN types (including AMR CN) must be signaled. It is also possible to limit the number of AMR frames encapsulated into one RTP packet. This is an optional feature and if no parameter is given in capability description, the transmitter can encapsulate any number of AMR speech frames into one RTP packet. There is also an option to retransmit one or more previously transmitted frames to help the receiver to recover from packet losses in difficult transmission conditions. It also possible to transmit these frames only partially in such a way that only the most sensitive bits are transmitted. Since the transmission of partly redundant frames is an optional property, it can be used only if the receiver has signaled support for this functionality in capability description. The partial redundancy is RECOMMENDED to be implemented and turned on at least for conversational services. Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 11] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 6.2 Storage mode For storing AMR frames e.g. as a file or e-mail attachment, the AMR frames must be formatted according to Annex A of [9]. Because no exchange of particular coding parameters, e.g. specific DTX/CN mode, can be signaled before downloading or receiving stored AMR data, the receiving entity (AMR decoder) MUST be able to decode all eight coding modes as well as the AMR DTX/CN [6]. 6.3 MIME Registration MIME-name for the AMR codec is allocated from IETF tree since AMR is expected to be widely used speech codec in VoIP applications. Some parts of this chapter will distinguish between RTP and storage modes. Media Type name: audio Media subtype name: AMR Required parameters: none Optional parameters for RTP mode: ptime: Definition as usual in RTP audio. mode-set: Requested AMR mode set. Restricts the active codec mode set to a subset of all modes. Possible values are: 0,...,7 (see Table 1a [2]). If not present, all speech modes are available. mode-change-period: Defines a number N which restricts the mode changes in such a way that mode changes are only allowed on multiples of N, initial state of the phase is arbitrary. If this parameter is not present, mode change can happen at any time. mode-change-neighbor: If present, mode changes SHALL be made to neighboring modes only. If not present, change between any two modes is allowed. amr-cn: If present, GSM AMR DTX/CN is supported. Note that if no CN capabilities are reported, AMR DTX/CN is assumed to be supported, i.e. this parameter is only sent together with one of the following CN parameters. pdc-efr-cn:If present, PDC-EFR DTX/CN is supported, otherwise not supported. is-641-cn: If present, IS-641 DTX/CN is supported, otherwise not supported. gsm-efr-cn:If present, GSM EFR DTX/CN is supported, otherwise not supported. maxframes: Maximum number of AMR speech frames in one RTP packet. The receiver may set this parameter in order to limit the buffering requirements or delay. redundancy:If present, transmission of partly redundant frames is supported, otherwise not supported. Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 12] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 Optional parameters for storage mode: none Encoding considerations for RTP mode: See section 3 in this document. Encoding considerations for storage mode: Each audio frame must be formatted in octet format according to AMR Interface Format 2 (AMR IF2) specified in Annex A of [2]. The audio frames must be stored in sequential order. This implies that the first octet after frame n must be the first octet of frame (n+1). Furthermore, missing frames and non-received frames between CN updates during non-speech period must be stored as NO_TRANSMISSION frames (frame type 15, see definition in [2]). Each receiving entity that accepts this MIME type must be able to decode all eight AMR coding modes [1] and the AMR DTX/CN [11]. Security considerations: none Interoperability considerations for RTP mode: If CN capabilities are not signaled in the capability description, only AMR CN is supported. Public specification: please refer to chapter 7 "References". Additional information for storage mode: Magic number: none File extensions: amr, AMR Macintosh file type code: none Object identifier or OID: none Person & email address to contact for further information: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com Intended usage: COMMON. It is expected that many VoIP applications (as well as mobile applications) will use this type. Author/Change controller: johan.sjoberg@ericsson.com ari.lakaniemi@nokia.com 6.4 Mapping to SDP Parameters Please note that this chapter applies to the RTP mode only. Parameters are mapped to SDP [13] as usual. Example usage in SDP: m=audio 49120 RTP/AVP 97 a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 13] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 7. References [1] GSM 06.90, "Adaptive Multi-Rate (AMR) speech transcoding". [2] 3G TS 26.101, "AMR Speech Codec Frame Structure". [3] IETF RFC 2119, "Key words for use in RFCs to Indicate Requirement Levels". [4] 3G TS 26.093, "AMR Speech Codec; Source Controlled Rate operation". [5] GSM 06.60, "Enhanced Full Rate (EFR) speech transcoding". [6] TIA/EIA -136-Rev.A, part 410 - "TDMA Cellular/PCS - Radio Interface, Enhanced Full Rate Voice Codec (ACELP). Formerly IS- 641. TIA published standard, 1998". [7] ARIB, RCR STD-27H, "Personal Digital Cellular Telecommunication System RCR Standard". [8] IETF RFC1889, "RTP: A Transport Protocol for Real-Time Applications". [9] IETF draft-westberg-realtime-cellular-01.txt, "Realtime Traffic over Cellular Access Networks". [10] IETF draft-larzon-udplite-02.txt, "The UDP Lite Protocol". [11] GSM 06.92, "Comfort noise aspects for Adaptive Multi-Rate (AMR) speech traffic channels". [12] GSM 06.62: Comfort noise aspect for Enhanced Full Rate (EFR) speech traffic channels [13] M. Handley and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998 [14] 3G TS 25.415 "UTRAN Iu Interface User Plane Protocols" Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 14] INTERNET-DRAFT RTP Payload Format for AMR July 14, 2000 8. Authors' addresses Johan Sjoberg Ericsson Research Ericsson Radio Systems AB Torshamnsgatan 23 SE-164 80 Stockholm SWEDEN E-mail: Johan.Sjoberg@ericsson.com Magnus Westerlund Ericsson Research Ericsson Radio Systems AB Torshamnsgatan 23 SE-164 80 Stockholm SWEDEN E-mail: Magnus.Westerlund@ericsson.com Ari Lakaniemi Nokia Research Center P.O.Box 407 FIN-00045 Nokia Group Finland E-mail: ari.lakaniemi@nokia.com Petri Koskelainen Nokia Research Center P.O.Box 100 FIN-33721 Tampere Finland E-mail: petri.koskelainen@nokia.com This Internet-Draft expires January 14, 2001. Sjoberg/Westerlund/Lakaniemi/Koskelainen [Page 15] --Boundary_(ID_2SCANejE9DIv3wZM94wSCg)-- From rem-conf Tue Jul 18 02:14:36 2000 From rem-conf-request@es.net Tue Jul 18 02:14:34 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13ETHp-0000eA-00; Tue, 18 Jul 2000 02:03:33 -0700 Received: from smtp1.cluster.oleane.net [195.25.12.16] by mail1.es.net with esmtp (Exim 1.81 #2) id 13ETHn-0000e0-00; Tue, 18 Jul 2000 02:03:32 -0700 Received: from oleane (dyn-1-1-161.Vin.dialup.oleane.fr [195.25.4.161]) by smtp1.cluster.oleane.net with SMTP id LAA02776; Tue, 18 Jul 2000 11:02:23 +0200 (CEST) Message-ID: <013401bff097$20cd0be0$0401a8c0@oleane.com> From: "mg263-8" To: Subject: Implementing H.323 Date: Tue, 18 Jul 2000 11:04:02 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0131_01BFF0A7.E194E720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0131_01BFF0A7.E194E720 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable "Implementing H.323": the VoIP deployment scenario International conference, Paris, 10-13 October http://www.upperside.fr/bah323.htm =20 ------=_NextPart_000_0131_01BFF0A7.E194E720 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

"Implementing H.323": the VoIP = deployment scenario
International conference, Paris, 10-13 = October
http://www.upperside.fr/bah32= 3.htm
 
 
------=_NextPart_000_0131_01BFF0A7.E194E720-- From rem-conf Tue Jul 18 08:41:09 2000 From rem-conf-request@es.net Tue Jul 18 08:41:08 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EZNL-0005ag-00; Tue, 18 Jul 2000 08:33:39 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EZNJ-0005aW-00; Tue, 18 Jul 2000 08:33:38 -0700 Received: from NSYRACUS ([10.27.5.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22513; Tue, 18 Jul 2000 11:33:32 -0400 (EDT) Date: Tue, 18 Jul 2000 11:36:54 -0400 (Eastern Daylight Time) From: Natalia Syracuse To: chuah cc: internet-drafts@ietf.org, rem-conf@es.net Subject: Re: LIPE internet draft In-Reply-To: <200007141449.KAA02159@qc84.ho.lucent.com> Message-ID: X-X-Sender: nsyracus@odin.ietf.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Inside is not avt draft. Please check and resend directly to me. Natalia Syracuse On Fri, 14 Jul 2000, chuah wrote: > Hi, > we wish to submit this draft to IETF AVT Working Group. > > thanks > Mooi Choo > From rem-conf Tue Jul 18 12:10:42 2000 From rem-conf-request@es.net Tue Jul 18 12:10:41 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ecgh-0000p8-00; Tue, 18 Jul 2000 12:05:51 -0700 Received: from athm-216-216-xxx-85.home.net (happy.omneon.com) [216.216.222.85] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Ecgg-0000oY-00; Tue, 18 Jul 2000 12:05:50 -0700 Received: by HAPPY with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Jul 2000 12:05:35 -0700 Message-ID: <03AB3CB11CBED3118A4F009027B0C2B141760E@HAPPY> From: Bill Nowicki To: rem-conf@es.net Subject: Uncompressed video payloads Date: Tue, 18 Jul 2000 12:05:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list It looks like draft-ietf-avt-smpte292-video-00.txt is meant to subsume the "hdtv" draft from last time? I will make my usual suggestion that this could easily be generalized as a payload format for all uncompressed video formats. That is, it could subsume RFC 2431 which was specific to standard definition. The same extended header could be used for all resolutions, with negotiation in the SDP parameters what the exact resolution, frame rate, pixel aspect ratio, sample quantization (8 or 10 bit). Then just have a list of some examples: SMPTE 292 would be one allowed set of parameters, BT.656 would be another (corresponding to SMPTE 259), and my desired application, lower resolution for existing network technology, would be another. The only issue I have with the payload format itself is that you seem to be following the uncompresed audio convention of incrementing the time stamp on each packet, as opposed to the video convention of having all packets for the same video frame having the same time stamp. I would vote to keep the video convention, since you can already retime the packets within each frame >from using the sequence number and offset, right? And you know missing packets from the sequence number, so the timestamp per packet gives you no new information. If you followed the video ceonvention of per-frame time stamps, then each packet could not contain samples from two frames, which generally makes decoding easier anyway. Bill Nowicki, Omneon Video, 408-585-5126 From rem-conf Tue Jul 18 12:58:31 2000 From rem-conf-request@es.net Tue Jul 18 12:58:30 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EdSx-0002EP-00; Tue, 18 Jul 2000 12:55:43 -0700 Received: from hulinks006.hulinks.co.jp (UnixServer.) [206.3.26.6] by mail1.es.net with smtp (Exim 1.81 #2) id 13EdSv-0002EF-00; Tue, 18 Jul 2000 12:55:41 -0700 Received: from from jofes. ([273.44.31.4]) by rs5s2.dadacentere1.chea.camtv.net.ie (8.9.1a/8.9.1/1.0) with SMTP id NAE11975 by UnixServer. (SMI-8.6/SMI-SVR4) id EAA01190; Wed, 19 Jul 2000 04:50:35 +0900 From: reply10@uole.com Message-ID: <00004e1e704e$00006a94$000077fe@from jofes. ([273.44.31.4]) by rs5s2.dadacentere1.chea.camtv.net.ie (8.9.1a/8.9.1/1.0) with SMTP id NAE11975 > To: Subject: Win a trip for 2 to the Sydney 2000 Olympics in Australia - Obligation Free!. Date: Sun, 16 Jul 2000 13:46:48 -0400 X-Priority: 3 X-MSMail-Priority: Normal Reply-To: reply10@uole.com X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Win airfares, 6 nights first class accommodation and tickets to major events at the 2000 Olympics in Sydney this September. Register free for August 10 prize draw by clicking here: http://www.govisitaustralia.com/default1.htm or here: http://www.govisitaustralianow.com/default1.htm The lucky winners of our July 10 Draw are already packing their bags! See you in Sydney! ============================================================== Note: If you have received this notice in error and do not wish to participate, please accept our apologies and please double click on the below link to be excluded >from further communication mailto:zone15@uol.com.ar?subject=delete ============================================================== Win airfares, 6 nights first class accommodation and tickets to major events at the 2000 Olympics in Sydney this September. From rem-conf Tue Jul 18 14:44:34 2000 From rem-conf-request@es.net Tue Jul 18 14:44:33 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Ef6R-0004HQ-00; Tue, 18 Jul 2000 14:40:35 -0700 Received: from tnt.isi.edu [128.9.128.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Ef6Q-0004H1-00; Tue, 18 Jul 2000 14:40:34 -0700 Received: from rum.isi.edu (rum.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id OAA17846 for ; Tue, 18 Jul 2000 14:40:29 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.9.3/8.8.6) id OAA06676 for rem-conf@es.net; Tue, 18 Jul 2000 14:40:28 -0700 (PDT) Date: Tue, 18 Jul 2000 14:40:28 -0700 (PDT) Message-Id: <200007182140.OAA06676@rum.isi.edu> To: rem-conf@es.net Subject: REMINDER - Sigcomm 2000 Early Registration deadline approaching X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list REMINDER: The deadline for early registration is fast approaching. Please see the website below for further information. --------------------------------------------------------------- Call for Papers ACM SIGCOMM 2000 Conference August 28 - September 1, 2000 Grand Hotel, Stockholm, Sweden http://www.acm.org/sigcomm/sigcomm2000 sigcomm2000-info@acm.org >> Early registration deadline: July 28, 2000 SIGCOMM 2000 is the annual conference of the Special Interest Group on Data Communication (SIGCOMM), a single-track, highly selective conference with a technical program of 26 papers, tutorials by noted instructors on the two days prior, and a work-in-progress poster session and a social session on outrageous opinions. All papers are currently available at the conference at the conference website. The SIGCOMM 2000 Award is being given to Prof. André Danthine, University of Liege, Belgium, who will also provide the keynote address. Registration Early registration for SIGCOMM 2000 is open through July 28, 2000. The conference and hotel registration is handled by the Stockholm Convention Bureau (for instructions on registration, see website above). Note that the number of delegates is limited to 500 and that registration requests will be handled on a "first-come-first-served" basis. On-line, secure registration is available at the SIGCOMM website. Please refer also to the web form or paper form for various rates and options. Stockholm, Opening Reception and Dinner events Stockholm - the Royal capital of Sweden - is one of the most beautiful cities in the world. It is built on fourteen islands and surrounded by waters so clean that you can fish and swim in the middle of the city. The reception is generously hosted by Stockholm City, and includes a sightseeing cruise on the water ways of Stockholm, through the Old Town to the City Hall, famous for the Nobel Prize festivities. The banquet dinner is hosted at the Vasa Museum, site of the Sweden's largest and most prestigious warship. General Co-Chairs Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se) Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se) Program Co-Chairs Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com) Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu) Publicity Chair Joe Touch, USC/ISI, USA (touch@isi.edu) Tutorials Chair Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se) From rem-conf Tue Jul 18 17:13:51 2000 From rem-conf-request@es.net Tue Jul 18 17:13:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EhR6-0006dm-00; Tue, 18 Jul 2000 17:10:04 -0700 Received: from gatekeeper-b3.c-cube.com [205.227.120.254] by mail1.es.net with smtp (Exim 1.81 #2) id 13EhR5-0006da-00; Tue, 18 Jul 2000 17:10:03 -0700 Received: from mailhost.c-cube.com by gatekeeper-b3.c-cube.com via smtpd (for mail1.es.net [198.128.3.181]) with SMTP; 18 Jul 2000 23:45:23 UT Received: from c-cube.com by fedex.c-cube.com (SMI-8.6/C-Cube-Fedex) id RAA07106; Tue, 18 Jul 2000 17:07:06 -0700 Message-ID: <3974F100.3C014A21@c-cube.com> Date: Tue, 18 Jul 2000 17:06:24 -0700 From: Wenqing Jiang X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: Questions on RFC 2429 and RFC 2736 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I am interested in looking into the robustness of the H.263+ bitstream packetization technique as described in RFC2429 according to what required in RFC 2736. Q1: is there a template implementation of RFC2429? Q2: is there a good modelling of packet losses over the network? or should one assume independent loss or bursty loss like Makovian chain? One paper in PacketVideo'2000 from Nokia did some work on this but the paper says that the loss pattern was hand-generated. don't know what exactly it means. Any help will be appreciated, Sincerely, Wenqing From rem-conf Tue Jul 18 19:28:18 2000 From rem-conf-request@es.net Tue Jul 18 19:28:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EjXq-0000i7-00; Tue, 18 Jul 2000 19:25:10 -0700 Received: from tnt.isi.edu [128.9.128.128] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EjXp-0000hx-00; Tue, 18 Jul 2000 19:25:09 -0700 Received: from rum.isi.edu (rum.isi.edu [128.9.160.237]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id TAA21279 for ; Tue, 18 Jul 2000 19:25:08 -0700 (PDT) From: Joe Touch Received: (from touch@localhost) by rum.isi.edu (8.9.3/8.8.6) id TAA08325 for rem-conf@es.net; Tue, 18 Jul 2000 19:25:07 -0700 (PDT) Date: Tue, 18 Jul 2000 19:25:07 -0700 (PDT) Message-Id: <200007190225.TAA08325@rum.isi.edu> To: rem-conf@es.net Subject: REMINDER - Sigcomm 2000 Early Registration deadline approaching X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list REMINDER: The deadline for early registration is fast approaching. Please see the website below for further information. --------------------------------------------------------------- Call for Participation ACM SIGCOMM 2000 Conference August 28 - September 1, 2000 Grand Hotel, Stockholm, Sweden http://www.acm.org/sigcomm/sigcomm2000 sigcomm2000-info@acm.org >> Early registration deadline: July 28, 2000 SIGCOMM 2000 is the annual conference of the Special Interest Group on Data Communication (SIGCOMM), a single-track, highly selective conference with a technical program of 26 papers, tutorials by noted instructors on the two days prior, and a work-in-progress poster session and a social session on outrageous opinions. All papers are currently available at the conference at the conference website. The SIGCOMM 2000 Award is being given to Prof. André Danthine, University of Liege, Belgium, who will also provide the keynote address. Registration Early registration for SIGCOMM 2000 is open through July 28, 2000. The conference and hotel registration is handled by the Stockholm Convention Bureau (for instructions on registration, see website above). Note that the number of delegates is limited to 500 and that registration requests will be handled on a "first-come-first-served" basis. On-line, secure registration is available at the SIGCOMM website. Please refer also to the web form or paper form for various rates and options. Stockholm, Opening Reception and Dinner events Stockholm - the Royal capital of Sweden - is one of the most beautiful cities in the world. It is built on fourteen islands and surrounded by waters so clean that you can fish and swim in the middle of the city. The reception is generously hosted by Stockholm City, and includes a sightseeing cruise on the water ways of Stockholm, through the Old Town to the City Hall, famous for the Nobel Prize festivities. The banquet dinner is hosted at the Vasa Museum, site of the Sweden's largest and most prestigious warship. General Co-Chairs Per Gunningberg, Uppsala U., Sweden (perg@docs.uu.se) Steve Pink, Lulea U. Tech., Sweden (steve@cdt.luth.se) Program Co-Chairs Christophe Diot, Sprint ATL, USA (cdiot@sprintlabs.com) Jim Kurose, U. Massachusetts, USA (kurose@cs.umass.edu) Publicity Chair Joe Touch, USC/ISI, USA (touch@isi.edu) Tutorials Chair Steve Pink, Lulea U Tech., Sweden (steve@cdt.luth.se) From rem-conf Wed Jul 19 03:53:10 2000 From rem-conf-request@es.net Wed Jul 19 03:53:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Er8i-0006uN-00; Wed, 19 Jul 2000 03:31:44 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Er8h-0006uD-00; Wed, 19 Jul 2000 03:31:43 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19469; Wed, 19 Jul 2000 06:31:42 -0400 (EDT) Message-Id: <200007191031.GAA19469@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-tcrtp-01.txt Date: Wed, 19 Jul 2000 06:31:42 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 : Tunneling multiplexed Compressed RTP ('TCRTP') Author(s) : B. Thompson, T. Koren, D. Wing Filename : draft-ietf-avt-tcrtp-01.txt Pages : Date : 18-Jul-00 This document describes a method to improve the end-to-end bandwidth utilization of RTP streams over an IP network using compression and multiplexing. Several application level compression/multiplexing solutions have been evaluated so far in the IETF AVT Working Group. This proposal differs from other solutions in that neither compression nor multiplexing needs to be done at application level. Because of this, existing RTP based applications do not need to change to support this encapsulation format. Instead of proposing a new encapsulation format for end to end multiplexing, this document describes the application of existing protocols for compression, multiplexing, and end to end tunneling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-tcrtp-01.txt 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-tcrtp-01.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-tcrtp-01.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: <20000718135222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-tcrtp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-tcrtp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000718135222.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Jul 19 03:53:10 2000 From rem-conf-request@es.net Wed Jul 19 03:53:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Er22-0006nI-00; Wed, 19 Jul 2000 03:24:50 -0700 Received: from (tsmtp4.mail.isp) [195.235.113.151] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Er1S-0006mT-00; Wed, 19 Jul 2000 03:24:14 -0700 Received: from cultureta ([195.5.74.75]) by tsmtp4.mail.isp (Netscape Messaging Server 4.1) with SMTP id FXXWR906.U4F; Wed, 19 Jul 2000 12:21:09 +0200 Message-ID: <001801bff16b$4132b4a0$fe00a8c0@cultureta> From: "Damos a conocer la Cultura" To: Subject: Cine bajo las estrellas Date: Wed, 19 Jul 2000 12:21:28 +0200 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0014_01BFF17B.DDA4CDE0"; type="multipart/alternative" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0014_01BFF17B.DDA4CDE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0015_01BFF17B.DDA4CDE0" ------=_NextPart_001_0015_01BFF17B.DDA4CDE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 =20 Adios a Jos=E9 Angel Valente El poeta gallego ha fallecido a los 71 a=F1os de edad M=E1s Informaci=F3n=20 Otros Titulares=20 n Ruta por los festivales nacionales de Teatro Cl=E1sico=20 n Entrevista con Antonio Orejudo, ganador del Premio Andaluc=EDa = de novela=20 n Sonidos c=E1lidos para el verano malague=F1o=20 n El litoral andaluz propone un rico programa de actividades = culturales=20 -------------------------------------------------------------------------= - Portada=20 Noticias culturales=20 Versi=F3n multimedia=20 Cr=EDtica de eventos=20 Rese=F1as de discos=20 Rese=F1as de libros=20 Cartelera de Andaluc=EDa=20 Espacio Virtual de las Artes=20 Andaluc=EDa Cultural=20 Entrevistas=20 Reportajes=20 Eventos=20 Denominaci=F3n de Origen=20 Temas de Actualidad =20 cine arte escena m=FAsica literatura=20 =20 =20 CINE BAJO LAS ESTRELLAS, del patio de vecinos al patio de butacas =20 El cine de verano ha sido durante a=F1os algo m=E1s que un modo de = exhibici=F3n cinematogr=E1fica: casi una peculiar extensi=F3n de la = cultura popular de los patios de vecinos. A=FAn quedan unos cuantos = repartidos por distintos puntos de Andaluc=EDa=20 M=E1s Informaci=F3n =20 =20 -------------------------------------------------------------------------= - =20 -------------------------------------------------------------------------= - =20 Javier Bar=F3n, tac=F3n de hierro y bronce=20 Javier Bar=F3n ha probado todos los manjares de la danza, y de = todos ellos se queda con el m=E1s tradicional de los flamencos. En el = Festival de Niebla se representa su montaje Un ramito de locura y en = laBienal de Flemanco estrena Baile de hierro, baile de bronce. M=E1s = Informaci=F3n =20 =20 =20 -------------------------------------------------------------------------= - =20 Pr=F3ximamente La bienal de Flamenco en elcultural.com =20 =20 Mirada atr=E1s Teo Escamilla, cineasta =20 Mirada adelante Pepa D=EDaz-Meco, actriz =20 Web de la semana=20 www.artef@ctosvirtuales.com =20 Actualidad Festival de Benic=E0ssim=20 Una cita con la m=FAsica el primer fin de semana de agosto =20 portada / contenidos multimedias de la semana / sugerencias / sobre = elcultural.com/ dossier de prensa=20 =20 Si no quieres volver a recibir mensajes de elcultural.com pincha = aqu=ED y b=F3rrate de la Secci=F3n Contenidos de Actualidad=20 =20 =20 ------=_NextPart_001_0015_01BFF17B.DDA4CDE0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 

Adios a Jos=E9 Angel Valente
El poeta = gallego ha=20 fallecido a los 71 a=F1os de edad
M=E1= s=20 Informaci=F3n

Otros=20 Titulares

 n=20 Ruta por = los=20 festivales nacionales de Teatro Cl=E1sico=20

 n = Ent= revista=20 con Antonio Orejudo, ganador del Premio Andaluc=EDa de=20 novela=20

 n = Sonid= os=20 c=E1lidos para el verano malague=F1o=20

 n = El= =20 litoral andaluz propone un rico programa de actividades=20 culturales=20

Portada =
Noticias = culturales=20
Versi=F3n=20 multimedia
Cr=EDtica=20 de eventos
Rese=F1as de=20 discos
Rese=F1as = de=20 libros
Cartelera de = Andaluc=EDa=20
Espacio Virtual = de las=20 Artes
Andaluc=EDa=20 Cultural
Entr= evistas=20
Repor= tajes=20
Eventos<= /A>=20
De= nominaci=F3n=20 de Origen
Temas de=20 Actualidad
cine arte escena m=FAsica literatura
CINE BAJO LAS ESTRELLAS, = del patio de=20 vecinos al patio de butacas
El cine de verano ha = sido durante=20 a=F1os algo m=E1s que un modo de exhibici=F3n cinematogr=E1fica: = casi  una=20 peculiar extensi=F3n de la cultura popular de los patios de=20 vecinos. A=FAn quedan unos cuantos repartidos por distintos = puntos=20 de Andaluc=EDa 
M=E1= s=20 Informaci=F3n 
Javier Bar=F3n, tac=F3n de = hierro y=20 bronce
  Javier Bar=F3n ha probado = todos los=20 manjares de la danza, y de todos ellos se queda con el m=E1s = tradicional de=20 los flamencos. En el Festival de Niebla se representa su montaje = Un=20 ramito de locura y en laBienal de Flemanco estrena Baile de = hierro,=20 baile de bronce. = M= =E1s=20 Informaci=F3n

Pr=F3ximamente
La=20 bienal de Flamenco en elcultural.com
=20

Mirada = atr=E1s
Te= o=20 Escamilla, cineasta
Mirada = adelante
Pe= pa=20 D=EDaz-Meco, actriz
Web=20 de la semana
= www.artef@ctosvirtuales.com
Actualidad
Festival de=20 Benic=E0ssim
Una cita con la m=FAsica el = primer fin de=20 semana de agosto

portada / contenidos=20 multimedias de la semana / sugerencias / sobre=20 elcultural.com/ dossier de=20 prensa
 
Si no quieres volver a recibir mensajes de = elcultural.com pincha=20 aqu=ED y=20 b=F3rrate de la Secci=F3n Contenidos de Actualidad=20

------=_NextPart_001_0015_01BFF17B.DDA4CDE0-- ------=_NextPart_000_0014_01BFF17B.DDA4CDE0 Content-Type: image/jpeg; name="elcultural.jpg" Content-Transfer-Encoding: base64 Content-ID: <000d01bff16b$1a0393e0$fe00a8c0@cultureta> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAATQAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAADFwAABh8AAAgyAAAK3//bAIQAAwICAgICAwICAwQDAgMEBQQDAwQFBgUFBQUFBgcG BgYGBgYHBwgJCQkIBwsLDAwLCw0MDAwNDg4ODg4ODg4ODgEDAwMGBQYLBwcLEA0KDRATDg4ODhMR Dg4ODg4REQ4ODg4ODhEODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O/8IAEQgADQB7AwERAAIR AQMRAf/EAMsAAQEBAQAAAAAAAAAAAAAAAAYEBQcBAAMBAQEAAAAAAAAAAAAAAAECBAMFABAAAAUE AQIFBQAAAAAAAAAAAQIEBQYAERIDIhMUECEVFgcgMDEjFxEAAQIEBAUDAgUFAAAAAAAAAQIDERIE BQAhExQxQTIVBlFhIkIz8HGBoSSxI0MlFhIAAgIBAwMFAAAAAAAAAAAAABEBAjEhYYFBwRJQoSIy ghMAAgMAAgIBBAIDAQAAAAAAAREAITFBUWFxoRCBkbHw0SDB4fH/2gAMAwEAAhEDEQAAAejdnMXc jaF7s/GagOtXqvJc7QEE5E3L2LjaAegl+Zydhn6DSyIa9d6cl6l08ibpDKNitS7mBuQi7V6hynAd FLczYnpm9ch//9oACAEBAAEFAnv5CIhdZLMlD/G980ctq5TNFCda7zrcqa1sglaJDqm2wzwb5M3E aF8sfG5G4z/e7QpiMdDGU06fXLW6TdURy3fJpPRzfJjqUf6SPauRGw0pXlY/VR1pRXyQrSLyQka9 nSMjaaSvRGcX9ISOd3JCIBnvTjPsnaVB7mY9eoEjyRvNIiliQqxIx9jjGOh//9oACAECAAEFAtaS 4aU+BwTBYE1w1pbCXUQRFNx7LkXQURIlx2bfM4pSloiYLAi5dkWuz8yXwLlbztpyx59TTfDXlibO 2m/S59QL4bfzrvh+y3K/Ov/aAAgBAwABBQK9CNXq9Xq9XrKr1fwvV6yrKsvoHwHxH7H/2gAIAQIC Bj8CckvVDtKZaXgruWtJEvJMPBpJEEoU21HaUTDwR8smeq7kPjJcr5LYthEYwWK42Lm3PY6YISzy T9fIq1sXZT2P0f/aAAgBAwIGPwL0D//aAAgBAQEGPwJ+z21hl5+kQVVLtRUJp0RH0Im6lYtLloU9 QVdfXaKw2shQkyICkwiIrGKy2+M2pVzTbPjVvqdCPkMpU5GY5YsluXblN1l2P91l1cFMfKXkDHme WPJm6Zrbi2Qp2qtLnyUtxZbiMhDhHjjxyyUOq5U1rKKhx0ujVqJ1TacyolOXPFxtbtGEJtlFuql3 Uj8ghKlN9PqYRxbLl2yZ+5vuNNUyXc5WyExBlziTimXWWtmnq6hSpw9WNoaaSD8ZlniT7YutYy2a KuYdbpkuNORBK1dSFgJPAHFG7cXVKW3SJdqXnCVHpmUSTnjuVp8fcqbIXdNLodGqqHFQbh+PXFRa rBbjX1NE1q1qlOBpLYhGXnE4tlypaBTr9wfUxtZ4FKkQjKYZ9Q9MXNk2M7m25vDXTK2mMDOYf0jj ddvy7V3GXU+rcbeTp4c4/ti8G0P1jdTH/YJSzSLTNz0lVDqDGPoI48TNQ5Vghz+MktsmL06Y6ykr ABjDpBxe1ePP3lNu1z3NFIyyr5THoUp1K+MeUYYsBpnbui4ikTtktNpW8UxV1F5aSF8Y5HFzCX7j t+4t7tSmW9aMDKJS7CEecYx5Y8e2b1aivFK1sgw00tJbz5rcRAwjHjjyEtvXcCCu4pp2WigCI4qL oJRH2GPDoO1ekEnYgtNyqXqGOodTIzekcRQ9Wouu3TBCWqZSCmX/AAqqHEwP6ceGFDXuGw7t/IVo ta2ppZBQ1YS+8ePLF3VXOXE0Hb1zokhRhnSRHSUFmJl9sUBbfvyvGNwduhtltImjnOpl1Tkv6fli +mzvXVBkPek0rLK0S/VKpbqFft68seImicqRQhStiiRBSXtQTayisEKmhwBx5kFPVuuX0dxOi1OB rK+0NWBEfWGWPuVWl/y0Pto+xrdXX9yflw98f//aAAgBAQMBPyEXpiVAC4CbEhzGTDFLfUhPHqas LgPIJIwvJINd5+eRQJEjpToIYU+0moQ6GoUa96YY+OQQDHnoQ712HGgUotlpqbUShkuskAh7lS2k tmoAGhIFWyoUgEsQFAJGT/QnehK4JFdFIiTBQ9p1B1uh6gEBIRaXdBowEnf2oG5uUVq1Ae+lAXx2 OIXX1OWe3ftHzqN4BLmzLZ2GqUMIMJnzej0FKleFNdaYLuVP04EZPr8TUgV/dGVjIICRZ061fTEF Erh6qHfOD1CPYVBCnK6XaIjVoeNxTx8C5OS8M3gNG2Rz0XHyQFKk99wqGmNucyfz/wCahtLuoEG3 MlyRy0R4R969kVOAksVKaoqdNDkMyRdPpbM3/9oACAECAwE/IV5ijiDgsMD/AJ+ICHTBBYD5QDd6 Xq5joCsoLnzAo6If3AHAA37h80gdAswJawncBQOamUvj+YcKg0OXLBQG5ox4fqcX8AtCrwvL5IGH WXncXEdC60T80oVja+vgZCcDYuv1CuAJ2yd/Bh4vcT/WwsI8/jiuofALd/JI+Ns2VvqFyT5Hz94R sFFsn/YUOp9pP9GE4D59Lj7R5Qly8c1G3H916xf+T//aAAgBAwMBPyEywTx+k7jV9YlC4gyPD/hB 2FVPX0UpoQ7KqalKcwQ7KqVcr4n/2gAMAwEAAhEDEQAAEMY0ruocW5X5FYtd8v/aAAgBAQMBPxA5 QiD9pBaGhaJCbpq7Ai4oGoGkAjBXTCmYGCDSCCMEJyA0bfIELDCaJQMFsuS4kogkCjCiF/gRvLEV hBawlrUoeiBVRt6IMRlrzFRly6Bw3Ar2s2hgCDaiZf13BFA4gxEG6rbui6YzXsSShDiON+AxRgQW WwLSLp33bEgEBG8AaVRAQSxKLs5EoB/69goSfsKDH8oh8z/5Bgf8DQMMSDI4aJapwovsuZTFASo5 cCQ1K0cOWCsKrreHO2lJIJQ4NmbGpcWbDHaesZnVGLEV3BOIXueJnVFV22Ib733rk8F7Cu8wwmmG oCfUWJQAhU4tEWwBXA4MC5vD3IpSRb3Yslbrule+DOkcoqCoFJUiThh0aLlNF4WJ/BrEZ2hNqChc hBGvoR7P/9oACAECAwE/EDBYVAY/ZWCBgAlMVfKLRtBHjuAOuz1o8eYKonEgMVfdcDmEM2vIUAGr vrIugFAOCVBTdL5MAaCuXBJA14a8wqnCIhyBKN9CDUABNE5Q4Hv9XC4PJQ6GEXyoIJAEwArlCGF0 NKni3/fEcDNIby8D+VDlOAo4L26wvYDeoWZKdP7Sifp/HmbwvmDsvgD4QTOyvvKFzy5CUhkJ6RAI RGwSkMAunKeQRYm2KZDGA4ViX2woXR34cJLmAvr6g46YGlkvug1M4GE8mcgHzLAx2DyUBQlZZAW+ JK+4CTlT4IOh5PhZzEcKSL5GFnsaUKABoIpUgJur91AGW8QvhgA+VnMoKnmeRKixZMjzc8kmiNfQ V4Nzpv5n1ftbH//aAAgBAwMBPxBZQhQKmYSZANQkCAtjx4QgADmCxCwTIK2BCx8xqZUHAawKhGgG oagrY91kxnDiMv8AUsimbLmIxrgt3YlDcVtgtCd39p7U4UzaUyNUVk/M2kxr6H//2Q== ------=_NextPart_000_0014_01BFF17B.DDA4CDE0 Content-Type: image/gif; name="logo2.gif" Content-Transfer-Encoding: base64 Content-ID: <000e01bff16b$1a0393e0$fe00a8c0@cultureta> R0lGODlhRAA4AOZ/AGlhp9fV6EtCoUY/j0tEmU9Jk1hSnWhjmXhzrpOPuklDlkZBjU5ImVROolJN nlZRpVVRmbWz0cbF3lRTleXl8E9Sl0xSiVNchVlkgl+DdVmMXFqcO+r15VWkKZjAg1O9ElasIlqy Jlu0J2O9LF21KlqjLeXx3ly8HFOtGlGkGlqyHmG/IVKlHVu1IGG+JV+6JFGhH2G6JV21JVqrI2K2 Kl2sKmnBMGq7NpnOdtXqx1e2FVq0GE+gF1anHV60IGXAI2K5Il6xImW+J2W5JmO1Jl+yJlehI4DD To2+a8DiqLnWpcnktt/v1FS7AEacAFSxC0yeC1m2Dl3AEFu5ElSpE02ZElKkFEmPEmXCHFOgGGO9 HV2tG1mmG2a9IlahHWa5IlyiI2q9KmKtJ2inNXa5QK7UkUmeAkyjA1q7Bl6+CVGlClSpDVGeDl21 ElqtFWS0HFegGVWYG2q4J1atAEmWAF21B1qrDWO6E2KzFFmjFGi8G2GqHnC4KlGiAFikDP///yH5 BAEAAH8ALAAAAABEADgAAAf/gH+Cg4SFhoeIiYqLjI2Oj5CRiSZKYzNWUGdmm2ZOTmY8cGBjSDmS p4g5Q1RnZ2tUPUZgYFy1XF5eMCw8UFB0Zn5IHKinHGN9e7QztTMzRs/Qz6Jg0TA8V2PEkEp5a27N 4M20tuTUXlk8WVm4a05VS9qMZH0qM1vgIChUapqbnv59zKixkoIFixReWLCqwiReojJ+2tSoAWLL Fj9+8owpY6oQBxNLPGzwUoUNLmgwssRxiEjNxC1iQOhQM6YhJA9VzqSIA4cLnCoeWBYiQ0VMkHsq /ChBxWEDj2dVjFCBI5RQHx8Wg8zwA08bFDgdYJRIQaejUCVzSGzxUcRNtnhK/+LAsAIDBtCqf4pM ARGkrx8TLOOksGKlgxUweJ8UCUFkRhA/Qsesy+UFSlUTT4LQKDKjDRmhZdjksZOHi5OqSJ68CQKC yJyuDpVomL0hjpOlkAIkaKBAAiEyLfC00NxHkoQICSY4KKBAwQAHDaJPuIAhQSPdAJozgGBAwYQI gsSEkBOCho85iyggR0BAOwMG0KM/4G4AAoQK+CEg8L0oe4MHBkwwgQEPMFBABkSQ8IYMWL1RSADr MUeAAxT+94B8BtQ3AQTRNZBhfdw9oEAB1ilCwQELRGdABRc6kMEPNODxAhA+zIABBAwsMAB8FdoH wYYGNOAABMwtsIAC8NnnnP8CDlwoIIENLFBiIhQgIAABEDzwgAMaSEHCFwwOUcMF8QH444YdNkDA AAogkEAEASQiAXv/BRiiAwqAt8icCwjAQAZptHDHCz4MMYYFWm4pJAPtKQDAmxRIkgAB8znAAJJu RnpdBB6c8AMeI/hARAkWDMCmA27CydKJJPJ3Sg5PfEkDDTuIoSleuC4RxYxAEKEDDrgG+4euvA7x q7C4JjFFDF8AYSywyFalLLPOHhutUNMC4ewU0F7r0BLLNjsEt96yBC61z5b7bbjVdqsuU0248IMP YZxww7vxxNuFs/biq028QwhBxAth4MrBMILY5BAaLgQ8RMN4eQDFJmf0cQX/wvHc4YIcQowgxA54 4UBFECrUMIMZGGsTxgp8uDCCC1HghcQaW3yzxRkpE3PECXys4AIQdSjsEBkoUGTyGULhwLPPP6QB m0NiuCHGPW6wIZQJaHThcxdC3CtUCzuA801VUWAhxA9CrOCgUGyoEHUNW7zF0hBYjID2D20kwVIO dsD0Rg1WlFEVDlKMoMcKI3ThA0tjtBFEDUepgRcHdQixsgs2TPGZNkz4sYMPIYRgh9xC8YGFDWFo 8cMKH9wAGCp7+ECCCiK04EfODjGxwwlhrG6DEFjcQYZZjTBxBBUqxCCCDz70gISwNkihxxArCCGE FlicUEcUcpBRRhJL5MDEufg5LFHGEXzsscYOO9C6QxFriBEtGXWYfUMYQ3Txw+onnDDFFFFAQx0G WIcntOFzMiACDUhQhBZMgSbeKkMd0rCCFaBNCAHrQheGwEEN9ooIHKSRD2IQgxBoTynqYsIN2jAF 1e3PejGAobaAQEItAIEGIxgBENpQBy48z18cwMENVNCGO9xBD9ProAa/8IUhvOEOdZhDHm7gLn8N ggllIMMNRtC/Kejgi/8bAQ28JzQrmvGMaEwjIgIBADs= ------=_NextPart_000_0014_01BFF17B.DDA4CDE0 Content-Type: image/gif; name="transparent.gif" Content-Transfer-Encoding: base64 Content-ID: <000f01bff16b$1a0393e0$fe00a8c0@cultureta> R0lGODlhAQABAPAAAAAAAP///yH5BAEAAAEALAAAAAABAAEAAAICTAEAOw== ------=_NextPart_000_0014_01BFF17B.DDA4CDE0 Content-Type: image/jpeg; name="JuanCarlos4.jpg" Content-Transfer-Encoding: base64 Content-ID: <001001bff16b$1a0393e0$fe00a8c0@cultureta> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAEMAAABZkAAAhqAAAMWf/bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAM DAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/8IAEQgAYACWAwERAAIR AQMRAf/EAMIAAQACAwEBAAAAAAAAAAAAAAABAgMEBQYHAQEBAQEBAAAAAAAAAAAAAAAAAQIDBBAA AgEDAwQBBQEAAAAAAAAAAAERAgMEIDESEDATBUBQYCEUBkIRAAEDAgMFBgUFAAAAAAAAAAEAEQIx AyAhElFxIhMEEDBBYYEyQJHB0SPxQmJyQxIBAQEAAAAAAAAAAAAAAAAAcGAhEwEAAgECBAYCAgMB AAAAAAABABEhMUEQMFFhIHGhscHxgZFA8FBg4dH/2gAMAwEAAhEDEQAAAflsRQQAAAAAABJBUUiS y2iV2c6ymnqY7moIQQCwqsKRJlmtnO9nPTZzqjWK50989bXKErZAJJBUAk7nL0+hxv1VmW543Hvy 8deL25cbv5Ne4x2QgFhVYAzTfdx08704ZD006fZDPnXgeHq8Jvny+vDBrlUAsCtIVeX0fPtzGtk6 M19JS6Snzrj6fJ+nx4Nc6oBYFQKzZ1SzLnfX5e30Xn77Uutvnod/Lx7nk9OGO5gAsKrChMQDex29 Xz7c/O+dqau+ODXPFrFUAFhVRCkKRddnO6mOyiLIKoALCqwAAJABAAABYFaQAAAAAAJBJJAFIAAA AAAEn//aAAgBAQABBQJtzLJZLJZLJZLJZLJZLJZLJZLJZLJY99CRxOIsaUsRVU1W4cEa3voRQqWJ WSm1UqVS6qrlu4OiOw99GPj+S16zCsXKqPRWWrv89julemuGVg27NF27FLdUaUPfrbSdWbjWreAe S4fz1+texwc/DzDOpXhpwcL2uPXaVp/5ehD36073MhZeH+jcmv1dVJh+uyce/brzMZ3/AOgqs3H7 l0W89eTLHoQ9+qaVPJlN6uksZMt49yl/tZFGPT7Lwr2HtLWVVZz71q43pQ99WJcdF3F9zl2l+0y7 d5HI/A9KHvqpcNVskkknUh7656T2EPf4KGnMMhkMhkMhkMhkMhkMhkMhkMhkMSZ//9oACAECAAEF AvlyT9CfSDiMkXdXV9GNR3uRyOaJg5Ei7sDXSSkgjvPpAl9q/wD/2gAIAQMAAQUC+VBBBHw4I7qH +DkKslHEfcRX1pGUHIjubnjPExW2bnjOA+5Iqim4chUlYjl3qH05FVRPwJ+xP//aAAgBAgIGPwJk /9oACAEDAgY/ApfQ3//aAAgBAQEGPwIqvZXBVV7KquCqqqoo9w6Jicwm7g481VPrAjsdZIuMwsxj KOHhMeZ4iWWXquX1GkAZna/luXOEBF/85gfIfRE2oDMFoHdkvz2owAH7c1LLRMZt4MmMANVfLYU5 LvXEUcAVuUJa5cwxlL0f69nuPzUfz8rhlnIahuZSFvO7D3gx0nexR4DI7IiLsP7KU+khOzc8OYzF v1Vy3N+ZE6SN2Io4en6OMI2pQmTqdhxbURqiDEsUGvW5vsf7K31AnZlKHEbZl6MUb46GD3G5ty3c csN4QhPo5uf5RXB0ZGTtrtxGfqiXMpybU48fH5YijiqhwIvDXEjKUXbfRcutsnVMPnkFzbnT8zzM s9ygbHTcmY95ep+yMx7iDE7j4YijjdStRmeXOsNj7EYmX46+u/uSj3Ne5PwZR+CKKoqKioqdlFRU VFRU7KKnaV//2gAIAQEDAT8h186zvp32d9O+zvs77O6nfTvs76d9O+zvs77O+neTvoVZOnzPXeG3 hGaLmNYxO1JWjE7k3iSUlF6+E08nzNfz8BwYoP4jC7KbfEOVTfqvNErSbcoVtLyfcfaZBU/puMTw mnk+Z67wEU61mwVpjuuP2zhqkUNLxumsUcgN4oMZMxWHXLkeprd7QbSwFFLaS9X1jQOjgy2d/Kde ewt3BvY5jVkKqs29XvExHwaPJ8z13gAFq2oHSgGmKgi3aYqxmmUs+rBe6LyJ01jTij+CdRWZZSqy ggvUJMmACCWilmlQdQTsrsaecr8vC0eT5nrvAqLrUVVOdmgFm995kSAFu2MVGi8bp4Xs2MxPTibe 9BrEmrQrdgNiBj5AyZ/MfG+gTYvcwLS62jMGivPvLrE1eDR5Pmeu8DS9XSd2PXl2lMyvDn1ZZ7QZ AmqdkDzeMHKisBhDaAeRa0TGis0ms1uUytyulIuXkDp0JR4dHk+Z67wLxACvzMshiZ6ltoXO1cKL poWyGZXr9QBtFVu/iaPJ8z13jzMHdMzv8ow8B8OjyfM1/PxjLS+S0eT5nrv4WjyfM006zvp3076d 9O+nbZ3076d9O+nfTvp22d9O+nbZ22UsHT5n/9oACAECAwE/If5Ny+PfPZnhcGXzVmawcVLEHBzG a+KhDLGJby2acFI0Ro4XnTwKRthgNI89OJTXDRK/gV/on//aAAgBAwMBPyH+TXhaucTEqBGHmhiK kQYgbwQlNpp5htgrHHVUxizMzRURNuURIG8AbKHXC90/TmlJZtCN2pcL0idOeoY0wm0hzw8F8Ll/ 6B//2gAMAwEAAhEDEQAAEMAkkkkkkkstMg+iDIlshpm6vFe/sktsw1VxHNthtrfgXkDtsppe0Eyg NsltOWPeA2tkNI9keFhtsgMNNbriNtkNttl19ttslNttttttklkgkkkkkllv/9oACAEBAwE/EAdS bvWfYM+6Z9wz7Jn2TPumfeM+wZ9kz7Bh/wBBn3zMXzM+6Z9gzZ9Rh/0Ge9o9E9Q9/AGIhXpAVmx2 hDQrTW50lxUVZ3uO5ci9lNS6uDlqNE3x6M6jUxrQboXKK4MxP7nZPUvfjUGTMqZs6VGSybBRiizX rFusFBygwiRumyHov1MS7cAQZo0KqEYTBi0GiSa1DRdHkYC2v1E11jwDh/Y7J6h7+AKkKUpIx2Q0 E9IAEqSWahysh164hownVRNmAWotkWjdZFga0VLdqlcBgxChtTNOxGmiOyB8Ks2tNfRUTOith3NX 0hddYQZVM1mx+kSr1M+cFccwPc/8J6h7+CuMsfneOsF3lBvLUN2OkA1J5NQpDaGE8swmJrJZnqlR oG8QWil1ChC4PRnePcJrQJiBoMb3pDh1zTwYtw0TWXg1FQfzCD9RBWsKV84C+NM9E9kp+R7+BgzI KdiIGKdeI2jRydKhesCJlKaGyzaBsLU76HKeyCy0rUSVVsXYMqhwaiFouxhzvC78WlAEwdDesUTl JQTYHXYNZYsF5DdsLA9C4AOurB7kravB6J7J6h7+DMqqqdf/ACLdHlDoQCldOkMwXahS7sAbAdiK ln4oSdxOt3rKe52oUtaoF0y65ioW7OKgFsCbPJhPjXAz0NBRjG8c2UcGArQBTR0lCjDm4tt9eG/D +h2T1D38CNdtOLP2CwwFO/XpGJCLAy3bLztG03mbyrrgvYOYTpxeC5xFxt3V7RgNU1Ph9E9k9Q9/ G4CWihaMYjSXJw/Evz+2fliFivPh9E9k9S9/HRkmBNpYyOYpKeN8NuHlP6nZPUPflX4cT8S8S39m ydyTZ6z6Bn1DPoGfQM+gZ9Uza9Bn0DPoGfQM+gZ9Axq+Jn1DKMegzJ8TKD4mfokp6J//2gAIAQID AT8Q/kLxGkaQvLly+Ykiwt4qNCHC+nNpy0g2c0RBc1I7S86y9TLHDLNOByXREtuFygvpM9SWBR7S gzV2g1M3hydEMriTbhaxvM46dZXfEJE0Zga3GHJS2UQWV7xK/wCR7Jr2ljQv5hXe0SmIHNuhCgzR 3l6MGIc14KlSpXPrhX+P/9oACAEDAwE/EP5AcY4bVjFROUQhHWVTECb1LdGNrBNYkeX+bCHFs0Ye Z/f3EFA11hAKuCF1mORrEdViYjySAZg8Rugu9tIF0OPPSU5IB1v2NZqugsKTpjeC7yoeS6bi53UO 1ILehMHNIZhT00zBJY2f3vNBU/iM0DydJeI8kQIqPaxtEZErXvAEOk6lwVIh7ntHmp6S5qZiy+Tf F5txTMobvBMVKYt5jzamC4FjwF518L/x/wD/2Q== ------=_NextPart_000_0014_01BFF17B.DDA4CDE0 Content-Type: image/jpeg; name="javierbaron3.jpg" Content-Transfer-Encoding: base64 Content-ID: <001101bff16b$1a0393e0$fe00a8c0@cultureta> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAPGAAAHEgAADV7/2wCEABALCwsMCxAMDBAXDw0PFxsUEBAUGx8XFxcXFx8eFxoaGhoX Hh4jJSclIx4vLzMzLy9AQEBAQEBAQEBAQEBAQEABEQ8PERMRFRISFRQRFBEUGhQWFhQaJhoaHBoa JjAjHh4eHiMwKy4nJycuKzU1MDA1NUBAP0BAQEBAQEBAQEBAQP/CABEIAIoAjAMBIgACEQEDEQH/ xACwAAABBQEBAAAAAAAAAAAAAAAFAQIDBAYHAAEAAwEBAAAAAAAAAAAAAAAAAAECAwQQAAEDAwQC AAUFAQAAAAAAAAECAwQAEQUQIRIGMRMgQSIjFDJDNBU1QhEAAQMCBAMGAwcCBwAAAAAAAQARAiED MUESBFFhIiBxgTJCExCRwaGx0VJyMxSCBeFiI0NTcyQSAAEEAgICAwAAAAAAAAAAABEAEAEhIDAx QVFhwRIi/9oADAMBAAIRAxEAAADUKoLm6xIBse+NhKzamb1C8ETS802IPUh811G1zroeN+RyS2o5 ELlNbhtozsvo98ZbZc8tAdorTVVmzNTrB5UEJ6hzPfwFkVMrTyoingd7zzoyZXtV9M+iFM5pTStQ IZVO+lQiUC9drJNM1CeVGPJ7Nr5PALxHSebbZVW26uud7oPOt2VHSMxDxxphRXez2lCqqqjpJewU SUwHK1Q8A0Hqnl0e2D75gtiJtN7SL09AoUczc6FBVuJyJc70shoucConXZmo+8+wq1efdadzwACw wNvGzlwettOzxqJOrNMrYVtwLNZ+rNDfO57XtdcfE7j6ZFY4PRSUGgoekM6MepQUThQyuQDgKhKj R59vlrKR7HM6s6J3J1SujyRN/Cxe6MFVvrkt0fk+wm9WNI11QzNbLnt5DnxyAr4Zg6g6N3J1Dee6 PP7Yxq/2ubHOUI52KG3Pcq6BUy8z6BgkRPVyqGZkgf/aAAgBAgABBQAC5CQKFGr0QFUoWOiBvV6O nG1OW1a8aW0uKVq0dT5vcqTRFwRY0CQUrBF99jRA0O1evkfWnjolQOhre1qHwAG6AbaeTqlJUUoC dCDexNAWGrVraijr/9oACAEDAAEFACaKr0TQua4mgSmvOqvFBIoAaE3pF9XNAavV6IJ+BY0T4+QT YA1fW169e4TavFA7fO1Fy1czfQkigRQNA1cWPnU0pQuDcWrwNVEJClFWiTtyAoq5HV29/gTr/9oA CAEBAAEFAB5UoIRk+xOPLU8nmHvrcdX6xOLhU4hY96qLhNNuvIVhOzvQUY6e1Pj6WNGrbWrt0xxm AFAIe58WbcVuEtBtZMTEyXicMptx3CIdScK801+QtKsJk5cWSlXJNGjVqtXdSh1ftKittpxphi4i 9ffkqi4FiOkR0Ci0KtTgQKy0JDiYsksu4+Y3Oh/DnUFeYaaCGmk2dxON4sxYvFpbIs4ACqxpSfpn iTIcRjHEplQ1RnesvtvYn4MxM/Cx65fIy0l5UAlMrFxkyIobFnmtnkBNcm1KU6lAlKtIyMPJCOxE L0Tqv2mfgzZZ/rJTS2VtrvFcSAvrOTStBFxPkJjMSn5U5bb8FmocdmdWTxq2pC5cl4RW/W3iADK1 +XZopk4ePxkVKR6y2ogQHvw50KR+THzKVSHW4Dso5XDSY0/A7LksIfbej+lwKFmJRjvpWlYvp8nG 0utvBKJMlv2pKSkKUn14RxK2pjG7UYRo0qMt13GpYiNhfuVlXEIRGdUtHP2VgpftZ80Dar7k2rPd eYmBL62TzdfDIcSeryzwKEOJLIFSWLqkOqC3Jb7zcv2yS+puK3BKyvrqz/ZOutMozfdDy/Pm+yrA 1nestTKhR1xzkYV3cWl2MtlR43FTlBKVOD8ht1spkqN5aW1paH0Tp8iKp15x0irnhehV6yGP/LEa cw8qPjI0ZSbIoG4kkEz4KkVjcXCDUmKjiqGq5QG05JfOXQq3271fXs2COUYZzXYsRHg9ynCTGnNv syl8qCUvtsI9Ic41kJDaBMnWbmfyB5Aq3277ir1eiafYYkt5nqUVLWCzbePkLYXxJcRS3XaekOBM 6W444mKW0Or5uJpAvVvovQNA0DRrK5mFiWcx2Cdl3E/q6flTKhuxyovRhU6PZMaChtObe9cZXgbJ b3H/ADegqgavWd7fGgiTKkS3gBYHfCTXIc+M+2+2tNxIZC1ej3HtbqBIV5NuLR224BVBVA12vsaw oDS1b0km3W8k4oh9laXUpXS+KRnJRk5JXkbhvY/thVA79jzH9ZBUSTVqtVr0m4LEl+K9hO1RpwIS U5SSiDAcOy/1J8J2Vf7Y8iu4/wClXy0Gh8Hxgv4Hbv8AGcpX6kePn+3/AP/aAAgBAgIGPwAbiol5 0zGkwuciQvqxXvTSucwvljlXPej/2gAIAQMCBj8Axg96QFMS8I4VWEPS8oTrHKL3w/hpwtflzgZV sJVr1hfGj//aAAgBAQEGPwBGci0YgkngBirsNrLzUN/hBvJD6lajKX3IS1ExIJ+SjdnIkP1VRAMY RjgC+HgiNVcquEzk8iViYkKM4SIkBSYLEMjZnH3YE6qlpOcaobi1QSd45x7+3/HtyEfdD3OJg4jp He6GLekAVT6TXFwEzkYo2pYjAjApgHJQMgYw4nFRlA6x6gV0/wCmeaJ1CV0eSlPF0bdyIhMFjTND 2r2l2JtGsbgzi3FsEJM2oAsefas2YnrhAmXdIo6Ax48IjJa4kcDGrgosDM8l7koiEXaqcxEjxWGC dtI4rpDDiU8j4lfyLTGUfM2YVu7CsrchIeCs7u2CI3Y6mOIOY7W4hE6wRi7+lSMgBJ2BOTIxjJnX uXYtngoRIZg/iao1oqfPJOaozOSMIS0xKBjfOrOlChMxe3M5YPwVoQL6HiR+Xl2b18ECYi1t6PIq W4d5yqeLrXANExEgMtRxTSYd6hOctTMTEUBPNAGjZrUz5RinkXByRES4CMHcGgWiJYGp7lG9aGmL jVbjWeg58lKxeqZYSOLjAq7trg0XrZeXAg4Hs343jEa46YaywM8m5ppnVJgTTDkpRmA4k8eIBXuR DSiRqUbBNR8NcsTgOaYH27MTW4SzngEBcvAyFF0Sozhe9EHAAgcs0LZEjHgKfNdePAZK7Mmvtwi3 6Sa/b2bwh57TXId4P4IWbw03Ims3qe9G34OE8w5majkAyaEjpYSie/JRnhI4hW7DtCIeSELAoXY+ mEQWMj9E8Z+5tiXEiwbj0lkTapEY966vOzgolqYkfCFwYRLS5xOKE4l4yDg8j2J2pjpmDE+NFc2s jpnbuSBlmwUTAPKMepuSM5UEWAUJt12yxIzBqoEeWcfuRmKkhkBrMS3VpkQScWp3o9JETmSa/NaW BB80jmUQ2mAxOSuSFdOBRnI6S9ER6o4qe3ljarH9J/xTKmC0+pn05txb4Xd5ahIboh+j1kcR3IW5 ONLgxaviiBAtqfxyVyMx1FiHUbcwzYKhRo6NKqNqNCT9yEZyELUQAYQoZnmeCO3l02idQjEN8zii 5cxqwq2SjO506gXHJlcjkbc/sIRuXZxtwjWUpkRA73Utt/aDQUluyHflbB+9fyffue8/n1HV8/h3 Ke72I9vd4yj6bn4FAX7ei5YIjuLbVY4THEEKd21Aws3K2iRjHirRYmEqxkM+IPMISBxT5IkZqc8d NPEoPLVI4QGKIlKMDEsLcOot+rBNGOmDuInEnjIqnpzQG2vTszk4lKBY6cw6Mrk5TJqTORkT3uu9 f1fTsRuWp+zurT+3dZ6HGMhmCj/a9/CFjdQNLM6QlzszOD/lKkIA6bjGUCXALZBachh8DGXgpMei 4XKE4w0nkc00APFPKrZo8WUvy5Jvg2er6dkXNsIjdwZiaagMnQ2m6tCWilud8EnT/lmDVaN/GE9u c7Y0yjzHEKN2zMTtTDwkMCE4qclomO5G0DRdR8CmiWAzWgfuTFBm3NNiQA/3/H+r6do2r9sXIH0y CnutncjZMayhdkIwb9S/ibhv4UyxY6tE/wA8TwWq1LXCVQeXei8GK+qc5c1ogXk+Eao3bpqayJ+a lc/MfsyRPh8PF/s7XubiTzl+3Zj5593LmiLsvb2wLw28T0jv4pzmv4V7z7bohICmgAaHPHH5J414 hHGJVXLrXIdWPcmFPdOkfpFSfHscn+nZO32Eo7jd1EpYwtnnxKluNxM3Ls6ylL4OoShX3Ro0vpBl 6H8ShKJf8cwUxTywFWRHlsx88uJ/KFZ20A0bcNRHOZz8Agj3Ihcn7Ev7ZsZs1Nzeiav/AMcT9/ZB FCM+YR9qBnbDC7ZidU4sANYGJBKcTAPA0PyRxAQo0cIQGJK3F4gebSGwaPSh3BHgyxXj8T7Z/wDV feFoZgeqfgnJcmpJxJz7LZFRvbeZt3oVjMIbffSFjc4Rl6J+ORXT1P6jgtxuj1XIQLHgT0hvmqly cTx4o/F+f0WXwtf9Q83lxPl+q9K9K9CPkQ8q9C9KHl8MVD93D/cUsP3beGGPq5IeXxR8iHlXoXox +i//2Q== ------=_NextPart_000_0014_01BFF17B.DDA4CDE0 Content-Type: image/jpeg; name="flamenc2.jpg" Content-Transfer-Encoding: base64 Content-ID: <001201bff16b$1a0393e0$fe00a8c0@cultureta> /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAE7gAAB2MAAAr6AAAPb//bAIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAM DAwMDAwQDA4PEA8ODBMTFBQTExwbGxscHx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f/8IAEQgAdgBxAwERAAIR AQMRAf/EAM4AAAEFAQEBAAAAAAAAAAAAAAACAwQFBwYBCAEBAQEBAQEAAAAAAAAAAAAAAAECAwQF EAABAwMCBAUFAQAAAAAAAAABAgMEABEFEBIgMCEGQDEiExRQYCM0FSQRAAEDAQQGCAMIAwAAAAAA AAEAEQIDITFBEhBRYTITBCAwcYGRsSJywUKCoVKSssIjgxTxYjMSAQEBAAAAAAAAAAAAAAAAAHBg ERMBAAICAQIFAwQDAAAAAAAAAQARITFBUWEQIDBxgUDwkWChscHR4fH/2gAMAwEAAhEDEQAAAdUA yoysCWfTwAJEiz0AADKzLAJR9OiDwjgSBwAACgOTEHJm3kUcAdHh4APDiCuEHUnEmmjo6KEDQ+eg MHCnYCSnOfNDPBZEJg2OjgAZ2cQWxdkc6jHobHbhkfW9vLyyYAGOHHHWHpOl7udYTKFam1TV308s wfFkY+byEdSdiVBopDFEadImevU78049FlMYCNl0WZFNHI5LHicXR6AHClYcvnpQKMyF2u5VcrHB 0mjwAA3LmhnSqmnE3CxVy4Ojg4SBYABmhmggmGhFLnpbpe6xDlpOX0J3Tx6VrkABmhmw2XxOKHl6 J7LXXjcy13n+xO9HyNquQAM1M2Akm+FfNPM+V6Iz0lXNjcgAZsZuBIPokAAAAAP/2gAIAQEAAQUC 0751ifta7q3Vfi741i/tVvFbhRUNE8WVxkGbX8PAXkduYsJXAZZkuLoFRraatehQ4CQBku4UsrXl 560RitR6KYlN/nULlAFbRooaDV5O5tEZoSnEQ2wVx5LTLnrmD86vNJpbgTQkGkKvS+lIPTXNOfFe z2QVJX2s7JEnJzEDJy1FS1SH1QWZi0STOQU/OZuqekN+oNNcHeExLsnegt/2XoMfDxyakG77kL0C OkKRDDZVj2fbabYcUpalFAKa9Q0k3+PIfU651uhps0p1G1YcLrk1kj5LVfIbUpat70WKtK2k+omi b1alTkLqU1aU83tS0jcjH3FR3ip2YT86TZSZiSWy42phJQsAW4FYTI7n+1Xy7lsc4whUdaK2kUyn /SCVGwq1ACgKSvhWncO7hsRu9KVC0exk+3sIoUKFC1Dh7y0V0EFp55z+2/7rXc0u0fPOfIiypK1u 5iUiY1mVEYzNPSspwd5aL8osJhxHuOLZiqZUlfXJInSnmoD6lhlhz2+2mVozfB3jpaovpeZgxWR/ CxW6PiojLow+OuxiMcwpGLaFNwI6HODvHWP+xyf/2gAIAQIAAQUC+1L1fl20tVvAW8Pf6HfW9DlG k/Rf/9oACAEDAAEFAvtHb129NtbKCeXurdRVW+r84UV+GtRTarVto8y9A0DRPgAKI1CKX58kUvQU PI8q/AFUT4L/2gAIAQICBj8CYf/aAAgBAwIGPwKRwQ//2gAIAQEBBj8C0cn/ACfp00ffHz6zk/5P 06aPvj59ZA80JHhvlYtf/hNln+NZqcZ/iVLI+/HHbpt6bm5ZKatp5InGS/c7iuxQ98fPqiEJzDye x1xauUD70l+1MSa5kaZUPePPq4nCRUIZnjAdyESJcPXghHl7ZfOo4ScN2uv7PEZokEMLZ3eaMKkj IDLAlrOIbUTvX4YAsm/2MX2hVAH4ghmj8FEVC8wBmO3o0qNO6AeR2oAX4lRoQjEzlB833XUuaqWm VxOKp+4eaMM/o4vFyt3t4rW8jPvKiRI2RETtbH7UBKZA9XjPFVas6jDPECWsU7fB9Nuio1+Uqc5X k6IcaGa2IJjftQFPcFgZQIDtIP4qV4a8EMU9oa9wsvg+KpypkMH3na3EKNolAhpO97uW1u6fBWYJ honAalUiLnUURbuwuvNlykOEaQsbMbVPtj+cLM7AM5vZf9eIRqAbvUAL3s8FljaTdFAC84dHNGrT dzruJRqcaAGLuqHzZ82VtmK3g2Fqeci58VBjdONnejLA7vYruhb0duHauSiDcJj8qy3jyWWV2B1K BNrzFnaUYu8X9Owaur5T6/hpzQG56vBEVabHJKbdizThAQJ2rh14tYSGuudZqpjTpbx7GRpilGXK sSKwd7A6dQ5Yblr9w6PKfX8NPE5epIVBfFcy8XqcMxMlGjU+ax9ijGFtOnBgeyKEBbKFhOxcxRiX zUp+nayMSL1HMLoz8ujyv1/DTARsEpAHxUhCmAJXrN/Xi+tGpGNpsT8EWoyo0RCUrCbdAqAesY9H lfr+Gml74+fVf//aAAgBAQMBPyHyh9i6fG4jwlvNvBUqfcunxGvcY4zC/PB/EF+7h/uN/iYEHFt/ qIAFbrcYgpE8SnaD0FhTZHT5HSUNsBCrdWFrKF0gl/iYubcpdfwEqnWcGU/eYy96XCYDwACYLlxW ePtNCynk4e07H9RXxcbDQuFDmXj2hV/bWbpmhvV6RL0lOC0u8h9aGmCxAUXh/uXSTTH90XalwNd4 ljde6aIOKesDbewCu86RolTo1wRgrRQGR7heeeYUVZwWALc/EobfkWPzYYe613TL+Ym+3kUi1dwc RCGLbRGdgtw3o5qZIoeocsG841/Cca6AVvr6RcU5aB+K3rXEr6hFG5TsbWpRKi6Va2ffxCC6cdKr i3MofNwLJd6i5KJzLIiutD4Ihd/tIWFcuIxibUt3/CIqaKdAlAxTjaHZEQbZZZNYc5mSzTsINdal eFtGwQp0WATq7UWFCcpAZHehUwqrOUW7MHMsqlmUE8j4Dqmx/U6iFPzNF3cK4GWnVDwe8KhoRV5z hrB7SoNkJmUemdQGnpFuSqYA1kdYTeVR8sQwoIA2J24in2hXRAFGvIyhWm+sdIGVc/8ABHK8tpcl bpum8TIIUtNFrt1I1aosC2nvBNFaTmqW9MRxFPhWe999wPAAeAhFq6L6wBsKesxVF+Q6aEZvroY/ IEHNEDuyzJfLqe8SNJvn7PZiJeRaadxV9LbvuOa4ggggjWmPy7+DVjDALYL5XdQ+KdZvuPwgBqx+ 8xJtuCChPeoFpEV2KxXuxyXxwD2dnEplYoiKyvZd5dvBkkIDbbV9pq8dMD/yF05W6Gcd7zNvqchE L/LA1KFqsNREeSfCpAIRG5c0czvTy7z1EJSXLrkmi5ECQAwUa2dI6Q4i/wDkBalS+BgXddvmBphA rD7rNvOgvfK28f8Af+n0v//aAAgBAgMBPyH9I3iDL8D6hX0Iw+mXC0uXD1KiRIH0Cwt4vpl9zXwZ z6deSvo//9oACAEDAwE/If0gSn3ajsO/4l5aL8XHfojOvtXgtg7++Ioor7fWRTcJ+mePMeMNzsgr 0hizSoGmUNyz6Fp8CXlymnpPib+G0zrDT6QovipLPov/2gAMAwEAAhEDEQAAEJIAJAJJJJABABBJ JBAIBJJIIJBABBJJBIBBJBJIJKMtFJJBAxqlIBAIBJARBAJDKQBJICp7RJJJJmr7JIRJIBJBBipJ IBIWGnJJIAJxHpJAAJJJJJ//2gAIAQEDAT8Q8NpKlQeOiCAlL2QtPML8UDNFAtwRFq46zSZRfZA8 pXzBjzFSDmgdC3pAGxbVky8FlqAvAVLvyiHDQp+I7DfeOZax78hgmHp71Kjo+QOxbTQRp+2AdoYr Cwhj0SV+8Io1oCvb+lFQ0OiXGtJDO+S/zDKAQstLe80BUso2SwypfFhsrYPaVVagsN8HnvOAPsgK YOp7TKOcxquKhDQSK6xUGiIKbqsMm/1bof3Mjw6QanbEsrEHxkERyO57FMQW7lJDxVicHVzEqENA OyxUB2ufFWqZpVDNgtXNMLSB2UqBMyFf5JJ8NBZK6YpR75g65YjFNDpoCuglSrl2XcnQKWYQdP6S x3WmLQB3AeDBAGAgoLsy3TNvFQLcBtlMU25YD4CBW54LRgluQh2+YkDd1xCbZ2W8BfFsy2I3i2UE C6JKLVe5D5iSkP6osjo/sOk7rElGG84dpSEJXXzINm0HI1DjupgqLeIvZUUkMh2o5hGjUzGejBTp EYS53Jxtu9VYiJEzsDgh1Gos0LculEQjKjdVr8Q/yCmCYAqDcVhCFVDeiFTTGTPArdEL14rszVEZ LeIBXQ3LGpTiDpUC6q0TJoaM3cd2mU6tQuYNG4hIsF7zbSLYrXEqMtF4qjvKRqBQs7RV/EUn+GCm ot2n9dRTl5Cz6Z1glaCs3MY3UIZUlinssQWrjoKyCUn4nWiiKRYddBLsxRb6b3CCFbqyCx2pTByg S3RNnFQ+dDyG14fCoBjemCszBNPLeErYJcwxsFKEPIRpCNF14KiRAqK3q0gD7wcp2vS6JStuAvRu o9C34jpUAdqAA+4ENpS6ydmGZJ7AC+7uVwJsAMuKZOYBLPIhXUFAGw7MXAKrI0DrrUKYQPtyewww 73AGcltOehBJ0gFoJ9lLD8iUu9YWnI5rHlVUMCnRiBXlMGpUOwi3tvKCcy9osT0EobC8SyC1oC62 Ax7QqvFnZS/ZFw07iGEdWiqA0DEC9nREzYJ15d/tLqFNsDK715TcGpY3r3rEH+5MUNiKU+IAHJks aXkh8TZcMaaA8oAdkGKtVQIGaWTCEd6hAa0LGQDuVlSAzmu0O2coJag35RfgrHkeGUu26W4Z5GMQ s0IuLXxEAFt0FPsP8Ijo9QraA7zKqQ28mw1UUe0YQRwQ3AKQ+xKCF9dDkpvy1i4mJT0g/wD/2gAI AQIDAT8Q/SDLZTLTAykwQ16KTSvCUYmtwBtv7PWDZUQ+mOXELSZahXcS59JIGJtcS7JYVKPoFGiF 4GKNS1Z9IDCDZ34aRxA49JLArxSwK+i//9oACAEDAwE/EP0gi8xDBt/y/iG8jLvSNgdj98zDfa/i OS+g/wB/tGKrXokcQzwz/ov8RVfFfH++YpRNtwlqHX44QgOC+3/HrHC1v3UDasbx7UHxX0oXKGlv ZNokcVt8EbLyOOYSrk36VDFVTmGxr+I44eHp/pgpy494Tuqef8+WvTBLdRt/A2hCsagCND0jS/MW po8FQiKDmKg+kDURbfIS7/Rf/9k= ------=_NextPart_000_0014_01BFF17B.DDA4CDE0 Content-Type: image/gif; name="transparent.gif" Content-Transfer-Encoding: base64 Content-ID: <001301bff16b$1a0393e0$fe00a8c0@cultureta> R0lGODlhAQABAPAAAAAAAP///yH5BAEAAAEALAAAAAABAAEAAAICTAEAOw== ------=_NextPart_000_0014_01BFF17B.DDA4CDE0-- From rem-conf Wed Jul 19 03:53:10 2000 From rem-conf-request@es.net Wed Jul 19 03:53:07 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Er8e-0006uB-00; Wed, 19 Jul 2000 03:31:40 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Er8d-0006u1-00; Wed, 19 Jul 2000 03:31:39 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19415; Wed, 19 Jul 2000 06:31:37 -0400 (EDT) Message-Id: <200007191031.GAA19415@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-crtp-enhance-00.txt Date: Wed, 19 Jul 2000 06:31:37 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 : Enhancements to IP/UDP/RTP Header Compression Author(s) : T. Koren, S. Casner, J. Geevarghese, B. Thompson, D. Wing, P. Ruddy, A. Tweedly Filename : draft-ietf-avt-crtp-enhance-00.txt Pages : Date : 18-Jul-00 This document describes enhancements to CRTP, the header compression algorithm for RTP streams described in [RFC2508]. Each enhancement addresses issues with RFC2508 in different deployment scenarios. Each section below provides a description of the proposed enhancement, the scenario where it is useful and the justification for its use. Each of these enhancements could be evaluated separately. The enhancements are applicable both for IPv4 and IPv6. The IPCP option 'IP header compression' (described in RFC2509) is also extended to negotiate using the CRTP enhancements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-crtp-enhance-00.txt 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-crtp-enhance-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-ietf-avt-crtp-enhance-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: <20000718135033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-crtp-enhance-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-crtp-enhance-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000718135033.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Jul 19 09:07:46 2000 From rem-conf-request@es.net Wed Jul 19 09:07:45 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EwGl-0005jk-00; Wed, 19 Jul 2000 09:00:23 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EwGb-0005jC-00; Wed, 19 Jul 2000 09:00:22 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id JAA08252 for ; Wed, 19 Jul 2000 09:00:04 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 19 Jul 2000 09:00:00 -0700 Received: from [17.202.37.134] (il0203a-dhcp06.apple.com [17.202.37.134]) by scv2.apple.com (8.9.3/8.9.3) with ESMTP id IAA28915; Wed, 19 Jul 2000 08:59:59 -0700 (PDT) Mime-Version: 1.0 X-Sender: singer@mail.apple.com Message-Id: X-Priority: 1 (Highest) Date: Wed, 19 Jul 2000 08:57:53 -0700 To: rem-conf@es.net From: Dave Singer Subject: I-D: draft-singer-mpeg4-ip-00.txt Cc: "'olivier.avaro@francetelecom.fr'" , Franceschini Guido Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is the MPEG-4 'FrameWork" document that's being discussed jointly with ISO; I haven't seen it announced on rem-conf. I think (hope) it will be discussed in Pittsburgh. Here's the abstract: This document forms an umbrella specification for the carriage and operation of MPEG-4 multimedia sessions over IP-based protocols, including RTP, RTSP, and HTTP, among others. It also serves to document the standard MIME types associated with MPEG-4. There's also a parallel document for the MIME types for motion jpeg 2000; it is as yet unclear to me which group might carry this to get the mime types assigned. -- David Singer Apple Computer/QuickTime From rem-conf Wed Jul 19 11:43:17 2000 From rem-conf-request@es.net Wed Jul 19 11:43:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Eyks-0000cI-00; Wed, 19 Jul 2000 11:39:38 -0700 Received: from relay.eecs.berkeley.edu [169.229.34.228] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Eykr-0000c6-00; Wed, 19 Jul 2000 11:39:37 -0700 Received: from huginn.CS.Berkeley.EDU (huginn.CS.Berkeley.EDU [169.229.60.60]) by relay.EECS.Berkeley.EDU (8.9.3/8.9.3) with ESMTP id LAA21399 for ; Wed, 19 Jul 2000 11:39:36 -0700 (PDT) Received: from fielder (dhcp5b90.CS.Berkeley.EDU [169.229.63.144]) by huginn.CS.Berkeley.EDU (8.9.1a/8.9.1) with SMTP id LAA28096 for ; Wed, 19 Jul 2000 11:40:29 -0700 (PDT) Date: Wed, 19 Jul 2000 11:43:21 -0700 From: Koichi Yano To: rem-conf@es.net Subject: RTCP Retransmission request Reply-To: yano@EECS.Berkeley.EDU Message-Id: <3975F6C9AA.64DCYANO@pop.cs.berkeley.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="V2VkLCAxOSBKdWwgMjAwMCAxMTo0MzoyMSAtMDcwMA==" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.25.06 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --V2VkLCAxOSBKdWwgMjAwMCAxMTo0MzoyMSAtMDcwMA== Content-Transfer-Encoding: 7bit Content-Type: text/plain Hi there, I submitted the revision of RTCP retransmission request profile on Jul 14 (definitely before 5pm E.T). However, for some reasons, the submission has not been processed yet. So I attach the draft. It is also available from: http://www.cs.berkeley.edu/~yano/pubs/draft-ietf-avt-rtprx-00.txt Please look into and give us comments. Any feedback is welcome. Sorry for inconvenience that the draft might not be available from the IETF web site for a while. Thank you in advance for your comments. Koichi --V2VkLCAxOSBKdWwgMjAwMCAxMTo0MzoyMSAtMDcwMA== Content-Type: application/octet-stream; name="draft-ietf-avt-rtprx-00.txt" Content-Disposition: attachment; filename="draft-ietf-avt-rtprx-00.txt" Content-Transfer-Encoding: base64 SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQVZUIFdHCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBLb2ljaGkgWWFubwpkcmFmdC1pZXRmLWF2dC1ydHByeC0wMC50 eHQgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hdHRoZXcgUG9kb2xza3kKSnVseSAxNCwg MjAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0ZXZlbiBN Y0Nhbm5lCkV4cGlyZXM6ICBKYW51YXJ5IDE0LCAyMDAxCgoKCiAgICAgICAgICAgUlRQIFByb2Zp bGUgZm9yIFJUQ1AtYmFzZWQgUmV0cmFuc21pc3Npb24gUmVxdWVzdAogICAgICAgICAgICAgICAg ICAgICAgICAgIGZvciBVbmljYXN0IHNlc3Npb24uCgoKU3RhdHVzIG9mIHRoaXMgTWVtbwoKICAg VGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3Jt YW5jZSB3aXRoCiAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4KCiAg IEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu Z2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2lu ZyBncm91cHMuICBOb3RlIHRoYXQKICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUg d29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtCiAgIERyYWZ0cy4KCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo cwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIg ZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtIERyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90 aGVyIHRoYW4gYXMgd29yayBpbiBwcm9ncmVzcy4KCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50 ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2ll dGYvMWlkLWFic3RyYWN0cy50eHQKCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRv dyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKICAgaHR0cDovL3d3dy5pZXRmLm9yZy9z aGFkb3cuaHRtbC4KCkFic3RyYWN0CgogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIG5ldyBS VFAgcHJvZmlsZSBmb3IgcmV0cmFuc21pc3Npb24gb2YgbG9zdAogICBwYWNrZXRzIG9mIHVuaWNh c3QgbXVsdGltZWRpYSBzZXNzaW9ucy4gIFdlIHJlZmVyIHRvIHRoaXMgcHJvZmlsZSBhcwogICAi UlRQL0FWUC1SWCIuICBUaGlzIHByb2ZpbGUgZm9sbG93cyBSRkMgMTg4OSBhcyBpdCBpcyBmb3Ig ZGF0YQogICBleGNoYW5nZS4gIFNwZWNpZmljYWxseSBmb3IgdW5pY2FzdCBzZXNzaW9uLCBpdCBj aGFuZ2VzIHRoZSBSVENQCiAgIGludGVydmFsIGFuZCBkZWZpbmVzIGEgbmV3IFJUQ1AgcGFja2V0 IHR5cGUgZm9yIHJldHJhbnNtaXNzaW9uCiAgIHJlcXVlc3RzLiAgVGhpcyBkb2N1bWVudCBhbHNv IGRlc2NyaWJlcyBob3cgcmV0cmFuc21pc3Npb24gcmVxdWVzdHMKICAgYW5kIHJldHJhbnNtaXNz aW9uIGRhdGEgbWF5IGJlIHNlbnQgd2l0aGluIFJUUC4KCjEuICBDb252ZW50aW9ucyBhbmQgQWNy b255bXMKCiAgIFRoZSBrZXl3b3JkcyBNVVNULCBNVVNUIE5PVCwgUkVRVUlSRUQsIFNIQUxMLCBT SEFMTCBOT1QsIFNIT1VMRCwKICAgU0hPVUxEIE5PVCwgUkVDT01NRU5ERUQsIE1BWSwgYW5kIE9Q VElPTkFMLCB3aGVuIHRoZXkgYXBwZWFyIGluIHRoaXMKICAgZG9jdW1lbnQsIGFyZSB0byBiZSBp bnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gWzJdLgoKCgpZYW5vLCBQb2RvbHNreSwgTWNDYW5u ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0KCkludGVy bmV0IERyYWZ0ICAgICAgICAgUlRDUC1iYXNlZCBSZXRyYW5zbWlzc2lvbiAgICAgICAgICAgICAg SnVseSwgMjAwMAoKCjIuIEludHJvZHVjdGlvbgoKICAgUlRQIHdhcyBkZXNpZ25lZCBhcyBhIGZs ZXhpYmxlIHByb3RvY29sIGNhcGFibGUgb2YgdHJhbnNwb3J0aW5nIHJlYWwtCiAgIHRpbWUgZGF0 YSBvdmVyIG11bHRpY2FzdCBvciB1bmljYXN0LiAgSXQgaGFzIGJlZW4gd2lkZWx5IGRlcGxveWVk IGFuZAogICB1c2VkIGV4dGVuc2l2ZWx5IGZvciB0cmFuc21pdHRpbmcgcmVhbC10aW1lIChvciAi bmVhciIgcmVhbC10aW1lKQogICBtdWx0aW1lZGlhIHNpZ25hbHMsIGNvbW1vbmx5IGNhbGxlZCBt ZWRpYSBzdHJlYW1zLiAgQW5kIGFsdGhvdWdoCiAgIGNvbnNpZGVyYWJsZSBlZmZvcnQgd2VudCBp bnRvIHRoZSBkZXNpZ24gb2YgUlRQIHNvIHRoYXQgaXQgY291bGQKICAgc3VwcG9ydCBtdWx0aS1w YXJ0eSBpbnRlcmFjdGl2ZSBjb25mZXJlbmNpbmcgb3ZlciBtdWx0aWNhc3QsIGEgY29tbW9uCiAg IHVzZSBvZiBpdCB0b2RheSBpcyBmb3Igb25lLXdheSBub24taW50ZXJhY3RpdmUgdHJhbnNtaXNz aW9uIG9mIG1lZGlhCiAgIHN0cmVhbXMuICBCZWNhdXNlIHRoZSBjb21tdW5pY2F0aW9uIGlzIG5v bi1pbnRlcmFjdGl2ZSwgZXh0cmEKICAgcGxheWJhY2sgYnVmZmVyaW5nIGFuZCBkZWxheSBtYXkg YmUgdG9sZXJhYmxlLCB3aGljaCBpbiB0dXJuIGVuYWJsZXMKICAgcmVjZWl2ZXJzIHRvIHJlcXVl c3QgYW5kIHJlY2VpdmUgcmV0cmFuc21pc3Npb25zIG9mIGxvc3QgUlRQIHBhY2tldHMKICAgYmVm b3JlIHRoZWlyIHNjaGVkdWxlZCBwbGF5LW91dCB0aW1lcy4gIEZvciBleGFtcGxlLCBwb3B1bGFy CiAgIGNvbW1lcmNpYWwgcHJvZHVjdHMgbGlrZSBSZWFsTmV0d29ya3MnIEcyIFBsYXllciBhbmQg TWljcm9zb2Z0J3MKICAgTmV0U2hvdyB1c2UgUlRQIGFzIHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9y dCBwcm90b2NvbCBmb3IgdGhlaXIgbWVkaWEKICAgc3RyZWFtcywgYW5kIHVzZSByZXRyYW5zbWlz c2lvbnMgaW4gdW5pY2FzdCBkZWxpdmVyeSBzZXNzaW9ucy4KCiAgIEhvd2V2ZXIsIGFzIG5vdGVk IGluIFs0XSwgbm8gc3RhbmRhcmQgZXhpc3RzIGZvciByZXF1ZXN0aW5nIHRoZQogICByZXRyYW5z bWlzc2lvbiBvZiBzdHJlYW1pbmcgbWVkaWEuICBBcyBhIHJlc3VsdCwgdmFyaW91cyBpbmRlcGVu ZGVudAogICBhbmQgaW5jb21wYXRpYmxlIHJlc2VhcmNoIGFuZCBjb21tZXJjaWFsIHNjaGVtZXMg aGF2ZSBiZWVuIGRldmVsb3BlZAogICBmb3IgcmV0cmFuc21pc3Npb24gb2YgUlRQIHN0cmVhbXMg WzMsIDVdLiAgVGhpcyBwdXJwb3NlIG9mIHRoaXMgbm90ZQogICBpcyB0byBkZWZpbmUgYSBzdGFu ZGFyZCByZXRyYW5zbWlzc2lvbiByZXF1ZXN0IGZyYW1ld29yayBmb3IgdXNlIHdpdGgKICAgdW5p Y2FzdCBSVFAgc3RyZWFtcy4gIEFkZGl0aW9uYWxseSwgcG90ZW50aWFsIGRlcGxveW1lbnQgb2Yg UlRDUAogICBwYWNrZXRzIGZvciBjb25nZXN0aW9uIGNvbnRyb2wgaXMgZGVzY3JpYmVkLgoKMy4g IFJUQ1AgUGFja2V0IEZvcm1zIGFuZCBQcm90b2NvbCBCZWhhdmlvcgoKICAgVGhlIHNlY3Rpb24g IlJUUCBQcm9maWxlcyBhbmQgUGF5bG9hZCBGb3JtYXQgU3BlY2lmaWNhdGlvbiIgb2YgUkZDCiAg IDE4ODkgZW51bWVyYXRlcyBhIG51bWJlciBvZiBpdGVtcyB0aGF0IGNhbiBiZSBzcGVjaWZpZWQg b3IgbW9kaWZpZWQKICAgaW4gYSBwcm9maWxlLiAgVGhpcyBuZXcgcHJvZmlsZSBpcyByZWZlcnJl ZCB0byBSVFAvQVZQLVJYIG9yIEFWUC1SWAogICBpbiB0aGlzIG5vdGUuICBUaGUgcHJvZmlsZSwg UlRQL0FWUC1SWCwgZm9sbG93cyBhbGwgb2YgdGhlIGRlZmF1bHQKICAgYW5kL29yIHJlY29tbWVu ZGVkIGFzcGVjdHMgb2YgdGhlIEF1ZGlvIGFuZCBWaWRlbyBQcm9maWxlLAogICBSVFAvQVZQWzZd LCBleGNlcHQgZm9yIHRoZSBpdGVtcyB3aGljaCBhcmUgZGVzY3JpYmVkIGJlbG93LgoKICAgUlRD UCBwYWNrZXQgdHlwZXM6CiAgICAgIEEgbmV3IFJUQ1AgcGFja2V0IHR5cGUsIFJUQ1BfTkFDSywg aXMgZGVmaW5lZCBmb3IgcmVxdWVzdGluZyBhCiAgICAgIHJldHJhbnNtaXNzaW9uLiAgVGhlIHBh Y2tldCBmb3JtYXQgaXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gNC4yLgoKICAgUlRDUCByZXBvcnQg aW50ZXJ2YWw6CiAgICAgIEluIG9yZGVyIHRvIGFsbG93IGltbWVkaWF0ZSBSVENQIHJlc3BvbnNl IHRvIHBhY2tldCBsb3NzLCB0aGUgUlRDUAogICAgICByZXBvcnQgaW50ZXJ2YWwgcmVzdHJpY3Rp b24gaW4gUkZDIDE4ODkgU0hPVUxEIGJlIHJlbGF4ZWQuCiAgICAgIEhvd2V2ZXIsIGluIG9yZGVy IHRvIHByZXZlbnQgUlRDUCBwYWNrZXRzIGZyb20gZmxvb2RpbmcgdGhlCiAgICAgIG5ldHdvcmss IHRoZSBiYW5kd2lkdGggY29uc3RyYWludCBvZiBSRkMgMTg4OSBzaG91bGQgYmUgcHJlc2VydmVk LgogICAgICBSZWNvbW1lbmRhdGlvbnMgYWJvdXQgdGhlIFJUQ1AgdHJhbnNtaXNzaW9uIGZyZXF1 ZW5jeSBhcmUKICAgICAgc3BlY2lmaWVkIGluIHNlY3Rpb24gNC4xLgoKICAgVGhpcyBwcm9maWxl IFNIT1VMRCBiZSByZWZlcnJlZCB0byBhcyAiUlRQL0FWUC1SWCIgYnkgYXBwbGljYXRpb25zCiAg IHN1Y2ggYXMgc2Vzc2lvbiBkaXJlY3Rvcmllcy4gIEEgcGF5bG9hZCB0eXBlIHdoaWNoIGlzIHRy YW5zbWl0dGVkIG9uCgoKCllhbm8sIFBvZG9sc2t5LCBNY0Nhbm5lICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQoKSW50ZXJuZXQgRHJhZnQgICAgICAgICBS VENQLWJhc2VkIFJldHJhbnNtaXNzaW9uICAgICAgICAgICAgICBKdWx5LCAyMDAwCgoKICAgIlJU UC9BVlAtUlgiIE1BWSBiZSBkZXNpZ25hdGVkIHRocm91Z2ggaGlnaCBsZXZlbCBjb250cm9sIHBy b3RvY29scwogICBzdWNoIGFzIFNEUFs4XSwgYXMgZGVzY3JpYmVkIGluIEF1ZGlvL1ZpZGVvIFBy b2ZpbGUgWzZdIG9yIGEKICAgc3VjY2VlZGluZyBkcmFmdC4gIEEgcGF5bG9hZCB0eXBlIHdoaWNo IGlzIGRlZmluZWQgZm9yIEF1ZGlvL1ZpZGVvCiAgIHByb2ZpbGUgbWF5IGJlIHVzZWQgYXMgaXQg aXMgYnkgZGVwbG95aW5nIGEgZGVmYXVsdCBOQUNLIGZvcm1hdCBzaG93bgogICBpbiBzZWN0aW9u IDQuMy4gIFRoZSBmb2xsb3dpbmcgaXMgYW4gZXhhbXBsZSBvZiBTRFAgbWVkaWEKICAgZGVzY3Jp cHRpb246CgogICBtPXZpZGVvIDQ5MTcwIFJUUC9BVlAtUlggMzEKCiAgIEluIHRoaXMgZXhhbXBs ZSwgdGhlIG1lZGlhIGZvcm1hdCAzMSBpbmRpY2F0ZXMgdGhhdCB2aWRlbyB1c2VzIEguMjYxLgog ICBUaGUgcGF5bG9hZCBmb3JtYXQgaW4gUkZDMjAzMiBbOV0gaXMgdXNlZCBmb3IgUlRQIGRhdGEg dHJhbnNtaXNzaW9uCiAgIGFuZCBOQUNLIHBhY2tldHMgYXJlIHNlbnQgd2l0aCB0aGUgcGFja2V0 IGZvcm1hdCBkZXNjcmliZWQgaW4gc2VjdGlvbgogICA0LjMuICBSVFAvQVZQLVJYIHVzZXMgdGhl IHNhbWUgUlRDUCBwb3J0IGZvciBOQUNLcyBhcyBmb3Igb3JpZ2luYWwKICAgUlRDUCBwYWNrZXRz LCBzbyBhIHNlcGFyYXRlIGNvbm5lY3Rpb24gZG9lcyBub3QgbmVlZCB0byBiZSBzcGVjaWZpZWQu CiAgIEEgbmV3IHBheWxvYWQgdHlwZSBtYXkgYmUgZGVmaW5lZCBpbiBhIHN1Y2NlZWRpbmcgZHJh ZnQgc3BlY2lmaWNhbGx5CiAgIGZvciB0aGlzIHByb2ZpbGUuICBGb3IgYW55IHN1Y2ggcGF5bG9h ZCB0eXBlLCBhIGR5bmFtaWMgcGF5bG9hZCB0eXBlCiAgIG51bWJlciBNVVNUIGJlIHVzZWQuCgog ICBUaGUgZGVjaXNpb24gb2Ygd2hldGhlciBhbmQgd2hlbiB0byBzZW5kIHJldHJhbnNtaXNzaW9u IHBhY2tldHMgaXMKICAgbGVmdCB0byBhIHNlbmRlciBhcHBsaWNhdGlvbiBhbmQgaXMgb3V0IG9m IHRoZSBzY29wZSBvZiB0aGlzCiAgIGRvY3VtZW50LiAgSWYgYSBzZW5kZXIgZGVjaWRlcyB0byBy ZXRyYW5zbWl0IHBhY2tldHMsIHRoZSBzZW5kZXIKICAgU0hPVUxEIHNlbmQgdGhlbSBhcyBzb29u IGFzIHBvc3NpYmxlIGFmdGVyIHRoZSByZWNlcHRpb24gb2YgdGhlIE5BQ0sKICAgcGFja2V0IHJl cXVlc3RpbmcgdGhlIHJldHJhbnNtaXNzaW9uLiAgSW4gYWRkaXRpb24sIHRoZSB0b3RhbAogICB0 cmFuc21pc3Npb24gcmF0ZSBTSE9VTEQgYmUgcmVndWxhdGVkIHdpdGhpbiBhIHNlc3Npb24gYmFu ZHdpZHRoCiAgIGxpbWl0IHRoYXQgaW5jbHVkZXMgdGhlIHJldHJhbnNtaXR0ZWQgcGFja2V0cy4g IFRoZSBkZXBsb3ltZW50IG9mCiAgIGNvbmdlc3Rpb24gY29udHJvbCBpcyBSRUNPTU1FTkRFRCBh cyBkZXNjcmliZWQgaW4gc2VjdGlvbiA1LgoKNC4gQ29udHJvbCBwYWNrZXRzIGZvciB1bmljYXN0 IHNlc3Npb24KCiAgIFRoaXMgbm90ZSBwcm9wb3NlcyBleHRlbmRpbmcgdGhlIFJUQ1Agc3BlY2lm aWNhdGlvbiB0byBhY2NvbW1vZGF0ZQogICByZXRyYW5zbWlzc2lvbiByZXF1ZXN0cy4gIFdlIGRl ZmluZSBhIG5ldyBSVENQIHR5cGUsIFJUQ1BfTkFDSywgZm9yCiAgIG5vdGlmeWluZyB0aGUgc2Vu ZGVyIG9mIGxvc3QgcGFja2V0cy4gIFJUQ1AgaXMgYSByZWFzb25hYmxlIHBsYWNlIGZvcgogICBp bnNlcnRpbmcgdGhlc2UgcmVxdWVzdHMgYmVjYXVzZSBpdCBpcyBhIHdlbGwtZXN0YWJsaXNoZWQg Y29udHJvbAogICBwcm90b2NvbCBhbmQgbm8gZXh0cmEgY29ubmVjdGlvbnMgbmVlZCB0byBiZSBl c3RhYmxpc2hlZC4gIEhvd2V2ZXIsCiAgIHRoZSBSVENQIGludGVydmFsIHNwZWNpZmllZCBpbiBb MV0gaXMgdG9vIGxhcmdlIGZvciB0aW1lbHkKICAgcmV0cmFuc21pc3Npb24gcmVxdWVzdHMuICBU aHVzLCB0aGUgY3VycmVudCBSVENQIG1pbmltdW0gdHJhbnNtaXNzaW9uCiAgIGludGVydmFsIHNo b3VsZCBiZSByZWxheGVkLgoKNC4xLiBSVENQIFRyYW5zbWlzc2lvbiBCYW5kd2lkdGgKCiAgIFRo ZSBSVENQIHRyYW5zbWlzc2lvbiBpbnRlcnZhbCBzcGVjaWZpZWQgaW4gWzFdIGlzIG5vdCBmcmVx dWVudAogICBlbm91Z2ggdG8gYWxsb3cgZWZmaWNpZW50IGNvbnRyb2wgb2YgYSB1bmljYXN0IHNl c3Npb24gbmVlZGluZyB0bwogICByZXF1ZXN0IHJldHJhbnNtaXNzaW9ucyBvZiBsb3N0IHBhY2tl dHMuICBSRkMgMTg4OSByZWNvbW1lbmRzIGEKICAgbWluaW11bSBpbnRlcnZhbCBvZiA1IHNlY29u ZHMgYmV0d2VlbiBjb250cm9sIHBhY2tldHMuICBJbiBvcmRlciB0bwogICBtYWtlIFJUQ1AgYXBw bGljYWJsZSBmb3IgdW5pY2FzdCByZXRyYW5zbWlzc2lvbiwgYSBwYWNrZXQtZ3JhbnVsYXJpdHkK ICAgUlRDUCBpbnRlcnZhbCBpcyBuZWNlc3NhcnkuCgogICBUaGUgbWluaW11bSBpbnRlcnZhbCBy ZXN0cmljdGlvbiBTSE9VTEQgYmUgcmVtb3ZlZCBmb3IgdW5pY2FzdCBSVFAKCgoKWWFubywgUG9k b2xza3ksIE1jQ2FubmUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDNdCgpJbnRlcm5ldCBEcmFmdCAgICAgICAgIFJUQ1AtYmFzZWQgUmV0cmFuc21pc3Npb24g ICAgICAgICAgICAgIEp1bHksIDIwMDAKCgogICBzZXNzaW9ucyBzbyB0aGF0IHJldHJhbnNtaXNz aW9uIHJlcXVlc3RzIGFyZSBhbGxvd2VkIHRvIGJlIHNlbnQKICAgaW1tZWRpYXRlbHkgYWZ0ZXIg bG9zcyBkZXRlY3Rpb24uICBJbiBvcmRlciB0byBwcmV2ZW50ICBSVENQIHBhY2tldHMKICAgZnJv bSBjYXVzaW5nIG5ldHdvcmsgY29uZ2VzdGlvbiwgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUg YXZlcmFnZQogICBiYW5kd2lkdGggYWxsb2NhdGVkIHRvIFJUQ1AgYmUgZml4ZWQgYXQgNSUgb2Yg dGhlIG92ZXJhbGwgc2Vzc2lvbgogICBiYW5kd2lkdGguICBUaGUgcmVjb21tZW5kZWQgZGVmYXVs dCBzZW5kZXItcmVjZWl2ZXIgYWxsb2NhdGlvbiB2YWx1ZXMKICAgYXJlIDEvNCBvZiB0aGUgUlRD UCBiYW5kd2lkdGggKDEuMjUlKSBmb3IgdGhlIGRhdGEgc2VuZGVyIGFuZCB0aGUKICAgcmVtYWlu ZGVyIG9mIHRoZSBiYW5kd2lkdGggKDMuNzUlKSBmb3IgdGhlIHJlY2VpdmVyLCBmb2xsb3dpbmcg dGhlCiAgIGNvbnZlbnRpb25zIG9mIFJGQyAxODg5LgoKICAgSWYgdGhlIHNpemUgb2YgUlRQIHBh eWxvYWQgcGFja2V0cyBpcyAxIEtCeXRlcyBhbmQgdGhlIHNpemUgb2YgUlRDUAogICBwYWNrZXRz IGlzIDQwIGJ5dGVzLCB0aGUgMy43NSUgbGltaXRhdGlvbiBpcyBsYXJnZSBlbm91Z2ggZm9yIGEK ICAgcmVjZWl2ZXIgdG8gc2VuZCBhbiBSVENQIHBhY2tldCBhdCBldmVyeSBvdGhlciBkYXRhIHBh Y2tldCBpbnRlcnZhbC4KICAgVGhlIGludGVydmFsIGlzIGZyZXF1ZW50IGVub3VnaCB0byBhbGxv dyB0aW1lbHkgcmV0cmFuc21pc3Npb24KICAgcmVxdWVzdHMuICBJbiB0aGUgY2FzZSBvZiBjb25z ZWN1dGl2ZSBsb3N0IHBhY2tldHMsIGEgTkFDSyBwYWNrZXQgY2FuCiAgIGFnZ3JlZ2F0ZSBsb3Nz IGluZm9ybWF0aW9uIG9mIHVwIHRvIDE2IHBhY2tldHMgd2hlbiB0aGUgZGVmYXVsdCBOQUNLCiAg IGZvcm1hdCBpcyB1c2VkLgoKICAgSW4gb3JkZXIgdG8gcmVndWxhdGUgdGhlIHNlbmRpbmcgcmF0 ZSBvZiBSVENQIHBhY2tldHMgd2l0aGluIHRoZSBSVENQCiAgIGJhbmR3aWR0aCwgdGhlIGRlcGxv eW1lbnQgb2YgYSB0cmFmZmljIHNoYXBpbmcgc2NoZW1lIHN1Y2ggYXMgYSB0b2tlbgogICBiYWNr ZXQgaXMgUkVDT01NRU5ERUQuIFRoZSB0b2tlbiByYXRlIFNIT1VMRCBiZSBzZXQgYXQgKHJ0Y3Bf YncgLwogICBydGNwX3NpemUpLCB3aGVyZSBydGNwX2J3IGlzIHRoZSBSVENQIGJhbmR3aWR0aCBh bmQgcnRjcF9zaXplIGlzIHRoZQogICBzaXplIG9mIFJUQ1AgcGFja2V0cy4gIFRoZSBidWNrZXQg c2l6ZSBTSE9VTEQgYmUgZGV0ZXJtaW5lZCBhY2NvcmRpbmcKICAgdG8gdGhlIHBsYXliYWNrIGJ1 ZmZlciBzaXplLiAgQXMgbG9uZyBhcyBhIHRva2VuIGlzIGluIHRoZSBidWNrZXQsCiAgIHRoZSBS VENQIHBhY2tldCBpcyBzZW50IGltbWVkaWF0ZWx5LCBhbmQgdGhlIGxvbmctdGVybSBSVENQIHJh dGUgaXMKICAgcmVndWxhdGVkIHdpdGhpbiB0aGUgUlRDUCBiYW5kd2lkdGggbGltaXQuCgo0LjIu IEdlbmVyaWMgUGFja2V0IGZvcm1hdCBmb3IgcmVxdWVzdGluZyByZXRyYW5zbWlzc2lvbgoKICAg VGhpcyBzZWN0aW9uIGRlZmluZXMgYSBnZW5lcmljIHBhY2tldCBmb3JtYXQgZm9yIGEgbmVnYXRp dmUKICAgYWNrbm93bGVkZ21lbnQgKE5BQ0spIHBhY2tldCwgd2hpY2ggaXMgc2VudCBmcm9tIHRo ZSByZWNlaXZlciB0byB0aGUKICAgc2VuZGVyIGFuZCB3aGljaCBub3RpZmllcyB0aGUgcGFja2V0 IGxvc3Mgb2Ygb25lIG9yIG1vcmUgUlRQIHBhY2tldHMuCiAgIFRoaXMgZ2VuZXJpYyBwYWNrZXQg Zm9ybWF0IHByb3ZpZGVzIGEgd2F5IG9mIGlkZW50aWZ5aW5nIGEgcGFja2V0IGFuZAogICBhIDE2 IGJpdCBmaWVsZCBmb3IgcGF5bG9hZCBzcGVjaWZpYyB1c2UuICBXaGVuIGEgcGF5bG9hZCBmb3Jt YXQgZG9lcwogICBub3Qgc3BlY2lmeSB0aGUgdXNlIG9mIHRoZSBmaWVsZCwgdGhlIGRlZmF1bHQg Zm9ybWF0IGluIDQuMyBNVVNUIGJlCiAgIHVzZWQuICBUaGUgZ2VuZXJpYyBmb3JtYXQgb2YgTkFD SyBwYWNrZXRzIGlzIGFzIGZvbGxvd3M6CgogICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAg ICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r CiAgIHxWPTJ8UHwgICBSQyAgICB8IFBUPVJUQ1BfTkFDSyAgfCAgICAgICAgICBsZW5ndGggICAg ICAgICAgICAgICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICAgICAgICBTU1JDIG9mIHBh Y2tldCBzZW5kZXIgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICs9Kz0rPSs9Kz0rPSs9Kz0r PSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rCiAgIHwgICAg ICAgICAgICAgICAgICBTU1JDXzEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgIHwgICAgICAgICAgICBQSUQgICAgICAgICAgICAgICAgfCAgICAg IFBheWxvYWQgU3BlY2lmaWMgICAgICAgICB8CiAgICs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9 Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rCiAgIHwgICAgICAgICAgICAg ICAgICBTU1JDXzIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CgoKCllh bm8sIFBvZG9sc2t5LCBNY0Nhbm5lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBbUGFnZSA0XQoKSW50ZXJuZXQgRHJhZnQgICAgICAgICBSVENQLWJhc2VkIFJldHJhbnNt aXNzaW9uICAgICAgICAgICAgICBKdWx5LCAyMDAwCgoKICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAg ICAgIFBJRCAgICAgICAgICAgICAgICB8ICAgICAgUGF5bG9hZCBTcGVjaWZpYyAgICAgICAgIHwK ICAgKz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9 Kz0rPSs9Kz0rPSsKICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKCiAgIFRoZSB2YXJpb3VzIGZpZWxkcyBWLCBQLCBSQywg U1NSQyBhbmQgbGVuZ3RoIGFyZSBkZWZpbmVkIGluIHRoZSBSVFAKICAgc3BlY2lmaWNhdGlvbiBb MV0uICBXZSBzdW1tYXJpemUgdGhlIG1lYW5pbmcgb2YgYWxsIG9mIHRoZSBmaWVsZHMKICAgYmVs b3c6CgogICB2ZXJzaW9uIChWKTogMiBiaXRzCiAgICAgIFRoaXMgZmllbGQgaWRlbnRpZmllcyB0 aGUgUlRQIHZlcnNpb24uICBUaGUgY3VycmVudCB2ZXJzaW9uIGlzIDIuCgogICBwYWRkaW5nIChQ KTogMSBiaXQKICAgICAgSWYgc2V0LCB0aGUgcGFkZGluZyBiaXQgaW5kaWNhdGVzIHRoYXQgdGhl IFJUQ1AgTkFDSyBwYWNrZXQKICAgICAgY29udGFpbnMgYWRkaXRpb25hbCBwYWRkaW5nIG9jdGV0 cyBhdCB0aGUgZW5kIHdoaWNoIGFyZSBub3QgcGFydAogICAgICBvZiB0aGUgcmV0cmFuc21pc3Np b24gY29udHJvbCBpbmZvcm1hdGlvbiBidXQgYXJlIGluY2x1ZGVkIGluIHRoZQogICAgICBsZW5n dGggZmllbGQuCgogICByZXBvcnQgY291bnQgKFJDKTogNSBiaXRzCiAgICAgIFRoZSBudW1iZXIg b2YgTkFDSyBibG9ja3MgZm9yIGRpZmZlcmVudCBTU1JDLgoKICAgcGFja2V0IHR5cGUgKFBUKTog OCBiaXRzCiAgICAgIFRoaXMgaXMgdGhlIFJUQ1AgcGFja2V0IHR5cGUgd2hpY2ggaWRlbnRpZmll cyB0aGUgcGFja2V0IGFzIGJlaW5nCiAgICAgIGFuIFJUQ1AgTkFDSy4KCiAgIGxlbmd0aDogMTYg Yml0cwogICAgICBUaGUgbGVuZ3RoIG9mIHRoaXMgUlRDUCBOQUNLIHBhY2tldCBpbiAzMi1iaXQg d29yZHMgbWludXMgb25lLAogICAgICBpbmNsdWRpbmcgdGhlIGhlYWRlciBhbmQgYW55IHBhZGRp bmcuICBUaGlzIGNvbmZvcm1zIHdpdGggdGhlCiAgICAgIGRlZmluaXRpb24gb2YgdGhlIGxlbmd0 aCBmaWVsZCB1c2VkIGluIFJUQ1Agc2VuZGVyIGFuZCByZWNlaXZlcgogICAgICByZXBvcnRzIFsx XS4KCiAgIFNTUkM6IDE2IGJpdHMKICAgICAgVGhlIHN5bmNocm9uaXphdGlvbiBzb3VyY2UgaWRl bnRpZmllciBmb3IgdGhlIG9yaWdpbmF0b3Igb2YgdGhpcwogICAgICBOQUNLIHBhY2tldC4KCiAg IFNTUkNfbjogMTYgYml0cwogICAgICBUaGUgU1NSQyBpZGVudGlmaWVyIG9mIHRoZSBzb3VyY2Ug dG8gd2hpY2ggdGhlIGluZm9ybWF0aW9uIGluIHRoaXMKICAgICAgTkFDSyByZXBvcnQgYmxvY2sg cGVydGFpbnMuCgogICBQYWNrZXQgSUQgKFBJRCk6IDE2IGJpdHMKICAgICAgVGhlIFBJRCBmaWVs ZCBpcyB1c2VkIHRvIHNwZWNpZnkgYSBsb3N0IHBhY2tldC4gIFBheWxvYWQKICAgICAgZGVmaW5p dGlvbiBjYW4gZGVjaWRlIGhvdyB0byBpZGVudGlmeSBhIHBhY2tldC4gIFR5cGljYWxseSBSVFAK ICAgICAgc2VxdWVuY2UgbnVtYmVyIGlzIHVzZWQgZm9yIFBJRCBhcyB0aGUgZGVmYXVsdCBmb3Jt YXQuCgogICBQYXlsb2FkIFNwZWNpZmljOiAxNiBiaXRzCiAgICAgIFRoaXMgMTYgYml0IGZpZWxk IGNhbiBiZSB1c2VkIGZvciBwYXlsb2FkIHNwZWNpZmljIHB1cnBvc2VzLiBJZiBhCiAgICAgIHBh eWxvYWQgdHlwZSBkb2VzIG5vdCBzcGVjaWZ5IHRoZSB1c2Ugb2YgdGhpcyBmaWVsZCwgdGhlIGRl ZmF1bHQKICAgICAgcGFja2V0IGZvcm1hdCBpbiA0LjMgbXVzdCBiZSB1c2VkLgoKCgpZYW5vLCBQ b2RvbHNreSwgTWNDYW5uZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg W1BhZ2UgNV0KCkludGVybmV0IERyYWZ0ICAgICAgICAgUlRDUC1iYXNlZCBSZXRyYW5zbWlzc2lv biAgICAgICAgICAgICAgSnVseSwgMjAwMAoKCiAgIE5vdGUgdGhhdCB0aGUgcmVjZWl2ZXIgbWF5 IGRldGVjdCBSVFAgcGFja2V0IGxvc3MgdmlhIHNlcXVlbmNlIG51bWJlcgogICBnYXBzLCB0aW1l ciBleHBpcmF0aW9ucywgb3Igb3RoZXIgbWV0aG9kczsgaG93ZXZlciwgZGV0YWlscyBvZiB0aGUK ICAgbG9zcyBkZXRlY3Rpb24gc2NoZW1lIGFyZSBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiB0aGlz IGRvY3VtZW50LgoKNC4zLiBEZWZhdWx0IE5BQ0sgZm9ybWF0CgogICBUaGlzIHNlY3Rpb24gc2hv d3MgdGhlIGRlZmF1bHQgdXNlIG9mIHRoZSBwYWNrZXQgaWQgZmllbGQgYW5kIHRoZQogICBwYXls b2FkIHNwZWNpZmljIGZpZWxkLiBSVFAvQVZQLVJYIHByb2ZpbGUgTUFZIGJlIGRlcGxveWVkIGZv cgogICB0cmFuc21pdHRpbmcgYSBwYXlsb2FkIHdoaWNoIGlzIGRlZmluZWQgZm9yIFJUUC9BVlAg cHJvZmlsZS4gIFVubGVzcwogICBhbnkgc3BlY2lmaWMgcGFja2V0IGZvcm1hdCBmb3IgQVZQLVJY IHByb2ZpbGUgaXMgZGVmaW5lZCBpbiBhIHBheWxvYWQKICAgdHlwZSwgdGhpcyBkZWZhdWx0IHBh Y2tldCBmb3JtYXQgTVVTVCBiZSB1c2VkIGZvciBOQUNLcy4KCiAgICAwICAgICAgICAgICAgICAg ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEK ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsKICAgfFY9MnxQfCAgIFJDICAgIHwgUFQ9UlRDUF9OQUNLICB8ICAgICAgICAg IGxlbmd0aCAgICAgICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgICAgICAg IFNTUkMgb2YgcGFja2V0IHNlbmRlciAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgKz0rPSs9 Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0r PSsKICAgfCAgICAgICAgICAgICAgICAgIFNTUkNfMSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgIEZTTiAgICAgICAgICAg ICAgICB8UnwgICAgICAgICAgIEJMUCAgICAgICAgICAgICAgIHwKICAgKz0rPSs9Kz0rPSs9Kz0r PSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSsKICAgfCAg ICAgICAgICAgICAgICAgIFNTUkNfMiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsKICAgfCAgICAgICAgICAgIEZTTiAgICAgICAgICAgICAgICB8Unwg ICAgICAgICAgIEJMUCAgICAgICAgICAgICAgIHwKICAgKz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9 Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSsKICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKCiAg IFRoZSBGU04gYW5kIEJMUCBmaWVsZHMgaGF2ZSBzaW1pbGFyIGRlZmluaXRpb25zIHRvIHRob3Nl IGdpdmVuIGZvcgogICB0aGUgUlRDUF9OQUNLIHBhY2tldCBzcGVjaWZpZWQgaW4gWzNdLiAgVGhl IFIgYml0IGlzIHVzZWQgdG8gbm90aWZ5CiAgIHRoZSBzZW5kZXIgd2hldGhlciBsb3N0IHBhY2tl dHMgbmVlZCB0byBiZSByZXRyYW5zbWl0dGVkLiAgTkFDSwogICBwYWNrZXRzIFNIT1VMRCBiZSBz ZW50IGZvciBhbGwgbG9zdCBwYWNrZXRzLCBldmVuIHBhY2tldHMgdGhlCiAgIHJlY2VpdmVyIG1h eSBubyBsb25nZXIgbmVlZCB0byBiZSByZXRyYW5zbWl0dGVkLCBpbiBvcmRlciB0byBhbGxvdwog ICBlZmZlY3RpdmUgb3BlcmF0aW9uIG9mIGNvbmdlc3Rpb24gY29udHJvbC4gIFRoZSByZWNlaXZl ciBjYW4gbm90aWZ5CiAgIHRoZSBzZW5kZXIgd2hldGhlciB0aGUgcGFja2V0IG5lZWRzIHJldHJh bnNtaXNzaW9uIHRocm91Z2ggdGhlIFIKICAgZmllbGQgaW4gYSBOQUNLIHBhY2tldC4gIFRoZSBt ZWFuaW5ncyBvZiB0aGVzZSBmaWVsZHMgYXJlIGFzIGZvbGxvd3M6CgogICBmaXJzdCBzZXF1ZW5j ZSBudW1iZXIgKEZTTik6IDE2IGJpdHMKICAgICAgVGhlIEZTTiBjb3JyZXNwb25kcyB0byBhbiBS VFAgc2VxdWVuY2UgbnVtYmVyIG9mIGEgbWVkaWEgc3RyZWFtLgogICAgICBBIE5BQ0sgcGFja2V0 IHdpdGggYSBGU04gZmllbGQgc2V0IHRvIE4gaXMgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgYQogICAg ICBzaWduYWwgdGhhdCB0aGUgcmVjZWl2ZXIgaGFzIGRldGVjdGVkIGxvc3Mgb2YgUlRQIGRhdGEg cGFja2V0IE4uCgogICByZXF1aXJlbWVudCBvZiByZXRyYW5zbWlzc2lvbiAoUik6IDEgYml0CiAg ICAgIFRoaXMgZmllbGQgaW5kaWNhdGVzIHdoZXRoZXIgdGhlIHJlY2VpdmVyIGlzIHJlcXVlc3Rp bmcKICAgICAgcmV0cmFuc21pc3Npb24gb2YgdGhlIGxvc3QgcGFja2V0cyBkZXNpZ25hdGVkIGJ5 IHRoZSBGU04gYW5kIEJMUAogICAgICBmaWVsZHMuICBJZiB0aGlzIGJpdCBpcyBzZXQgdG8gMSwg dGhlIGxvc3QgcGFja2V0cyBvZiB0aGlzIE5BQ0sKICAgICAgYmxvY2sgYXJlIHJlcXVlc3RlZCB0 byBiZSByZXRyYW5zbWl0dGVkLiAgSWYgdGhlIGJpdCBpcyBzZXQgdG8gMCwKCgoKWWFubywgUG9k b2xza3ksIE1jQ2FubmUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDZdCgpJbnRlcm5ldCBEcmFmdCAgICAgICAgIFJUQ1AtYmFzZWQgUmV0cmFuc21pc3Npb24g ICAgICAgICAgICAgIEp1bHksIDIwMDAKCgogICAgICB0aGUgbG9zdCBwYWNrZXRzIGFyZSBub3Qg dG8gYmUgcmV0cmFuc21pdHRlZCwgYW5kIHRoaXMgTkFDSyBwYWNrZXQKICAgICAgd2FzIHNlbnQg b25seSBmb3IgdGhlIHB1cnBvc2Ugb2YgcmVwb3J0aW5nIHBhY2tldCBsb3NzLgoKICAgYml0bWFz ayBvZiBmb2xsb3dpbmcgbG9zdCBwYWNrZXRzIChCTFApOiAxNSBiaXRzCiAgICAgIFRoZSBCTFAg YWxsb3dzIGZvciByZXBvcnRpbmcgbG9zc2VzIG9mIGFueSBvZiB0aGUgMTUgUlRQIHBhY2tldHMK ICAgICAgaW1tZWRpYXRlbHkgZm9sbG93aW5nIHRoZSBSVFAgcGFja2V0IGluZGljYXRlZCBieSB0 aGUgRlNOLiAgVGhlCiAgICAgIEJMUCdzIGRlZmluaXRpb24gaXMgaWRlbnRpY2FsIHRvIHRoYXQg Z2l2ZW4gaW4gWzNdLiAgRGVub3RpbmcgdGhlCiAgICAgIEJMUCdzIGxlYXN0IHNpZ25pZmljYW50 IGJpdCBhcyBiaXQgMSwgYW5kIGl0cyBtb3N0IHNpZ25pZmljYW50IGJpdAogICAgICBhcyBiaXQg MTUsIHRoZW4gYml0IGkgb2YgdGhlIGJpdG1hc2sgaXMgc2V0IHRvIDEgaWYgdGhlIHNlbmRlciBo YXMKICAgICAgbm90IHJlY2VpdmVkIFJUUCBwYWNrZXQgbnVtYmVyIEZTTitpIChtb2R1bG8gMl4x NikgYW5kIHRoZQogICAgICByZWNlaXZlciBkZWNpZGVzIHRoaXMgcGFja2V0IGlzIGxvc3Q7IGJp dCBpIGlzIHNldCB0byAwIG90aGVyd2lzZS4KICAgICAgTm90ZSB0aGF0IHRoZSBzZW5kZXIgTVVT VCBOT1QgYXNzdW1lIHRoYXQgYSByZWNlaXZlciBoYXMgcmVjZWl2ZWQKICAgICAgYSBwYWNrZXQg YmVjYXVzZSBpdHMgYml0bWFzayB3YXMgc2V0IHRvIDAuICBGb3IgZXhhbXBsZSwgdGhlIGxlYXN0 CiAgICAgIHNpZ25pZmljYW50IGJpdCBvZiB0aGUgQkxQIHdvdWxkIGJlIHNldCB0byAxIGlmIHRo ZSBwYWNrZXQKICAgICAgY29ycmVzcG9uZGluZyB0byB0aGUgRlNOIGFuZCB0aGUgZm9sbG93aW5n IHBhY2tldCBoYXZlIGJlZW4gbG9zdC4KICAgICAgSG93ZXZlciwgdGhlIHNlbmRlciBjYW5ub3Qg aW5mZXIgdGhhdCBwYWNrZXRzIEZTTisyIHRocm91Z2ggRlNOKzE1CiAgICAgIGhhdmUgYmVlbiBy ZWNlaXZlZCBzaW1wbHkgYmVjYXVzZSBiaXRzIDIgdGhyb3VnaCAxNSBvZiB0aGUgQkxQIGFyZQog ICAgICAwOyBhbGwgdGhlIHNlbmRlciBrbm93cyBpcyB0aGF0IHRoZSByZWNlaXZlciBoYXMgbm90 IHJlcG9ydGVkIHRoZW0KICAgICAgYXMgbG9zdCBhdCB0aGlzIHRpbWUuCgo0LjQuIFNlbmRlciBh bmQgUmVjZWl2ZXIgUmVwb3J0CgogICBUaGUgb3JpZ2luYWwgUlRDUCBwYWNrZXRzIChTUi9SUikg U0hPVUxEIGFsc28gYmUgc2VudCBiYXNlZCBvbiBSRkMKICAgMTg4OS4gIExvc3MgZnJhY3Rpb24g YW5kIG90aGVyIGZpZWxkcyBpbiBTUiBhbmQgUlIgU0hPVUxEIGJlCiAgIGdlbmVyYXRlZCBiYXNl ZCBvbiBvcmlnaW5hbCBkYXRhIHRyYW5zbWlzc2lvbnMgYW5kIHdpdGhvdXQgdGFraW5nCiAgIGlu dG8gYWNjb3VudCByZXF1ZXN0ZWQgcmV0cmFuc21pc3Npb25zIHRoYXQgZGlkIG5vdCBhcnJpdmUu ICBUaGUKICAgcmVhc29uIGlzIHRoYXQgYWx0aG91Z2ggdGhlIGxvc3MgZnJhY3Rpb24gaW4gUlIg c2hvdWxkIGlkZWFsbHkKICAgYWNjb3VudCBmb3IgbG9zcyBvZiBhbnkgZGF0YSBpbiB0aGUgZm9y d2FyZCB0cmFuc21pc3Npb24gcGF0aCwgaXQgaXMKICAgZGlmZmljdWx0IHRvIGlkZW50aWZ5IHRo ZSByZWFzb24gb2YgYW4gdW5kZWxpdmVyZWQgcmV0cmFuc21pc3Npb24KICAgcGFja2V0LiAgVGhl cmUgYXJlIHRocmVlIHBvc3NpYmxlIHJlYXNvbnMgYSByZXF1ZXN0ZWQgcmV0cmFuc21pc3Npb24K ICAgbWF5IGJlIG1pc3Npbmc6IHRoZSByZXRyYW5zbWl0dGVkIHBhY2tldCB3YXMgbG9zdCBpbiB0 aGUgZm9yd2FyZAogICB0cmFuc21pc3Npb24gcGF0aCwgdGhlIHJldHJhbnNtaXNzaW9uIHJlcXVl c3Qgd2FzIGxvc3QgaW4gdGhlIHJldmVyc2UKICAgdHJhbnNtaXNzaW9uIHBhdGgsICBvciB0aGUg c2VuZGVyIGNob3NlIG5vdCB0byByZXNwb25kIHRvIHRoZQogICByZXRyYW5zbWlzc2lvbiByZXF1 ZXN0LgoKICAgVGhlIFJlY2VpdmVyIFJlcG9ydHMgU0hPVUxEIGJlIGlzc3VlZCBtb3JlIGZyZXF1 ZW50bHkgdGhhbiBzcGVjaWZpZWQKICAgaW4gUkZDIDE4ODkgZm9yIHVzZSBpbiBjb25nZXN0aW9u IGNvbnRyb2wgKFNlY3Rpb24gNSkuICBBIHJlY2VpdmVyCiAgIFNIT1VMRCBzZW5kIGEgUlIgd2l0 aGluIHRoZSBSVFQgaW50ZXJ2YWxzIGFuZCBjYW4gZXN0aW1hdGUgdGhlIFJUVAogICB0aHJvdWdo IHRoZSBlbGFwc2VkIHRpbWUgYmV0d2VlbiB0cmFuc21pc3Npb24gb2YgYSBOQUNLIHBhY2tldCBh bmQKICAgcmVjZXB0aW9uIG9mIHRoZSBjb3JyZXNwb25kaW5nIHJldHJhbnNtaXNzaW9uIHBhY2tl dC4KCjUuIENvbmdlc3Rpb24gQ29udHJvbAoKICAgRmFpciBiZWhhdmlvciBhZ2FpbnN0IG90aGVy IHR5cGVzIG9mIHRyYWZmaWMgKG1haW5seSBUQ1ApIGhhcyBjb21lIHRvCiAgIGJlIGEgc2lnbmlm aWNhbnQgaXNzdWUgZm9yIHRoZSBzdGFiaWxpdHkgb2YgdGhlIEludGVybmV0LiAgVGhlIG5lZWQK ICAgdG8gZW1wbG95IGNvbmdlc3Rpb24gY29udHJvbCB0byBtYWtlIFJUUCBzdHJlYW1zIHNoYXJl IGJhbmR3aWR0aAogICBmYWlybHkgd2l0aCBvdGhlciBzdHJlYW1zIGhhcyBiZWNvbWUgbW9yZSBp bXBvcnRhbnQgbm93IHRoYW4gZXZlcgogICBiZWZvcmUuICBUaGUgZGVwbG95bWVudCBvZiBjb25n ZXN0aW9uIGNvbnRyb2wgaXMgUkVDT01NRU5ERUQgZm9yIGEKCgoKWWFubywgUG9kb2xza3ksIE1j Q2FubmUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDddCgpJ bnRlcm5ldCBEcmFmdCAgICAgICAgIFJUQ1AtYmFzZWQgUmV0cmFuc21pc3Npb24gICAgICAgICAg ICAgIEp1bHksIDIwMDAKCgogICBzdHJlYW0gZm9sbG93aW5nIHRoZSBBVlAtUlggcHJvZmlsZS4g IEluIGNvbmp1bmN0aW9uIHdpdGggdGhlCiAgIGZyZXF1ZW50IFJUQ1AgaW50ZXJ2YWwgZm9ybXVs YXRlZCBpbiB0aGlzIHByb3Bvc2FsLCBOQUNLcyBhbmQgUlJzIGNhbgogICBwcm92aWRlIHRoZSBu ZWNlc3NhcnkgaW5mb3JtYXRpb24gZm9yIGVmZmVjdGl2ZSBjb25nZXN0aW9uIGNvbnRyb2wuCiAg IFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIFJUQ1AgKFJS IGFuZCBOQUNLKQogICBpbmZvcm1hdGlvbiBmb3IgY29uZ2VzdGlvbiBjb250cm9sLgoKICAgRm9y IG1hbnkgY29uZ2VzdGlvbiBjb250cm9sIHNjaGVtZXNbMTAsMTFdIHRvIG9wZXJhdGUsIHRoZSBs b3NzIHJhdGUKICAgYW5kIFJUVCBpcyByZXF1aXJlZC4gIEJlY2F1c2UgUlJzIGluY2x1ZGUgdGhl IGxvc3MgZnJhY3Rpb24sIGFuZAogICBiZWNhdXNlIHRoZSBSVFQgY2FuIGJlIGNhbGN1bGF0ZWQg YnkgdGhlIHNlbmRlciBiYXNlZCBvbiB0aGUgUlJzIGFzCiAgIGRlc2NyaWJlZCBpbiBSRkMxODg5 WzFdLCBpZiBSUnMgYXJlIHNlbnQgZnJlcXVlbnRseSBlbm91Z2ggKHNlY3Rpb24KICAgNC4zKSB0 aGVuIGEgc2VuZGVyIGNhbiBleGVjdXRlIGEgY29uZ2VzdGlvbiBjb250cm9sIHNjaGVtZSBzdWNo IGFzIGEKICAgVENQIGZhaXIgZXF1YXRpb24tYmFzZWQgc2NoZW1lWzEwXS4KCiAgIEEgY29uZ2Vz dGlvbiBjb250cm9sIHNjaGVtZSwgVEZSQ1sxMV0sIHJlY29tbWVuZHMgdGhlIHVzZSBvZiB0aGUg bG9zcwogICBpbnRlcnZhbCByYXRlIGluc3RlYWQgb2YgdGhlIGxvc3MgcmF0ZS4gIEJ5IGtlZXBp bmcgdHJhY2sgb2Ygc2VxdWVuY2UKICAgbnVtYmVyIG9mIGxvc3QgcGFja2V0cyBwcm92aWRlZCBi eSBOQUNLIHBhY2tldHMsIHRoZSBzZW5kZXIgY2FuCiAgIGNhbGN1bGF0ZSB0aGUgbG9zcyBpbnRl cnZhbCBhbmQgZXhlY3V0ZSB0aGUgY29uZ2VzdGlvbiBjb250cm9sCiAgIGRlc2NyaWJlZCBpbiBb MTFdLiAgVGhlIFJUVCBpcyBjYWxjdWxhdGVkIGJhc2VkIG9uIFJSIHJlY2VwdGlvbgogICB0aW1p bmcgaW4gdGhpcyBjYXNlIGFzIHdlbGwuCgo2LiBFeGFtcGxlcyBvZiByZXRyYW5zbWlzc2lvbiBk ZWNpc2lvbnMKCiAgIFJldHJhbnNtaXR0ZWQgcGFja2V0cyB3aGljaCBhcnJpdmUgYWZ0ZXIgdGhl aXIgc2NoZWR1bGVkIHBsYXlvdXQgdGltZQogICB3YXN0ZSBuZXR3b3JrIHJlc291cmNlcyBldmVu IHdoZW4gc3VjY2Vzc2Z1bGx5IHJlY2VpdmVkLiBUaGlzIHNlY3Rpb24KICAgZ2l2ZXMgIGV4YW1w bGVzIG9mIGhvdyB0aGUgZGVjaXNpb24gdG8gcmV0cmFuc21pdCBhIHBhY2tldCBtYXkgYmUKICAg bWFkZSBhbmQgaG93IHRoZSAgUiBiaXQgaW4gdGhlIE5BQ0sgcGFja2V0cyBpcyB1c2VkLgoKNi4x ICBBIHNpbXBsZSByZXRyYW5zbWlzc2lvbiByZXF1ZXN0IHN5c3RlbQoKICAgVGhlIHNpbXBsZXN0 IHdheSB0byByZWFsaXplIGxvc3MgcmVjb3ZlcnkgdXNpbmcgcmV0cmFuc21pc3Npb25zIGlzIHRv CiAgIGxldCB0aGUgcmVjZWl2ZXIgZGVjaWRlIHdoZXRoZXIgYSBOQUNLIHBhY2tldCB3aXRoIFIg Yml0IHNldCBzaG91bGQKICAgYmUgc2VudCBhbmQgaGF2ZSB0aGUgc2VuZGVyIHJlc3BvbmQgdG8g YWxsIHJldHJhbnNtaXNzaW9uIHJlcXVlc3RzCiAgIHdpdGggcmV0cmFuc21pdHRlZCBwYWNrZXRz LiAgSW4gdGhpcyBjYXNlIHRoZSByZWNlaXZlciBzZW5kcyBOQUNLcwogICB3aXRoIHRoZSBSIGJp dCBzZXQgd2hlbmV2ZXIgaXQgZGV0ZXJtaW5lcyB0aGF0IG9uZSBvciBtb3JlIGRhdGEKICAgcGFj a2V0cyBoYXZlIGJlZW4gbG9zdCBhbmQgdGhhdCB0aGVpciBwbGF5YmFjayB0aW1lcyBoYXZlIG5v dCB5ZXQKICAgcGFzc2VkLiBJZiB0aGUgcmVjZWl2ZXIgZGV0ZWN0cyBsb3N0IHBhY2tldHMgYWZ0 ZXIgdGhlIHBsYXliYWNrIHRpbWUKICAgcGFzc2VkLCB0aGUgUiBiaXQgaW4gTkFDSyBwYWNrZXRz IGlzIHNldCB0byAwLgoKICAgVGhpcyBzY2hlbWUgY2FuIGJlIHJlYWxpemVkIHdpdGhvdXQgYW4g ZXh0cmEgY29udHJvbCBwYWNrZXQgYmV0d2VlbgogICB0aGUgc2VuZGVyIGFuZCB0aGUgcmVjZWl2 ZXIuIEhvd2V2ZXIgaXQgY291bGQgcmVzdWx0IGluIG1hbnkgbGF0ZQogICBwYWNrZXRzIHRoYXQg YXJyaXZlIGFmdGVyIHBsYXkgb3V0IHRpbWUgYmVjYXVzZSBpdCBkb2VzIG5vdCBhY2NvdW50CiAg IGZvciB0aGUgZGVsYXkgYmV0d2VlbiB0aGUgdGltZSBhIHJlY2VpdmVyIHRyYW5zbWl0cyBhIE5B Q0sgYW5kIHRoZQogICB0aW1lIGF0IHdoaWNoIHRoZSByZXRyYW5zbWl0dGVkIHBhY2tldChzKSBj b3JyZXNwb25kaW5nIHRvIHRoYXQgTkFDSwogICBhcnJpdmUgKHdoaWNoIGlzIG9uZSBSVFQgb3Ig Z3JlYXRlcikuCgoKCgoKCgpZYW5vLCBQb2RvbHNreSwgTWNDYW5uZSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgOF0KCkludGVybmV0IERyYWZ0ICAgICAgICAg UlRDUC1iYXNlZCBSZXRyYW5zbWlzc2lvbiAgICAgICAgICAgICAgSnVseSwgMjAwMAoKCjYuMi4g IFJlY2VpdmVyLWJhc2VkIGRlY2lzaW9ucyBvbiByZXF1ZXN0aW5nIHJldHJhbnNtaXNzaW9ucwoK ICAgQmVmb3JlIG1ha2luZyBhIHJldHJhbnNtaXNzaW9uIHJlcXVlc3QgYXQgdGltZSBUciBvZiBw YWNrZXQgTgogICAoc2NoZWR1bGVkIGZvciBwbGF5LW91dCBhdCB0aW1lIFRwW05dKSwgdGhlIHJl Y2VpdmVyIGNoZWNrcyBpZgoKICAgVHIgKyBlUlRUIDwgVHBbTl0KCiAgIHdoZXJlIGVSVFQgaXMg YW4gZXN0aW1hdGUgb2YgdGhlIHJvdW5kIHRyaXAgdGltZSAoUlRUKS4gIElmIHRydWUgdGhlbgog ICB0aGUgcmVjZWl2ZXIgYXNzdW1lcyB0aGUgcmV0cmFuc21pc3Npb24gd2lsbCBhcnJpdmUgaW4g dGltZSwgYW5kIGl0CiAgIHNlbmRzIHRoZSByZXF1ZXN0IGZvciBwYWNrZXQgTiB3aXRoIFIgYml0 IHNldC4gIElmIGZhbHNlIHRoZSByZWNlaXZlcgogICBzZW5kcyBhIE5BQ0sgd2hvc2UgUiBiaXQg aXMgc2V0IHRvIDAuICBUaGUgYWJvdmUgY2hlY2sgY2FuIGJlIG1hZGUKICAgbW9yZSBnZW5lcmFs IHRvIGFjY291bnQgZm9yIHJlY2VpdmVyIGRlY29kaW5nIGRlbGF5cyBhbmQgdGhlIHNlbmRlcidz CiAgIGRlbGF5IGluIHJlc3BvbmRpbmcgdG8gdGhlIHJldHJhbnNtaXNzaW9uIHJlcXVlc3QuIFRo ZSBSVFQgZXN0aW1hdGUKICAgY2FuIGJlIGJhc2VkIG9uIHRoZSBtZWFzdXJlZCBlbGFwc2VkIHRp bWUgYmV0d2VlbiB0aGUgdHJhbnNtaXNzaW9uIG9mCiAgIGVhY2ggTkFDSyBhbmQgdGhlIHJlY2Vw dGlvbiBvZiBlYWNoIHJldHJhbnNtaXR0ZWQgcGFja2V0LiAgZVJUVCBpcwogICBjYWxjdWxhdGVk IGZyb20gdGhlc2UgUlRUIG1lYXN1cmVtZW50cyB0aHJvdWdoIEthcm4ncyBhbGdvcml0aG1bN10u CgoKNy4gUmVmZXJlbmNlcwoKICAgWzFdIFNjaHVsenJpbm5lLCBILiwgQ2FzbmVyLCBTLiwgRnJl ZGVyaWNrLCBSLiwgYW5kIFYuIEphY29ic29uLAogICAiUlRQOiBBIHRyYW5zcG9ydCBwcm90b2Nv bCBmb3IgcmVhbC10aW1lIGFwcGxpY2F0aW9ucywiIFJGQyAxODg5LAogICBKYW51YXJ5IDE5OTYu CgogICBbMl0gUy4gQnJhZG5lciwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gaW5kaWNh dGUgcmVxdWlyZW1lbnQKICAgbGV2ZWxzLCIgUmVxdWVzdCBmb3IgQ29tbWVudHMgKEJlc3QgQ3Vy cmVudCBQcmFjdGljZSkgMjExOSwgSW50ZXJuZXQKICAgRW5naW5lZXJpbmcgVGFzayBGb3JjZSwg TWFyLiAxOTk3LgoKICAgWzNdIFR1cmxldHRpLCBULiBhbmQgSHVpdGVtYSwgQy4sICJSVFAgUGF5 bG9hZCBGb3JtYXQgZm9yIEguMjYxIFZpZGVvCiAgIFN0cmVhbXMsIiBSRkMgMjAzMiwgT2N0b2Jl ciAxOTk2LgoKICAgWzRdIFBlcmtpbnMsIEMuIGFuZCBIb2Rzb24sIE8uLCAiT3B0aW9ucyBmb3Ig UmVwYWlyIG9mIFN0cmVhbWluZwogICBNZWRpYSIgUkZDIDIzNTQsIEp1bmUgMTk5OC4KCiAgIFs1 XSBSLiBYLiBYdSwgQS4gQy4gTXllcnMsIEguIFpoYW5nLCBhbmQgUi4gWWF2YXRrYXIuICBSZXNp bGllbnQKICAgbXVsdGljYXN0IHN1cHBvcnQgZm9yIGNvbnRpbnVvdXMgbWVkaWEgYXBwbGljYXRp b25zLiAgSW4gUHJvY2VlZGluZ3MKICAgb2YgdGhlIDd0aCBJbnRlcm5hdGlvbmFsIFdvcmtzaG9w IG9uIE5ldHdvcmsgYW5kIE9wZXJhdGluZyBTeXN0ZW1zCiAgIFN1cHBvcnQgZm9yIERpZ2l0YWwg QXVkaW8gYW5kIFZpZGVvIChOT1NTREFWJzk3KSwgV2FzaGluZ3RvbgogICBVbml2ZXJzaXR5IGlu IFN0LiBMb3VpcywgTWlzc291cmksIE1heSAxOTk3LgoKICAgWzZdIFNjaHVsenJpbm5lLCBILiwg IlJUUCBQcm9maWxlIGZvciBBdWRpbyBhbmQgVmlkZW8gQ29uZmVyZW5jZXMKICAgd2l0aCBNaW5p bWFsIENvbnRyb2wsIiBSRkMgMTg5MCwgSmFudWFyeSAxOTk2LgoKICAgWzddIFAuIEthcm4gYW5k IEMuIFBhcnRyaWRnZSwgIkltcHJvdmluZyBSb3VuZC1UcmlwIFRpbWUgRXN0aW1hdGVzIGluCiAg IFJlbGlhYmxlIFRyYW5zcG9ydCBQcm90b2NvbC4iICBBQ00gVHJhbnNhY3Rpb25zIG9uIENvbXB1 dGVyIFN5c3RlbXMKICAgKFRPQ1MpLCBWb2wuIDksIE5vLiA0LCBwcC4gMzY0LTM3MywgTm92ZW1i ZXIgMTk5MQoKICAgWzhdIE0uIEhhbmRsZXkgYW5kIFYuIEphY29ic29uLCAiU0RQOiBTZXNzaW9u IERlc2NyaXB0aW9uIFByb3RvY29sLiIKCgoKWWFubywgUG9kb2xza3ksIE1jQ2FubmUgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDldCgpJbnRlcm5ldCBEcmFm dCAgICAgICAgIFJUQ1AtYmFzZWQgUmV0cmFuc21pc3Npb24gICAgICAgICAgICAgIEp1bHksIDIw MDAKCgogICBSZXF1ZXN0IGZvciBDb21tZW50cyBSRkMgMjMyNy4KCiAgIFs5XSBULiBUdXJsZXR0 aSBhbmQgQy4gSHVpdGVtYSwgIlJUUCBQYXlsb2FkIEZvcm1hdCBmb3IgSC4yNjEgVmlkZW8KICAg U3RyZWFtcy4iICBSZXF1ZXN0IGZvciBDb21tZW50cyBSRkMgMjAzMiwgT2N0b2JlciAxOTk2LgoK ICAgWzEwXSBKLiBNYWhkYXZpLCBTLiBGbG95ZCwgIlRDUC1GcmllbmRseSBVbmljYXN0IFJhdGUt QmFzZWQgRmxvdwogICBDb250cm9sIiwgVGVjaG5pY2FsIG5vdGUgc2VudCB0byB0aGUgZW5kMmVu ZC1pbnRlcmVzdCBtYWlsaW5nIGxpc3QsCiAgIEphbnVhcnkgOCwgMTk5Ny4KCiAgIFsxMV0gUy4g RmxveWQsIE0uIEhhbmRsZXksIEouIFBhZGh5ZSwgYW5kIEouIFdpZG1lciwgIkVxdWF0aW9uLUJh c2VkCiAgIENvbmdlc3Rpb24gQ29udHJvbCBmb3IgVW5pY2FzdCBBcHBsaWNhdGlvbnMuIiAgQUNN IFNJR0NPTU0gMjAwMC4KCkFVVEhPUlMnIEFERFJFU1NFUwoKCiAgIEtvaWNoaSBZYW5vCiAgIFVD IEJlcmtlbGV5IENvbXB1dGVyIFNjaWVuY2UgRGVwdC4KICAgUGhvbmU6IDUxMC02NDItOTUxMwog ICBFbWFpbDogeWFub0Bjcy5iZXJrZWxleS5lZHUKICAgVVJMOiBodHRwOi8vd3d3LmNzLmJlcmtl bGV5LmVkdS9+eWFubwoKICAgTWF0dGhldyBQb2RvbHNreQogICBVQyBCZXJrZWxleSBDb21wdXRl ciBTY2llbmNlIERlcHQuCiAgIFBob25lOiA1MTAtNjQyLTg5MDUKICAgRW1haWw6IHBvZG9sc2t5 QGVlY3MuYmVya2VsZXkuZWR1CiAgIFVSTDogaHR0cDovL3d3dy5lZWNzLmJlcmtlbGV5LmVkdS9+ cG9kb2xza3kKCiAgIFN0ZXZlbiBNY0Nhbm5lCiAgIEZhc3RGb3J3YXJkIE5ldHdvcmtzCiAgIEVt YWlsOiBtY2Nhbm5lQGNzLmJlcmtlbGV5LmVkdQoKCiAgIFRoaXMgZHJhZnQgd2FzIGNyZWF0ZWQg aW4gSnVseSwgMjAwMC4KICAgSXQgZXhwaXJlcyAgSmFuLCAyMDAxLgoKCgoKCgoKCgoKCgoKCgoK Cllhbm8sIFBvZG9sc2t5LCBNY0Nhbm5lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDEwXQo= --V2VkLCAxOSBKdWwgMjAwMCAxMTo0MzoyMSAtMDcwMA==-- From rem-conf Wed Jul 19 12:07:19 2000 From rem-conf-request@es.net Wed Jul 19 12:07:18 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13EzAG-0001la-00; Wed, 19 Jul 2000 12:05:52 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13EzA7-0001lC-00; Wed, 19 Jul 2000 12:05:44 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id PAA03925; Wed, 19 Jul 2000 15:06:06 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id AAA20302; Thu, 20 Jul 2000 00:05:40 +0500 Message-Id: <200007191905.AAA20302@hafez.east.isi.edu> To: yano@EECS.Berkeley.EDU cc: rem-conf@es.net Subject: Re: RTCP Retransmission request In-Reply-To: Your message of "Wed, 19 Jul 2000 11:43:21 PDT." <3975F6C9AA.64DCYANO@pop.cs.berkeley.edu> Date: Wed, 19 Jul 2000 15:05:40 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Koichi Yano writes: >I submitted the revision of RTCP retransmission request profile on Jul >14 (definitely before 5pm E.T). >However, for some reasons, the submission has not been processed yet. >So I attach the draft. It is also available from: >http://www.cs.berkeley.edu/~yano/pubs/draft-ietf-avt-rtprx-00.txt It was passed to the working-group chairs for approval this morning, so I guess it'll be in the archives later today or tomorrow. I expect the i-d maintainers are somewhat busy right now - please be patient folks! Cheers, Colin From rem-conf Wed Jul 19 14:33:03 2000 From rem-conf-request@es.net Wed Jul 19 14:33:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13F1Pt-0004JM-00; Wed, 19 Jul 2000 14:30:09 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13F1Pq-0004JA-00; Wed, 19 Jul 2000 14:30:06 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id RAA05390 for ; Wed, 19 Jul 2000 17:30:27 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id CAA21727 for ; Thu, 20 Jul 2000 02:30:01 +0500 Message-Id: <200007192130.CAA21727@hafez.east.isi.edu> To: rem-conf@es.net Subject: DRAFT AVT agenda for Pittsburgh Date: Wed, 19 Jul 2000 17:30:01 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Attached is a first draft of the AVT agenda for Pittsburgh. Please send comments, corrections and additions to me and Steve as soon as possible. In particular, those who want agenda time but are not mentioned on this draft should contact me urgently. Thanks, Colin ------------------------------------------------------------------------------- Audio/Video Transport Working Group Agenda Wednesday 2nd August 2000, 09:00-11:30 ====================================== - Introduction and status update (Casner/Perkins) 15 - Enhancements to IP/UDP/RTP Header Compression (Koren) 5 draft-ietf-avt-crtp-enhance-00.txt - A LightWeight IP Encapsulation (LIPE) Scheme (Chuah) 10 draft-chuah-avt-lipe-01.txt - IP/UDP/RTP Header Compression over AAL2 (Koren) draft-buffam-avt-crtp-over-aal2-00.txt - Applicability of RFC2429 to H.263++ (Wenger) 5 - RTCP reporting extensions (Friedman) 20 draft-friedman-avt-rtcp-report-extns-01.txt - RTP Profile for RTCP-based Retransmission Request for Unicast session 10 draft-ietf-avt-rtprx-00.txt (Yano) - RTP Payload Format to Enable Multiple Selective Retransmissions draft-miyazaki-avt-rtp-selret-01.txt (Burmeister) 10 - RTCP-based Feedback for Predictive Video Coding draft-wenger-avt-rtcp-feedback-00.txt (Wenger) 15 - Low delay RTCP packet format for backward messages draft-fukunaga-low-delay-rtcp-00.txt (Fukunaga) 10 - RTP Payload Format for Generic FEC with ULP (Li) draft-li-avt-ulp-00.txt - A More Loss-Tolerant RTP Payload Format for MP3 Audio draft-ietf-avt-rtp-mp3-02.txt (Finlayson) 10 Thursday 3rd August 2000, 13:00-15:00 ===================================== - RTP payload format for AMR Liaison Statement from ETSI SMG2 (Barany) 5 draft-sjoberg-avt-rtp-amr-01.txt (Sjöberg) 5 draft-fingscheidt-avt-rtp-amr-00.txt ? draft-wimmer-amr-01.txt ? Discussion 10 - RTP Payload Format for SMPTE 292M (Gharai) 15 draft-ietf-avt-smpte292-video-00.txt draft-gharai-ac3-01.txt - RTP Payload Format for Distributed Speech Recognition 15 draft-meunier-avt-rtp-dsr-00.txt (Meunier) - A Framework for the delivery of MPEG-4 over IP-based Protocols draft-singer-mpeg4-ip-00.txt (Singer) ------------------------------------------------------------------------------- From rem-conf Wed Jul 19 15:07:32 2000 From rem-conf-request@es.net Wed Jul 19 15:07:31 2000 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 13F1yy-0002pp-00; Wed, 19 Jul 2000 15:06:24 -0700 Received: from sdn-ar-006nynyorp284.dialsprint.net ([168.191.123.86] helo=xzarsnorth.com) by mail2.es.net with smtp (Exim 1.92 #1) id 13F1yv-0002pV-00; Wed, 19 Jul 2000 15:06:22 -0700 From: Subject: Pay on Performance! Search engine positioning. Date: Wed, 19 Jul 2000 14:26:38 Message-Id: <826.875074.519699@xzarsnorth.com> Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list You pay only after results are shown to you. How about that!? We can list your website in all major Search Engines and achieve Top 10 positions. GUARANTEED! If people cannot find your business in the first 30 matches of a search, then submitting was a waste of time, money and hope. Search engine positioning is the most cost effective way of promoting your Website. We key on the following major search engines: Yahoo-AltaVista-WebCrawler-Lycos-Excite-iwon-Looksmart- AskJeeves-AOL Search-Netscape-HotBot-MSN-Infoseek-Snap- Google-Northern Light-Open Directory-Findwhat-Dogpile- Goto-Canada-Fast Serch (Alltheweb) Let us start launching your pages to the top of the search results today! Top 10 positions. GUARANTEED! Pay on Performance. You pay only after we show you the results. You choose how many search engines you want and we take your website to the TOP. As simple as that!!! For more information email us at: infoport12@earthlink.net with this subject: Send me more information Or call: Evelyn Navar 1-718-583-1771 Monday through Friday between 11am to 7pm Eastern Time ------------------------------------------------------------- Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter cannot be considered "spam" as long as we include: 1) contact information (see above); and, 2) the way to be removed from future mailings (see below). To be removed from this list, please mail to: digitalinkings@earthlink.net with 'remove' in subject line and you will be removed from our list. ------------------------------------------------------------ From rem-conf Thu Jul 20 03:56:49 2000 From rem-conf-request@es.net Thu Jul 20 03:56:47 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13FDnI-0005X0-00; Thu, 20 Jul 2000 03:43:08 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13FDnG-0005Wq-00; Thu, 20 Jul 2000 03:43:06 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09821; Thu, 20 Jul 2000 06:43:04 -0400 (EDT) Message-Id: <200007201043.GAA09821@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtprx-00.txt Date: Thu, 20 Jul 2000 06:43:04 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 Profile for RTCP-based Retransmission Request for Unicast session. Author(s) : K. Yano, M. Podolsky, S. McCanne Filename : draft-ietf-avt-rtprx-00.txt Pages : 10 Date : 19-Jul-00 This document specifies a new RTP profile for retransmission of lost packets of unicast multimedia sessions. We refer to this profile as 'RTP/AVP-RX'. This profile follows RFC 1889 as it is for data exchange. Specifically for unicast session, it changes the RTCP interval and defines a new RTCP packet type for retransmission requests. This document also describes how retransmission requests and retransmission data may be sent within RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtprx-00.txt 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-rtprx-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-ietf-avt-rtprx-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: <20000719140824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtprx-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtprx-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000719140824.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Jul 20 10:36:15 2000 From rem-conf-request@es.net Thu Jul 20 10:36:14 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13FK9S-0001x0-00; Thu, 20 Jul 2000 10:30:26 -0700 Received: from atlas.dnai.com [207.181.194.95] by mail1.es.net with esmtp (Exim 1.81 #2) id 13FK9R-0001wT-00; Thu, 20 Jul 2000 10:30:25 -0700 Received: from azoth.dnai.com (azoth.dnai.com [207.181.194.94]) by atlas.dnai.com (8.9.3/8.9.3) with ESMTP id KAA75033 for ; Thu, 20 Jul 2000 10:29:25 -0700 (PDT) Received: from cougar.chiplogic.com (cougar.chiplogic.com [216.15.52.34]) by azoth.dnai.com (8.9.3/8.9.3) with ESMTP id KAA92557 for ; Thu, 20 Jul 2000 10:29:24 -0700 (PDT) Received: from hariv (pc_hariv [192.168.0.44]) by cougar.chiplogic.com (8.9.1b+Sun/8.9.1) with SMTP id KAA11859 for ; Thu, 20 Jul 2000 10:29:20 -0700 (PDT) Message-ID: <002201bff26f$4b703640$03000004@hariv.domain> Reply-To: "Hari Krishna Vuppaladhadiam" From: "Hari Krishna Vuppaladhadiam" To: Subject: Packetization for signalling information from the T1/E1 framer Date: Thu, 20 Jul 2000 10:23:58 -0700 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; boundary="NextPart"; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I need information for the packetization (RTP) for signalling information specially CCS, CAS etc.. Hari From rem-conf Fri Jul 21 00:48:38 2000 From rem-conf-request@es.net Fri Jul 21 00:48:37 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13FXJw-0002or-00; Fri, 21 Jul 2000 00:34:08 -0700 Received: from hyundai5000.stm.it [195.62.32.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 13FXJu-0002ob-00; Fri, 21 Jul 2000 00:34:06 -0700 Received: from S4p205sG8 (tnt11a-204.focal-chi.corecomm.net [216.214.86.204]) by hyundai5000.stm.it (8.7.4/8.7.3) with SMTP id KAA04523; Fri, 21 Jul 2000 10:23:02 +0200 From: f3w4005AA@pd.jaring.my DATE: 21 Jul 00 3:59:34 AM Message-ID: <5JGD6KVx824g> TO: jana@sez.at SUBJECT: A Million Dollars? 2 Ways To Get It... X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A MILLION DOLLARS? 2 WAYS TO GET IT - THE SIMPLE FACT IS YOU CAN WIN IT OR WORK FOR IT! THIS E-MAIL PROVIDES INFORMATION ON BOTH METHODS PLUS PLENTY OF FREE BONUSES! CHECK YOUR AREAS OF INTEREST: ** Check boxes of interest and fax back to 770/234-5340 ** [ ] Show me where to register on line (for free!) where I can win a million dollars in prizes [ ] Tell me how I can make money part time in a home based business with little or no risk. Best time to call me is ______am or ______pm [ ] How can I get a free website and information on a visa/mc merchant account [ ] Send me your list of free special money making reports [ ] Where can I receive unlimited long distance calls for less than $60 per month with direct dial access [ ] I am a serious bus opp seeker, if you have a legitimate opportunity to make immediate and residual income contact me ASAP. For the right business, I have $_________to invest. My current profession is ________________________________________________________. $$ Fax Back For Immediate Response to: 770/234-5340 $$ Name______________________________________________ Phone_______________________Fax____________________ E-Mail_____________________________________________ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To be taken off of this listserver, Please include the word R in the subject header to: neddie@uk2.net From rem-conf Sat Jul 22 16:45:32 2000 From rem-conf-request@es.net Sat Jul 22 16:45:31 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13G8VJ-0000tv-00; Sat, 22 Jul 2000 16:16:21 -0700 Received: from gigli.inet.it (lsserver03.larrysmith.it) [194.185.218.193] by mail1.es.net with esmtp (Exim 1.81 #2) id 13G8VH-0000tl-00; Sat, 22 Jul 2000 16:16:19 -0700 Received: from minsk.docs.uu.se ([209.81.129.132]) by lsserver03.larrysmith.it (Lotus Domino Build 166.1) with SMTP id 2000072021493457:709 ; Thu, 20 Jul 2000 21:49:34 +0200 To: From: 69chevelle@hongkong.com Subject: Learn the currency trade market 23923 Date: Fri, 21 Jul 2000 14:50:56 -0500 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal Reply-To: weights@china.com X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win98; U) X-MIMETrack: Itemize by SMTP Server on lsserver03/larrysmith(Release 5.0 (Intl)|30 March 1999) at 07/20/2000 09:49:39 PM, Serialize by Router on lsserver03/larrysmith(Release 5.0 (Intl)|30 March 1999) at 07/23/2000 01:15:39 AM, Serialize complete at 07/23/2000 01:15:39 AM Message-ID: <000046200319$0000780b$00005d73@xa2.so-net.or.jp> Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Do You Have The Yen To Be a A Millionaire?
100% return in less than 90 days!

Unique Strategy Trading in the International Currency Markets!

Largest MarketPlace in the World!

Get our Reports, Charts and Strategies on the U.S. Dollar vs
Japanese yen and euro dollar.

 Example:
A $10,000 Investment in the yen vs the dollar, "properly positioned",
on 08/18 could have returned $30,369 on 09/19/99.

For a "FREE NO OBLIGATION" information packet please submit
the following:

 United States and Canadian Residents Only!
Just Click Below to go to our website:

click here


To be removed:
We are eager to take you off our list if you do not want future emails. We give you our assurance that your email address will be removed before w= e will do any future
mailings. Your email address WILL NOT be distributed to anyone.

mailto:69chevelle@hongkong.com?subject=3Dremove

<= p>

From rem-conf Sat Jul 22 20:15:22 2000 From rem-conf-request@es.net Sat Jul 22 20:15:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13GBqY-0003ME-00; Sat, 22 Jul 2000 19:50:30 -0700 Received: from (sstmail.sstech.on.ca) [216.94.153.178] by mail1.es.net with esmtp (Exim 1.81 #2) id 13GBqX-0003M4-00; Sat, 22 Jul 2000 19:50:29 -0700 Received: from y8b86y8 (1cust131.tnt1.springfield.il.da.uu.net [63.27.174.131]) by sstmail.sstech.on.ca with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id N7F30JVV; Sat, 22 Jul 2000 22:52:32 -0400 To: huopuogae17@kolping.de From: huopuogae17@kolping.de (Terry) Comments: Authenticated sender is Subject: The One And Only Electronic Spy Software ! Message-Id: <200007222966ZAA15330@hygtrfed5r.sstech.on.ca> Date: Sat, 22 Jul 2000 19:50:29 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Cyber Investigator "EASY WAY TO FIND OUT ANYTHING ABOUT ANYONE" Cyber Investigator TAKES YOU BEYOND WHAT SEARCH ENGINES CAN DO! Cyber Investigator is an amazing new tool that allows you to find EVERYTHING you ever wanted to know about your EMPLOYEES, FRIENDS, RELATIVES, SPOUSE, NEIGHBORS, even your BOSS! You can check out ANYONE, ANYTIME, ANYWHERE, right on the internet... Here's the best part: With our SECURE ORDER SYSTEM you can have this amazing tool in your hands right away and you can be doing your own on-line investigations IMMEDIATELY. To find out more about what Cyber Investigator can do for YOU! CLICK HERE http://3463729345/252525.html To be removed from future mailings send email to: pjsoft@n2sales. From rem-conf Sat Jul 22 22:11:07 2000 From rem-conf-request@es.net Sat Jul 22 22:11:05 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13GDwF-0005WY-00; Sat, 22 Jul 2000 22:04:31 -0700 Received: from terminator.sefes.es [194.179.85.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13GDwD-0005WE-00; Sat, 22 Jul 2000 22:04:29 -0700 Received: from depredador.sefes.es (jobs.sefes.es [194.179.85.3]) by terminator.sefes.es (SMTP Server) with ESMTP id 37D3D839A; Sun, 23 Jul 2000 07:01:18 +0200 (MEST) Received: from [208.162.252.154] by depredador.sefes.es (Netscape Mail Server v2.02) with SMTP id ABQ9396; Sun, 23 Jul 2000 05:20:18 +0200 From: Jpz44@aol.com To: MNP31@aol.com Subject: 3.95% 30 Yr. / 4.95% 40 Yr. Mortgages! Date: Sat, 22 Jul 00 23:06:18 Eastern Daylight Time Reply-To: Jpz44@aol.com X-Priority: 3 X-MSMailPriority: Normal Importance: Normal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0" Message-Id: <20000723050118.37D3D839A@terminator.sefes.es> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_018C_01BD9940.715D52A0 Content-Type: text/html; 3.95% 30 Year / 4.95% 40 Year Mortgages Now Available!

Loans from $50,000 to $1,500,000.00.

NO Penalty for early payoff.

Self-Employed and can't show income? NO PROBLEM!!

Go to www.debtfreehome.com for more information and to apply.



* In compliance with the proposed legislation for commercial e-mail,
we are providing Contact http://www.debtfreehome.com/contact.html and
remove@debtfreehome.comlinks. Requests sent to the Remove link
(and the Remove link ONLY) will immediately stop further transmissions
of this message at no cost to you.





 From rem-conf Sat Jul 22 22:27:20 2000 From rem-conf-request@es.net Sat Jul 22 22:27:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13GEDK-0005up-00; Sat, 22 Jul 2000 22:22:10 -0700 Received: from proxy2.ba.best.com [206.184.139.14] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 13GEDI-0005uS-00; Sat, 22 Jul 2000 22:22:08 -0700 Received: from kaipara.live.com (mg134-005.ricochet.net [204.179.134.5]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id WAA11491 for ; Sat, 22 Jul 2000 22:21:01 -0700 (PDT) Message-Id: <4.3.1.1.20000722221731.00b4b100@shell7.ba.best.com> X-Sender: rsf@shell7.ba.best.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sat, 22 Jul 2000 22:20:43 -0700 To: rem-conf@es.net From: Ross Finlayson Subject: This mailing list's spam problem Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As I'm sure you've all noticed, this mailing list has been getting lots of spam. Could the organizer of the list please change the list to accept messages from list members only? (Yes, I realize that this inconveniences those people who are subscribed indirectly, via an 'exploder' list...) Ross. From rem-conf Sun Jul 23 05:34:03 2000 From rem-conf-request@es.net Sun Jul 23 05:34:02 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13GKn9-0003lW-00; Sun, 23 Jul 2000 05:23:35 -0700 Received: from newdev.eecs.harvard.edu (newdev.harvard.edu) [140.247.60.212] by mail1.es.net with esmtp (Exim 1.81 #2) id 13GKn7-0003lG-00; Sun, 23 Jul 2000 05:23:33 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id IAA00448; Sun, 23 Jul 2000 08:22:45 -0400 (EDT) Date: Sun, 23 Jul 2000 08:22:45 -0400 (EDT) From: Scott Bradner Message-Id: <200007231222.IAA00448@newdev.harvard.edu> To: finlayson@live.com, rem-conf@es.net Subject: Re: This mailing list's spam problem X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > Could the organizer of the list please change the list to accept > messages from list members only? this can only be done on IETF mailing lists with the OK of the area director Scott From rem-conf Sun Jul 23 12:14:21 2000 From rem-conf-request@es.net Sun Jul 23 12:14:20 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13GR5T-0000DW-00; Sun, 23 Jul 2000 12:06:55 -0700 Received: from soong.cs.gmu.edu [129.174.87.53] by mail1.es.net with esmtp (Exim 1.81 #2) id 13GR5R-0000DK-00; Sun, 23 Jul 2000 12:06:53 -0700 Received: (from simon@localhost) by soong.cs.gmu.edu (8.9.3+Sun/8.9.3) id PAA13725; Sun, 23 Jul 2000 15:06:50 -0400 (EDT) Date: Sun, 23 Jul 2000 15:06:50 -0400 (EDT) From: "Robert P. Simon" Message-Id: <200007231906.PAA13725@soong.cs.gmu.edu> To: rem-conf@es.net Subject: CNDS '01 - Call for Papers Cc: simon@cs.gmu.edu X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> We apologize if you receive multiple copies of this. <-- ======================================================================= ANNOUNCEMENT AND CALL FOR PAPERS The Society for Computer Simulation International (SCS) presents: COMMUNICATION NETWORKS AND DISTRIBUTED SYSTEMS MODELING AND SIMULATION CONFERENCE January 7 - 11, 2001 Crown Plaza Hotel Phoenix, Arizona Part of the 2001 SCS Western Multiconference on Computer Simulation http://www.scs.org/confernc/wmc01/wmc2001cfp.html The purpose of this conference is to serve as a forum for the exchange of ideas, among researchers from around the world, about the design and performance of computer systems, network architectures, and communications protocols in parallel and distributed environments. This conference grew out of the urgent need to understand these systems as they became more complex. The paper sessions are designed to promote discussion of concepts, methodology, and results between authors and the audience. The structure of the conference is designed to provide for a high degree of collegiality and continuity in the discussions of the various topics presented during the week. In addition to technical sessions of contributed paper presentations, the conference, in conjunction with the Western Simulation Multiconference (WMC), will offer invited presentations, vendor presentations, and exhibits. Original technical papers, addressing all aspects of analysis, design, modeling, and performance evaluation of communication networks and distributed systems, are solicited for presentation at the conference and publication in the conference proceedings. Topics of interest include: * Network Architectures * High Speed Networks, ATM * Interconnection Networks * Wireless Networks * Distributed Systems * Mobile Computing * Multimedia Systems * Real-time Systems * Video-on-Demand Systems * Distributed Database Systems * Fault-tolerant Systems * Memory Systems * Operating Systems * File and I/O Systems * Web-based Computing IMPORTANT DATES: September 15th, 2000 Paper Submission Deadline. October 13th, 2000 Acceptance Notification. November 1st, 2000 Camera Ready Copies Due Date. Papers should be submitted electronically to simon@cs.gmu.edu. Submitted files must be in PostScript format with all figures and tables included. Only papers which have not been previously published or presented should be submitted. More conference information is available at http://www.scs.org/confernc/wmc01/text/cnds-cfp.html All submissions will be fully refereed for accuracy, technical content, and relevance. Papers should be limited to 20 double-spaced pages (at most 6 single-spaced pages for the camera-ready version). The authors should prepare a single page which includes authors names, title, affiliation, abstract, and a contact person information (complete address, email, phone, and fax). Accepted papers will appear in the Conference's Proceedings to be published by the Society for Computer Simulation. An award will be presented to the best paper presented at WMC'01. Authors of top papers will also be encouraged to submit a follow-on paper to the International Journal in Computer Simulation. Authors must obtain employer, client, or government releases prior to submittal of the final manuscript. General Chair Program Chair Prof. Taieb Znati Prof. Robert Simon Computer Science Department Computer Science Department University of Pittsburgh George Mason University Pittsburgh, PA 15260 Fairfax, VA 22030 U.S.A. U.S.A. Phone: +1(412)624-8417 Phone: +1(703)993-1556 FAX: +1(412)624-8854 FAX: +1(703)993-1710 E_Mail: znati@cs.pitt.edu E_Mail: simon@cs.gmu.edu Sponsored by The Society for Computer Simulation International P.O. Box 17900 San Diego, California 92177 Phone 858-277-3888 Fax 858-277-3930 E-mail scs@scs.org From rem-conf Sun Jul 23 18:19:50 2000 From rem-conf-request@es.net Sun Jul 23 18:19:49 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13GWkK-0004m4-00; Sun, 23 Jul 2000 18:09:28 -0700 Received: from cirrus.simepar.br [200.19.65.33] by mail1.es.net with smtp (Exim 1.81 #2) id 13GWkI-0004lu-00; Sun, 23 Jul 2000 18:09:26 -0700 Received: from MailClients by MailServer id AA36664; Sun, 23 Jul 2000 22:07:53 -0300 Message-Id: <00003e5e2b70$000074c8$0000138d@default> To: From: arcolleen@utic.net.ba Subject: A Million Dollars? 2 Ways To Get It... Date: Sun, 23 Jul 2000 12:37:10 -0500 X-Priority: 3 X-Msmail-Priority: Normal X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A MILLION DOLLARS? 2 WAYS TO GET IT - THE SIMPLE FACT IS YOU CAN WIN IT OR WORK FOR IT! THIS E-MAIL PROVIDES INFORMATION ON BOTH METHODS PLUS PLENTY OF FREE BONUSES! CHECK YOUR AREAS OF INTEREST: You are recieving this message because you were referred or requested additional information. If you would like to have your address removed from our Opt-In listserver, see the end of this message. ** Check boxes of interest and fax back to 770/234-5340 ** [ ] Show me where to register on line (for free!) where I can win a million dollars in prizes [ ] Tell me how I can make money part time in a home based business with little or no risk. Best time to call me is ______am or ______pm [ ] How can I get a free website and information on a visa/mc merchant account [ ] Send me your list of free special money making reports [ ] Where can I receive unlimited long distance calls for less than $60 per month with direct dial access [ ] I am a serious bus opp seeker, if you have a legitimate opportunity to make immediate and residual income contact me ASAP. For the right business, I have $_________to invest. My current profession is ________________________________________________________. $$ Fax Back For Immediate Response to: 770/234-5340 $$ Name______________________________________________ Phone_______________________Fax____________________ E-Mail_____________________________________________ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To be taken off of this listserver, Please include the word R in the subject header to: r241@uk2.net From rem-conf Mon Jul 24 03:46:04 2000 From rem-conf-request@es.net Mon Jul 24 03:46:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13GfYQ-00031s-00; Mon, 24 Jul 2000 03:33:46 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13GfYO-00031i-00; Mon, 24 Jul 2000 03:33:44 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07437; Mon, 24 Jul 2000 06:33:43 -0400 (EDT) Message-Id: <200007241033.GAA07437@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-mime-03.txt Date: Mon, 24 Jul 2000 06:33:43 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 : MIME Type Registration of RTP Payload Formats Author(s) : S. Casner, P. Hoschka Filename : draft-ietf-avt-rtp-mime-03.txt Pages : 18 Date : 21-Jul-00 This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-mime-03.txt 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-mime-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-ietf-avt-rtp-mime-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: <20000721171214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mime-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mime-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721171214.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Jul 24 03:46:04 2000 From rem-conf-request@es.net Mon Jul 24 03:46:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13GfYU-000324-00; Mon, 24 Jul 2000 03:33:50 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13GfYS-00031u-00; Mon, 24 Jul 2000 03:33:49 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07463; Mon, 24 Jul 2000 06:33:48 -0400 (EDT) Message-Id: <200007241033.GAA07463@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-profile-new-09.txt,.ps Date: Mon, 24 Jul 2000 06:33:47 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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 Profile for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne, S. Casner Filename : draft-ietf-avt-profile-new-09.txt,.ps Pages : 44 Date : 21-Jul-00 This memorandum is a revision of RFC 1890 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1890 are marked by change bars. This document describes a profile called 'RTP/AVP' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-09.txt 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-profile-new-09.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-profile-new-09.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: <20000721171238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-new-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-new-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721171238.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Jul 24 03:46:04 2000 From rem-conf-request@es.net Mon Jul 24 03:46:00 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13GfYX-00032G-00; Mon, 24 Jul 2000 03:33:53 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 13GfYW-000326-00; Mon, 24 Jul 2000 03:33:52 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07475; Mon, 24 Jul 2000 06:33:52 -0400 (EDT) Message-Id: <200007241033.GAA07475@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-new-08.txt,.ps Date: Mon, 24 Jul 2000 06:33:51 -0400 Sender: nsyracus@cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --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: A Transport Protocol for Real-Time Applications Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson Filename : draft-ietf-avt-rtp-new-08.txt,.ps Pages : 102 Date : 21-Jul-00 This memorandum is a revision of RFC 1889 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1889 are marked by change bars. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-08.txt 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-new-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-new-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: <20000721171248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-new-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-new-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000721171248.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Jul 24 04:01:32 2000 From rem-conf-request@es.net Mon Jul 24 04:01:32 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Gfqw-00048M-00; Mon, 24 Jul 2000 03:52:54 -0700 Received: from nscolmar.colmar.uha.fr [194.167.108.34] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Gfqt-000477-00; Mon, 24 Jul 2000 03:52:52 -0700 Received: from colmar.colmar.uha.fr (colmar.colmar.uha.fr [194.167.107.31]) by nscolmar.colmar.uha.fr (8.9.3/8.9.3) with ESMTP id MAA15393; Mon, 24 Jul 2000 12:17:54 +0200 From: conf@colmar.uha.fr Received: from gtrpc13 (gtrpc13.colmar.uha.fr [192.168.12.51]) by colmar.colmar.uha.fr (8.8.8/8.8.8) with SMTP id MAA07829; Mon, 24 Jul 2000 12:48:52 +0100 (WET DST) Message-Id: <3.0.1.32.20000724135449.009392b0@colmar.colmar.uha.fr> X-Sender: conf@colmar.colmar.uha.fr X-Mailer: Windows Eudora Pro Version 3.0.1 (32) [F] Date: Mon, 24 Jul 2000 13:54:49 +0200 To: conf@colmar.colmar.uha.fr Subject: Call for papers of ICN'01 & Final program of ECUMN'00 Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please feel free to circulate this following : - call for papers of ICN'01 (see 0000,0000,fefehttp://iutsun1.colmar.uha.fr/= ICN01.html ) AND=20 - final program of ECUMN'00 (see= 0000,0000,fefehttp://iutsun1.colmar.uha.fr= /ECUMN2000.html ) to interested colleagues. Accept our sincere apologies if you receive multiple copies. ----------------------------------------------------------------------------= ---

CALL FOR PAPERS=20 IEEE International Conference on Networking=20 ICN'01=20 July 11-13, 2001 - CREF, Colmar, France=20
GENERAL INFORMATION=20 The 2001 International Conference on Networking (ICN'01) is sponsored by= IEEE/Comsoc, IEEE/Computer, by IEE, by SEE and by WSES. ICN'01 is organized= by academic, research and industrial societies will be held at the= Technical Institute, Colmar, part of the University of Haute Alsace,= France, from Wednesday July 11, 2001 to Friday July 13, 2001. The city of= Colmar is ideally situated in the eastern part of France, near the German= and Swiss borders. The city of Colmar has been working on its own= Metropolitan Area Network (MAN) project, called OASICE, including LAN= interconnection, PBX interconnection and interactive video. An exhibition= illustrating these topics will be organized for industrial companies and= development research institutes.=20 In order to encourage closer interaction between academic and industrial ATM= research communities, we solicit both academic research papers and= industrial contributions.=20 TOPICS OF SPECIAL INTEREST=20 Topics of interest include, but are not limited to the following:=20 =20 Communications switching and routing =20 Communications modeling =20 Communications security =20 Computer communications =20 Multimedia and multicast communications =20 Internet environment =20 Network Management and control =20 Quality of Service (IntServ, DiffServ, =85) =20 Wireless Communications (Satellite, WLL, 3G) =20 Voice over IP =20 Java, Tina, Corba architectures Network signaling =20 ATM networks =20 ATM/IP integration =20 Integrated services =20 Traffic engineering =20 Telecommunication networks architectures =20 Performance evaluation, simulation =20 Mobile agents, active and intelligent networks =20 Applications and case studies =20 Protocol design and evaluation =20 MPLS=20 These topics can be discussed in term of concepts, state of the art,= standards, implementations, running experiments and applications.=20 INSTRUCTIONS FOR AUTHORS=20 Mail four papers or E-mail preferably in Word 6 format, or alternately a= postscript version of a 2000-word extended abstract summarizing an original= work. All the manuscripts must be written in English. The top of the first= page of each paper should include the title of the paper, authors' name,= position, address, telephone and fax numbers, e-mail of the author= responsible for correspondence and a list of four keywords. The deadline= for submission of all extended abstracts is December 10, 2000 with= notification of acceptance by February 20, 2001. Submission of camera-ready= paper is by March 30, 2001.=20 Authors of accepted papers will be invited to submit full-length manuscripts= for inclusion in the proceedings with ISBN.=20 All submitted papers should be sent to the following address:=20 Pascal LORENZ=20 University of Haute Alsace=20 IUT - Department GTR=20 34 rue du Grillenbreit=20 68008 Colmar, France=20 Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042=20 E-mail: lorenz@colmar.uha.fr=20 Check our Web page at= 0000,0000,fefehttp://iutsun1.colmar.uha.fr= /ICN01.html for the latest information concerning the= conference.=20 Best papers will be forwarded for consideration in a special issue of a= journal.=20 TUTORIALS AND WORKSHOPS=20 Tutorials and workshops provide overviews of current high interest topics.= Proposals for half of full day tutorials are due by December 10, 2000.=20 INTERNATIONAL ADVISORY COMMITTEE=20 R. Addie (Australia) - University of Southern Queensland=20 K. Begain (Jordan) - Mu'tah University=20 A. Benslimane (France) - University of Belfort-Montbeliard=20 B. Bing (Singapore) - Ngee Ann Polytechnic=20 D. Bonjour (France) - CNET=20 A. Brandwajn (USA) - University of California Santa Cruz=20 J.P. Coudreuse (France) =96 Mitsubishi=20 J. Crowcroft (UK) =96 University College London=20 S. Fdida (France) =96 LIP6=20 B. Gavish (USA) - Vanderbilt University=20 H. Guyennet (France) - University of Franche-Comte=20 J. Halpern (USA) =96 Newbridge=20 Z. Hulicki (Poland) =96 University of Cracow=20 R. Israel (France) - IEEE=20 A. Jajszczyk (Poland) - University of Mining & Metallurgy=20 A. Jamalipour (Australia) - University of Sydney=20 S. Kota (USA) - Lockeed Martin=20 D. Kouvatsos (UK) - University of Bradford=20 S. Kumar (USA) =96 Ericsson=20 G.S. Kuo (Taiwan) =96 National Central University=20 F. Le Faucheur (France) - Cisco=20 M. Lee (Korea) =96 Dongshin University=20 P. Lorenz (France) - University of Haute Alsace=20 H.. Mouftah (Canada) - Queen's University=20 G. Omidyar (USA) - Computer Sciences Corp.=20 J.J. Pansiot (France) - University of Strasbourg=20 M. Potts (Switzerland) - Martel=20 Z. Mammeri (France) - University of Toulouse=20 N. Mastorakis (Greece) - Military Institutions of University Education=20 S. Moyer (USA) - Bellcore=20 R. Muraine (France) - Newbridge=20 G. Pujolle (France) - University of Versailles-Saint-Quentin=20 S. Rao (Switzerland) - Ascom=20 A. Reid (UK) - British Telecom=20 S. Ritzenthaler (France) - Newbridge=20 P. Rolin (France) - ENST Bretagne=20 R. Saracco (Italy) - CSELT=20 G. Swallow (USA) - Cisco=20 H. Tobiet (France) =96 Clemessy=20 M. Trehel (France) =96 University of Franche-Comte=20 V.A. Villagra (Spain) =96 University of Madrid=20 E. Vazquez Gallo (Spain) =96 University of Madrid=20 O. Yang (Canada) - University of Ottawa=20 IMPORTANT DATES=20 Extended Abstract due: December 10, 2000=20 Notification of acceptance: February 20, 2001=20 Deadline for full-length camera-ready manuscript: March 30, 2001=20 ---------------------------------------------------------------------------
1st IEEE European Conference on Universal Multiservice= Networks ECUMN'2000 October 2-4, 2000 - CREF, Colmar, France FINAL PROGRAM
=20 08:30 - 18:30 Conference Registration Monday October 2, 2000 09:00 - 09:20 Opening Address=20 09:20 - 10:30 Tutorial Session 1 Internet Services over Mobile and Wireless Networks: Architectures and= Protocols G. Omidyar, Computer Sciences Corp., USA ; M.J. Montpetit, Teledesic LLC,= USA 10:30 - 11:00 Coffee Break 11:00 - 12:15 Network Architecture and Convergence Chair: S. Ritzenthaler, Newbridge, France MPLS and Next Generation Access Network A. Kankkunen, Integral Access Inc, USA Deutsche Telekom's View on Network Convergence L. Falkenhagen Deutsche Telekom AG, Germany A Functional Architecture for End-to-end Quality-of-Service in a= Multi-domain Network E. Pagani, G.P. Rossi, University of Milano, Italy 12:15 - 13:00 Panel Discussion 1 - Network Evolution and Convergence 13:00 - 14:30 Lunch 14:30 - 16:15 Traffic=20 Chair: M. Villen, Telefonica I+D, Spain The Relevance of the Bufferless Analysis for Traffic Management in= Telecommunication Networks G. Hasslinger, F. Hartleb, Telekom Innovations-GmbH, Germany ; M. Fiedler,= University of Karlskrona/Ronneby, Sweden Mapping of Loss and Delay Between IntServ and DiffServ T. Chahed, G. H=E9buterne, C. Fayet, National Institute of= Telecommunications, France Resource Demand of Aggregated Resource Reservations J. Ehrensberger, Swiss Federal Institute of Technology, Switzerland Characterization of the MPEG-2 Video Traffic Generated by DVD Applications A. Chodorek, Kielce University of Technology, Poland ; R. Chodorek,= University of Mining and Metallurgy, Poland 14:30 - 16:15 Interworking between narrow band and broadband networks Chair: S. Chakraborty, Technical University of Helsinki, Finland Integrating Euro-ISDN with ATM Technology: Interworking Mechanisms and= Services Support L. Mandalos, K. Leonidou, C. Andreopoulos, J. Drakos, S. Koubias, G.= Papadopoulos, University of Patras, Greece Extending the Internet with the Intelligent Network Capabilities B. El Ouahidi, M. Bouhdadi, University of Rabat, Morocco ; D. Bourget, ENST,= France A Suitable Service Discipline for ATM-Ethernet Interconnection J.M. Arco, D. Meziat, B. Alarcos, University of Alcala, Spain Interoperability of ATM-Ethernet Interworking System: Design and Congestion= Control R. Ouni, A. Soudani, S. Nasri, M. Abid, R. Tourki, University of Monastir,= Tinisia ; K. Torki, INPG, France 16:15 - 16:45 Coffee Break 16:45 - 18:30 Routing Chair: P. Chemouil, France Telecom R&D, France Adaptive Routing and Load Balancing of Ephemeral Connections M. Heusse, ENST de Bretagne, France A new Multi-Services Rerouting Algorithm A. Gueroui, University of Versailles, France ; L. Mokdad University of= Dauphine, France ; J. Ben-Othman University of Paris 6, France Extending Mobile IP-v6 with Multicast to Support Mobile Networks in IPv6 T. Ernst, C. Castelluccia, INRIA Rh=F4ne-Alpes, France ; H.Y. Lach, Motorola= Labs, France 16:45 - 18:30 Interworking between IP and ATM Chair: M. Potts, Martel, Switzerland Topology Optimization of IP over ATM L. Frelechou, M. Osborne, R. Haas, IBM Research, Switzerland Resource Reservation with Boomerang via Open Interfaces M. Maliosz, Budapest University of Technology and Economics, Hungary Efficient Translation of Network Performance Parameters for Transport of IP= Packets over Cell-Switched Subnetworks J. Schmitt, M. Karsten, R. Steinmetz, Darmstadt University of Technology,= Germany Design of Adaptive Access Network and Control Protocol H. Nakagawa, I. Kazunari, N. Ohta, NTT Information Sharing Platform= Laboratories, Japan 19:15 Reception - Town Hall Tuesday October 3, 2000 09:00 - 10:45 End to end traffic Control (1) Chair: U. Krieger, Deutsche Telecom, Germany Guaranteed QoS for TCP flows in ATM-based DiffServ Networks T. M=FCller, Dresden University of Technology, Germany Virtual Buffering Strategy for GFR Services in IP/ATM Internetworks S.C. Hu, Ming Shin Institute of Technology, Taiwan ; P.C. Wang, Y.C. Chen,= National Chiao Tung University, Taiwan ; C.T. Chan, Chunghwa Telecom,= Taiwan An Efficient Weight Assignment Process for GPS Servers G. Urvoy, PRISM, France ; G. Hebuterne, Institut National des= T=E9l=E9communications, France Some Aspects of RTP - TCP Coexistence in Universal Multiservice Networks R. Chodorek, University of Mining and Metallurgy, Poland 09:00 - 10:45 Mobile Networks and Mobile Services Chair: G. Omidyar, Computer Sciences Corp, USA Voice Enabled Request and Response for Mobile Devices Supporting WAP= Protocol: the Constraints A. Mohan, Himachal Futuristic Communications, India ; A. Mohan, Indian= Institute of Technology, India IP based enhanced Data Casting Services over Radio Broadcast Networks W. Kellerer, P. Sties, J. Ebersp=E4cher, Munich University of Technology,= Germany Location-Dependant and Value Added Services (VAS) for Mobile Communications P. Lorenz, University of Haute Alsace, France ; H. Tobiet, NMG, France=20 The IP Revolution and Potential gains for ISP/Mobile/Fixed Telephony= Operators in the Liberalization of Telecommunications D. Vergados, D. Drakoulis, E. Vayias, J. Soldatos, N. Mitrou, National= Technical University of Athens, Greece 10:45 - 11:15 Coffee Break 11:15 - 13:00 Multicast Chair: G. Girardi, CSELT, Italy A Scalable Fault Tolerant Approach to Core Election in an Inter-Domain= Multicast Routing Environment M.D.Ech-Cherif El Kettani, ENSIAS, Morocco; Y. Souissi, EMI, Morocco A New Routing Algorithm for Delay-Constrained Dynamic Multicast T. Asaka, NTT Service Integration Laboratories, Japan ; T. Miyoshi, Y.= Tanaka, Waseda University, Japan Remote Time-Alignment of Interactive Services through Efficient Multicast= Algorithms A. Borella, G. Cancellieri, University of Ancona, Italy Key Establishment for IGMP Authentication in IP Multicast T. Hardjono, B. Cain, Nortel Networks, USA 11:15 - 13:00 IP Test-beds Chair: H. Tobiet, NMG, France Real-Time Multimedia Services over Internet A. Benslimane, Technical University of Belfort-Montb=E9liard, France Telephony over IP: Theoretical Modelling and Lab Experiments P. Senesi, P. Ferrabone, G. Gritella, R. Rinaldi, M. Siviero, CSELT, Italy User-domain Multiservice Architecture for Wired and Wireless IP Networks L. Cheng, I. Marsic, The State University of New Jersey, USA A Testbed Environment for the Performance Evaluation of Modular Network= Architectures D. Maggiorini, E. Pagani, G.P. Rossi, University of Milano, Italy 13:00 - 14:30 Lunch 14:30 - 16:15 Modeling Chair: G. H=E9buterne, INT, France Estimation of the Renewal Function by Empiral Data - A Bayesian Approach N.M. Markovitch, Russian Academy of Sciences, Russia ; U.R. Krieger, T-Nova= Deutsche Telekom, Germany Modeling Access Networks for Quality of Service F. Duran, T. Lizambri, S. Wakid, National Institute of Standards and= Technology, USA ; D.R. Vaman, Megaxess, USA Managing Wireless Internet Information of Electronic Advertising E. Rashid, Y. Yoshioka, Hirosaki University, Japan ; Y. Nemoto, T. Nakamura,= Tohoku University, Japan Performance Evaluation of a full Memory Multidestination Protocol for= Satellite Based Reliable Multicast with and without Local Recovery H. Jianhua, K.R. Subramanian, Y. ZongKai, H. Ping, Nanyang Technological= University, Singapore 14:30 - 16:15 Tariffs and Bandwidth Allocation Chair: P. Lorenz, University of Haute Alsace, France INEDAC Project: A Tool to Calculate Interconnection Tariff based on a= Bottom-up Method J.A. Portilla, K.D. Hackbarth, A.E. Garcia, University of Cantabria, Spain ;= R. W=F6hrl, F. Gonzalez, Institut f=FCr Kommunikationsdienste GmbH, Germany Auction Method and its Performance in a Dynamic Bandwidth Allocation Service E. Takahashi, Y. Tanaka, Waseda Universiy, Japan Multivariable Feedforward Plus Feedback Control for Adapting MPEG Video= Streams to Variable Channel Bandwidth H.F. Raynaud, M. Luong, University of Paris Nord, France Robust Topology for Enterprise Networks against Diverse Tariff Structures T. Miyoshi, K. Mouri, Y. Tanaka, Waseda University, Japan ; T. Asaka, NTT= Service Integration Laboratories, Japan 16:15 - 16:45 Coffee Break 16:45 - 18:30 End to end Traffic Control (2) Chair: G. H=E9buterne, INT, France An Architecture of QoS Services for a Core Internet Network over DTM C.J. Barenco, Polytechnic University of Madrid, Spain ; A.A. Salona, J.I.= Moreno, University Carlos III of Madrid, Spain Congestion Avoidance for Unicast and Multicast Traffic A. Dracinschi, S. Fdida, University Pierre et Marie Curie, France MPOA and QoS Support in LIS Internetworking Environments I. Erturk, Kocaeli University, UK ; E. Stipidis, University of Sussex, UK A Method for Increasing Throughput based on Packet Striping F. Jacquet, M. Misson, IUT of Clermont-Ferrand, France 16:45 - 18:30 Advanced Networking Chair: G.V. Morson, Cambridge Network, England A New Network Service Environment using Active Network K. Widoyo, T. Aoki, H. Yasuda, University of Tokyo, Japan Adaptive Applications over Active Networks: Case Study on Layered Multicast L. Yamamoto, G. Leduc, University of Li=E8ge, Belgium Integrated Performance Monitoring of Client/Server Software C. Steigner, J. Wilke, I. Wulff, University of Koblenz-Landau, Germany Who needs Addresses ? V. Guruprasad, IBM, USA 20:00 Gala Dinner - Restaurant Meistermann Wednesday October 4, 2000 09:00 - 10:00 Tutorial Session 2 Chair: P. Rolin, France Telecom R&D, France Active Networks and its Management M. Brunner, NEC Europe Ltd, Germany 10:00- 10:30 Coffee Break 10:30 - 11:45 New Architectures for New Services Chair: A. Gravey, ENST-Bretagne, France A Novel Architecture for Efficient Protocol Processing in High Speed= Communication Environments G. Konstantoulakis, V. Nellas, C. Georgopoulos, T. Orphanoudakis, N. Zervos,= Ellemedia Technologies, Greece ; M. Steck, Hyperstone electronics GmbH,= Germany; D. Verkest, Interuniversity Microelectronics Centre (IMEC),= Belgium; G. Doumenis, D.Reisis, University of Athens, Greece; N. Nikolaou,= J.A. Sanchez, Lucent Technologies, The Netherlands Using T=E9l=E9domotis Interface for a new Multiservice Network applied to= Monitoring the Elderly T. Val, E. Campo, IUT of Blagnac, France ; P. Kauffmann, M. Misson,= University of Clermont II, France ; P.Y. Danet, France T=E9l=E9com R&D,= France Video and Interactive Internet access in a DVB Network R. Jaeger, BetaResearch, Germany 11:45 - 13:00 Panel Discussion 2 - New Architectures for New Services 13:00 - 14:30 Lunch 14:30 Visit of Vialis From rem-conf Mon Jul 24 05:18:18 2000 From rem-conf-request@es.net Mon Jul 24 05:18:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Gh5i-000093-00; Mon, 24 Jul 2000 05:12:14 -0700 Received: from utrhcs.cs.utwente.nl [130.89.10.247] by mail1.es.net with esmtp (Exim 1.81 #2) id 13Gh5d-00008M-00; Mon, 24 Jul 2000 05:12:09 -0700 Received: from zeus.cs.utwente.nl (zeus.cs.utwente.nl [130.89.10.12]) by utrhcs.cs.utwente.nl (8.9.3/8.9.3) with ESMTP id OAA14661; Mon, 24 Jul 2000 14:11:49 +0200 (MET DST) Received: from cs.utwente.nl by zeus.cs.utwente.nl (8.8.8+Sun/csrelay-Sol1.4/RB) id OAA25178; Mon, 24 Jul 2000 14:09:01 +0200 (MET DST) Message-ID: <397C31DD.F9A6A548@cs.utwente.nl> Date: Mon, 24 Jul 2000 14:09:01 +0200 From: Clever Ricardo Guareis de Farias Organization: CTIT - Centre for Telematics and Information Technology X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Subject: IDMS 2000: Call for Participation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list [Our apologies if you receive multiple copies of this Announcement] Announcement and Call for Participation IDMS 2000 7th International Workshop on Interactive Distributed Multimedia Systems and Telecommunication Services CTIT/Univ. of Twente, Enschede, the Netherlands October 17-20, 2000 http://www.ctit.utwente.nl/Docs/news/idms_2000.htm In cooperation with ACM SIGCOMM and SIGMM Sponsored by KPN Research, Lucent Technologies and Philips After past successful IDMS workshops held in Stuttgart, Hamburg, Berlin, Darmstadt, Oslo, and Toulouse, the 7th IDMS workshop --IDMS 2000-- will be held in Enschede, the Netherlands. We cordially invite you to participate in this workshop. The goal of the IDMS series of workshops is to bring together researchers, developers, and practitioners from academia and industry; and to provide a forum for discussion, presentation, and exploration of technologies and advances in the broad field of interactive distributed multimedia systems and telecommunication services. Topics covered in IDMS workshops range from basic system technologies such as networking and operating system support to all kinds of teleservices and distributed multimedia applications. WORKSHOP HIGHLIGHTS IDMS 2000 consists of a full day of tutorials, a three days technical program, and demonstrations during the workshop. The tutorial day offers three tutorials from leading researchers and practioners: T1: "Scalability issues in CORBA-based systems" Steve Vinoski, IONA Technologies T2: "IP telephony" Ralf Steinmetz, Darmstadt Univ. of Technology and GMD IPSI Ralf Ackermann, Darmstadt Univ. of Technology T3: "Scalable multimedia servers" B. Prabhakaran, National Univ. of Singapore The technical program is single-track, with three invited presentations from top experts in their field, and seven paper sessions. Invited presentations: P1: "Energy-efficient hand-held multimedia systems" Gerard Smit, Univ. of Twente P2: "Short-range connectivity with Bluetooth" Jaap Haartsen, Ericsson P3: "On the failure of middleware to support multimedia applications" Gordon Blair, Univ. of Lancaster Paper sessions: S1: Efficient audio/video coding and delivery S2: Multimedia conferencing, synchronization and multicast S3: Communication, control and telephony over IP networks S4: QoS models and architectures S5: Multimedia applications and user aspects S6: Design and implementation approaches S7: Mobile multimedia and ubiquitous computing systems Details on the program are available at: http://www.ctit.utwente.nl/Docs/news/idms_2000.htm VENUE The workshop will be held on the campus of the University of Twente, Enschede, the Netherlands. Enschede is a pleasant and relatively small city in the east part of the Netherlands, close to the German border. Enschede's convenient geographical location accounts for its important role in the economy of the region. The University of Twente is one of the three technical universities and the only real campus university in the Netherlands. While the landscape of Twente in general is renowned for its beauty, the university campus is probably the loveliest 146 ha of the whole region. The forested campus, embellished with modern architecture, forms a unique environment for student life, sports and study. Details on the venue, accommodation and travel information are available at: http://www.ctit.utwente.nl/Docs/news/idms_2000.htm REGISTRATION Registration should be done using the forms available at the website: http://www.ctit.utwente.nl/Docs/news/idms_2000.htm Important dates for registration: On or before Sept. 15, 2000: Discount on registration fees After Sept. 15, 2000: Regular registration fees We look forward to seeing you at IDMS 2000. From rem-conf Mon Jul 24 13:39:24 2000 From rem-conf-request@es.net Mon Jul 24 13:39:23 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13GorE-0006Zg-00; Mon, 24 Jul 2000 13:29:48 -0700 Received: from east.isi.edu [38.245.76.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 13GorC-0006ZU-00; Mon, 24 Jul 2000 13:29:46 -0700 Received: from hafez.east.isi.edu (hafez.east.isi.edu [38.245.76.121]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id QAA20736; Mon, 24 Jul 2000 16:30:05 -0400 (EDT) Received: from hafez.east.isi.edu (localhost [127.0.0.1]) by hafez.east.isi.edu (8.9.3/8.8.7) with ESMTP id BAA03226; Tue, 25 Jul 2000 01:29:39 +0500 Message-Id: <200007242029.BAA03226@hafez.east.isi.edu> To: rem-conf@es.net Subject: AVT agenda for Pittsburgh cc: agenda@ietf.org Date: Mon, 24 Jul 2000 16:29:39 -0400 From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Attached is the AVT agenda for the Pittsburgh IETF meeting. Colin ------------------------------------------------------------------------------ Audio/Video Transport Working Group Agenda Wednesday 2nd August 2000, 09:00-11:30 ====================================== - Introduction and status update (Casner/Perkins) 20 - Applicability of RFC2429 to H.263++ (Wenger) 5 - Enhancements to IP/UDP/RTP Header Compression (Koren) 5 draft-ietf-avt-crtp-enhance-00.txt - A LightWeight IP Encapsulation (LIPE) Scheme (Chuah) 10 draft-chuah-avt-lipe-01.txt - IP/UDP/RTP Header Compression over AAL2 (Koren) draft-buffam-avt-crtp-over-aal2-00.txt - RTCP reporting extensions (Friedman) 20 draft-friedman-avt-rtcp-report-extns-01.txt - RTP Profile for RTCP-based Retransmission Request for Unicast session 10 draft-ietf-avt-rtprx-00.txt (Yano) - RTP Payload Format to Enable Multiple Selective Retransmissions draft-miyazaki-avt-rtp-selret-01.txt (Burmeister) 10 - RTCP-based Feedback for Predictive Video Coding draft-wenger-avt-rtcp-feedback-00.txt (Wenger) 15 - Low delay RTCP packet format for backward messages draft-fukunaga-low-delay-rtcp-00.txt (Fukunaga) 10 - RTP Payload Format for Generic FEC with ULP (Li) draft-li-avt-ulp-00.txt - An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams draft-lnt-avt-uxp-00.txt (Wimmer) 10 - A More Loss-Tolerant RTP Payload Format for MP3 Audio draft-ietf-avt-rtp-mp3-02.txt (Finlayson) 10 Thursday 3rd August 2000, 13:00-15:00 ===================================== - RTP payload format for AMR Liaison Statement from ETSI SMG2 (Barany) 5 draft-sjoberg-avt-rtp-amr-01.txt (Sjöberg) 5 draft-wimmer-amr-01.txt (Wimmer) 5 draft-fingscheidt-avt-rtp-amr-00.txt Discussion 10 - RTP Payload Format for SMPTE 292M (Gharai) 15 draft-ietf-avt-smpte292-video-00.txt draft-gharai-ac3-01.txt - RTP Payload Format for Distributed Speech Recognition 15 draft-meunier-avt-rtp-dsr-00.txt (Meunier) - RTP Payload Format for SONET over IP 15 http://www.tcb.net/plip/draft-white-sonet-format-rtp-00.txt - Transport of MPEG-4 on IP Introduction (Perkins) 5 draft-ietf-avt-rtp-mpeg4-03.txt (Civanlar) 5 draft-ietf-avt-rtp-mpeg4-es-02.txt (Kikuchi) 5 draft-singer-mpeg4-ip-00.txt (Singer) 20 ------------------------------------------------------------------------------ From rem-conf Tue Jul 25 03:21:14 2000 From rem-conf-request@es.net Tue Jul 25 03:21:11 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13H1dr-0000EB-00; Tue, 25 Jul 2000 03:08:51 -0700 Received: from dns.cowan.edu.au [139.230.128.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 13H1do-0000E1-00; Tue, 25 Jul 2000 03:08:49 -0700 Received: from cowan.edu.au (gmao@fovea.fste.ac.cowan.edu.au [139.230.147.162]) by dns.cowan.edu.au (8.8.8/8.8.8) with ESMTP id SAA23130 for ; Tue, 25 Jul 2000 18:08:44 +0800 (WST) Sender: gmao@dns.cowan.edu.au Message-ID: <397D68B2.9DDE630E@cowan.edu.au> Date: Tue, 25 Jul 2000 10:15:14 +0000 From: Guoqiang Mao Reply-To: G.Mao@cowan.edu.au Organization: Edith Cowan University X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.15 i686) X-Accept-Language: en, zh-CN MIME-Version: 1.0 To: rem-conf@es.net Subject: request for video trace files Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Audio/Video Transport maillis users, I am a graduate student at Edith Cowan University, Australia. I am now doing some research on QoS analysis for real-time transport of video traffic through ATM network. I need some video traffic files for my simulation study. I have got Starwar files from the web. But I need more such files for the study of heterogeneous video traffic case. Is there any one can tell me where I can get more video traffic files? Your help will be appreciated. Best regards, Guoqiang -- Guoqiang Mao School of Engineering and Mathematics Edith Cowan University 100 Joondalup Dr., Joondalup Western Australia 6027 Tel: +61 8 94005318 Fax: +61 8 94005811 From rem-conf Wed Jul 26 02:49:36 2000 From rem-conf-request@es.net Wed Jul 26 02:49:35 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13HNfr-0006CG-00; Wed, 26 Jul 2000 02:40:23 -0700 Received: from (multitech.co.in) [202.54.39.98] by mail1.es.net with esmtp (Exim 1.81 #2) id 13HNfo-0006C2-00; Wed, 26 Jul 2000 02:40:21 -0700 Received: from multitech.co.in [192.168.1.61] by multitech.co.in [127.0.0.1] with SMTP (MDaemon.v3.0.2.R) for ; Wed, 26 Jul 2000 15:11:17 +0530 Message-ID: <397EB1F0.61DC364E@multitech.co.in> Date: Wed, 26 Jul 2000 15:10:00 +0530 From: "Prabha.N" X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: rem-conf@es.net Subject: New Member Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: rem-conf@es.net X-Return-Path: prabhan@multitech.co.in X-MDRcpt-To: rem-conf@es.net X-MDRemoteIP: 192.168.1.61 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello, I have doubts regarding RTP and RTCP. Can i post my messages here. Regards, Prabha From rem-conf Wed Jul 26 03:22:52 2000 From rem-conf-request@es.net Wed Jul 26 03:22:52 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13HOCS-0007Kb-00; Wed, 26 Jul 2000 03:14:04 -0700 Received: from (redball.dynamicsoft.com) [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13HOCQ-0007KR-00; Wed, 26 Jul 2000 03:14:02 -0700 Received: from dynamicsoft.com (1Cust52.tnt5.freehold.nj.da.uu.net [63.36.113.52]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA17017; Wed, 26 Jul 2000 06:15:19 -0400 (EDT) Message-ID: <397EBAD3.D29C196D@dynamicsoft.com> Date: Wed, 26 Jul 2000 06:17:55 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Prabha.N" CC: rem-conf@es.net Subject: Re: New Member References: <397EB1F0.61DC364E@multitech.co.in> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list yes. -Jonathan R. "Prabha.N" wrote: > > Hello, > I have doubts regarding RTP and RTCP. Can i post my messages here. > > Regards, > Prabha -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Wed Jul 26 10:36:13 2000 From rem-conf-request@es.net Wed Jul 26 10:36:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13HV1V-0004I8-00; Wed, 26 Jul 2000 10:31:13 -0700 Received: from (cd-writer) [212.140.94.96] by mail1.es.net with smtp (Exim 1.81 #2) id 13HV1N-0004Hi-00; Wed, 26 Jul 2000 10:31:08 -0700 From: To: Message-Id: <419.436733.76843299b-v-ltd@lycos.com> Subject: BRAND NEW CARS FROM 23 POUNDS PW Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: Wed, 26 Jul 2000 10:31:08 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A BRAND NEW CAR FROM 23 POUNDS PER WEEK xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx LIMITED OFFERS CALL OUR SALES HOTLINE 0808 100 2784 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx SPECIAL OFFER SPECIAL OFFER SPECIAL OFFER SPECIAL OFFER CANCELLED ORDERS :- ONLY 4 CARS LEFT IMMEDIATE DELIVERY MERCEDES ML320 AUTOS 459 POUNDS PCM INCLUDES METALLIC PAINT LUX PACK FULLY LOADED TO A VERY HIGH SPEC xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx FREE PHONE 0808 100 2784 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ********************************************** PORSCHE BOXSTERS FROM £399 BMW 1.8 Z3 (Roadster 2 Year Deal 10,000 pa) £249.00 Mercedes-Benz M-class ML320 5DR Estate 3.2 Auto £399.00 Mercedes-Benz SL320 2dr Convertible 3.2 Auto £599.00 Volvo 2.4 4dr Saloon (140bhp) £299.00 Mercedes-Benz SLK 230 Komp 2dr Convertible 2.3 (197bhp) Silver Brabas Kit, 18" Alloys Privacy Glass Front & Rear Spoiler £499.00 Mercedes-Benz SLK 200 ROADSTER 2dr Convertible 2.3 £325.00 Mercedes-Benz A Class 5dr £225.00 VW GOLF Cabriolet 1.8S £249.00 Renault Megane Sport Alize 2dr Cab 1.6 16v with Air Con, Power Hood, Alloy Wheels £249.00 Renault Laguna 1.6 RT 16v 5dr £175.00 Peugeot 306 1.8S Cabriolet £249.00 Peugeot 306 2.0SE Cabriolet £285.00 Peugeot 206 GTI 2.0 16V 137 BHP  Multi Point Injection Air con, 15"Foudre Alloys, Suede Trim, CD/Radio, ABS, Power Windows, C/Locking, Alarm, Deadlocks £199.00 Peugeot 206 1.1L 3DR £145.00 Peugeot 406 Rapier HDI EST Digital Air con, Alloy Wheels, CD/Radio, ABS, Metallic Paint, Electric Mirrors, Power Windows, C/Locking, Auto Wipers, Dual Air Bag, Deadlocks £197.00 Peugeot 806 MPV 7 Seat ( T Reg ) £229.00 Nissan Micra 1.0 3DR £99.00 Porsche Boxster 2.7 Convertible £399.00 Alfa Romeo 156 1.8 Twin Spark 16 VALVE 4 DR £279.00 Vectra 1.8ls 5dr A/C V REG £156.00 Citroen Xsara 1.4LX 5dr £156.00 BMW 3 Series 1.9 Saloon £295.00 Audi A3 £225.00 Toyota RAV 4 REEBOK 3DR Alloys, CD, Rear Spoiler Wheel Arch Ext, Wheel Cover Plus Power Sunroof And Choice Of Met Paint £228.00 ********************************************** Initial deposit plus 35 monthly payments, + VAT,10000mpa E&OE For a Personal Quotation On The Car Of Your ChosePlease Phone Free On 0808 100 2784 This email has been sent electronically and we apologize for any unsolicited mail sent. If you require us to remove your email address please click on the web page provided http://salesbvl.homested.com/files/index.htm and enter you email address in the box provided your email will be removed with in 24 hours. From rem-conf Thu Jul 27 08:24:29 2000 From rem-conf-request@es.net Thu Jul 27 08:24:28 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13HpJs-0001RS-00; Thu, 27 Jul 2000 08:11:32 -0700 Received: from penguin-ext.wise.edt.ericsson.se [194.237.142.110] by mail1.es.net with esmtp (Exim 1.81 #2) id 13HpJr-0001RG-00; Thu, 27 Jul 2000 08:11:31 -0700 Received: from esealnt409.al.sw.ericsson.se (esealnt409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.10.1/8.10.1/WIREfire-1.3) with ESMTP id e6RFBOQ22937 for ; Thu, 27 Jul 2000 17:11:24 +0200 (MEST) Received: from SMTP ([153.88.251.32]) by esealnt409.al.sw.ericsson.se with Microsoft SMTPSVC(5.0.2172.1); Thu, 27 Jul 2000 17:11:24 +0200 Received: from esealnt743.al.sw.ericsson.se ([153.88.251.13]) by 153.88.251.32 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 27 Jul 2000 15:11:23 0000 (GMT) Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 27 Jul 2000 17:11:22 +0200 Message-ID: <5E5172B4DE05D311B3AB0008C75DA941019EF67A@edeacnt100.eed.ericsson.se> From: "Michael Meyer (EED)" To: "'rem-conf@es.net'" Subject: Question on draft-ietf-avt-rtp-new-08 Date: Thu, 27 Jul 2000 17:11:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFF7DC.E9300F50" X-OriginalArrivalTime: 27 Jul 2000 15:11:24.0013 (UTC) FILETIME=[ED8F71D0:01BFF7DC] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list 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_000_01BFF7DC.E9300F50 Content-Type: text/plain; charset="ISO-8859-1" Hi, I do not know whether this issue was discussed here before, but I believe the description for the RTCP transmission interval in section 6.3.1 bullet 1. is incomplete. In the upper part of 6.3.1 for the senders the average RTCP message size is considered to calculate the constant C, while this is not done in the last sentence for all members. Shouldn't it be in the last sentence: The constant C is set to the average RTCP packet size divided by the total RTCP bandwidth ? Best regards /Michael <> ------_=_NextPart_000_01BFF7DC.E9300F50 Content-Type: application/octet-stream; name="Michael Meyer (E-mail).vcf" Content-Disposition: attachment; filename="Michael Meyer (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Meyer;Michael;; FN:Michael Meyer (E-mail) ORG:Ericsson Eurolab Deutschland - EED/R/N; TITLE: TEL;WORK;VOICE:+49 2407 575 654 TEL;WORK;FAX:+49 2407 575 400 ADR;WORK:;;Ericsson Allee 1;52134 Herzogenrath;Germany;; LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Ericsson Allee 1=0D=0A52134 Herzogenrath, Germany =0D=0A EMAIL;PREF;INTERNET:eedmme@eed.ericsson.se REV:20000111T171632Z END:VCARD ------_=_NextPart_000_01BFF7DC.E9300F50-- From rem-conf Thu Jul 27 10:47:00 2000 From rem-conf-request@es.net Thu Jul 27 10:46:59 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13HrfV-0003c3-00; Thu, 27 Jul 2000 10:42:01 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13HrfT-0003bt-00; Thu, 27 Jul 2000 10:42:00 -0700 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id KAA05444 for ; Thu, 27 Jul 2000 10:41:57 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Thu, 27 Jul 2000 10:41:57 -0700 Received: from [17.202.37.250] (il0203a-dhcp122.apple.com [17.202.37.250]) by scv1.apple.com (8.9.3/8.9.3) with ESMTP id KAA15581; Thu, 27 Jul 2000 10:41:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: kmarks@mail.apple.com Message-Id: In-Reply-To: <200007180120.AA06839@metronet.com> References: <200007180120.AA06839@metronet.com> Date: Thu, 27 Jul 2000 00:33:07 -0700 To: "Timothy G. McGrath" , rem-conf@es.net From: Kevin Marks Subject: Re: Looking for H261/H263 Codecs for Windows Cc: tmcgrath@metronet.com (Tim McGrath) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 8:20 PM -0500 7/17/00, Timothy G. McGrath wrote: >Does anybody know of or can recommend commercial/freeware h.261/h.263 >codecs for MS Windows (9x and NT platforms). I need to use one of these in >a custom application which compresses streaming video over >RTP. Unfortunately, the compressors installed with Netmeeting don't appear >to be usable outside of that particular app. > >I've found a handful of ancient, freeware codecs on the net, but I don't >have the time to re-engineer these according to recent standards. Ideally, >I'd like to find compressors which are written to conform to the MS Video >Compressor DDK specifications, but I'll take any API as long it's simple to >use and well-documented. Both are included in QuickTime, and the API is well-documented with sample code. From rem-conf Thu Jul 27 15:02:52 2000 From rem-conf-request@es.net Thu Jul 27 15:02:51 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13Hvcu-0006vo-00; Thu, 27 Jul 2000 14:55:36 -0700 Received: from mail.ecsoft.no (ecsoft.no) [193.216.108.195] by mail1.es.net with smtp (Exim 1.81 #2) id 13Hvcs-0006ve-00; Thu, 27 Jul 2000 14:55:34 -0700 Received: from 1tz75ipam ([32.100.170.83]) by ecsoft.no (Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) with SMTP id C125692A.00735929; Thu, 27 Jul 2000 23:54:39 +0200 DATE: 27 Jul 00 5:04:25 PM FROM: MUm51McaP@spammit.com Message-ID: SUBJECT: WAZZZUUUUPPPPPP? Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Build a residual income from time you spend on the Internet placing FREE advertisements like this. Successful Internet company wants you to help them market their products and services online. Place FREE pre-written ads and get paid commissions on any sales that you bring to the company. A FREE Web Site, and complete training and instructions will be provided to you. To Register with the program and to begin receiving instructions, simply mailto:myclub@england.com?subject=RegisterMe AND INSERT YOUR FIRST AND LAST NAME AS TEXT to be removed from this list mailto:eatyourspam@china.com?subject=remove From rem-conf Thu Jul 27 22:46:05 2000 From rem-conf-request@es.net Thu Jul 27 22:46:04 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13I2qu-0004pu-00; Thu, 27 Jul 2000 22:38:32 -0700 Received: from (redball.dynamicsoft.com) [216.173.40.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 13I2qs-0004pK-00; Thu, 27 Jul 2000 22:38:30 -0700 Received: from dynamicsoft.com (1Cust16.tnt3.freehold.nj.da.uu.net [63.25.172.16]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01227; Fri, 28 Jul 2000 01:40:00 -0400 (EDT) Message-ID: <39811D59.D6ED7980@dynamicsoft.com> Date: Fri, 28 Jul 2000 01:42:49 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Michael Meyer (EED)" CC: "'rem-conf@es.net'" Subject: Re: Question on draft-ietf-avt-rtp-new-08 References: <5E5172B4DE05D311B3AB0008C75DA941019EF67A@edeacnt100.eed.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list "Michael Meyer (EED)" wrote: > > Hi, > > I do not know whether this issue was discussed here before, but I believe the description for the RTCP transmission interval in section 6.3.1 bullet 1. is incomplete. > > In the upper part of 6.3.1 for the senders the average RTCP message size is considered to calculate the constant C, while this is not done in the last sentence for all members. > > Shouldn't it be in the last sentence: The constant C is set to the average RTCP packet size divided by the total RTCP bandwidth ? Yes, I believe you are correct. The units of C are time, and so setting it only to the RTCP bandwidth is wrong based on that alone. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From rem-conf Sat Jul 29 00:51:27 2000 From rem-conf-request@es.net Sat Jul 29 00:51:26 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13IR8a-0003Pw-00; Sat, 29 Jul 2000 00:34:24 -0700 Received: from mailout3.hananet.net [210.220.163.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 13IR8Y-0003Pm-00; Sat, 29 Jul 2000 00:34:22 -0700 Received: from in vi ([211.117.252.227]) by mailout3.hananet.net (Netscape Messaging Server 4.15) with ESMTP id FYG7OY02.K27; Sat, 29 Jul 2000 16:34:10 +0900 From: "James Park" Subject: See-through digital camera To: 1@es.net X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Date: Sat, 29 Jul 2000 16:27:00 +0900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Ladies and Gentlemen ; This message is only for =A1=AERegional Distributor=A1=AF candidates If this letter is wrong-directed, please accept our apology and simply discard this=2E Thank you=2E We're a major developer of 'Vision (Optics, Infrared)' related products in Korea=2E And this is to introduce our new ' Digital Camera' which is equipped with super outstanding infrared functions=2E While adopting features of Standard Digital Camera , we were able to bring the technology into this machine so that the ultimate fantasy of advanced camera could be achieved=2E 1=2E See-through function : More than double penetration than that of 'SXXX Night Shot' which once created a big boom even though it was a rather blurry Black & white=2E 2=2E Color image even though it=A1=AFs see-through : Allows more vivid natural image=2E 3=2E Night-eye Function : Equipped with Infrared self-transmitting system enables to catch the black&white image up to 6M even under darkroom situation=2E Please take a look at some of pictures at http://myhome=2Eshinbiro=2Ecom/~invitech/ ( Please, do not mis-guided of the infrared see-through technology by the picture of woman in swimsuit=2E We included this picture only because to emphasize the visual effects=2E And the woman agreed and paid later on=2E) Parties acknowledging a great marketability of this product are invited to join our distributors=A1=AF network=2E Especially those who run their own web shopping malls (say, engaged in 'Adult Entertainment Products') and/or have sizable customer (DM marketing) groups are most welcomed=2E The regional distributors are going to have good chances to be benefited by being given the opportunities distributing other smart infrared products in a queue following this digital camera=2E That makes it all for now, many thanks for your precious time and looking forward to hearing from you=2E Please email to kespbg@kebi=2Ecom Sincerely, James Park Sales Manager Tel : 82-31-909-8300 Fax : 82-31-909-8308 From rem-conf Sat Jul 29 09:45:13 2000 From rem-conf-request@es.net Sat Jul 29 09:45:12 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13IZUq-0000jv-00; Sat, 29 Jul 2000 09:29:56 -0700 Received: from max1-3.newyork.corecomm.net (altavistausa.com) [209.81.238.131] by mail1.es.net with smtp (Exim 1.81 #2) id 13IZUi-0000jO-00; Sat, 29 Jul 2000 09:29:49 -0700 From: Subject: Re: From Lorraine,as promised,I can lower your bill! Date: Sat, 29 Jul 2000 13:26:09 Message-Id: <325.845909.356424@altavistausa.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Untitled Document


Today, everyone knows the impact of the Internet.
But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31    Saudi Arabia $.59     Denmark $.04      Sweden $.05

Click Here Now.

If you do not have flash please go to
www.macromedia.com
to download it.

From rem-conf Sat Jul 29 10:54:17 2000 From rem-conf-request@es.net Sat Jul 29 10:54:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13IafJ-0002Rt-00; Sat, 29 Jul 2000 10:44:49 -0700 Received: from max1-3.newyork.corecomm.net (altavistausa.com) [209.81.238.131] by mail1.es.net with smtp (Exim 1.81 #2) id 13IafH-0002Rj-00; Sat, 29 Jul 2000 10:44:47 -0700 From: Subject: From Lorraine,as promised,I can lower your bill Date: Sat, 29 Jul 2000 14:41:07 Message-Id: <330.426607.850681@altavistausa.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Untitled Document


Today, everyone knows the impact of the Internet.
But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31    Saudi Arabia $.59     Denmark $.04      Sweden $.05

Click Here Now.

If you do not have flash please go to
www.macromedia.com
to download it.

From rem-conf Sun Jul 30 00:28:22 2000 From rem-conf-request@es.net Sun Jul 30 00:28:22 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13InOY-00023V-00; Sun, 30 Jul 2000 00:20:22 -0700 Received: from ip125.tucson4.az.pub-ip.psi.net (cameronm) [38.29.64.125] by mail1.es.net with smtp (Exim 1.81 #2) id 13InOS-00020E-00; Sun, 30 Jul 2000 00:20:17 -0700 Message-Id: From: r_5rem@excite.com Bcc: Date: Sun, 30 Jul 2000 00:20:17 -0700 To: rem-conf@es.net Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list BAD CREDIT/GOOD CREDIT..... WE CAN HELP! GET YOUR FREE MORTGAGE QUOTE TODAY ON LINE WITH IN MINUTES....LET THE MORTGAGE COMPANIES COMPETE FOR YOUR BUSINESS! PURCHASE $$$ AVAILBLE ALSO CLICK HERE FOR FAST ON LINE APPLICATION: http://www.mortgagequotetodayonline.com From rem-conf Mon Jul 31 01:57:17 2000 From rem-conf-request@es.net Mon Jul 31 01:57:15 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13JBDh-0001MM-00; Mon, 31 Jul 2000 01:46:45 -0700 Received: from (mail.nnet.net) [198.165.204.69] by mail1.es.net with smtp (Exim 1.81 #2) id 13JBDb-0001Li-00; Mon, 31 Jul 2000 01:46:40 -0700 Received: from 208.137.132.158 [208.137.132.158] by mail.nnet.net (SMTPD32-4.03) id A25E14A3009A; Mon, 31 Jul 2000 00:58:30 +03d00 From: Jpz44@aol.com To: MNP31@aol.com Subject: 3.95% 30 Yr. / 4.95% 40 Yr. Mortgages! Date: Sun, 30 Jul 00 23:24:12 Eastern Daylight Time Reply-To: Jpz44@aol.com X-Priority: 3 X-MSMailPriority: Normal Importance: Normal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_018C_01BD9940.715D52A0" Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_018C_01BD9940.715D52A0 Content-Type: text/html; 3.95% 30 Year / 4.95% 40 Year Mortgages Now Available!

Loans from $50,000 to $1,500,000.00.

NO Penalty for early payoff.

Self-Employed and can't show income? NO PROBLEM!!

Go to www.debtfreehome.com for more information and to apply.



* In compliance with the proposed legislation for commercial e-mail,
we are providing Contact http://www.debtfreehome.com/contact.html and
remove@debtfreehome.comlinks. Requests sent to the Remove link
(and the Remove link ONLY) will immediately stop further transmissions
of this message at no cost to you.





 From rem-conf Mon Jul 31 07:45:18 2000 From rem-conf-request@es.net Mon Jul 31 07:45:16 2000 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 13JGh7-0005Ut-00; Mon, 31 Jul 2000 07:37:29 -0700 Received: from c017-h014.c017.sfo.cp.net (c017.sfo.cp.net) [209.228.12.228] by mail1.es.net with smtp (Exim 1.81 #2) id 13JGh5-0005UL-00; Mon, 31 Jul 2000 07:37:27 -0700 Received: (cpmta 13699 invoked from network); 31 Jul 2000 07:36:26 -0700 Received: from dns.packetdesign.net (HELO mailman.packetdesign.com) (216.15.46.10) by smtp.packetdesign.com with SMTP; 31 Jul 2000 07:36:26 -0700 X-Sent: 31 Jul 2000 14:36:26 GMT Received: from localhost ([192.168.0.254]) by mailman.packetdesign.com (8.9.3/8.9.3) with ESMTP id HAA19060; Mon, 31 Jul 2000 07:36:03 -0700 (PDT) (envelope-from casner@acm.org) Date: Mon, 31 Jul 2000 07:39:13 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net Subject: New congestion control text in RTP spec Message-ID: Sender: casner@packetdesign.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the AVT working group: I'd like to call your attention, for both those who are here at IETF and those who are not, to the new sections on congestion control that were added to the recent revisions of the RTP spec and profile drafts as a result of the discussion at the last IETF: draft-ietf-avt-rtp-new-08.txt / .ps draft-ietf-avt-profile-new-09.txt / .ps In the RTP spec, the congestion control discussion is in a new Section 10, with references in Sections 6 and 13. It simply establishes the requirement for congestion control in RTP, and defers definition of any specific behaviors to profiles because they are context-specific. In the profile, a new "Congestion" item was added in Section 2 using the text that Mark Handley provided in response to my request at the last IETF meeting. Again, the requirements are described only in general terms because specific algorithms have not been devised yet for multicast congestion control. ---> Is this text in both documents appropriate and sufficient? -- Steve