From rem-conf Sat Aug 01 01:59:14 1998 From rem-conf-request@es.net Sat Aug 01 01:59:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z2XNI-0005uT-00; Sat, 1 Aug 1998 01:50:48 -0700 Received: from (fsnt.future.futsoft.com) [38.242.192.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z2XNF-0005tQ-00; Sat, 1 Aug 1998 01:50:46 -0700 Received: from kailash.future.futsoft.com (unverified [38.242.192.4]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Sat, 01 Aug 1998 14:14:26 +0530 Received: from msgate.future.futsoft.com (msgate.future.futsoft.com [10.0.8.4]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id NAA25616; Sat, 1 Aug 1998 13:28:32 +0530 Received: by msgate.future.futsoft.com with Microsoft Mail id <35C386A7@msgate.future.futsoft.com>; Sat, 01 Aug 98 14:20:39 PDT From: vishwas To: "'rem-conf@es.net'" Cc: "'mbone-na@ISI.EDU'" Subject: Problem interop Linux <-> CISCO2503 Date: Sat, 01 Aug 98 14:09:00 PDT Message-Id: <35C386A7@msgate.future.futsoft.com> Encoding: 14 TEXT X-Mailer: Microsoft Mail V3.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, I am running DVMRP between Linux1.2.1 over a Serial Interface using slattach with SLIP encapsulation. But now I have to test my setup with a cisco box 2503 IOS 11.2. I am unable to bring the Line protocol UP on the cisco box over the serial interface. I tried Sync, Async and almost all possibilities. Since cisco 2503 has one ethernet and two serial interfaces, my testing is halted as I am unsuccessful in configuring SLIP on cisco serial interfaces. I dont want to try PPP encapsulation right now. Can any body help me in configuring SLIP on CISCO to bring up the line protocol up. Regards vishwa From rem-conf Sun Aug 02 01:54:12 1998 From rem-conf-request@es.net Sun Aug 02 01:54:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z2taY-0007VY-00; Sun, 2 Aug 1998 01:33:58 -0700 Received: from dyn208-28-52-194.win.mnsi.net (MNSi.net) [208.28.52.194] by mail1.es.net with smtp (Exim 1.81 #2) id 0z2taN-0007Tz-00; Sun, 2 Aug 1998 01:33:49 -0700 To: From: Subject: 175 channels of Satellite TV costs less than standard cable. Date: Sun, 2 Aug 1998 00:58:35 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <><><><><><><><><><><><><><><><><><><><><><><><><><> <>DIGITAL SATELLITE TV FOR LESS THAN REGULAR CABLE<> <> INCLUDING ALL ADULT, SPORTS, MOVIE, AND PPV <> <><><><><><><><><><><><><><><><><><><><><><><><><><> More than 175 channels of Digital Satellite TV, legally, for less than you are paying for regular cable. Three 24 hour XXX adult networks. Every single college and professional sporting event. 100's of movie choices per day. Unlimited FREE pay per views. All channels in digital SVHS picture and CD quality sound. There are no extra costs. Dish, receiver, and guaranteed 'test' device are all included. <><><><><><><><><><><><><> <>CONSIDER THESE FACTS. <> <><><><><><><><><><><><><> 1) 'Test devices' allow you to 'test' (receive) every single DSS satellite channel available for FREE. 2) It is legal to use 'test' devices world wide and legal to sell them outside of the US. 3) The DSS system (SKY in Europe) has always allowed 'testing' and always will, because of a fundamental design error. 4) DSS (Digital Satellite Systems) are cheaper than ever and can be purchased for as little as $50. 5) The Satellite Freedom Guide is only $5 and there is a money back guarantee. 6) You can call POWER2PEOPLE in Canada at 1-519-258-3754. POWER2PEOPLE has been following the DSS 'testing' scene for 4 years. Our Satellite Freedom Guide completely describes everything you need to know, step by step, to get over 175 channels for less than you are paying for cable right now. Upgrading from cable to full access satellite TV while saving money sounds too good to be true, but it is true and guaranteed. If you are interested, read on, if not please forward this email to friends. We are not in the business of selling 'test' devices or satellite systems. Our goal is to spread accurate and easy to understand instructions on how to get up and 'testing' as quickly, safely, and inexpensively as possible. You can start enjoying all possible DSS broadcasts within a week of receiving our guidebook. It is completely legal because you are 'testing' the function of your satellite hardware. There are over 175 channels in digital sound and picture and if you have never seen the system, go to your local audio video retailer and prepare to be amazed. Select from hundreds of FREE movie choices every day. You get unlimited FREE Pay Per View's from over 100 selections per month. These are new movies and special events such as concerts and sports spectaculars. There are also three 24 hour soft and hard core adult networks. Beyond enjoying Satellite TV, you will learn how to start 'cloning cards' for profit. It is easy. You will supply your customers with what they want; TV that is FREE, with ultimate selection and better picture & sound than they have ever seen. Receiving every possible broadcast for FREE by 'testing' is truly incredible and improves your television experience in every way. THE SATELLITE FREEDOM GUIDE MAKES YOU A 'TESTING' EXPERT BY DESCRIBING EVERYTHING YOU NEED TO KNOW STEP BY STEP, INCLUDING: - What we would do if we were you and wanted to buy a 'test' device that was cheap, trouble free, and guaranteed. - All 'test' devices described: DDT's, B,L,T cards, emulators, combo cards, plastic cards, wedge cards, 3m cards etc. - Circuit schematics to build your own DDT card. - Full instructions to start 'cloning' & selling 'test' cards. - Full cloning hardware, software, and methods described. - Why test devices go down and why they always come back up. - ECM's (electronic counter measure) and how to avoid them. - How to deal with the satellite companies to get the most out of 'testing'. - A full guide to 'test device' manufacturers. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <>POWER2PEOPLE WANTS YOU TO STOP PAYING FOR SOFTWARE TODAY<> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Be aware of the truth that ALL popular software is easily downloadable from moving sites on the Internet. This includes virtually every game and 95% of applications. These are not shareware or crippled versions, but fully working copies. Formerly this practice was very complex and required specific and continually changing computer expertise. That is over. Because of the explosion of the web, the method has become so straight forward that anybody can do it with the right information. Please stop paying for software immediately. Using software without paying for it is obviously illegal but fortunately for those who know how, downloading is 100% safe and easy. POWER2PEOPLE has been following the Internet 'warez' (internet slang for pirated software) scene for over 8 years and we have put all of our knowledge into the Software Freedom Guide. With the Software Freedom Guide in hand, the concept of paying for software becomes laughable. You will quickly begin to download new pirated software every day. This step by step guide describes absolutely everything a beginner needs to know to easily find active 'warez' sites, download, uncompress, and install 'warez' immediately. You will have the resources of experienced software traders, and system administrators at your fingertips. You will learn all about how to use FTP, IRC, and the World Wide Web to find and download any software you want. You will be downloading software before it even reaches your local software retailer. Power2people has also included a new section which fully describes how to make 'backups' of all your PC and Mac CD's, audio CD's, and all Sony Playstation games. All you need is a CD burner, the correct information, and some readily available shareware. Some people even rent software and make 'backups' of them. This is clearly illegal but we will tell you how so you can make your own choice. There is no special computer knowledge required, all instructions are covered. You can call POWER2PEOPLE in Canada at 1-519-258-3754. <><><><><><><><><><><><><><><><><><><><><><><><><><><><><> <>POWER2PEOPLE offers you a way to start bulk emailing <> <>your message to millions for the lowest startup cost. <> <><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Send your message to 60 million email addresses for only $40 with our 'Bulk Email Startup Kit'. True freedom is freedom of speech and you can do it just like we do for the lowest price possible. POWER2PEOPLE will send you the following: 1) 60 million sorted, cleaned email addresses and complete startup information on CD. These lists are great, they are the lists we use. Your CD is not burned until your order arrives thus ensuring you the best lists. 2) Copies of the most powerful bulk mailing software for FREE. Using some of the techniques described in the Software Freedom Guide, we show you exactly how and where to download and register the most powerful bulk mailing software in existence. These are the premier titles in the industry and together these programs sell for over $850.00(US) but you will learn how to download them for FREE. You can become your own mail server(MX) and directly deliver mail or send it through SMTP, these programs have it all and can fully cloak all headers possible. 3) Complete insiders guide to bulk mailing from A-Z including: message creation, list collection, list manipulation, how to maximize speed and minimize detection, legal considerations including the Washington State law, and much more. Just search the web for 'bulk email' and you will see that our offer is the most complete and by far the least expensive on the internet. <><><><><><> <>PRICING <> <><><><><><> Software Freedom Guide - $5 + $3 shipping Satellite Freedom Guide - $5 + $3 shipping Both Guides - $8 + $4 shipping Bulk Email Startup Kit - $40+ $0 shipping Total Freedom (all products)- $45+ $0 shipping <><><><><><><><> <>HOW TO ORDER<> <><><><><><><><> Print out the disclaimer below and sign it. Send it, your postal address and email address, and US funds in the form of personal check, money order, bank draft, or cash to: Software Freedom Guide or Satellite Freedom Guide or Both Guides or Bulk Email Startup Kit or Total Freedom c/o POWER2PEOPLE 110 Eugenie Street West Suite 430 Windsor, Ontario Canada, N8X 4Y6 (Please note that POWER2PEOPLE can not be held liable for any receipt of cash. Postal money orders must be 'international' or your order can not be processed. 21 day wait for personal checks. We can not process orders from Wisconsin residents. The Satellite Freedom Guide applies to DSS type systems only, DirecTV, USSB, and SKY in N. America, S. America, and Europe.) <><><><><><><> <>GUARANTEE <> <><><><><><><> If you are displeased in any way, simply return the Guide(s) to us and we will send you a check for $3.50. We regret that we can not refund shipping and material costs. The 'Bulk Email Startup Kit' and 'Total Freedom' products can not be guaranteed. <><><><><><><><><><><><><><><><><><><><><> <>DISCLAIMER AND LIMITATION OF LIABILITY<> <><><><><><><><><><><><><><><><><><><><><> My signature below indicates my agreement to the following two paragraphs and that I am over 18 years of age. POWER2PEOPLE provides 'information' for educational purposes only. The purchaser is responsible for consulting and adhering to any applicable laws and statutes in their area. POWER2PEOPLE does not endorse, advocate, recommend, advise, support, and shall not be held liable for the breaking of any law. IN NO EVENT WILL POWER2PEOPLE BE LIABLE TO ANY PARTY (i) for any direct, indirect, special, punitive or consequential damages (including, but not limited to, damages for loss of business profits, business interruption, loss of programs or information, and the like), or any other damages arising in any way out of the availability, use, reliance on, or inability to use POWER2PEOPLE or any 'information', regardless of the form of action, whether in contract, tort, or otherwise; or (ii) for any claim attributable to errors, omissions, or other inaccuracies in or destructive properties of any 'information'. From rem-conf Sun Aug 02 15:47:20 1998 From rem-conf-request@es.net Sun Aug 02 15:47:20 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0z36mQ-00044J-00; Sun, 2 Aug 1998 15:39:06 -0700 Received: from omzrelay.mcit.com ([166.37.204.49]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@es.net id 0z36mQ-000443-00; Sun, 2 Aug 1998 15:39:06 -0700 Received: from omta2.mcit.com.mci.com (omta2.mcit.com [166.37.204.3]) by omzrelay.mcit.com (8.8.7/) with ESMTP id RAA31818; Sun, 2 Aug 1998 17:36:17 -0500 (CDT) Received: from sinnreich2 ([166.44.130.195]) by omta2.mcit.com.mci.com (Intermail v3.1 117 241) with SMTP id <19980802223617.ZOOO876@[166.44.130.195]>; Sun, 2 Aug 1998 17:36:17 -0500 From: "Henry Sinnreich" To: "Steven McCanne" , "Brian Smithson" Cc: Subject: RE: First Virtual Corporation / ICAST press release Date: Sun, 2 Aug 1998 17:35:42 -0500 Message-ID: <000d01bdbe65$e1ee3120$c3822ca6@sinnreich2.678.mciw> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <3.0.5.32.19980731153827.0085ad10@pop.cs.berkeley.edu> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I don't recall if Vinay Kumar has made a name for himslef in the MBONE work, but if he turns it into a successful commercial product the more power to him. Henry Sinnreich MCI > -----Original Message----- > From: Steven McCanne [mailto:mccanne@cs.berkeley.edu] > Sent: Friday, July 31, 1998 5:38 PM > To: Brian Smithson > Cc: rem-conf@es.net > Subject: Re: First Virtual Corporation / ICAST press release > > > >Mr. Kumar > >is a pioneer of Internet technology, having lead the team that > architected > >the delivery of multimedia over the Internet, known as the MBone. > > Brian, > > I realize Vinay Kumar set up a web site and wrote a descriptive book about > our research community's work, but I don't recall that he made > any specific > contributions or maintained any leadership roles. Does anyone > else on this > list? > > Steve > > > From rem-conf Sun Aug 02 21:38:47 1998 From rem-conf-request@es.net Sun Aug 02 21:38:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z3CKA-0000d1-00; Sun, 2 Aug 1998 21:34:18 -0700 Received: from send1d.yahoomail.com [205.180.60.48] by mail1.es.net with smtp (Exim 1.81 #2) id 0z3CK9-0000cr-00; Sun, 2 Aug 1998 21:34:17 -0700 Message-ID: <19980803042731.29904.rocketmail@send1d.yahoomail.com> Received: from [202.41.72.102] by send1d; Sun, 02 Aug 1998 21:27:31 PDT Date: Sun, 2 Aug 1998 21:27:31 -0700 (PDT) From: Arkesh Kumar Subject: Re:H.320 Codecs To: rem-conf@es.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi I would like to know if any manufacturer provides a H.320 Codec with an audio stereo pair. With regards, Arkesh _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com From rem-conf Mon Aug 03 09:49:36 1998 From rem-conf-request@es.net Mon Aug 03 09:49:35 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z3Nbk-00065k-00; Mon, 3 Aug 1998 09:37:12 -0700 Received: from zephyr.isi.edu [128.9.160.160] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z3Nbi-00065a-00; Mon, 3 Aug 1998 09:37:11 -0700 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id JAA07361 for ; Mon, 3 Aug 1998 09:37:10 -0700 (PDT) Date: Mon, 3 Aug 1998 09:35:46 -0700 From: braden@ISI.EDU Posted-Date: Mon, 3 Aug 1998 09:35:46 -0700 Message-Id: <199808031635.AA20376@gra.isi.edu> Received: by gra.isi.edu (5.65c/4.0.3-6) id ; Mon, 3 Aug 1998 09:35:46 -0700 To: rem-conf@es.net Subject: RE: First Virtual Corporation / ICAST press release X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list *> > >Mr. Kumar *> > >is a pioneer of Internet technology, having lead the team that *> > architected *> > >the delivery of multimedia over the Internet, known as the MBone. *> > What's going on here? The MBONE was architected by the two Steves: Steve Deering and Steve Casner. Bob Braden From rem-conf Wed Aug 05 11:40:06 1998 From rem-conf-request@es.net Wed Aug 05 11:40:04 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z48Ie-0000SD-00; Wed, 5 Aug 1998 11:28:36 -0700 Received: from server1.ef.se (server1) [194.213.71.130] by mail1.es.net with smtp (Exim 1.81 #2) id 0z48Ic-0000S3-00; Wed, 5 Aug 1998 11:28:34 -0700 Received: by server1 with MERCUR-SMTP/POP3-Server (v2.10) for at Wed, 5 Aug 98 11:33:39 +0100 To: mao6@lsi.usp.br From: mao6@lsi.usp.br (guyrmo) Comments: Authenticated sender is Subject: Low AirFares--Cheaper than Airlines--Free AirFare Alert Service Message-Id: <199808053382NAA28791@deremuv.se> Date: Wed, 5 Aug 98 11:33:39 +0100 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list TravelNews keeps on-line travellers updated on Fare Wars, cruise and vacation specials, and other travel-related news. To enroll in this FREE Email service, please see end of message. Dear Client, Special Preferred AirFares now available by phone.....Airfare outlook for the rest of 1998..... Our Preferred Fares are now available by phone. These special AirFares are lower than the Airlines themselves and lower than travel agencies. We currently offer Preferred Fares with Delta, Northwest, Continental, United, and American (Caribbean only). Call us for the best rates for travel in the US, Canada, the Caribbean, Europe, Central and South America, and more !! 800-672-1672 (9am-6pm EST) ** Fully Bonded Airline Ticket supplier, serving clients worldwide since 1991. ** (rates are discounts off lowest published fare by above carriers, must be purchased at least 7 days in advance and include a Saturday night stay, subject to availability) You'll never pay regular rates again!! 800-672-1672 (9am-6pm EST) Airfare Outlook for 1998......Most airlines continue to report record booking levels which will continue the trend of higher fares that we predicted at the beginning of this year. Even though many carriers did offer sporadic "sales fares", the discounts were generally smaller and the "fare wars" fewer. It is even more important to monitor fares closely during the 2nd half of 1998 and especially important to BUY EARLY !! Remember that low fares for Holiday travel (Labor Day, Thanksgiving, Christmas) are currently available but will no doubt be selling out much sooner this year because demand will be higher. If you wait too long to buy tickets, you could pay up to 50% more. ** Did you know that we have lower fares than on-line booking !! ** ** Most transactions on-line take up to 40 minutes, ours take only 5-10 minutes!! ** 800-672-1672 (9am-6pm EST) TravelNews keeps on-line consumers updated on AirFares, Fare Wars, travel bargains, and other travel-related news. If you would like a subscription to this FREE news service, (no cost involved, all addresses kept confidential, can cancel at anytime, will receive approximately 2-3 brief messages per month) call 919-383-0388 ext 11 DO NOT USE REPLY button !! o v e r K From rem-conf Wed Aug 05 11:56:02 1998 From rem-conf-request@es.net Wed Aug 05 11:56:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z48g0-000157-00; Wed, 5 Aug 1998 11:52:44 -0700 Received: from ihgw2.lucent.com [207.19.48.2] by mail1.es.net with smtp (Exim 1.81 #2) id 0z48fz-00014x-00; Wed, 5 Aug 1998 11:52:43 -0700 Received: from mtgbcs.mt.lucent.com by ihig2.firewall.lucent.com (SMI-8.6/EMS-L sol2) id NAA19322; Wed, 5 Aug 1998 13:41:29 -0500 Received: from lucent.com by mtgbcs.mt.lucent.com (SMI-8.6/EMS-1.4 sol2) id OAA19571; Wed, 5 Aug 1998 14:56:01 -0400 Message-ID: <35C8A9B1.FCE15F68@lucent.com> Date: Wed, 05 Aug 1998 14:51:29 -0400 From: A Rahim Choudhary Organization: Lucent Technologies X-Mailer: Mozilla 4.03 [en]C-EMS-1.3.1 (WinNT; U) MIME-Version: 1.0 To: rem-conf@es.net Subject: request Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please include me in this list. Thanks -- Phone and Fax: 732-957-7776 e-mail: arc@lucent.com Dr. Abdur Rahim Choudhary, Bell Labs, Lucent Technologies, Cross Product Architecture Department, 200 Laurel Avenue, MT-4C-514, Middletown, NJ 07748, USA. From rem-conf Thu Aug 06 17:25:12 1998 From rem-conf-request@es.net Thu Aug 06 17:25:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z4aBl-0000sk-00; Thu, 6 Aug 1998 17:15:21 -0700 Received: from mtiwmhc01.worldnet.att.net [204.127.131.36] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z4aBk-0000rR-00; Thu, 6 Aug 1998 17:15:20 -0700 Received: from brian-murphy ([12.68.156.210]) by mtiwmhc01.worldnet.att.net (InterMail v03.02.03 118 118 102) with SMTP id <19980806204301.CWPT4726@brian-murphy>; Thu, 6 Aug 1998 20:43:01 +0000 To: From: prodmgr@accessig.com Bcc: rboston@tenet.edu, rc42@cornell.edu, rchapman@miranda.umds.ac.uk, rcollins@leif.ucs.mun.ca, rdixon@stargate.acs.ohio-state.edu, rdunbar@trystero.radio.com, rehn@cleo.murdoch.edu.au, rej@yacc.co.uk, rem-conf@es.net, reycla@yahoo.com, rfrisard@iamerica.net, rgardner@charon.mit.edu, rha94001@uconnvm.uconn.edu, rhayden@geekcode.com, rhjj60@email.sps.mot.com, richard.adams@picksys.com, rick.davies@picksys.com, rlc1@cornell.edu, rlevy01@fiu.edu, rlevy01@xlab1.fiu.edu Subject: Cost Effective Services Message-Id: Content-Type: TEXT/PLAIN charset=US-ASCII content-length: 1174 Date: Thu, 6 Aug 1998 20:43:01 +0000 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list August 6, 1998 ============================================================================== COST EFFECTIVE SERVICES ============================================================================== Are you facing programming project that will stretch your budget??? Are you wasting your valuable resources on programming projects??? Our Internal staff performs services at very reasonable prices. * YEAR 2000 UPGRADES * MIGRATION OF APPLICATIONS * DATA CONVERSION * MIGRATE YOUR PICK TO VISUAL BASIC The Access International Group offers you a combination of resources, tools and experience to assist you in your project efforts. Our Proven technology and focus on returning economic benefits to our customers allows you to concentrate on your own business. Many Development Environment, Languages, and Operating Systems supported. For more information please call 973-360-0750 ext. 101, or email us at aftec@accessig.com From rem-conf Thu Aug 06 20:02:00 1998 From rem-conf-request@es.net Thu Aug 06 20:01:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z4cjC-0002ZP-00; Thu, 6 Aug 1998 19:58:02 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0z4cjB-0002ZF-00; Thu, 6 Aug 1998 19:58:01 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Aug 6 22:56:34 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id WAA00058 for ; Thu, 6 Aug 1998 22:56:57 -0400 (EDT) Message-ID: <35CA6C6E.45CEFF7D@dnrc.bell-labs.com> Date: Thu, 06 Aug 1998 22:54:38 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Update of FEC draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, I have just submitted an updated version of the FEC draft to the archives. Until it appears, you can get a copy from: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-fec-03.txt The changes since the previous version are: 1. Recovery of the entire 32 bit timestamp, as agreed at the previous meeting 2. Addition of a header and procedures for Reed Solomon based recovery 3. Textual description of recovery algorithm converted to C for clarity 4. Removal of references to Budge draft (now expired) 5. Clarification on what the f() operator is Comments are most welcome, in particular on the section on R-S codes. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Fri Aug 07 13:06:59 1998 From rem-conf-request@es.net Fri Aug 07 13:06:59 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z4sgF-0005x5-00; Fri, 7 Aug 1998 13:00:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0z4sgE-0005wv-00; Fri, 7 Aug 1998 13:00:02 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Aug 7 15:58:06 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA22245 for ; Fri, 7 Aug 1998 15:58:22 -0400 (EDT) Message-ID: <35CB5BD2.BAEA9E0B@dnrc.bell-labs.com> Date: Fri, 07 Aug 1998 15:56:02 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: New draft available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Folks, Henning an I have just submitted a draft to the archives entitled "Issues with RTP Sampling". It discusses a number of problems we have found with the RTP SSRC sampling algorithm, and proposes simple fixes to all of them. Until the draft appears in the archives, you can pick up copies at: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-rtpsample-00.txt http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-avt-rtpsample-00.ps The PS is better since there are some plots and equations. Comments welcome. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Sat Aug 08 03:27:12 1998 From rem-conf-request@es.net Sat Aug 08 03:27:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z5623-0004fj-00; Sat, 8 Aug 1998 03:15:27 -0700 Received: from lu-s1.zid.khs-linz.ac.at [193.170.96.105] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0z5622-0004fZ-00; Sat, 8 Aug 1998 03:15:26 -0700 Received: from khsa.khs-linz.ac.at (s08haau0.zid.khs-linz.ac.at [193.170.96.98]) by lu-s1.zid.khs-linz.ac.at (8.9.1/8.8.8) with ESMTP id MAA02586; Sat, 8 Aug 1998 12:13:16 +0200 Received: from S08HAAU0/SpoolDir by khsa.khs-linz.ac.at (Mercury 1.43); 8 Aug 98 12:26:50 GMT+1 Received: from SpoolDir by S08HAAU0 (Mercury 1.43); 8 Aug 98 12:26:27 GMT+1 Received: from khsa.khs-linz.ac.at (193.170.98.102) by khsa.khs-linz.ac.at (Mercury 1.43) with ESMTP; 8 Aug 98 12:26:20 GMT+1 Message-ID: <35CC2478.D3D10D71@khsa.khs-linz.ac.at> Date: Sat, 08 Aug 1998 12:12:09 +0200 From: Schahram Dustdar Organization: Center for Informatics, University of Art and Industrial Design X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: mbone@isi.edu, confctrl@isi.edu, rem-conf@es.net CC: Gertjan Hofstede Subject: Mbone questionaire Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by lu-s1.zid.khs-linz.ac.at id MAA02586 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list * Sorry if you receive this mail more than once ! * Dear colleague, We are two researchers working with the MBone-tools since 1993 and are interested in understanding and promoting their usage in an organizational and international context. We would like to ask you for 20 minutes of your time to fill in this questionnaire since you are experts in MBone videoconferencing. We will present the results and mail them to all interested respondents. Please send your answer to gertjan.hofstede@users.info.wau.nl Thank you very much for your cooperation. Schahram Dustdar and Gertjan Hofstede -------------------------------------------------------------------------= ------------- Videoconferencing questionnaire Remarks: Floor control deals with the question of who is allowed to have the temporary monopoly to distribute signals to the other participants (such as audio, video or shared data). Side chatting is private communication between two or more people involved in a videoconference. Personalia 1. How old are you? 2. What is your nationality? 3. Are you female or male? 4. What is your job title? 5. Of how many people are you boss? 6. In what type of organization do you work? (Profit, government, academic, other non-profit) 7. How many videoconferences have you attended within your organization? 8. How many videoconferences have you attended between organizations? 9. How many videoconferences have you initiated? Context=20 1. How well do you usually know your conference partners? (1 very well, 5 not at all) 2. How many participants are usually in the videoconference ? 3. How much time elapses between the call for the videoconference and the actual videoconference? (hours, days, weeks, months) 4. What type of tasks do the videoconferences address ? (1 always .. 5 never) =B7 Group Setup =B7 Brainstorming =B7 Briefing =B7 Discussion =B7 Planning =B7 Negotiation =B7 Evaluation of Project =B7 Try out of technology =B7 Other: ........ 5. Which other applications do you use during a videoconfence? 6. How many time zones does the videoconference usually span? Preparation of a videoconference (Please give a descriptive answer) 1. When and how do you decide on the floor control of audio, video and shared data?=20 2. When and how do you decide on note taking during the videoconference? =20 3. When and how do you decide on the agenda for the meeting?=20 During a videoconference=20 1. Compared to face-to-face meetings, how problematic is concurrent speaking? (1 much more so ... 5 much less so) 2. Compared to face-to-face meetings, how problematic is it to know exactly who is talking at the moment? (1 much more so ... 5 much less so) 3. Is screen space a limiting factor ? (1 very much ... 5 not at all) 4. What monitor size do you use (inches)? 5. Compared to face-to-face meetings, how easy is it to reach agreement in a videoconference? (1 much easier ... 5 much more difficult)=20 6. Compared to face-to-face meetings, how often have you experienced strong "intellectual" disagreement in a videoconference ? (1 much more often .. 5 much less often) 7. Compared to face-to-face meetings, how often have you experienced strong "personal resentment" in a videoconference ? (1 much more often .. 5 much less often) 8. Have you experienced culture clashes using videoconferences? (if yes please explain) In a hypothetical ideal videoconferencing environment, what features would you wish to see (1 very much ... not at all 5:): 1. Would you like to have anonymous features in videoconferencing tools? (eg. In the shared whiteboard) 2. Would you like to have a "speaking meter" in the audio tool in order to measure how long each participant talks? 3. Would you like to allow "side-chatting" in videoconferencing tools? 4. Would you like to have features to keep track of the meeting's progress ? If yes which features?=20 The next three questions are open ended: 5. What features would be needed in order to promote that every participant freely expresses his/her ideas? 6. How do the videoconferencing participants signal the conference chair that they want to say something? =20 7. Would you like to have work-related background information of your conference participants? (such as: which projects is the other person responsible for, to whom does he report, when is the deadline for the project, etc.) If yes, what information ? Conclusion=20 1. Who does the documentation of the minutes? (open?) 2. Are they provided on a web-page afterwards? =20 3. If yes, how long does it take until they appear on the Intranet/Internet? 4. Do you use them after the meeting ? (1 very intensively ... 5 not at all) 5. Reading the minutes afterwards, would you like to play back the 6. audio/video streams of the meeting? 7. In your opinion, what are the main differences between face-to-face meetings and videoconferences?=20 8. In your opinion, what are the main do's and don'ts? 9. In the future, how important will videoconferencing grow to be ? (1 crucial ...5 insignificant) Would you like to receive the results of this questionaire? Thank you very much for your cooperation! -------------------------------------------------------------------------= ----- -- Dr.Schahram Dustdar=20 University of Art and Industrial Design Center for Informatics Services (ZID) Head of Department Hauptplatz 8, A-4010 Linz-Austria/Europe eMail: dustdar@khsa.khs-linz.ac.at Home: http://www.khs-linz.ac.at/~dustdar WWW: http://www.khs-linz.ac.at Tel: XX43-732-7898-260 Fax: XX43-732-783508 -------------------------------------------- Austrian Multimedia National Support Centre=20 for multimedia conferencing support From rem-conf Sun Aug 09 18:12:45 1998 From rem-conf-request@es.net Sun Aug 09 18:12:44 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0z5gJH-0005dn-00; Sun, 9 Aug 1998 17:59:39 -0700 Received: from yukawa.yukawa.kyoto-u.ac.jp ([130.54.107.20]) by mail2.es.net with esmtp (Exim 1.92 #1) for rem-conf@ES.NET id 0z5gJF-0005dd-00; Sun, 9 Aug 1998 17:59:37 -0700 Received: from JPNYITP.yukawa.kyoto-u.ac.jp (jpnyitp.yukawa.kyoto-u.ac.jp [130.54.107.10]) by yukawa.yukawa.kyoto-u.ac.jp (8.9.1+3.0W/3.7W-yukawa) with SMTP id JAA03917; Mon, 10 Aug 1998 09:58:22 +0900 (JST) Date: Mon, 10 Aug 1998 09:58:22 +0900 (JST) Received: from JPNYITP.YUKAWA.KYOTO-U.AC.JP by JPNYITP.yukawa.kyoto-u.ac.jp (IBM VM SMTP V2R2) with BSMTP id 9000; Sun, 09 Aug 98 19:39:06 JST Received: from JPNYITP (NJE origin SMTP@JPNYITP) by JPNYITP.YUKAWA.KYOTO-U.AC.JP (LMail V1.1d/1.7f) with BSMTP id 8999; Sun, 9 Aug 1998 19:38:57 +0000 Received: from localhost by JPNYITP.yukawa.kyoto-u.ac.jp (IBM VM SMTP V2R2) with TCP; Sun, 09 Aug 98 19:38:53 JST To: bobuijui95@kola.dcu.ie From: bobuijui95@kola.dcu.ie (grynomu) Comments: Authenticated sender is Subject: direct-email-secrets & stumbling blocks Message-Id: <199808092127UAA7655@gasuvo.crol.yukawa.kyoto-u.ac.jp> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list REACH NEW PROSPECTS - WITHOUT THE TECHNICAL HASSLE ! DO YOU KNOW HOW MOST DIRECT EMAILERS STUMBLE? Direct email uses similar principles involved in the familiar model of direct postal mail. If done correctly, one's success is sure to come. If not performed correctly, then it becomes a case of luck. THE 4 BASIC PRINCIPLE OF DIRECT EMAIL: These basic steps are what the professional, consistent and successful direct emailers use. They are the foundation and root of the direct email model. These include the following: 1. Consistently accessing new and fresh lists 2. Consistently updating lists 3. Consistently sending your ad at reasonable intervals (repetition is the key = look at TV commercials) 4. Optimizing your ad and subject to a more "order pulling" ad DO YOU KNOW AIDA? AIDA is an acronym of the model used in creating powerful and effective sales letters, which is widely used in advertising today. Grab one of several direct mail and direct email letters and read them. The effective letters follow AIDA. What's AIDA stand for? A = grab the prospect's "ATTENTION" I = create "INTEREST" by providing some information D = create stimulaton the produces "DESIRE" A = demand immediate "ACTION" Do you need current and supplemental prospect email lists ? Do you need fresh lists every day, every week or every month ? Do you need more new prospects - never reached before ? If you answered yes, our List Update Service will provide you NEW and FRESH email contacts. NEVER RUN OUT OF EMAIL PROSPECTS ! ! __________________________________________ MORE INFO (24 hrs): 626-839-3835 (US) __________________________________________ 18 From rem-conf Mon Aug 10 08:37:40 1998 From rem-conf-request@es.net Mon Aug 10 08:37:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z5tur-0001s3-00; Mon, 10 Aug 1998 08:31:21 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z5tuq-0001r1-00; Mon, 10 Aug 1998 08:31:20 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA25127; Mon, 10 Aug 1998 11:30:15 -0400 (EDT) Message-Id: <199808101530.LAA25127@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-02.txt Date: Mon, 10 Aug 1998 11:30:14 -0400 Sender: cclark@ns.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) : S. Naudus, M. Baugher, J. Du Filename : draft-ietf-avt-rtp-mib-02.txt Pages : 27 Date : 07-Aug-98 This memo defines an experimental Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Real-Time Transport Protocol systems [1]. Comments should be made to the IETF Audio/Video Transport Working Group at rem-conf@es.net. This memo does not specify a standard for the Internet community. Internet-Drafts are 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-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-mib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-mib-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: <19980807104801.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-mib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980807104801.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Mon Aug 10 18:30:16 1998 From rem-conf-request@es.net Mon Aug 10 18:30:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6313-0000I3-00; Mon, 10 Aug 1998 18:14:21 -0700 Received: from client-151-204-207-86.bellatlantic.net (smpt1.ignats.com) [151.204.207.86] by mail1.es.net with smtp (Exim 1.81 #2) id 0z630z-0000HN-00; Mon, 10 Aug 1998 18:14:17 -0700 To: From: Subject: Wholesale Catalog - Indian rugs, Pottery, Artifacts Date: Sat, 8 Aug 1998 07:35:52 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Attention: Store owners and Independent dealers. You can buy Direct from our American owned company with factories in Mexico.Hand-woven wool rugs, blankets, tablemats, and saddleblankets. Pottery, Leather goods, Longhorns, cowhides, purses. Indian style Kachina dolls,saddles, Mandellas, Dreamcatchers, sandpaintings, drums and Artifacts of all kinds. see Mexican sarapes, Sombreros, Baja shirts, hand-forged branding irons, Bells, imported knives. .....For 28 years we have supplied quality western style merchandise to thousands of stores and dealers. join our Fax Club to keep informed on latest specials, closeouts and new products. Dealers Needed in all states to work event sales, Rodeos, Craft shows, Swap Meets, and roadside selling.Buy Direct and Save Big !!! Visit our 36,000 sq. ft. warehouse in El Paso. Contact us today for a FREE COLOR WHOLESALE CATALOG .. El Paso Saddleblanket Co. 601 N. Oregon st. El Paso, Tx 79901 telephone 915 544 1000 or fax 915 533 7209 30 Day Money-Back guarantee From rem-conf Mon Aug 10 23:19:33 1998 From rem-conf-request@es.net Mon Aug 10 23:19:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z67iK-0002gC-00; Mon, 10 Aug 1998 23:15:20 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0z67iJ-0002g2-00; Mon, 10 Aug 1998 23:15:19 -0700 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 11 Aug 1998 07:15:12 +0100 To: Jonathan Rosenberg cc: rem-conf@es.net Subject: Re: Update of FEC draft In-reply-to: Your message of "Thu, 06 Aug 1998 22:54:38 EDT." <35CA6C6E.45CEFF7D@dnrc.bell-labs.com> Date: Tue, 11 Aug 1998 07:15:08 +0200 Message-ID: <3767.902816108@cs.ucl.ac.uk> From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <35CA6C6E.45CEFF7D@dnrc.bell-labs.com>Jonathan Rosenberg writes: > I have just submitted an updated version of the FEC draft to the > archives. > ... > Comments are most welcome, in particular on the section on R-S codes. Jonathan I am not sure the RS codes are completely specified and whether they fit into this draft. Otherwise, it is much cleaner than the earlier drafts in this direction and merits support. Kind Regards - Orion =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Research Student Networked Multimedia Research Group Department of Computer Science, University College London, Gower Street, London, WC1E 6BT, UK. Tel: (0)171 419 3704. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= draft-ietf-avt-fec-03-comments.txt: 2 Introduction -------------- The justification for FEC in multicast could be that receivers have a mixture of shared and unique loss patterns. By applying FEC, you can address these loss patterns across the receivers. If losses were just shared, retransmission is arguably better. There is an implicit assumption that losses are not due to congestion in the first branches downstream from the source. 5 Parity Codes -------------- Scheme 2 generates FEC data only, there is no "original media". Only applications aware of the FEC payload format will be able to decode any part of this stream. Scheme 3 as shown in not complete and notation differs from other examples: > a,b,c,d,e,f -> f(a), f(b), f(a,b,c), f(c), f(a,c,d), f(a,b,d), f(d), ... Would be better written as: a,b,c,d -> a, b, f(a,b,c), c, f(a,c,d), f(a,b,d), d, f(b,c,d) Also, statement about 4 packet delays is not clear. If a receiver gets b,f(a,c,d),f(a,b,d),d then the delay in decoding packet a from when it should have originally arrived is 7 packets. 8 FEC Packet Structure ---------------------- The parity header you have defined is compatible with a wide range of linear codes (parity, Hamming, etc...) and you can write a brute force decoder that throughs up variations of associated packets to get your media data out. The cost of this is not particularly high, but if you explicitly state what the scheme is you can write a more efficient decoder, you have an exact measure of how long decoding takes and be able to determine when decoding will fail. The delay makes life easier for application developers, and knowledge of when sequences will fail means lower memory overhead. A modern response is that efficiency isn't a concern here, we can work out the delay by inspecting a few packets, and we can timeout data and have ample memory anyway. 6 Reed Solomon Codes -------------------- I believe there is a fundamental problem with RS codes and the goals of this draft. There is no natural division of the output of a RS encoder into data bits and parity bits. RS transforms the input k bits into a unique set of n bits. The original k bits do not appear in the outgoing n bits. RS codes are attractive because they have maximal separation between codewords and so have good error-correcting/detecting properties. To achieve maximal separation distance the k bits are mapped into n bits in different space. Hence no overlap, and no separability. It is not entirely clear to me that you can achieve low latency RS coding because the number of packets over which it is applied is large c*2**m. If you can tolerate a large delay, there is a wide range of reliable multicast data delivery protocols that could be employed. It maybe better not to specify a payload for RS codes until someone in the group has an implementation, and has experimented with it. Also, references to RS encoding would be useful especially, the original papers: "Polynomial Codes Over Certain Finite Fields", Reed, I.S. and Solomon, G., Journal of the Society of Industrial and Applied Mathematics (SIAM), Vol 8, No 2, pp300-304. "A New Treatment of Bose-Chaudhuri Codes", Mattson, H.F and Solomon, G., Journal of the Society of Industrial and Applied Mathematics (SIAM), Vol 9, No 4, pp654-669. 8.2 Reed Solomon Header ----------------------- The header should include the field over which the code is generated to completely specifiy the code. Fields in RS lit are usually 2**m so the field component could be compactly represented by m. Section 17 Bibliography ----------------------- Not to claim undue credit or leave anybody out: Ref [2] should begin C.Perkins and O.Hodson. Ref [3] should begin C.Perkins, I.Kouvelas, O.Hodson, V.Hardman, M. Handley, J.C. Bolot, A.Vega-Garcia, S. Fosse-Parisis. From rem-conf Tue Aug 11 05:58:46 1998 From rem-conf-request@es.net Tue Aug 11 05:58:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6DuY-00060e-00; Tue, 11 Aug 1998 05:52:22 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0z6DuX-00060T-00; Tue, 11 Aug 1998 05:52:21 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Tue Aug 11 08:51:26 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id IAA14783; Tue, 11 Aug 1998 08:51:44 -0400 (EDT) Message-ID: <35D03DC8.9BDC8688@dnrc.bell-labs.com> Date: Tue, 11 Aug 1998 08:49:12 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Orion Hodson CC: rem-conf@es.net Subject: Re: Update of FEC draft References: <3767.902816108@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: > > <35CA6C6E.45CEFF7D@dnrc.bell-labs.com>Jonathan Rosenberg writes: > > I have just submitted an updated version of the FEC draft to the > > archives. > > ... > > Comments are most welcome, in particular on the section on R-S codes. > > Jonathan > > I am not sure the RS codes are completely specified and whether they > fit into this draft. Otherwise, it is much cleaner than the earlier > drafts in this direction and merits support. > > Kind Regards > > - Orion > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Research Student Networked Multimedia Research Group > Department of Computer Science, University College London, > Gower Street, London, WC1E 6BT, UK. Tel: (0)171 419 3704. > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > draft-ietf-avt-fec-03-comments.txt: > > 2 Introduction > -------------- > > The justification for FEC in multicast could be that receivers have a > mixture of shared and unique loss patterns. By applying FEC, you can > address these loss patterns across the receivers. If losses were just > shared, retransmission is arguably better. > > There is an implicit assumption that losses are not due to congestion > in the first branches downstream from the source. I'll add some text to clarify that. > > 5 Parity Codes > -------------- > > Scheme 2 generates FEC data only, there is no "original media". Only > applications aware of the FEC payload format will be able to decode > any part of this stream. Yes. I don't think the draft requires that you send original media; there will certainly be applications where everyone may have FEC (some kind of local conference, perhaps) and thus this is certainly appropriate. I see no reason to rule it out. > > Scheme 3 as shown in not complete and notation differs from other > examples: > > > a,b,c,d,e,f -> f(a), f(b), f(a,b,c), f(c), f(a,c,d), f(a,b,d), f(d), ... > > Would be better written as: > > a,b,c,d -> a, b, f(a,b,c), c, f(a,c,d), f(a,b,d), d, f(b,c,d) OK; I'll change. Thanks. > > Also, statement about 4 packet delays is not clear. If a receiver > gets b,f(a,c,d),f(a,b,d),d then the delay in decoding packet a from > when it should have originally arrived is 7 packets. Hmm.. I had taken this number from the original Budge draft; it does seem like 7. I'll change. > > 8 FEC Packet Structure > ---------------------- > > The parity header you have defined is compatible with a wide range of > linear codes (parity, Hamming, etc...) and you can write a brute force > decoder that throughs up variations of associated packets to get your > media data out. The cost of this is not particularly high, but if you > explicitly state what the scheme is you can write a more efficient > decoder, you have an exact measure of how long decoding takes and be > able to determine when decoding will fail. The delay makes life > easier for application developers, and knowledge of when sequences > will fail means lower memory overhead. In fact, we do explicitly state what the scheme is. If you collect the offset masks from the FEC packets in a block, you end up with the matrix used to generate the code. This is a very explicit definition of what the code is. It will give you the time required to decode and tell you when it will fail. You'll have to recheck to see if the code has changed for each block, but that doesn't seem that problematic. The strength of the mechanism is that a decoder can be constructed, which, as you say, works by brute force to decode independent of details of the particular code. This affords great flexibility in allowing operation over a wide range of scenarios. It also means that encoders can be highly adaptive and diverse, and the mechanisms still work. > > A modern response is that efficiency isn't a concern here, we can > work out the delay by inspecting a few packets, and we can timeout > data and have ample memory anyway. I'm not even sure its so wasteful. There's a natural delay limitation imposed by the playout buffer. You only need bother to keep FEC packets which are associated with sequence numbers higher than the current playout point. With a playout buffer limit of, say, 500ms, and 30ms per packet, where talking about 16 data packets. For a reasonable code, say (3,5), thats 10 FEC packets. This doesn't seem so awful, and its an upper bound. You can also throw the FEC packets away when all of the data packets associated with it are present, and also once you've used it. > > 6 Reed Solomon Codes > -------------------- > > I believe there is a fundamental problem with RS codes and the goals > of this draft. There is no natural division of the output of a RS > encoder into data bits and parity bits. RS transforms the input k > bits into a unique set of n bits. The original k bits do not appear > in the outgoing n bits. RS codes are attractive because they have > maximal separation between codewords and so have good > error-correcting/detecting properties. To achieve maximal separation > distance the k bits are mapped into n bits in different space. Hence > no overlap, and no separability. Hmm. I was under the (apparently mistaken) assumption that the original k packets were still present in the output. This would present a problem. > > It is not entirely clear to me that you can achieve low latency RS > coding because the number of packets over which it is applied is large > c*2**m. If you can tolerate a large delay, there is a wide range of > reliable multicast data delivery protocols that could be employed. It > maybe better not to specify a payload for RS codes until someone in > the group has an implementation, and has experimented with it. What is c and m above? I also don't see why, fundamentally, RS codes cannot be applied over reasonably small block sizes. > > Also, references to RS encoding would be useful especially, the original > papers: > > "Polynomial Codes Over Certain Finite Fields", Reed, I.S. and Solomon, > G., Journal of the Society of Industrial and Applied Mathematics > (SIAM), Vol 8, No 2, pp300-304. > > "A New Treatment of Bose-Chaudhuri Codes", Mattson, H.F and Solomon, > G., Journal of the Society of Industrial and Applied Mathematics > (SIAM), Vol 9, No 4, pp654-669. I'll add them. > > 8.2 Reed Solomon Header > ----------------------- > > The header should include the field over which the code is generated > to completely specifiy the code. Fields in RS lit are usually 2**m so > the field component could be compactly represented by m. The draft states that the payload type is used to indicate this. > > Section 17 Bibliography > ----------------------- > > Not to claim undue credit or leave anybody out: > > Ref [2] should begin C.Perkins and O.Hodson. > > Ref [3] should begin C.Perkins, I.Kouvelas, O.Hodson, V.Hardman, > M. Handley, J.C. Bolot, A.Vega-Garcia, S. Fosse-Parisis. I'll fix. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Tue Aug 11 10:03:30 1998 From rem-conf-request@es.net Tue Aug 11 10:03:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6HjP-0001FX-00; Tue, 11 Aug 1998 09:57:07 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z6HjO-0001F9-00; Tue, 11 Aug 1998 09:57:06 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA17927; Tue, 11 Aug 1998 12:56:02 -0400 (EDT) Message-Id: <199808111656.MAA17927@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-redundancy-revised-00.txt Date: Tue, 11 Aug 1998 12:56:01 -0400 Sender: cclark@ns.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 for Redundant Audio Data Author(s) : C. Perkins, I. Kouvelas, O. Hodson, V. Hardman, M. Handley, J. Bolot, A. Vega-Garcia, S. Fosse-Parisis Filename : draft-ietf-avt-redundancy-revised-00.txt Pages : 11 Date : 10-Aug-98 This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications. Internet-Drafts are 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-redundancy-revised-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-redundancy-revised-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-redundancy-revised-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: <19980810153249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-redundancy-revised-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-redundancy-revised-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980810153249.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Tue Aug 11 10:03:30 1998 From rem-conf-request@es.net Tue Aug 11 10:03:28 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6Hiw-0001FL-00; Tue, 11 Aug 1998 09:56:38 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z6Hiv-0001F5-00; Tue, 11 Aug 1998 09:56:37 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA17786; Tue, 11 Aug 1998 12:55:34 -0400 (EDT) Message-Id: <199808111655.MAA17786@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-fec-03.txt Date: Tue, 11 Aug 1998 12:55:34 -0400 Sender: cclark@ns.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 : An RTP Payload Format for Generic Forward Error Correction Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-fec-03.txt Pages : 17 Date : 10-Aug-98 This document specifies a payload format for generic forward error correction of media encapsulated in RTP. It is engineered for FEC algorithms based on the exclusive or (parity) operation or Reed Solo- mon codes, although it can be used with other techniques. The payload format allows end systems to transmit using arbitrary block lengths and parity schemes. It also allows for the recovery of both the pay- load and critical RTP header fields. Since FEC is sent as a separate stream, it is backwards compatible with non-FEC capable hosts, so that receivers which do not wish to implement FEC can just ignore the extensions. Internet-Drafts are 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-fec-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-fec-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-fec-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: <19980810150115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-fec-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-fec-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980810150115.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Aug 12 00:54:18 1998 From rem-conf-request@es.net Wed Aug 12 00:54:16 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6VXu-0000rK-00; Wed, 12 Aug 1998 00:42:10 -0700 Received: from mail1s.biglobe.ne.jp [210.147.14.241] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z6VXd-0000qS-00; Wed, 12 Aug 1998 00:41:54 -0700 Received: from mail-gw.biglobe.ne.jp (mailsv15.biglobe.ne.jp [210.147.14.248]) by mail1s.biglobe.ne.jp (8.8.8+2.7Wbeta7/3.5Wpl7-98042010) with ESMTP id FAA20899; Mon, 10 Aug 1998 05:36:01 +0900 (JST) From: adm@pu.go.id Received: from mailsv15.biglobe.ne.jp by mail-gw.biglobe.ne.jp (8.8.8/3.6W-INET_GW) id FAA27527; Mon, 10 Aug 1998 05:34:45 +0900 (JST) Date: Mon, 10 Aug 98 04:35:41 EST To: Friend@public.com Subject: HELP all women were raped during the May riots in Jakarta Message-ID: <> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list We Promise that we will throw a nuclear bomb to Indonesia to destroy this besterd Islam country, if they still persecute our chinese. B J Habibie, we will kill you if you don't settle this case. see what they do! http://lateline.muzi.net/topics/Indonesian_atrocity/ http://muzi.net ¦L¥§¬F©²email:dkiweb@indo.net.id ¦L¥§¥~¥æ³¡Home Page: http://www.deplu.go.id ¥»¦¸¨Æ¥óªººô­¶: http://members.spree.com/expose/ http://dailynews.sinanet.com/focus/1998071402/index.html FORWARDED FROM MISSIONNET'S URGENT PRAYER NETWORK ___________________________________________________________ Source: Christian Leaders Association ¨Ó·½:¤Ñ¥D±Ð»â³S¨ó·| 21 June, 1998. Jakarta, Indonesia 1998¦~6¤ë21¤é,¦L¥§¶®¥[¹F Dear friends, (¿Ë·RªºªB¤Í) Here I submit a victim's account of being raped during the May riots here in Jakarta. Reference to Huaran Bulletin Board June 12, 1998. (³o¸Ì§Ú·Q§i¶D¤j®a¦³Ãö¤­¤ë¼É°Ê®É¦b¶®¥[¹Fµo¥Íªº ±j¼É¨Æ¥ó,³o¬O§Ú±q¤µ¦~6¤ë12¤éªºHuaran§G§iª©¤¤±oª¾ªº) The purpose is to request your prayers for hundreds of similar victims. (§Æ±æ¤j®a¯à¬°³o¨ÇÄ묹ªÌ¬èë) "My name is Vivian, and I am 18 years old. I have a little sister and brother. As a family we live in what is supposed to be a "secure" apartment. ("§Ú¥sVivian,¤µ¦~18·³.§Ú¦³¤@­Ó©f©f©M§Ì§Ì,¦í¦b¤@´É³Q»{ ¬°¬O¦w¥þªº¤½´J) At 9.15 am, May 14th, 1998 a huge crowd had gathered around our apartment. They screamed, "Let's butcher the Chinese!", "Let's eat pigs!", "Let's have a party!" We live of the 7th floor and we got a call from a family on the 3rd floor saying that the crowd had reached the 2nd floor. They even chased some occupants upstairs. We were all very frightened. In our fright we prayed and left everything in God's hands. (1998¦~5¤ë14¤é¤W¤È9ÂI15¤À,¤@¸s¤HÂô¶i§Ú­Ìªº¤½´J ¥L­Ì³ÛµÛ"§Ú­Ì­n±þ¤FµØ¤H!","§Ú­Ì§â½Þ¦Y¤F!",§Ú­Ì¦í¦b ¤C¼Ó,¤T¼Óªº®a¤H§i¶D§Ú­Ì¨º¸s¤H¤w¸g¨ì¤F¤G¼Ó,¥L­Ì¬Æ ¦Ü°lµÛ¦í¤á¤W¨Ó,§Ú­Ì³£³QÀ~Ãa¤F,¥u¯à¦b®£Äߤ¤¬èë,±N ¤@¤Á¥æµ¹¤W«Ò) Afterward we left our room and went upstairs to the top floor, as it was impossible to go downstairs and escape. We got to the 15th floor and stayed with some friends. Not long afterwards we were surprised because some of the crowd coming out of the elevators right before we entered the room. We hurried into the room and locked the door tightly. At that time we heard them knock at the other rooms loudly and there were some screams from women and girls. Our room was filled with fear. (¤§«á§Ú­ÌÂ÷¶}©Ð¶¡°k¨ì³»¼Ó,§¹¥þµLªk¤U¼Ó°k¨«,§Ú­Ì©M ¤@¨ÇªB¤Í°k¨ì15¼Ó,¨S¦³¦h¤[,¦b§Ú­Ì¸ú¶i©Ð¸Ì¤§«e,¨º¸s ¤H´N½Ä¥X¹q±è,§Ú­Ì»°§Ö¶i¤J©Ð¸ÌÂêºò©Ðªù,¥uÅ¥¨ìªù¥~ ¶Ç¨Ó½ðªùªºÁn­µ,¥H¤Î¤@¨Ç°ü¤k©M¤k«Äªº¦y¥sÁn,¾ã­Ó ©Ð¶¡¥Rº¡µÛ®£Äß) We realized that they would come to us. So we spread throughout the room hiding in the corners.We could hear girls of 10 to 12 years old screaming, "Mommy, ..mommy...mom...mom...it hurts" That time I didn't know that these little girls were being raped. After about half an hour the noise diminished and we had some guts to go out and check. It was indescribable. A lot, some of them youg girls, were lying on the floor. "Oh my God, what has happened?" Seeing all of this we screemed and my little sister Fenny, screamed histerically and hugged her father. (§Ú­Ì¤F¸Ñ¨ì¥L­Ì¿ð¦­·|¶i¨Ó,©Ò¥H§Ú­Ì·æÁYªº¸ú¦bÀ𨤠§Ú­ÌÅ¥¨ì¤j¬ù10¨ì12·³ªº¤k«Äªº¦y¥s"¶ý...¶ý...¶ý....¦nµh §â¦o¥á¨ì¨Fµo¤W,§Ú°¨¤W¤ÏÀ³¨ì¦oªº¦MÀI,©ó¬O¤j¥s, ¦ý¬O¤@­Ó¼É¥Á¥´¤F§Ú¤@­Ó¦Õ¥ú,§Úª¨ª¨¤]³Q¥L­Ì¥Î¤ì ´Ò¥´©ü,§Ú¶ý¶ý¦bFenny³Q¥á¨ì¨Fµo¤W®É´N©ü­Ë¤F,§Ú¥u ¯à¬èë,¥u¯à¬èë¨aÃø¤£­n­°Á{) Uncle Dodi kept trying to stop them by offering money. His efforts were fruitless. And in the end 5 people raped Fenny. Before beginning with the raping they always said "Allahu Akbar" (an islamic phrase in arabic meaning "God is great". They were ferocius and brutal. (Dodi¨û¨û¸ÕµÛ¥Î¿úÅý¥L­Ì¤£­n¬I¼É,¦ý¬O¨S¦³¥Î,µM«á ¦³¤­­Ó¤H±j¼É¤FFenny,¨C­Ó¦b±j¼É«e³£©ÀµÛ"Allahu Akbar" ¬O¥ì´µÄõ±Ðªºµu¥yªü©Ô§B¸Üªº·N«ä¬O"°¶¤jªº¯«",¥L­Ì Åã±o´Ý¼É¦Ó¥B¹³³¥Ã~¤@¯ë) Not long afterward, around 9 men came to the room and dragged me. I also saw them forcing and dragging my Aunt Vera. But at that time I passed out and everything went blank. I became conscious at around 5 or 6 pm. My head hurted and I realized I had no clothing on my body. I cried and realized my family was still there. My father was hugging my mother and little bother Doni. I also saw uncle Dodi lying on the floor and Aunt Vera was crying over his body. I felt so weak and fainted again. (¨S¦³¦h¤[,¤j·§¦³¤E­Ó¤H§â§Ú©ì¥X¥h,§Ú¬Ý¨ì¥L­Ì¤]§â VeraÂTÂT©ì¥X¨Ó,¦ý¬O§Ú©ü¤F¹L¥h,¤@¤Á³£Åܦ¨ªÅ¥Õ ¤j¬ù¤U¤È5ÂI¨ì6ÂIªº®É­Ô,§Ú³vº¥ªº«ì´_·NÃÑ,§ÚªºÀY ³¡¨ü¤F¶Ë,¨­¤W¤]¤@µ·¤£±¾,§Ú­ú¤F¥X¨Ó,¨Ã¥Bµo²{§Ú ªº®a¤HÁÙ¦b,§Úª¨ª¨©êµÛ§Ú¶ý¶ý©M§Ì§Ì,Dodi¨û¨û­Ë¦b ¦a¤W¦ÓVeraÂTÂT©êµÛ¥Lµh­ú,§Ú·P¨ìµê®z¦Ó¤S·w¯t¹L¥h) The next day I was in the Pluit hospital. My father and mother were beside me. With all the pains on my body I asked, "Mom, why Fenny. Mom?" I felt a stinging pain as I said these words. My cheeks were swollen. My mother cried again and couldn't speak any words, while my father, holding back his tears, managed to smile at me. After 4 days in treatment, my condition has improved. With a sad look, my father told me then what had happened. After I fainted 7 people raped me. At that time my father still couldn't see well after beling hit with a piece of wood. They raped me repeatedly. Then my father said "Vivian, Fenny is gone..." (²Ä¤G¤Ñ§Ú³Q°e¨ìPluitÂå°|,§Úªºª¨¶ý¦b§Ú¨­®Ç,§Ú§ÔµÛµh °Ý¥L­Ì"¶ý,Fenny©O?¶ý"»¡¸ÜÅý§Ú·P¨ì°w¨ë¯ëªºµh­W,§Ú ¶ý¶ý­ú¤F°_¨Ó,¤@¥y¸Ü³£»¡¤£¥X¨Ó,§Úª¨ª¨§Ô¦í²\¤ô,¹ï§Ú ­W¯º¤@¤U,¥|¤Ñ¤§«á,§Úªº±¡ªp¦n¤FÂI,§Úªº¤÷¿Ë¤@Áy¶Ë´d ªº§i¶D§Ú,·í®É§Ú©ü°g¤F¥H«á,¦³7­Ó¤H±j¼É¤F§Ú,§Ú¤÷¿Ë«h ³Q¶Ã´Ò¼Þ¥´,¨º¨Ç¼É¥Á­«½Æªº±j¼ÉµÛ§Ú.¶ý¶ý¦b¤@®Ç¶Ë¤ßªº »¡"Vivian,Fenny¦º¤F...") I was confused and cried out, "Why Dad?" My father couldn't answer. He told me to rest and went out of the room. I cried over and over again, feeling that my life had no meaning any more. A week ago, after I was released from the hospital I was told everything that had happend. (§Ú¸£¤¤¤@¤ù²V¶Ã,­ú¤F°_¨Ó,"ª¨ª¨.¬°¤°»ò?"§Ú¤÷¿ËµLªk ¦^µª§Ú,¥L§i¶D§Ú¦n¦n¥ð®§,¨«¤F¥X¥h,§Ú¤£°±ªº­ú,§Úªº¤H ¥Í¤w¸g§¹¥þ¨S¦³¥ô¦ó·N¸q¤F,¤@­Ó¬P´Á¹L¥h¤F,¦b§Ú¥X °|¤§«á,¤~ª¾¹D¨Æ±¡ªº¾ã­Ó¸g¹L) When Fenny was raped she kept on fighting and so she was repeatedly slapped by her rapists. The last time she fought Fenny spitted on one of them. Offended, the man grabbed a knife and stabbed Fenny's stomach over and over again. Finally she died with blood over her whole body. (Fenny¦b³Q±j¼Éªº®É­Ô¤£°±ªº¤Ï§Ü,©ó¬O¨º¨Ç¼É¥Á¤£Â_ ªº¥´¦o,³Ì«áFennyªº¤Ï§Ü·S¤õ¤F¨ä¤¤¤@­Ó¼É¥Á,¥L§ì°_ ¤@§â¤M¤l¨ë¶iFennyªº¨{¤l,¤@¦¸¤S¤@¦¸ªº¨ë¶i¨ë¥X,³Ì «áFenny¥þ¨­¬O¦åªº¦º¤F) My father told me that uncle Dodi had the same fate watched by aunt Vera who was also raped. "God...why should all of this happen? Where are you God? Are you still alive?" My aunt Vera now stays with her parents. She is in shock. Her face is blank and refuses to eat. Almost every hour my mother and I cry over all these happenings. I can never forget. These mobs of people are uncivilized monsters." (¤÷¿Ë§i¶D§Ú,Dodi¨û¨û¤]¬ÝµÛ¦Û¤vªº¤Ó¤Ó³Q±j¼É,"¤Ñ§r! ¬°¤°»ò·|µo¥Í³oºØ¨Æ?¯«¦b­þ¸Ì?Í¢ÁÙ¬¡µÛ¶Ü?"§ÚÂTÂT Vera²{¦b©M¥Lªº¤÷¥À¦í¦b¤@°_,¦o¨ü¨ìÄY­«ªºÅåÀ~, ¦oªºÁy¤W¨S¦³¦å¦â¦Ó¥B©Úµ´¶i­¹,§Ú©M¶ý¶ýµL®ÉµL¨è ¦]¬°³o³õ´c¹Ú¦Ó­úª_,§Ú¥Ã»·§Ñ¤£¤F,¨º¨Ç¼É¥Á´N¹³¬O ¨S¦³¶i¤Æªº©ÇÃ~) Additional comments from Bill Hekman: (¥H¤U¬OBill Hekmanªºªþµù) This is one of many victims. Hundreds of women and children were raped, mutilated and killed by muslim mobs. Some had their vaginas ripped apart, their bodies cut into pieces. (³o¥u¬O«Ü¦hªºÄ묹ªÌ¤¤ªº¤@­Ó,¦³¼Æ¦Ê¦ì°ü¤k»P¤p«Ä ³Q¦^±Ð¼É®{±j¼É,±ÙÂ_¤â¸},±þ®`,¦o­Ìªºªº³±¹D³Q¼¹µõ ,¨­Åé³Q¬å¦¨¦n´X¬q) Over 5000 of the Chinese Indonesian's shops were looted and burned down. A few days ago anther 63 shops were burned in Tegal, Central Java. The city of Solo is burned down. There is no protection and no justice in this country any more. (¶W¹L5000®a¥H¤Wªº¦L¥§µØ¤Hªº°Ó©±³Q±°¹Ü©MµI¿N, ´X¤Ñ«e¦b¤ö«zªºTegal,¥t¥~63®a°Ó©±³Q©ñ¤õ¿N±¼,¦L¥§ ²{¦b§¹¥þ¨S¦³«O»Ù,¥¿¸q¿ºµMµL¦s) Yesterday I was in the Kelapa Gading area and that area was spared from destruction. The police and military had guarded all the entry roads. The people there had collected large sums of money from door to door and paid for their protection. (¬Q¤Ñ§Ú¦bKelapa Gading°Ï,¨º¸Ì¥Ø«eÁÙ¨S¦³³Q¯}Ãa,ĵ¹î ©M­x¶¤¦b©Ò¦³¸ô¤fĵ§Ù,¨º¸Ìªº¤H­Ì¶°¦X¤F¤@¤jµ§¿ú¨Ó ¤ä¥I³o¨Ç«OÅ@) A similar situation took place in the Pondok Indah area.For the people who cannot pay millions to the armed forces there is no protection. Right now the hunderds of thousands of thugs,robbers, rapist, and killers live all around us. They are our neighbors. There is no punishment for the criminals and no justice for the victims. Yet, all Indonesians call themselves believers in God almighty. What a hipocracy. Shouting "God is great" when raping women andchildren is a blasphemy against a Holy God. (¦bPondok Indah°Ï¤]¬O¦P¼Ëªº±¡ªp,®³¤£¥X¿úªº¤H´N§¹¥þ ¨S¦³¥ô¦ó«O»Ù,²{¦b¦³¦¨¤d¤W¸Uªº¦^±Ð¨ë«È,±jµs,±j¼ÉªÌ©M ±þ¤HÅ]¦í¦b§Ú­Ìªº¥|©P,¥L­Ì¬O§Ú­Ìªº¾F©~,¹ï©ó¸o¥Ç¨S¦³ ³B»@,¹ï©ó¨ü®`ªÌ¤]¨S¦³¤½²z,¦ý¬O,©Ò¦³ªº¦L¥§¤H©I³êµÛ ¥L­Ì©Ò«H¥õªº"¥þ¯àªº¯«:"¤Ó¿Ø¨ë¤F.¦b±j¼É°ü¤k©M¤p«Ä®É ©I³Û°¶¤jªº¯«,³o¬O¹ï¯«¸t¤W«Òªº«_Âp) Pray that God will annoint His preachers and missionaries throughout this nation with the power of the Holy Spirit to preach the message of repentance. God's word in 2 Chronicles 7:14 needs to be proclaimed boldly. There is no room for preachers filled with fear who think of evacuation and other selfish plans. Pray for Revival in all our churches. (¬èë¤W«Ò¦b³o­Ó°ê®a¤¤¬°Í¢ªº¤l¥Á¶î¤Wªo»I,¥Î¯«¸tªº ¤O¶q¶Ç»¼®¬§ïªº°T®§,¬ù¸t¸g¾ú¥N§Ó²Ä7³¹²Ä14¸`À³¸Ó ³QÅã©úªº«Å§i, There is no room for preachers filled with fear who thinkof evacuation and other selfish plans.(³o¤@¥y¦b¤U½¤£¥X¨Ó¾A¤Áªº¦r¥y,±æ¦³ ¯àªÌ¸É¤W) Ä@§Ú­Ìªº¸t·µ¬Ò¯à´_¿³ Some Christians are putting signs on their shops "Owned by Muslim". May God forgive them. Healing of this nation filled with crime and unjustice is bringing God's judgement and punishment. Healing and Salvation can only come with a nasional repentance at all levels in the government, armed forces and society. Then we need to share the Gospel of the Lord Jesus Christ. Christ is the One and Only Savior. No one will ever receive forgiveness and see heaven except through God's appointed Savior, the Lord Jesus Christ. Thank you for standing with us now. God bless you. (¦³ªº¤Ñ¥D±Ð®{ªº°Ó©±³Q¶K¤W"¦^±Ð®{©Ò¦³"ªº¼Ð»y,Ä@ ¤W«Ò¼e®¤¥L­Ì,¥Î¤W«Òªº¼f§P»PÃg»@¨ÓÂåªv³o­Ó¥Rº¡ ¸o´c»P¤£¸qªº°ê«×,°ß¦³¾ã­Ó°ê®a-¦U¯Å¬F©²,­x¶¤©MªÀ·| -ªº®¬§ï¤~¯à°±¤î¶Ëµh,§Ú­Ì­n¶Ç¼½°ò·þªººÖ­µ,°ò·þ¬O°ß chaos in Indonesia last May 13-15. Many Chinese Indonesian citizens were abused, tortured and killed. Their houses and stores were looted and burnt. Hundreds of Chinese Indonesian girls/women (aged 10-55) were sexually harassed and gang raped brutally. Some victims were even raped in front of their family members or in front of inhuman cheering crowd. (½Ð±N³o«Ê"¶Àµ·±a"ªº«H¥ó±Hµ¹±zªºªB¤Í,¨Óªí¥Ü§Ú­Ì¹ï©ó ¦b¤­¤ë13-15¤é©ó¦L¥§¼É°Ê¤¤¨ü®`ªºÄ묹ªÌ¤@Åé·P»P¦P±¡ ³\¦hµØ¸Çªº¦L¥§¤½¥Á³Q±j¼É,­â­h,±þ®`.¥L­Ìªº©Ð¤l©M°Ó©± ³Q·m§T©MµI¿N,¦³ªº¨ü®`ªÌ´N¦b®a¤H»P¤@¸s¨S¦³¤H©Ê ÁÙÅw©Iªº¸s²³­±«e³Q½ü¼É) Some of them were even thrown into the fire and burnt to death after being raped. Yet, not many actions seem to have been taken to investigate all this or to help the victims. And not very many people seem to know or care about what happened. Please help to spread the news and let the world know. (¨ä¤¤¦³¨Ç¤H¦b³Q±j¼É¤§«á,ÁÙ³Q¥á¤J¤õ¤¤µI¿N¦Ü¦º,¦ý¬O,¨Ã ¨S¦³³\¦h½Õ¬d©Î¨ó§Uªº¦æ°Ê¦b¶i¦æ,¦Ó¥B¤]ÁÙ¨S¦³«Ü¦h¤HÃö ¤ß©Î¬Oª¾¹D³o¨Ç¨Æ±¡,½Ð¨ó§U´²§G³o¨Ç®ø®§,Åý°ê»Ú¶¡ª¾¹D ³o¨Ç¨Æ) We need help to get more international attention to help Chinese Indonesians, who are now living in fear in Indonesia. Please pass this ribbon around as the symbol of campaign against human rights violations, injustice, and racism towards Chinese Indonesians. (§Ú­Ì»Ý­n¤Þ°_°ê»Ú¶¡ªº­«µø,¥H«KÀ°§U¥Ø«e¥Í¬¡¦b®£Äߤ¤ ªº¦L¥§µØ¤H,½Ð±Nµ·±a§@¬°¤Ï¹ï¥[½Ñ©ó¦L¥§µØ¤Hªº¼É¤O, ¤£¥¿¸q¥H¤ÎºØ±Ú¥D¸qªº¼Ð»x) Show that we care and may God help us! (§i¶D¥@¤H§Ú­ÌÃö¤ß,Ä@¤W«Ò½ç»P§Ú­Ì¤O¶q) From rem-conf Wed Aug 12 01:28:31 1998 From rem-conf-request@es.net Wed Aug 12 01:28:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6WCo-00027H-00; Wed, 12 Aug 1998 01:24:26 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0z6WCn-000276-00; Wed, 12 Aug 1998 01:24:25 -0700 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Aug 1998 09:24:17 +0100 To: Jonathan Rosenberg cc: Orion Hodson , rem-conf@es.net Subject: Re: Update of FEC draft In-reply-to: Your message of "Tue, 11 Aug 1998 08:49:12 EDT." <35D03DC8.9BDC8688@dnrc.bell-labs.com> Date: Wed, 12 Aug 1998 09:24:14 +0200 Message-ID: <7192.902910254@cs.ucl.ac.uk> From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <35D03DC8.9BDC8688@dnrc.bell-labs.com>Jonathan Rosenberg writes: > > > > 5 Parity Codes > > -------------- > > > > Scheme 2 generates FEC data only, there is no "original media". Only > > applications aware of the FEC payload format will be able to decode > > any part of this stream. > > Yes. I don't think the draft requires that you send original media; > there will certainly be applications where everyone may have FEC (some > kind of local conference, perhaps) and thus this is certainly > appropriate. I see no reason to rule it out. The draft should allow both. Section 4 Basic Operation section only describes the case where FEC packets and media packets are sent as separate streams. The draft should explicitly say there may only be an FEC stream, or a media stream and an FEC stream. > > 6 Reed Solomon Codes > > -------------------- > > > > I believe there is a fundamental problem with RS codes and the goals > > of this draft. There is no natural division of the output of a RS > > encoder into data bits and parity bits. RS transforms the input k > > bits into a unique set of n bits. The original k bits do not appear > > in the outgoing n bits. RS codes are attractive because they have > > maximal separation between codewords and so have good > > error-correcting/detecting properties. To achieve maximal separation > > distance the k bits are mapped into n bits in different space. Hence > > no overlap, and no separability. > > Hmm. I was under the (apparently mistaken) assumption that the original > k packets were still present in the output. This would present a > problem. This does not have to be a problem if section 4 is modified as above. My tenuous understanding of RS codes is that they are not systematic (i.e. source data is not present in their output), the example at the end of the original work ends with mapping: (0,0,0,1,1,0,0,1) -> (000,001,110,110,111,000,001,111) which is clearly not systematic. I would suggest we ask someone who has a better grasp of RS codes to read through the RS section. Phil Karn (karn@qualcomm.com) has done some work in this area and has some RS source code off his web page. He would be a good person to ask. > > > > It is not entirely clear to me that you can achieve low latency RS > > coding because the number of packets over which it is applied is large > > c*2**m. If you can tolerate a large delay, there is a wide range of > > reliable multicast data delivery protocols that could be employed. It > > maybe better not to specify a payload for RS codes until someone in > > the group has an implementation, and has experimented with it. > > What is c and m above? I also don't see why, fundamentally, RS codes > cannot be applied over reasonably small block sizes. Sorry, m is the power of two over which the code is defined. So 2*m is the minimum number of packets you can apply the operation. c is the number of these blocks you do in one go. m = 3 seems to be a popular field over which to conduct RS coding. So that's c*8 packets delay at both ends, if you can tolerate that kind of latency other approaches may become sensilble. At some point there is a transition to RM. >> 8.2 Reed Solomon Header >> ----------------------- >> >> The header should include the field over which the code is generated >> to completely specifiy the code. Fields in RS lit are usually 2**m so >> the field component could be compactly represented by m. > > The draft states that the payload type is used to indicate this. You're right, this did not register. - Orion From rem-conf Wed Aug 12 03:02:27 1998 From rem-conf-request@es.net Wed Aug 12 03:02:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6Xgb-0003Ou-00; Wed, 12 Aug 1998 02:59:17 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0z6XgZ-0003Ok-00; Wed, 12 Aug 1998 02:59:16 -0700 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Aug 1998 10:59:08 +0100 To: Jonathan Rosenberg cc: rem-conf@es.net Subject: Re: Update of FEC draft In-reply-to: Your message of "Wed, 12 Aug 1998 09:24:14 +0200." <7192.902910254@cs.ucl.ac.uk> Date: Wed, 12 Aug 1998 10:59:04 +0200 Message-ID: <7299.902915944@cs.ucl.ac.uk> From: Orion Hodson X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list <7192.902910254@cs.ucl.ac.uk>Orion Hodson writes: > <35D03DC8.9BDC8688@dnrc.bell-labs.com>Jonathan Rosenberg writes: > > Hmm. I was under the (apparently mistaken) assumption that the original > > k packets were still present in the output. This would present a > > problem. > > This does not have to be a problem if section 4 is modified as above. > My tenuous understanding of RS codes is that they are not systematic No RS codes are systematic. Sorry, my mistake, tenuous understanding at fault. - Orion From rem-conf Wed Aug 12 09:59:29 1998 From rem-conf-request@es.net Wed Aug 12 09:59:29 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6eA9-0007de-00; Wed, 12 Aug 1998 09:54:13 -0700 Received: from irv-port271.jps.net (208.237.197.38) [208.237.197.38] by mail1.es.net with smtp (Exim 1.81 #2) id 0z6eA7-0007dI-00; Wed, 12 Aug 1998 09:54:11 -0700 From: looseweight@bigfoot.com To: rem-conf@es.net Reply-To: looseweight@bigfoot.com Subject: EZ LOSE Message-Id: Date: Wed, 12 Aug 1998 09:54:11 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Friend, If there was a way that you could help your friends to lose weight without changing their lifestyle, no pills, no shakes and no side effects, would you want to know more about it? 87% success rate in clinical studies in the past 2 years, easy and affordable with 30 day money back guarantee and a superb new business opportunity! To respect your time I will keep it short for now. For more info enter MORE in the subject field and reply. If you want to be removed from this mailing list enter REMOVE. To your health - Dr JJ Levine From rem-conf Wed Aug 12 11:39:47 1998 From rem-conf-request@es.net Wed Aug 12 11:39:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6fk4-0001eE-00; Wed, 12 Aug 1998 11:35:24 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z6fk3-0001cA-00; Wed, 12 Aug 1998 11:35:23 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01071; Wed, 12 Aug 1998 14:34:15 -0400 (EDT) Message-Id: <199808121834.OAA01071@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-01.txt,.ps Date: Wed, 12 Aug 1998 14:34:15 -0400 Sender: cclark@ns.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) : V. Jacobson, S. Casner, R. Frederick, H. Schulzrinne Filename : draft-ietf-avt-rtp-new-01.txt,.ps Pages : 94 Date : 11-Aug-98 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. The revision process is not yet complete; some changes which have been discussed and tentatively accepted in meetings of the Audio/Video Transport working group have not yet been incorporated into this draft. 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. Internet-Drafts are 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-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-new-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: <19980811151657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-new-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-new-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980811151657.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Aug 12 11:39:47 1998 From rem-conf-request@es.net Wed Aug 12 11:39:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6fli-0001ez-00; Wed, 12 Aug 1998 11:37:06 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z6flh-0001eQ-00; Wed, 12 Aug 1998 11:37:05 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01623; Wed, 12 Aug 1998 14:35:58 -0400 (EDT) Message-Id: <199808121835.OAA01623@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-03.txt,.ps Date: Wed, 12 Aug 1998 14:35:57 -0400 Sender: cclark@ns.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 Filename : draft-ietf-avt-profile-new-03.txt,.ps Pages : 31 Date : 11-Aug-98 This memo 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. The 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. However, the encoding definitions are independent of the particular transport mechanism used. 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. Internet-Drafts are 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-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-profile-new-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-profile-new-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: <19980811170444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-profile-new-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-new-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980811170444.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Aug 12 11:39:47 1998 From rem-conf-request@es.net Wed Aug 12 11:39:47 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6fkC-0001eJ-00; Wed, 12 Aug 1998 11:35:32 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z6fk3-0001c9-00; Wed, 12 Aug 1998 11:35:23 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA01039; Wed, 12 Aug 1998 14:34:11 -0400 (EDT) Message-Id: <199808121834.OAA01039@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-jpeg-new-02.txt,.ps Date: Wed, 12 Aug 1998 14:34:10 -0400 Sender: cclark@ns.cnri.reston.va.us X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --NextPart Note: This revision reflects comments received during the last call period. 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 JPEG-compressed Video Author(s) : L. Berc, R. Frederick, B. Fenner, S. McCanne, P. Stewart Filename : draft-ietf-avt-jpeg-new-02.txt,.ps Pages : 25 Date : 11-Aug-98 This memo describes the RTP payload format for JPEG video streams. The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. This document 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 author(s). Internet-Drafts are 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-jpeg-new-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-jpeg-new-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-jpeg-new-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: <19980811151159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-jpeg-new-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-jpeg-new-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980811151159.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Wed Aug 12 12:05:32 1998 From rem-conf-request@es.net Wed Aug 12 12:05:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6gC4-0003wR-00; Wed, 12 Aug 1998 12:04:20 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z6gC3-0003vb-00; Wed, 12 Aug 1998 12:04:19 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA06870; Wed, 12 Aug 1998 15:03:15 -0400 (EDT) Message-Id: <199808121903.PAA06870@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-rtpsample-00.txt,.ps Date: Wed, 12 Aug 1998 15:03:15 -0400 Sender: cclark@ns.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 : Issues with RTP Sampling Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-avt-rtpsample-00.txt,.ps Pages : 12 Date : 11-Aug-98 In order to control the flow of RTCP packets in large multicast groups, session participants are required to transmit their packets with a period proportional to the group size. Obtaining a group size estimate generally requires a participant to maintain a list of group members. As this can require significant memory, particularly for embedded systems, RTP has been revised to allow for a statistical sampling procedure which allows the memory size to be bounded for all group sizes. However, this sampling algorithm can interact with other aspects of RTP. In particular, we have identified three problems. First, RTP sampling has an adverse affect on the performance of BYE reconsideration. Secondly, it can cause inaccurate estimates with dynamic group sizes that decrease rapidly. Thirdly, the current SSRC sampling algorithm grossly overestimates the group size when there are a few senders. We discuss these problems in detail and present simple solutions. Internet-Drafts are 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-rtpsample-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtpsample-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtpsample-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: <19980811104145.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtpsample-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtpsample-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980811104145.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf Thu Aug 13 00:12:27 1998 From rem-conf-request@es.net Thu Aug 13 00:12:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6rV0-0002yw-00; Thu, 13 Aug 1998 00:08:38 -0700 Received: from zip.elliott.net (zip.kego.com) [199.242.251.2] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z6rUy-0002yW-00; Thu, 13 Aug 1998 00:08:36 -0700 Received: from zip (Administrators@localhost) by zip.kego.com (8.8.8/8.8.7) with SMTP id AAA00271 for ; Thu, 13 Aug 1998 00:07:19 -0700 (Pacific Daylight Time) Resent-Date: Thu, 13 Aug 1998 00:07:18 -0700 (Pacific Daylight Time) Resent-From: cam@elliott.net Resent-Message-Id: <199808130707.AAA00271@zip.kego.com> Message-ID: <005401bdc689$0291f120$02fbf2c7@zip.kego.com> From: "Cameron Elliott" To: Subject: T.124 standard? Date: Thu, 13 Aug 1998 00:07:18 -0700 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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Resent-Bcc: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Does anyone know how I can purchase a copy of T.124 without buying a $400+ subscription to the ITU standards? (T.124 is NOT available currently through the ITU online purchasing program) Thanks Cameron Elliott From rem-conf Thu Aug 13 01:49:02 1998 From rem-conf-request@es.net Thu Aug 13 01:49:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6ss4-0004Il-00; Thu, 13 Aug 1998 01:36:32 -0700 Received: from mailer2.lut.ac.uk [158.125.1.206] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0z6ss3-0004IZ-00; Thu, 13 Aug 1998 01:36:31 -0700 Received: from [158.125.1.201] (helo=sun-cc201.lboro.ac.uk ident=root) by mailer2.lut.ac.uk with smtp (Exim 1.92 #1) id 0z6srn-00074E-00; Thu, 13 Aug 1998 09:36:15 +0100 Received: from ccjch by sun-cc201.lboro.ac.uk with local (Exim 1.82 #1) id 0z6srl-0003P3-00; Thu, 13 Aug 1998 09:36:13 +0100 Subject: Re: T.124 standard? To: cam@elliott.net (Cameron Elliott) Date: Thu, 13 Aug 1998 09:36:12 +0100 (BST) Cc: rem-conf@es.net In-Reply-To: <005401bdc689$0291f120$02fbf2c7@zip.kego.com> from "Cameron Elliott" at Aug 13, 98 00:07:18 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 782 Message-Id: From: Julian Highfield X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Cameron Elliott wrote: > Does anyone know how I can purchase a copy of T.124 > without buying a $400+ subscription to the ITU standards? > (T.124 is NOT available currently through the ITU online > purchasing program) There's always the T120 archives - mostly with draft standards. E.g. The README in that archive says "Contains T.120 work in progress, ITU Study Group 8 meeting reports, and other T.120 related contributions. The material contained at the this site is openly distributed." So I turned some of it into HTML for easier reading. I didn't process all of the later revisions though, so you'll want the original archive. Regards, Julian. From rem-conf Thu Aug 13 09:03:31 1998 From rem-conf-request@es.net Thu Aug 13 09:03:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z6zlL-0000q0-00; Thu, 13 Aug 1998 08:58:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0z6zlK-0000pq-00; Thu, 13 Aug 1998 08:58:02 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Aug 13 11:57:28 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id LAA06178; Thu, 13 Aug 1998 11:57:45 -0400 (EDT) Message-ID: <35D30C59.28C5F9AB@dnrc.bell-labs.com> Date: Thu, 13 Aug 1998 11:55:05 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Orion Hodson CC: rem-conf@es.net Subject: Re: Update of FEC draft References: <7192.902910254@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: > > <35D03DC8.9BDC8688@dnrc.bell-labs.com>Jonathan Rosenberg writes: > > > > > > 5 Parity Codes > > > -------------- > > > > > > Scheme 2 generates FEC data only, there is no "original media". Only > > > applications aware of the FEC payload format will be able to decode > > > any part of this stream. > > > > Yes. I don't think the draft requires that you send original media; > > there will certainly be applications where everyone may have FEC (some > > kind of local conference, perhaps) and thus this is certainly > > appropriate. I see no reason to rule it out. > > The draft should allow both. Section 4 Basic Operation section only > describes the case where FEC packets and media packets are sent as > separate streams. The draft should explicitly say there may only be > an FEC stream, or a media stream and an FEC stream. OK, I'll clarify as its my intention that the draft allows both. > > > It is not entirely clear to me that you can achieve low latency RS > > > coding because the number of packets over which it is applied is large > > > c*2**m. If you can tolerate a large delay, there is a wide range of > > > reliable multicast data delivery protocols that could be employed. It > > > maybe better not to specify a payload for RS codes until someone in > > > the group has an implementation, and has experimented with it. > > > > What is c and m above? I also don't see why, fundamentally, RS codes > > cannot be applied over reasonably small block sizes. > > Sorry, m is the power of two over which the code is defined. So 2*m > is the minimum number of packets you can apply the operation. c is > the number of these blocks you do in one go. I think that this is not how it works. The size of the field over which the RS code operations doesn't dictate the number of packets, but rather the number of bits at a time in the packet which get operated on. So, for example, lets say we are using a FEC code over an 8 bit field, and we are using k=12, n=15. The 12 data packets are 32 bits long each. Thus, the encoder would construct the parity packets 8 bits at a time, requiring 4 passes to compute the entire 32 bits. So, the value of the field has nothing to do with the number of packets. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Aug 13 13:57:54 1998 From rem-conf-request@es.net Thu Aug 13 13:57:53 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z74No-0004Ry-00; Thu, 13 Aug 1998 13:54:04 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0z74Nn-0004Rn-00; Thu, 13 Aug 1998 13:54:03 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Aug 13 16:53:47 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA16538; Thu, 13 Aug 1998 16:54:01 -0400 (EDT) Message-ID: <35D351C8.AEC52211@dnrc.bell-labs.com> Date: Thu, 13 Aug 1998 16:51:20 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Colin Perkins , rem-conf@es.net Subject: Re: draft-ietf-avt-fec-03 References: <3802.903028301@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 Colin - I'm forwarding my responses to your comments to the list as I think they warrant more widespread discussion. Colin Perkins wrote: > > Hi Jonathan, > > I've just been reading through the FEC draft. Generally, it seems pretty > good, but I have a few minor comments: > > - In section 4 you state that "FEC packets have their own sequence number > and timestamp space", yet section 8 implies that the media clock is used. > Using the media clock seems sensible, so section 4 should be ammended to > match this. (this also means there is a sensible timestamp offset to use, > if combining fec with redundancy). My choice of words was not too good. What I meant by "having its own TS space" is that the FEC packets aren't interspersed with the media, and have their own timestamps which represent their generation times. Their generation time is defined as the RTP timestamp of the media clock when the FEC packet is sent. > > - Is an offset mask of 24 bits really not sufficient? The mechanism for > extending it to 56 bits is reasonably clean, I'm just surprised it's > needed... Probably it is sufficient. I'd be game to remove the extra 32 bit option, but keep the E bit as "for future use", and require it to be set to 0. We can use it for future extensions. Any objections to its removal? > > - The security considerations section should possibly be expanded. The use > of FEC makes changing encryption keys a little harder. Simple example: > a f(a,b) b > with a and b being encrypted with different keys, which key is used for > the FEC packet? Same problem occurs when enabling/disabling encryption. > The issue should, at least, be noted. Good point. I don't think this is hard. You basically switch keys on the media stream, and at some point, switch keys on the FEC stream. These need not be synchronized. You would make the determination about when the switch occurs separately for each stream. Additionally, it strikes me that there are actually a few modes of operation: 1. FEC encrypted, media not 2. media encrypted, FEC not 3. FEC and media encrypted, same keys 4. FEC and media encrypted, different keys Should we require one mode (such as 3), or allow multiple? > > Also this section should maybe highlight the affects excessive use of FEC > can have on the network. Just as a reminder to the clueless that "hey, I > see loss, lets keep adding FEC until I get all my data through" is not > necessarily a good idea... Certainly, the IESG requested that we add a > note to this effect when we were writing the redundancy draft, and I > think it's applicable here too. Good idea. I'll do that. > > - I'm not convinced that putting parity FEC and Reed-Solomon into one > document is the best way of doing this. They seem to be different enough > that two documents should maybe be written? After the last meeting, there was a brief discussion about this. I recall that the quick decision was to use a single specification. But, if two are warranted, I have no problem with this. It seems that the two approaches do share enough infrastructure to perhaps be in the same document, though. Opinions? -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Aug 13 23:48:40 1998 From rem-conf-request@es.net Thu Aug 13 23:48:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z7DZj-0001KP-00; Thu, 13 Aug 1998 23:42:59 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z7DZi-0001JW-00; Thu, 13 Aug 1998 23:42:58 -0700 Received: from big-bear (big-bear.precept.com [204.162.119.41]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id XAA29977; Thu, 13 Aug 1998 23:41:57 -0700 (PDT) Date: Thu, 13 Aug 1998 23:41:57 -0700 (PDT) From: Stephen Casner X-Sender: casner@big-bear.precept.com To: rem-conf@es.net cc: Vern Paxson Subject: Colin Perkins added as AVT co-chair Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list To the Audio/Video Transport Working Group: I am please to announce that Colin Perkins from UCL has accepted my request to serve as co-chair of AVT and that the IESG has given its approval. It is my hope that together Colin and I can keep the the working group's business moving ahead better than I have done alone. I have said on more than one occasion in the past that after 6 years it should be time for the WG to wrap up, yet we continue to have relevant new work to address. The first order of business is to update the WG charter, since we passed the end of the current one some time ago. The new charter needs to establish milestones for completion of the work currently on the agenda, and also to lay out our expectations for what continuing work on payload formats or other activities there might be. It may be appropriate for the group to go dormant and be rejuvenated as new work arises. I'll be working with Colin to draft a proposed updated charter and send it to the list so that we can get WG concurrence on it in Chicago and then pass it to the IESG for approval. -- Steve From rem-conf Fri Aug 14 09:53:38 1998 From rem-conf-request@es.net Fri Aug 14 09:53:37 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z7MrO-00072R-00; Fri, 14 Aug 1998 09:37:50 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0z7MrN-00072G-00; Fri, 14 Aug 1998 09:37:49 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Aug 1998 17:37:44 +0100 To: Jonathan Rosenberg cc: rem-conf@es.net Subject: Re: draft-ietf-avt-fec-03 In-reply-to: Your message of "Thu, 13 Aug 1998 16:51:20 EDT." <35D351C8.AEC52211@dnrc.bell-labs.com> Date: Fri, 14 Aug 1998 17:37:42 +0100 Message-ID: <4664.903112662@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Jonathan Rosenberg writes: ... >> - The security considerations section should possibly be expanded. The use >> of FEC makes changing encryption keys a little harder. Simple example: >> a f(a,b) b >> with a and b being encrypted with different keys, which key is used for >> the FEC packet? Same problem occurs when enabling/disabling encryption. >> The issue should, at least, be noted. > >Good point. I don't think this is hard. You basically switch keys on the >media stream, and at some point, switch keys on the FEC stream. These >need not be synchronized. You would make the determination about when >the switch occurs separately for each stream. It's a little tricky if you want to repair across the point when the media encryption changes, since there is some FEC data which is protecting media data encrypted with both old and new keys. If you do FEC on the _encrypted_ packets, then everything should be fine, but if you do FEC on the clear-data and then encrypt the result, problems can occur. Colin From rem-conf Fri Aug 14 10:32:01 1998 From rem-conf-request@es.net Fri Aug 14 10:32:01 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z7NYB-0000Kg-00; Fri, 14 Aug 1998 10:22:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0z7NYA-0000KW-00; Fri, 14 Aug 1998 10:22:02 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Fri Aug 14 13:20:51 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id NAA12569; Fri, 14 Aug 1998 13:21:08 -0400 (EDT) Message-ID: <35D4715F.64978F57@dnrc.bell-labs.com> Date: Fri, 14 Aug 1998 13:18:23 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Colin Perkins CC: rem-conf@es.net Subject: Re: draft-ietf-avt-fec-03 References: <4664.903112662@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 Colin Perkins wrote: > > >Good point. I don't think this is hard. You basically switch keys on the > >media stream, and at some point, switch keys on the FEC stream. These > >need not be synchronized. You would make the determination about when > >the switch occurs separately for each stream. > > It's a little tricky if you want to repair across the point when the media > encryption changes, since there is some FEC data which is protecting media > data encrypted with both old and new keys. > > If you do FEC on the _encrypted_ packets, then everything should be fine, > but if you do FEC on the clear-data and then encrypt the result, problems > can occur. I don't see this as a problem. Can you clarify what the difficulty is? -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Fri Aug 14 10:53:43 1998 From rem-conf-request@es.net Fri Aug 14 10:53:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z7O0g-0001BV-00; Fri, 14 Aug 1998 10:51:30 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0z7O0e-0001BL-00; Fri, 14 Aug 1998 10:51:29 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Aug 1998 18:51:24 +0100 To: Jonathan Rosenberg cc: rem-conf@es.net Subject: Re: draft-ietf-avt-fec-03 In-reply-to: Your message of "Fri, 14 Aug 1998 13:18:23 EDT." <35D4715F.64978F57@dnrc.bell-labs.com> Date: Fri, 14 Aug 1998 18:51:22 +0100 Message-ID: <14881.903117082@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Jonathan Rosenberg writes: >Colin Perkins wrote: >> >> >Good point. I don't think this is hard. You basically switch keys on the >> >media stream, and at some point, switch keys on the FEC stream. These >> >need not be synchronized. You would make the determination about when >> >the switch occurs separately for each stream. >> >> It's a little tricky if you want to repair across the point when the media >> encryption changes, since there is some FEC data which is protecting media >> data encrypted with both old and new keys. >> >> If you do FEC on the _encrypted_ packets, then everything should be fine, >> but if you do FEC on the clear-data and then encrypt the result, problems >> can occur. > >I don't see this as a problem. Can you clarify what the difficulty is? For example, assume you're using the following scheme: a,b,c,d,e,f -> a, f(a,b), b, f(b,c), c, f(c,d), d, ... and wish to send packets a,b unencrypted and packets c,d encrypted. The FEC operation works on unencrypted media data, and the resulting FEC packets are then encrypted. If f(b,c) is encrypted it cannot be used for recovery of b by receivers which don't have the encryption key. However, if the FEC is generated from the encrypted packets, f(b,c) is still useful for those receivers which don't have the key, yet doesn't help them obtain information about c. I'm not sure it's a big deal..... Colin From rem-conf Fri Aug 14 13:27:39 1998 From rem-conf-request@es.net Fri Aug 14 13:27:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z7QPI-0003Lz-00; Fri, 14 Aug 1998 13:25:04 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0z7QPG-0003Lp-00; Fri, 14 Aug 1998 13:25:02 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id QAA20453; Fri, 14 Aug 1998 16:25:01 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: rem-conf@es.net, mbone@isi.edu cc: sdr@cs.ucl.ac.uk Subject: New sdr 2.5a5 released Date: Fri, 14 Aug 1998 16:25:00 -0400 Message-ID: <20451.903126300@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A new version of the Multicast Session Directory tool sdr is now available from UCL's ftp server: ftp://cs.ucl.ac.uk/mice/sdr/2.5a5. Binaries are available there for FreeBSD, Irix, Linux, Solaris and Windows 95/98/NT4. Source is also there if you need to build sdr for other platforms. If you do so, AND YOU ARE OUTSIDE THE USA, please contribute the binary and Makefile back to Colin Perkins (C.Perkins@cs.ucl.ac.ul) at UCL. The version of sdr fixes a number of bugs that have been observed with previous versions. In addition, it implements the Session Initiation Protocol more or less in compliance with the current internet draft. (I say more or less, because the SIP code is currently relatively untested, and SIP over TCP is known to be buggy in this version of sdr). The SIP implementation in sdr is mine - please mail me if you discover any problems with it. Also Ed Whelan (E.Whelan@cs.ucl.ac.uk) and Goli Montasser-Kohsari (G.MontasserKohsari@cs.ucl.ac.uk) at UCL have fully implemented the SAP security specification. In this latest version of SDR the following security features have been included: 1) Media Tool Encryption The media tools can, if the tool supports it, be started encrypted. A key is specified when creating the announcement and this can be either a randomly generated key or a key specified by the user. Different random keys are used by default but the user can set each tool to use the same key if desired. The tools currently support symmetric DES encryption. 2) Session Announcement Encryption The session announcement can be encrypted either symmetrically or asymmetrically. a) Symmetric Encryption The algorithm used in this case is DES. b) Asymmetric Encryption Either PGP or PKCS#7 security formats can be used. In the case of PGP the user must have PGP 2.6.3 installed whereas with PKCS#7 the SECUDE security toolkit is necessary. With asymmetric encryption the announcment is encrypted with the public key of a group and can only be decrypted by members of the group who have access to the corresponding private key. The group key pairs are distributed by secure means prior to the setting up of a conference group. 3) Session Announcement Authentication The session announcemnt can be authenticated using either PGP or PKCS#7 (SECUDE). In this case the session announcement is signed with the originator's private key and so anyone with access to the originator's public key can be sure that the announcement came from the originator and has not been changed en route. It is also an option to send the originator's certificate along with the signed announcement. Any combination of tool encryption, session announcemnt encryption and session announcement authentication are allowed. The precise formats used for the above features are as detailed in the latest SAP specification Please mail Ed or Goli if you have any comments on the security implementation, or mail sdr@cs.ucl.ac.uk to reach us all. Since sdr now utilizes strong encryption, I am no longer the primary maintainer of the code - the group at UCL have taken over this task. General sdr bug reports should be sent to sdr@cs.ucl.ac.uk. Cheers, Mark From rem-conf Sat Aug 15 13:59:08 1998 From rem-conf-request@es.net Sat Aug 15 13:59:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z7nBH-0004Ji-00; Sat, 15 Aug 1998 13:44:07 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0z7nBF-0004JY-00; Sat, 15 Aug 1998 13:44:05 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Sat Aug 15 16:42:13 EDT 1998 Received: from dnrc.bell-labs.com ([135.17.200.54]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA15867; Sat, 15 Aug 1998 16:42:28 -0400 (EDT) Message-ID: <35D5F332.9AF973B5@dnrc.bell-labs.com> Date: Sat, 15 Aug 1998 16:44:34 -0400 From: Jonathan Rosenberg Organization: Bell Laboratories X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: Colin Perkins CC: rem-conf@es.net Subject: Re: draft-ietf-avt-fec-03 References: <14881.903117082@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 Colin Perkins wrote: > > >I don't see this as a problem. Can you clarify what the difficulty is? > > For example, assume you're using the following scheme: > a,b,c,d,e,f -> a, f(a,b), b, f(b,c), c, f(c,d), d, ... > and wish to send packets a,b unencrypted and packets c,d encrypted. The FEC > operation works on unencrypted media data, and the resulting FEC packets > are then encrypted. If f(b,c) is encrypted it cannot be used for recovery > of b by receivers which don't have the encryption key. But, if the receivers don't have the key, they can't decrypt the media anyway, so the difference is just packet b. I don't see this as a problem, since they won't get the rest of the conversation anyway. > > However, if the FEC is generated from the encrypted packets, f(b,c) is > still useful for those receivers which don't have the key, yet doesn't > help them obtain information about c. Besides this, are there any reasons for doing the FEC after encryption as opposed to before? I'm wondering if there are any impacts on the effeciveness of the algorithms, or something like that. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Sun Aug 16 13:49:13 1998 From rem-conf-request@es.net Sun Aug 16 13:49:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z89dA-0004Up-00; Sun, 16 Aug 1998 13:42:24 -0700 Received: from sasa-torre.teran.com.ni (fenix.sasa.com.ni) [200.30.51.36] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0z89d7-0004Ud-00; Sun, 16 Aug 1998 13:42:22 -0700 Received: from cielo.sasa.com.ni (cielo.sasa.com.ni [200.30.51.206]) by fenix.sasa.com.ni (8.7.4/8.7.3) with ESMTP id PAA10808 for ; Sun, 16 Aug 1998 15:05:37 -0600 (CST) Received: by cielo.sasa.com.ni with Internet Mail Service (5.5.1960.3) id ; Sun, 16 Aug 1998 14:47:33 -0600 Message-ID: <20EC40B45418D2118E3800609708B11B021B41@cielo.sasa.com.ni> From: Amacias Toledo To: "'rem-conf@es.net'" Subject: Information H.323 standard Date: Sun, 16 Aug 1998 14:47:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello Don Kordick. This quite interesting this of the H.323 that is the estandar for the communication of audio and video for LAN/WAN, they could say me where I could find information specify of this protocol, something as well as the RFC of INTERNIC. Since attempts to consent in the ITU-T but all these documents are charged. They for chance don't know one point where could go down this information freely, my objectives are understand the new technology mere and make a species of study-summary of this Estandar. For the school. Thank you for their help From rem-conf Mon Aug 17 06:45:27 1998 From rem-conf-request@es.net Mon Aug 17 06:45:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8PNs-0003u2-00; Mon, 17 Aug 1998 06:31:40 -0700 Received: from www.radio.cbc.ca [159.33.1.50] by mail1.es.net with smtp (Exim 1.81 #2) id 0z8PNq-0003ts-00; Mon, 17 Aug 1998 06:31:38 -0700 Received: from localhost (594 bytes) by www.radio.cbc.ca via send-mail with P:stdio/R:inet_hosts/T:smtp (sender: ) (ident using unix) id for ; Mon, 17 Aug 1998 09:31:50 -0400 (EDT) (Smail-3.2.0.100 1997-Dec-8 #1 built 1998-Jul-24) Message-Id: Date: Mon, 17 Aug 1998 09:31:50 -0400 (EDT) From: jlawlor@radio.cbc.ca (Joe Lawlor) To: rem-conf@es.net Subject: Web page url's X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I apologize if this is the wrong place to ask this question. Is somebody working on a type of That can allow me to call an Mbone stream from a Web Page? Who would do such a thing? Is it a matter of setting up Mime-types? Where might this kind of thing get developed if it is not already available? Thanks you for your patience. Joe Lawlor CBC Radio on the Internet Project jlawlor@www.radio.cbc.ca Check out "http://www.radio.cbc.ca/" From rem-conf Mon Aug 17 07:26:07 1998 From rem-conf-request@es.net Mon Aug 17 07:26:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8QCB-0004tD-00; Mon, 17 Aug 1998 07:23:39 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0z8QC9-0004t3-00; Mon, 17 Aug 1998 07:23:37 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id KAA24547; Mon, 17 Aug 1998 10:23:18 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: jlawlor@radio.cbc.ca (Joe Lawlor) cc: rem-conf@es.net Subject: Re: Web page url's In-reply-to: Your message of "Mon, 17 Aug 1998 09:31:50 EDT." Date: Mon, 17 Aug 1998 10:23:18 -0400 Message-ID: <24545.903363798@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >Is somebody working on a type of That can allow me to call >an Mbone stream from a Web Page? >Who would do such a thing? >Is it a matter of setting up Mime-types? >Where might this kind of thing get developed if it is not already available? There are two standard ways to do this: 1. Have the hyperlink fetch the session description using HTTP. The response will be in SDP (RFC 2327) with content type application/sdp. The client parses the SDP and starts the media tools (or receives the streams itself). 2. Have the hyperlink be of type rtsp (See RFC 2326). Use RTSP to get a session description and join the session. Which of the two you might choose depends on whether or not you need the extra control you get from RTSP. Cheers, Mark From rem-conf Mon Aug 17 07:57:33 1998 From rem-conf-request@es.net Mon Aug 17 07:57:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8Qei-0005oG-00; Mon, 17 Aug 1998 07:53:08 -0700 Received: from omega.xerox.com (alpha.xerox.com) [13.1.64.95] by mail1.es.net with smtp (Exim 1.81 #2) id 0z8Qeg-0005nn-00; Mon, 17 Aug 1998 07:53:06 -0700 Received: from mango.parc.xerox.com ([13.1.102.232]) by alpha.xerox.com with SMTP id <40739(2)>; Mon, 17 Aug 1998 07:52:00 PDT Received: from mango.parc.xerox.com (localhost [127.0.0.1]) by mango.parc.xerox.com (8.8.8/8.8.8) with ESMTP id HAA05371; Mon, 17 Aug 1998 07:51:52 -0700 (PDT) (envelope-from fenner@mango.parc.xerox.com) Message-Id: <199808171451.HAA05371@mango.parc.xerox.com> To: Mark Handley cc: jlawlor@radio.cbc.ca (Joe Lawlor), rem-conf@es.NET Subject: Re: Web page url's In-reply-to: Your message of "Mon, 17 Aug 1998 07:23:18 PDT." <24545.903363798@north.lcs.mit.edu> Date: Mon, 17 Aug 1998 07:51:52 PDT From: Bill Fenner X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <24545.903363798@north.lcs.mit.edu>you write: >1. Have the hyperlink fetch the session description using HTTP. The >response will be in SDP (RFC 2327) with content type application/sdp. Small sdp messages (smaller than 1K after data-URL-encoding) can be encoded directly in an HTML page without another round trip to the server, using the data: URL type. I've been thinking that this encoding is appropriate for SD and SDP for a long time; now that there's a general data: URL (see RFC 2397) there doesn't have to be an SDP-specific way of doing it. i.e. Click here Bill From rem-conf Mon Aug 17 08:51:50 1998 From rem-conf-request@es.net Mon Aug 17 08:51:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8RWS-0006tZ-00; Mon, 17 Aug 1998 08:48:40 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0z8RWQ-0006tP-00; Mon, 17 Aug 1998 08:48:38 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 17 Aug 1998 16:48:30 +0100 To: Jonathan Rosenberg cc: rem-conf@es.net Subject: Re: draft-ietf-avt-fec-03 In-reply-to: Your message of "Sat, 15 Aug 1998 16:44:34 EDT." <35D5F332.9AF973B5@dnrc.bell-labs.com> Date: Mon, 17 Aug 1998 16:48:28 +0100 Message-ID: <11220.903368908@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Jonathan Rosenberg writes: >Colin Perkins wrote: >> For example, assume you're using the following scheme: >> a,b,c,d,e,f -> a, f(a,b), b, f(b,c), c, f(c,d), d, ... >> and wish to send packets a,b unencrypted and packets c,d encrypted. The FEC >> operation works on unencrypted media data, and the resulting FEC packets >> are then encrypted. If f(b,c) is encrypted it cannot be used for recovery >> of b by receivers which don't have the encryption key. > >But, if the receivers don't have the key, they can't decrypt the media >anyway, so the difference is just packet b. I don't see this as a >problem, since they won't get the rest of the conversation anyway. Sure, it only affects the tail-end of a stream where the key is going to change such that some receivers don't have the new key. As such it's not a big deal in most cases... >> However, if the FEC is generated from the encrypted packets, f(b,c) is >> still useful for those receivers which don't have the key, yet doesn't >> help them obtain information about c. > >Besides this, are there any reasons for doing the FEC after encryption >as opposed to before? I'm wondering if there are any impacts on the >effeciveness of the algorithms, or something like that. I don't think it'll affect the encryption, but I'm hardly an expert in the way DES works..... Colin From rem-conf Mon Aug 17 10:41:51 1998 From rem-conf-request@es.net Mon Aug 17 10:41:50 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8TDy-0000he-00; Mon, 17 Aug 1998 10:37:42 -0700 Received: from el-postino.s-vision.com [207.108.173.5] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z8TDw-0000hU-00; Mon, 17 Aug 1998 10:37:41 -0700 Received: by el-postino.s-vision.com with Internet Mail Service (5.5.2232.9) id ; Mon, 17 Aug 1998 11:37:41 -0600 Message-ID: <00D7B108BAFFD011B66D00A0C903629C32BBCB@el-postino.s-vision.com> From: Richard Shields To: rem-conf@es.net Subject: H.263+ RTP Payload Header? Date: Mon, 17 Aug 1998 11:37:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I'm looking for the H.263+ RTP payload header description. Can someone give me a pointer to it's location? Thanks, Richard From rem-conf Mon Aug 17 11:54:53 1998 From rem-conf-request@es.net Mon Aug 17 11:54:52 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8UNz-0001uW-00; Mon, 17 Aug 1998 11:52:07 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0z8UNy-0001uL-00; Mon, 17 Aug 1998 11:52:06 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Aug 17 14:50:12 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id OAA29336; Mon, 17 Aug 1998 14:50:28 -0400 (EDT) Message-ID: <35D87B00.35826540@dnrc.bell-labs.com> Date: Mon, 17 Aug 1998 14:48:32 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Colin Perkins CC: rem-conf@es.net Subject: Re: draft-ietf-avt-fec-03 References: <11220.903368908@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 Colin Perkins wrote: > > >But, if the receivers don't have the key, they can't decrypt the media > >anyway, so the difference is just packet b. I don't see this as a > >problem, since they won't get the rest of the conversation anyway. > > Sure, it only affects the tail-end of a stream where the key is going to > change such that some receivers don't have the new key. As such it's not > a big deal in most cases... Yes, I think we can just not worry about this one. > >Besides this, are there any reasons for doing the FEC after encryption > >as opposed to before? I'm wondering if there are any impacts on the > >effeciveness of the algorithms, or something like that. > > I don't think it'll affect the encryption, but I'm hardly an expert in the > way DES works..... My concern was less the actual algorithm correctness, but rather if there were any protocol related security issues, like denial of service or an opening for some known-ciphertext attacks. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Mon Aug 17 23:34:23 1998 From rem-conf-request@es.net Mon Aug 17 23:34:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8fG0-00070T-00; Mon, 17 Aug 1998 23:28:36 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z8fFy-00070D-00; Mon, 17 Aug 1998 23:28:34 -0700 Received: from big-bear (big-bear.precept.com [204.162.119.41]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id XAA11635; Mon, 17 Aug 1998 23:27:33 -0700 (PDT) Date: Mon, 17 Aug 1998 23:27:33 -0700 (PDT) From: Stephen Casner X-Sender: casner@big-bear.precept.com To: rem-conf@es.net Subject: Proposed agenda for AVT WG at IETF in Chicago Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list AVT Working Group: Here's the proposed agenda for the AVT meeting next week. Please note that the second session was moved from morning to afternoon to accommodate some some other scheduling conflict. If you requested a slot and we overlooked it, or if you have other comments, please let us know. Also, please note the drafts associated with each topic. In particular, please take a look at the revised RTP protocol specification draft-ietf-avt-rtp-new-01.txt,.ps and RTP audio/video profile draft-ietf-avt-profile-new-03.txt,.ps. These are in preparation for going to draft standard. Another message with details about them will follow. And lastly, we'd appreciate it if some folks familiar with payload formats and with codecs would take a look at the QCELP draft draft-mckay-qcelp-01.txt to see if it is ready for WG last call. -- Steve Casner and Colin Perkins Audio/Video Transport WG A G E N D A Wednesday, August 26, 15:30-17:30 - Introduction and status [Casner] 15 - IESG status on: draft-tynan-rtp-bt656-03.txt draft-ietf-avt-jpeg-new-02.txt draft-ietf-avt-crtp-05.txt draft-ietf-avt-rtp-h263-video-02.txt - Drafts to act upon: - Guidelines for RTP payload formats draft-ietf-avt-rtp-format-guidelines-00.txt,.ps - RTP Payload Format for PureVoice(tm) Audio draft-mckay-qcelp-01.txt ? - Status of RTP MIB and H.media MIB [Baugher] 5 - RTP multiplexing protocol proposals: 45 draft-ietf-avt-aggregation-00.txt [Rosenberg] ? draft-tanigawa-rtp-multiplex-00.txt [Hoshi, Tsukada, Tanigawa] late draft from Nokia [Senthil] - DMIF for RTP/MPEG4 [Balabanian] 10 draft-ietf-avt-rtp-mpeg4-dmif-00.txt - Discussion 45 Thursday, August 27, 13:00-15:00 - RTP spec and profile issues [Casner] 30 draft-ietf-avt-rtp-new-01.txt, .ps draft-ietf-avt-profile-new-03.txt, .ps - Improvement to SSRC scaling [Rosenberg] 10 draft-ietf-avt-rtpsample-00.txt - Update on RTP redundancy mechanism [Perkins] 10 - FEC payload format [Rosenberg] 15 draft-ietf-avt-fec-03.txt - AVT revised charter bashing 15 From rem-conf Tue Aug 18 00:00:58 1998 From rem-conf-request@es.net Tue Aug 18 00:00:57 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8fjM-0007mn-00; Mon, 17 Aug 1998 23:58:56 -0700 Received: from isb.worldwerx.com.pk [194.133.48.216] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z8fjI-0007ju-00; Mon, 17 Aug 1998 23:58:53 -0700 Received: from riqbal (pc34.worldwerx.com.pk [192.168.5.34]) by isb.worldwerx.com.pk (8.9.0/8.9.0) with SMTP id LAA01635 for ; Tue, 18 Aug 1998 11:51:16 +0500 Message-Id: <199808180651.LAA01635@isb.worldwerx.com.pk> From: "Rashed Iqbal" Organization: Worldwerx, Islamabad To: rem-conf@es.net Date: Tue, 18 Aug 1998 12:06:47 PKT MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: The Padding Bit X-Confirm-Reading-To: "Rashed Iqbal" Priority: normal X-mailer: Pegasus Mail for Win32 (v3.01b) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hello All, I have a small query regarding padding as specified by RFC 1889. I'll be grateful if someone confirms (or refute!) my understanding as given below. > RFC 1889 reads: > padding (P): 1 bit > If the padding bit is set, the packet contains > one or more additional padding octets at the > end which are not part of the payload. The > last octet of the padding contains a count of > how many padding octets should be ignored. > Padding may be needed by some encryption > algorithms with fixed block sizes or for > carrying several RTP packets in a lower-layer > protocol data unit. MY UNDERSTANDING is that if only one padding octet is to be appended at the end of payload, the last octet will contain 0x01 and this octet will be the very octet that will be ignored by a decoder. In this case, if the padding bit is set, it is illegal to have a zero value in the last octet. Rashed From rem-conf Tue Aug 18 06:03:17 1998 From rem-conf-request@es.net Tue Aug 18 06:03:15 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8lGo-0003Wv-00; Tue, 18 Aug 1998 05:53:50 -0700 Received: from is1-50.antd.nist.gov (is1-55.antd.nist.gov) [129.6.50.251] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z8lGn-0003Wl-00; Tue, 18 Aug 1998 05:53:49 -0700 Received: from muon.ncsl.nist.gov (muon.ncsl.nist.gov [129.6.55.158]) by is1-55.antd.nist.gov (8.8.8/8.8.8) with SMTP id IAA16840; Tue, 18 Aug 1998 08:52:07 -0400 (EDT) Message-ID: <002e01bdcaa7$1c26dca0$9e370681@muon.ncsl.nist.gov> Reply-To: "Wo Chang" From: "Wo Chang" To: Cc: Subject: Looking for RTP-based MPEG-2 player Date: Tue, 18 Aug 1998 08:52:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Are there any RTP-based MPEG-2 players available? Public domain and commercial are welcome. I have looked at the followings but doesn't seem to meet my requirement (be able to play MPEG-2 stream over RTP): * vat/vic - support RTP but not with MPEG-2 (yet) * IP/TV - support RTP but only with MPEG-1 (I'm running an evaluation copy, MPEG-1 works ok but not MPEG-2. If IP/TV can handle MPEG-2, my problem solved) * Sun's ShowME TV - support RTP but with MPEG-1 * ICAST - support RTP with ITU H.261 and ITU H.263 * Xing's StreamWorks 4.0 (release Oct. 1998) - support MPEG-1 and MPEG-2, but not sure if it is RTP-based. Any pointers are greatly appreciated. Best regards, --Wo Chang From rem-conf Tue Aug 18 07:12:57 1998 From rem-conf-request@es.net Tue Aug 18 07:12:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8mLe-0004lE-00; Tue, 18 Aug 1998 07:02:54 -0700 Received: from odin.ietf.org (ietf.org) [132.151.1.176] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z8mLc-0004k0-00; Tue, 18 Aug 1998 07:02:52 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA08749 for ; Tue, 18 Aug 1998 10:01:48 -0400 (EDT) Message-Id: <199808181401.KAA08749@ietf.org> To: rem-conf@es.net Subject: 42nd IETF-Multicast Schedule Date: Tue, 18 Aug 1998 10:01:47 -0400 From: Marcia Beaulieu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Chicago IETF Multicast Guide (as of 08/18/98) Following is the tentative schedule of plenary meetings and working group sessions to be transmitted; to interpret the acronyms, see the agenda at http://www.ietf.org/meetings/agenda_chic.txt It is possible that this schedule will be modified. MULTICAST GUIDE Note that times are in Central Time. UTC (aka GMT) also provided. MONDAY 0930-1130 1300-1500 1530-1730 1930-2200 (UTC) 1430-1630 1800-2000 2030-2230 2430-0300 =========+===========+===========+===========+===========+ CHAN 1 | mobileip | iptel | ion | | =========+===========+===========+===========+===========+ CHAN 2 | nfsv4 | nfsv4 | mboned | policy | =========+===========+===========+===========+===========+ TUESDAY 0900-1000 1015-1115 1300-1400 1415-1515 (UTC) 1400-1500 1515-1615 1800-1900 1915-2015 =========+===========+===========+===========+===========+ CHAN 1 | rsvp | issll | malloc | malloc | =========+===========+===========+===========+===========+ CHAN 2 | ippm | idmr | | ipsec | =========+===========+===========+===========+===========+ TUESDAY (CON'T) 1545-1645 1700-1800 (UTC) 2045-2145 2200-2300 =========+===========+===========+ CHAN 1 | | | =========+===========+===========+ CHAN 2 | ipngwg | ipngwg | =========+===========+===========+ WEDNESDAY 0900-1130 1300-1500 1530-1730 1930-2200 (UTC) 1400-1630 1800-2000 2030-2230 2430-0300 =========+===========+===========+===========+===========+ CHAN 1 | nat | smiv2 | avt | plenary | =========+===========+===========+===========+===========+ CHAN 2 | diffserv | mmusic | tcpsat | plenary | =========+===========+===========+===========+===========+ THURSDAY 0900-1130 1300-1500 1530-1730 (UTC) 1400-1630 1800-2000 2030-2230 =========+===========+===========+===========+ CHAN 1 | ipngwg | avt | pint | =========+===========+===========+===========+ CHAN 2 | diffserv | rap | | =========+===========+===========+===========+ FRIDAY 0900-1130 (UTC) 1400-1630 =========+===========+ CHAN 1 | tcpimpl | =========+===========+ CHAN 2 | | =========+===========+ Each day's program may also be replayed by tape delay from: 2330 (UTC): 0430 Advice for remote participants: Please keep your microphones muted and your video transmissions disabled during the plenaries and working group sessions, unless or until invited to respond by the chair of the session. Vat users can disable reception of accidental sources of audio multicasts (such as people who forget to mute their mics) by clicking in the box next to that source's name. From rem-conf Tue Aug 18 07:12:57 1998 From rem-conf-request@es.net Tue Aug 18 07:12:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8mNJ-0004la-00; Tue, 18 Aug 1998 07:04:37 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0z8mNH-0004lQ-00; Tue, 18 Aug 1998 07:04:36 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 18 Aug 1998 15:03:13 +0100 To: Rashed Iqbal cc: rem-conf@es.net Subject: Re: The Padding Bit In-reply-to: Your message of "Tue, 18 Aug 1998 12:06:47 +0700." <199808180651.LAA01635@isb.worldwerx.com.pk> Date: Tue, 18 Aug 1998 15:03:06 +0100 Message-ID: <4794.903448986@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Rashed Iqbal writes: >Hello All, > >I have a small query regarding padding as >specified by RFC 1889. I'll be grateful if >someone confirms (or refute!) my understanding >as given below. > >> RFC 1889 reads: >> padding (P): 1 bit >> If the padding bit is set, the packet contains >> one or more additional padding octets at the >> end which are not part of the payload. The >> last octet of the padding contains a count of >> how many padding octets should be ignored. >> Padding may be needed by some encryption >> algorithms with fixed block sizes or for >> carrying several RTP packets in a lower-layer >> protocol data unit. > >MY UNDERSTANDING is that if only one padding >octet is to be appended at the end of payload, >the last octet will contain 0x01 and this octet >will be the very octet that will be ignored by a >decoder. In this case, if the padding bit is >set, it is illegal to have a zero value in the >last octet. That is my understanding. In draft-ietf-avt-rtp-new-01 this paragraph is clarified to say "The last octet of the padding contains a count of how many padding octets should be ignored, including itself". Colin From rem-conf Tue Aug 18 09:13:00 1998 From rem-conf-request@es.net Tue Aug 18 09:13:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8oIy-0007Bh-00; Tue, 18 Aug 1998 09:08:16 -0700 Received: from artemis.rus.uni-stuttgart.de [129.69.18.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z8oIw-0007BX-00; Tue, 18 Aug 1998 09:08:15 -0700 Received: from kssun7.rus.uni-stuttgart.de (kssun7.rus.uni-stuttgart.de [129.69.30.17]) by artemis.rus.uni-stuttgart.de (8.8.8/8.8.8) with ESMTP id SAA24745; Tue, 18 Aug 1998 18:05:09 +0200 (MET DST) env-from (christ@rus.uni-stuttgart.de) Received: from rus.uni-stuttgart.de (ksat10.rus.uni-stuttgart.de [129.69.30.170]) by kssun7.rus.uni-stuttgart.de (8.8.8/8.8.8) with ESMTP id RAA21627; Tue, 18 Aug 1998 17:55:11 +0200 (MET DST) Message-ID: <35D9B45C.9302ECF1@rus.uni-stuttgart.de> Date: Tue, 18 Aug 1998 19:05:32 +0200 From: Paul Christ X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: c.perkins@cs.ucl.ac.uk, christ@rus.uni-stuttgart.de, wesner@rus.uni-stuttgart.de CC: rem-conf@es.net, Christine Guillemot Subject: Status of Generic Payload Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Colin, dear all, (Colin, remember me - I am with Andreas Rozek in MECCANO :-) Finally we at RUS too ended up in the avt group etc. <= In the ACTS COMIQS project, we are working in the direction of a payload, as generic as possible, that could be usable for different stream types, including audio, video, scene description (in the MPEG-4 sense), and that could support error protection mechanisms (under the form of redundant data, or FEC) tailored to data segment types with different levels of priority and/or latency tolerance (e.g; decoder configuration information..... Sending our colleague Stefan Wesner (a talented but newcomer ...) over to Chicago - and finding nothing in the agenda concerning 'the generic payload' - question: What is the status with respect to generic payload concepts proposed by microsoft and sun at the last IETF meeting. (Knowing we missed the deadline this time we may nevertheless send you our ideas wrt generic payload towards the end of the week) All the best Paul From rem-conf Tue Aug 18 09:47:51 1998 From rem-conf-request@es.net Tue Aug 18 09:47:51 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8ou6-0000KF-00; Tue, 18 Aug 1998 09:46:38 -0700 Received: from bells.cs.ucl.ac.uk [128.16.5.31] by mail1.es.net with smtp (Exim 1.81 #2) id 0z8ou2-0000K2-00; Tue, 18 Aug 1998 09:46:37 -0700 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 18 Aug 1998 17:46:04 +0100 To: Paul Christ cc: wesner@rus.uni-stuttgart.de, rem-conf@es.net, christine.guillemot@irisa.fr Subject: Re: Status of Generic Payload In-reply-to: Your message of "Tue, 18 Aug 1998 19:05:32 +0200." <35D9B45C.9302ECF1@rus.uni-stuttgart.de> Date: Tue, 18 Aug 1998 17:46:03 +0100 Message-ID: <12982.903458763@cs.ucl.ac.uk> From: Colin Perkins X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> Paul Christ writes: >Colin, dear all, >(Colin, remember me - I am with Andreas Rozek in MECCANO :-) I remember, welcome! >Finally we at RUS too ended up in the avt group etc. <= > >In the ACTS COMIQS project, we are working in the direction of a >payload, as generic as possible, that could be usable for different >stream types, including audio, video, scene description (in the MPEG-4 >sense), and that could support error protection mechanisms >(under the form of redundant data, or FEC) tailored to data segment >types with different levels of priority and/or latency tolerance (e.g; >decoder configuration information..... > >Sending our colleague Stefan Wesner (a talented but newcomer ...) >over to Chicago - and finding nothing in the agenda concerning >'the generic payload' - question: > >What is the status with respect to generic payload concepts >proposed by microsoft and sun at the last IETF meeting. The two groups agreed to work together to produce a joint proposal. To the best of my knowledge this merger is not yet complete, so no agenda time was requested for this meeting. Maybe someone working on this could give an update on the current state of the work for the list? Regards, Colin From rem-conf Tue Aug 18 11:17:22 1998 From rem-conf-request@es.net Tue Aug 18 11:17:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8qHj-0001gB-00; Tue, 18 Aug 1998 11:15:07 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z8qHi-0001g1-00; Tue, 18 Aug 1998 11:15:06 -0700 Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id KAA13352 for ; Tue, 18 Aug 1998 10:56:04 -0700 Received: from scv4.apple.com (scv4.apple.com [17.128.100.142]) by mailgate.apple.com (mailgate.apple.com2.0.15) with ESMTP id ; Tue, 18 Aug 1998 10:55:37 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv4.apple.com (8.8.5/8.8.5) with ESMTP id KAA16076; Tue, 18 Aug 1998 10:55:26 -0700 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <12982.903458763@cs.ucl.ac.uk> References: "Your message of Tue, 18 Aug 1998 19:05:32 +0200." <35D9B45C.9302ECF1@rus.uni-stuttgart.de> MIME-Version: 1.0 Date: Tue, 18 Aug 1998 10:51:59 -0700 To: Colin Perkins From: Dave Singer Subject: Re: Status of Generic Payload Cc: Paul Christ , wesner@rus.uni-stuttgart.de, rem-conf@es.net, christine.guillemot@irisa.fr Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 5:46 PM +0100 8/18/98, Colin Perkins wrote: >--> Paul Christ writes: >>Colin, dear all, >>(Colin, remember me - I am with Andreas Rozek in MECCANO :-) > >I remember, welcome! > >>Finally we at RUS too ended up in the avt group etc. <= >> >>In the ACTS COMIQS project, we are working in the direction of a >>payload, as generic as possible, that could be usable for different >>stream types, including audio, video, scene description (in the MPEG-4 >>sense), and that could support error protection mechanisms >>(under the form of redundant data, or FEC) tailored to data segment >>types with different levels of priority and/or latency tolerance (e.g; >>decoder configuration information..... >> >>Sending our colleague Stefan Wesner (a talented but newcomer ...) >>over to Chicago - and finding nothing in the agenda concerning >>'the generic payload' - question: >> >>What is the status with respect to generic payload concepts >>proposed by microsoft and sun at the last IETF meeting. > >The two groups agreed to work together to produce a joint proposal. To the >best of my knowledge this merger is not yet complete, so no agenda time was >requested for this meeting. > >Maybe someone working on this could give an update on the current state of >the work for the list? > >Regards, >Colin You are right. Sun, Microsoft and Apple agreed to work on a merged proposal, but none of us have had time to actually do the merge. I think we feel that we ought to solve this problem, but it's not pressing. What would really help is some feedback on the various schemes and ideas presented. We achieved varying levels of complexity and functionality, in these areas: a) packing the media data into RTP packets b) naming the resulting packing (e.g. in an SDP RTPMAP) c) naming the enclosed media data (e.g. in an SDP RTPMAP) David Singer Apple Computer/QuickTime 408-974-3162 From rem-conf Tue Aug 18 14:12:45 1998 From rem-conf-request@es.net Tue Aug 18 14:12:45 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z8sxA-0004XF-00; Tue, 18 Aug 1998 14:06:04 -0700 Received: from 2cust84.tnt16.chi5.da.uu.net (sendmail) [153.36.168.84] by mail1.es.net with smtp (Exim 1.81 #2) id 0z8sx8-0004Wq-00; Tue, 18 Aug 1998 14:06:02 -0700 To: From: Subject: AD: New on-line zine needs YOUR help! Date: Tue, 18 Aug 1998 12:30:25 Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This message is sent in compliance with the new e-mail bill: SECTION 301, Paragraph (a)(2)(C) of s. 1618 Sender : ViewZone, 1 Phelps Lane, Simsbury, CT 06070 Phone : 1-860-651-7433 E-mail : viewzone@cyber-host.net To be removed from our mailing list, simply reply with "REMOVE" in the subject. ----------------------------------------------------------------------- We'd Like Your Help ViewZone is an on-line magazine that looks at life from different angles. It's hard to describe but we think you'll enjoy it - AND we want your opinion. Viewzone is a little crazy at times, thought provoking, sometimes controversial - but always entertaining. """"We hate spam (except for breakfast) - but we thought you'd want to check out this new on-line magazine. It's FREE and, well, we'd like your opinion on what you see.""""" Weird science, humor, reality(!), interesting personalities and interesting adventures... check us out! (e-mail back from the site) We're at: http://www.viewzone.com Gary Vey CEO, Viewzone Magazine From rem-conf Tue Aug 18 23:07:27 1998 From rem-conf-request@es.net Tue Aug 18 23:07:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z91Kn-0000z5-00; Tue, 18 Aug 1998 23:03:01 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z91Km-0000yV-00; Tue, 18 Aug 1998 23:03:00 -0700 Received: from big-bear (big-bear.precept.com [204.162.119.41]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id XAA25380; Tue, 18 Aug 1998 23:01:59 -0700 (PDT) Date: Tue, 18 Aug 1998 23:01:59 -0700 (PDT) From: Stephen Casner X-Sender: casner@big-bear.precept.com To: rem-conf@es.net Subject: Revised RTP spec and profile drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As mentioned in the message about the AVT agenda, I'd like to call your attention to the revised RTP protocol specification draft-ietf-avt-rtp-new-01.txt,.ps and RTP audio/video profile draft-ietf-avt-profile-new-03.txt,.ps. These are in preparation for going to draft standard. The revised RTP spec includes all the pending changes that have been discussed over the past several meetings, except for a couple that are intentionally omitted as noted in the "Resolution of Open Issues" section preceding the Introduction. A new Appendix B lists all the changes from RFC 1889, and the PostScript version of the draft includes changebars for all the changes other than minor wording tweaks. One change not visible is that the last paragraph of the Introduction section in RFC 1889, which suggested that implementers include warnings about bandwidth usage, has been deleted as no longer relevant. I believe this version is pretty close to ready for WG last call for publication as Draft Standard except that I did not manage before the posting deadline to give the draft a complete reading through to change "must" to "MUST", etc., where needed. So, if you want to express concern about what has changed or not changed, now is the time. In particular, the wording in Section 6 making RTCP mandatory for IP multicast environments has been relaxed. Does it provide the right level of motivation now? The revised A/V Profile needs a bit more work before it is ready. Sorry, the insertion of changebars in the PostScript verions is not complete. This draft includes the changes discussed at the last meeting, namely the addition of a static payload type for QCELP but also a statement that no further new static assignments will be made. However, I think Section 3 on registering payload types needs further revision to reflect this change. Another change needed in the Profile is to specify that the encoding names defined therein are to be registered as MIME subtypes (of the audio or video major types), and that this is the method for defining any additional encoding names in the future. This step was one of the conclusions we came to in our discussion of generic payload formats at the last meeting, and was reinforced in a dinner discussion with Harald Alvestrand. I don't know if these encoding names can be registered as MIME subtypes through the profile document itself, or whether another document will be required. In whichever document, it will be necessary to specify what it means to define one of these encoding names, i.e., what information is bound to the name for RTP purposes. This is part of the SDP aspects of the generic payload format problem as listed by Dave Singer. I plan to talk about this as part of the discussion of the RTP spec and profile revisions. BTW, I intended to mention in the agenda message that generic payload formats were not on the agenda because the authors had not yet prepared a merged proposal and preferred to defer the discussion until the next meeting. -- Steve From rem-conf Wed Aug 19 00:48:36 1998 From rem-conf-request@es.net Wed Aug 19 00:48:34 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z92w1-00029H-00; Wed, 19 Aug 1998 00:45:33 -0700 Received: from necom830.hpcl.titech.ac.jp [131.112.32.132] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z92w0-00028z-00; Wed, 19 Aug 1998 00:45:32 -0700 From: Masataka Ohta Message-Id: <199808190734.QAA09166@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA09166; Wed, 19 Aug 1998 16:34:09 +0900 Subject: Re: Web page url's To: jlawlor@radio.cbc.ca (Joe Lawlor) Date: Wed, 19 Aug 98 16:34:07 JST Cc: rem-conf@es.net In-Reply-To: ; from "Joe Lawlor" at Aug 17, 98 9:31 am X-Mailer: ELM [version 2.3 PL11] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Joe; > I apologize if this is the wrong place to ask this question. > > Is somebody working on a type of That can allow me to call > an Mbone stream from a Web Page? Yes. > Who would do such a thing? See: draft-fujikawa-sdp-url-01.txt > Is it a matter of setting up Mime-types? No, because the description needs a lot of parameters without inline headers. FYI, data URL, which describes a description of a stream, neither, is no good. Masataka Ohta From rem-conf Wed Aug 19 08:18:12 1998 From rem-conf-request@es.net Wed Aug 19 08:18:10 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z99rt-000617-00; Wed, 19 Aug 1998 08:09:45 -0700 Received: from smtpott1.nortel.ca [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z99rr-00060x-00; Wed, 19 Aug 1998 08:09:43 -0700 Received: from zcars00t by smtpott1; Wed, 19 Aug 1998 11:09:05 -0400 Received: from ca.nortel.com by zcars00t.ca.nortel.com id <08899-0@zcars00t.ca.nortel.com>; Wed, 19 Aug 1998 11:05:43 -0400 Date: 19 Aug 1998 09:31 EDT Sender: "Vahe Balabanian" To: casner@cisco.com Cc: rem-conf@es.net From: "Vahe Balabanian" Subject: re:Proposed agenda for AVT WG at IETF in Chicago Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear All, In message "Proposed agenda for AVT WG at IETF in Chicago", casner@cisco.com writes: >AVT Working Group: > >Here's the proposed agenda for the AVT meeting next week. ... > > - DMIF for RTP/MPEG4 [Balabanian] 10 > draft-ietf-avt-rtp-mpeg4-dmif-00.txt Please note tha I have an updated version '01' of the above that can be accessed with anonymous from ftp at 192.58.194.75/pub/vahe or at ftp.playground.net/pub/vahe We have been familiarized with MPEG-4 over the last 2 meetings. We realize that MPEG-4 is unlike any existing RTP Payload Type because it has its own stream structure and decoder types defined in separate streams i.e., it contains streams about its streams consisting of Scene and Object Descriptor streams. The issues of mapping MPEG-4 over RTP have now been identified: a) RTP Time Stamp is either derived fom MPEG-4 Composition TS (monotonicaly increasing order not preserved)or from an RTP source clock. An out of band DMIF signal provides the MPEG-4 stream configuration at the time of establishing the stream in order to derive the Composition TS. b) RTP carries a generic payload type. The latter is specified elsewhere. There has been some work in RTP on this with the Payload Type being specified in SDP RTPMAP. Also see d) c) Multistreaming over RTP. There is work being done in AVT on RTP Mux but it requires consistency of RTP Time Stamps for the streams being carried over the RTP Mux. d) Dynamic SDP streaming to correspond to the scene and Object Descriptor streams in MPEG-4. Of course no parallel work exists yet on this in MMUSIC or AVT. At the meeting I would like to get the latest views on the above issues as well as consider the implications of the option below: MPEG4 being modified by AVT/MMUSIC jointly with MPEG for suitable operation over IP as a next generation RTP. This approach is better than piecemeal adjustments to RTP. Any feedback is welcome. Vahe Balabanian balabani@nortel.ca Phone: (613) 763-4721 b) From rem-conf Wed Aug 19 08:18:12 1998 From rem-conf-request@es.net Wed Aug 19 08:18:11 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z99wR-00062L-00; Wed, 19 Aug 1998 08:14:27 -0700 Received: from smtpott1.nortel.ca [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z99wQ-00062B-00; Wed, 19 Aug 1998 08:14:26 -0700 Received: from zcars00t by smtpott1; Wed, 19 Aug 1998 11:13:46 -0400 Received: from ca.nortel.com by zcars00t.ca.nortel.com id <08871-0@zcars00t.ca.nortel.com>; Wed, 19 Aug 1998 11:07:36 -0400 Date: 19 Aug 1998 09:31 EDT Sender: "Vahe Balabanian" To: casner@cisco.com Cc: rem-conf@es.net From: "Vahe Balabanian" Subject: re:Proposed agenda for AVT Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear All, In message "Proposed agenda for AVT WG at IETF in Chicago", casner@cisco.com writes: >AVT Working Group: > >Here's the proposed agenda for the AVT meeting next week. ... > > - DMIF for RTP/MPEG4 [Balabanian] 10 > draft-ietf-avt-rtp-mpeg4-dmif-00.txt Please note tha I have an updated version '01' of the above that can be accessed with anonymous from ftp at 192.58.194.75/pub/vahe or at ftp.playground.net/pub/vahe We have been familiarized with MPEG-4 over the last 2 meetings. We realize that MPEG-4 is unlike any existing RTP Payload Type because it has its own stream structure and decoder types defined in separate streams i.e., it contains streams about its streams consisting of Scene and Object Descriptor streams. The issues of mapping MPEG-4 over RTP have now been identified: a) RTP Time Stamp is either derived fom MPEG-4 Composition TS (monotonicaly increasing order not preserved)or from an RTP source clock. An out of band DMIF signal provides the MPEG-4 stream configuration at the time of establishing the stream in order to derive the Composition TS. b) RTP carries a generic payload type. The latter is specified elsewhere. There has been some work in RTP on this with the Payload Type being specified in SDP RTPMAP. Also see d) c) Multistreaming over RTP. There is work being done in AVT on RTP Mux but it requires consistency of RTP Time Stamps for the streams being carried over the RTP Mux. d) Dynamic SDP streaming to correspond to the scene and Object Descriptor streams in MPEG-4. Of course no parallel work exists yet on this in MMUSIC or AVT. At the meeting I would like to get the latest views on the above issues as well as consider the implications of the option below: MPEG4 being modified by AVT/MMUSIC jointly with MPEG for suitable operation over IP as a next generation RTP. This approach is better than piecemeal adjustments to RTP. Any feedback is welcome. Vahe Balabanian balabani@nortel.ca Phone: (613) 763-4721 b) From rem-conf Wed Aug 19 09:44:46 1998 From rem-conf-request@es.net Wed Aug 19 09:44:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9BJB-0000YD-00; Wed, 19 Aug 1998 09:42:01 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9BJA-0000Y2-00; Wed, 19 Aug 1998 09:42:00 -0700 Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id JAA32430 for ; Wed, 19 Aug 1998 09:31:35 -0700 Received: from scv2.apple.com (scv2.apple.com [17.128.100.140]) by mailgate.apple.com (mailgate.apple.com2.0.15) with ESMTP id ; Wed, 19 Aug 1998 09:31:06 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv2.apple.com (8.8.5/8.8.5) with ESMTP id JAA17664; Wed, 19 Aug 1998 09:30:58 -0700 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <199808190734.QAA09166@necom830.hpcl.titech.ac.jp> References: ; from "Joe Lawlor" at Aug 17, 98 9:31 am MIME-Version: 1.0 Date: Wed, 19 Aug 1998 09:28:36 -0700 To: Masataka Ohta From: Dave Singer Subject: Re: Web page url's Cc: jlawlor@radio.cbc.ca (Joe Lawlor), rem-conf@es.net Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Your approach may have its benefits, but to say that embedded objects of type "application/sdp" are "no good" is a little strong. They seem to work fine, either as sdp files, or using data URLs. I've even tried them...and seen them work. At 4:34 PM +0900 8/19/98, Masataka Ohta wrote: >Joe; > >> I apologize if this is the wrong place to ask this question. >> >> Is somebody working on a type of That can allow me to call >> an Mbone stream from a Web Page? > >Yes. > >> Who would do such a thing? > >See: > > draft-fujikawa-sdp-url-01.txt > >> Is it a matter of setting up Mime-types? > >No, because the description needs a lot of parameters without inline >headers. > >FYI, data URL, which describes a description of a stream, neither, >is no good. > > Masataka Ohta David Singer Apple Computer/QuickTime 408-974-3162 From rem-conf Wed Aug 19 16:54:23 1998 From rem-conf-request@es.net Wed Aug 19 16:54:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9Hzr-0005c7-00; Wed, 19 Aug 1998 16:50:31 -0700 Received: from necom830.hpcl.titech.ac.jp [131.112.32.132] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9Hzq-0005bt-00; Wed, 19 Aug 1998 16:50:30 -0700 From: Masataka Ohta Message-Id: <199808192340.IAA10886@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA10886; Thu, 20 Aug 1998 08:40:18 +0900 Subject: Re: Web page url's To: singer@apple.com (Dave Singer) Date: Thu, 20 Aug 98 8:40:17 JST Cc: mohta@necom830.hpcl.titech.ac.jp, jlawlor@radio.cbc.ca, rem-conf@es.net In-Reply-To: ; from "Dave Singer" at Aug 19, 98 9:28 am X-Mailer: ELM [version 2.3 PL11] X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list David; > Your approach may have its benefits, but to say that embedded objects of > type "application/sdp" are "no good" is a little strong. Like data URLs, objects with application/sdp type is a description of a description. > They seem to work > fine, either as sdp files, or using data URLs. I've even tried them...and > seen them work. That is perhaps because you are not handling sdp itself as an application. You should be handling something pointed by SDP application. It's like a difference between pointers to integers and pointers to pointers to integers. Masataka Ohta From rem-conf Thu Aug 20 08:35:34 1998 From rem-conf-request@es.net Thu Aug 20 08:35:33 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9WW7-0006YJ-00; Thu, 20 Aug 1998 08:20:47 -0700 Received: from smtpott1.nortel.ca [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9WW6-0006Y9-00; Thu, 20 Aug 1998 08:20:46 -0700 Received: from zcars00t by smtpott1; Thu, 20 Aug 1998 11:20:19 -0400 Received: from ca.nortel.com by zcars00t.ca.nortel.com id <05356-0@zcars00t.ca.nortel.com>; Thu, 20 Aug 1998 11:17:27 -0400 Date: 20 Aug 1998 11:17 EDT Sender: "Vahe Balabanian" To: casner@cisco.com Cc: rem-conf@es.net From: "Vahe Balabanian" Subject: re:Proposed agenda for AVT WG at IETF in Chicago Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Correction: replace ftp.playground.net/pub/vahe by http://www.playground.net/~balabanianvahe/vahe/ My sincere apologies, Vahe ----->Previous message Aug 29, 1998Dear All, In message "Proposed agenda for AVT WG at IETF in Chicago", casner@cisco.com writes: >AVT Working Group: > >Here's the proposed agenda for the AVT meeting next week. ... > > - DMIF for RTP/MPEG4 [Balabanian] 10 > draft-ietf-avt-rtp-mpeg4-dmif-00.txt Please note tha I have an updated version '01' of the above that can be accessed with anonymous from ftp at 192.58.194.75/pub/vahe or at ftp.playground.net/pub/vahe We have been familiarized with MPEG-4 over the last 2 meetings. We realize that MPEG-4 is unlike any existing RTP Payload Type because it has its own stream structure and decoder types defined in separate streams i.e., it contains streams about its streams consisting of Scene and Object Descriptor streams. The issues of mapping MPEG-4 over RTP have now been identified: a) RTP Time Stamp is either derived fom MPEG-4 Composition TS (monotonicaly increasing order not preserved)or from an RTP source clock. An out of band DMIF signal provides the MPEG-4 stream configuration at the time of establishing the stream in order to derive the Composition TS. b) RTP carries a generic payload type. The latter is specified elsewhere. There has been some work in RTP on this with the Payload Type being specified in SDP RTPMAP. Also see d) c) Multistreaming over RTP. There is work being done in AVT on RTP Mux but it requires consistency of RTP Time Stamps for the streams being carried over the RTP Mux. d) Dynamic SDP streaming to correspond to the scene and Object Descriptor streams in MPEG-4. Of course no parallel work exists yet on this in MMUSIC or AVT. At the meeting I would like to get the latest views on the above issues as well as consider the implications of the option below: MPEG4 being modified by AVT/MMUSIC jointly with MPEG for suitable operation over IP as a next generation RTP. This approach is better than piecemeal adjustments to RTP. Any feedback is welcome. Vahe Balabanian balabani@nortel.ca Phone: (613) 763-4721 b) From rem-conf Thu Aug 20 08:48:47 1998 From rem-conf-request@es.net Thu Aug 20 08:48:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9WrG-0006uv-00; Thu, 20 Aug 1998 08:42:38 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9WrF-0006ul-00; Thu, 20 Aug 1998 08:42:37 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id IAA01971 for ; Thu, 20 Aug 1998 08:42:35 -0700 (PDT) Message-Id: <3.0.3.32.19980820084234.00a5e2b0@postgres.berkeley.edu> X-Sender: ireney@postgres.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 20 Aug 1998 08:42:34 -0700 To: rem-conf@es.net From: Irene Yam Subject: 8/26 Seminar Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list
Berkeley Multimedia Research Center Berkeley Multimedia, Interfaces, and Graphics Seminar
Implementing an On-Demand Internet Streaming Media Business Dave Glazer Eloquent, Inc. 8/26/98 405 Soda Hall 12:30-2:00 p.m.
Abstract: The delivery of knowledge is being revolutionized by the influence of desktop multimedia technology. The ability to digitize and distribute various media and documents has created new possibilities that can increase the effectiveness of information while lowering the cost of its delivery. While much of today's technology-based training uses sophistcated custom-built applications, most organizations do not have the time or money to build them. This talk will describe an Enterprise Knowledge Development System that can be used to provide on-demand, computer-based training. The system is based on streaming digital audio and video with synchronized slides and transcript. The authoring process, media server, delivery protocol, and client application will be described. ____________________________________________ Chris Williams Berkeley Multimedia Research Center (BMRC) 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: cwilliams@bmrc.berkeley.edu From rem-conf Thu Aug 20 09:18:44 1998 From rem-conf-request@es.net Thu Aug 20 09:18:44 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9XP7-0000oX-00; Thu, 20 Aug 1998 09:17:37 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0z9XP5-0000oN-00; Thu, 20 Aug 1998 09:17:35 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id MAA03982; Thu, 20 Aug 1998 12:17:26 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Vahe Balabanian cc: casner@cisco.com, rem-conf@es.net Subject: Re: Proposed agenda for AVT WG at IETF in Chicago In-reply-to: Your message of "20 Aug 1998 11:17:00 EDT." Date: Thu, 20 Aug 1998 12:17:26 -0400 Message-ID: <3980.903629846@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >At the meeting I would like to get the latest views on the >above issues as well as consider the implications of the >option below: > >MPEG4 being modified by AVT/MMUSIC jointly with MPEG for >suitable operation over IP as a next generation RTP. I'm very confused. RTP is a general purpose "transport" protocol. MPEG4 is a specific (albeit complex) codec. How do you view MPEG4 as being a next generation RTP? Can I carry legally carry H.261 or any of the several hundred other codecs in the microsoft or quicktime codec registries over MPEG4? Do you have a proposal for IP/UDP/MPEG4 header compression so this works over low rate modems? Do you also propose replacing SIP, SDP, SAP and RTSP too? Or H.323 for that matter? Sorry, but I don't really understand what you're proposing. Mark From rem-conf Thu Aug 20 10:53:59 1998 From rem-conf-request@es.net Thu Aug 20 10:53:58 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9YpL-0002cM-00; Thu, 20 Aug 1998 10:48:47 -0700 Received: from mail-out1.apple.com [17.254.0.52] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9YpK-0002cC-00; Thu, 20 Aug 1998 10:48:46 -0700 Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.8.5/8.8.5) with ESMTP id KAA29532 for ; Thu, 20 Aug 1998 10:24:19 -0700 Received: from scv2.apple.com (scv2.apple.com [17.128.100.140]) by mailgate.apple.com (mailgate.apple.com2.0.15) with ESMTP id ; Thu, 20 Aug 1998 10:23:16 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv2.apple.com (8.8.5/8.8.5) with ESMTP id KAA34010; Thu, 20 Aug 1998 10:23:03 -0700 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <3980.903629846@north.lcs.mit.edu> References: "Your message of 20 Aug 1998 11:17:00 EDT." MIME-Version: 1.0 Date: Thu, 20 Aug 1998 10:17:43 -0700 To: Mark Handley From: Dave Singer Subject: Re: Proposed agenda for AVT WG at IETF in Chicago Cc: Vahe Balabanian , casner@cisco.com, rem-conf@es.net Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark I'm sure Vahe will answer this as well, and provide more insight as he's worked more in this integration area, but I thought I'd just (a) reassure you that Mpeg4 is confusing and (b) try to clarify a little on Mpeg4 being a 'specific codec', along with a sprinkling of opinion. Mpeg4 is an umbrella for a whole bunch of stuff: visual, audio, VRML-like scenes, intellectual property and other content information, java streams, and so on. Inside the video and audio sections there are multiple 'tools' (codecs); visual has a video coder (a fmaily member with Mpeg1 and 2, greatly enhanced), still image coder (wavelet based), face and body animation, and mesh coding. Audio has even more (two time/frequency coders, speech, parametric, text-to-speech, synthetic audio, as well as the mpeg1 and 2 layers). The 3D scene described by the VRML-like layer can integrate new substreams into the scene as they come and go, and there is a separate stream which describes these substreams (e.g. a video stream) as they enter and leave the overall presentation. An Mpeg4 scene could in theory involve hundreds of streams over its life (though many of us hope that this is not a normal usage). There is an optional tool called flexmux which can fragment and pack the fragments of multiple streams into a single mpeg4 multiplex stream, which might help here. Some of these streams are likely to react poorly to packet loss, which makes packing them into RTP interesting. On the other hand, others will benefit from usual RTP framing techniques -- the video coder could do partial-frame recovery given a suitable RTP packing, for example. Some of these streams also use 'initialization data' which can be extensive, though most keep it small (the synthetic audio layer provides an orchestra in initialization data). The normal way to carry this initialization data is on the stream which declares new streams -- but this is an area where reliable delivery (or repeated delivery) will be needed; you can't decode a stream until you know if its existence and format. The Mpeg4 file format will represent each of these streams as a separate set of data in the file, composed in its natural framing. What I mean by that is that the data won't be pre-multiplexed assuming a particular transport, in the way that Mpeg2 transport both fragmented and multiplexed the fragments of the video frames or audio data. So a video stream will be separately identified, and stored as frames of video. This should make it much easier to derive appropriate fragmentation and multiplexing techniques for each stream for each transport. In RTP, I would take this as meaning that we would do ALF and IP multiplexing to the greatest extent possible; with the caveat that there is presumably some limit to how many IP streams we would consider reasonable in a single presentation. Clearly there are questions here about the overlap -- e.g. between SDP which describes streams and their format, and the Mpeg4 descriptor stream. RTSP itself I feel is fairly safe -- once we have worked out the 'describe' format and the transport mapping, I can't think why RTSP per se would need any change. Hmm. This is a longer answer than I intended, and doesn't really answer all the questions. Debate on this issue would be advantageous, I think, and if it develops we should probably pull in an MPEG4 mailing list as well? >I'm very confused. RTP is a general purpose "transport" protocol. >MPEG4 is a specific (albeit complex) codec. How do you view MPEG4 as >being a next generation RTP? Can I carry legally carry H.261 or any >of the several hundred other codecs in the microsoft or quicktime >codec registries over MPEG4? Do you have a proposal for IP/UDP/MPEG4 >header compression so this works over low rate modems? Do you also >propose replacing SIP, SDP, SAP and RTSP too? Or H.323 for that >matter? > >Sorry, but I don't really understand what you're proposing. > >Mark David Singer Apple Computer/QuickTime 408-974-3162 From rem-conf Thu Aug 20 11:14:13 1998 From rem-conf-request@es.net Thu Aug 20 11:14:13 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9ZC6-0003S9-00; Thu, 20 Aug 1998 11:12:18 -0700 Received: from artemis.rus.uni-stuttgart.de [129.69.18.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9ZC5-0003Rz-00; Thu, 20 Aug 1998 11:12:17 -0700 Received: from kssun7.rus.uni-stuttgart.de (kssun7.rus.uni-stuttgart.de [129.69.30.17]) by artemis.rus.uni-stuttgart.de (8.8.8/8.8.8) with ESMTP id UAA03298; Thu, 20 Aug 1998 20:12:13 +0200 (MET DST) env-from (christ@kssun7.rus.uni-stuttgart.de) Received: (from christ@localhost) by kssun7.rus.uni-stuttgart.de (8.8.8/8.8.8) id UAA24730; Thu, 20 Aug 1998 20:02:15 +0200 (MET DST) From: "Paul Christ" Message-Id: <980820200213.ZM24728@kssun7.rus.uni-stuttgart.de> Date: Thu, 20 Aug 1998 20:02:13 +0200 In-Reply-To: Mark Handley "Re: Proposed agenda for AVT WG at IETF in Chicago" (Aug 20, 12:17pm) References: <3980.903629846@north.lcs.mit.edu> X-Mailer: Z-Mail (4.0.1 13Jan97) To: Mark Handley Subject: Re: Proposed agenda for AVT WG at IETF in Chicago Cc: Vahe Balabanian , wesner@rus.uni-stuttgart.de, christine.guillemot@irisa.fr, casner@cisco.com, rem-conf@es.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark, as you wrote: >I'm very confused. RTP is a general purpose "transport" protocol. >MPEG4 is a specific (albeit complex) codec. How do you view MPEG4 as >being a next generation RTP? Can I carry legally carry H.261 or any >of the several hundred other codecs in the microsoft or quicktime >codec registries over MPEG4? Do you have a proposal for IP/UDP/MPEG4 >header compression so this works over low rate modems? Do you also >propose replacing SIP, SDP, SAP and RTSP too? Or H.323 for that >matter? > >Sorry, but I don't really understand what you're proposing. > >Mark hm, if I understand Vahe rightly he is more thinking of the MPEG-4 multi-stream transport philosophy ... which could be seen in relation to multiplexing etc. issues in the RTP context. Yours Paul Christ From rem-conf Thu Aug 20 12:12:32 1998 From rem-conf-request@es.net Thu Aug 20 12:12:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9a6B-0004jP-00; Thu, 20 Aug 1998 12:10:15 -0700 Received: from smtpott1.nortel.ca [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9a69-0004jF-00; Thu, 20 Aug 1998 12:10:13 -0700 Received: from zcars00t by smtpott1; Thu, 20 Aug 1998 15:09:49 -0400 Received: from ca.nortel.com by zcars00t.ca.nortel.com id <13825-0@zcars00t.ca.nortel.com>; Thu, 20 Aug 1998 15:07:09 -0400 Date: 20 Aug 1998 15:07 EDT Sender: "Vahe Balabanian" To: mjh@east.isi.edu Cc: casner@cisco.com, rem-conf@es.net From: "Vahe Balabanian" Subject: re:Re: Proposed agenda for AVT WG at IETF in Chicago Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Mark, Dave Singer provided an excellent description of the extent of what MPEG-4 is. What we are doing right now in AVT is respond to some facets of MPEG-4 but not look at MPEG-4 as a whole. Some specific comments below. In message "Re: Proposed agenda for AVT WG at IETF in Chicago", mjh@east.isi.edu writes: > >>At the meeting I would like to get the latest views on the >>above issues as well as consider the implications of the >>option below: >> >>MPEG4 being modified by AVT/MMUSIC jointly with MPEG for >>suitable operation over IP as a next generation RTP. > >I'm very confused. RTP is a general purpose "transport" protocol. >MPEG4 is a specific (albeit complex) codec. How do you view MPEG4 as >being a next generation RTP? MPEG-4 contains two levels of codecs. At one level are the audiovisual codecs. At the other level is the Sync Layer codec which does the synchronization of the audiovisual streams and places them within a scene on the screen. In adddition it does intellectual propery management and much more. >Can I carry legally carry H.261 or any >of the several hundred other codecs in the microsoft or quicktime >codec registries over MPEG4? In theory you can. Right now MPEG-4 has profiles where specific codecs are identified, H.261 is one example. The profiles allow for the addition of codecs as the need arises. >Do you have a proposal for IP/UDP/MPEG4 >header compression so this works over low rate modems? MPEG-4 at its audiovisual layer has scalable codecs covering a range from few Kbps to many Mbps. The reason why I want us to look at MPEG-4 is to be able to ensure its efficient carriage over IP because that expertise resides in IETF. At this moment the only proposal from MPEG is packing multiple streams over an IP port using FlexMux. We may propose other more IP friendly compression schemes. >Do you also >propose replacing SIP, SDP, SAP and RTSP too? Or H.323 for that >matter? Not at all, the intent is to work with SIP, SDP, SAP, RTSP and H.323 to the extent that we realize that MPEG-4 has gone beyond the traditional codec operations. > >Sorry, but I don't really understand what you're proposing. I hope to improve our understanding through continuous dialogue such as this one. What I am proposing is that RTP NG be the MPEG-4 Sync Layer adapted for IP operation. After trying for a while, I feel that this is a better approach than forcing the MPEG-4 to work with RTP (like forcing a square peg into a round whole). > Kind regards, Vahe Balabanian From rem-conf Thu Aug 20 12:50:21 1998 From rem-conf-request@es.net Thu Aug 20 12:50:20 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9agq-0005eG-00; Thu, 20 Aug 1998 12:48:08 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0z9ago-0005e2-00; Thu, 20 Aug 1998 12:48:06 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Aug 20 15:46:06 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA18236; Thu, 20 Aug 1998 15:46:23 -0400 (EDT) Message-ID: <35DC7C8D.30621717@dnrc.bell-labs.com> Date: Thu, 20 Aug 1998 15:44:13 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Vahe Balabanian CC: mjh@east.isi.edu, casner@cisco.com, rem-conf@es.net Subject: Re: Proposed agenda for AVT WG at IETF in Chicago References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Vahe Balabanian wrote: > > I hope to improve our understanding through continuous dialogue > such as this one. What I am proposing is that RTP NG be the > MPEG-4 Sync Layer adapted for IP operation. After trying for > a while, I feel that this is a better approach than forcing the > MPEG-4 to work with RTP (like forcing a square peg into a round > whole). I'm reminded of the term "if it ain't broke, don't fix it". RTP has achieved fairly widespread usage, and success as the transport medium of choice for a vast array of codecs. Its used in the mbone. Its used in H.323. Its used by SIP, SAP, SDP, RTSP, and a host of proprietary signaling mechanisms. It works for big and small multicast groups, for audio and for video. Why would we abandon this work, and develop a "RTP-NG" just because, for some reason, MPEG4 doesn't work well with it? Perhaps the problem is the peg isn't the right shape? -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Aug 20 13:49:16 1998 From rem-conf-request@es.net Thu Aug 20 13:49:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9bbp-0006nt-00; Thu, 20 Aug 1998 13:47:01 -0700 Received: from smtpott1.nortel.ca [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9bbo-0006na-00; Thu, 20 Aug 1998 13:47:00 -0700 Received: from zcars00t by smtpott1; Thu, 20 Aug 1998 16:46:07 -0400 Received: from ca.nortel.com by zcars00t.ca.nortel.com id <25103-0@zcars00t.ca.nortel.com>; Thu, 20 Aug 1998 16:43:41 -0400 Date: 20 Aug 1998 16:43 EDT Sender: "Vahe Balabanian" To: jdrosen@dnrc.bell-labs.com Cc: mjh@east.isi.edu, casner@cisco.com, rem-conf@es.net From: "Vahe Balabanian" Subject: re:Re: Proposed agenda for AVT WG at IETF in Chicago Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan, In message "Re: Proposed agenda for AVT WG at IETF in Chicago", jdrosen@dnrc.bell-labs.com writes: >Vahe Balabanian wrote: >> >> I hope to improve our understanding through continuous dialogue >> such as this one. What I am proposing is that RTP NG be the >> MPEG-4 Sync Layer adapted for IP operation. After trying for >> a while, I feel that this is a better approach than forcing the >> MPEG-4 to work with RTP (like forcing a square peg into a round >> whole). > >I'm reminded of the term "if it ain't broke, don't fix it". RTP has >achieved fairly widespread usage, and success as the transport medium of >choice for a vast array of codecs. Its used in the mbone. Its used in >H.323. Its used by SIP, SAP, SDP, RTSP, and a host of proprietary >signaling mechanisms. It works for big and small multicast groups, for >audio and for video. Why would we abandon this work, and develop a >"RTP-NG" just because, for some reason, MPEG4 doesn't work well with it? >Perhaps the problem is the peg isn't the right shape? > I am sorry I did not mean to abandon RTP. It is perfectly a good system. Do you read "RTP NG" as abandoning RTP? Is there no way that RTP NG encompass RTP? This is why I want to do it in IETF. By jointly working with MPEG I am sure to some extent the MPEG-4 peg will also be reshaped to the degree that basic features are not lost. That is if we assume MPEG-4 is an advance in technology of codecs and its use over IP is desirable. Vahe From rem-conf Thu Aug 20 14:11:40 1998 From rem-conf-request@es.net Thu Aug 20 14:11:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9bx6-0007aF-00; Thu, 20 Aug 1998 14:09:00 -0700 Received: from rumor.research.att.com [192.20.225.9] by mail1.es.net with smtp (Exim 1.81 #2) id 0z9bx5-0007a5-00; Thu, 20 Aug 1998 14:08:59 -0700 Received: from research.att.com ([135.207.30.100]) by rumor; Thu Aug 20 17:02:13 EDT 1998 Received: from surfcity.research.att.com ([135.207.128.5]) by research; Thu Aug 20 17:06:32 EDT 1998 Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id RAA16992; Thu, 20 Aug 1998 17:06:31 -0400 (EDT) Message-ID: <00d901bdcc7d$48f5ab80$4683cf87@pcmrcfast.research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Vahe Balabanian" Cc: Subject: Re: re:Re: Proposed agenda for AVT WG at IETF in Chicago Date: Thu, 20 Aug 1998 16:58:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Actually, being somewhat involved in this work, I don't think that it is that difficult to make the "useful parts" of MPEG4 work nicely over RTP. I guess, it would be helpful if Vahe can explain which parts of MPEG4 make it "square." ----------------------------------------------------------------------- M. Reha Civanlar Technology Leader, AT&T Labs - Research 100 Schultz Drive, Red Bank, NJ 07701, U.S.A civanlar@research.att.com Phone: +1 732 345 3305 Fax:+1 732 345 3033 http://www.research.att.com/info/mrc From rem-conf Thu Aug 20 14:27:38 1998 From rem-conf-request@es.net Thu Aug 20 14:27:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9cDb-0000dl-00; Thu, 20 Aug 1998 14:26:03 -0700 Received: from dirty.research.bell-labs.com [204.178.16.6] by mail1.es.net with smtp (Exim 1.81 #2) id 0z9cDa-0000db-00; Thu, 20 Aug 1998 14:26:02 -0700 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Aug 20 17:24:11 EDT 1998 Received: from dnrc.bell-labs.com (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id RAA21773; Thu, 20 Aug 1998 17:24:28 -0400 (EDT) Message-ID: <35DC938A.B8F04CD7@dnrc.bell-labs.com> Date: Thu, 20 Aug 1998 17:22:18 -0400 From: Jonathan Rosenberg X-Mailer: Mozilla 4.04 [en] (WinNT; I) MIME-Version: 1.0 To: Vahe Balabanian CC: mjh@east.isi.edu, casner@cisco.com, rem-conf@es.net Subject: Re: Proposed agenda for AVT WG at IETF in Chicago References: <199808202047.QAA05607@boole.dnrc.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Vahe Balabanian wrote: > > I am sorry I did not mean to abandon RTP. It is perfectly a good > system. Do you read "RTP NG" as abandoning RTP? Is there no way > that RTP NG encompass RTP? This is a hard question to answer, particularly since I have no idea what (or why) RTP-NG is. However, the statement that MPEG-4 is so different, that it requires an RTP-NG, would seem to me to imply that RTP-NG would need to be different enough for MPEG-4 to work on it. -Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 FAX: (732) 834-5379 Rm. 4C-526 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Thu Aug 20 23:15:30 1998 From rem-conf-request@es.net Thu Aug 20 23:15:30 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9kKj-0005CI-00; Thu, 20 Aug 1998 23:05:57 -0700 Received: from hermes.research.kpn.com [139.63.192.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9kKZ-0005Bx-00; Thu, 20 Aug 1998 23:05:47 -0700 Received: from ntl11.research.kpn.com by research.kpn.com (PMDF V5.1-8 #18053) with SMTP id <01J0UWSHPBPM0009WQ@research.kpn.com> for rem-conf@es.net; Fri, 21 Aug 1998 08:07:33 +0200 Received: by ntl11.research.kpn.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BDCCDA.7D5C74F0@ntl11.research.kpn.com>; Fri, 21 Aug 1998 08:05:41 +0100 Date: Fri, 21 Aug 1998 08:05:40 +0100 From: "Koenen, R.H." Subject: RE: Re: Proposed agenda for AVT WG at IETF in Chicago To: 'Vahe Balabanian' , "'mjh@east.isi.edu'" Cc: "'casner@cisco.com'" , "'rem-conf@es.net'" Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Indeed Dave provided a very good Overview of MPEG-4. > In theory you can. Right now MPEG-4 has profiles where specific > codecs are identified, H.261 is one example. The profiles > allow for the addition of codecs as the need arises. A small correction: H > > >Do you have a proposal for IP/UDP/MPEG4 > >header compression so this works over low rate modems? > > MPEG-4 at its audiovisual layer has scalable codecs covering > a range from few Kbps to many Mbps. The reason why I want us to > look at MPEG-4 is to be able to ensure its efficient carriage > over IP because that expertise resides in IETF. At this moment > the only proposal from MPEG is packing multiple streams > over an IP port using FlexMux. We may propose other more IP > friendly compression schemes. > > >Do you also > >propose replacing SIP, SDP, SAP and RTSP too? Or H.323 for that > >matter? > > Not at all, the intent is to work with SIP, SDP, SAP, RTSP and > H.323 to the extent that we realize that MPEG-4 has gone beyond > the traditional codec operations. > > > >Sorry, but I don't really understand what you're proposing. > > I hope to improve our understanding through continuous dialogue > such as this one. What I am proposing is that RTP NG be the > MPEG-4 Sync Layer adapted for IP operation. After trying for > a while, I feel that this is a better approach than forcing the > MPEG-4 to work with RTP (like forcing a square peg into a round > whole). > > > Kind regards, > > Vahe Balabanian > > From rem-conf Thu Aug 20 23:40:40 1998 From rem-conf-request@es.net Thu Aug 20 23:40:39 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9kpy-0005vH-00; Thu, 20 Aug 1998 23:38:14 -0700 Received: from hermes.research.kpn.com [139.63.192.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9kpv-0005v4-00; Thu, 20 Aug 1998 23:38:12 -0700 Received: from ntl11.research.kpn.com by research.kpn.com (PMDF V5.1-8 #18053) with SMTP id <01J0UXWQ2FV20009WQ@research.kpn.com> for rem-conf@es.net; Fri, 21 Aug 1998 08:39:59 +0200 Received: by ntl11.research.kpn.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BDCCDF.055B8860@ntl11.research.kpn.com>; Fri, 21 Aug 1998 08:38:07 +0100 Date: Fri, 21 Aug 1998 08:38:06 +0100 From: "Koenen, R.H." Subject: RE: Re: Proposed agenda for AVT WG at IETF in Chicago To: 'Vahe Balabanian' , "'mjh@east.isi.edu'" Cc: "'casner@cisco.com'" , "'rem-conf@es.net'" , 'Herpel Carsten' , 'Leonardo Chiariglione' , 'Olivier AVARO' Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Vahe, Reva, people, Indeed Dave Singer provided an excellent concise overview of MPEG-4. Then Vahe wrote about using H.261 in MPEG-4 something that needs correction and a bit of further explanation: > Right now MPEG-4 has profiles where specific > codecs are identified, H.261 is one example. The profiles > allow for the addition of codecs as the need arises. H.261 is NOT in any MPEG-4 Profile, and it is highly unlikely that it will ever be. MPEG-4 Video can decode H.263 bitstreams though (which is not backward compatible with H.261 by the way). MPEG firmly believes in the 'one functionality, on tool' rule, and MPEG-4 codecs do a perfect job at the functionality 'compression of natural video'. Also, MPEG-4 does (currently) NOT define profiles that include 'other codecs'. We do not consider this to enhance interoperability, one of the main goals in the standardisation effort. (However, a registration procedure will be put in place so that people, if they really want to, can register their own stream type and have a unique ID for it.) Then, Reha Cinvlar asked "which parts of MPEG-4 make it square". Ask different people and you will get different answers. Let me explain a bit about Profiling in MPEG-4 though. Bear in mind that MPEG-4 is an object based standard, and that a scene is composed of these elements called objects. There are 4 types of Profiles: 1. Visual 2. Audio 3. Graphics Media 4. Scene Description 1. Visual: defines which types of Visual Objects a decoder understands. e.g. rectangular natural Video, arbitrary shaped objects, animated faces, etc. 2. Audio: defines the Audio Objects a decoder understands: e.g. speech, simple wavetable synthesis, AAC-type Audio 3. Graphics Media: defines which types of (2D and 3D) VRML-like elements a decoder can decode. Examples: 'Audio-only', '2D', 'VRML' 4. Scene Description: defines which tools the decoder has on board to lay out and manipulate objects in the scene. Currently there are only 2D and 3D profiles MPEG does NOT prescribe which combinations are allowed. The right combination will have te be determined by users of the standard (don't read 'end users' here.) Elements included in MPEG-4 but not subject to profiling in MPEG-4 are: * System tools like synchronisation, buffer managment, simple muxing * the File Format * Intellectual Property Management and Protection * Interfaces to application and network Not all applications will want to use those tools however. As you can see, MPEG-4 is very much a toolbox standard, from which you pick what you need. For an extremely brief primer on MPEG-4, focused on WWW/TV integration and highlighting the profiles, please see http://www.w3.org/Architecture/1998/06/Workshop/paper26/ best regards, Rob Koenen Chairman MPEG Requirements Group ---------------- Rob Koenen, Multimedia Technology Group, KPN Research PO Box 421, 2260 AK Leidschendam The Netherlands tel +31 70 332 5310 fax +31 70 332 5567 GSM +31 653 815 686 > -----Original Message----- > From: Vahe Balabanian [mailto:balabani@nortel.ca] > Sent: Thursday, August 20, 1998 8:07 PM > To: mjh@east.isi.edu > Cc: casner@cisco.com; rem-conf@es.net > Subject: re:Re: Proposed agenda for AVT WG at IETF in Chicago > > > Mark, > > Dave Singer provided an excellent description of the extent of what > MPEG-4 is. What we are doing right now in AVT is respond to some > facets of MPEG-4 but not look at MPEG-4 as a whole. Some specific > comments below. > > In message "Re: Proposed agenda for AVT WG at IETF in Chicago", > mjh@east.isi.edu writes: > > > > >>At the meeting I would like to get the latest views on the > >>above issues as well as consider the implications of the > >>option below: > >> > >>MPEG4 being modified by AVT/MMUSIC jointly with MPEG for > >>suitable operation over IP as a next generation RTP. > > > >I'm very confused. RTP is a general purpose "transport" protocol. > >MPEG4 is a specific (albeit complex) codec. How do you view MPEG4 as > >being a next generation RTP? > > MPEG-4 contains two levels of codecs. At one level are the > audiovisual > codecs. At the other level is the Sync Layer codec which does the > synchronization of the audiovisual streams and places them within > a scene on the screen. In adddition it does intellectual propery > management and much more. > > >Can I carry legally carry H.261 or any > >of the several hundred other codecs in the microsoft or quicktime > >codec registries over MPEG4? > > In theory you can. Right now MPEG-4 has profiles where specific > codecs are identified, H.261 is one example. The profiles > allow for the addition of codecs as the need arises. > > >Do you have a proposal for IP/UDP/MPEG4 > >header compression so this works over low rate modems? > > MPEG-4 at its audiovisual layer has scalable codecs covering > a range from few Kbps to many Mbps. The reason why I want us to > look at MPEG-4 is to be able to ensure its efficient carriage > over IP because that expertise resides in IETF. At this moment > the only proposal from MPEG is packing multiple streams > over an IP port using FlexMux. We may propose other more IP > friendly compression schemes. > > >Do you also > >propose replacing SIP, SDP, SAP and RTSP too? Or H.323 for that > >matter? > > Not at all, the intent is to work with SIP, SDP, SAP, RTSP and > H.323 to the extent that we realize that MPEG-4 has gone beyond > the traditional codec operations. > > > >Sorry, but I don't really understand what you're proposing. > > I hope to improve our understanding through continuous dialogue > such as this one. What I am proposing is that RTP NG be the > MPEG-4 Sync Layer adapted for IP operation. After trying for > a while, I feel that this is a better approach than forcing the > MPEG-4 to work with RTP (like forcing a square peg into a round > whole). > > > Kind regards, > > Vahe Balabanian > > From rem-conf Fri Aug 21 03:34:48 1998 From rem-conf-request@es.net Fri Aug 21 03:34:46 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9oS0-0000gX-00; Fri, 21 Aug 1998 03:29:44 -0700 Received: from relay14.jaring.my [192.228.128.125] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9oRy-0000gD-00; Fri, 21 Aug 1998 03:29:42 -0700 Received: from jyluke (jyluke.mimos.my [192.228.133.16]) by relay14.jaring.my (8.8.8/8.8.7) with SMTP id SAA08065 for ; Fri, 21 Aug 1998 18:28:39 +0800 (MYT) Message-ID: <35DD4BCB.73A6@ew.mimos.my> Date: Fri, 21 Aug 1998 18:28:27 +0800 From: JY Luke Reply-To: jyluke@ew.mimos.my Organization: MIMOS Berhad X-Mailer: Mozilla 3.04 (Win95; U) MIME-Version: 1.0 To: rem-conf@es.net Subject: Session Broadcast Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Sorry for this late announcement as we faced some uncertainty until the last minutes. We are going to broadcast the opening and closing ceremony of the 19th general assembly of ASEAN Inter-Parliamentary Organisation (AIPO). The opening ceremony will be held on 24th August 1998 from 1000 (GMT+8) till 1100 (GMT+8), which will cover opening address by the Hon. Deputy Prime Minister of Malaysia. The closing ceremony will be held on 28th August 1998 from 1500 (GMT+8) till 1700 (GMT+8). Regards, JY Luke MIMOS Berhad Malaysia From rem-conf Fri Aug 21 05:34:26 1998 From rem-conf-request@es.net Fri Aug 21 05:34:25 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9qKa-000235-00; Fri, 21 Aug 1998 05:30:12 -0700 Received: from p-voyageur.issy.cnet.fr [139.100.0.39] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9qKY-00022v-00; Fri, 21 Aug 1998 05:30:10 -0700 Received: from bumba.issy.cnet.fr by p-voyageur.issy.cnet.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id QJVVYNTV; Fri, 21 Aug 1998 14:30:09 +0200 From: Olivier AVARO - France Telecom - CNET MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Singer Cc: Mark Handley , Vahe Balabanian , casner@cisco.com, rem-conf@es.net Subject: Re: Proposed agenda for AVT WG at IETF in Chicago In-Reply-To: Dave Singer's message of "Thu, August 20, 1998 10:17:43 -0700" regarding "Re: Proposed agenda for AVT WG at IETF in Chicago" id References: <3980.903629846@north.lcs.mit.edu> X-Mailer: VM 6.31 under Emacs 19.34.6 Report-Mode: Confirmed Message-Id: Date: Fri, 21 Aug 1998 05:30:10 -0700 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi Dave, all, > Clearly there are questions here about the overlap -- e.g. between SDP > which describes streams and their format, and the Mpeg4 descriptor stream. I don't know yet SDP and if someone has got entry point I would be grateful. From the little knowledge I have, it seems that SDP could carry : - the first object descriptor needed by MPEG that tell where and what is the MPEG-4 content. - the complete MPEG-4 descriptor streams. Is it what you guys (Vahe, ohers, ...) have in mind ? Thanx for the feed back in any case. See you, Olivir From rem-conf Fri Aug 21 05:35:43 1998 From rem-conf-request@es.net Fri Aug 21 05:35:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9qOD-00024j-00; Fri, 21 Aug 1998 05:33:57 -0700 Received: from ctral1.vanderbilt.edu [129.59.1.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9qOB-00024T-00; Fri, 21 Aug 1998 05:33:55 -0700 Received: from gavish ([194.90.232.161]) by ctrvax.Vanderbilt.Edu (PMDF V5.1-10 #24212) id <01J0UVB9ICXC9GEFUD@ctrvax.Vanderbilt.Edu>; Fri, 21 Aug 1998 07:27:29 CDT Received: from gavish ([194.90.232.161]) by ctrvax.Vanderbilt.Edu (PMDF V5.1-10 #24212) with SMTP id <01J0UUW8H1GA9GTW1W@ctrvax.Vanderbilt.Edu>; Fri, 21 Aug 1998 07:25:22 -0500 (CDT) Date: Fri, 21 Aug 1998 07:10:27 -0500 From: Bezalel Gavish Subject: 7th International Conference on Telecommunication Systems - CFP X-Sender: gavishb@ctrvax.vanderbilt.edu To: (Recipient list suppressed) Message-id: MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list C A L L for P A P E R S 7th International Conference on Telecommunication Systems Modeling and Analysis March 18-21, 1999 Nashville, Tennessee, USA Sponsored by: American Telecommunications Systems Management Association BellSouth Telecommunications, Inc. IFIP Working Group 7.3 "Computer system modeling and performance evaluation" INFORMS Technical Section on Telecommunications INFORMS College of Information Systems Vanderbilt Institute of Public Policy Studies The 7th International Conference on Telecommunication Systems - Modeling and Analysis will be held in Nashville on March 18-21, 1999. The conference will build on the tradition of the earlier conferences. The general idea is to limit the number of partici- pants, concentrate on a few topics, and to present new problems and problem areas, to encourage informal interaction and exchanges of ideas. The objective is to advance the state of the modeling and analysis in telecommunications by stimulating research activity on new and important problems. The conference will be divided into segments with each segment devoted to a specific topic. This will allow for little conflict between segments. All papers will be screened by the Program Committee to ensure the quality of presentations. A decentralized paper handling process will be used. Abstracts and papers should be submitted directly to a Program Committee member who will handle its review. It is expected that this will expedite the paper review process. Social and cultural activities will be included in the 1999 agenda. The conference will be held at two sites, Thursday and Friday meetings will take place at the Tennessee Economic Development Center at the BellSouth Tower in downtown Nashville. The Saturday and Sunday meeting will be held at the Club House Inn hotel (see description at the end of the message). Listed below are some of the potential segments: -- Configuration of ATM networks -- DSL based systems -- Internet and its Impact on Commerce -- Internet and Intranet -- Mobility and Nomadicity -- Pricing and economic analysis of Internet and E-commerce -- Topological Design and Network Configuration Problems -- Design and Analysis of Local Access Networks and Outside Plant Problems -- Low Earth Orbit Satellite Communication Systems -- Cellular Systems and PCS Modeling and Configuration -- Time Dependent Expansion of Telecommunication Systems -- Network Reliability, Availability and Survivability -- Network Design Problems in Gigabit and Terabit Networks -- LAN, WAN Global Network Interconnection -- Artificial Intelligence/Heuristics in Telecommunication Systems -- Quantitative Methods in Network Management -- Pricing and Economic Analysis of Telecommunications -- Impact of Telecommunications on Industrial Organization -- Performance Evaluation of Telecommunication Systems -- Distributed Computing and Distributed Data Bases -- Security and Privacy Issues in Telecommunications -- Virtual Reality, Multimedia and their Impact -- Standards The Program Committee is open to any ideas you might have regarding additional topics or format of the conference. The intention is, whenever possible, to limit the number of parallel sessions to three. The conference is scheduled over a weekend so as to reduce teaching conflicts for academic participants, and to enable participants to take advantage of weekend hotel and airfare rates and of the many events that take place in the downtown area. Members of the Program Committee include: Prof. Bezalel Gavish (Chairman) Owen Graduate School of Management Vanderbilt University Tel: 615-322-3659 401 21st Avenue South FAX: 615-343-7177 Nashville, TN 37203 E-mail: gavishb@ctrvax.vanderbilt.edu Prof. Abdullah Al-Dhelaan College of Computer & Information Sciences King Saud University, Riyadh, Saudi Arabia Phone : (0966)-1-467-7777 Fax : (0966)-1-468-1221 E-mail : dhelaan@usa.net Prof. Kemal Altinkemer Krannert Graduate School of Management Purdue University 1310 Krannert Building West Lafayette, IN 47907-1310 Phone : 765-494-9009 Fax : 765-494-1526 E-mail : kemal@mgmt.purdue.edu Prof. Ran Giladi Department of Communication Systems Engineering Faculty of Engineering Sciences Ben Gurion University of the Negev POB 653 Beer Sheva, 84105 Israel Phone : (972)-7-6472591 FAX : (972)-7-6472883 E-Mail : Ran@bgumail.bgu.ac.il Prof. Luis Gouveia D.E.I.O. - C.I.O. Faculdade de Ciencias da Universidade de Lisboa Edificio C2 -Campo Grande Cidade Universitaria 1700 Lisboa Portugal Phone : +351-1-7573141, ext 1584 E-mail : lgouveia@fc.ul.pt Dr. Sidney L. Hantler Manager, Stochastic Analysis Systems and Software Department IBM TJ Watson Research Center Yorktown Heights, NY 10598 Phone : 914-784-7218 E-Mail : hantler@watson.ibm.com Prof. Richard Harris Department of Communication and Electronic Engineering Royal Melbourne Institute of Technology GPO Box 2476V Mlebourne, Victoria Australia, 3001 Phone : 61 3 9925 2457 (RMIT) Fax : 61 3 9660 1060 (RMIT) E-Mail : richard@catt.rmit.edu.au Prof. Joakim Kalvenes School of Management The University of Texas at Dallas P.O. Box 830688, J044 Richardson, TX 75083-0688 Phone : 972-883-2152 Fax : 972-883-2089 E-mail : kalvenes@utdallas.edu Dr. Johan M. Karlsson Department of Communication Systems Lund Institute of Technology P.O. Box 118 S-221 00 Lund Sweden E-Mail : johan@tts.lth.se Dr. Konosuke Kawashima Traffic Research Center NTT Advanced Technology Corp. 2-4-15 Naka-cho, Musashino-shi Tokyo, 180-0006 JAPAN Phone : +81 422 370536 Fax : +81 422 604806 E-mail : shima@mitaka.ntt-at.co.jp Prof. Hans Kruse McClure School of Communication Systems Management Ohio University 9 S. College Street Athens, OH 45701 Phone : 614-593-4891 Fax : 614-593-4889 E-mail : hkruse1@ohiou.edu Prof. Armin R. Mikler Department of Computer Sciences University of North Texas P.O. Box 311366 Denton, TX 76203-1366 Phone : 940-565-4279 Fax : 940-565-2799 E-mail : mikler@cs.unt.edu Prof. June S. Park Department of Management Sciences The University of Iowa 108 Pappajohn Business Administration Bldg. Iowa City, IA 52242-1000 USA Phone : 319-335-2087 Fax : 319-335-1956 E-Mail : june-park@uiowa.edu Prof. Guy Pujolle Laboratoire PRiSM Universite de Versailles - Saint Quentin 45 avenue des Etats-Unis 78 035 Versailles Cedex FRANCE Phone : +33 (1) 39 25 40 61 Fax : +33 (1) 39 25 40 57 E-Mail : guy.pujolle@prism.uvsq.fr Dr. Ernesto Santibanez-Gonzalez Escuela de Ingenieria Industrial Universidad Catolica, Valparaiso Av. Brasil 2147 Valparaiso Chile Phone : 56 32 257331 Fax : 56 2 214823 E-Mail : esantiba@aix1.ucv.cl Prof. Andrew P. Snow Department of Computer Information Systems Georgia State University P.O. Box 4015 Atlanta, GA 30302-4015 Phone : 404-651-0879 E-mail : asnow@gsu.edu Prof. Yutaka Takahashi Nara Institute of Science and Technology Takayama-cho 8916-5, Ikoma-shi Nara, 630-01 JAPAN Phone : 81 74 372 5350 Fax : 81 74 372 5359 E-Mail : ytanaka@mn.waseda.ac.jp Prof. Lars C. Wolf Industrial Process & Sys. Comm. Department of Electr. Eng. & Information Technology Darmstadt University of Technology Merckstr. 25 64283 Darmstadt Germany Tel. : +49-6151-16-6155 (Fax -6152) E-mail : Lars.Wolf@kom.tu-darmstadt.de Prof. Stefan Voss University of Braunschweig Abt-Jerusalem Strasse 7 D-38106 Braunschweig Germany Phone : 49 531 391-3210 E-Mail : Stefan.Voss@tu-bs.de Due to the limit on the number of participants, early conference and hotel registration is recommended. The ClubHouse Inn & Conference Center is the official hotel of the conference. To ensure your participation, please use the following steps: 1. Send to a Program Committee member by October 1, 1998, a paper (preferable), or titles and extended abstracts for potential presentations to be considered for the conference. Sending more than one extended abstract is encouraged, enabling the Program Committee to have a wider choice in terms of assigning talks to segments. Use E-mail to expedite the submission of titles and abstracts and papers. 2. Use the forms at the end of this message to preregister for the conference and the hotel. Let us also know if you would like to have a formal duty during the conference such as: Session Chair, or Discussant. 3. You will be notified by December 15, 1998, which abstract(s)/ paper(s) have been selected for the conference. Detailed instructions on how to prepare camera ready copies will be sent to authors of accepted presentations. February 10, 1999, is the deadline for sending a final version of the paper. Participants will receive copies of the collection of papers to be presented. 4. All papers submitted to the conference will be considered for publication in the "Telecommunication Systems" Journal. If you do not wish for your paper to be submitted for publication consideration in the "Telecommunication Systems" Journal, please specify it in the cover letter of your submission. The Program Committee looks forward to receiving your feedback/ideas. Feel free to volunteer any help you can offer. If you have suggestions for Segment Leaders (i.e., individuals who will have a longer time to give an overview/state of the art talk on their segment subject) please E-mail them to Prof Gavish. Also, if there are individuals whose participation you view as important, please send their names and E-mail addresses to the Program Committee Chairman, or forward to them a copy of this message. I look forward to a very successful conference. Sincerely yours, Bezalel Gavish ---------------------------------------------------------------------------- -------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN 37220 USA Tel: Office (615) 322-3659 FAX (615) 343-7177 Home (615) 370-0813 Email: Gavishb@ctral1.vanderbilt.edu From rem-conf Fri Aug 21 05:35:57 1998 From rem-conf-request@es.net Fri Aug 21 05:35:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9qOf-00025c-00; Fri, 21 Aug 1998 05:34:25 -0700 Received: from hermes.research.kpn.com [139.63.192.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9qOd-00025S-00; Fri, 21 Aug 1998 05:34:24 -0700 Received: from ntl11.research.kpn.com by research.kpn.com (PMDF V5.1-8 #18053) with SMTP id <01J0VADAU6MS0009XQ@research.kpn.com> for rem-conf@es.net; Fri, 21 Aug 1998 14:36:10 +0200 Received: by ntl11.research.kpn.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BDCD10.C7479550@ntl11.research.kpn.com>; Fri, 21 Aug 1998 14:34:18 +0100 Date: Fri, 21 Aug 1998 14:34:17 +0100 From: "Koenen, R.H." Subject: RE: Re: Proposed agenda for AVT WG at IETF in Chicago To: "Koenen, R.H." , 'Vahe Balabanian' , "'mjh@east.isi.edu'" Cc: "'casner@cisco.com'" , "'rem-conf@es.net'" , 'Herpel Carsten' , 'Leonardo Chiariglione' , 'Olivier AVARO' Message-id: MIME-version: 1.0 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Oops ... > 3. Graphics Media: defines which types of (2D and 3D) > VRML-like elements > a decoder can decode. Examples: 'Audio-only', '2D', 'VRML' > 4. Scene Description: defines which tools the decoder has on board to > lay out and manipulate objects in the scene. Currently there > are only 2D and 3D profiles The examples are exactly the other way around (Cut & Paste error) 3. Graphics Media: defines which types of (2D and 3D) VRML-like graphics elements a decoder can decode. Examples are boxes, lines, spheres ... Currently there are only 2D and 3D Graphics profiles 4. Scene Description: defines which tools the decoder has on board to lay out and manipulate objects in the scene. Examples are 'Audio-only', '2D', 'VRML' regards, Rob ---------------- Rob Koenen, Multimedia Technology Group, KPN Research PO Box 421, 2260 AK Leidschendam The Netherlands tel +31 70 332 5310 fax +31 70 332 5567 GSM +31 653 815 686 From rem-conf Fri Aug 21 05:41:57 1998 From rem-conf-request@es.net Fri Aug 21 05:41:56 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9qVJ-0002xZ-00; Fri, 21 Aug 1998 05:41:17 -0700 Received: from smtpott1.nortel.ca [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9qVI-0002x2-00; Fri, 21 Aug 1998 05:41:16 -0700 Received: from zcars00t by smtpott1; Fri, 21 Aug 1998 08:40:56 -0400 Received: from ca.nortel.com by zcars00t.ca.nortel.com id <27455-0@zcars00t.ca.nortel.com>; Fri, 21 Aug 1998 08:38:25 -0400 Date: 21 Aug 1998 08:38 EDT Sender: "Vahe Balabanian" To: R.H.Koenen@research.kpn.com Cc: mjh@east.isi.edu, casner@cisco.com, rem-conf@es.net, HerpelC@thmulti.com, leonardo.chiariglione@CSELT.STET.it, olivier.avaro@cnet.francetelecom.fr From: "Vahe Balabanian" Subject: re:RE: Re: Proposed agenda for AVT WG at IETF in Chicago Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear rob, In message "RE: Re: Proposed agenda for AVT WG at IETF in Chicago", R.H.Koenen@research.kpn.com writes: >Dear Vahe, Reva, people, > > >Indeed Dave Singer provided an excellent concise overview of MPEG-4. > >Then Vahe wrote about using H.261 in MPEG-4 something that needs >correction >and a bit of further explanation: > >> Right now MPEG-4 has profiles where specific >> codecs are identified, H.261 is one example. The profiles >> allow for the addition of codecs as the need arises. > >H.261 is NOT in any MPEG-4 Profile, and it is highly unlikely that it >will ever be. MPEG-4 Video can decode H.263 bitstreams >though (which is not backward compatible with H.261 by the way). > I stand corrected. Thank you, Vahe From rem-conf Fri Aug 21 06:13:08 1998 From rem-conf-request@es.net Fri Aug 21 06:13:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9qz7-0005As-00; Fri, 21 Aug 1998 06:12:05 -0700 Received: from smtpott1.nortel.ca [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9qz6-0005AX-00; Fri, 21 Aug 1998 06:12:04 -0700 Received: from zcars00t by smtpott1; Fri, 21 Aug 1998 09:11:28 -0400 Received: from ca.nortel.com by zcars00t.ca.nortel.com id <05145-0@zcars00t.ca.nortel.com>; Fri, 21 Aug 1998 09:08:46 -0400 Date: 21 Aug 1998 09:08 EDT Sender: "Vahe Balabanian" To: civanlar@research.att.com Cc: rem-conf@es.net From: "Vahe Balabanian" Subject: Re: Proposed agenda for AVT WG at IETF in Chicago Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Reha, In message "Re: re:Re: Proposed agenda for AVT WG at IETF in Chicago", civanlar@research.att.com writes: >Actually, being somewhat involved in this work, I don't think that it is >that difficult to make the "useful parts" of MPEG4 work nicely over RTP. > >I guess, it would be helpful if Vahe can explain which parts of MPEG4 make >it "square." > These are my concerns: 1- MPEG-4 Timestamps specifically the Decoder Time Stamp do we need a special provision for RTP at the Sync Layer? 2- The Generic MPEG-4 Payload how do we deal with them in the RTP Mixers? 3- MPEG-4 Elementary stream FlexMuxing in the context of RTP. Does it break anything? 4- What is the equivalent of a Scene and Object Descriptor streams in RTP in the context of multicasting and Mixer operation. does RTP have to deal with these streams in a different way? In general when we describe the MPEG-4 RTP payload type don't we need to address the above to the extent there is nothing broken in RTP? May be there are answers to all these within the context of RTP. But we need to adress them all. I do not see the problem just as MPEG-4 stream mapping to RTP data transport. Thanks for asking the question, Vahe From rem-conf Fri Aug 21 06:13:08 1998 From rem-conf-request@es.net Fri Aug 21 06:13:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9qz6-0005An-00; Fri, 21 Aug 1998 06:12:04 -0700 Received: from smtpott1.nortel.ca [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9qz5-0005AX-00; Fri, 21 Aug 1998 06:12:03 -0700 Received: from zcars00t by smtpott1; Fri, 21 Aug 1998 09:11:28 -0400 Received: from ca.nortel.com by zcars00t.ca.nortel.com id <05146-0@zcars00t.ca.nortel.com>; Fri, 21 Aug 1998 09:08:46 -0400 Date: 21 Aug 1998 09:08 EDT Sender: "Vahe Balabanian" To: civanlar@research.att.com Cc: rem-conf@es.net From: "Vahe Balabanian" Subject: Re: Proposed agenda for AVT WG at IETF in Chicago Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Reha, In message "Re: re:Re: Proposed agenda for AVT WG at IETF in Chicago", civanlar@research.att.com writes: >Actually, being somewhat involved in this work, I don't think that it is >that difficult to make the "useful parts" of MPEG4 work nicely over RTP. > >I guess, it would be helpful if Vahe can explain which parts of MPEG4 make >it "square." > These are my concerns: 1- MPEG-4 Timestamps specifically the Decoder Time Stamp do we need a special provision for RTP at the Sync Layer? 2- The Generic MPEG-4 Payload how do we deal with them in the RTP Mixers? 3- MPEG-4 Elementary stream FlexMuxing in the context of RTP. Does it break anything? 4- What is the equivalent of a Scene and Object Descriptor streams in RTP in the context of multicasting and Mixer operation. does RTP have to deal with these streams in a different way? In general when we describe the MPEG-4 RTP payload type don't we need to address the above to the extent there is nothing broken in RTP? May be there are answers to all these within the context of RTP. But we need to adress them all. I do not see the problem just as MPEG-4 stream mapping to RTP data transport. Thanks for asking the question, Vahe From rem-conf Fri Aug 21 06:51:44 1998 From rem-conf-request@es.net Fri Aug 21 06:51:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9rZ3-0006hG-00; Fri, 21 Aug 1998 06:49:13 -0700 Received: from north.lcs.mit.edu [18.26.0.4] by mail1.es.net with smtp (Exim 1.81 #2) id 0z9rZ2-0006h6-00; Fri, 21 Aug 1998 06:49:12 -0700 Received: from north.lcs.mit.edu by north.lcs.mit.edu (SMI-8.6/SMI-SVR4) id JAA07014; Fri, 21 Aug 1998 09:49:07 -0400 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Vahe Balabanian cc: civanlar@research.att.com, rem-conf@es.net Subject: Re: Proposed agenda for AVT WG at IETF in Chicago In-reply-to: Your message of "21 Aug 1998 09:08:00 EDT." Date: Fri, 21 Aug 1998 09:49:07 -0400 Message-ID: <7012.903707347@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >>I guess, it would be helpful if Vahe can explain which parts of MPEG4 make >>it "square." >> >These are my concerns: > >1- MPEG-4 Timestamps specifically the Decoder Time Stamp > do we need a special provision for RTP at the Sync Layer? Given that you can't guarantee synchronized clocks between sender and receiver, all you need is synchronized clocks between different RTP streams from the same sender. Thus it seems to me that putting the MPEG-4 "Decoder Time Stamp" in the RTP timestamp field would be acceptable. Perhaps I'm missing something here. What's special about it being a decoder timestamp rather than a A/V capture timestamp? If all we're talking about is a constant offset, then as far as RTP is concerned, there's no significant difference. Mark From rem-conf Fri Aug 21 07:21:49 1998 From rem-conf-request@es.net Fri Aug 21 07:21:49 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9s3q-0007Yc-00; Fri, 21 Aug 1998 07:21:02 -0700 Received: from rumor.research.att.com [192.20.225.9] by mail1.es.net with smtp (Exim 1.81 #2) id 0z9s3p-0007YD-00; Fri, 21 Aug 1998 07:21:01 -0700 Received: from research.att.com ([135.207.30.100]) by rumor; Fri Aug 21 10:14:10 EDT 1998 Received: from surfcity.research.att.com ([135.207.128.5]) by research; Fri Aug 21 10:17:29 EDT 1998 Received: from pcmrcfast (pcmrcfast [135.207.131.70]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id KAA07558; Fri, 21 Aug 1998 10:17:28 -0400 (EDT) Message-ID: <019b01bdcd0d$4d70d0f0$4683cf87@pcmrcfast.research.att.com> Reply-To: "M. Reha Civanlar" From: "M. Reha Civanlar" To: "Mark Handley" , "Vahe Balabanian" Cc: Subject: Re: Proposed agenda for AVT WG at IETF in Chicago Date: Fri, 21 Aug 1998 10:09:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list -----Original Message----- From: Mark Handley To: Vahe Balabanian Cc: civanlar@research.att.com ; rem-conf@es.net Date: Friday, August 21, 1998 9:51 AM Subject: Re: Proposed agenda for AVT WG at IETF in Chicago > >>>I guess, it would be helpful if Vahe can explain which parts of MPEG4 make >>>it "square." >>> >>These are my concerns: >> >>1- MPEG-4 Timestamps specifically the Decoder Time Stamp >> do we need a special provision for RTP at the Sync Layer? > >Given that you can't guarantee synchronized clocks between sender and >receiver, all you need is synchronized clocks between different RTP >streams from the same sender. Thus it seems to me that putting the >MPEG-4 "Decoder Time Stamp" in the RTP timestamp field would be >acceptable. > >Perhaps I'm missing something here. What's special about it being a >decoder timestamp rather than a A/V capture timestamp? If all we're >talking about is a constant offset, then as far as RTP is concerned, >there's no significant difference. > >Mark > I guess, it would be useful to repeat the following discussion that I made earlier for the MPEG-4 payload type draft authors here again: All MPEG systems basically use three time stamps: the Presentation TS (PTS), the Decoding TS (DTS) and the program clock reference (PCR). In RTP, the time stamp is more or less equal to the PTS and the functionality of the PCR is to be handled by the NTP. As for the DTS, there is no equivalent in RTP because, in a multicast session, transmitters do not use time stamps to control buffers of numerous receivers which usually have heterogeneous and time varying reception conditions. Decoders are expected to do intelligent (network and source adaptive) buffering to reduce the chances of an overflow or underflow. The existing MPEG-1&2 payload types work perfectly O.K. with this approach. I don't see any reason for MPEG-4 to be different. I believe, either the use of the DTS is left optional or its length is made selectable in MPEG-4 spec. If this is true, this corner may be shaved by defining an Internet profile in MPEG-4 which does not transmit the DTS or make it small enough to reduce the overhead. ----------------------------------------------------------------------- M. Reha Civanlar Technology Leader, AT&T Labs - Research 100 Schultz Drive, Red Bank, NJ 07701, U.S.A civanlar@research.att.com Phone: +1 732 345 3305 Fax:+1 732 345 3033 http://www.research.att.com/info/mrc From rem-conf Fri Aug 21 07:31:41 1998 From rem-conf-request@es.net Fri Aug 21 07:31:40 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9sDQ-0000Ju-00; Fri, 21 Aug 1998 07:30:56 -0700 Received: from smtpott1.nortel.ca [192.58.194.78] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9sDP-0000Jg-00; Fri, 21 Aug 1998 07:30:55 -0700 Received: from zcars00t by smtpott1; Fri, 21 Aug 1998 10:30:36 -0400 Received: from ca.nortel.com by zcars00t.ca.nortel.com id <01118-0@zcars00t.ca.nortel.com>; Fri, 21 Aug 1998 10:27:38 -0400 Date: 21 Aug 1998 10:27 EDT Sender: "Vahe Balabanian" To: mjh@east.isi.edu Cc: civanlar@research.att.com, rem-conf@es.net From: "Vahe Balabanian" Subject: Re: Proposed agenda for AVT WG at IETF in Chicago Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message "Re: Proposed agenda for AVT WG at IETF in Chicago", mjh@east.isi.edu writes: > >>>I guess, it would be helpful if Vahe can explain which parts of MPEG4 make >>>it "square." >>> >>These are my concerns: >> >>1- MPEG-4 Timestamps specifically the Decoder Time Stamp >> do we need a special provision for RTP at the Sync Layer? > >Given that you can't guarantee synchronized clocks between sender and >receiver, all you need is synchronized clocks between different RTP >streams from the same sender. Thus it seems to me that putting the >MPEG-4 "Decoder Time Stamp" in the RTP timestamp field would be >acceptable. > >Perhaps I'm missing something here. What's special about it being a >decoder timestamp rather than a A/V capture timestamp? If all we're >talking about is a constant offset, then as far as RTP is concerned, >there's no significant difference. MPEG-4 experts may want to comment more extensively since they seem to be active on this reflector. In MPEG-4 there are two types of Timestamps: 1- Composition TS provides the time at which a Composition Unit on a composition buffer is composited in a scene (using information >from the Scene Stream) and rendered on the screen. 2- Decoding TS provides the time a received Access Unit on a decoder buffer is decompressed into a Composition Unit using an appropriate decoder for the stream (the decoder type is obtained >from the Object Descriptor Stream)and placed in a composition buffer. Vahe From rem-conf Fri Aug 21 09:21:56 1998 From rem-conf-request@es.net Fri Aug 21 09:21:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9tpA-0002NA-00; Fri, 21 Aug 1998 09:14:00 -0700 Received: from artemis-en.rus.uni-stuttgart.de (artemis.rus.uni-stuttgart.de) [129.69.1.28] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9tp9-0002Mt-00; Fri, 21 Aug 1998 09:13:59 -0700 Received: from kssun7.rus.uni-stuttgart.de (kssun7.rus.uni-stuttgart.de [129.69.30.17]) by artemis.rus.uni-stuttgart.de (8.8.8/8.8.8) with ESMTP id SAA02294; Fri, 21 Aug 1998 18:13:11 +0200 (MET DST) env-from (christ@rus.uni-stuttgart.de) Received: from rus.uni-stuttgart.de (ksat10.rus.uni-stuttgart.de [129.69.30.170]) by kssun7.rus.uni-stuttgart.de (8.8.8/8.8.8) with ESMTP id SAA25859; Fri, 21 Aug 1998 18:03:12 +0200 (MET DST) Message-ID: <35DDAACA.708F9C22@rus.uni-stuttgart.de> Date: Fri, 21 Aug 1998 19:13:46 +0200 From: Paul Christ X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net CC: wesner@rus.uni-stuttgart.de, christ@rus.uni-stuttgart.de, Christian Comiqs , Christine Guillemot Subject: Concerning: Proposed agenda for AVT WG at IETF in Chicago Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by artemis.rus.uni-stuttgart.de id SAA02294 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear all, in the context of the European project=20 'COMIQS - Commerce through=20 MPEG-4 over the Internet with Quality of Service' see http://www.ccett.fr/comiqs/welcome.htm INRIA/IRISA, Rennes and RUS, University of Stuttgart, Stuttgart are aiming at discussions in avt and mmusic concerning=20 - Generic Payload for RTP - RTSP-based Stream Control for MPEG-4 We are preparing related private Internet-Drafts for Orlando; you may see our colleague Stefan.Wesner@rus.uni-stuttgart.de in Chicago (talented but new :-) in search of further=20 discussions. Abstract of our ideas so far: Generic Payload for RTP ----------------------- inspired by ... Microsoft, Sun, ISO; FEC etc. proposals Our approach: study of applicability for MPEG-4 audio, video and possibly scene description streams=20 Our Ultimate goals: derive a payload=20 generic (i.e. unique for audio, video, possibly scene description) with a simple but still sufficient fragmentation and grouping mechanism.=20 Allowing for protection against packet loss while alleviating from extra connection management complexity for separate FEC channels in high-number-of-streams applications such as MPEG-4 with protocol support for a hierarchy of error control mechanisms (=91no=91,FEC, redundant data,...) adaptable to data segment types and network characteristics Possibly derive impact on MPEG-4 syntax (e.g drop HEC field of the=20 MPEG-4 video syntax) RTSP-based Stream Control for MPEG-4 ------------------------------------- Our Goal: stream control command methods reflecting syntax and semantics of the MPEG-4 scene nodes, in line with RTSP extension guidelines (section 1.5)=20 Dissociating=20 Connection Management ~ url and Stream Control ~ channelHandle Extending Syntax and Semantics of RTSP methods NormalPlayTime NPT extension to support MPEG-4 Absolute Time npt-ref =3D npt-hh : npt-mm : npt-ss . *DIGI= T Relative Time, Random Access Point RAP and Range extensions=20 use # HTML/SMIL fragment identifier,=20 specify ranges as npt-range | fragment-range Extended Syntax: loop (ch_identifier) e.g. PLAY loop (23,56,32) Additional Optional Methods e.g. R-MUTE Yours Paul Christ RUS From rem-conf Fri Aug 21 15:32:56 1998 From rem-conf-request@es.net Fri Aug 21 15:32:55 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0z9zcE-0006ag-00; Fri, 21 Aug 1998 15:25:02 -0700 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0z9zcB-0006aS-00; Fri, 21 Aug 1998 15:24:59 -0700 Received: from miller.ntc.nokia.com (miller.ntc.nokia.com [192.100.105.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id BAA17104; Sat, 22 Aug 1998 01:24:28 +0300 (EET DST) Received: from rhino.ntc.nokia.com by miller.ntc.nokia.com with ESMTP (1.39.111.2/16.2) id AA114208100; Fri, 21 Aug 1998 18:21:40 -0400 Received: from Microsoft Mail (PU Serial #1991) by rhino.ntc.nokia.com (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm)) id AA-1998Aug21.181800.1991.301988; Fri, 21 Aug 1998 18:21:40 -0400 From: subbiah@NASBPD01BS.ntc.nokia.com (Subbiah Baranitharan NRC/Bos) To: internet-drafts@ietf.org ('internet-drafts@ietf.org'), rem-conf@es.net ('rem-conf') Cc: casner@cisco.com ('Stephen Casner') Message-Id: <1998Aug21.181800.1991.301988@rhino.ntc.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===_1998Aug21.181800.1991.301988===_" Organization: Nokia Telecommunications Date: Fri, 21 Aug 1998 18:21:40 -0400 Subject: IETF draft to the AVT working group X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --===_1998Aug21.181800.1991.301988===_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello all, Attached is an Internet Draft to the AVT working group titled "User = Multiplexing in RTP payload between IP Telephony Gateways". Sorry for the late submission. Abstract This draft proposes a method to multiplex a number of low bit rate audio streams (upto 256) into a single RTP/UDP/IP connection between IP telephony gateways. Audio samples from different users are assem- bled into an RTP payload thus reducing the overhead of RTP/UDP/IP headers. To identify users sharing a single RTP/UDP/IP connection, a 2 byte MINI-Header is proposed. A channel negotiation procedure to assign and release channels on a single UDP connection between gateways is described. [[ umrt_ietf_drft_new.txt : 4859 in umrt_iet.f_d ]] regards, Barani Subbiah --===_1998Aug21.181800.1991.301988===_ Content-Type: application/octet-stream; name="umrt_iet.f_d" Content-Transfer-Encoding: base64 SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAgICAgICAgICAgICAgICAgICAgICAgQVZU ICBXb3JraW5nIEdyb3VwDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4NCmRyYWZ0LWlldGYtYXZ0LWJhcmFuaV9z ZW50aGlsLTAwLnR4dCAgICAgICAgICAgICAgTm9raWEgUmVzZWFyY2ggQ2VudGVyLg0KQXVnIDIx LCAxOTk4DQpFeHBpcmVzOiBGZWIgMjEsIDE5OTkNCg0KDQogICAgICAgIFVzZXIgTXVsdGlwbGV4 aW5nIGluIFJUUCBwYXlsb2FkIGJldHdlZW4gSVAgVGVsZXBob255IEdhdGV3YXlzDQoNCg0KU1RB VFVTIE9GIFRISVMgTUVNTw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0 LiBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdS0NCiAgIG1lbnRzIG9mIHRoZSBJbnRl cm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQNCiAgIGl0 cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZSB3b3JrLQ0KICAgaW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Yg c2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVk IGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRl IHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIG1hdGUtDQogICByaWFsIG9yIHRv IGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzIGBgd29yayBpbiBwcm9ncmVzcycnLg0KDQogICBUbyBs ZWFybiB0aGUgY3VycmVudCBzdGF0dXMgb2YgYW55IEludGVybmV0LURyYWZ0LCBwbGVhc2UgY2hl Y2sgdGhlDQogICBgYDFpZC1hYnN0cmFjdHMudHh0JycgbGlzdGluZyBjb250YWluZWQgaW4gdGhl IEludGVybmV0LURyYWZ0cyBTaGFkb3cNCiAgIERpcmVjdG9yaWVzIG9uIGZ0cC5pcy5jby56YSAo QWZyaWNhKSwgbmljLm5vcmR1Lm5ldCAoRXVyb3BlKSwNCiAgIG11bm5hcmkub3ouYXUgKFBhY2lm aWMgUmltKSwgZHMuaW50ZXJuaWMubmV0IChVUyBFYXN0IENvYXN0KSwgb3INCiAgIGZ0cC5pc2ku ZWR1IChVUyBXZXN0IENvYXN0KS4NCg0KICAgRGlzdHJpYnV0aW9uIG9mIHRoaXMgZG9jdW1lbnQg aXMgdW5saW1pdGVkLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFCU1RS QUNUDQoNCiAgIFRoaXMgZHJhZnQgcHJvcG9zZXMgYSBtZXRob2QgdG8gbXVsdGlwbGV4IGEgbnVt YmVyIG9mIGxvdyBiaXQgcmF0ZQ0KICAgYXVkaW8gc3RyZWFtcyAodXB0byAyNTYpIGludG8gYSBz aW5nbGUgUlRQL1VEUC9JUCBjb25uZWN0aW9uIGJldHdlZW4NCiAgIElQIHRlbGVwaG9ueSBnYXRl d2F5cy4gQXVkaW8gc2FtcGxlcyBmcm9tIGRpZmZlcmVudCB1c2VycyBhcmUgYXNzZW0tDQogICBi bGVkIGludG8gYW4gUlRQIHBheWxvYWQgdGh1cyByZWR1Y2luZyB0aGUgb3ZlcmhlYWQgb2YgUlRQ L1VEUC9JUA0KICAgaGVhZGVycy4gVG8gaWRlbnRpZnkgdXNlcnMgc2hhcmluZyBhIHNpbmdsZSBS VFAvVURQL0lQIGNvbm5lY3Rpb24sIA0KICAgYSAyIGJ5dGUgTUlOSS1IZWFkZXIgaXMgcHJvcG9z ZWQuIEEgY2hhbm5lbCBuZWdvdGlhdGlvbiBwcm9jZWR1cmUgdG8NCiAgIGFzc2lnbiBhbmQgcmVs ZWFzZSBjaGFubmVscyBvbiBhIHNpbmdsZSBVRFAgY29ubmVjdGlvbiBiZXR3ZWVuDQogICBnYXRl d2F5cyBpcyBkZXNjcmliZWQuICANCg0KDQoxIEludHJvZHVjdGlvbg0KDQogICBJUCB0ZWxlcGhv bnkgZ2F0ZXdheXMgcHJvdmlkZSBhbiBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgZXhpc3RpbmcNCiAg IGNpcmN1aXQgc3dpdGNoZWQgdGVsZXBob25lIG5ldHdvcmtzIChzdWNoIGFzIFBTVE4gYW5kIEdT TSkgYW5kIHRoZSANCiAgIHBhY2tldCBzd2l0Y2hlZCBJUCBkYXRhIG5ldHdvcmtzLiBJbiBhIHRy YWRpdGlvbmFsIElQIHRlbGVwaG9ueQ0KICAgYXBwbGljYXRpb24sIHRlbGVwaG9uZSBjYWxscyBi ZXR3ZWVuIFBTVE4vR1NNIHVzZXJzIGludGVyY29ubmVjdGVkIGJ5DQogICBhIHBhaXIgb2YgSVAg dGVsZXBob255IGdhdGV3YXlzIGFyZSBjYXJyaWVkIGJ5IHNlcGFyYXRlIFJUUC9VRFAvSVAgDQog ICBjb25uZWN0aW9ucy4gQ29kZWNzIGF0IHRoZSBJUCB0ZWxlcGhvbnkgZ2F0ZXdheSB3aGljaCBj b21wcmVzcyANCiAgIGluY29taW5nIFBTVE4vR1NNIHNwZWVjaCBzYW1wbGVzIGdlbmVyYXRlIHBh Y2tldHMgd2l0aCBzaXplcyByYW5naW5nDQogICBmcm9tIDUgdG8gMjAgYnl0ZXMgcGVyIHNwZWVj aCBzYW1wbGUuIEZvciBleGFtcGxlLCBHLjcyMy4xICh0aGUgbW9zdA0KICAgcG9wdWxhciBJUCB0 ZWxlcGhvbnkgY29kZWMgYW5kIHRoZSBJTVRDIFZvSVAgRm9ydW0ncyBtYW5kYXRvcnkgbG93DQog ICBiaXQtcmF0ZSBjb2RlYyksIGdlbmVyYXRlcyBhIDIwIGJ5dGUgc3BlZWNoIHBhY2tldCBhdCAz MCBtcyBpbnRlcnZhbHMNCg0KDQogICAgICAgDQpCLiBTdWJiaWFoLCBTLiBTZW5nb2RhbiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCg0KDQpJbnRlcm5ldCBE cmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXVnIDE1LCAx OTk4DQoNCg0KICAgWzRdLiBNYW55IGNvZGVjcyB1c2VkIGluIGNlbGx1bGFyIGVudmlyb25tZW50 cyBnZW5lcmF0ZSBwYWNrZXRzIG9mIA0KICAgc2l6ZSBsZXNzIHRoYW4gMTAgYnl0ZXMgcGVyIHNw ZWVjaCBzYW1wbGUuIFNtYWxsIHNpemUgcGFja2V0cyBhcmUNCiAgIHN1YmplY3QgdG8gYSBsYXJn ZSBvdmVyaGVhZCB3aGVuIHRyYW5zZmVycmVkIHVzaW5nIHRoZSBSZWFsIHRpbWUNCiAgIFRyYW5z cG9ydCBQcm90b2NvbCAoUlRQKS4gVGhlIFJUUC9VRFAvSVAgb3ZlcmhlYWQgaXMgNDAgYnl0ZXMN CiAgICgxMis4KzIwKSBmb3IgYSBzaW5nbGUgc3BlZWNoIHBhY2tldC4gRm9yIGV4YW1wbGUsIGEg MTAgYnl0ZSBwYWNrZXQNCiAgIHRyYW5zZmVycmVkIHZpYSBSVFAvVURQL0lQIGhhcyBhbiBvdmVy aGVhZCBvZiA4MCUuIA0KDQogICBJbiBhZGRpdGlvbiwgZm9yIGVhY2ggY2FsbCByZXF1ZXN0IGEg c2luZ2xlIFVEUC9JUCBjb25uZWN0aW9uIChhIHBhaXINCiAgIG9mIFVEUCBwb3J0cykgaXMgZXN0 YWJsaXNoZWQgYmV0d2VlbiB0aGUgZ2F0ZXdheXMuIFRoaXMgbm90IG9ubHkNCiAgIGxpbWl0cyB0 aGUgbnVtYmVyIG9mIGF1ZGlvIHN0cmVhbXMgYmV0d2VlbiB0aGUgZ2F0ZXdheXMgdG8gdGhlIG51 bWJlcg0KICAgb2YgYXZhaWxhYmxlIFVEUCBwb3J0IHBhaXJzLCBidXQgYWxzbyByZXF1aXJlcyBh IGxhcmdlIHN0YXRlIChtZW1vcnkpDQogICB0byBiZSBtYWludGFpbmVkIGF0IHRoZSB0ZWxlcGhv bnkgZ2F0ZXdheXMsIHRoZXJlYnkgbWFraW5nIHRoZXNlDQogICBnYXRld2F5cyBsZXNzIHNjYWxl YWJsZS4gDQoNCiAgIEFub3RoZXIgZGlzYWR2YW50YWdlIG9mIHRoZSB0cmFkaXRpb25hbCBSVFAv VURQL0lQIG1ldGhvZCBpbiBhDQogICBnYXRld2F5IHNjZW5hcmlvIGlzIHRoZSBwb3NzaWJpbGl0 eSBvZiBjb25nZXN0aW9uIGF0IGludGVybWVkaWF0ZQ0KICAgcm91dGVycyBpbiB0aGUgSVAgbmV0 d29yay4gSW4gdGhlIFJUUC9VRFAvSVAgbWV0aG9kLCBlYWNoIGluZGl2aWR1YWwNCiAgIHNwZWVj aCBwYWNrZXQgaXMgdHJhbnNtaXR0ZWQgYXMgYSBzaW5nbGUgSVAgcGFja2V0LCB3aGljaCByZXN1 bHRzIGluDQogICBsYXJnZSBudW1iZXIgb2Ygc21hbGwgc2l6ZWQgSVAgcGFja2V0cyBiZXR3ZWVu IGdhdGV3YXlzLiBUaGlzIGlzIGENCiAgIHBvdGVudGlhbCBzaXR1YXRpb24gZm9yIGNvbmdlc3Rp b24gYXQgaW50ZXJtZWRpYXRlIElQIHJvdXRlcnMuIA0KICAgQ29uZ2VzdGlvbiBpbiBJUCBuZXR3 b3JrcyByZXN1bHRzIGluIHBhY2tldCBsb3NzIGFuZCBVRFAgZG9lcyBub3QgDQogICBoYXZlIGFu eSByZS10cmFuc21pc3Npb24gbWVjaGFuaXNtIHRvIHJlY292ZXIgbG9zdCBwYWNrZXRzLiBBbHNv LCANCiAgIHJlYWwgdGltZSBhcHBsaWNhdGlvbnMgc3VjaCBhcyBzcGVlY2ggYXJlIGludG9sZXJh bnQgdG8gZGVsYXkgY2F1c2VkIA0KICAgYnkgcmUtdHJhbnNtaXNzaW9uLiANCg0KICAgSW4gdGhp cyBkcmFmdCwgd2UgcHJvcG9zZSBhIG1lY2hhbmlzbSB0aGF0IGVuYWJsZXMgc2V2ZXJhbCBzdHJl YW1zDQogICAodXB0byAyNTYpIHRvIHNoYXJlIGEgc2luZ2xlIFJUUC9VRFAvSVAgY29ubmVjdGlv biBiZXR3ZWVuIElQIA0KICAgdGVsZXBob255IGdhdGV3YXlzIHRoZXJlYnkgcmVkdWNpbmcgdGhl IG92ZXJoZWFkLCBsb3dlcmluZyB0aGUNCiAgIHBvc3NpYmlsaXR5IGZvciBjb25nZXN0aW9uIGF0 IElQIHJvdXRlcnMsIGFuZCBtYWtpbmcgc3VjaCBnYXRld2F5cw0KICAgbW9yZSBzY2FsZWFibGUu IFRoaXMgbWV0aG9kIGlzIHN1aXRhYmxlIGZvciBJUCB0ZWxlcGhvbnkgZ2F0ZXdheXMNCiAgIHRo YXQgaW50ZXJjb25uZWN0IFBTVE4vR1NNIHVzZXJzIHRocm91Z2ggSVAgbmV0d29ya3MuIEluIGEg Y2VsbHVsYXINCiAgIGVudmlyb25tZW50LCBpdCBjYW4gYWxzbyBiZSB1c2VkIGluIGNlbGx1bGFy IHRydW5raW5nLCBsaW5rcyB0aGF0IA0KICAgaW50ZXJjb25uZWN0IEJhc2UgU3RhdGlvbiAoQlMp LCBCYXNlIFN0YXRpb24gY29udHJvbGxlciAoQlNDKSwgYW5kIA0KICAgTW9iaWxlIFN3aXRjaGlu ZyBDZW50ZXIgKE1TQykgb2YgYSBSYWRpbyBBY2Nlc3MgTmV0d29yayAoUkFOKS4gDQogICBJbmRp dmlkdWFsIHVzZXIgcGFja2V0cyBtdWx0aXBsZXhlZCBpbiBhbiBSVFAgcGF5bG9hZCBhcmUgaWRl bnRpZmllZCANCiAgIHVzaW5nIGEgMiBieXRlIE1JTkktaGVhZGVyLiBUaGUgY2hhbm5lbCBhc3Nv Y2lhdGlvbiBiZXR3ZWVuIGdhdGV3YXlzIA0KICAgZm9yIGEgc2luZ2xlIHVzZXIgY2FuIGJlIGNh cnJpZWQgb3V0IGJ5IG9uZSBvZiB0aGUgdGhyZWUgbWVjaGFuaXNtcyANCiAgIGRlc2NyaWJlZCBs YXRlciBpbiB0aGlzIGRyYWZ0LiANCg0KMiBVc2VyIG11bHRpcGxleGluZyBpbiBSVFAgcGF5bG9h ZA0KDQogICBJdCBoYXMgYmVlbiBvYnNlcnZlZCB0aGF0LCBhdCBhbnkgZ2l2ZW4gdGltZSB0aGVy ZSBhcmUgbXVsdGlwbGUgDQogICBhY3RpdmUgdXNlcnMgYmV0d2VlbiBJUCB0ZWxlcGhvbnkgZ2F0 ZXdheSBwYWlycyB0aGF0IGludGVyY29ubmVjdCANCiAgIFBTVE4vUEJYL0dTTSBjbG91ZHMuIFRo aXMgaXMgYWxzbyB0cnVlIGluIHRoZSBjYXNlIG9mIGNlbGx1bGFyIA0KICAgdHJ1bmtpbmcgYmV0 d2VlbiBhIEJhc2UgVHJhbnNtaXNzaW9uIFN5c3RlbSAoQlRTKSBhbmQgQlNDL01TQy4gQXQgDQog ICBwcmVzZW50LCBJUCB0ZWxlcGhvbnkgZ2F0ZXdheXMgZXN0YWJsaXNoIGFuZCBtYWludGFpbiBh IHNlcGFyYXRlIA0KICAgUlRQL1VEUC9JUCBjb25uZWN0aW9uIGZvciBlYWNoIGNhbGwgcmVxdWVz dC4gSW4gdGhlIGFib3ZlIHNjZW5hcmlvcywgDQogICBhIGxhcmdlIG51bWJlciBvZiBjb25uZWN0 aW9ucyBvcmlnaW5hdGUgYW5kIHRlcm1pbmF0ZSBiZXR3ZWVuIHR3byANCiAgIGdhdGV3YXlzIGlu dGVyY29ubmVjdGVkIGJ5IGFuIElQIG5ldHdvcmsuIFRoaXMgaXMgYW4gaWRlYWwgc2l0dWF0aW9u IA0KICAgZm9yIG11bHRpcGxleGluZyBhIGdyb3VwIG9mIHVzZXJzIGluIGEgc2luZ2xlIFJUUC9V RFAvSVAgY29ubmVjdGlvbi4gDQoNCiAgIFRoZSBtZWNoYW5pc20gZm9yIHVzZXIgbXV4IGluIFJU UCB0aGF0IGlzIHByb3Bvc2VkIGluIHRoaXMgZHJhZnQgDQogICBkZWNyZWFzZXMgdGhlIG92ZXJo ZWFkIGJ5IG11bHRpcGxleGluZyB0d28gb3IgbW9yZSAodXAgdG8gMjU2KSBsb3cgDQogICBiaXQg cmF0ZSBjb25uZWN0aW9ucyAoY29tcHJlc3NlZCBzcGVlY2gpIGluIGEgc2luZ2xlIFJUUC9VRFAv SVAgDQogICBjb25uZWN0aW9uLiBUbyBlbmFibGUgc3VjaCBtdWx0aXBsZXhpbmcsIGEgMiBieXRl IGhlYWRlciBjYWxsZWQgDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAg ICAgICAgICAgICAgICAJCQkgICAgICAgICAgICBBdWcgMTUsIDE5OTgNCg0KDQogICBNSU5JLUhl YWRlciBpcyBwcmVwZW5kZWQgdG8gZWFjaCBtaW5pIHBhY2tldCBiZWZvcmUgaXQgaXMgYXNzZW1i bGVkIA0KICAgd2l0aCBvdGhlciBtaW5pIHBhY2tldHMgaW50byBhbiBSVFAgcGF5bG9hZC4gVG8g aWRlbnRpZnkgYSBzaW5nbGUgDQogICB1c2VyIGFtb25nIHRoZSBudW1iZXIgb2YgdXNlcnMgc2hh cmluZyB0aGUgc2FtZSBSVFAgY29ubmVjdGlvbiwgZWFjaCANCiAgIHVzZXIgaXMgYXNzaWduZWQg YSB1bmlxdWUgQ2hhbm5lbCBJZGVudGlmaWVyIChDSUQpIHdoaWNoIGlzIG5lZ290LQ0KICAgaWF0 ZWQgZHVyaW5nIGNvbm5lY3Rpb24gc2V0dXAuIFRoZSBDSUQgbmVnb3RpYXRpb24gcHJvY2VkdXJl IGlzIA0KICAgY2FycmllZCBvdXQgYnkgYSBjb250cm9sIHNpZ25hbGluZyB3aGljaCBtYXkgYmUg YmFzZWQgb24gb25lIG9mIHRoZQ0KICAgdGhyZWUgbWV0aG9kcyhDTlAsIFNJUCBhbmQgSC4yMjUp IGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuIA0KDQoyLjEgTUlOSS1IZWFkZXINCg0KICAgVGhlIGZv cm1hdCBvZiBhIE1JTkktSGVhZGVyIGlzIHNob3duIGluIEZpZ3VyZSAxOg0KDQoNCiAgICAgICAg ICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgIA0KICAgICAgICAgICAgICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgICAgICAgICAgfCAgICAg IENJRCAgICAgIHwgICBMSSAgICAgIHxUfFJ8ICAgDQogICAgICAgICAgICAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoJCSAgICAgRmlndXJlIDE6IEZvcm1hdCBvZiBh IE1JTkktSGVhZGVyDQoNCg0KICAgVGhlIGxlbmd0aCBvZiB0aGUgTUlOSS1IZWFkZXIgaXMgMiBi eXRlcywgd2hpY2ggaW5jbHVkZXMgYSBDaGFubmVsIA0KICAgSWRlbnRpZmllcihDSUQpLCBMZW5n dGggSW5kaWNhdG9yIChMSSksIFRyYW5zaXRpb24gYml0IChUKSBhbmQgYSANCiAgIFJlc2VydmVk IGJpdCAoUikuIFRoZSBwdXJwb3NlIG9mIGVhY2ggZmllbGQgaXMgZGVzY3JpYmVkIGJlbG93Og0K DQogICAgIC0gQ2hhbm5lbCBJRGVudGlmaWNhdGlvbiAoQ0lEKTogVGhpcyA4IGJpdCBmaWVsZCBh bGxvd3MgYSBtYXhpbXVtIA0KICAgICAgIG9mIDI1NiB1c2VycyB0byBzaGFyZSBhIHNpbmdsZSBS VFAvVURQL0lQIGNvbm5lY3Rpb24uIFdoZW4gdGhlIA0KICAgICAgIHRvdGFsIG51bWJlciBvZiB1 c2VycyBleGNlZWRzIDI1NiwgYSBuZXcgUlRQL1VEUC9JUCBjb25uZWN0aW9uIGlzDQogICAgICAg ZXN0YWJsaXNoZWQuDQoNCiAgICAgLSBMZW5ndGggSW5kaWNhdG9yIChMSSk6IFRoaXMgNiBiaXQg ZmllbGQgYWxsb3dzIGEgbWF4aW11bSBwYXlsb2FkIA0KICAgICAgIHNpemUgb2YgNjQgYnl0ZXMu DQoNCiAgICAgLSBUcmFuc2l0aW9uIGJpdCAoVCk6IFRoZSB0cmFuc2l0aW9uIGJpdCBpcyB1c2Vk IHRvIGZhY2lsaXRhdGUNCiAgICAgICBkeW5hbWljIHJlLW5lZ290aWF0aW9uIG9mIG1pbmktcGFj a2V0IHByb2Nlc3NpbmcuIE5vdGlmaWNhdGlvbiBvZg0KICAgICAgIHN1Y2ggY2hhbmdlcyBvY2N1 cnMgYnkgdG9nZ2xpbmcgdGhlIGJpdC4NCg0KICAgICAtIFJlc2VydmVkIGJpdCAoUik6IFRoZSB1 c2Ugb2YgdGhpcyBiaXQgaXMgYmVpbmcgZXhwbG9yZWQgYXQgdGhpcw0KICAgICAgIG1vbWVudC4N Cg0KICAgSXQgaGFzIGJlZW4gb2JzZXJ2ZWQgdGhhdCBhbiA4IGJpdCBDSUQgaXMgc3VmZmljaWVu dCBmb3IgbXVsdGlwbGV4aW5nDQogICBzaW5jZSB0aGVyZSBhcmUgZW5vdWdoIHNwZWVjaCBzYW1w bGVzIGF0IGFueSBpbnN0YW5jZS4gTW9zdCBvZiB0aGUgDQogICBjb2RlY3MgZ2VuZXJhdGUgcGFj a2V0cyBsZXNzIHRoYW4gNDAgYnl0ZXMgcGVyIHNwZWVjaCBzYW1wbGUgdGhhdCBjYW4NCiAgIGJl IGVhc2lseSBhY2NvbW1vZGF0ZWQgd2l0aCBhIDYgYml0IExJIGZpZWxkLiBXaGlsZSB0aGUgcHJl c2VuY2Ugb2YgYQ0KICAgU2VxdWVuY2UgTnVtYmVyIChTTikgZmllbGQgYW5kIGEgTWFya2VyIChN KSBmaWVsZCBpbiB0aGUgbWluaS1oZWFkZXINCiAgIGNvdWxkIGJlIHVzZWZ1bCBhdCB0aGUgcmVj ZWl2aW5nIGdhdGV3YXksIHdlIGJlbGlldmUgdGhhdCB0aGUgDQogICBwcmVzZW5jZSBvZiB0aGVz ZSBmaWVsZHMgaXMgbm90IGNyaXRpY2FsLiBUaGUgU04gZmllbGQgaW4gdGhlIFJUUCANCiAgIGhl YWRlciBjYW4gZ3VhcmFudGVlIHRoZSBvcmRlciBvZiBwYWNrZXQgKFJUUCBwYWNrZXQpIGFycml2 YWwgYXQgdGhlDQogICByZWNlaXZlci4gSWYgdGhlIHBhY2tldCBtdWx0aXBsZXhpbmcgb3JkZXIg YXQgdGhlIHRyYW5zbWl0dGVyIGlzIA0KICAgbWFpbnRhaW5lZCB0aGVuIHRoZXJlIGlzIG5vIG5l ZWQgZm9yIFNOIGluIHRoZSBNSU5JLUhlYWRlciBmcm9tIHRoZSANCiAgIHN0YW5kcG9pbnQgb2Yg aW4tc2VxdWVuY2UgYXJyaXZhbCBvZiBwYWNrZXRzIHdpdGhpbiBhIHNpbmdsZSANCiAgIFJUUC9V RFAvSVAgY29ubmVjdGlvbi4gTW9yZW92ZXIsIGEgSGVhZGVyIEVycm9yIENvbnRyb2wgKEhFQykg ZmllbGQgDQogICB0byBwcm90ZWN0IGZyb20gdHJhbnNtaXNzaW9uIGVycm9ycyBoYXMgYmVlbiBs ZWZ0IG91dCBiZWNhdXNlIFVEUCANCiAgIGNoZWNrc3VtIGNvdWxkIGJlIHVzZWQgZm9yIHRoZSBz YW1lIHB1cnBvc2UuDQoNCg0KDQoNCkIuIFN1YmJpYWgsIFMuIFNlbmdvZGFuICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCVtQYWdlIDNdDQoNCg0KSW50ZXJuZXQgRHJhZnQgCQkJ CSAJCQkgIEF1ZyAxNSwgMTk5OA0KDQoNCg0KMi4yIFJUUCBQYXlsb2FkIEZvcm1hdA0KDQogICBB IHNwZWVjaCBzYW1wbGUgKHZvaWNlIHBhY2tldCkgcmVjZWl2ZWQgZnJvbSBhIHVzZXIgaXMgY29u dmVydGVkIHRvIGENCiAgIG1pbmkgcGFja2V0IGJ5IGFkZGluZyB0aGUgMiBieXRlIE1JTkktSGVh ZGVyLiBUaGUgQ0lEIHNlbGVjdGlvbiBhbmQgDQogICBjaGFubmVsIG5lZ290aWF0aW9uIHByb2Nl ZHVyZXMgYXJlIGNhcnJpZWQgb3V0IGJlZm9yZSB0aGUgcGFja2V0IGlzIA0KICAgYXNzZW1ibGVk LiBUaGVzZSBwcm9jZWR1cmVzIGFyZSBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLiBUaGUgYXNzZW1i bHkNCiAgIG9mIG1pbmkgcGFja2V0cyBpbnRvIGEgc2luZ2xlIFJUUCBwYXlsb2FkIHdpdGggUlRQ L1VEUC9JUCBoZWFkZXIgaXMNCiAgIHNob3duIGluIEZpZ3VyZSAyLiBUaGUgbWluaSBwYWNrZXRz IGZvbGxvdyB0aGUgUlRQIGhlYWRlciBhbmQgZWFjaA0KICAgbWluaSBwYWNrZXQgaXMgZGVsaW5l YXRlZCBieSB0aGUgMiBieXRlIE1JTkktSGVhZGVyLiBUaGlzIGFycmFuZ2VtZW50DQogICBvZiBh IE1JTkktaGVhZGVyIGZvbGxvd2VkIGJ5IHBheWxvYWQgYWxsb3dzIHZhcmlhYmxlIHNpemVkIHBh Y2tldHMNCiAgICg8PSA2NCBieXRlcykgdG8gYmUgYXNzZW1ibGVkIHdpdGhvdXQgdGhlIGtub3ds ZWRnZSBvZiB0aGUgcGF5bG9hZCANCiAgIGl0c2VsZi4gTW9yZW92ZXIsIHRoaXMgc2NoZW1lIHJl cXVpcmVzIGEgdmVyeSBzaW1wbGUgZGUtbXVsdGlwbGV4aW5nDQogICBhbGdvcml0aG0gYXQgdGhl IHJlY2VpdmVyLiBUaGUgUlRQIHBheWxvYWQgcmVjZWl2ZWQgYnkgdGhlIHJlbW90ZSANCiAgIGdh dGV3YXkgaXMgZGUtYXNzZW1ibGVkIHRvIHJlY292ZXIgdGhlIGluZGl2aWR1YWwgbWluaSBwYWNr ZXRzIHVudGlsIA0KICAgdGhlIHBheWxvYWQgYmVjb21lcyBlbXB0eS4gVGhlIHBhY2tldHMgYXJl IHRoZW4gZGVsaXZlcmVkIHRvIHRoZQ0KICAgcmVzcGVjdGl2ZSB1c2VycyBiYXNlZCBvbiB0aGUg Y2hhbm5lbCBhc3NvY2lhdGlvbiBjYXJyaWVkIG91dCBkdXJpbmcgDQogICB0aGUgY2FsbCBzZXR1 cCBwaGFzZS4gDQoNCg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rICAgKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICsgICAgICAgKyAgICAg ICArICAgICArICAgICArICAgICArICAgICArICAgKyAgICAgKyAgICAgfA0KICAgICB8IElQICAg ICsgIFVEUCAgKyBSVFAgICArIE1IMSArIFZQMSArIE1IMiArIFZQMiArIH4gKyBNSG4gKyBWUG4g fA0KICAgICB8ICgyMCkgICsgICg4KSAgKyAoMTIpICArICgyKSArICAgICArICgyKSArICAgICAr ICAgKyAoMikgKyAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rICAgKy0rLSstKy0rLSstKw0KDQoJKk1IIC0gTWluaSBIZWFkZXIsIFZQ IC0gVm9pY2UgUGFja2V0DQoNCgkgICBGaWd1cmUgMi4gUlRQIHBheWxvYWQgZm9ybWF0IHdpdGgg dXNlciBtdWx0aXBsZXhpbmcNCg0KMi4zIFBhY2tldCBhc3NlbWJseSB0aW1lcg0KDQogICBXaGls ZSBhc3NlbWJsaW5nIG1pbmkgcGFja2V0cyBpbnRvIGFuIFJUUCBwYXlsb2FkLCB0aGVyZSBpcyBh IG5lZWQgdG8NCiAgIGNvbnRyb2wgdGhlIHdhaXRpbmcgdGltZSAoZGVsYXkpIGJldHdlZW4gdGhl IHBsYWNlbWVudCBvZiB0aGUgZmlyc3QgDQogICBwYWNrZXQgaW4gdGhlIFJUUCBwYXlsb2FkIGFu ZCB0aGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBjb21wbGV0ZSBJUCANCiAgIHBhY2tldCB0byB0aGUg cmVtb3RlIGdhdGV3YXkuIFdpdGhvdXQgYSB0aW1lciwgcGFja2V0cyBwbGFjZWQgYXQgdGhlIA0K ICAgYmVnaW5uaW5nIHdpbGwgYmUgc3ViamVjdGVkIHRvIGEgbGFyZ2UgZGVsYXkuIFRoaXMgcHJv YmxlbSBvY2N1cnMgDQogICB3aGVuIHRoZXJlIGlzIGEgbGFyZ2UgaW50ZXJ2YWwgYmV0d2VlbiBz dWNjZXNzaXZlIHBhY2tldCBhcnJpdmFscyBhdCANCiAgIHRoZSBtdWx0aXBsZXhpbmcgZW5kLiBU byBzb2x2ZSB0aGlzIHByb2JsZW0sIHdlIHByb3Bvc2UgYSB0aW1lciANCiAgIGNhbGxlZCBUSU1F Ul9NVVggdG8gY29udHJvbCB0aGUgbWF4aW11bSBkZWxheSBhIG1pbmkgcGFja2V0IG1heSBiZSAN CiAgIHN1YmplY3RlZCB0byBkdXJpbmcgdGhlIFJUUCBwYXlsb2FkIGFzc2VtYmx5LiBUaGUgVElN RVJfTVVYIGlzIA0KICAgaW5pdGlhbGl6ZWQgd2hlbiB0aGUgZmlyc3QgcGFja2V0IGlzIHBsYWNl ZCBpbiB0aGUgUlRQIHBheWxvYWQgYW5kIA0KICAgdXBvbiB0aGUgdGltZXIgZXhwaXJ5IHRoZSBS VFAvVURQL0lQIHBhY2tldCBpcyB0cmFuc21pdHRlZC4gVGhlcmUgYXJlDQogICBpbnN0YW5jZXMg d2hlbiB0aGUgUlRQL1VEUC9JUCBwYWNrZXQgbmVlZHMgdG8gYmUgdHJhbnNtaXR0ZWQgd2l0aG91 dCANCiAgIHRoZSBleHBpcnkgb2YgVElNRVJfTVVYLiBUaGUgaGlnaGVyIHRoZSBUSU1FUl9NVVgg dmFsdWUgdGhlIGJldHRlciANCiAgIHRoZSBiYW5kd2lkdGggZWZmaWNpZW5jeS4gSG93ZXZlciwg YSBoaWdoZXIgVElNRVJfTVVYIHZhbHVlIG1lYW5zIA0KICAgYWRkaXRpb25hbCBkZWxheSBmb3Ig dm9pY2UgcGFja2V0cy4NDQoNCjIuNCBQYWNrZXQgU2l6ZQ0KDQogICBUaGUgYXNzZW1ibHkgcHJv Y2VzcyBvZiBtaW5pLXBhY2tldHMgaW50byBhbiBSVFAgcGF5bG9hZCBzaG91bGQgbm90DQogICBv bmx5IGNvbnNpZGVyIHRoZSBUSU1FUl9NVVggdmFsdWUgYnV0IHNob3VsZCBhbHNvIHRha2UgaW50 byBhY2NvdW50IA0KICAgdGhlIHNpemUgb2YgdGhlIHJlc3VsdGluZyBJUCBkYXRhZ3JhbS4gVGhl IHNpemUgb2YgdGhlIHJlc3VsdGluZyBJUCANCiAgIGRhdGFncmFtIHNob3VsZCBub3QgZXhjZWVk IHRoZSBtYXhpbXVtIHRyYW5zbWlzc2lvbiB1bml0IChNVFUpIG9mIHRoZQ0KDQoNCg0KQi4gU3Vi YmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDRdDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAJCSAgICAgICAgICAg ICAgIEF1ZyAxNSwgMTk5OA0KDQoNCiAgIElQIG5ldHdvcmsuIEhlbmNlLCB3aGVuIHRoZSBJUCBu ZXR3b3JrIGlzIHRoZSBwdWJsaWMgSW50ZXJuZXQsIHRoZSANCiAgIHNpemUgb2YgdGhlIElQIGRh dGFncmFtIHNob3VsZCBub3QgZXhjZWVkIDE1MDAgYnl0ZXMuIEl0IGhhcyBiZWVuIA0KICAgZGV0 ZXJtaW5lZCB0aGF0IGFuIElQIGRhdGFncmFtIG9mIHNpemUgbGVzcyB0aGFuIDE1MDAgYnl0ZXMg dXN1YWxseSANCiAgIGdvZXMgdGhyb3VnaCB0aGUgSW50ZXJuZXQgdW5mcmFnbWVudGVkLg0KDQoy LjUgVURQIGNvbm5lY3Rpb24NCg0KICAgSW1wbGVtZW50YXRpb24gZGV0YWlscyBvZiBzaGFyaW5n IGEgcGFpciBvZiBVRFAgcG9ydHMgYW1vbmcgZGlmZmVyZW50DQogICB1c2VycyBhbmQgcmV1c2lu ZyB0aGUgc2FtZSBwb3J0IG51bWJlcnMgZm9yIHBlcnNpc3RlbnQgVURQIHNlc3Npb25zIA0KICAg YXJlIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gDQoNCjMgQ29udHJvbCBzaWdu YWxpbmcgZm9yIHVzZXIgbXVsdGlwbGV4aW5nIA0KDQogICBUaGUgdXNlciBwbGFuZSBhbmQgY29u dHJvbCBwbGFuZSBiZXR3ZWVuIGdhdGV3YXlzIGlzIHNob3duIGluIA0KICAgRmlndXJlIDMuIFRo ZSBjb250cm9sIHBsYW5lIHNpZ25hbGluZyBpcyBuZWVkZWQgYmVjYXVzZSBwZWVyIE11eCANCiAg IGNvbnRyb2xsZXJzIGFyZSByZXF1aXJlZCB0byBuZWdvdGlhdGUgYSBjaGFubmVsIGZvciBhbiBp bmNvbWluZyBjYWxsIA0KICAgcmVxdWVzdCBvbiBhbiBleGlzdGluZyBvciBvbiBhIG5ldyBVRFAg Y29ubmVjdGlvbi4gVGhlIGNvbnRyb2wgDQogICBzaWduYWxpbmcgaXMgdHJhbnNmZXJyZWQgdXNp bmcgYSBjb21tb24gcGVyc2lzdGVudCBjb25uZWN0aW9uLCB3aGljaA0KICAgbWF5IGJlIGVpdGhl ciBjb25uZWN0aW9uIG9yaWVudGVkIChUQ1ApIG9yIGNvbm5lY3Rpb25sZXNzIChVRFApLg0KICAg VGhlIHVzZXIgcGxhbmUgYXNzb2NpYXRpb24gKENJRCBhbGxvY2F0aW9uIG9uIGEgVURQIGNvbm5l Y3Rpb24pIGlzIA0KICAgbWFkZSBhZnRlciBhIHN1Y2Nlc3NmdWwgY29ubmVjdGlvbiBzZXR1cC4g SW4gdGhpcyBkcmFmdCwgd2UgZGVzY3JpYmUNCiAgIHRocmVlIGRpZmZlcmVudCBhcHByb2FjaGVz IHRvIGVzdGFibGlzaCBhbmQgY2xlYXIgYSBDSUQgYXNzb2NpYXRpb24uDQogICBUaGUgdXNlciBw bGFuZSBkYXRhIGlzIGNhcnJpZWQgb3ZlciBSVFAvVURQL0lQIGxheWVycyBpbiBhIG1hbm5lcg0K ICAgc2ltaWxhciB0byB0aGUgYXVkaW8gYW5kIHZpZGVvIHRyYW5zcG9ydCBvdmVyIElQIG5ldHdv cmtzLiBUaGUNCiAgIGRlc2NyaXB0aW9uIG9mIHRoZSBzaWduYWxsaW5nIGFuZCBjb250cm9sIG9w ZXJhdGlvbiBpcyBub3QgbWVhbnQgdG8NCiAgIGJlIGNvbXByZWhlbnNpdmUuDQoNCgkrKysrKysr KysrKysrKysrKysrCQkJCSsrKysrKysrKysrKysrKysrKysNCgkrIE11eCBDb250cm9sbGVyICAr CQkJCSsgTXV4IGNvbnRyb2xsZXIgICsNCgkrKysrKysrKysrKysrKysrKysrCQkJCSsrKysrKysr KysrKysrKysrKysNCgkJfCAgICB8CQkJCQkgICB8CQl8CQ0KCQl8ICAgIHwJVS1wbGFuZQkJICAg ICAgICAgIFUtcGxhbmUgIHwJCXxDLXBsYW5lIA0KQy1wbGFuZQkgICAgICAgIHwgICArKysrKysr CQkJCSsrKysrKysJICAgICAgICB8CQ0KCQl8ICAgKyBSVFAgKwkJCQkrIFJUUCArCSAgICAgICAg fA0KCSsrKysrKysrKysrKysrKysrKysJCQkJKysrKysrKysrKysrKysrKysrKw0KCSsgIFRDUCAg IHwgICBVRFAgICsJCQkJKyAgIFVEUCAgfCAgVENQCSAgKyANCgkrKysrKysrKysrKysrKysrKysr CQkJCSsrKysrKysrKysrKysrKysrKysNCgkrCUlQCSAgKysrKz4JICBJUCBORVQgICAgICAgICAg PCsrKysrKwlJUAkgICsNCgkrKysrKysrKysrKysrKysrKysrCQkJCSsrKysrKysrKysrKysrKysr KysNCg0KICBGaWd1cmUgMy4gQ29udHJvbCBwbGFuZSBhbmQgdXNlciBwbGFuZSBpbiBhIHVzZXIg bXVsdGlwbGV4aW5nIHNjZW5hcmlvDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoNCg0KSW50ZXJuZXQg RHJhZnQgCQkJCQkJCQlBdWcgMTUsIDE5OTgNCg0NCg0KMy4xIENJRCBzZWxlY3Rpb24gDQoNCiAg IElycmVzcGVjdGl2ZSBvZiB0aGUgY2hvaWNlIG9mIHRoZSBzaWduYWxpbmcgbWVjaGFuaXNtIGJl dHdlZW4gdGhlIE1VWA0KICAgY29udHJvbGxlcnMsIHRoZSBDSUQgc2VsZWN0aW9uIHByb2NlZHVy ZSBhdCBlYWNoIG9mIHRoZSBNVVgNCiAgIGNvbnRyb2xsZXJzIE1VU1QgYmUgZG9uZSBhcyBmb2xs b3dzOg0KDQogICAgIDEpIEFycml2YWwgb2YgYSBuZXcgY2FsbCBmcm9tIGEgUFNUTi9HU00gdXNl ciB0cmlnZ2VycyBhIENJRCANCiAgICAgICAgYXNzaWdubWVudCBzZXF1ZW5jZSBhdCB0aGUgTVVY IGNvbnRyb2xsZXIgb2YgdGhlIGxvY2FsIGdhdGV3YXkuIA0KICAgICAgICBBZnRlciBlc3RhYmxp c2hpbmcgd2hpY2ggcmVtb3RlIGdhdGV3YXkgY2FuIGhhbmRsZSB0aGUgY2FsbCwgDQogICAgICAg IHRoZSBsb2NhbCBNVVggY29udHJvbGxlciBjaGVja3MgZm9yIHRoZSBleGlzdGVuY2Ugb2YgYW4g DQogICAgICAgIFJUUC9VRFAvSVAgY29ubmVjdGlvbiB0byB0aGUgcmVtb3RlIE1VWCBjb250cm9s bGVyLiBJZiB0aGVyZSANCiAgICAgICAgZXhpc3RzIGEgVURQIGNvbm5lY3Rpb24gd2l0aCBmcmVl IENJRHMsIHRoZW4gYSBDSUQgaXMgY2hvc2VuIGFuZA0KICAgICAgICByZXNlcnZlZCBmb3IgdGhh dCBjYWxsLiBJZiB0aGVyZSBpcyBubyBVRFAgY29ubmVjdGlvbiBiZXR3ZWVuIA0KICAgICAgICB0 aGUgZ2F0ZXdheXMgb3IgaWYgYWxsIHRoZSBleGlzdGluZyBjb25uZWN0aW9ucyBhcmUgZnVsbCAo aS5lLiwgDQogICAgICAgIG5vIGZyZWUgQ0lEKSwgdGhlbiBhIG5ldyBSVFAvVURQL0lQIGNvbm5l Y3Rpb24gaXMgZXN0YWJsaXNoZWQuIA0KICAgICAgICBPbmNlIHRoZSBDSUQgc2VsZWN0aW9uIGlz IGRvbmUsIGEgbm90aWZpY2F0aW9uIG1lc3NhZ2UgdGhhdCANCiAgICAgICAgY29uc2lzdHMgb2Yg Q0lELCBjYWxsaW5nIHVzZXIgSUQsIGNhbGxlZCB1c2VyIElELCBsb2NhbCBhbmQgDQogICAgICAg IHJlbW90ZSBVRFAgcG9ydCBudW1iZXJzIGlzIHRyYW5zbWl0dGVkLiBTdWNoIHRyYW5zbWlzc2lv biBtYXkNCiAgICAgICAgb2NjdXIgZWl0aGVyIGluIHRoZSBpbml0aWFsIG5vdGlmaWNhdGlvbiBt ZXNzYWdlIChkdXJpbmcgY2FsbA0KICAgICAgICBzZXR1cCkgb3IgaW4gdGhlIG5vdGlmaWNhdGlv biBtZXNzYWdlIGZvciBjYXBhYmlsaXR5IGV4Y2hhbmdlDQogICAgICAgIHRoYXQgb2NjdXJzIGFm dGVyIGNhbGwgc2V0dXAuDQoNCiAgICAgMikgVXBvbiByZWNlaXZpbmcgdGhlIG1lc3NhZ2UgY29u dGFpbmluZyB0aGUgQ0lELCB0aGUgTVVYIGNvbnRyb2wtDQogICAgICAgIGxlciBhdCB0aGUgcmVt b3RlIGdhdGV3YXkgY2hlY2tzIGl0cyBDSUQgdGFibGUgYXNzb2NpYXRlZCB3aXRoDQogICAgICAg IHRoZSBVRFAgY29ubmVjdGlvbi4gVGhlIHN0YXR1cyBvZiBDSURzIGlzIG1haW50YWluZWQgaW4g YSBDSUQNCiAgICAgICAgdGFibGUsIHdoaWNoIGlzIGFzc29jaWF0ZWQgd2l0aCBlYWNoIFVEUCBj b25uZWN0aW9uIGJldHdlZW4gYW55DQogICAgICAgIHR3byBnYXRld2F5cy4gSWYgdGhlIENJRCBp bmRpY2F0ZWQgaW4gdGhlIG5vdGlmaWNhdGlvbiBtZXNzYWdlIA0KICAgICAgICBoYXMgbm90IGFs cmVhZHkgYmVlbiBhc3NpZ25lZCwgdGhlbiB0aGUgcmVtb3RlIE1VWCBjb250cm9sbGVyDQogICAg ICAgIG1ha2VzIGFuIGVudHJ5IGluIGl0cyBDSUQgdGFibGUgYXNzaWduaW5nIHRoZSBDSUQgdG8g YSBjYWxsIA0KICAgICAgICBiZXR3ZWVuIHRoZSBwYWlyIG9mIFVEUCBwb3J0cyBhcyBpbmRpY2F0 ZWQgaW4gdGhlIG5vdGlmaWNhdGlvbg0KICAgICAgICBtZXNzYWdlLiBJZiB0aGUgVURQIHBvcnQg YXQgdGhlIHJlbW90ZSBnYXRld2F5IGlzIG5vdCBhbHJlYWR5IA0KICAgICAgICBvcGVuLCB0aGVu IHRoZSBNVVggY29udHJvbGxlciBvcGVucyB0aGUgVURQIHBvcnQuIFRhYmxlIDEgc2hvd3MgDQog ICAgICAgIGEgc2FtcGxlIENJRCB0YWJsZSB1c2VkIGF0IGEgZ2F0ZXdheSBmb3IgYSBzaW5nbGUg VURQIGNvbm5lLQ0KICAgICAgICBjdGlvbi4NCg0KCQktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgkJfCBDSUQgfENJRCBzdGF0dXMJ fCAJTG9jYWwgVUlEIAl8UmVtb3RlIFVJRCB8DQoJCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCQl8ICAgNQl8IEFzc2lnbmVkCXwJ NjE3MjMwMDAwMCAJfDkxMjczNjM3MzYgfA0KCQl8CXwJCXwJCQl8CSAgICB8DQoJCXwgIDEwCXwg UmVzZXJ2ZWQgIAl8CTYxNzU0NjQ2MzYJfDgyNjM3Mzc0NzQgfA0KCQl8CXwJCXwJCQl8CSAgICB8 DQoJCXwgIDIwCXwgSWRsZQkJfAkJCXwJICAgIHwNCgkJfAl8CQl8CQkJfAkgICAgfA0KCQl8IDIw MAl8IElkbGUJCXwJCQl8CSAgICB8DQogCQktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KCQlUYWJsZSAxLiBDSUQgdGFibGUgZm9y IGEgc2luZ2xlIFVEUCBjb25uZWN0aW9uDQoNCg0KMy4yIENJRCBjb2xsaXNpb24NCg0KICAgRHVy aW5nIHRoZSBDSUQgbmVnb3RpYXRpb24gcHJvY2VkdXJlcywgdGhlcmUgaXMgYSBwb3NzaWJpbGl0 eSB0aGF0IA0KICAgdGhlIHNhbWUgQ0lEIGlzIHNlbGVjdGVkIGJ5IGJvdGggZW5kcyBmb3IgdGhl aXIgb3duIGNhbGwgcmVxdWVzdHMuIA0KICAgQm90aCBnYXRld2F5cyB0cmFuc21pdCBjaGFubmVs IHJlcXVlc3QgbWVzc2FnZXMgd2l0aCB0aGUgc2FtZSBDSUQgDQogICB3aXRob3V0IHRoZSBrbm93 bGVkZ2Ugb2YgdGhlIG90aGVyIGdhdGV3YXkuIEFmdGVyIHJlY2VpdmluZyB0aGUgDQogICByZXF1 ZXN0LCBib3RoIHNpZGVzIGFyZSB1bmFibGUgdG8gYWxsb2NhdGUgdGhlIENJRCBzaW5jZSBpdCBo YXMgYmVlbg0KDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoNCg0KSW50ZXJuZXQgRHJhZnQgCQkJCQkJ CQlBdWcgMTUsIDE5OTgNCg0KDQoNCiAgIHJlc2VydmVkIGZvciB0aGVpciBsb2NhbCBjYWxsIHJl cXVlc3QuIFRoaXMgcHJvYmxlbSBpcyBvdGhlcndpc2UgDQogICBrbm93biBhcyBDSUQgZ2xhcmUu IFdlIHByb3Bvc2UgdG8gdXNlIGEgbWV0aG9kIHRoYXQgaXMgZmFpciB0byBib3RoIA0KICAgZW5k cyBpbiBDSUQgYXNzaWdubWVudCBwcm9jZWR1cmVzLiBJbiB0aGlzIG1ldGhvZCwgb25lIHNpZGUg aXMgDQogICBhc3NpZ25lZCB0byBhbGxvY2F0ZSBDSURzIGZyb20gdGhlIHRvcCBvZiB0aGUgQ0lE IHRhYmxlIGFuZCB0aGUgDQogICBvcHBvc2l0ZSBzaWRlIGZyb20gYm90dG9tLiBIb3dldmVyLCBD SUQgY29sbGlzaW9uIG9jY3VycyB3aGVuIGEgDQogICBzaW5nbGUgQ0lEIGlzIGF2YWlsYWJsZSBh dCBib3RoIGVuZHMuIEV2ZW4gaW4gc3VjaCBhIGNhc2UsIGZhaXJuZXNzIA0KICAgY2FuIGJlIGFj aGlldmVkIGJ5IGFuIGFzc2lnbm1lbnQgYmFzZWQgb24gdGhlIGV2ZW4gYW5kIG9kZCB2YWx1ZSBv Zg0KICAgQ0lELiBUaGUgYXJiaXRyYXRpb24gb2Ygd2hpY2ggc2lkZSBzdGFydHMgZnJvbSB0b3Ag Y2FuIGJlIHJlc29sdmVkIA0KICAgdXNpbmcgSVAgYWRkcmVzcyBvZiB0aGUgZ2F0ZXdheXMuIEZv ciBleGFtcGxlLCB0aGUgZ2F0ZXdheSB3aXRoIHRoZSANCiAgIGhpZ2hlciBJUCBhZGRyZXNzIHN0 YXJ0cyBmcm9tIHRoZSB0b3AgYW5kIHRoZSBvdGhlciBnYXRld2F5IHN0YXJ0cyANCiAgIGZyb20g dGhlIGJvdHRvbS4gDQoNCjMuMyBDaGFubmVsIE5lZ290aWF0aW9uIFByb2NlZHVyZXMgKENOUCkN Cg0KICAgQ05QIGlzIGEgbmV3IGNvbnRyb2wgc2lnbmFsaW5nIHNwZWNpZmljYWxseSBwcm9wb3Nl ZCBmb3IgdGhlIHVzZXIgDQogICBtdWx0aXBsZXhpbmcgYXBwbGljYXRpb24gYmV0d2VlbiBJUCB0 ZWxlcGhvbnkgZ2F0ZXdheXMgdGhhdCANCiAgIGludGVyY29ubmVjdCBQU1ROL0dTTSBjbG91ZHMu IFRoZSBmdW5jdGlvbiBvZiBDTlAgaXMgdG8gbmVnb3RpYXRlIGEgDQogICBDSUQgZm9yIGEgY2Fs bCB0aHJvdWdoIGEgc2V0IG9mIG1lc3NhZ2VzIHNpbWlsYXIgdG8gc3RhbmRhcmQgc2lnbmFsLQ0K ICAgaW5nIHByb3RvY29scy4gU2luY2UgQ05QIGlzIHRhcmdldGVkIGZvciBhIHNwZWNpZmljIGFw cGxpY2F0aW9uLCB3ZSANCiAgIGRvIG5vdCBhbnRpY2lwYXRlIHRoZSBuZWVkIGZvciBjb21wbGV4 IHNpZ25hbGluZyBwcm9jZWR1cmVzIHNpbWlsYXIgDQogICB0byBILjIyNS9ILjI0NSBbNSw2XS4g SG93ZXZlciwgSC4yMjUvSC4yNDUgY291bGQgYmUgYWRhcHRlZCB0byBzdWl0DQogICB0aGUgcmVx dWlyZW1lbnRzIG9mIHRoZSB1c2VyIG11bHRpcGxleGluZyBpbiBSVFAgbWV0aG9kLiBDTlAgY29u c2lzdHMNCiAgIG9mIGEgc2V0IG9mIG1lc3NhZ2VzIHRoYXQgaW5jbHVkZSBhc3NpZ24sIGFzc2ln bl9jb25maXJtLCByZWxlYXNlLCANCiAgIHJlbGVhc2VfY29uZmlybSBhbmQgcmVqZWN0LiBBbiBh ZGRpdGlvbmFsIG1lc3NhZ2UgIm1lc3NhZ2VzX3RyYW5zZmVyIg0KICAgaXMgYWxzbyBwcm9wb3Nl ZCBpbiBjYXNlIHRoZXJlIGlzIGEgbmVlZCB0byB0cmFuc21pdCBjb250cm9sIG1lc3NhZ2VzDQog ICBvZiBhIHBhcnRpY3VsYXIgdXNlciAoY2FsbCBjb250cm9sIG1lc3NhZ2VzKSBkdXJpbmcgdGhl IGFjdGl2ZSANCiAgIHNlc3Npb24gb2YgYSBjYWxsLiBBIGRldGFpbGVkIHN0dWR5IG9uIHRoZSBm b3JtYXQgb2YgdGhlIENOUCBtZXNzYWdlcw0KICAgYW5kIHRoZWlyIHBhcmFtZXRlcnMgd2lsbCBi ZSByZXBvcnRlZCBsYXRlci4NCg0KICAgVGhlIGZvbGxvd2luZyBpcyB0aGUgc2VxdWVuY2Ugb2Yg ZXZlbnRzIHRoYXQgb2NjdXIgaW4gYSBjaGFubmVsIA0KICAgbmVnb3RpYXRpb24gcGhhc2U6DQoN CiAgICAgLSBBc3NpZ246IFVwb24gYXJyaXZhbCBvZiBhIG5ldyBjYWxsIGZyb20gYSBQU1ROL0dT TSB1c2VyLCBhIENJRCBpcw0KICAgICAgIGFzc2lnbmVkIGJhc2VkIG9uIHRoZSBwcm9jZWR1cmUg ZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cyBzZWN0LQ0KICAgICAgIGlvbi4gQW4gImFzc2lnbiIg bWVzc2FnZSBpcyB0aGVuIHRyYW5zbWl0dGVkIHRvIHRoZSByZW1vdGUgZ2F0ZS0gDQogICAgICAg d2F5IGNvbnRhaW5pbmcgdGhlIGxvY2FsIFVEUCBwb3J0IG51bWJlciwgcmVtb3RlIFVEUCBwb3J0 IG51bWJlciwgDQogICAgICAgQ0lEIG51bWJlciwgY2FsbGluZyBhbmQgY2FsbGVkIHVzZXIsIGFu ZCBhbiBVVUkgZmllbGQgdG8gY2FycnkgDQogICAgICAgYW55IGNhbGwgY29udHJvbCBzaWduYWxp bmcgKFBTVE4gYW5kIFNTNykuIA0KDQogICAgIC0gQXNzaWduX2NvbmZpcm0gb3IgcmVqZWN0OiBU aGUgcmVtb3RlIHBlZXIgcmVjb3ZlcnMgdGhlIGluZm9ybWF0LQ0KICAgICAgIGlvbiB3aXRoaW4g dGhlICJhc3NpZ24iIG1lc3NhZ2UgYW5kIGRvZXMgbG9jYWwgcHJvY2Vzc2luZyBhcw0KICAgICAg IGRlc2NyaWJlZCBpbiB0aGUgcHJldmlvdXMgc2VjdGlvbi4gSWYgdGhlIGNhbGwgY2FuIGJlIGFj Y2VwdGVkDQogICAgICAgdGhlbiB0aGUgbG9jYWwgTXV4IGNvbnRyb2xsZXIgdXBkYXRlcyBpdHMg bG9jYWwgQ0lEIHRhYmxlIGFuZA0KICAgICAgIHJlcGxpZXMgd2l0aCBhbiAiYXNzaWduX2NvbmZp cm0iIG1lc3NhZ2UuIElmIHRoZSByZW1vdGUgZ2F0ZXdheQ0KICAgICAgIGV4cGVyaWVuY2VzIGEg cHJvYmxlbSBpbiBhbGxvY2F0aW5nIHRoZSBjb25uZWN0aW9uLCBzYXkgZHVlIHRvIA0KICAgICAg IENJRCBjb2xsaXNpb24sIHRoZW4gaXQgdHJhbnNtaXRzIGEgInJlamVjdCIgbWVzc2FnZS4gVXBv biByZWNlaS0NCiAgICAgICB2aW5nIHRoZSAiYXNzaWduX2NvbmZpcm0iIG1lc3NhZ2UsIHRoZSBs b2NhbCBNdXggY29udHJvbGxlcg0KICAgICAgIGNvbmZpcm1zIHRoZSBDSUQgYXNzaWdubWVudCBi eSB1cGRhdGluZyB0aGUgQ0lEIHRhYmxlIGFuZCBub3RpLQ0KICAgICAgIGZ5aW5nIHRoZSBsb2Nh bCB1c2VyLiANCg0KDQpCLiBTdWJiaWFoLCBTLiBTZW5nb2RhbiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAg ICAgICAgIAkJICAgICAgICAgICAgICAgQXVnIDE1LCAxOTk4DQoNCg0KDQoNCgkJKysrKysrKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAJKysrKysrKyAgICAgICAgDQoJCSsgICAgICsgICAg ICAgICBBc3NpZ24gICAgICAgICAgCSsgICAgICsNCgkJKyAgICAgKyAgICAgLS0tLS0tLS0tLS0t LS0tLT4gICAgCSsgICAgICsNCgkJKyBHVzEgKyAgICAgIEFzc2lnbl9jb25maXJtCQkrIEdXMiAr DQoJCSsgICAgICsgICAgPC0tLS0tLS0tLS0tLS0tLS0tLQkgICAgICAgICsgICAgICsNCgkJKyAg ICAgKyAJCQkJKyAgICAgKw0KCQkrKysrKysrICAgCQkJCSsrKysrKysNCgkJCSAgDQoJCQkgRmln dXJlIDQ6IENOUCBDb25maXJtIHNlcXVlbmNlDQoNCg0KCQkrKysrKysrICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAkrKysrKysrICAgICAgICANCgkJKyAgICAgKyAgICAgICAgIEFzc2lnbiAg ICAgICAgICAJKyAgICAgKw0KCQkrICAgICArICAgICAtLS0tLS0tLS0tLS0tLS0tPiAgICAJKyAg ICAgKw0KCQkrIEdXMSArICAgICAgICAgUmVqZWN0CQkJKyBHVzIgKw0KCQkrICAgICArICAgIDwt LS0tLS0tLS0tLS0tLS0tLS0JICAgICAgICArICAgICArDQoJCSsgICAgICsgCQkJCSsgICAgICsN CgkJKysrKysrKyAgIAkJCQkrKysrKysrDQoJCQkgIA0KCQkJIEZpZ3VyZSA1OiBDTlAgUmVqZWN0 IHNlcXVlbmNlDQoNCg0KMy40IFVzZSBvZiBILjIyNS9ILjI0NSBmb3IgY2hhbm5lbCBuZWdvdGlh dGlvbg0KDQoJICAgIAkJCQkJCQkgDQoJCQkrKysrKysrKysJCSAgICArKysrKysrKysrKw0KCSsr KysrKysrKwkrCSstLS0tLS0gSC4yMjUgLS0tLS0tKwkgICAgICArICAgICArKysrKysrKw0KCSsJ KwkrIAkrLS0tLS0tIEguMjQ1IC0tLS0tLSsJICAgICAgKwkgICAgKwkgICArCQ0KCSsgUFNUTiAg KysrKysJKyAgICAJKwkgICAgICAJICAgICsJICAgICAgKysrKysrKyBQU1ROICsNCgkrKysrKysr KysJKyBJUCBHVyArLS0tICBJUCBORVRXT1JLIC0tLSsgSVAgR1cgICArCSAgICArKysrKysrKw0K CQkJKwkrICAgIAkgCSAgICArCSAgICAgICsNCgkJCSsgCSstLSBVRFAgY2hhbm5lbCAxIC0tKwkg ICAgICArDQoJKysrKysrKysrCSsJKy0tIFVEUCBjaGFubmVsIG4gLS0rCSAgICAgICsJICAgICsr KysrKysrKw0KCSsJKyArKysrCSsrKysrKysrKwkJICAgICArKysrKysrKysrKysrKysrICAgICAg ICsNCgkrIEdTTQkrCQkJCQkJICAgICsgR1NNICAgKw0KCSsrKysrKysrKwkJCQkJCSAgICArKysr KysrKysNCg0KCQlGaWd1cmUgNjogSC4yMjUvSC4yNDUgaW4gYW4gSVAgdGVsZXBob255IGdhdGV3 YXkgDQoNCg0KICAgSVRVLVQgaGFzIHN0YW5kYXJkaXplZCBILjIyNVs1XSBhbmQgSC4yNDVbNl0g YXMgdGhlIGNhbGwgc2lnbmFsaW5nIA0KICAgcHJvdG9jb2wgYW5kIGNhbGwgY29udHJvbCBwcm90 b2NvbCByZXNwZWN0aXZlbHkgdG8gYmUgdXNlZCB3aXRoaW4gDQogICB0aGUgSVRVLVQgc3RhbmRh cmQgSC4zMjNbN10uIEguMjI1IGFuZCBILjI0NSBtYXkgYmUgdXNlZCBmb3IgDQogICBzaWduYWxp bmcgYW5kIGNvbnRyb2wgcHVycG9zZXMgYmV0d2VlbiB0aGUgZ2F0ZXdheXMuIFdoZW4gdGhpcyBp cyB0aGUNCiAgIGNhc2UsIHBlcnNpc3RlbnQgSC4yMjUgYW5kIEguMjQ1IGNvbm5lY3Rpb25zIGV4 aXN0IGJldHdlZW4gYSBwYWlyIG9mDQogICBnYXRld2F5cy4gQWxsIHZvaWNlIGNvbm5lY3Rpb25z IGJldHdlZW4gdGhlIHR3byBnYXRld2F5cyBzaG91bGQgdXNlIA0KICAgdGhlIHNhbWUgSC4yMjUg YW5kIEguMjQ1IGNvbm5lY3Rpb24gZm9yIGNhbGwgc2lnbmFsaW5nIGFuZCBjYWxsIA0KICAgY29u dHJvbCBwdXJwb3Nlcy4NCg0KDQoNCkIuIFN1YmJpYWgsIFMuIFNlbmdvZGFuICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCVtQYWdlIDhdDQoNCg0KSW50ZXJuZXQgRHJhZnQgCQkJ CQkJCSAgQXVnIDE1LCAxOTk4DQoNDQoNCiAgIFdoZW4gYSBuZXcgY2FsbCBhcnJpdmVzIGF0IGEg Z2F0ZXdheSBmcm9tIHRoZSBjaXJjdWl0IHN3aXRjaGVkIHNpZGUgDQogICAoUFNUTi9HU00pLCBh IFNFVFVQIG1lc3NhZ2UgaXMgdHJhbnNtaXR0ZWQgZnJvbSB0aGUgaW5pdGlhdGluZyANCiAgIGdh dGV3YXkgdG8gdGhlIHRlcm1pbmF0aW5nIGdhdGV3YXkgb24gdGhlIHBlcnNpc3RlbnQgVENQIGNh bGwtc2lnbmEtDQogICBsaW5nIGNoYW5uZWwgKEguMjI1IGNoYW5uZWwpLiBUaGUgVXNlci1Vc2Vy LUluZm9ybWF0aW9uLUVsZW1lbnQgDQogICAoVVVJRSkgb2YgdGhlIFNFVFVQIG1lc3NhZ2UgaW5j bHVkZXMgdGhlIHBhcmFtZXRlcnMgdGhhdCBhcmUgbmVlZGVkDQogICBmb3IgY29ubmVjdGlvbiBz ZXR1cCBhcyBpbmRpY2F0ZWQgaW4gdGhlIEguMjI1IGRvY3VtZW50IFs5XS4gDQoNCiAgIEZvciB0 aGUgcHVycG9zZSBvZiB1c2VyIG11bHRpcGxleGluZyBiZXR3ZWVuIGdhdGV3YXlzLCB0aGUgc2V0 dGluZyBvZg0KICAgdGhlIFVVSUUgZmllbGRzIGluIHRoZSBTRVRVUCBtZXNzYWdlIE1VU1QgYmUg YXMgZm9sbG93czoNCg0KICAgICAtIGgyNDVBZGRyZXNzOiBUaGlzIGZpZWxkIGlzIHNldCB0byB0 aGUgVFNBUCBhZGRyZXNzIG9mIHRoZSBjYWxsIA0KICAgICAgIGNvbnRyb2wgVENQIGNoYW5uZWwg KEguMjQ1IGNoYW5uZWwpIGF0IHRoZSBpbml0aWF0aW5nIGdhdGV3YXkgDQogICAgICAgdGhhdCB3 aWxsIGJlIHVzZWQgZm9yIGNhbGwgY29udHJvbCBwdXJwb3NlcyBvZiB0aGlzIHZvaWNlIHN0cmVh bS4NCiAgICAgICBJbml0aWF0aW5nIGdhdGV3YXlzIHNob3VsZCB1c2UgdGhlIHNhbWUgY2FsbCBj b250cm9sIGNoYW5uZWwgZm9yIA0KICAgICAgIGFsbCB2b2ljZSBzdHJlYW1zLiBIb3dldmVyLCB0 aGUgaW5pdGlhdGluZyBnYXRld2F5IG1heSB3aXNoIHRvIA0KICAgICAgIG9wZW4gYSBuZXcgY2Fs bCBjb250cm9sIGNoYW5uZWwgd2hlbiB0aGUgbnVtYmVyIG9mIHZvaWNlIHN0cmVhbXMNCiAgICAg ICB1c2luZyB0aGUgc2FtZSBjb250cm9sIGNoYW5uZWwgZXhjZWVkcyBhIGNlcnRhaW4gdGhyZXNo b2xkIHZhbHVlLg0KICAgICAgIFdoZW4gdGhlIGluaXRpYXRpbmcgZ2F0ZXdheSB3aXNoZXMgdG8g dXNlIGEgbmV3IGNhbGwgY29udHJvbCANCiAgICAgICBjaGFubmVsLCB0aGUgVFNBUCBhZGRyZXNz IG9mIHRoZSBuZXcgSC4yNDUgY2hhbm5lbCBpcyBpbmNsdWRlZCANCiAgICAgICBpbiB0aGlzIGZp ZWxkLg0KDQogICBJZiB0aGUgcmVtb3RlIGdhdGV3YXkgcmVzcG9uZHMgd2l0aCBhIENPTk5FQ1Qg bWVzc2FnZSB1cG9uIHJlY2VpdmluZw0KICAgdGhlIFNFVFVQIG1lc3NhZ2UsIHRoZSBVVUlFIGZp ZWxkcyB3aXRoaW4gdGhlIENPTk5FQ1QgbWVzc2FnZSBNVVNUDQogICBiZSBzZXQgYXMgZm9sbG93 czoNCg0KICAgICAtIGgyNDVBZGRyZXNzOiBUaGlzIGZpZWxkIGlzIHNldCB0byB0aGUgVFNBUCBh ZGRyZXNzIG9mIHRoZSBjYWxsIA0KICAgICAgIGNvbnRyb2wgVENQIGNoYW5uZWwgKEguMjQ1IGNo YW5uZWwpIGF0IHRoZSByZXNwb25kaW5nIGdhdGV3YXkgDQogICAgICAgdGhhdCB3aWxsIGJlIHVz ZWQgZm9yIGNhbGwgY29udHJvbCBwdXJwb3NlcyBvZiB0aGlzIHZvaWNlIHN0cmVhbS4NCiAgICAg ICBSZW1vdGUgZ2F0ZXdheXMgc2hvdWxkIHVzZSB0aGUgc2FtZSBjYWxsIGNvbnRyb2wgY2hhbm5l bCBmb3IgYWxsIA0KICAgICAgIHZvaWNlIHN0cmVhbXMgd2hlbiBhbiBpbml0aWF0aW5nIGdhdGV3 YXkgaGFzIHVzZWQgdGhlIHNhbWUNCiAgICAgICBleGlzdGluZyBjYWxsIGNvbnRyb2wgY2hhbm5l bC4gSWYgYSByZW1vdGUgZ2F0ZXdheSB3aXNoZXMgdG8gdXNlIA0KICAgICAgIGEgbmV3IGNhbGwg Y29udHJvbCBjaGFubmVsIHdoZW4gdGhlIGluaXRpYXRpbmcgZ2F0ZXdheSBoYXMgDQogICAgICAg aW5kaWNhdGVkIHRoZSB1c2Ugb2YgYW4gZXhpc3RpbmcgY2FsbCBjb250cm9sIGNoYW5uZWwgaW4g dGhlIA0KICAgICAgIFNFVFVQIG1lc3NhZ2UsIHRoZW4gdGhlIHJlbW90ZSBnYXRld2F5IG11c3Qg c2VuZCBhIEZBQ0lMSVRZIGFuZCANCiAgICAgICBhIFJFTEVBU0UgbWVzc2FnZS4gSG93ZXZlciwg aWYgYW4gaW5pdGlhdGluZyBnYXRld2F5IGhhcyBpbmRpYy0NCiAgICAgICBhdGVkIHRoZSB1c2Ug b2YgYSBuZXcgY2FsbCBjb250cm9sIGNoYW5uZWwsIHRoZW4gdGhlIHJlbW90ZQ0KICAgICAgIGdh dGV3YXkgbXVzdCB1c2UgYSBuZXcgY2FsbCBjb250cm9sIGNoYW5uZWwuIFRoZSBUU0FQIGFkZHJl c3Mgb2YNCiAgICAgICB0aGUgbmV3IGNhbGwgY29udHJvbCBUQ1AgY2hhbm5lbCBhdCB0aGUgcmVt b3RlIGdhdGV3YXkgaXMNCiAgICAgICBpbmNsdWRlZCBpbiB0aGlzIGZpZWxkLg0KDQogICBVcG9u IHJlY2VpdmluZyB0aGUgQ09OTkVDVCBtZXNzYWdlIGZyb20gdGhlIHJlbW90ZSBnYXRld2F5LCB0 aGUgY2FsbCANCiAgIGNvbnRyb2wgcGhhc2UgKEguMjQ1KSBiZWdpbnMuIFRoZSBjYXBhYmlsaXR5 IGV4Y2hhbmdlIG1lc3NhZ2VzIA0KICAgZGV0ZXJtaW5lIHRoZSBjaG9pY2Ugb2YgY29kZWNzIGFu ZCB0aGUgc2VjdXJpdHkgcGFyYW1ldGVycyBpZiBhbnkgdG8NCiAgIGJlIHVzZWQgYmV0d2VlbiB0 aGUgZ2F0ZXdheXMuIEluIGFkZGl0aW9uLCB0aGUgY2FwYWJpbGl0eSBleGNoYW5nZQ0KICAgYWxz byBpbmRpY2F0ZXMgdGhlIGNhcGFiaWxpdHkgZm9yIHBlcmZvcm1pbmcgbXVsdGlwbGV4aW5nLiBJ biB0aGUgDQogICBvcGVuTG9naWNhbENoYW5uZWwgKGFuZCBvcGVuTG9naWNhbENoYW5uZWxBY2sp IG1lc3NhZ2UsIGluIGFkZGl0aW9uDQogICB0byBpbmRpY2F0aW5nIHRoZSBUU0FQIGFkZHJlc3Ms IHRoZSBDSUQgaXMgYWxzbyBpbmRpY2F0ZWQuDQogICANCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29k YW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDldDQoNCg0KSW50 ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAJCSAgICAgICAgICAgICAgIEF1ZyAxNSwgMTk5 OA0KDQoNCg0KCQkrKysrKysrICAgICAgICAgICAgICAgICAgICAgICAgICAgIAkrKysrKysrICAg ICAgICANCgkJKyAgICAgKyAgICAgICAgIFNFVFVQICAgICAgICAgIAkJKyAgICAgKw0KCQkrICAg ICArICAgICAtLS0tLS0tLS0tLS0tLS0tPiAgICAJKyAgICAgKw0KCQkrIEdXMSArICAgICAgICAg Q09OTkVDVAkJCSsgR1cyICsNCgkJKyAgICAgKyAgICA8LS0tLS0tLS0tLS0tLS0tLS0tCQkrICAg ICArDQoJCSsgICAgICsgCSAgQ2FwYWJpbGl0eVNldAkJKyAgICAgKyANCgkJKyAgICAgKyAgICAt LS0tLS0tLS0tLS0tLS0tLS0+CQkrICAgICArDQoJCSsgICAgICsJIENhcGFiaWxpdHlTZXRBY2sJ CSsgICAgICsNCgkJKyAgICAgKyAgICA8LS0tLS0tLS0tLS0tLS0tLS0tCQkrICAgICArDQoJCSsg ICAgICsJCU9MQwkJCSsgICAgICsNCgkJKyAgICAgKwkgICAtLS0tLS0tLS0tLS0tLS0tLS0+CQkr ICAgICArDQoJCSsgICAgICsJCU9MQ0FjawkJCSsgICAgICsNCgkJKyAgICAgKwkgICA8LS0tLS0t LS0tLS0tLS0tLS0tCQkrICAgICArDQoJCSsrKysrKysJCQkJCSsrKysrKysNCg0KCQkJIEZpZ3Vy ZSA3OiBILjIyNS9ILjI0NSBleGNoYW5nZSBzZXF1ZW5jZQ0KDQoNCg0KCQkrKysrKysrICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAkrKysrKysrICAgICAgICANCgkJKyAgICAgKyAgICAgICAg IFNFVFVQICAgICAgICAgIAkJKyAgICAgKw0KCQkrICAgICArICAgICAtLS0tLS0tLS0tLS0tLS0t PiAgICAJKyAgICAgKw0KCQkrIEdXMSArICAgICAgICAgRkFDSUxJVFkJCSsgR1cyICsNCgkJKyAg ICAgKwkgICAgPC0tLS0tLS0tLS0tLS0tLS0tLQkJKyAgICAgKw0KCQkrICAgICArIAkJUkVMRUFT RQkJKyAgICAgKw0KCQkrICAgICArCSAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLQkrICAgICArDQoJ CSsrKysrKysgICAJCQkJKysrKysrKw0KCQkJICANCgkJCSBGaWd1cmUgODogSC4yMjUgRmFjaWxp dHkvUmVqZWN0IHNlcXVlbmNlDQoNCg0KDQoNCkIuIFN1YmJpYWgsIFMuIFNlbmdvZGFuICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMF0NCg0KDQpJbnRlcm5ldCBE cmFmdCAJCQkJCQkJICAgIEF1ZyAxNSwgMTk5OA0KDQoNCg0KDQozLjUgVXNlIG9mIFNJUCBmb3Ig Y2hhbm5lbCBuZWdvdGlhdGlvbg0KDQoNCgkrKysrKysrKysrKwkJCSAgICAgIAkJKysrKysrKysr KysrKysrKysNCgkrCSAgICArIC0tLSBwZXJzaXN0ZW50IFNJUCBjaGFubmVsIC0tIAkrCQkrDQoJ KyAJICAgICsJCQkJCSsJICAgICAJKwkNCgkrCSAgICArICAgIAkgCSAgICAgIAkJKwkgICAgIAkr DQoJKyBJUCBHVzEgICAgKwkJCQkJKyAgSVAgR1cyICAJKw0KCSsJICAgICsgICAgCSAJICAgICAg CQkrCSAgICAgCSsNCgkrIAkgICAgKyAgLS0tIGF1ZGlvIFVEUCBjaGFubmVsIDEgLS0tCSsgCSAg ICAgCSsNCgkrCSAgICArICAtLS0gYXVkaW8gVURQIGNoYW5uZWwgbiAtLS0JKwkgICAgIAkrDQoJ KysrKysrKysrKysJCQkgICAgICAJCSsrKysrKysrKysrKysrKysrDQoJCQkNCgkJRmlndXJlIDku IFNJUCBpbiBJUCB0ZWxlcGhvbnkgZ2F0ZXdheXMNCg0KDQoNDQoNCg0KICAgU2Vzc2lvbiBJbml0 aWF0aW9uIFByb3RvY29sIChTSVApIGNhbiBiZSB1c2VkIGFzIHRoZSBjb250cm9sIA0KICAgc2ln bmFsaW5nIHByb3RvY29sIGJldHdlZW4gdGhlIHR3byBnYXRld2F5cyBbMTFdLiBJbiB0aGlzIGNh c2UsIA0KICAgdGhlIGdhdGV3YXkgdGhhdCByZWNlaXZlcyBhIGNhbGwgZnJvbSB0aGUgY2lyY3Vp dCBzd2l0Y2hlZCBzaWRlIA0KICAgaXMgdGhlIFNJUCBjbGllbnQsIHdoaWxlIHRoZSByZW1vdGUg Z2F0ZXdheSBpcyB0aGUgU0lQIHNlcnZlci4gDQogICBUaGUgc2VyaWVzIG9mIG1lc3NhZ2VzIHRo YXQgYXJlIGV4Y2hhbmdlZCBhcmUgZGVzY3JpYmVkIGJlbG93LiANCiAgIFRoZXNlIG1lc3NhZ2Vz IGFyZSBleGNoYW5nZWQgb24gdGhlIHBlcnNpc3RlbnQgc2lnbmFsaW5nIGNvbm5lY3Rpb24gDQog ICBleGlzdGluZyBiZXR3ZWVuIHRoZSB0d28gZ2F0ZXdheXMuIFN1Y2ggYSBwZXJzaXN0ZW50IGNv bm5lY3Rpb24gDQogICBtYXkgZWl0aGVyIGJlIFRDUCBvciBVRFAuDQoNCiAgIEFzIHdpdGggdGhl IGNhc2Ugb2YgSC4yMjUsIHRoZSBkZXNjcmlwdGlvbiBoZXJlIGlzIG5vdCBtZWFudCB0byBiZSAN CiAgIGV4aGF1c3RpdmUgYnV0IGlzIG1lcmVseSBmb3IgaWxsdXN0cmF0aW9uLiBJc3N1ZXMgc3Vj aCBhcyBsb2NhdGluZyANCiAgIHRoZSByZW1vdGUgZ2F0ZXdheSBieSB0aGUgdXNlIG9mIHByb3h5 IG9yIHJlZGlyZWN0IHNlcnZlcnMsIGFtb25nIA0KICAgb3RoZXIgdGhpbmdzLCBhcmUgbm90IGRp c2N1c3NlZCBoZXJlLg0KDQogICBXaGVuIGEgbmV3IGNhbGwgY29tZXMgaW50byB0aGUgaW5pdGlh dGluZyBnYXRld2F5IGZyb20gdGhlIGNpcmN1aXQgDQogICBzd2l0Y2hlZCBzaWRlLCBhbiBJTlZJ VEUgbWVzc2FnZSBpcyBzZW50IGZyb20gdGhlIGNhbGxpbmcgZ2F0ZXdheSANCiAgIChTSVAgY2xp ZW50KSB0byB0aGUgY2FsbGVkIGdhdGV3YXkgKFNJUCBzZXJ2ZXIpLiBUaGUgZmllbGRzIG9mIHRo ZQ0KICAgSU5WSVRFIG1lc3NhZ2UgYXJlIHNldCBhcyBmb2xsb3dzOg0KDQogICAgIC0gUmVxdWVz dC1VUkk6IFRoaXMgZmllbGQgY29udGFpbnMgc2lwOnBob25lbnVtYmVyQHJlbW90ZWdhdGV3YXku IA0KICAgICAgIEZvciBpbnN0YW5jZSwgaWYgdGhlIG51bWJlciBiZWluZyBjYWxsZWQgaXMgKzEt NzgxLTM1OS01MTEyIGFuZCANCiAgICAgICB0aGUgcmVtb3RlIGdhdGV3YXkgdGhhdCBjYW4gaGFu ZGxlIHRoaXMgY2FsbCBpcyANCiAgICAgICBndzEtYm9zdG9uLnJlc2VhcmNoLm5va2lhLmNvbSwg dGhlbiB0aGUgUmVxdWVzdC1VUkkgaGFzIGEgdmFsdWUgDQogICAgICAgc2lwOisxLTc4MS0zNTkt NTExMkBndzEtYm9zdG9uLnJlc2VhcmNoLm5va2lhLmNvbS4NCg0KICAgICAtIFNlc3Npb24gRGVz Y3JpcHRpb246IFRoZSBzZXNzaW9uIGRlc2NyaXB0aW9uIGluY2x1ZGVzIHRoZSANCiAgICAgICBj YXBhYmlsaXR5IG9mIHRoZSBpbml0aWF0aW5nIGdhdGV3YXkgd2l0aCByZWdhcmQgdG8gc3VwcG9y dGVkIA0KICAgICAgIGNvZGVjcywgc3VwcG9ydGVkIHNlY3VyaXR5IHBhcmFtZXRlcnMgZXRjLiBB bHNvIGluY2x1ZGVkIGluIHRoZSANCiAgICAgICBzZXNzaW9uIGRlc2NyaXB0aW9uIGlzIHRoZSBD aGFubmVsIElkZW50aWZpZXIgKENJRCksIHRoZSBzb3VyY2UgDQogICAgICAgVURQIHBvcnQgYW5k IHRoZSBkZXN0aW5hdGlvbiBVRFAgcG9ydC4NCg0KICAgVXBvbiByZWNlaXZpbmcgdGhlIElOVklU RSBtZXNzYWdlLCB0aGUgcmVtb3RlIGdhdGV3YXkgcmV0dXJucyB0aGUgDQogICBmb2xsb3dpbmcg bWVzc2FnZXMgaW4gdGhlIHNlcXVlbmNlIGluZGljYXRlZDoNCg0KICAgICAtIFRSWUlORzogVGhp cyBtZXNzYWdlIGluZGljYXRlcyB0byB0aGUgY2FsbGluZyBnYXRld2F5IHRoYXQgdGhlIA0KICAg ICAgIHJlbW90ZSBnYXRld2F5IGhhcyByZWNlaXZlZCB0aGUgSU5WSVRFIG1lc3NhZ2Ugc3VjY2Vz c2Z1bGx5IGFuZCANCiAgICAgICB0aGF0IHRoZSByZW1vdGUgZ2F0ZXdheSBpcyB0cnlpbmcgdG8g ZXN0YWJsaXNoIGNvbnRhY3Qgd2l0aCB0aGUgDQogICAgICAgdXNlci4gVGhpcyBpcyBhbHNvIGFu IGluZGljYXRpb24gdG8gdGhlIGluaXRpYXRpbmcgZ2F0ZXdheSBub3QgDQogICAgICAgdG8gcmV0 cmFuc21pdCB0aGUgSU5WSVRFIG1lc3NhZ2UuDQoNCiAgICAgLSBSSU5HSU5HOiBUaGlzIG1lc3Nh Z2UgaW5kaWNhdGVzIHRoYXQgdGhlIHVzZXIgaGFzIGJlZW4gY29udGFjdGVkDQogICAgICAgYW5k IHRoYXQgaGlzIHBob25lIGlzIHJpbmdpbmcuDQoNCiAgICAgLSBTVUNDRVNTOiBUaGlzIG1lc3Nh Z2UgaW5kaWNhdGVzIHRoYXQgdGhlIHVzZXIgaGFzIGFuc3dlcmVkIGhpcyANCiAgICAgICBwaG9u ZS4NCg0KICAgVGhlIFNVQ0NFU1MgbWVzc2FnZSBpcyBzZW50IGJ5IHRoZSByZW1vdGUgZ2F0ZXdh eSBvbmx5IGlmIHRoZSBDSUQNCiAgIHZhbHVlIGluZGljYXRlZCBpbiB0aGUgSU5WSVRFIG1lc3Nh Z2UgaXMgYWNjZXB0YWJsZSB0byB0aGUgcmVtb3RlDQogICBnYXRld2F5LiBVcG9uIHJlY2Vpdmlu ZyB0aGUgU1VDQ0VTUyBtZXNzYWdlLCB0aGUgaW5pdGlhdGluZyBnYXRld2F5DQogICByZXR1cm5z IGFuIEFDSyBtZXNzYWdlIGJhY2sgdG8gdGhlIHJlbW90ZSBnYXRld2F5LiBUaGlzIGlzIGlsbHVz dC0NCiAgIHJhdGVkIGluIEZpZ3VyZSAxMC4NCg0KICAgSWYgdGhlIENJRCBpbmRpY2F0ZWQgaW4g dGhlIElOVklURSBtZXNzYWdlIGlzIG5vdCBhIHZhbGlkIG9uZSwgdGhlDQogICByZW1vdGUgZ2F0 ZXdheSByZXR1cm5zIGFuIEVSUk9SL0ZBSUxVUkUgbWVzc2FnZSBiYWNrIHRvIHRoZSBpbml0aWEt DQogICB0aW5nIGdhdGV3YXkgYXMgaW5kaWNhdGVkIGluIEZpZ3VyZSAxMS4NCg0KDQoNCg0KDQoN Cg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDExXQ0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgCQkg ICAgICAgICAgICAgICAgQXVnIDE1LCAxOTk4DQoNCg0KDQoNCgkJKysrKysrKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAJKysrKysrKyAgICAgICAgDQoJCSsgICAgICsgICAgICAgICBJTlZJ VEUgICAgICAgICAgCSsgICAgICsNCgkJKyAgICAgKyAgICAgLS0tLS0tLS0tLS0tLS0tLT4gICAg CSsgICAgICsNCgkJKyBHVzEgKyAgICAgICAgIFRSWUlORwkJCSsgR1cyICsNCgkJKyAgICAgKyAg ICA8LS0tLS0tLS0tLS0tLS0tLS0tCSAgICAgICAgKyAgICAgKw0KCQkrICAgICArIAkgICAgUklO R0lORwkJKyAgICAgKw0KCQkrICAgICArICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0JICAgICAgICAr ICAgICArDQoJCSsgICAgICsJICAgIFNVQ0NFU1MJCQkrICAgICArDQoJCSsgICAgICsgICAgPC0t LS0tLS0tLS0tLS0tLS0tLQkgICAgICAgICsgICAgICsNCgkJKyAgICAgKwkJQUNLCQkJKyAgICAg Kw0KCQkrICAgICArCSAgICAgIC0tLS0tLS0tLS0tLS0tLS0+CQkrICAgICArDQoJCSsrKysrKysJ CQkJCSsrKysrKysNCg0KDQoJCQkgRmlndXJlIDEwOiBTSVAgQ29uZmlybSBzZXF1ZW5jZQ0KDQoN Cg0KCQkrKysrKysrICAgICAgICAgICAgICAgICAgICAgICAgICAgIAkrKysrKysrICAgICAgICAN CgkJKyAgICAgKyAgICAgICAgIElOVklURSAgICAgICAgICAJKyAgICAgKw0KCQkrICAgICArICAg ICAtLS0tLS0tLS0tLS0tLS0tPiAgICAJKyAgICAgKw0KCQkrIEdXMSArICAgICAgRVJST1IvRkFJ TFVSRSAgIAkJKyBHVzIgKw0KCQkrICAgICArICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0JCSsgICAg ICsNCgkJKysrKysrKyAgIAkJCQkrKysrKysrDQoJCQkgIA0KCQkJIEZpZ3VyZSAxMTogU0lQIFJl amVjdCBzZXF1ZW5jZQ0KDQoNCjQgVHJhbnNtaXNzaW9uIGVycm9ycyBhbmQgcGFja2V0IGxvc3Mg DQoNCiAgIFByb3RvY29scyBzdWNoIGFzIEFUTSwgSVAgYW5kIEFBTDIgc3BlY2lmeSBhIEhlYWRl ciBFcnJvciBDb3JyZWN0aW9uDQogICAoSEVDKSB0byBkZXRlY3QgZXJyb3JzIGluIHRoZSBoZWFk ZXJzLCB3aGVyZWFzIFVEUCBvZmZlcnMgYm90aCBoZWFkZXINCiAgIGFuZCBwYXlsb2FkIHByb3Rl Y3Rpb24uIFRoZSBVRFAgY2hlY2tzdW0gZmllbGQgaW4gdGhlIFVEUCBoZWFkZXIgaXMNCiAgIGNh bGN1bGF0ZWQgZm9yIHRoZSBlbnRpcmUgVURQIHBhY2tldCBpbmNsdWRpbmcgdGhlIGhlYWRlciBh bmQgcGF5bG9hZA0KICAgYnl0ZXMuIFRoZSBNSU5JLWhlYWRlciB1c2VkIGZvciB1c2VyIG11bHRp cGxleGluZyBpcyAyIGJ5dGUgbG9uZyBhbmQgDQogICBkb2VzIG5vdCBoYXZlIGFueSBIRUMgZmll bGQuIFRoZSByZWFzb24gaXMgdGhhdCB0aGUgbWluaSBwYWNrZXRzIGFyZQ0KICAgZW5jYXBzdWxh dGVkIHdpdGhpbiBhIFVEUCBwYXlsb2FkIHRodXMgcHJvdGVjdGVkIGJ5IHRoZSBVRFAgY2hlY2tz dW0uDQogICBUaGUgcHJlc2VuY2Ugb2YgdGhlIFJUUCBzZXF1ZW5jZSBudW1iZXIgaW4gdGhlIFJU UCBoZWFkZXIgZmFjaWxpdGF0ZXMNCiAgIHRvIGlkZW50aWZ5IHBhY2tldCBsb3NzZXMgYXQgdGhl IFJUUCBsZXZlbC4gU2luY2UgZWFjaCBSVFAgcGFja2V0DQogICBjb250YWlucyBhIG51bWJlciBv ZiBtaW5pIHBhY2tldHMsIHBhY2tldCBsb3NzIGF0IGluZGl2aWR1YWwgbGV2ZWwgDQogICBiZWNv bWVzIGRpZmZpY3VsdC4gSG93ZXZlciwgaXQgaXMgb3VyIHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUg U04gZm9yIA0KICAgaW5kaXZpZHVhbCBtaW5pIHBhY2tldCBpcyBub3QgbmVjZXNzYXJ5LiANCg0K NSBBcHBsaWNhdGlvbiBzY2VuYXJpb3MNCg0KICAgU29tZSBvZiB0aGUgbW9zdCBvYnZpb3VzIHNj ZW5hcmlvcywgaW4gd2hpY2ggdGhlIHByb3Bvc2VkIG1ldGhvZCBpcyANCiAgIGJlbmVmaWNpYWws IGFyZSBzaG93biBpbiBGaWd1cmUgMTIuIFRyYWRpdGlvbmFsIHRlbGVwaG9ueSBzeXN0ZW0gc3Vj aCANCiAgIGFzIFBTVE4gaW50ZXJjb25uZWN0ZWQgYnkgSVAgdGVsZXBob255IGdhdGV3YXlzIGlz IGFuIGlkZWFsIHNjZW5hcmlvIA0KICAgd2hlcmUgdXNlciBtdXggbWV0aG9kIGltcHJvdmVzIHRo ZSBiYW5kd2lkdGggZWZmaWNpZW5jeSBpbiB0aGUgSVANCg0KDQoNCg0KQi4gU3ViYmlhaCwgUy4g U2VuZ29kYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0K DQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgCQkgICAgICAgICAgICAgICAgQXVn IDE1LCAxOTk4DQ0KDQoNCiAgIG5ldHdvcmsuIFRoaXMgbWV0aG9kIGNhbiBhbHNvIGJlIHVzZWQg aW4gdGhlIFJhZGlvIEFjY2VzcyBOZXR3b3JrIA0KICAgKFJBTikgb2YgYSBjZWxsdWxhciBuZXR3 b3JrLiBJbiBjZWxsdWxhciB0cnVua2luZywgbXV4IGNvbnRyb2xsZXIgDQogICBpcyBhIHBhcnQg b2YgdGhlIEJTIGFuZCBCU0MvTVNDIGNvbm5lY3RlZCBieSBJUCBuZXR3b3Jrcy4gVXNlciANCiAg IGFnZ3JlZ2F0aW9uIGNhbiBiZSBhcHBsaWVkIGJldHdlZW4gQlRTIGFuZCBCU0MgYXMgd2VsbCBh cyBiZXR3ZWVuDQogICBCU0MgYW5kIE1TQy4gDQoNCg0KCSsrKysrKysrKysJCQkJCSAgICAgICAg ICAgICsrKysrKysrDQoJKwkgKwkJCQkJICAgICAgICAgICAgKwkgICArDQogIAkrIFBTVE4gICAr CQkJCQkgICAgICAgICAgICArIFBTVE4gKw0KCSsrKysrKysrKysJCQkJCSAgICAgICAgICsgICsr KysrKysrDQoJCSAgICArCQkJCQkJKw0KCQkJKysrKysrKysrKysJCSAgICAgICsrKysrKysrKw0K CQkJKyAJICArCQkgICAgICArCSAgICAgICsJDQoJCSAgCSsJICArICAgIAkgCSAgICAgICsJICAg ICAgKw0KCQkJKyBJUCBHVyArKysrKysgIElQIE5FVFdPUksgKysrKyBJUCBHVyArDQoJCQkrCSAg KyAgICAJIAkgICAgICArCSAgICAgICsNCgkJICAgICsJKyAJICArCQkgICAgICArICAgICAgICsN CgkrKysrKysrKysrKyAJKwkgICsJIAkgICAgICArCSAgICAgICsJICAgICsrKysrKysNCgkrCSAg KyAJKysrKysrKysrKysJCSAgICAgICsrKysrKysrKyArKysrKyAgICAgKw0KCSsgR1NNCSAgKwkJ CQkJCSAgICArIEdTTSArDQoJKysrKysrKysrKysJCQkJCQkgICAgKysrKysrKw0KDQoNCgkJRmln dXJlIDEyLiBBcHBsaWNhdGlvbiBzY2VuYXJpbyBvZiBVc2VyIG11eCBpbiBSVFANCg0KDQo2IFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZXJlIGFyZSBubyBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBiZXlvbmQgdGhvc2UgYWRkcmVzc2VkIGluIFJUUA0KICAgaXRzZWxmLiBUaGUgbXVs dGlwbGV4aW5nIHByb3RvY29sIGNhbiBtYWtlIHVzZSBvZiB3aGF0ZXZlciBlbmNyeXB0aW9uDQog ICBhbmQgYXV0aGVudGljYXRpb24gc2NoZW1lcyBhcmUgcHJlc2VudCBpbiBSVFAsIFNJUCwgSC4z MjMgb3Igb3RoZXIgDQogICByZWxldmFudCBwcm90b2NvbHMuIEZvciBpbnN0YW5jZSwgdGhlIG11 bHRpcGxleGVkIG1lZGlhIHN0cmVhbSBjb3VsZCANCiAgIGJlIHNlY3VyZWQgYnkgc2VjdXJpbmcg dGhlIFVEUCBwb3J0cyB1c2luZyBJUFNFQy4gVGhlIHNpZ25hbGluZyBhbmQNCiAgIGNvbnRyb2wg Y2hhbm5lbHMgY291bGQgYmUgc2VjdXJlZCBlaXRoZXIgYnkgdGhlIHVzZSBvZiBJUFNFQyBvciBU TFMuIA0KICAgQXBwbGljYXRpb24gbGV2ZWwgc2VjdXJpdHkgYXMgc3BlY2lmaWVkIGluIFNJUCBh bmQgSC4yMzUgbWF5IGFsc28gYmUgDQogICBpbmNvcnBvcmF0ZWQuDQoNCjcgQ29tcGFyaXNvbiBv ZiBVc2VyIG11eCBpbiBSVFAgYW5kIHRyYWRpdGlvbmFsIFJUUC9VRFAvSVANCg0KICAgVGhlIGlt cG9ydGFudCByZWFzb24gZm9yIG11bHRpcGxleGluZyBzbWFsbCBzaXplIHBhY2tldHMgaW50byBh IA0KICAgc2luZ2xlIFJUUCBwYXlsb2FkIGlzIHRoYXQgdGhlIFJUUC9VRFAvSVAgb3ZlcmhlYWQg Zm9yIGVhY2ggcGFja2V0IA0KICAgY2FuIGJlIHJlZHVjZWQuIEZvciBleGFtcGxlLCB0aGUgUlRQ L1VEUC9JUCBvdmVyaGVhZCBpcyA2Ni43JSBpbiBjYXNlDQogICBvZiAyMCBieXRlIEcuNzIzLjEg cGFja2V0IGFuZCA4MCUgZm9yIGEgMTAgYnl0ZSBHLjcyOSBwYWNrZXQuIA0KICAgQ29uc2lkZXJp bmcgdGhhdCBJUCB0ZWxlcGhvbnkgZ2F0ZXdheXMgdHJhbnNmZXIgMTAwcyBvZiB1c2VyIGF0IGFu eSANCiAgIGdpdmVuIHRpbWUsIHRoZSB0b3RhbCBiYW5kd2lkdGggcmVxdWlyZW1lbnQgaW5jbHVk aW5nIHRoZSBvdmVyaGVhZCANCiAgIGlzIHZlcnkgaGlnaC4gVGhlIGJhbmR3aWR0aCByZXF1aXJl bWVudCBmb3IgYSB0cmFkaXRpb25hbCBzY2hlbWUgDQogICAoUlRQL1VEUC9JUCkgaXMgY29tcGFy ZWQgdG8gdXNlciBtdXggaW4gUlRQIGFuZCB0aGUgcmVzdWx0cyBhcmUgc2hvd24NCiAgIGluIFRh YmxlIDIuIFRoZSByZXN1bHRzIGluZGljYXRlIHRoYXQgdGhlIGJhbmR3aWR0aCByZXF1aXJlbWVu dCB0byANCiAgIHRyYW5zcG9ydCBzYW1lIG51bWJlciBvZiB1c2VycyB0aHJvdWdoIHVzZXIgbXV4 IGlzIHZlcnkgbG93IGNvbXBhcmVkIA0KICAgdG8gdGhlIHRyYWRpdGlvbmFsIElQIHRlbGVwaG9u eSAoUlRQL1VEUC9JUCkgbWV0aG9kLg0KDQoNCg0KDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29k YW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDQoNCklu dGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgCQkgICAgICAgICAgICAgICAgQXVnIDE1LCAx OTk4DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQojIHVzZXJzICAgICAgTm8gTXV4ICAgICAgICAgICBVc2Vy IE11eCAgICAgICAgTm8gTXV4CSAgICBVc2VyTXV4DQoJICAgIChHLjcyMy4xKQkgICAgIChHLjcy My4xKSAgICAgICAgKEcuNzI5KSAgICAgICAoRy43MjkpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCjEwCQkxNTkJ CTY4LjkJCTQwMAkJMTI4DQozMAkJNDc3CQkxODUuNQkJMTIwMAkJMzIwDQo1MAkJNzk1CQkzMDIu MQkJMjAwMAkJNTEyDQo3MAkJMTExMwkJNDE4LjcJCTI4MDAJCTcwNA0KOTAJCTE0MzEJCTUzNS4z CQkzNjAwCQk4OTYNCjExMAkJMTc0OQkJNjUxLjkJCTQ0MDAJCTEwODgNCjEzMAkJMjA2NwkJNzY4 LjUJCTUyMDAJCTEyODANCjE1MAkJMjM4NQkJODg1LjEJCTYwMDAJCTE0NzINCjE3MAkJMjcwMwkJ MTAwMS43CSAgICAgICAgNjgwMAkJMTY2NA0KMTkwCQkzMDIxCQkxMTE4LjMJICAgICAgICA3NjAw CQkxODU2DQoyMTAJCTMzMzkJCTEyMzQuOQkgICAgICAgIDg0MDAJCTIwNDgNCjIzMAkJMzY1NwkJ MTM1MS41CSAgICAgICAgOTIwMAkJMjI0MA0KMjUwCQkzOTc1CQkxNDY4LjEJICAgICAgICAxMDAw MAkJMjQzMg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUYWJsZSAyLiBCYW5kd2lkdGggcmVxdWlyZW1lbnRz IGluIEticHMgZm9yIHVzZXIgbXV4IGFuZCBJUCBtZXRob2RzDQoNCg0KICAgQSBjb21wYXJpc29u IG9mIHBlcmNlbnRhZ2Ugb3ZlcmhlYWQgZm9yIHR3byBkaWZmZXJlbnQgc3BlZWNoIGNvZGVjcw0K ICAgaXMgc2hvd24gaW4gVGFibGUgMy4gVGhlIG92ZXJoZWFkIGR1ZSB0byBSVFAvVURQL0lQIGlz IGNvbnN0YW50IGZvciANCiAgIGJvdGggY29kZWNzLiBVc2VyIG11eCBpbiBSVFAgbWV0aG9kIGlz IGFibGUgdG8gbXVsdGlwbGV4IHNtYWxsIA0KICAgcGFja2V0cyBpbnRvIGEgc2luZ2xlIFJUUC9V RFAvSVAgcGF5bG9hZCB0aHVzIHJlZHVjaW5nIHRoZSBvdmVyaGVhZCANCiAgIHRvIG1pbmltdW0u IFRoZSBvdmVyaGVhZCBjb21wYXJpc29uIG9uIGJvdGggY29kZWNzIHByb3ZlcyB0aGF0IHVzZXIg DQogICBtdXggaW4gUlRQIGlzIHZlcnkgZWZmaWNpZW50IGluIHJlZHVjaW5nIHRoZSBvdmVyaGVh ZC4gDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KI1VzZXJzCU11eChHLjcyOSkJSVAgKEcuNzI5KQlNdXgoRy43 MjMuMSkJSVAgKEcuNzIzLjEpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoxMAkzNy41CQk4MAkJMjMuMDc2OTIzMDgJ NjYuNw0KMzAJMjUJCTgwCQkxNC4yODU3MTQyOQk2Ni43DQo1MAkyMS44NzUJCTgwCQkxMi4yODA3 MDE3NQk2Ni43DQo3MAkyMC40NTQ1NDU0NQk4MAkJMTEuMzkyNDA1MDYJNjYuNw0KOTAJMTkuNjQy ODU3MTQJODAJCTEwLjg5MTA4OTExCTY2LjcNCjExMAkxOS4xMTc2NDcwNgk4MAkJMTAuNTY5MTA1 NjkJNjYuNw0KMTMwCTE4Ljc1CQk4MAkJMTAuMzQ0ODI3NTkJNjYuNw0KMTUwCTE4LjQ3ODI2MDg3 CTgwCQkxMC4xNzk2NDA3Mgk2Ni43DQoxNzAJMTguMjY5MjMwNzcJODAJCTEwLjA1MjkxMDA1CTY2 LjcNCjE5MAkxOC4xMDM0NDgyOAk4MAkJOS45NTI2MDY2MzUJNjYuNw0KMjEwCTE3Ljk2ODc1CTgw CQk5Ljg3MTI0NDYzNQk2Ni43DQoyMzAJMTcuODU3MTQyODYJODAJCTkuODAzOTIxNTY5CTY2LjcN CjI1MAkxNy43NjMxNTc4OQk4MAkJOS43NDcyOTI0MTkJNjYuNw0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgIFRh YmxlIDMuIENvbXBhcmlzb24gb2YgJSBvdmVyaGVhZCBkdWUgdG8gSVAgYW5kIHVzZXIgbXV4IGlu IFJUUA0KDQoNCjggQWR2YW50YWdlcyBvZiB1c2VyIG11bHRpcGxleGluZyBpbiBSVFANCg0KICAg VGhlIGZpcnN0IGFkdmFudGFnZSBvZiB1c2luZyB0aGUgcHJvcG9zZWQgbWV0aG9kIGJldHdlZW4g SVAgdGVsZXBob255DQogICAgDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDQoNCkludGVybmV0IERyYWZ0 ICAgICAgICAgICAgICAgICAgCQkgICAgICAgICAgICAgICAgQXVnIDE1LCAxOTk4DQoNCiAgIGdh dGV3YXlzIGlzIHRoZSBiYW5kd2lkdGggZWZmaWNpZW5jeS4gVGhlIHNlY29uZCBhZHZhbnRhZ2Ug b2Ygc2hhcmluZw0KICAgYSBzaW5nbGUgUlRQL1VEUC9JUCBpcyB0aGF0IHRoZSBudW1iZXIgb2Yg VURQIGNvbm5lY3Rpb25zIGlzIHJlZHVjZWQNCiAgIGJldHdlZW4gZ2F0ZXdheXMuIEZvciBleGFt cGxlLCBpbiB0aGUgcHJvcG9zZWQgdXNlciBtdWx0aXBsZXhpbmcgDQogICBtZXRob2QgYSBzaW5n bGUgVURQIGNvbm5lY3Rpb24gY2FuIGJlIHNoYXJlZCBieSBhIG1heGltdW0gb2YgMjU2IA0KICAg dXNlcnMuIFRoZSB0aGlyZCBhZHZhbnRhZ2UgaXMgdGhhdCB0aGUgbGVzcyBjaGFuY2VzIGZvciB0 cmFmZmljIA0KICAgY29uZ2VzdGlvbiBhdCBpbnRlcm1lZGlhdGUgSVAgcm91dGVycywgYmVjYXVz ZSB0aGUgcHJvcG9zZWQgbWV0aG9kIA0KICAgcmVkdWNlcyB0aGUgbnVtYmVyIG9mIElQIHBhY2tl dHMgYnkgbXVsdGlwbGV4aW5nIG1pbmkgcGFja2V0cyBpbiBhIA0KICAgc2luZ2xlIFJUUCBwYXls b2FkLiBEZXNwaXRlIHRoZSBtdWx0aXBsZXhpbmcgZWZmZWN0LCB1c2VyIG11bHRpcGxleC0NCiAg IGluZyBpbiBSVFAgZG9lcyBub3QgY2F1c2UgYW55IHByb2JsZW1zIGluIHRoZSBJUCBuZXR3b3Jr IHNpbmNlIFJUUCANCiAgIHBheWxvYWQgKG1pbmkgcGFja2V0cykgaXMgdHJhbnNwYXJlbnQgdG8g dGhlIGludGVybWVkaWF0ZSBJUCByb3V0ZXJzLg0KICAgVGhlIHVzZXIgbXV4IG1ldGhvZCByZXF1 aXJlcyBtaW5pbWFsIGVmZm9ydCBvbiBzdGFuZGFyZGl6YXRpb24gYW5kIA0KICAgY291bGQgYmUg aW1wbGVtZW50ZWQgYXMgYW4gYWRkLW9uIG1vZHVsZSB0byB0aGUgZXhpc3RpbmcgdGVsZXBob255 IA0KICAgZ2F0ZXdheXMuDQoNCg0KDQoNCjkgQ29tcGFyaXNvbiBvZiB0aHJlZSBkaWZmZXJlbnQg cHJvcG9zYWxzDQoNCiAgIFdlIGhhdmUgZm91bmQgdHdvIG90aGVyIHByb3Bvc2FscyBbOSwxMF0g c3VibWl0dGVkIGFzIElFVEYgZHJhZnRzIHRvIA0KICAgdGhlIEFWVCBncm91cC4gV2UgaGF2ZSBj b21wYXJlZCBvdXIgcHJvcG9zYWwgd2l0aCBvdGhlcnMgaW4gdGVybXMgb2YgDQogICBrbm93biBw ZXJmb3JtYW5jZSBtZXRyaWNzLiBUYWJsZSA0IHN1bW1hcml6ZXMgdGhlIHJlc3VsdHMgb2YgdGhl DQogICBjb21wYXJpc29uLg0KDQoNCisrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQorCSAgICAgICAgICAgICArICAgIE5v a2lhICAJKyAgICAgTHVjZW50ICAgKyAgICBIaXRhY2hpKw0KKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCisJCSAgICAg KwkJCSsgICAgICAgICAgICAgICsgICAgICAgICAgICsNCitSZWR1Y2luZyBvdmVyaGVhZCAgICsg IFZlcnkgZ29vZAkrICAgVmVyeSBnb29kICArICAgICBvawkgICArDQorCQkgICAgICsJCQkrCSAg ICAgICArCSAgICsNCitCYW5kd2lkdGggZWZmaWNpZW5jeSsgIFZlcnkgZ29vZAkrICAgVmVyeSBn b29kICArICAgICBvawkgICArDQorCQkgICAgICsJCQkrCSAgICAgICArCSAgICsNCitBZGRpdGlv bmFsIGhlYWRlciAgICsgICAgeWVzCQkrICAgIHllcyAgICAgICArICBOb3Qga25vd24rDQorCQkg ICAgICsgKDIgYnl0ZXMvcGt0KSAgICArICgyIGJ5dGVzL3BrdCkrICAgICAgICAgICArDQorCQkg ICAgICsJCQkrCSAgICAgICArICAgICAgICAgICArDQorQXNzZW1ibHkgYW5kIAkgICAgICsgICBT aW1wbGUgICAgICAgICArICAgIEhhcmQgICAgICArICAgU2ltcGxlICArDQorZGUtYXNzZW1ibHkg CSAgICAgKwkJCSsJICAgICAgICsJICAgKw0KKwkJICAgICArCQkJKwkgICAgICAgKwkgICArDQor TWF4ICMgb2YgdXNlcnMJICAgICArCQkJKwkgICAgICAgKwkgICArDQorZm9yIG11bHRpcGxleGlu ZyAgICArICAgICAyNTYJICAgICAgICArICAgIDI1NiAgICAgICArICBOb3Qga25vd24rDQorCQkg ICAgICsJCQkrCSAgICAgICArCSAgICsNCitNaW5pIHBhY2tldCBzaXplICAgICsgVmFyaWFibGUg ICAgCSsgIFZhcmlhYmxlICAgICsgIFZhcmlhYmxlICsNCisJCSAgICAgKyAoMCB+NjQpICAgICAg ICAgICsocmVxLiBrbm93biAgICsgICAgICAgICAgICsNCisJCSAgICAgKwkJCSsgICBwcm9maWxl cykgICsJICAgKw0KKwkJICAgICArCQkJKwkgICAgICAgKwkgICArDQorQ2hhbm5lbCBhc3NvY2lh dGlvbiArIFJlcXVpcmVkCSAgICAgICAgKyAgUmVxdWlyZWQgICAgKyAgIFJlcXVpcmVkKw0KKyhz aWduYWxpbmcpCSAgICAgKwkJCSsJICAgICAgICsgICAgICAgICAgICsNCisJCSAgICAgKwkJCSsJ ICAgICAgICsJICAgKw0KK1BhZGRpbmcgbXV4ICAJICAgICArIE5vdCByZXF1aXJlZCAgICAgKyAg ICBSZXF1aXJlZCAgKyBOb3QgcmVxICAgKw0KK2hlYWRlcgkJICAgICArCQkJKwkgICAgICAgKwkg ICArDQorCQkgICAgICsJCQkrCSAgICAgICArCSAgICsNCitNdWx0aXBsZXggdGltZXIgICAgICsg UHJvcG9zZWQJICAgICAgICArIE5vdCBwcm9wb3NlZCArIE5vdCBwcm9wICArDQorCQkgICAgICsg CQkJKwkgICAgICAgKwkgICArDQorRHluYW1pYyBjYXBhYmlsaXR5ICArIFBvc3NpYmxlICAgICAg ICAgKyBOb3QgcG9zc2libGUgKyBOb3QgcG9zcyAgKw0KKyAgZXhjaGFuZ2UgICAgICAgICAgKyAJ CQkrCSAgICAgICArCSAgICsNCisrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQoNCiAgIFRhYmxlIDQuIENvbXBhcmlzb24g b2YgZGlmZmVyZW50IGFwcHJvYWNoZXMgb24gdXNlciBtdWx0aXBsZXhpbmcNCiAgICAgICAgICAg IGluIFJUUCBwYXlsb2FkDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDQoNCkludGVybmV0IERyYWZ0ICAg ICAgICAgICAgICAgICAgCQkgICAgICAgICAgQXVnIDE1LCAxOTk4DQoNCg0KMTAgQ29uY2x1c2lv bg0KDQogICBBIG5ldyBtZXRob2QgdG8gbXVsdGlwbGV4IHNwZWVjaCBzYW1wbGVzIGZyb20gYSBu dW1iZXIgb2YgdXNlcnMgaW4gDQogICBhIFJUUCBwYXlsb2FkIGlzIHByb3Bvc2VkLiBJdCBpcyBz aG93biB0aGF0IHRoaXMgbWV0aG9kIHJlZHVjZXMgdGhlIA0KICAgb3ZlcmhlYWQgZm9yIHNtYWxs IHBhY2tldHMsIGltcHJvdmVzIHRoZSBiYW5kd2lkdGggZWZmaWNpZW5jeSwgbG93ZXJzDQogICB0 aGUgY2hhbmNlcyBmb3IgY29uZ2VzdGlvbiBhdCBpbnRlcm1lZGlhdGUgSVAgcm91dGVycyBhbmQg ZW5oYW5jZXMgDQogICB0aGUgc2NhbGFiaWxpdHkgb2YgdGhlIGdhdGV3YXlzLiBBIG5ldyBjb250 cm9sIHNpZ25hbGluZyBwcm9jZWR1cmUgdG8NCiAgIG5lZ290aWF0ZSBhIGNoYW5uZWwgYmV0d2Vl biBwZWVyIGdhdGV3YXlzIGlzIGFsc28gcHJvcG9zZWQuIFRoZSANCiAgIGFkdmFudGFnZXMgb2Yg dGhpcyBtZXRob2QganVzdGlmeSB0aGUgbmVlZCBmb3Igc3VjaCBhIG1lY2hhbmlzbSANCiAgIGJl dHdlZW4gZ2F0ZXdheXMgdGhhdCBpbnRlcmNvbm5lY3QgUFNUTiBhbmQgR1NNIHVzZXJzLg0KDQox MSBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJu ZXQgU29jaWV0eSAoMTk5OCkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1l bnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8N CiAgIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVy d2lzZSBleHBsYWluIGl0DQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBi ZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQNCiAgIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hv bGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkNCiAgIGtpbmQsIHByb3Zp ZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoDQog ICBhcmUgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLg0K DQogICBIb3dldmVyLCB0aGlzIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlmaWVkIGlu IGFueSB3YXksIHN1Y2ggYXMNCiAgIGJ5IHJlbW92aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9y IHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNvY2ktDQogICBldHkgb3Igb3RoZXIgSW50ZXJu ZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2UNCiAgIG9m IGRldmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVy ZXMgZm9yDQogICBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBw cm9jZXNzIG11c3QgYmUgZm9sLQ0KICAgbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0 ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuDQogICBFbmdsaXNoLg0KDQogICBUaGUgbGlt aXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90 IGJlDQogICByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3Jz IG9yIGFzc2lnbnMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUg SU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HDQogICBUQVNLIEZP UkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJ TkcNCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRI RSBJTkZPUk1BVElPTg0KICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1Ig QU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVItDQogICBDSEFOVEFCSUxJVFkgT1IgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIg0KDQoxMiBBdXRob3JzJyBBZGRyZXNzZXMNCg0K ICAgQmFyYW5pIFN1YmJpYWgsIFNlbnRoaWwgU2VuZ29kYW4NCiAgIE5va2lhIFJlc2VhcmNoIENl bnRlciAgIA0KICAgMyBCdXJsaW5ndG9uIFdvb2RzIERyLiwgU3RlLiAyNjANCiAgIEJ1cmxpbmd0 b24sIE1BIC0gMDE4MDMsIFVTQQ0KDQogICBiYXJhbml0aGFyYW4uc3ViYmlhaEByZXNlYXJjaC5u b2tpYS5jb20NCiAgIHNlbnRoaWwuc2VuZ29kYW5AcmVzZWFyY2gubm9raWEuY29tDQoNCg0KQi4g U3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFtQYWdlIDE2XQ0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgCQkgICAgICAg ICAgICAgICAgQXVnIDE1LCAxOTk4DQoNCg0KDQoxMyBCaWJsaW9ncmFwaHkNCg0KICAgWzFdIEgu IFNjaHVsenJpbm5lLCBTLiBDYXNuZXIsIFIuIEZyZWRlcmljaywgYW5kIFYuIEphY29ic29uLCBS VFA6IGENCiAgICAgICB0cmFuc3BvcnQgcHJvdG9jb2wgZm9yIHJlYWwtdGltZSBhcHBsaWNhdGlv bnMsIFJlcXVlc3QgZm9yIA0KICAgICAgIENvbW1lbnRzKFByb3Bvc2VkIFN0YW5kYXJkKSAxODg5 LCBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrDQogICAgICAgRm9yY2UsIEphbi4gMTk5Ni4NCg0K ICAgWzJdIEludGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb24gVW5pb24sIENvZGluZyBvZiBz cGVlY2ggYXQgOA0KICAgICAgIGtiaXQvcyB1c2luZyBjb25qdWdhdGUtc3RydWN0dXJlIGFsZ2Vi cmFpYy1jb2RlLWV4Y2l0ZWQgbGluZWFyLQ0KICAgICAgIHByZWRpY3Rpb24sIFJlY29tbWVuZGF0 aW9uIEcuNzI5LCBUZWxlY29tbXVuaWNhdGlvbiBTdGFuZGFyZGktDQogICAgICAgemF0aW9uIFNl Y3RvciBvZiBJVFUsIEdlbmV2YSwgU3dpdHplcmxhbmQsIE1hci4gMTk5Ni4NCg0KICAgWzNdIEgu IFNjaHVsenJpbm5lLCBSVFAgcHJvZmlsZSBmb3IgYXVkaW8gYW5kIHZpZGVvIGNvbmZlcmVuY2Vz IHdpdGgNCiAgICAgICBtaW5pbWFsIGNvbnRyb2wsIFJlcXVlc3QgZm9yIENvbW1lbnRzIChQcm9w b3NlZCBTdGFuZGFyZCkgMTg5MCwNCiAgICAgICBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZv cmNlLCBKYW4uIDE5OTYuDQoNCiAgIFs0XSBJVFUtVCBSZWNvbW1lbmRhdGlvbiAgRy43MjMuMSAo MTk5NSkgIkR1YWwgIFJhdGUgIFNwZWVjaCAgQ29kZXIgDQogICAgICAgRm9yIE11bHRpbWVkaWEg Q29tbXVuaWNhdGlvbnMgVHJhbnNtaXR0aW5nICBBdCAgNS4zICBBbmQgIDYuMyAgDQogICAgICAg a2JpdC9zIiANCg0KICAgWzVdIElUVS1UIFJlY29tbWVuZGF0aW9uIEguMjI1LjAgKDE5OTgpOiAi IE1lZGlhIFN0cmVhbSBQYWNrZXRpemF0aW9uDQogICAgICAgYW5kIFN5bmNocm9uaXphdGlvbiBm b3IgVmlzdWFsIFRlbGVwaG9uZSBTeXN0ZW1zIG9uIE5vbi1HdWFyYW50LQ0KICAgICAgIGVlZCBR dWFsaXR5IG9mIFNlcnZpY2UgTEFOcyAiLg0KDQogICBbNl0gSVRVLVQgUmVjb21tZW5kYXRpb24g SC4yNDUgKDE5OTgpOiAiQ29udHJvbCBvZiBjb21tdW5pY2F0aW9ucyANCiAgICAgICBiZXR3ZWVu IFZpc3VhbCBUZWxlcGhvbmUgU3lzdGVtcyBhbmQgVGVybWluYWwgRXF1aXBtZW50Ii4gSVRVLVQg DQogICAgICAgUmVjb21tZW5kYXRpb24gSC4yNDYgKDE5OTgpICJJbnRlcndvcmtpbmcgb2YgSC5z ZXJpZXMgbXVsdGltZWRpYQ0KICAgICAgIHRlcm1pbmFscyINCg0KICAgWzddIElUVS1UIFJlY29t bWVuZGF0aW9uIEguMzIzIChNYXksIDE5OTYpOiBWaXN1YWwgVGVsZXBob25lIFN5c3RlbXMNCiAg ICAgICBhbmQgRXF1aXBtZW50IGZvciBMb2NhbCBBcmVhIE5ldHdvcmtzIFdoaWNoIFByb3ZpZGUg YSBOb24tR3VhcmEtDQogICAgICAgbnRlZWQgUXVhbGl0eSBvZiBTZXJ2aWNlLg0KDQogICBbOF0g SVRVLVQgUmVjb21tZW5kYXRpb24gSC4zMjMgKEphbnVhcnksIDE5OTgpOiBQYWNrZXQgQmFzZWQg TXVsdGktDQogICAgICAgbWVkaWEgQ29tbXVuaWNhdGlvbnMgU3lzdGVtcw0KDQogICBbOV0gSi4g Um9zZW5iZXJnIGFuZCBILiBTY2h1bHpyaW5uZTogQW4gUlRQIHBheWxvYWQgZm9ybWF0IGZvciB1 c2VyDQogICAgICAgbXVsdGlwbGV4aW5nLCBJRVRGIGRyYWZ0LCB3b3JrIGluIHByb2dyZXNzLCBN YXkgMTk5OC4JDQoNCiAgIFsxMF0gSy4gVGFuaWdhd2EsIFQuIEhvc2hpIGFuZCBLLiBUc3VrYWRh OiBBIFJUUCBzaW1wbGUgbXVsdGlwbGV4aW5nIA0KICAgICAgICB0cmFuc2ZlciBtZXRob2QgZm9y IEludGVybmV0IHRlbGVwaG9ueSBnYXRld2F5LCBJRVRGIGRyYWZ0LCANCiAgICAgICAgd29yayBp biBwcm9ncmVzcywgSnVuZSAxOTg4DQoNCiAgIFsxMV0gSC4gU2NodWx6cmlubmUsIEUuIFNjaG9v bGVyLCBKLiBSb3NlbmJlcmc6IFNlc3Npb24gSW5pdGlhdGlvbiANCglQcm90b2NvbCwgSUVURiBk cmFmdCwgd29yayBpbiBwcm9ncmVzcywgSnVseSAxOTk4Lg0KDQoNCg0KDQoNCg0KDQoNCkIuIFN1 YmJpYWgsIFMuIFNlbmdvZGFuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdl IDE3XQ0KDQoNCg== --===_1998Aug21.181800.1991.301988===_-- From rem-conf Fri Aug 21 16:35:01 1998 From rem-conf-request@es.net Fri Aug 21 16:35:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zA0fL-00001h-00; Fri, 21 Aug 1998 16:32:19 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zA0fI-00001V-00; Fri, 21 Aug 1998 16:32:17 -0700 Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id QAA34560 for ; Fri, 21 Aug 1998 16:20:45 -0700 Received: from scv2.apple.com (scv2.apple.com [17.128.100.140]) by mailgate.apple.com (mailgate.apple.com2.0.15) with ESMTP id ; Fri, 21 Aug 1998 16:18:27 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv2.apple.com (8.8.5/8.8.5) with ESMTP id QAA38436; Fri, 21 Aug 1998 16:18:20 -0700 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: <199808211230.FAA18082@mail-in1.apple.com> References: "Dave Singer's message of Thu, August 20, 1998 10:17:43 -0700 regarding Re: Proposed agenda for AVT WG at IETF in Chicago id" <3980.903629846@north.lcs.mit.edu> MIME-Version: 1.0 Date: Fri, 21 Aug 1998 16:16:20 -0700 To: Olivier AVARO - France Telecom - CNET From: Dave Singer Subject: Re: Proposed agenda for AVT WG at IETF in Chicago Cc: Mark Handley , Vahe Balabanian , casner@cisco.com, rem-conf@es.net Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Olivier SDP is a simple text description format which declares basic information about the set of streams forming a session. Here is an example of a simple two-stream SDP: v=0 o=qts 3104776650 3104776819 IN IP4 17.0.0.255 s=Faucet i=Vic/Vat from the Lab Sun called faucet u=http://www.apple.com e=Ingrid Flowmore p=Ingrid Flowmore 408 996 1010 c=IN IP4 224.2.210.93/15 t=0 0 a=tool:sdr v2.2a23 a=type:test m=audio 22584 RTP/AVP 3 c=IN IP4 224.2.210.93/15 m=video 57736 RTP/AVP 31 c=IN IP4 224.2.255.62/15 you'll note that it is text-based. The initialization information needed for Mpeg4 streams (e.g. the object descriptor) doesn't fit very comfortably into this format. We discussed this a little at a recent IETF -- what to do about 'codecs' which need significant setup information? I'm not sure we reached a conclusion. I suspect (?) that what SDP could tell you is the set of Mpeg4 streams being used, and the mapping from IP RTP stream to Mpeg4 streamID. I would treat the SDP file then as also presenting the 'initial object descriptor' in the sense that it should say which are the 'root' streams of the presentation. One of these might be an object descriptor stream, which would use Mpeg4 streamIDS (as usual) and carry full object descriptors for the streams. Using the mapping info in the SDP file, the StreamIDs could then be mapped to RTP sessions. Such an approach assumes that any 'root' streams do not use extension descriptors etc. and that all the information needed about them (which would normally be in the initial object descriptor) could be in the SDP file. I am speculating without having detailed such a design, but I suspect some approach along these lines is possible without doing violence to either RTP/SDP etc. or to MPEG4. At 5:30 AM -0700 8/21/98, Olivier AVARO - France Telecom - CNET wrote: >Hi Dave, all, > > > Clearly there are questions here about the overlap -- e.g. between SDP > > which describes streams and their format, and the Mpeg4 descriptor stream. > >I don't know yet SDP and if someone has got entry point I would be >grateful. From the little knowledge I have, it seems that SDP could >carry : >- the first object descriptor needed by MPEG that tell where and what is >the MPEG-4 content. >- the complete MPEG-4 descriptor streams. > >Is it what you guys (Vahe, ohers, ...) have in mind ? > >Thanx for the feed back in any case. > >See you, > >Olivir > David Singer Apple Computer/QuickTime 408-974-3162 From rem-conf Fri Aug 21 16:35:01 1998 From rem-conf-request@es.net Fri Aug 21 16:35:00 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zA0gS-00002D-00; Fri, 21 Aug 1998 16:33:28 -0700 Received: from mail-out2.apple.com [17.254.0.51] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zA0gR-000022-00; Fri, 21 Aug 1998 16:33:27 -0700 Received: from mailgate.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.8.5/8.8.5) with ESMTP id QAA13604 for ; Fri, 21 Aug 1998 16:29:02 -0700 Received: from scv3.apple.com (scv3.apple.com [17.128.100.121]) by mailgate.apple.com (mailgate.apple.com2.0.15) with ESMTP id ; Fri, 21 Aug 1998 16:27:27 -0700 Received: from [17.255.20.102] (dsinger2.apple.com [17.255.20.102]) by scv3.apple.com (8.8.5/8.8.5) with ESMTP id QAA31314; Fri, 21 Aug 1998 16:27:23 -0700 X-Sender: singer@mail.apple.com Message-Id: In-Reply-To: MIME-Version: 1.0 Date: Fri, 21 Aug 1998 16:24:00 -0700 To: Vahe Balabanian From: Dave Singer Subject: Re: Proposed agenda for AVT WG at IETF in Chicago Cc: civanlar@research.att.com, rem-conf@es.net Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 9:08 AM -0400 8/21/98, Vahe Balabanian wrote: >These are my concerns: > >1- MPEG-4 Timestamps specifically the Decoder Time Stamp > do we need a special provision for RTP at the Sync Layer? > I think that the RTP time-stamp is, as someone else says, the presentation time-stamp. Since some streams need both, those streams should have an RTP payload format which allows them to carry DTS (or the delta between PTS and DTS, which may be smaller) in the packets. >3- MPEG-4 Elementary stream FlexMuxing in the context of RTP. > Does it break anything? > I don't believe so. One would have to declare the type of the RTP stream (the payload type) as being Mpeg4 flexmux. The descriptive information for this stream should include the flexmux mapping table. Happily, such a beast could easily be put into an attribute in SDP, I think. >2- The Generic MPEG-4 Payload how do we deal with them > in the RTP Mixers? > >4- What is the equivalent of a Scene and Object Descriptor > streams in RTP in the context of multicasting and > Mixer operation. does RTP have to deal with these streams > in a different way? > There is a generic Mpeg-4 payload? Having asked that, my mind goes quite numb at the thought of dynamic mixing of arbitrary Mpeg-4 sessions... >In general when we describe the MPEG-4 RTP payload type don't we >need to address the above to the extent there is nothing >broken in RTP? RTP provides a multiplexing layer and expects to identify the payload type of each stream. Just as there have been separate payload types for Mpeg1 video elementary, audio elementary, and systems streams, so there may be separate payload types for Mpeg4 video, visual, audio, flexmux, and so on. I'm not sure what the set should be, but for the moment, I'm not convinced it ought to have only one type. David Singer Apple Computer/QuickTime 408-974-3162 From rem-conf Fri Aug 21 20:03:22 1998 From rem-conf-request@es.net Fri Aug 21 20:03:20 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zA3ro-0002V2-00; Fri, 21 Aug 1998 19:57:24 -0700 Received: from hydra.precept.com [204.162.119.8] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zA3rm-0002Ue-00; Fri, 21 Aug 1998 19:57:22 -0700 Received: from oak.precept.com (oak.precept.com [204.162.116.21]) by hydra.precept.com (8.8.6/8.8.6) with SMTP id TAA24796; Fri, 21 Aug 1998 19:56:21 -0700 (PDT) Date: Fri, 21 Aug 1998 19:56:58 -0700 (Pacific Daylight Time) From: Stephen Casner To: rem-conf@es.net cc: Vern Paxson Subject: Draft of updated AVT charter Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As I mentioned in an earlier message, the AVT charter badly needs updating. My thanks to Colin Perkins for putting together most of this draft charter. The contents and schedule for the milestones will be discussed at the AVT meeting next week. Comments are welcome from email participants as well. -- Steve Audio/Video Transport (avt) Chair(s): Stephen Casner Colin Perkins Transport Area Director(s): Scott Bradner Vern Paxson Transport Area Advisor: Vern Paxson Mailing Lists: General Discussion:rem-conf@es.net To Subscribe: rem-conf-request@es.net Archive: ftp://nic.es.net/pub/mailing-lists/mail-archive/rem-conf Description of Working Group: The Audio/Video Transport Working Group was formed to specify protocols for real-time transmission of audio and video over UDP and IP multicast. Although the original target was an experimental protocol, in the time since the group was originally chartered much research and develpment has been undertaken in this area, leading to the specification of the standards-track Real-time Transport Protocol (RTP). RTP provides the necessary end-to-end network transport functions for the delivery of real-time data, but does not address resource reservation, guaranteed quality-of-service or call-setup (other working groups are focusing on these problems). An integral part of RTP is the control protocol (RTCP) which augments the data transport to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. The base RTP specification was deliberately designed to be malleable, with profile documents specifying its use in particular scenarios and payload format documents defining the packetisation of particular media formats. The AVT group has developed a profile for audio/video conferencing applications with minimal control and a large range of payload format specifications. We have also developed a header compression mechanism for RTP streams and a document giving guidelines for the use of FEC as packet loss protection. We are in the process of developing a MIB for RTP systems. The future goals of the working group are to revise RTP and the A/V profile for advancement to draft standard stage, to complete the MIB, to produce a guidelines document for future developers of payload formats and to continue development of new payload format documents (including the possibility of producing a "generic" payload format). Goals and Milestones: Revise RTP for advancement to draft standard. Revise A/V profile for advancement to draft standard. - Should aim for working group last call in November and submission to the IESG immediately after the December IETF. This gives time for one more round of editing after this meeting. - Part of this task is registering encoding names as MIME subtypes Complete the MIB - Plan is for this work to be "finished" by December Write guidelines for payload format authors document - Can probably be ready for last call by December? It should just take another round of editing, since the current document is pretty good. Generic payload format? - Proposals to be merged and submitted as draft - Discussion at December meeting - Submit revised draft in February 1999 Other payload formats? - BT656, H.263+, JPEG are done - PureVoice audio: last call September 1998 - Generic FEC: I'd like to see this split, with the parity FEC going to last call soon after this meeting and the R-S forming a different draft, which can have one more iteration before going to last call around the December meeting. The two are sufficiently different that these should be two documents. - DMIF/MPEG-4: tied in with the generic stuff? - X protocol streams: off topic? Multiplexing protocol - Decide course of action at this meeting From rem-conf Sat Aug 22 09:36:13 1998 From rem-conf-request@es.net Sat Aug 22 09:36:12 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zAGS0-0001El-00; Sat, 22 Aug 1998 09:23:36 -0700 Received: from ctral1.vanderbilt.edu [129.59.1.22] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zAGRy-0001Eb-00; Sat, 22 Aug 1998 09:23:34 -0700 Received: from gavish ([194.90.232.150]) by ctrvax.Vanderbilt.Edu (PMDF V5.1-10 #24212) id <01J0WHVAFAQO9GH2S4@ctrvax.Vanderbilt.Edu>; Sat, 22 Aug 1998 11:24:02 CDT Received: from gavish ([194.90.232.150]) by ctrvax.Vanderbilt.Edu (PMDF V5.1-10 #24212) with SMTP id <01J0WHG689RM9GGVHY@ctrvax.Vanderbilt.Edu>; Sat, 22 Aug 1998 11:22:14 -0500 (CDT) Date: Sat, 22 Aug 1998 11:07:12 -0500 From: Bezalel Gavish Subject: ICTEC 98 Conference - Call for Participation X-Sender: gavishb@ctrvax.vanderbilt.edu To: (Recipient list suppressed) Message-id: <01J0WHG7DUD09GGVHY@ctrvax.Vanderbilt.Edu> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Content-type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Call for Participation First International Conference on Telecommunications and Electronic Commerce (ICTEC) Nashville, USA November 20-22, 1998 http://cottonian.ogsm.vanderbilt.edu/ICTEC/ Sponsored by Vanderbilt University Institute for Public Policy Studies (VIPPS), BellSouth, Magnetek, National Commercial Bank (Saudi Arabia), INFORMS Colleges on Information Systems and Telecommunications, IFIP WG 7.3, ATSMA Over the past few years, electronic commerce (EC) has emerged as a dramatic new mode of business. Today, almost every company is either using or considering EC. Advances in telecommunications and automated processes are already forcing dramatic changes in a variety of industries, ranging from banking and finance to music and entertainment. Yet, the TEC environment is still in a relatively early state of evolution. New forums focusing on EC are necessary to stimulate the necessary interactions and knowledge sharing; and given the central role of telecommunications networks in EC, dialogue between telecommunications researchers and EC researchers is essential. ICTEC will bring together both academic and industrial researchers in the fields of telecommunications and EC, to discuss new technological developments and their implications for EC, as well as technological issues that need to be addressed to further the effectiveness and efficiency of EC. The conference will combine research tracks in which technical papers will be presented, with industrial tracks consisting of panels, plenary speakers and exhibits. The conference will include technical sessions, panel discussions and plenary talks on topics such as the following: EC Architecture Information Management Issues in EC EC Developments in Various Countries EC Developments in Specific Industries Document Management Agent-based EC Systems EC Market Mechanisms Marketing and Operations Issues in EC Network Management issues Legal and Policy Issues in TEC EC Strategy Payment Systems in EC Traffic Management Issues Conference General Chair: Bezalel Gavish, Vanderbilt University, Nashville, USA. Information on the conference, including location and registration information, forms and contacts, is available on the WWW, at http://cottonian.ogsm.vanderbilt.edu/ICTEC/ ---------------------------------------------------------------------------- -------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN 37220 USA Tel: Office (615) 322-3659 FAX (615) 343-7177 Home (615) 370-0813 Email: Gavishb@ctral1.vanderbilt.edu From rem-conf Sun Aug 23 07:35:55 1998 From rem-conf-request@es.net Sun Aug 23 07:35:54 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zAb92-00035z-00; Sun, 23 Aug 1998 07:29:24 -0700 Received: from axl01it.ntc.nokia.com [131.228.118.232] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zAb8y-00035p-00; Sun, 23 Aug 1998 07:29:20 -0700 Received: from miller.ntc.nokia.com (miller.ntc.nokia.com [192.100.105.20]) by axl01it.ntc.nokia.com (8.8.5/8.6.9) with ESMTP id RAA16029; Sun, 23 Aug 1998 17:28:52 +0300 (EET DST) Received: from rhino.ntc.nokia.com by miller.ntc.nokia.com with ESMTP (1.39.111.2/16.2) id AA197262364; Sun, 23 Aug 1998 10:26:04 -0400 Received: from Microsoft Mail (PU Serial #1991) by rhino.ntc.nokia.com (PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm)) id AA-1998Aug23.102100.1991.302464; Sun, 23 Aug 1998 10:26:05 -0400 From: subbiah@NASBPD01BS.ntc.nokia.com (Subbiah Baranitharan NRC/Bos) To: rem-conf@es.net ('rem-conf') Cc: casner@cisco.com ('Stephen Casner') Message-Id: <1998Aug23.102100.1991.302464@rhino.ntc.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===_1998Aug23.102100.1991.302464===_" Organization: Nokia Telecommunications Date: Sun, 23 Aug 1998 10:26:05 -0400 Subject: FW: IETF draft to the AVT working group X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --===_1998Aug23.102100.1991.302464===_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, Please use text editor to open the draft circulated earlier. Filename was = truncated in the earlier version. regards, Barani Subbiah ---------- From: Subbiah Baranitharan NRC/Bos To: 'internet-drafts@ietf.org'; 'rem-conf' Cc: 'Stephen Casner' Subject: IETF draft to the AVT working group Date: Friday, August 21, 1998 6:21PM [[ umrt_nok.txt : 2683 in umrt_nok.txt ]] Hello all, Attached is an Internet Draft to the AVT working group titled "User Multiplexing in RTP payload between IP Telephony Gateways". Sorry for the late submission. Abstract This draft proposes a method to multiplex a number of low bit rate audio streams (upto 256) into a single RTP/UDP/IP connection between IP telephony gateways. Audio samples from different users are assem- bled into an RTP payload thus reducing the overhead of RTP/UDP/IP headers. To identify users sharing a single RTP/UDP/IP connection, a 2 byte MINI-Header is proposed. A channel negotiation procedure to assign and release channels on a single UDP connection between gateways is described. [[ umrt_ietf_drft_new.txt : 4859 in umrt_iet.f_d ]] regards, Barani Subbiah --base64 encoded file (umrt_iet.f_d) attached... --===_1998Aug23.102100.1991.302464===_ Content-Type: application/octet-stream; name="umrt_nok.txt" Content-Transfer-Encoding: base64 SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSAgICAgICAgICAgICAgICAgICAgICAgQVZU ICBXb3JraW5nIEdyb3VwDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4NCmRyYWZ0LWlldGYtYXZ0LWJhcmFuaV9z ZW50aGlsLTAwLnR4dCAgICAgICAgICAgICAgTm9raWEgUmVzZWFyY2ggQ2VudGVyLg0KQXVnIDIx LCAxOTk4DQpFeHBpcmVzOiBGZWIgMjEsIDE5OTkNCg0KDQogICAgICAgIFVzZXIgTXVsdGlwbGV4 aW5nIGluIFJUUCBwYXlsb2FkIGJldHdlZW4gSVAgVGVsZXBob255IEdhdGV3YXlzDQoNCg0KU1RB VFVTIE9GIFRISVMgTUVNTw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0 LiBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdS0NCiAgIG1lbnRzIG9mIHRoZSBJbnRl cm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQNCiAgIGl0 cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJp YnV0ZSB3b3JrLQ0KICAgaW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuDQoNCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Yg c2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVk IGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRl IHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlIG1hdGUtDQogICByaWFsIG9yIHRv IGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzIGBgd29yayBpbiBwcm9ncmVzcycnLg0KDQogICBUbyBs ZWFybiB0aGUgY3VycmVudCBzdGF0dXMgb2YgYW55IEludGVybmV0LURyYWZ0LCBwbGVhc2UgY2hl Y2sgdGhlDQogICBgYDFpZC1hYnN0cmFjdHMudHh0JycgbGlzdGluZyBjb250YWluZWQgaW4gdGhl IEludGVybmV0LURyYWZ0cyBTaGFkb3cNCiAgIERpcmVjdG9yaWVzIG9uIGZ0cC5pcy5jby56YSAo QWZyaWNhKSwgbmljLm5vcmR1Lm5ldCAoRXVyb3BlKSwNCiAgIG11bm5hcmkub3ouYXUgKFBhY2lm aWMgUmltKSwgZHMuaW50ZXJuaWMubmV0IChVUyBFYXN0IENvYXN0KSwgb3INCiAgIGZ0cC5pc2ku ZWR1IChVUyBXZXN0IENvYXN0KS4NCg0KICAgRGlzdHJpYnV0aW9uIG9mIHRoaXMgZG9jdW1lbnQg aXMgdW5saW1pdGVkLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFCU1RS QUNUDQoNCiAgIFRoaXMgZHJhZnQgcHJvcG9zZXMgYSBtZXRob2QgdG8gbXVsdGlwbGV4IGEgbnVt YmVyIG9mIGxvdyBiaXQgcmF0ZQ0KICAgYXVkaW8gc3RyZWFtcyAodXB0byAyNTYpIGludG8gYSBz aW5nbGUgUlRQL1VEUC9JUCBjb25uZWN0aW9uIGJldHdlZW4NCiAgIElQIHRlbGVwaG9ueSBnYXRl d2F5cy4gQXVkaW8gc2FtcGxlcyBmcm9tIGRpZmZlcmVudCB1c2VycyBhcmUgYXNzZW0tDQogICBi bGVkIGludG8gYW4gUlRQIHBheWxvYWQgdGh1cyByZWR1Y2luZyB0aGUgb3ZlcmhlYWQgb2YgUlRQ L1VEUC9JUA0KICAgaGVhZGVycy4gVG8gaWRlbnRpZnkgdXNlcnMgc2hhcmluZyBhIHNpbmdsZSBS VFAvVURQL0lQIGNvbm5lY3Rpb24sIA0KICAgYSAyIGJ5dGUgTUlOSS1IZWFkZXIgaXMgcHJvcG9z ZWQuIEEgY2hhbm5lbCBuZWdvdGlhdGlvbiBwcm9jZWR1cmUgdG8NCiAgIGFzc2lnbiBhbmQgcmVs ZWFzZSBjaGFubmVscyBvbiBhIHNpbmdsZSBVRFAgY29ubmVjdGlvbiBiZXR3ZWVuDQogICBnYXRl d2F5cyBpcyBkZXNjcmliZWQuICANCg0KDQoxIEludHJvZHVjdGlvbg0KDQogICBJUCB0ZWxlcGhv bnkgZ2F0ZXdheXMgcHJvdmlkZSBhbiBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgZXhpc3RpbmcNCiAg IGNpcmN1aXQgc3dpdGNoZWQgdGVsZXBob25lIG5ldHdvcmtzIChzdWNoIGFzIFBTVE4gYW5kIEdT TSkgYW5kIHRoZSANCiAgIHBhY2tldCBzd2l0Y2hlZCBJUCBkYXRhIG5ldHdvcmtzLiBJbiBhIHRy YWRpdGlvbmFsIElQIHRlbGVwaG9ueQ0KICAgYXBwbGljYXRpb24sIHRlbGVwaG9uZSBjYWxscyBi ZXR3ZWVuIFBTVE4vR1NNIHVzZXJzIGludGVyY29ubmVjdGVkIGJ5DQogICBhIHBhaXIgb2YgSVAg dGVsZXBob255IGdhdGV3YXlzIGFyZSBjYXJyaWVkIGJ5IHNlcGFyYXRlIFJUUC9VRFAvSVAgDQog ICBjb25uZWN0aW9ucy4gQ29kZWNzIGF0IHRoZSBJUCB0ZWxlcGhvbnkgZ2F0ZXdheSB3aGljaCBj b21wcmVzcyANCiAgIGluY29taW5nIFBTVE4vR1NNIHNwZWVjaCBzYW1wbGVzIGdlbmVyYXRlIHBh Y2tldHMgd2l0aCBzaXplcyByYW5naW5nDQogICBmcm9tIDUgdG8gMjAgYnl0ZXMgcGVyIHNwZWVj aCBzYW1wbGUuIEZvciBleGFtcGxlLCBHLjcyMy4xICh0aGUgbW9zdA0KICAgcG9wdWxhciBJUCB0 ZWxlcGhvbnkgY29kZWMgYW5kIHRoZSBJTVRDIFZvSVAgRm9ydW0ncyBtYW5kYXRvcnkgbG93DQog ICBiaXQtcmF0ZSBjb2RlYyksIGdlbmVyYXRlcyBhIDIwIGJ5dGUgc3BlZWNoIHBhY2tldCBhdCAz MCBtcyBpbnRlcnZhbHMNCg0KDQogICAgICAgDQpCLiBTdWJiaWFoLCBTLiBTZW5nb2RhbiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCg0KDQpJbnRlcm5ldCBE cmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQXVnIDE1LCAx OTk4DQoNCg0KICAgWzRdLiBNYW55IGNvZGVjcyB1c2VkIGluIGNlbGx1bGFyIGVudmlyb25tZW50 cyBnZW5lcmF0ZSBwYWNrZXRzIG9mIA0KICAgc2l6ZSBsZXNzIHRoYW4gMTAgYnl0ZXMgcGVyIHNw ZWVjaCBzYW1wbGUuIFNtYWxsIHNpemUgcGFja2V0cyBhcmUNCiAgIHN1YmplY3QgdG8gYSBsYXJn ZSBvdmVyaGVhZCB3aGVuIHRyYW5zZmVycmVkIHVzaW5nIHRoZSBSZWFsIHRpbWUNCiAgIFRyYW5z cG9ydCBQcm90b2NvbCAoUlRQKS4gVGhlIFJUUC9VRFAvSVAgb3ZlcmhlYWQgaXMgNDAgYnl0ZXMN CiAgICgxMis4KzIwKSBmb3IgYSBzaW5nbGUgc3BlZWNoIHBhY2tldC4gRm9yIGV4YW1wbGUsIGEg MTAgYnl0ZSBwYWNrZXQNCiAgIHRyYW5zZmVycmVkIHZpYSBSVFAvVURQL0lQIGhhcyBhbiBvdmVy aGVhZCBvZiA4MCUuIA0KDQogICBJbiBhZGRpdGlvbiwgZm9yIGVhY2ggY2FsbCByZXF1ZXN0IGEg c2luZ2xlIFVEUC9JUCBjb25uZWN0aW9uIChhIHBhaXINCiAgIG9mIFVEUCBwb3J0cykgaXMgZXN0 YWJsaXNoZWQgYmV0d2VlbiB0aGUgZ2F0ZXdheXMuIFRoaXMgbm90IG9ubHkNCiAgIGxpbWl0cyB0 aGUgbnVtYmVyIG9mIGF1ZGlvIHN0cmVhbXMgYmV0d2VlbiB0aGUgZ2F0ZXdheXMgdG8gdGhlIG51 bWJlcg0KICAgb2YgYXZhaWxhYmxlIFVEUCBwb3J0IHBhaXJzLCBidXQgYWxzbyByZXF1aXJlcyBh IGxhcmdlIHN0YXRlIChtZW1vcnkpDQogICB0byBiZSBtYWludGFpbmVkIGF0IHRoZSB0ZWxlcGhv bnkgZ2F0ZXdheXMsIHRoZXJlYnkgbWFraW5nIHRoZXNlDQogICBnYXRld2F5cyBsZXNzIHNjYWxl YWJsZS4gDQoNCiAgIEFub3RoZXIgZGlzYWR2YW50YWdlIG9mIHRoZSB0cmFkaXRpb25hbCBSVFAv VURQL0lQIG1ldGhvZCBpbiBhDQogICBnYXRld2F5IHNjZW5hcmlvIGlzIHRoZSBwb3NzaWJpbGl0 eSBvZiBjb25nZXN0aW9uIGF0IGludGVybWVkaWF0ZQ0KICAgcm91dGVycyBpbiB0aGUgSVAgbmV0 d29yay4gSW4gdGhlIFJUUC9VRFAvSVAgbWV0aG9kLCBlYWNoIGluZGl2aWR1YWwNCiAgIHNwZWVj aCBwYWNrZXQgaXMgdHJhbnNtaXR0ZWQgYXMgYSBzaW5nbGUgSVAgcGFja2V0LCB3aGljaCByZXN1 bHRzIGluDQogICBsYXJnZSBudW1iZXIgb2Ygc21hbGwgc2l6ZWQgSVAgcGFja2V0cyBiZXR3ZWVu IGdhdGV3YXlzLiBUaGlzIGlzIGENCiAgIHBvdGVudGlhbCBzaXR1YXRpb24gZm9yIGNvbmdlc3Rp b24gYXQgaW50ZXJtZWRpYXRlIElQIHJvdXRlcnMuIA0KICAgQ29uZ2VzdGlvbiBpbiBJUCBuZXR3 b3JrcyByZXN1bHRzIGluIHBhY2tldCBsb3NzIGFuZCBVRFAgZG9lcyBub3QgDQogICBoYXZlIGFu eSByZS10cmFuc21pc3Npb24gbWVjaGFuaXNtIHRvIHJlY292ZXIgbG9zdCBwYWNrZXRzLiBBbHNv LCANCiAgIHJlYWwgdGltZSBhcHBsaWNhdGlvbnMgc3VjaCBhcyBzcGVlY2ggYXJlIGludG9sZXJh bnQgdG8gZGVsYXkgY2F1c2VkIA0KICAgYnkgcmUtdHJhbnNtaXNzaW9uLiANCg0KICAgSW4gdGhp cyBkcmFmdCwgd2UgcHJvcG9zZSBhIG1lY2hhbmlzbSB0aGF0IGVuYWJsZXMgc2V2ZXJhbCBzdHJl YW1zDQogICAodXB0byAyNTYpIHRvIHNoYXJlIGEgc2luZ2xlIFJUUC9VRFAvSVAgY29ubmVjdGlv biBiZXR3ZWVuIElQIA0KICAgdGVsZXBob255IGdhdGV3YXlzIHRoZXJlYnkgcmVkdWNpbmcgdGhl IG92ZXJoZWFkLCBsb3dlcmluZyB0aGUNCiAgIHBvc3NpYmlsaXR5IGZvciBjb25nZXN0aW9uIGF0 IElQIHJvdXRlcnMsIGFuZCBtYWtpbmcgc3VjaCBnYXRld2F5cw0KICAgbW9yZSBzY2FsZWFibGUu IFRoaXMgbWV0aG9kIGlzIHN1aXRhYmxlIGZvciBJUCB0ZWxlcGhvbnkgZ2F0ZXdheXMNCiAgIHRo YXQgaW50ZXJjb25uZWN0IFBTVE4vR1NNIHVzZXJzIHRocm91Z2ggSVAgbmV0d29ya3MuIEluIGEg Y2VsbHVsYXINCiAgIGVudmlyb25tZW50LCBpdCBjYW4gYWxzbyBiZSB1c2VkIGluIGNlbGx1bGFy IHRydW5raW5nLCBsaW5rcyB0aGF0IA0KICAgaW50ZXJjb25uZWN0IEJhc2UgU3RhdGlvbiAoQlMp LCBCYXNlIFN0YXRpb24gY29udHJvbGxlciAoQlNDKSwgYW5kIA0KICAgTW9iaWxlIFN3aXRjaGlu ZyBDZW50ZXIgKE1TQykgb2YgYSBSYWRpbyBBY2Nlc3MgTmV0d29yayAoUkFOKS4gDQogICBJbmRp dmlkdWFsIHVzZXIgcGFja2V0cyBtdWx0aXBsZXhlZCBpbiBhbiBSVFAgcGF5bG9hZCBhcmUgaWRl bnRpZmllZCANCiAgIHVzaW5nIGEgMiBieXRlIE1JTkktaGVhZGVyLiBUaGUgY2hhbm5lbCBhc3Nv Y2lhdGlvbiBiZXR3ZWVuIGdhdGV3YXlzIA0KICAgZm9yIGEgc2luZ2xlIHVzZXIgY2FuIGJlIGNh cnJpZWQgb3V0IGJ5IG9uZSBvZiB0aGUgdGhyZWUgbWVjaGFuaXNtcyANCiAgIGRlc2NyaWJlZCBs YXRlciBpbiB0aGlzIGRyYWZ0LiANCg0KMiBVc2VyIG11bHRpcGxleGluZyBpbiBSVFAgcGF5bG9h ZA0KDQogICBJdCBoYXMgYmVlbiBvYnNlcnZlZCB0aGF0LCBhdCBhbnkgZ2l2ZW4gdGltZSB0aGVy ZSBhcmUgbXVsdGlwbGUgDQogICBhY3RpdmUgdXNlcnMgYmV0d2VlbiBJUCB0ZWxlcGhvbnkgZ2F0 ZXdheSBwYWlycyB0aGF0IGludGVyY29ubmVjdCANCiAgIFBTVE4vUEJYL0dTTSBjbG91ZHMuIFRo aXMgaXMgYWxzbyB0cnVlIGluIHRoZSBjYXNlIG9mIGNlbGx1bGFyIA0KICAgdHJ1bmtpbmcgYmV0 d2VlbiBhIEJhc2UgVHJhbnNtaXNzaW9uIFN5c3RlbSAoQlRTKSBhbmQgQlNDL01TQy4gQXQgDQog ICBwcmVzZW50LCBJUCB0ZWxlcGhvbnkgZ2F0ZXdheXMgZXN0YWJsaXNoIGFuZCBtYWludGFpbiBh IHNlcGFyYXRlIA0KICAgUlRQL1VEUC9JUCBjb25uZWN0aW9uIGZvciBlYWNoIGNhbGwgcmVxdWVz dC4gSW4gdGhlIGFib3ZlIHNjZW5hcmlvcywgDQogICBhIGxhcmdlIG51bWJlciBvZiBjb25uZWN0 aW9ucyBvcmlnaW5hdGUgYW5kIHRlcm1pbmF0ZSBiZXR3ZWVuIHR3byANCiAgIGdhdGV3YXlzIGlu dGVyY29ubmVjdGVkIGJ5IGFuIElQIG5ldHdvcmsuIFRoaXMgaXMgYW4gaWRlYWwgc2l0dWF0aW9u IA0KICAgZm9yIG11bHRpcGxleGluZyBhIGdyb3VwIG9mIHVzZXJzIGluIGEgc2luZ2xlIFJUUC9V RFAvSVAgY29ubmVjdGlvbi4gDQoNCiAgIFRoZSBtZWNoYW5pc20gZm9yIHVzZXIgbXV4IGluIFJU UCB0aGF0IGlzIHByb3Bvc2VkIGluIHRoaXMgZHJhZnQgDQogICBkZWNyZWFzZXMgdGhlIG92ZXJo ZWFkIGJ5IG11bHRpcGxleGluZyB0d28gb3IgbW9yZSAodXAgdG8gMjU2KSBsb3cgDQogICBiaXQg cmF0ZSBjb25uZWN0aW9ucyAoY29tcHJlc3NlZCBzcGVlY2gpIGluIGEgc2luZ2xlIFJUUC9VRFAv SVAgDQogICBjb25uZWN0aW9uLiBUbyBlbmFibGUgc3VjaCBtdWx0aXBsZXhpbmcsIGEgMiBieXRl IGhlYWRlciBjYWxsZWQgDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAg ICAgICAgICAgICAgICAJCQkgICAgICAgICAgICBBdWcgMTUsIDE5OTgNCg0KDQogICBNSU5JLUhl YWRlciBpcyBwcmVwZW5kZWQgdG8gZWFjaCBtaW5pIHBhY2tldCBiZWZvcmUgaXQgaXMgYXNzZW1i bGVkIA0KICAgd2l0aCBvdGhlciBtaW5pIHBhY2tldHMgaW50byBhbiBSVFAgcGF5bG9hZC4gVG8g aWRlbnRpZnkgYSBzaW5nbGUgDQogICB1c2VyIGFtb25nIHRoZSBudW1iZXIgb2YgdXNlcnMgc2hh cmluZyB0aGUgc2FtZSBSVFAgY29ubmVjdGlvbiwgZWFjaCANCiAgIHVzZXIgaXMgYXNzaWduZWQg YSB1bmlxdWUgQ2hhbm5lbCBJZGVudGlmaWVyIChDSUQpIHdoaWNoIGlzIG5lZ290LQ0KICAgaWF0 ZWQgZHVyaW5nIGNvbm5lY3Rpb24gc2V0dXAuIFRoZSBDSUQgbmVnb3RpYXRpb24gcHJvY2VkdXJl IGlzIA0KICAgY2FycmllZCBvdXQgYnkgYSBjb250cm9sIHNpZ25hbGluZyB3aGljaCBtYXkgYmUg YmFzZWQgb24gb25lIG9mIHRoZQ0KICAgdGhyZWUgbWV0aG9kcyhDTlAsIFNJUCBhbmQgSC4yMjUp IGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuIA0KDQoyLjEgTUlOSS1IZWFkZXINCg0KICAgVGhlIGZv cm1hdCBvZiBhIE1JTkktSGVhZGVyIGlzIHNob3duIGluIEZpZ3VyZSAxOg0KDQoNCiAgICAgICAg ICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgDQogICAgICAgICAgICAg ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgIA0KICAgICAgICAgICAgICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgICAgICAgICAgfCAgICAg IENJRCAgICAgIHwgICBMSSAgICAgIHxUfFJ8ICAgDQogICAgICAgICAgICAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KDQoJCSAgICAgRmlndXJlIDE6IEZvcm1hdCBvZiBh IE1JTkktSGVhZGVyDQoNCg0KICAgVGhlIGxlbmd0aCBvZiB0aGUgTUlOSS1IZWFkZXIgaXMgMiBi eXRlcywgd2hpY2ggaW5jbHVkZXMgYSBDaGFubmVsIA0KICAgSWRlbnRpZmllcihDSUQpLCBMZW5n dGggSW5kaWNhdG9yIChMSSksIFRyYW5zaXRpb24gYml0IChUKSBhbmQgYSANCiAgIFJlc2VydmVk IGJpdCAoUikuIFRoZSBwdXJwb3NlIG9mIGVhY2ggZmllbGQgaXMgZGVzY3JpYmVkIGJlbG93Og0K DQogICAgIC0gQ2hhbm5lbCBJRGVudGlmaWNhdGlvbiAoQ0lEKTogVGhpcyA4IGJpdCBmaWVsZCBh bGxvd3MgYSBtYXhpbXVtIA0KICAgICAgIG9mIDI1NiB1c2VycyB0byBzaGFyZSBhIHNpbmdsZSBS VFAvVURQL0lQIGNvbm5lY3Rpb24uIFdoZW4gdGhlIA0KICAgICAgIHRvdGFsIG51bWJlciBvZiB1 c2VycyBleGNlZWRzIDI1NiwgYSBuZXcgUlRQL1VEUC9JUCBjb25uZWN0aW9uIGlzDQogICAgICAg ZXN0YWJsaXNoZWQuDQoNCiAgICAgLSBMZW5ndGggSW5kaWNhdG9yIChMSSk6IFRoaXMgNiBiaXQg ZmllbGQgYWxsb3dzIGEgbWF4aW11bSBwYXlsb2FkIA0KICAgICAgIHNpemUgb2YgNjQgYnl0ZXMu DQoNCiAgICAgLSBUcmFuc2l0aW9uIGJpdCAoVCk6IFRoZSB0cmFuc2l0aW9uIGJpdCBpcyB1c2Vk IHRvIGZhY2lsaXRhdGUNCiAgICAgICBkeW5hbWljIHJlLW5lZ290aWF0aW9uIG9mIG1pbmktcGFj a2V0IHByb2Nlc3NpbmcuIE5vdGlmaWNhdGlvbiBvZg0KICAgICAgIHN1Y2ggY2hhbmdlcyBvY2N1 cnMgYnkgdG9nZ2xpbmcgdGhlIGJpdC4NCg0KICAgICAtIFJlc2VydmVkIGJpdCAoUik6IFRoZSB1 c2Ugb2YgdGhpcyBiaXQgaXMgYmVpbmcgZXhwbG9yZWQgYXQgdGhpcw0KICAgICAgIG1vbWVudC4N Cg0KICAgSXQgaGFzIGJlZW4gb2JzZXJ2ZWQgdGhhdCBhbiA4IGJpdCBDSUQgaXMgc3VmZmljaWVu dCBmb3IgbXVsdGlwbGV4aW5nDQogICBzaW5jZSB0aGVyZSBhcmUgZW5vdWdoIHNwZWVjaCBzYW1w bGVzIGF0IGFueSBpbnN0YW5jZS4gTW9zdCBvZiB0aGUgDQogICBjb2RlY3MgZ2VuZXJhdGUgcGFj a2V0cyBsZXNzIHRoYW4gNDAgYnl0ZXMgcGVyIHNwZWVjaCBzYW1wbGUgdGhhdCBjYW4NCiAgIGJl IGVhc2lseSBhY2NvbW1vZGF0ZWQgd2l0aCBhIDYgYml0IExJIGZpZWxkLiBXaGlsZSB0aGUgcHJl c2VuY2Ugb2YgYQ0KICAgU2VxdWVuY2UgTnVtYmVyIChTTikgZmllbGQgYW5kIGEgTWFya2VyIChN KSBmaWVsZCBpbiB0aGUgbWluaS1oZWFkZXINCiAgIGNvdWxkIGJlIHVzZWZ1bCBhdCB0aGUgcmVj ZWl2aW5nIGdhdGV3YXksIHdlIGJlbGlldmUgdGhhdCB0aGUgDQogICBwcmVzZW5jZSBvZiB0aGVz ZSBmaWVsZHMgaXMgbm90IGNyaXRpY2FsLiBUaGUgU04gZmllbGQgaW4gdGhlIFJUUCANCiAgIGhl YWRlciBjYW4gZ3VhcmFudGVlIHRoZSBvcmRlciBvZiBwYWNrZXQgKFJUUCBwYWNrZXQpIGFycml2 YWwgYXQgdGhlDQogICByZWNlaXZlci4gSWYgdGhlIHBhY2tldCBtdWx0aXBsZXhpbmcgb3JkZXIg YXQgdGhlIHRyYW5zbWl0dGVyIGlzIA0KICAgbWFpbnRhaW5lZCB0aGVuIHRoZXJlIGlzIG5vIG5l ZWQgZm9yIFNOIGluIHRoZSBNSU5JLUhlYWRlciBmcm9tIHRoZSANCiAgIHN0YW5kcG9pbnQgb2Yg aW4tc2VxdWVuY2UgYXJyaXZhbCBvZiBwYWNrZXRzIHdpdGhpbiBhIHNpbmdsZSANCiAgIFJUUC9V RFAvSVAgY29ubmVjdGlvbi4gTW9yZW92ZXIsIGEgSGVhZGVyIEVycm9yIENvbnRyb2wgKEhFQykg ZmllbGQgDQogICB0byBwcm90ZWN0IGZyb20gdHJhbnNtaXNzaW9uIGVycm9ycyBoYXMgYmVlbiBs ZWZ0IG91dCBiZWNhdXNlIFVEUCANCiAgIGNoZWNrc3VtIGNvdWxkIGJlIHVzZWQgZm9yIHRoZSBz YW1lIHB1cnBvc2UuDQoNCg0KDQoNCkIuIFN1YmJpYWgsIFMuIFNlbmdvZGFuICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCVtQYWdlIDNdDQoNCg0KSW50ZXJuZXQgRHJhZnQgCQkJ CSAJCQkgIEF1ZyAxNSwgMTk5OA0KDQoNCg0KMi4yIFJUUCBQYXlsb2FkIEZvcm1hdA0KDQogICBB IHNwZWVjaCBzYW1wbGUgKHZvaWNlIHBhY2tldCkgcmVjZWl2ZWQgZnJvbSBhIHVzZXIgaXMgY29u dmVydGVkIHRvIGENCiAgIG1pbmkgcGFja2V0IGJ5IGFkZGluZyB0aGUgMiBieXRlIE1JTkktSGVh ZGVyLiBUaGUgQ0lEIHNlbGVjdGlvbiBhbmQgDQogICBjaGFubmVsIG5lZ290aWF0aW9uIHByb2Nl ZHVyZXMgYXJlIGNhcnJpZWQgb3V0IGJlZm9yZSB0aGUgcGFja2V0IGlzIA0KICAgYXNzZW1ibGVk LiBUaGVzZSBwcm9jZWR1cmVzIGFyZSBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLiBUaGUgYXNzZW1i bHkNCiAgIG9mIG1pbmkgcGFja2V0cyBpbnRvIGEgc2luZ2xlIFJUUCBwYXlsb2FkIHdpdGggUlRQ L1VEUC9JUCBoZWFkZXIgaXMNCiAgIHNob3duIGluIEZpZ3VyZSAyLiBUaGUgbWluaSBwYWNrZXRz IGZvbGxvdyB0aGUgUlRQIGhlYWRlciBhbmQgZWFjaA0KICAgbWluaSBwYWNrZXQgaXMgZGVsaW5l YXRlZCBieSB0aGUgMiBieXRlIE1JTkktSGVhZGVyLiBUaGlzIGFycmFuZ2VtZW50DQogICBvZiBh IE1JTkktaGVhZGVyIGZvbGxvd2VkIGJ5IHBheWxvYWQgYWxsb3dzIHZhcmlhYmxlIHNpemVkIHBh Y2tldHMNCiAgICg8PSA2NCBieXRlcykgdG8gYmUgYXNzZW1ibGVkIHdpdGhvdXQgdGhlIGtub3ds ZWRnZSBvZiB0aGUgcGF5bG9hZCANCiAgIGl0c2VsZi4gTW9yZW92ZXIsIHRoaXMgc2NoZW1lIHJl cXVpcmVzIGEgdmVyeSBzaW1wbGUgZGUtbXVsdGlwbGV4aW5nDQogICBhbGdvcml0aG0gYXQgdGhl IHJlY2VpdmVyLiBUaGUgUlRQIHBheWxvYWQgcmVjZWl2ZWQgYnkgdGhlIHJlbW90ZSANCiAgIGdh dGV3YXkgaXMgZGUtYXNzZW1ibGVkIHRvIHJlY292ZXIgdGhlIGluZGl2aWR1YWwgbWluaSBwYWNr ZXRzIHVudGlsIA0KICAgdGhlIHBheWxvYWQgYmVjb21lcyBlbXB0eS4gVGhlIHBhY2tldHMgYXJl IHRoZW4gZGVsaXZlcmVkIHRvIHRoZQ0KICAgcmVzcGVjdGl2ZSB1c2VycyBiYXNlZCBvbiB0aGUg Y2hhbm5lbCBhc3NvY2lhdGlvbiBjYXJyaWVkIG91dCBkdXJpbmcgDQogICB0aGUgY2FsbCBzZXR1 cCBwaGFzZS4gDQoNCg0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rICAgKy0rLSstKy0rLSstKw0KICAgICB8ICAgICAgICsgICAgICAgKyAgICAg ICArICAgICArICAgICArICAgICArICAgICArICAgKyAgICAgKyAgICAgfA0KICAgICB8IElQICAg ICsgIFVEUCAgKyBSVFAgICArIE1IMSArIFZQMSArIE1IMiArIFZQMiArIH4gKyBNSG4gKyBWUG4g fA0KICAgICB8ICgyMCkgICsgICg4KSAgKyAoMTIpICArICgyKSArICAgICArICgyKSArICAgICAr ICAgKyAoMikgKyAgICAgfA0KICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rICAgKy0rLSstKy0rLSstKw0KDQoJKk1IIC0gTWluaSBIZWFkZXIsIFZQ IC0gVm9pY2UgUGFja2V0DQoNCgkgICBGaWd1cmUgMi4gUlRQIHBheWxvYWQgZm9ybWF0IHdpdGgg dXNlciBtdWx0aXBsZXhpbmcNCg0KMi4zIFBhY2tldCBhc3NlbWJseSB0aW1lcg0KDQogICBXaGls ZSBhc3NlbWJsaW5nIG1pbmkgcGFja2V0cyBpbnRvIGFuIFJUUCBwYXlsb2FkLCB0aGVyZSBpcyBh IG5lZWQgdG8NCiAgIGNvbnRyb2wgdGhlIHdhaXRpbmcgdGltZSAoZGVsYXkpIGJldHdlZW4gdGhl IHBsYWNlbWVudCBvZiB0aGUgZmlyc3QgDQogICBwYWNrZXQgaW4gdGhlIFJUUCBwYXlsb2FkIGFu ZCB0aGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBjb21wbGV0ZSBJUCANCiAgIHBhY2tldCB0byB0aGUg cmVtb3RlIGdhdGV3YXkuIFdpdGhvdXQgYSB0aW1lciwgcGFja2V0cyBwbGFjZWQgYXQgdGhlIA0K ICAgYmVnaW5uaW5nIHdpbGwgYmUgc3ViamVjdGVkIHRvIGEgbGFyZ2UgZGVsYXkuIFRoaXMgcHJv YmxlbSBvY2N1cnMgDQogICB3aGVuIHRoZXJlIGlzIGEgbGFyZ2UgaW50ZXJ2YWwgYmV0d2VlbiBz dWNjZXNzaXZlIHBhY2tldCBhcnJpdmFscyBhdCANCiAgIHRoZSBtdWx0aXBsZXhpbmcgZW5kLiBU byBzb2x2ZSB0aGlzIHByb2JsZW0sIHdlIHByb3Bvc2UgYSB0aW1lciANCiAgIGNhbGxlZCBUSU1F Ul9NVVggdG8gY29udHJvbCB0aGUgbWF4aW11bSBkZWxheSBhIG1pbmkgcGFja2V0IG1heSBiZSAN CiAgIHN1YmplY3RlZCB0byBkdXJpbmcgdGhlIFJUUCBwYXlsb2FkIGFzc2VtYmx5LiBUaGUgVElN RVJfTVVYIGlzIA0KICAgaW5pdGlhbGl6ZWQgd2hlbiB0aGUgZmlyc3QgcGFja2V0IGlzIHBsYWNl ZCBpbiB0aGUgUlRQIHBheWxvYWQgYW5kIA0KICAgdXBvbiB0aGUgdGltZXIgZXhwaXJ5IHRoZSBS VFAvVURQL0lQIHBhY2tldCBpcyB0cmFuc21pdHRlZC4gVGhlcmUgYXJlDQogICBpbnN0YW5jZXMg d2hlbiB0aGUgUlRQL1VEUC9JUCBwYWNrZXQgbmVlZHMgdG8gYmUgdHJhbnNtaXR0ZWQgd2l0aG91 dCANCiAgIHRoZSBleHBpcnkgb2YgVElNRVJfTVVYLiBUaGUgaGlnaGVyIHRoZSBUSU1FUl9NVVgg dmFsdWUgdGhlIGJldHRlciANCiAgIHRoZSBiYW5kd2lkdGggZWZmaWNpZW5jeS4gSG93ZXZlciwg YSBoaWdoZXIgVElNRVJfTVVYIHZhbHVlIG1lYW5zIA0KICAgYWRkaXRpb25hbCBkZWxheSBmb3Ig dm9pY2UgcGFja2V0cy4NDQoNCjIuNCBQYWNrZXQgU2l6ZQ0KDQogICBUaGUgYXNzZW1ibHkgcHJv Y2VzcyBvZiBtaW5pLXBhY2tldHMgaW50byBhbiBSVFAgcGF5bG9hZCBzaG91bGQgbm90DQogICBv bmx5IGNvbnNpZGVyIHRoZSBUSU1FUl9NVVggdmFsdWUgYnV0IHNob3VsZCBhbHNvIHRha2UgaW50 byBhY2NvdW50IA0KICAgdGhlIHNpemUgb2YgdGhlIHJlc3VsdGluZyBJUCBkYXRhZ3JhbS4gVGhl IHNpemUgb2YgdGhlIHJlc3VsdGluZyBJUCANCiAgIGRhdGFncmFtIHNob3VsZCBub3QgZXhjZWVk IHRoZSBtYXhpbXVtIHRyYW5zbWlzc2lvbiB1bml0IChNVFUpIG9mIHRoZQ0KDQoNCg0KQi4gU3Vi YmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQ YWdlIDRdDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAJCSAgICAgICAgICAg ICAgIEF1ZyAxNSwgMTk5OA0KDQoNCiAgIElQIG5ldHdvcmsuIEhlbmNlLCB3aGVuIHRoZSBJUCBu ZXR3b3JrIGlzIHRoZSBwdWJsaWMgSW50ZXJuZXQsIHRoZSANCiAgIHNpemUgb2YgdGhlIElQIGRh dGFncmFtIHNob3VsZCBub3QgZXhjZWVkIDE1MDAgYnl0ZXMuIEl0IGhhcyBiZWVuIA0KICAgZGV0 ZXJtaW5lZCB0aGF0IGFuIElQIGRhdGFncmFtIG9mIHNpemUgbGVzcyB0aGFuIDE1MDAgYnl0ZXMg dXN1YWxseSANCiAgIGdvZXMgdGhyb3VnaCB0aGUgSW50ZXJuZXQgdW5mcmFnbWVudGVkLg0KDQoy LjUgVURQIGNvbm5lY3Rpb24NCg0KICAgSW1wbGVtZW50YXRpb24gZGV0YWlscyBvZiBzaGFyaW5n IGEgcGFpciBvZiBVRFAgcG9ydHMgYW1vbmcgZGlmZmVyZW50DQogICB1c2VycyBhbmQgcmV1c2lu ZyB0aGUgc2FtZSBwb3J0IG51bWJlcnMgZm9yIHBlcnNpc3RlbnQgVURQIHNlc3Npb25zIA0KICAg YXJlIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gDQoNCjMgQ29udHJvbCBzaWdu YWxpbmcgZm9yIHVzZXIgbXVsdGlwbGV4aW5nIA0KDQogICBUaGUgdXNlciBwbGFuZSBhbmQgY29u dHJvbCBwbGFuZSBiZXR3ZWVuIGdhdGV3YXlzIGlzIHNob3duIGluIA0KICAgRmlndXJlIDMuIFRo ZSBjb250cm9sIHBsYW5lIHNpZ25hbGluZyBpcyBuZWVkZWQgYmVjYXVzZSBwZWVyIE11eCANCiAg IGNvbnRyb2xsZXJzIGFyZSByZXF1aXJlZCB0byBuZWdvdGlhdGUgYSBjaGFubmVsIGZvciBhbiBp bmNvbWluZyBjYWxsIA0KICAgcmVxdWVzdCBvbiBhbiBleGlzdGluZyBvciBvbiBhIG5ldyBVRFAg Y29ubmVjdGlvbi4gVGhlIGNvbnRyb2wgDQogICBzaWduYWxpbmcgaXMgdHJhbnNmZXJyZWQgdXNp bmcgYSBjb21tb24gcGVyc2lzdGVudCBjb25uZWN0aW9uLCB3aGljaA0KICAgbWF5IGJlIGVpdGhl ciBjb25uZWN0aW9uIG9yaWVudGVkIChUQ1ApIG9yIGNvbm5lY3Rpb25sZXNzIChVRFApLg0KICAg VGhlIHVzZXIgcGxhbmUgYXNzb2NpYXRpb24gKENJRCBhbGxvY2F0aW9uIG9uIGEgVURQIGNvbm5l Y3Rpb24pIGlzIA0KICAgbWFkZSBhZnRlciBhIHN1Y2Nlc3NmdWwgY29ubmVjdGlvbiBzZXR1cC4g SW4gdGhpcyBkcmFmdCwgd2UgZGVzY3JpYmUNCiAgIHRocmVlIGRpZmZlcmVudCBhcHByb2FjaGVz IHRvIGVzdGFibGlzaCBhbmQgY2xlYXIgYSBDSUQgYXNzb2NpYXRpb24uDQogICBUaGUgdXNlciBw bGFuZSBkYXRhIGlzIGNhcnJpZWQgb3ZlciBSVFAvVURQL0lQIGxheWVycyBpbiBhIG1hbm5lcg0K ICAgc2ltaWxhciB0byB0aGUgYXVkaW8gYW5kIHZpZGVvIHRyYW5zcG9ydCBvdmVyIElQIG5ldHdv cmtzLiBUaGUNCiAgIGRlc2NyaXB0aW9uIG9mIHRoZSBzaWduYWxsaW5nIGFuZCBjb250cm9sIG9w ZXJhdGlvbiBpcyBub3QgbWVhbnQgdG8NCiAgIGJlIGNvbXByZWhlbnNpdmUuDQoNCgkrKysrKysr KysrKysrKysrKysrCQkJCSsrKysrKysrKysrKysrKysrKysNCgkrIE11eCBDb250cm9sbGVyICAr CQkJCSsgTXV4IGNvbnRyb2xsZXIgICsNCgkrKysrKysrKysrKysrKysrKysrCQkJCSsrKysrKysr KysrKysrKysrKysNCgkJfCAgICB8CQkJCQkgICB8CQl8CQ0KCQl8ICAgIHwJVS1wbGFuZQkJICAg ICAgICAgIFUtcGxhbmUgIHwJCXxDLXBsYW5lIA0KQy1wbGFuZQkgICAgICAgIHwgICArKysrKysr CQkJCSsrKysrKysJICAgICAgICB8CQ0KCQl8ICAgKyBSVFAgKwkJCQkrIFJUUCArCSAgICAgICAg fA0KCSsrKysrKysrKysrKysrKysrKysJCQkJKysrKysrKysrKysrKysrKysrKw0KCSsgIFRDUCAg IHwgICBVRFAgICsJCQkJKyAgIFVEUCAgfCAgVENQCSAgKyANCgkrKysrKysrKysrKysrKysrKysr CQkJCSsrKysrKysrKysrKysrKysrKysNCgkrCUlQCSAgKysrKz4JICBJUCBORVQgICAgICAgICAg PCsrKysrKwlJUAkgICsNCgkrKysrKysrKysrKysrKysrKysrCQkJCSsrKysrKysrKysrKysrKysr KysNCg0KICBGaWd1cmUgMy4gQ29udHJvbCBwbGFuZSBhbmQgdXNlciBwbGFuZSBpbiBhIHVzZXIg bXVsdGlwbGV4aW5nIHNjZW5hcmlvDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoNCg0KSW50ZXJuZXQg RHJhZnQgCQkJCQkJCQlBdWcgMTUsIDE5OTgNCg0NCg0KMy4xIENJRCBzZWxlY3Rpb24gDQoNCiAg IElycmVzcGVjdGl2ZSBvZiB0aGUgY2hvaWNlIG9mIHRoZSBzaWduYWxpbmcgbWVjaGFuaXNtIGJl dHdlZW4gdGhlIE1VWA0KICAgY29udHJvbGxlcnMsIHRoZSBDSUQgc2VsZWN0aW9uIHByb2NlZHVy ZSBhdCBlYWNoIG9mIHRoZSBNVVgNCiAgIGNvbnRyb2xsZXJzIE1VU1QgYmUgZG9uZSBhcyBmb2xs b3dzOg0KDQogICAgIDEpIEFycml2YWwgb2YgYSBuZXcgY2FsbCBmcm9tIGEgUFNUTi9HU00gdXNl ciB0cmlnZ2VycyBhIENJRCANCiAgICAgICAgYXNzaWdubWVudCBzZXF1ZW5jZSBhdCB0aGUgTVVY IGNvbnRyb2xsZXIgb2YgdGhlIGxvY2FsIGdhdGV3YXkuIA0KICAgICAgICBBZnRlciBlc3RhYmxp c2hpbmcgd2hpY2ggcmVtb3RlIGdhdGV3YXkgY2FuIGhhbmRsZSB0aGUgY2FsbCwgDQogICAgICAg IHRoZSBsb2NhbCBNVVggY29udHJvbGxlciBjaGVja3MgZm9yIHRoZSBleGlzdGVuY2Ugb2YgYW4g DQogICAgICAgIFJUUC9VRFAvSVAgY29ubmVjdGlvbiB0byB0aGUgcmVtb3RlIE1VWCBjb250cm9s bGVyLiBJZiB0aGVyZSANCiAgICAgICAgZXhpc3RzIGEgVURQIGNvbm5lY3Rpb24gd2l0aCBmcmVl IENJRHMsIHRoZW4gYSBDSUQgaXMgY2hvc2VuIGFuZA0KICAgICAgICByZXNlcnZlZCBmb3IgdGhh dCBjYWxsLiBJZiB0aGVyZSBpcyBubyBVRFAgY29ubmVjdGlvbiBiZXR3ZWVuIA0KICAgICAgICB0 aGUgZ2F0ZXdheXMgb3IgaWYgYWxsIHRoZSBleGlzdGluZyBjb25uZWN0aW9ucyBhcmUgZnVsbCAo aS5lLiwgDQogICAgICAgIG5vIGZyZWUgQ0lEKSwgdGhlbiBhIG5ldyBSVFAvVURQL0lQIGNvbm5l Y3Rpb24gaXMgZXN0YWJsaXNoZWQuIA0KICAgICAgICBPbmNlIHRoZSBDSUQgc2VsZWN0aW9uIGlz IGRvbmUsIGEgbm90aWZpY2F0aW9uIG1lc3NhZ2UgdGhhdCANCiAgICAgICAgY29uc2lzdHMgb2Yg Q0lELCBjYWxsaW5nIHVzZXIgSUQsIGNhbGxlZCB1c2VyIElELCBsb2NhbCBhbmQgDQogICAgICAg IHJlbW90ZSBVRFAgcG9ydCBudW1iZXJzIGlzIHRyYW5zbWl0dGVkLiBTdWNoIHRyYW5zbWlzc2lv biBtYXkNCiAgICAgICAgb2NjdXIgZWl0aGVyIGluIHRoZSBpbml0aWFsIG5vdGlmaWNhdGlvbiBt ZXNzYWdlIChkdXJpbmcgY2FsbA0KICAgICAgICBzZXR1cCkgb3IgaW4gdGhlIG5vdGlmaWNhdGlv biBtZXNzYWdlIGZvciBjYXBhYmlsaXR5IGV4Y2hhbmdlDQogICAgICAgIHRoYXQgb2NjdXJzIGFm dGVyIGNhbGwgc2V0dXAuDQoNCiAgICAgMikgVXBvbiByZWNlaXZpbmcgdGhlIG1lc3NhZ2UgY29u dGFpbmluZyB0aGUgQ0lELCB0aGUgTVVYIGNvbnRyb2wtDQogICAgICAgIGxlciBhdCB0aGUgcmVt b3RlIGdhdGV3YXkgY2hlY2tzIGl0cyBDSUQgdGFibGUgYXNzb2NpYXRlZCB3aXRoDQogICAgICAg IHRoZSBVRFAgY29ubmVjdGlvbi4gVGhlIHN0YXR1cyBvZiBDSURzIGlzIG1haW50YWluZWQgaW4g YSBDSUQNCiAgICAgICAgdGFibGUsIHdoaWNoIGlzIGFzc29jaWF0ZWQgd2l0aCBlYWNoIFVEUCBj b25uZWN0aW9uIGJldHdlZW4gYW55DQogICAgICAgIHR3byBnYXRld2F5cy4gSWYgdGhlIENJRCBp bmRpY2F0ZWQgaW4gdGhlIG5vdGlmaWNhdGlvbiBtZXNzYWdlIA0KICAgICAgICBoYXMgbm90IGFs cmVhZHkgYmVlbiBhc3NpZ25lZCwgdGhlbiB0aGUgcmVtb3RlIE1VWCBjb250cm9sbGVyDQogICAg ICAgIG1ha2VzIGFuIGVudHJ5IGluIGl0cyBDSUQgdGFibGUgYXNzaWduaW5nIHRoZSBDSUQgdG8g YSBjYWxsIA0KICAgICAgICBiZXR3ZWVuIHRoZSBwYWlyIG9mIFVEUCBwb3J0cyBhcyBpbmRpY2F0 ZWQgaW4gdGhlIG5vdGlmaWNhdGlvbg0KICAgICAgICBtZXNzYWdlLiBJZiB0aGUgVURQIHBvcnQg YXQgdGhlIHJlbW90ZSBnYXRld2F5IGlzIG5vdCBhbHJlYWR5IA0KICAgICAgICBvcGVuLCB0aGVu IHRoZSBNVVggY29udHJvbGxlciBvcGVucyB0aGUgVURQIHBvcnQuIFRhYmxlIDEgc2hvd3MgDQog ICAgICAgIGEgc2FtcGxlIENJRCB0YWJsZSB1c2VkIGF0IGEgZ2F0ZXdheSBmb3IgYSBzaW5nbGUg VURQIGNvbm5lLQ0KICAgICAgICBjdGlvbi4NCg0KCQktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCgkJfCBDSUQgfENJRCBzdGF0dXMJ fCAJTG9jYWwgVUlEIAl8UmVtb3RlIFVJRCB8DQoJCS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCQl8ICAgNQl8IEFzc2lnbmVkCXwJ NjE3MjMwMDAwMCAJfDkxMjczNjM3MzYgfA0KCQl8CXwJCXwJCQl8CSAgICB8DQoJCXwgIDEwCXwg UmVzZXJ2ZWQgIAl8CTYxNzU0NjQ2MzYJfDgyNjM3Mzc0NzQgfA0KCQl8CXwJCXwJCQl8CSAgICB8 DQoJCXwgIDIwCXwgSWRsZQkJfAkJCXwJICAgIHwNCgkJfAl8CQl8CQkJfAkgICAgfA0KCQl8IDIw MAl8IElkbGUJCXwJCQl8CSAgICB8DQogCQktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KCQlUYWJsZSAxLiBDSUQgdGFibGUgZm9y IGEgc2luZ2xlIFVEUCBjb25uZWN0aW9uDQoNCg0KMy4yIENJRCBjb2xsaXNpb24NCg0KICAgRHVy aW5nIHRoZSBDSUQgbmVnb3RpYXRpb24gcHJvY2VkdXJlcywgdGhlcmUgaXMgYSBwb3NzaWJpbGl0 eSB0aGF0IA0KICAgdGhlIHNhbWUgQ0lEIGlzIHNlbGVjdGVkIGJ5IGJvdGggZW5kcyBmb3IgdGhl aXIgb3duIGNhbGwgcmVxdWVzdHMuIA0KICAgQm90aCBnYXRld2F5cyB0cmFuc21pdCBjaGFubmVs IHJlcXVlc3QgbWVzc2FnZXMgd2l0aCB0aGUgc2FtZSBDSUQgDQogICB3aXRob3V0IHRoZSBrbm93 bGVkZ2Ugb2YgdGhlIG90aGVyIGdhdGV3YXkuIEFmdGVyIHJlY2VpdmluZyB0aGUgDQogICByZXF1 ZXN0LCBib3RoIHNpZGVzIGFyZSB1bmFibGUgdG8gYWxsb2NhdGUgdGhlIENJRCBzaW5jZSBpdCBo YXMgYmVlbg0KDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoNCg0KSW50ZXJuZXQgRHJhZnQgCQkJCQkJ CQlBdWcgMTUsIDE5OTgNCg0KDQoNCiAgIHJlc2VydmVkIGZvciB0aGVpciBsb2NhbCBjYWxsIHJl cXVlc3QuIFRoaXMgcHJvYmxlbSBpcyBvdGhlcndpc2UgDQogICBrbm93biBhcyBDSUQgZ2xhcmUu IFdlIHByb3Bvc2UgdG8gdXNlIGEgbWV0aG9kIHRoYXQgaXMgZmFpciB0byBib3RoIA0KICAgZW5k cyBpbiBDSUQgYXNzaWdubWVudCBwcm9jZWR1cmVzLiBJbiB0aGlzIG1ldGhvZCwgb25lIHNpZGUg aXMgDQogICBhc3NpZ25lZCB0byBhbGxvY2F0ZSBDSURzIGZyb20gdGhlIHRvcCBvZiB0aGUgQ0lE IHRhYmxlIGFuZCB0aGUgDQogICBvcHBvc2l0ZSBzaWRlIGZyb20gYm90dG9tLiBIb3dldmVyLCBD SUQgY29sbGlzaW9uIG9jY3VycyB3aGVuIGEgDQogICBzaW5nbGUgQ0lEIGlzIGF2YWlsYWJsZSBh dCBib3RoIGVuZHMuIEV2ZW4gaW4gc3VjaCBhIGNhc2UsIGZhaXJuZXNzIA0KICAgY2FuIGJlIGFj aGlldmVkIGJ5IGFuIGFzc2lnbm1lbnQgYmFzZWQgb24gdGhlIGV2ZW4gYW5kIG9kZCB2YWx1ZSBv Zg0KICAgQ0lELiBUaGUgYXJiaXRyYXRpb24gb2Ygd2hpY2ggc2lkZSBzdGFydHMgZnJvbSB0b3Ag Y2FuIGJlIHJlc29sdmVkIA0KICAgdXNpbmcgSVAgYWRkcmVzcyBvZiB0aGUgZ2F0ZXdheXMuIEZv ciBleGFtcGxlLCB0aGUgZ2F0ZXdheSB3aXRoIHRoZSANCiAgIGhpZ2hlciBJUCBhZGRyZXNzIHN0 YXJ0cyBmcm9tIHRoZSB0b3AgYW5kIHRoZSBvdGhlciBnYXRld2F5IHN0YXJ0cyANCiAgIGZyb20g dGhlIGJvdHRvbS4gDQoNCjMuMyBDaGFubmVsIE5lZ290aWF0aW9uIFByb2NlZHVyZXMgKENOUCkN Cg0KICAgQ05QIGlzIGEgbmV3IGNvbnRyb2wgc2lnbmFsaW5nIHNwZWNpZmljYWxseSBwcm9wb3Nl ZCBmb3IgdGhlIHVzZXIgDQogICBtdWx0aXBsZXhpbmcgYXBwbGljYXRpb24gYmV0d2VlbiBJUCB0 ZWxlcGhvbnkgZ2F0ZXdheXMgdGhhdCANCiAgIGludGVyY29ubmVjdCBQU1ROL0dTTSBjbG91ZHMu IFRoZSBmdW5jdGlvbiBvZiBDTlAgaXMgdG8gbmVnb3RpYXRlIGEgDQogICBDSUQgZm9yIGEgY2Fs bCB0aHJvdWdoIGEgc2V0IG9mIG1lc3NhZ2VzIHNpbWlsYXIgdG8gc3RhbmRhcmQgc2lnbmFsLQ0K ICAgaW5nIHByb3RvY29scy4gU2luY2UgQ05QIGlzIHRhcmdldGVkIGZvciBhIHNwZWNpZmljIGFw cGxpY2F0aW9uLCB3ZSANCiAgIGRvIG5vdCBhbnRpY2lwYXRlIHRoZSBuZWVkIGZvciBjb21wbGV4 IHNpZ25hbGluZyBwcm9jZWR1cmVzIHNpbWlsYXIgDQogICB0byBILjIyNS9ILjI0NSBbNSw2XS4g SG93ZXZlciwgSC4yMjUvSC4yNDUgY291bGQgYmUgYWRhcHRlZCB0byBzdWl0DQogICB0aGUgcmVx dWlyZW1lbnRzIG9mIHRoZSB1c2VyIG11bHRpcGxleGluZyBpbiBSVFAgbWV0aG9kLiBDTlAgY29u c2lzdHMNCiAgIG9mIGEgc2V0IG9mIG1lc3NhZ2VzIHRoYXQgaW5jbHVkZSBhc3NpZ24sIGFzc2ln bl9jb25maXJtLCByZWxlYXNlLCANCiAgIHJlbGVhc2VfY29uZmlybSBhbmQgcmVqZWN0LiBBbiBh ZGRpdGlvbmFsIG1lc3NhZ2UgIm1lc3NhZ2VzX3RyYW5zZmVyIg0KICAgaXMgYWxzbyBwcm9wb3Nl ZCBpbiBjYXNlIHRoZXJlIGlzIGEgbmVlZCB0byB0cmFuc21pdCBjb250cm9sIG1lc3NhZ2VzDQog ICBvZiBhIHBhcnRpY3VsYXIgdXNlciAoY2FsbCBjb250cm9sIG1lc3NhZ2VzKSBkdXJpbmcgdGhl IGFjdGl2ZSANCiAgIHNlc3Npb24gb2YgYSBjYWxsLiBBIGRldGFpbGVkIHN0dWR5IG9uIHRoZSBm b3JtYXQgb2YgdGhlIENOUCBtZXNzYWdlcw0KICAgYW5kIHRoZWlyIHBhcmFtZXRlcnMgd2lsbCBi ZSByZXBvcnRlZCBsYXRlci4NCg0KICAgVGhlIGZvbGxvd2luZyBpcyB0aGUgc2VxdWVuY2Ugb2Yg ZXZlbnRzIHRoYXQgb2NjdXIgaW4gYSBjaGFubmVsIA0KICAgbmVnb3RpYXRpb24gcGhhc2U6DQoN CiAgICAgLSBBc3NpZ246IFVwb24gYXJyaXZhbCBvZiBhIG5ldyBjYWxsIGZyb20gYSBQU1ROL0dT TSB1c2VyLCBhIENJRCBpcw0KICAgICAgIGFzc2lnbmVkIGJhc2VkIG9uIHRoZSBwcm9jZWR1cmUg ZGVzY3JpYmVkIGluIHRoZSBwcmV2aW91cyBzZWN0LQ0KICAgICAgIGlvbi4gQW4gImFzc2lnbiIg bWVzc2FnZSBpcyB0aGVuIHRyYW5zbWl0dGVkIHRvIHRoZSByZW1vdGUgZ2F0ZS0gDQogICAgICAg d2F5IGNvbnRhaW5pbmcgdGhlIGxvY2FsIFVEUCBwb3J0IG51bWJlciwgcmVtb3RlIFVEUCBwb3J0 IG51bWJlciwgDQogICAgICAgQ0lEIG51bWJlciwgY2FsbGluZyBhbmQgY2FsbGVkIHVzZXIsIGFu ZCBhbiBVVUkgZmllbGQgdG8gY2FycnkgDQogICAgICAgYW55IGNhbGwgY29udHJvbCBzaWduYWxp bmcgKFBTVE4gYW5kIFNTNykuIA0KDQogICAgIC0gQXNzaWduX2NvbmZpcm0gb3IgcmVqZWN0OiBU aGUgcmVtb3RlIHBlZXIgcmVjb3ZlcnMgdGhlIGluZm9ybWF0LQ0KICAgICAgIGlvbiB3aXRoaW4g dGhlICJhc3NpZ24iIG1lc3NhZ2UgYW5kIGRvZXMgbG9jYWwgcHJvY2Vzc2luZyBhcw0KICAgICAg IGRlc2NyaWJlZCBpbiB0aGUgcHJldmlvdXMgc2VjdGlvbi4gSWYgdGhlIGNhbGwgY2FuIGJlIGFj Y2VwdGVkDQogICAgICAgdGhlbiB0aGUgbG9jYWwgTXV4IGNvbnRyb2xsZXIgdXBkYXRlcyBpdHMg bG9jYWwgQ0lEIHRhYmxlIGFuZA0KICAgICAgIHJlcGxpZXMgd2l0aCBhbiAiYXNzaWduX2NvbmZp cm0iIG1lc3NhZ2UuIElmIHRoZSByZW1vdGUgZ2F0ZXdheQ0KICAgICAgIGV4cGVyaWVuY2VzIGEg cHJvYmxlbSBpbiBhbGxvY2F0aW5nIHRoZSBjb25uZWN0aW9uLCBzYXkgZHVlIHRvIA0KICAgICAg IENJRCBjb2xsaXNpb24sIHRoZW4gaXQgdHJhbnNtaXRzIGEgInJlamVjdCIgbWVzc2FnZS4gVXBv biByZWNlaS0NCiAgICAgICB2aW5nIHRoZSAiYXNzaWduX2NvbmZpcm0iIG1lc3NhZ2UsIHRoZSBs b2NhbCBNdXggY29udHJvbGxlcg0KICAgICAgIGNvbmZpcm1zIHRoZSBDSUQgYXNzaWdubWVudCBi eSB1cGRhdGluZyB0aGUgQ0lEIHRhYmxlIGFuZCBub3RpLQ0KICAgICAgIGZ5aW5nIHRoZSBsb2Nh bCB1c2VyLiANCg0KDQpCLiBTdWJiaWFoLCBTLiBTZW5nb2RhbiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAg ICAgICAgIAkJICAgICAgICAgICAgICAgQXVnIDE1LCAxOTk4DQoNCg0KDQoNCgkJKysrKysrKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAJKysrKysrKyAgICAgICAgDQoJCSsgICAgICsgICAg ICAgICBBc3NpZ24gICAgICAgICAgCSsgICAgICsNCgkJKyAgICAgKyAgICAgLS0tLS0tLS0tLS0t LS0tLT4gICAgCSsgICAgICsNCgkJKyBHVzEgKyAgICAgIEFzc2lnbl9jb25maXJtCQkrIEdXMiAr DQoJCSsgICAgICsgICAgPC0tLS0tLS0tLS0tLS0tLS0tLQkgICAgICAgICsgICAgICsNCgkJKyAg ICAgKyAJCQkJKyAgICAgKw0KCQkrKysrKysrICAgCQkJCSsrKysrKysNCgkJCSAgDQoJCQkgRmln dXJlIDQ6IENOUCBDb25maXJtIHNlcXVlbmNlDQoNCg0KCQkrKysrKysrICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAkrKysrKysrICAgICAgICANCgkJKyAgICAgKyAgICAgICAgIEFzc2lnbiAg ICAgICAgICAJKyAgICAgKw0KCQkrICAgICArICAgICAtLS0tLS0tLS0tLS0tLS0tPiAgICAJKyAg ICAgKw0KCQkrIEdXMSArICAgICAgICAgUmVqZWN0CQkJKyBHVzIgKw0KCQkrICAgICArICAgIDwt LS0tLS0tLS0tLS0tLS0tLS0JICAgICAgICArICAgICArDQoJCSsgICAgICsgCQkJCSsgICAgICsN CgkJKysrKysrKyAgIAkJCQkrKysrKysrDQoJCQkgIA0KCQkJIEZpZ3VyZSA1OiBDTlAgUmVqZWN0 IHNlcXVlbmNlDQoNCg0KMy40IFVzZSBvZiBILjIyNS9ILjI0NSBmb3IgY2hhbm5lbCBuZWdvdGlh dGlvbg0KDQoJICAgIAkJCQkJCQkgDQoJCQkrKysrKysrKysJCSAgICArKysrKysrKysrKw0KCSsr KysrKysrKwkrCSstLS0tLS0gSC4yMjUgLS0tLS0tKwkgICAgICArICAgICArKysrKysrKw0KCSsJ KwkrIAkrLS0tLS0tIEguMjQ1IC0tLS0tLSsJICAgICAgKwkgICAgKwkgICArCQ0KCSsgUFNUTiAg KysrKysJKyAgICAJKwkgICAgICAJICAgICsJICAgICAgKysrKysrKyBQU1ROICsNCgkrKysrKysr KysJKyBJUCBHVyArLS0tICBJUCBORVRXT1JLIC0tLSsgSVAgR1cgICArCSAgICArKysrKysrKw0K CQkJKwkrICAgIAkgCSAgICArCSAgICAgICsNCgkJCSsgCSstLSBVRFAgY2hhbm5lbCAxIC0tKwkg ICAgICArDQoJKysrKysrKysrCSsJKy0tIFVEUCBjaGFubmVsIG4gLS0rCSAgICAgICsJICAgICsr KysrKysrKw0KCSsJKyArKysrCSsrKysrKysrKwkJICAgICArKysrKysrKysrKysrKysrICAgICAg ICsNCgkrIEdTTQkrCQkJCQkJICAgICsgR1NNICAgKw0KCSsrKysrKysrKwkJCQkJCSAgICArKysr KysrKysNCg0KCQlGaWd1cmUgNjogSC4yMjUvSC4yNDUgaW4gYW4gSVAgdGVsZXBob255IGdhdGV3 YXkgDQoNCg0KICAgSVRVLVQgaGFzIHN0YW5kYXJkaXplZCBILjIyNVs1XSBhbmQgSC4yNDVbNl0g YXMgdGhlIGNhbGwgc2lnbmFsaW5nIA0KICAgcHJvdG9jb2wgYW5kIGNhbGwgY29udHJvbCBwcm90 b2NvbCByZXNwZWN0aXZlbHkgdG8gYmUgdXNlZCB3aXRoaW4gDQogICB0aGUgSVRVLVQgc3RhbmRh cmQgSC4zMjNbN10uIEguMjI1IGFuZCBILjI0NSBtYXkgYmUgdXNlZCBmb3IgDQogICBzaWduYWxp bmcgYW5kIGNvbnRyb2wgcHVycG9zZXMgYmV0d2VlbiB0aGUgZ2F0ZXdheXMuIFdoZW4gdGhpcyBp cyB0aGUNCiAgIGNhc2UsIHBlcnNpc3RlbnQgSC4yMjUgYW5kIEguMjQ1IGNvbm5lY3Rpb25zIGV4 aXN0IGJldHdlZW4gYSBwYWlyIG9mDQogICBnYXRld2F5cy4gQWxsIHZvaWNlIGNvbm5lY3Rpb25z IGJldHdlZW4gdGhlIHR3byBnYXRld2F5cyBzaG91bGQgdXNlIA0KICAgdGhlIHNhbWUgSC4yMjUg YW5kIEguMjQ1IGNvbm5lY3Rpb24gZm9yIGNhbGwgc2lnbmFsaW5nIGFuZCBjYWxsIA0KICAgY29u dHJvbCBwdXJwb3Nlcy4NCg0KDQoNCkIuIFN1YmJpYWgsIFMuIFNlbmdvZGFuICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCVtQYWdlIDhdDQoNCg0KSW50ZXJuZXQgRHJhZnQgCQkJ CQkJCSAgQXVnIDE1LCAxOTk4DQoNDQoNCiAgIFdoZW4gYSBuZXcgY2FsbCBhcnJpdmVzIGF0IGEg Z2F0ZXdheSBmcm9tIHRoZSBjaXJjdWl0IHN3aXRjaGVkIHNpZGUgDQogICAoUFNUTi9HU00pLCBh IFNFVFVQIG1lc3NhZ2UgaXMgdHJhbnNtaXR0ZWQgZnJvbSB0aGUgaW5pdGlhdGluZyANCiAgIGdh dGV3YXkgdG8gdGhlIHRlcm1pbmF0aW5nIGdhdGV3YXkgb24gdGhlIHBlcnNpc3RlbnQgVENQIGNh bGwtc2lnbmEtDQogICBsaW5nIGNoYW5uZWwgKEguMjI1IGNoYW5uZWwpLiBUaGUgVXNlci1Vc2Vy LUluZm9ybWF0aW9uLUVsZW1lbnQgDQogICAoVVVJRSkgb2YgdGhlIFNFVFVQIG1lc3NhZ2UgaW5j bHVkZXMgdGhlIHBhcmFtZXRlcnMgdGhhdCBhcmUgbmVlZGVkDQogICBmb3IgY29ubmVjdGlvbiBz ZXR1cCBhcyBpbmRpY2F0ZWQgaW4gdGhlIEguMjI1IGRvY3VtZW50IFs5XS4gDQoNCiAgIEZvciB0 aGUgcHVycG9zZSBvZiB1c2VyIG11bHRpcGxleGluZyBiZXR3ZWVuIGdhdGV3YXlzLCB0aGUgc2V0 dGluZyBvZg0KICAgdGhlIFVVSUUgZmllbGRzIGluIHRoZSBTRVRVUCBtZXNzYWdlIE1VU1QgYmUg YXMgZm9sbG93czoNCg0KICAgICAtIGgyNDVBZGRyZXNzOiBUaGlzIGZpZWxkIGlzIHNldCB0byB0 aGUgVFNBUCBhZGRyZXNzIG9mIHRoZSBjYWxsIA0KICAgICAgIGNvbnRyb2wgVENQIGNoYW5uZWwg KEguMjQ1IGNoYW5uZWwpIGF0IHRoZSBpbml0aWF0aW5nIGdhdGV3YXkgDQogICAgICAgdGhhdCB3 aWxsIGJlIHVzZWQgZm9yIGNhbGwgY29udHJvbCBwdXJwb3NlcyBvZiB0aGlzIHZvaWNlIHN0cmVh bS4NCiAgICAgICBJbml0aWF0aW5nIGdhdGV3YXlzIHNob3VsZCB1c2UgdGhlIHNhbWUgY2FsbCBj b250cm9sIGNoYW5uZWwgZm9yIA0KICAgICAgIGFsbCB2b2ljZSBzdHJlYW1zLiBIb3dldmVyLCB0 aGUgaW5pdGlhdGluZyBnYXRld2F5IG1heSB3aXNoIHRvIA0KICAgICAgIG9wZW4gYSBuZXcgY2Fs bCBjb250cm9sIGNoYW5uZWwgd2hlbiB0aGUgbnVtYmVyIG9mIHZvaWNlIHN0cmVhbXMNCiAgICAg ICB1c2luZyB0aGUgc2FtZSBjb250cm9sIGNoYW5uZWwgZXhjZWVkcyBhIGNlcnRhaW4gdGhyZXNo b2xkIHZhbHVlLg0KICAgICAgIFdoZW4gdGhlIGluaXRpYXRpbmcgZ2F0ZXdheSB3aXNoZXMgdG8g dXNlIGEgbmV3IGNhbGwgY29udHJvbCANCiAgICAgICBjaGFubmVsLCB0aGUgVFNBUCBhZGRyZXNz IG9mIHRoZSBuZXcgSC4yNDUgY2hhbm5lbCBpcyBpbmNsdWRlZCANCiAgICAgICBpbiB0aGlzIGZp ZWxkLg0KDQogICBJZiB0aGUgcmVtb3RlIGdhdGV3YXkgcmVzcG9uZHMgd2l0aCBhIENPTk5FQ1Qg bWVzc2FnZSB1cG9uIHJlY2VpdmluZw0KICAgdGhlIFNFVFVQIG1lc3NhZ2UsIHRoZSBVVUlFIGZp ZWxkcyB3aXRoaW4gdGhlIENPTk5FQ1QgbWVzc2FnZSBNVVNUDQogICBiZSBzZXQgYXMgZm9sbG93 czoNCg0KICAgICAtIGgyNDVBZGRyZXNzOiBUaGlzIGZpZWxkIGlzIHNldCB0byB0aGUgVFNBUCBh ZGRyZXNzIG9mIHRoZSBjYWxsIA0KICAgICAgIGNvbnRyb2wgVENQIGNoYW5uZWwgKEguMjQ1IGNo YW5uZWwpIGF0IHRoZSByZXNwb25kaW5nIGdhdGV3YXkgDQogICAgICAgdGhhdCB3aWxsIGJlIHVz ZWQgZm9yIGNhbGwgY29udHJvbCBwdXJwb3NlcyBvZiB0aGlzIHZvaWNlIHN0cmVhbS4NCiAgICAg ICBSZW1vdGUgZ2F0ZXdheXMgc2hvdWxkIHVzZSB0aGUgc2FtZSBjYWxsIGNvbnRyb2wgY2hhbm5l bCBmb3IgYWxsIA0KICAgICAgIHZvaWNlIHN0cmVhbXMgd2hlbiBhbiBpbml0aWF0aW5nIGdhdGV3 YXkgaGFzIHVzZWQgdGhlIHNhbWUNCiAgICAgICBleGlzdGluZyBjYWxsIGNvbnRyb2wgY2hhbm5l bC4gSWYgYSByZW1vdGUgZ2F0ZXdheSB3aXNoZXMgdG8gdXNlIA0KICAgICAgIGEgbmV3IGNhbGwg Y29udHJvbCBjaGFubmVsIHdoZW4gdGhlIGluaXRpYXRpbmcgZ2F0ZXdheSBoYXMgDQogICAgICAg aW5kaWNhdGVkIHRoZSB1c2Ugb2YgYW4gZXhpc3RpbmcgY2FsbCBjb250cm9sIGNoYW5uZWwgaW4g dGhlIA0KICAgICAgIFNFVFVQIG1lc3NhZ2UsIHRoZW4gdGhlIHJlbW90ZSBnYXRld2F5IG11c3Qg c2VuZCBhIEZBQ0lMSVRZIGFuZCANCiAgICAgICBhIFJFTEVBU0UgbWVzc2FnZS4gSG93ZXZlciwg aWYgYW4gaW5pdGlhdGluZyBnYXRld2F5IGhhcyBpbmRpYy0NCiAgICAgICBhdGVkIHRoZSB1c2Ug b2YgYSBuZXcgY2FsbCBjb250cm9sIGNoYW5uZWwsIHRoZW4gdGhlIHJlbW90ZQ0KICAgICAgIGdh dGV3YXkgbXVzdCB1c2UgYSBuZXcgY2FsbCBjb250cm9sIGNoYW5uZWwuIFRoZSBUU0FQIGFkZHJl c3Mgb2YNCiAgICAgICB0aGUgbmV3IGNhbGwgY29udHJvbCBUQ1AgY2hhbm5lbCBhdCB0aGUgcmVt b3RlIGdhdGV3YXkgaXMNCiAgICAgICBpbmNsdWRlZCBpbiB0aGlzIGZpZWxkLg0KDQogICBVcG9u IHJlY2VpdmluZyB0aGUgQ09OTkVDVCBtZXNzYWdlIGZyb20gdGhlIHJlbW90ZSBnYXRld2F5LCB0 aGUgY2FsbCANCiAgIGNvbnRyb2wgcGhhc2UgKEguMjQ1KSBiZWdpbnMuIFRoZSBjYXBhYmlsaXR5 IGV4Y2hhbmdlIG1lc3NhZ2VzIA0KICAgZGV0ZXJtaW5lIHRoZSBjaG9pY2Ugb2YgY29kZWNzIGFu ZCB0aGUgc2VjdXJpdHkgcGFyYW1ldGVycyBpZiBhbnkgdG8NCiAgIGJlIHVzZWQgYmV0d2VlbiB0 aGUgZ2F0ZXdheXMuIEluIGFkZGl0aW9uLCB0aGUgY2FwYWJpbGl0eSBleGNoYW5nZQ0KICAgYWxz byBpbmRpY2F0ZXMgdGhlIGNhcGFiaWxpdHkgZm9yIHBlcmZvcm1pbmcgbXVsdGlwbGV4aW5nLiBJ biB0aGUgDQogICBvcGVuTG9naWNhbENoYW5uZWwgKGFuZCBvcGVuTG9naWNhbENoYW5uZWxBY2sp IG1lc3NhZ2UsIGluIGFkZGl0aW9uDQogICB0byBpbmRpY2F0aW5nIHRoZSBUU0FQIGFkZHJlc3Ms IHRoZSBDSUQgaXMgYWxzbyBpbmRpY2F0ZWQuDQogICANCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29k YW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDldDQoNCg0KSW50 ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAgICAJCSAgICAgICAgICAgICAgIEF1ZyAxNSwgMTk5 OA0KDQoNCg0KCQkrKysrKysrICAgICAgICAgICAgICAgICAgICAgICAgICAgIAkrKysrKysrICAg ICAgICANCgkJKyAgICAgKyAgICAgICAgIFNFVFVQICAgICAgICAgIAkJKyAgICAgKw0KCQkrICAg ICArICAgICAtLS0tLS0tLS0tLS0tLS0tPiAgICAJKyAgICAgKw0KCQkrIEdXMSArICAgICAgICAg Q09OTkVDVAkJCSsgR1cyICsNCgkJKyAgICAgKyAgICA8LS0tLS0tLS0tLS0tLS0tLS0tCQkrICAg ICArDQoJCSsgICAgICsgCSAgQ2FwYWJpbGl0eVNldAkJKyAgICAgKyANCgkJKyAgICAgKyAgICAt LS0tLS0tLS0tLS0tLS0tLS0+CQkrICAgICArDQoJCSsgICAgICsJIENhcGFiaWxpdHlTZXRBY2sJ CSsgICAgICsNCgkJKyAgICAgKyAgICA8LS0tLS0tLS0tLS0tLS0tLS0tCQkrICAgICArDQoJCSsg ICAgICsJCU9MQwkJCSsgICAgICsNCgkJKyAgICAgKwkgICAtLS0tLS0tLS0tLS0tLS0tLS0+CQkr ICAgICArDQoJCSsgICAgICsJCU9MQ0FjawkJCSsgICAgICsNCgkJKyAgICAgKwkgICA8LS0tLS0t LS0tLS0tLS0tLS0tCQkrICAgICArDQoJCSsrKysrKysJCQkJCSsrKysrKysNCg0KCQkJIEZpZ3Vy ZSA3OiBILjIyNS9ILjI0NSBleGNoYW5nZSBzZXF1ZW5jZQ0KDQoNCg0KCQkrKysrKysrICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAkrKysrKysrICAgICAgICANCgkJKyAgICAgKyAgICAgICAg IFNFVFVQICAgICAgICAgIAkJKyAgICAgKw0KCQkrICAgICArICAgICAtLS0tLS0tLS0tLS0tLS0t PiAgICAJKyAgICAgKw0KCQkrIEdXMSArICAgICAgICAgRkFDSUxJVFkJCSsgR1cyICsNCgkJKyAg ICAgKwkgICAgPC0tLS0tLS0tLS0tLS0tLS0tLQkJKyAgICAgKw0KCQkrICAgICArIAkJUkVMRUFT RQkJKyAgICAgKw0KCQkrICAgICArCSAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLQkrICAgICArDQoJ CSsrKysrKysgICAJCQkJKysrKysrKw0KCQkJICANCgkJCSBGaWd1cmUgODogSC4yMjUgRmFjaWxp dHkvUmVqZWN0IHNlcXVlbmNlDQoNCg0KDQoNCkIuIFN1YmJpYWgsIFMuIFNlbmdvZGFuICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxMF0NCg0KDQpJbnRlcm5ldCBE cmFmdCAJCQkJCQkJICAgIEF1ZyAxNSwgMTk5OA0KDQoNCg0KDQozLjUgVXNlIG9mIFNJUCBmb3Ig Y2hhbm5lbCBuZWdvdGlhdGlvbg0KDQoNCgkrKysrKysrKysrKwkJCSAgICAgIAkJKysrKysrKysr KysrKysrKysNCgkrCSAgICArIC0tLSBwZXJzaXN0ZW50IFNJUCBjaGFubmVsIC0tIAkrCQkrDQoJ KyAJICAgICsJCQkJCSsJICAgICAJKwkNCgkrCSAgICArICAgIAkgCSAgICAgIAkJKwkgICAgIAkr DQoJKyBJUCBHVzEgICAgKwkJCQkJKyAgSVAgR1cyICAJKw0KCSsJICAgICsgICAgCSAJICAgICAg CQkrCSAgICAgCSsNCgkrIAkgICAgKyAgLS0tIGF1ZGlvIFVEUCBjaGFubmVsIDEgLS0tCSsgCSAg ICAgCSsNCgkrCSAgICArICAtLS0gYXVkaW8gVURQIGNoYW5uZWwgbiAtLS0JKwkgICAgIAkrDQoJ KysrKysrKysrKysJCQkgICAgICAJCSsrKysrKysrKysrKysrKysrDQoJCQkNCgkJRmlndXJlIDku IFNJUCBpbiBJUCB0ZWxlcGhvbnkgZ2F0ZXdheXMNCg0KDQoNDQoNCg0KICAgU2Vzc2lvbiBJbml0 aWF0aW9uIFByb3RvY29sIChTSVApIGNhbiBiZSB1c2VkIGFzIHRoZSBjb250cm9sIA0KICAgc2ln bmFsaW5nIHByb3RvY29sIGJldHdlZW4gdGhlIHR3byBnYXRld2F5cyBbMTFdLiBJbiB0aGlzIGNh c2UsIA0KICAgdGhlIGdhdGV3YXkgdGhhdCByZWNlaXZlcyBhIGNhbGwgZnJvbSB0aGUgY2lyY3Vp dCBzd2l0Y2hlZCBzaWRlIA0KICAgaXMgdGhlIFNJUCBjbGllbnQsIHdoaWxlIHRoZSByZW1vdGUg Z2F0ZXdheSBpcyB0aGUgU0lQIHNlcnZlci4gDQogICBUaGUgc2VyaWVzIG9mIG1lc3NhZ2VzIHRo YXQgYXJlIGV4Y2hhbmdlZCBhcmUgZGVzY3JpYmVkIGJlbG93LiANCiAgIFRoZXNlIG1lc3NhZ2Vz IGFyZSBleGNoYW5nZWQgb24gdGhlIHBlcnNpc3RlbnQgc2lnbmFsaW5nIGNvbm5lY3Rpb24gDQog ICBleGlzdGluZyBiZXR3ZWVuIHRoZSB0d28gZ2F0ZXdheXMuIFN1Y2ggYSBwZXJzaXN0ZW50IGNv bm5lY3Rpb24gDQogICBtYXkgZWl0aGVyIGJlIFRDUCBvciBVRFAuDQoNCiAgIEFzIHdpdGggdGhl IGNhc2Ugb2YgSC4yMjUsIHRoZSBkZXNjcmlwdGlvbiBoZXJlIGlzIG5vdCBtZWFudCB0byBiZSAN CiAgIGV4aGF1c3RpdmUgYnV0IGlzIG1lcmVseSBmb3IgaWxsdXN0cmF0aW9uLiBJc3N1ZXMgc3Vj aCBhcyBsb2NhdGluZyANCiAgIHRoZSByZW1vdGUgZ2F0ZXdheSBieSB0aGUgdXNlIG9mIHByb3h5 IG9yIHJlZGlyZWN0IHNlcnZlcnMsIGFtb25nIA0KICAgb3RoZXIgdGhpbmdzLCBhcmUgbm90IGRp c2N1c3NlZCBoZXJlLg0KDQogICBXaGVuIGEgbmV3IGNhbGwgY29tZXMgaW50byB0aGUgaW5pdGlh dGluZyBnYXRld2F5IGZyb20gdGhlIGNpcmN1aXQgDQogICBzd2l0Y2hlZCBzaWRlLCBhbiBJTlZJ VEUgbWVzc2FnZSBpcyBzZW50IGZyb20gdGhlIGNhbGxpbmcgZ2F0ZXdheSANCiAgIChTSVAgY2xp ZW50KSB0byB0aGUgY2FsbGVkIGdhdGV3YXkgKFNJUCBzZXJ2ZXIpLiBUaGUgZmllbGRzIG9mIHRo ZQ0KICAgSU5WSVRFIG1lc3NhZ2UgYXJlIHNldCBhcyBmb2xsb3dzOg0KDQogICAgIC0gUmVxdWVz dC1VUkk6IFRoaXMgZmllbGQgY29udGFpbnMgc2lwOnBob25lbnVtYmVyQHJlbW90ZWdhdGV3YXku IA0KICAgICAgIEZvciBpbnN0YW5jZSwgaWYgdGhlIG51bWJlciBiZWluZyBjYWxsZWQgaXMgKzEt NzgxLTM1OS01MTEyIGFuZCANCiAgICAgICB0aGUgcmVtb3RlIGdhdGV3YXkgdGhhdCBjYW4gaGFu ZGxlIHRoaXMgY2FsbCBpcyANCiAgICAgICBndzEtYm9zdG9uLnJlc2VhcmNoLm5va2lhLmNvbSwg dGhlbiB0aGUgUmVxdWVzdC1VUkkgaGFzIGEgdmFsdWUgDQogICAgICAgc2lwOisxLTc4MS0zNTkt NTExMkBndzEtYm9zdG9uLnJlc2VhcmNoLm5va2lhLmNvbS4NCg0KICAgICAtIFNlc3Npb24gRGVz Y3JpcHRpb246IFRoZSBzZXNzaW9uIGRlc2NyaXB0aW9uIGluY2x1ZGVzIHRoZSANCiAgICAgICBj YXBhYmlsaXR5IG9mIHRoZSBpbml0aWF0aW5nIGdhdGV3YXkgd2l0aCByZWdhcmQgdG8gc3VwcG9y dGVkIA0KICAgICAgIGNvZGVjcywgc3VwcG9ydGVkIHNlY3VyaXR5IHBhcmFtZXRlcnMgZXRjLiBB bHNvIGluY2x1ZGVkIGluIHRoZSANCiAgICAgICBzZXNzaW9uIGRlc2NyaXB0aW9uIGlzIHRoZSBD aGFubmVsIElkZW50aWZpZXIgKENJRCksIHRoZSBzb3VyY2UgDQogICAgICAgVURQIHBvcnQgYW5k IHRoZSBkZXN0aW5hdGlvbiBVRFAgcG9ydC4NCg0KICAgVXBvbiByZWNlaXZpbmcgdGhlIElOVklU RSBtZXNzYWdlLCB0aGUgcmVtb3RlIGdhdGV3YXkgcmV0dXJucyB0aGUgDQogICBmb2xsb3dpbmcg bWVzc2FnZXMgaW4gdGhlIHNlcXVlbmNlIGluZGljYXRlZDoNCg0KICAgICAtIFRSWUlORzogVGhp cyBtZXNzYWdlIGluZGljYXRlcyB0byB0aGUgY2FsbGluZyBnYXRld2F5IHRoYXQgdGhlIA0KICAg ICAgIHJlbW90ZSBnYXRld2F5IGhhcyByZWNlaXZlZCB0aGUgSU5WSVRFIG1lc3NhZ2Ugc3VjY2Vz c2Z1bGx5IGFuZCANCiAgICAgICB0aGF0IHRoZSByZW1vdGUgZ2F0ZXdheSBpcyB0cnlpbmcgdG8g ZXN0YWJsaXNoIGNvbnRhY3Qgd2l0aCB0aGUgDQogICAgICAgdXNlci4gVGhpcyBpcyBhbHNvIGFu IGluZGljYXRpb24gdG8gdGhlIGluaXRpYXRpbmcgZ2F0ZXdheSBub3QgDQogICAgICAgdG8gcmV0 cmFuc21pdCB0aGUgSU5WSVRFIG1lc3NhZ2UuDQoNCiAgICAgLSBSSU5HSU5HOiBUaGlzIG1lc3Nh Z2UgaW5kaWNhdGVzIHRoYXQgdGhlIHVzZXIgaGFzIGJlZW4gY29udGFjdGVkDQogICAgICAgYW5k IHRoYXQgaGlzIHBob25lIGlzIHJpbmdpbmcuDQoNCiAgICAgLSBTVUNDRVNTOiBUaGlzIG1lc3Nh Z2UgaW5kaWNhdGVzIHRoYXQgdGhlIHVzZXIgaGFzIGFuc3dlcmVkIGhpcyANCiAgICAgICBwaG9u ZS4NCg0KICAgVGhlIFNVQ0NFU1MgbWVzc2FnZSBpcyBzZW50IGJ5IHRoZSByZW1vdGUgZ2F0ZXdh eSBvbmx5IGlmIHRoZSBDSUQNCiAgIHZhbHVlIGluZGljYXRlZCBpbiB0aGUgSU5WSVRFIG1lc3Nh Z2UgaXMgYWNjZXB0YWJsZSB0byB0aGUgcmVtb3RlDQogICBnYXRld2F5LiBVcG9uIHJlY2Vpdmlu ZyB0aGUgU1VDQ0VTUyBtZXNzYWdlLCB0aGUgaW5pdGlhdGluZyBnYXRld2F5DQogICByZXR1cm5z IGFuIEFDSyBtZXNzYWdlIGJhY2sgdG8gdGhlIHJlbW90ZSBnYXRld2F5LiBUaGlzIGlzIGlsbHVz dC0NCiAgIHJhdGVkIGluIEZpZ3VyZSAxMC4NCg0KICAgSWYgdGhlIENJRCBpbmRpY2F0ZWQgaW4g dGhlIElOVklURSBtZXNzYWdlIGlzIG5vdCBhIHZhbGlkIG9uZSwgdGhlDQogICByZW1vdGUgZ2F0 ZXdheSByZXR1cm5zIGFuIEVSUk9SL0ZBSUxVUkUgbWVzc2FnZSBiYWNrIHRvIHRoZSBpbml0aWEt DQogICB0aW5nIGdhdGV3YXkgYXMgaW5kaWNhdGVkIGluIEZpZ3VyZSAxMS4NCg0KDQoNCg0KDQoN Cg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDExXQ0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgCQkg ICAgICAgICAgICAgICAgQXVnIDE1LCAxOTk4DQoNCg0KDQoNCgkJKysrKysrKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAJKysrKysrKyAgICAgICAgDQoJCSsgICAgICsgICAgICAgICBJTlZJ VEUgICAgICAgICAgCSsgICAgICsNCgkJKyAgICAgKyAgICAgLS0tLS0tLS0tLS0tLS0tLT4gICAg CSsgICAgICsNCgkJKyBHVzEgKyAgICAgICAgIFRSWUlORwkJCSsgR1cyICsNCgkJKyAgICAgKyAg ICA8LS0tLS0tLS0tLS0tLS0tLS0tCSAgICAgICAgKyAgICAgKw0KCQkrICAgICArIAkgICAgUklO R0lORwkJKyAgICAgKw0KCQkrICAgICArICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0JICAgICAgICAr ICAgICArDQoJCSsgICAgICsJICAgIFNVQ0NFU1MJCQkrICAgICArDQoJCSsgICAgICsgICAgPC0t LS0tLS0tLS0tLS0tLS0tLQkgICAgICAgICsgICAgICsNCgkJKyAgICAgKwkJQUNLCQkJKyAgICAg Kw0KCQkrICAgICArCSAgICAgIC0tLS0tLS0tLS0tLS0tLS0+CQkrICAgICArDQoJCSsrKysrKysJ CQkJCSsrKysrKysNCg0KDQoJCQkgRmlndXJlIDEwOiBTSVAgQ29uZmlybSBzZXF1ZW5jZQ0KDQoN Cg0KCQkrKysrKysrICAgICAgICAgICAgICAgICAgICAgICAgICAgIAkrKysrKysrICAgICAgICAN CgkJKyAgICAgKyAgICAgICAgIElOVklURSAgICAgICAgICAJKyAgICAgKw0KCQkrICAgICArICAg ICAtLS0tLS0tLS0tLS0tLS0tPiAgICAJKyAgICAgKw0KCQkrIEdXMSArICAgICAgRVJST1IvRkFJ TFVSRSAgIAkJKyBHVzIgKw0KCQkrICAgICArICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0JCSsgICAg ICsNCgkJKysrKysrKyAgIAkJCQkrKysrKysrDQoJCQkgIA0KCQkJIEZpZ3VyZSAxMTogU0lQIFJl amVjdCBzZXF1ZW5jZQ0KDQoNCjQgVHJhbnNtaXNzaW9uIGVycm9ycyBhbmQgcGFja2V0IGxvc3Mg DQoNCiAgIFByb3RvY29scyBzdWNoIGFzIEFUTSwgSVAgYW5kIEFBTDIgc3BlY2lmeSBhIEhlYWRl ciBFcnJvciBDb3JyZWN0aW9uDQogICAoSEVDKSB0byBkZXRlY3QgZXJyb3JzIGluIHRoZSBoZWFk ZXJzLCB3aGVyZWFzIFVEUCBvZmZlcnMgYm90aCBoZWFkZXINCiAgIGFuZCBwYXlsb2FkIHByb3Rl Y3Rpb24uIFRoZSBVRFAgY2hlY2tzdW0gZmllbGQgaW4gdGhlIFVEUCBoZWFkZXIgaXMNCiAgIGNh bGN1bGF0ZWQgZm9yIHRoZSBlbnRpcmUgVURQIHBhY2tldCBpbmNsdWRpbmcgdGhlIGhlYWRlciBh bmQgcGF5bG9hZA0KICAgYnl0ZXMuIFRoZSBNSU5JLWhlYWRlciB1c2VkIGZvciB1c2VyIG11bHRp cGxleGluZyBpcyAyIGJ5dGUgbG9uZyBhbmQgDQogICBkb2VzIG5vdCBoYXZlIGFueSBIRUMgZmll bGQuIFRoZSByZWFzb24gaXMgdGhhdCB0aGUgbWluaSBwYWNrZXRzIGFyZQ0KICAgZW5jYXBzdWxh dGVkIHdpdGhpbiBhIFVEUCBwYXlsb2FkIHRodXMgcHJvdGVjdGVkIGJ5IHRoZSBVRFAgY2hlY2tz dW0uDQogICBUaGUgcHJlc2VuY2Ugb2YgdGhlIFJUUCBzZXF1ZW5jZSBudW1iZXIgaW4gdGhlIFJU UCBoZWFkZXIgZmFjaWxpdGF0ZXMNCiAgIHRvIGlkZW50aWZ5IHBhY2tldCBsb3NzZXMgYXQgdGhl IFJUUCBsZXZlbC4gU2luY2UgZWFjaCBSVFAgcGFja2V0DQogICBjb250YWlucyBhIG51bWJlciBv ZiBtaW5pIHBhY2tldHMsIHBhY2tldCBsb3NzIGF0IGluZGl2aWR1YWwgbGV2ZWwgDQogICBiZWNv bWVzIGRpZmZpY3VsdC4gSG93ZXZlciwgaXQgaXMgb3VyIHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUg U04gZm9yIA0KICAgaW5kaXZpZHVhbCBtaW5pIHBhY2tldCBpcyBub3QgbmVjZXNzYXJ5LiANCg0K NSBBcHBsaWNhdGlvbiBzY2VuYXJpb3MNCg0KICAgU29tZSBvZiB0aGUgbW9zdCBvYnZpb3VzIHNj ZW5hcmlvcywgaW4gd2hpY2ggdGhlIHByb3Bvc2VkIG1ldGhvZCBpcyANCiAgIGJlbmVmaWNpYWws IGFyZSBzaG93biBpbiBGaWd1cmUgMTIuIFRyYWRpdGlvbmFsIHRlbGVwaG9ueSBzeXN0ZW0gc3Vj aCANCiAgIGFzIFBTVE4gaW50ZXJjb25uZWN0ZWQgYnkgSVAgdGVsZXBob255IGdhdGV3YXlzIGlz IGFuIGlkZWFsIHNjZW5hcmlvIA0KICAgd2hlcmUgdXNlciBtdXggbWV0aG9kIGltcHJvdmVzIHRo ZSBiYW5kd2lkdGggZWZmaWNpZW5jeSBpbiB0aGUgSVANCg0KDQoNCg0KQi4gU3ViYmlhaCwgUy4g U2VuZ29kYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0K DQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgCQkgICAgICAgICAgICAgICAgQXVn IDE1LCAxOTk4DQ0KDQoNCiAgIG5ldHdvcmsuIFRoaXMgbWV0aG9kIGNhbiBhbHNvIGJlIHVzZWQg aW4gdGhlIFJhZGlvIEFjY2VzcyBOZXR3b3JrIA0KICAgKFJBTikgb2YgYSBjZWxsdWxhciBuZXR3 b3JrLiBJbiBjZWxsdWxhciB0cnVua2luZywgbXV4IGNvbnRyb2xsZXIgDQogICBpcyBhIHBhcnQg b2YgdGhlIEJTIGFuZCBCU0MvTVNDIGNvbm5lY3RlZCBieSBJUCBuZXR3b3Jrcy4gVXNlciANCiAg IGFnZ3JlZ2F0aW9uIGNhbiBiZSBhcHBsaWVkIGJldHdlZW4gQlRTIGFuZCBCU0MgYXMgd2VsbCBh cyBiZXR3ZWVuDQogICBCU0MgYW5kIE1TQy4gDQoNCg0KCSsrKysrKysrKysJCQkJCSAgICAgICAg ICAgICsrKysrKysrDQoJKwkgKwkJCQkJICAgICAgICAgICAgKwkgICArDQogIAkrIFBTVE4gICAr CQkJCQkgICAgICAgICAgICArIFBTVE4gKw0KCSsrKysrKysrKysJCQkJCSAgICAgICAgICsgICsr KysrKysrDQoJCSAgICArCQkJCQkJKw0KCQkJKysrKysrKysrKysJCSAgICAgICsrKysrKysrKw0K CQkJKyAJICArCQkgICAgICArCSAgICAgICsJDQoJCSAgCSsJICArICAgIAkgCSAgICAgICsJICAg ICAgKw0KCQkJKyBJUCBHVyArKysrKysgIElQIE5FVFdPUksgKysrKyBJUCBHVyArDQoJCQkrCSAg KyAgICAJIAkgICAgICArCSAgICAgICsNCgkJICAgICsJKyAJICArCQkgICAgICArICAgICAgICsN CgkrKysrKysrKysrKyAJKwkgICsJIAkgICAgICArCSAgICAgICsJICAgICsrKysrKysNCgkrCSAg KyAJKysrKysrKysrKysJCSAgICAgICsrKysrKysrKyArKysrKyAgICAgKw0KCSsgR1NNCSAgKwkJ CQkJCSAgICArIEdTTSArDQoJKysrKysrKysrKysJCQkJCQkgICAgKysrKysrKw0KDQoNCgkJRmln dXJlIDEyLiBBcHBsaWNhdGlvbiBzY2VuYXJpbyBvZiBVc2VyIG11eCBpbiBSVFANCg0KDQo2IFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoZXJlIGFyZSBubyBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBiZXlvbmQgdGhvc2UgYWRkcmVzc2VkIGluIFJUUA0KICAgaXRzZWxmLiBUaGUgbXVs dGlwbGV4aW5nIHByb3RvY29sIGNhbiBtYWtlIHVzZSBvZiB3aGF0ZXZlciBlbmNyeXB0aW9uDQog ICBhbmQgYXV0aGVudGljYXRpb24gc2NoZW1lcyBhcmUgcHJlc2VudCBpbiBSVFAsIFNJUCwgSC4z MjMgb3Igb3RoZXIgDQogICByZWxldmFudCBwcm90b2NvbHMuIEZvciBpbnN0YW5jZSwgdGhlIG11 bHRpcGxleGVkIG1lZGlhIHN0cmVhbSBjb3VsZCANCiAgIGJlIHNlY3VyZWQgYnkgc2VjdXJpbmcg dGhlIFVEUCBwb3J0cyB1c2luZyBJUFNFQy4gVGhlIHNpZ25hbGluZyBhbmQNCiAgIGNvbnRyb2wg Y2hhbm5lbHMgY291bGQgYmUgc2VjdXJlZCBlaXRoZXIgYnkgdGhlIHVzZSBvZiBJUFNFQyBvciBU TFMuIA0KICAgQXBwbGljYXRpb24gbGV2ZWwgc2VjdXJpdHkgYXMgc3BlY2lmaWVkIGluIFNJUCBh bmQgSC4yMzUgbWF5IGFsc28gYmUgDQogICBpbmNvcnBvcmF0ZWQuDQoNCjcgQ29tcGFyaXNvbiBv ZiBVc2VyIG11eCBpbiBSVFAgYW5kIHRyYWRpdGlvbmFsIFJUUC9VRFAvSVANCg0KICAgVGhlIGlt cG9ydGFudCByZWFzb24gZm9yIG11bHRpcGxleGluZyBzbWFsbCBzaXplIHBhY2tldHMgaW50byBh IA0KICAgc2luZ2xlIFJUUCBwYXlsb2FkIGlzIHRoYXQgdGhlIFJUUC9VRFAvSVAgb3ZlcmhlYWQg Zm9yIGVhY2ggcGFja2V0IA0KICAgY2FuIGJlIHJlZHVjZWQuIEZvciBleGFtcGxlLCB0aGUgUlRQ L1VEUC9JUCBvdmVyaGVhZCBpcyA2Ni43JSBpbiBjYXNlDQogICBvZiAyMCBieXRlIEcuNzIzLjEg cGFja2V0IGFuZCA4MCUgZm9yIGEgMTAgYnl0ZSBHLjcyOSBwYWNrZXQuIA0KICAgQ29uc2lkZXJp bmcgdGhhdCBJUCB0ZWxlcGhvbnkgZ2F0ZXdheXMgdHJhbnNmZXIgMTAwcyBvZiB1c2VyIGF0IGFu eSANCiAgIGdpdmVuIHRpbWUsIHRoZSB0b3RhbCBiYW5kd2lkdGggcmVxdWlyZW1lbnQgaW5jbHVk aW5nIHRoZSBvdmVyaGVhZCANCiAgIGlzIHZlcnkgaGlnaC4gVGhlIGJhbmR3aWR0aCByZXF1aXJl bWVudCBmb3IgYSB0cmFkaXRpb25hbCBzY2hlbWUgDQogICAoUlRQL1VEUC9JUCkgaXMgY29tcGFy ZWQgdG8gdXNlciBtdXggaW4gUlRQIGFuZCB0aGUgcmVzdWx0cyBhcmUgc2hvd24NCiAgIGluIFRh YmxlIDIuIFRoZSByZXN1bHRzIGluZGljYXRlIHRoYXQgdGhlIGJhbmR3aWR0aCByZXF1aXJlbWVu dCB0byANCiAgIHRyYW5zcG9ydCBzYW1lIG51bWJlciBvZiB1c2VycyB0aHJvdWdoIHVzZXIgbXV4 IGlzIHZlcnkgbG93IGNvbXBhcmVkIA0KICAgdG8gdGhlIHRyYWRpdGlvbmFsIElQIHRlbGVwaG9u eSAoUlRQL1VEUC9JUCkgbWV0aG9kLg0KDQoNCg0KDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29k YW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDEzXQ0KDQoNCklu dGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgCQkgICAgICAgICAgICAgICAgQXVnIDE1LCAx OTk4DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQojIHVzZXJzICAgICAgTm8gTXV4ICAgICAgICAgICBVc2Vy IE11eCAgICAgICAgTm8gTXV4CSAgICBVc2VyTXV4DQoJICAgIChHLjcyMy4xKQkgICAgIChHLjcy My4xKSAgICAgICAgKEcuNzI5KSAgICAgICAoRy43MjkpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCjEwCQkxNTkJ CTY4LjkJCTQwMAkJMTI4DQozMAkJNDc3CQkxODUuNQkJMTIwMAkJMzIwDQo1MAkJNzk1CQkzMDIu MQkJMjAwMAkJNTEyDQo3MAkJMTExMwkJNDE4LjcJCTI4MDAJCTcwNA0KOTAJCTE0MzEJCTUzNS4z CQkzNjAwCQk4OTYNCjExMAkJMTc0OQkJNjUxLjkJCTQ0MDAJCTEwODgNCjEzMAkJMjA2NwkJNzY4 LjUJCTUyMDAJCTEyODANCjE1MAkJMjM4NQkJODg1LjEJCTYwMDAJCTE0NzINCjE3MAkJMjcwMwkJ MTAwMS43CSAgICAgICAgNjgwMAkJMTY2NA0KMTkwCQkzMDIxCQkxMTE4LjMJICAgICAgICA3NjAw CQkxODU2DQoyMTAJCTMzMzkJCTEyMzQuOQkgICAgICAgIDg0MDAJCTIwNDgNCjIzMAkJMzY1NwkJ MTM1MS41CSAgICAgICAgOTIwMAkJMjI0MA0KMjUwCQkzOTc1CQkxNDY4LjEJICAgICAgICAxMDAw MAkJMjQzMg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUYWJsZSAyLiBCYW5kd2lkdGggcmVxdWlyZW1lbnRz IGluIEticHMgZm9yIHVzZXIgbXV4IGFuZCBJUCBtZXRob2RzDQoNCg0KICAgQSBjb21wYXJpc29u IG9mIHBlcmNlbnRhZ2Ugb3ZlcmhlYWQgZm9yIHR3byBkaWZmZXJlbnQgc3BlZWNoIGNvZGVjcw0K ICAgaXMgc2hvd24gaW4gVGFibGUgMy4gVGhlIG92ZXJoZWFkIGR1ZSB0byBSVFAvVURQL0lQIGlz IGNvbnN0YW50IGZvciANCiAgIGJvdGggY29kZWNzLiBVc2VyIG11eCBpbiBSVFAgbWV0aG9kIGlz IGFibGUgdG8gbXVsdGlwbGV4IHNtYWxsIA0KICAgcGFja2V0cyBpbnRvIGEgc2luZ2xlIFJUUC9V RFAvSVAgcGF5bG9hZCB0aHVzIHJlZHVjaW5nIHRoZSBvdmVyaGVhZCANCiAgIHRvIG1pbmltdW0u IFRoZSBvdmVyaGVhZCBjb21wYXJpc29uIG9uIGJvdGggY29kZWNzIHByb3ZlcyB0aGF0IHVzZXIg DQogICBtdXggaW4gUlRQIGlzIHZlcnkgZWZmaWNpZW50IGluIHJlZHVjaW5nIHRoZSBvdmVyaGVh ZC4gDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KI1VzZXJzCU11eChHLjcyOSkJSVAgKEcuNzI5KQlNdXgoRy43 MjMuMSkJSVAgKEcuNzIzLjEpDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoxMAkzNy41CQk4MAkJMjMuMDc2OTIzMDgJ NjYuNw0KMzAJMjUJCTgwCQkxNC4yODU3MTQyOQk2Ni43DQo1MAkyMS44NzUJCTgwCQkxMi4yODA3 MDE3NQk2Ni43DQo3MAkyMC40NTQ1NDU0NQk4MAkJMTEuMzkyNDA1MDYJNjYuNw0KOTAJMTkuNjQy ODU3MTQJODAJCTEwLjg5MTA4OTExCTY2LjcNCjExMAkxOS4xMTc2NDcwNgk4MAkJMTAuNTY5MTA1 NjkJNjYuNw0KMTMwCTE4Ljc1CQk4MAkJMTAuMzQ0ODI3NTkJNjYuNw0KMTUwCTE4LjQ3ODI2MDg3 CTgwCQkxMC4xNzk2NDA3Mgk2Ni43DQoxNzAJMTguMjY5MjMwNzcJODAJCTEwLjA1MjkxMDA1CTY2 LjcNCjE5MAkxOC4xMDM0NDgyOAk4MAkJOS45NTI2MDY2MzUJNjYuNw0KMjEwCTE3Ljk2ODc1CTgw CQk5Ljg3MTI0NDYzNQk2Ni43DQoyMzAJMTcuODU3MTQyODYJODAJCTkuODAzOTIxNTY5CTY2LjcN CjI1MAkxNy43NjMxNTc4OQk4MAkJOS43NDcyOTI0MTkJNjYuNw0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgIFRh YmxlIDMuIENvbXBhcmlzb24gb2YgJSBvdmVyaGVhZCBkdWUgdG8gSVAgYW5kIHVzZXIgbXV4IGlu IFJUUA0KDQoNCjggQWR2YW50YWdlcyBvZiB1c2VyIG11bHRpcGxleGluZyBpbiBSVFANCg0KICAg VGhlIGZpcnN0IGFkdmFudGFnZSBvZiB1c2luZyB0aGUgcHJvcG9zZWQgbWV0aG9kIGJldHdlZW4g SVAgdGVsZXBob255DQogICAgDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE0XQ0KDQoNCkludGVybmV0IERyYWZ0 ICAgICAgICAgICAgICAgICAgCQkgICAgICAgICAgICAgICAgQXVnIDE1LCAxOTk4DQoNCiAgIGdh dGV3YXlzIGlzIHRoZSBiYW5kd2lkdGggZWZmaWNpZW5jeS4gVGhlIHNlY29uZCBhZHZhbnRhZ2Ug b2Ygc2hhcmluZw0KICAgYSBzaW5nbGUgUlRQL1VEUC9JUCBpcyB0aGF0IHRoZSBudW1iZXIgb2Yg VURQIGNvbm5lY3Rpb25zIGlzIHJlZHVjZWQNCiAgIGJldHdlZW4gZ2F0ZXdheXMuIEZvciBleGFt cGxlLCBpbiB0aGUgcHJvcG9zZWQgdXNlciBtdWx0aXBsZXhpbmcgDQogICBtZXRob2QgYSBzaW5n bGUgVURQIGNvbm5lY3Rpb24gY2FuIGJlIHNoYXJlZCBieSBhIG1heGltdW0gb2YgMjU2IA0KICAg dXNlcnMuIFRoZSB0aGlyZCBhZHZhbnRhZ2UgaXMgdGhhdCB0aGUgbGVzcyBjaGFuY2VzIGZvciB0 cmFmZmljIA0KICAgY29uZ2VzdGlvbiBhdCBpbnRlcm1lZGlhdGUgSVAgcm91dGVycywgYmVjYXVz ZSB0aGUgcHJvcG9zZWQgbWV0aG9kIA0KICAgcmVkdWNlcyB0aGUgbnVtYmVyIG9mIElQIHBhY2tl dHMgYnkgbXVsdGlwbGV4aW5nIG1pbmkgcGFja2V0cyBpbiBhIA0KICAgc2luZ2xlIFJUUCBwYXls b2FkLiBEZXNwaXRlIHRoZSBtdWx0aXBsZXhpbmcgZWZmZWN0LCB1c2VyIG11bHRpcGxleC0NCiAg IGluZyBpbiBSVFAgZG9lcyBub3QgY2F1c2UgYW55IHByb2JsZW1zIGluIHRoZSBJUCBuZXR3b3Jr IHNpbmNlIFJUUCANCiAgIHBheWxvYWQgKG1pbmkgcGFja2V0cykgaXMgdHJhbnNwYXJlbnQgdG8g dGhlIGludGVybWVkaWF0ZSBJUCByb3V0ZXJzLg0KICAgVGhlIHVzZXIgbXV4IG1ldGhvZCByZXF1 aXJlcyBtaW5pbWFsIGVmZm9ydCBvbiBzdGFuZGFyZGl6YXRpb24gYW5kIA0KICAgY291bGQgYmUg aW1wbGVtZW50ZWQgYXMgYW4gYWRkLW9uIG1vZHVsZSB0byB0aGUgZXhpc3RpbmcgdGVsZXBob255 IA0KICAgZ2F0ZXdheXMuDQoNCg0KDQoNCjkgQ29tcGFyaXNvbiBvZiB0aHJlZSBkaWZmZXJlbnQg cHJvcG9zYWxzDQoNCiAgIFdlIGhhdmUgZm91bmQgdHdvIG90aGVyIHByb3Bvc2FscyBbOSwxMF0g c3VibWl0dGVkIGFzIElFVEYgZHJhZnRzIHRvIA0KICAgdGhlIEFWVCBncm91cC4gV2UgaGF2ZSBj b21wYXJlZCBvdXIgcHJvcG9zYWwgd2l0aCBvdGhlcnMgaW4gdGVybXMgb2YgDQogICBrbm93biBw ZXJmb3JtYW5jZSBtZXRyaWNzLiBUYWJsZSA0IHN1bW1hcml6ZXMgdGhlIHJlc3VsdHMgb2YgdGhl DQogICBjb21wYXJpc29uLg0KDQoNCisrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQorCSAgICAgICAgICAgICArICAgIE5v a2lhICAJKyAgICAgTHVjZW50ICAgKyAgICBIaXRhY2hpKw0KKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysNCisJCSAgICAg KwkJCSsgICAgICAgICAgICAgICsgICAgICAgICAgICsNCitSZWR1Y2luZyBvdmVyaGVhZCAgICsg IFZlcnkgZ29vZAkrICAgVmVyeSBnb29kICArICAgICBvawkgICArDQorCQkgICAgICsJCQkrCSAg ICAgICArCSAgICsNCitCYW5kd2lkdGggZWZmaWNpZW5jeSsgIFZlcnkgZ29vZAkrICAgVmVyeSBn b29kICArICAgICBvawkgICArDQorCQkgICAgICsJCQkrCSAgICAgICArCSAgICsNCitBZGRpdGlv bmFsIGhlYWRlciAgICsgICAgeWVzCQkrICAgIHllcyAgICAgICArICBOb3Qga25vd24rDQorCQkg ICAgICsgKDIgYnl0ZXMvcGt0KSAgICArICgyIGJ5dGVzL3BrdCkrICAgICAgICAgICArDQorCQkg ICAgICsJCQkrCSAgICAgICArICAgICAgICAgICArDQorQXNzZW1ibHkgYW5kIAkgICAgICsgICBT aW1wbGUgICAgICAgICArICAgIEhhcmQgICAgICArICAgU2ltcGxlICArDQorZGUtYXNzZW1ibHkg CSAgICAgKwkJCSsJICAgICAgICsJICAgKw0KKwkJICAgICArCQkJKwkgICAgICAgKwkgICArDQor TWF4ICMgb2YgdXNlcnMJICAgICArCQkJKwkgICAgICAgKwkgICArDQorZm9yIG11bHRpcGxleGlu ZyAgICArICAgICAyNTYJICAgICAgICArICAgIDI1NiAgICAgICArICBOb3Qga25vd24rDQorCQkg ICAgICsJCQkrCSAgICAgICArCSAgICsNCitNaW5pIHBhY2tldCBzaXplICAgICsgVmFyaWFibGUg ICAgCSsgIFZhcmlhYmxlICAgICsgIFZhcmlhYmxlICsNCisJCSAgICAgKyAoMCB+NjQpICAgICAg ICAgICsocmVxLiBrbm93biAgICsgICAgICAgICAgICsNCisJCSAgICAgKwkJCSsgICBwcm9maWxl cykgICsJICAgKw0KKwkJICAgICArCQkJKwkgICAgICAgKwkgICArDQorQ2hhbm5lbCBhc3NvY2lh dGlvbiArIFJlcXVpcmVkCSAgICAgICAgKyAgUmVxdWlyZWQgICAgKyAgIFJlcXVpcmVkKw0KKyhz aWduYWxpbmcpCSAgICAgKwkJCSsJICAgICAgICsgICAgICAgICAgICsNCisJCSAgICAgKwkJCSsJ ICAgICAgICsJICAgKw0KK1BhZGRpbmcgbXV4ICAJICAgICArIE5vdCByZXF1aXJlZCAgICAgKyAg ICBSZXF1aXJlZCAgKyBOb3QgcmVxICAgKw0KK2hlYWRlcgkJICAgICArCQkJKwkgICAgICAgKwkg ICArDQorCQkgICAgICsJCQkrCSAgICAgICArCSAgICsNCitNdWx0aXBsZXggdGltZXIgICAgICsg UHJvcG9zZWQJICAgICAgICArIE5vdCBwcm9wb3NlZCArIE5vdCBwcm9wICArDQorCQkgICAgICsg CQkJKwkgICAgICAgKwkgICArDQorRHluYW1pYyBjYXBhYmlsaXR5ICArIFBvc3NpYmxlICAgICAg ICAgKyBOb3QgcG9zc2libGUgKyBOb3QgcG9zcyAgKw0KKyAgZXhjaGFuZ2UgICAgICAgICAgKyAJ CQkrCSAgICAgICArCSAgICsNCisrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQoNCiAgIFRhYmxlIDQuIENvbXBhcmlzb24g b2YgZGlmZmVyZW50IGFwcHJvYWNoZXMgb24gdXNlciBtdWx0aXBsZXhpbmcNCiAgICAgICAgICAg IGluIFJUUCBwYXlsb2FkDQoNCg0KQi4gU3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDQoNCkludGVybmV0IERyYWZ0ICAg ICAgICAgICAgICAgICAgCQkgICAgICAgICAgQXVnIDE1LCAxOTk4DQoNCg0KMTAgQ29uY2x1c2lv bg0KDQogICBBIG5ldyBtZXRob2QgdG8gbXVsdGlwbGV4IHNwZWVjaCBzYW1wbGVzIGZyb20gYSBu dW1iZXIgb2YgdXNlcnMgaW4gDQogICBhIFJUUCBwYXlsb2FkIGlzIHByb3Bvc2VkLiBJdCBpcyBz aG93biB0aGF0IHRoaXMgbWV0aG9kIHJlZHVjZXMgdGhlIA0KICAgb3ZlcmhlYWQgZm9yIHNtYWxs IHBhY2tldHMsIGltcHJvdmVzIHRoZSBiYW5kd2lkdGggZWZmaWNpZW5jeSwgbG93ZXJzDQogICB0 aGUgY2hhbmNlcyBmb3IgY29uZ2VzdGlvbiBhdCBpbnRlcm1lZGlhdGUgSVAgcm91dGVycyBhbmQg ZW5oYW5jZXMgDQogICB0aGUgc2NhbGFiaWxpdHkgb2YgdGhlIGdhdGV3YXlzLiBBIG5ldyBjb250 cm9sIHNpZ25hbGluZyBwcm9jZWR1cmUgdG8NCiAgIG5lZ290aWF0ZSBhIGNoYW5uZWwgYmV0d2Vl biBwZWVyIGdhdGV3YXlzIGlzIGFsc28gcHJvcG9zZWQuIFRoZSANCiAgIGFkdmFudGFnZXMgb2Yg dGhpcyBtZXRob2QganVzdGlmeSB0aGUgbmVlZCBmb3Igc3VjaCBhIG1lY2hhbmlzbSANCiAgIGJl dHdlZW4gZ2F0ZXdheXMgdGhhdCBpbnRlcmNvbm5lY3QgUFNUTiBhbmQgR1NNIHVzZXJzLg0KDQox MSBGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJu ZXQgU29jaWV0eSAoMTk5OCkuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1l bnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkgYmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8N CiAgIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVy d2lzZSBleHBsYWluIGl0DQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBi ZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQNCiAgIGFuZCBkaXN0cmlidXRlZCwgaW4gd2hv bGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkNCiAgIGtpbmQsIHByb3Zp ZGVkIHRoYXQgdGhlIGFib3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoDQog ICBhcmUgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLg0K DQogICBIb3dldmVyLCB0aGlzIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlmaWVkIGlu IGFueSB3YXksIHN1Y2ggYXMNCiAgIGJ5IHJlbW92aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9y IHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNvY2ktDQogICBldHkgb3Igb3RoZXIgSW50ZXJu ZXQgb3JnYW5pemF0aW9ucywgZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2UNCiAgIG9m IGRldmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVy ZXMgZm9yDQogICBjb3B5cmlnaHRzIGRlZmluZWQgaW4gdGhlIEludGVybmV0IFN0YW5kYXJkcyBw cm9jZXNzIG11c3QgYmUgZm9sLQ0KICAgbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0 ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuDQogICBFbmdsaXNoLg0KDQogICBUaGUgbGlt aXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90 IGJlDQogICByZXZva2VkIGJ5IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3Jz IG9yIGFzc2lnbnMuDQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJhc2lzIGFuZCBUSEUg SU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HDQogICBUQVNLIEZP UkNFIERJU0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJ TkcNCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRI RSBJTkZPUk1BVElPTg0KICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1Ig QU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVItDQogICBDSEFOVEFCSUxJVFkgT1IgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIg0KDQoxMiBBdXRob3JzJyBBZGRyZXNzZXMNCg0K ICAgQmFyYW5pIFN1YmJpYWgsIFNlbnRoaWwgU2VuZ29kYW4NCiAgIE5va2lhIFJlc2VhcmNoIENl bnRlciAgIA0KICAgMyBCdXJsaW5ndG9uIFdvb2RzIERyLiwgU3RlLiAyNjANCiAgIEJ1cmxpbmd0 b24sIE1BIC0gMDE4MDMsIFVTQQ0KDQogICBiYXJhbml0aGFyYW4uc3ViYmlhaEByZXNlYXJjaC5u b2tpYS5jb20NCiAgIHNlbnRoaWwuc2VuZ29kYW5AcmVzZWFyY2gubm9raWEuY29tDQoNCg0KQi4g U3ViYmlhaCwgUy4gU2VuZ29kYW4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFtQYWdlIDE2XQ0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgCQkgICAgICAg ICAgICAgICAgQXVnIDE1LCAxOTk4DQoNCg0KDQoxMyBCaWJsaW9ncmFwaHkNCg0KICAgWzFdIEgu IFNjaHVsenJpbm5lLCBTLiBDYXNuZXIsIFIuIEZyZWRlcmljaywgYW5kIFYuIEphY29ic29uLCBS VFA6IGENCiAgICAgICB0cmFuc3BvcnQgcHJvdG9jb2wgZm9yIHJlYWwtdGltZSBhcHBsaWNhdGlv bnMsIFJlcXVlc3QgZm9yIA0KICAgICAgIENvbW1lbnRzKFByb3Bvc2VkIFN0YW5kYXJkKSAxODg5 LCBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrDQogICAgICAgRm9yY2UsIEphbi4gMTk5Ni4NCg0K ICAgWzJdIEludGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb24gVW5pb24sIENvZGluZyBvZiBz cGVlY2ggYXQgOA0KICAgICAgIGtiaXQvcyB1c2luZyBjb25qdWdhdGUtc3RydWN0dXJlIGFsZ2Vi cmFpYy1jb2RlLWV4Y2l0ZWQgbGluZWFyLQ0KICAgICAgIHByZWRpY3Rpb24sIFJlY29tbWVuZGF0 aW9uIEcuNzI5LCBUZWxlY29tbXVuaWNhdGlvbiBTdGFuZGFyZGktDQogICAgICAgemF0aW9uIFNl Y3RvciBvZiBJVFUsIEdlbmV2YSwgU3dpdHplcmxhbmQsIE1hci4gMTk5Ni4NCg0KICAgWzNdIEgu IFNjaHVsenJpbm5lLCBSVFAgcHJvZmlsZSBmb3IgYXVkaW8gYW5kIHZpZGVvIGNvbmZlcmVuY2Vz IHdpdGgNCiAgICAgICBtaW5pbWFsIGNvbnRyb2wsIFJlcXVlc3QgZm9yIENvbW1lbnRzIChQcm9w b3NlZCBTdGFuZGFyZCkgMTg5MCwNCiAgICAgICBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZv cmNlLCBKYW4uIDE5OTYuDQoNCiAgIFs0XSBJVFUtVCBSZWNvbW1lbmRhdGlvbiAgRy43MjMuMSAo MTk5NSkgIkR1YWwgIFJhdGUgIFNwZWVjaCAgQ29kZXIgDQogICAgICAgRm9yIE11bHRpbWVkaWEg Q29tbXVuaWNhdGlvbnMgVHJhbnNtaXR0aW5nICBBdCAgNS4zICBBbmQgIDYuMyAgDQogICAgICAg a2JpdC9zIiANCg0KICAgWzVdIElUVS1UIFJlY29tbWVuZGF0aW9uIEguMjI1LjAgKDE5OTgpOiAi IE1lZGlhIFN0cmVhbSBQYWNrZXRpemF0aW9uDQogICAgICAgYW5kIFN5bmNocm9uaXphdGlvbiBm b3IgVmlzdWFsIFRlbGVwaG9uZSBTeXN0ZW1zIG9uIE5vbi1HdWFyYW50LQ0KICAgICAgIGVlZCBR dWFsaXR5IG9mIFNlcnZpY2UgTEFOcyAiLg0KDQogICBbNl0gSVRVLVQgUmVjb21tZW5kYXRpb24g SC4yNDUgKDE5OTgpOiAiQ29udHJvbCBvZiBjb21tdW5pY2F0aW9ucyANCiAgICAgICBiZXR3ZWVu IFZpc3VhbCBUZWxlcGhvbmUgU3lzdGVtcyBhbmQgVGVybWluYWwgRXF1aXBtZW50Ii4gSVRVLVQg DQogICAgICAgUmVjb21tZW5kYXRpb24gSC4yNDYgKDE5OTgpICJJbnRlcndvcmtpbmcgb2YgSC5z ZXJpZXMgbXVsdGltZWRpYQ0KICAgICAgIHRlcm1pbmFscyINCg0KICAgWzddIElUVS1UIFJlY29t bWVuZGF0aW9uIEguMzIzIChNYXksIDE5OTYpOiBWaXN1YWwgVGVsZXBob25lIFN5c3RlbXMNCiAg ICAgICBhbmQgRXF1aXBtZW50IGZvciBMb2NhbCBBcmVhIE5ldHdvcmtzIFdoaWNoIFByb3ZpZGUg YSBOb24tR3VhcmEtDQogICAgICAgbnRlZWQgUXVhbGl0eSBvZiBTZXJ2aWNlLg0KDQogICBbOF0g SVRVLVQgUmVjb21tZW5kYXRpb24gSC4zMjMgKEphbnVhcnksIDE5OTgpOiBQYWNrZXQgQmFzZWQg TXVsdGktDQogICAgICAgbWVkaWEgQ29tbXVuaWNhdGlvbnMgU3lzdGVtcw0KDQogICBbOV0gSi4g Um9zZW5iZXJnIGFuZCBILiBTY2h1bHpyaW5uZTogQW4gUlRQIHBheWxvYWQgZm9ybWF0IGZvciB1 c2VyDQogICAgICAgbXVsdGlwbGV4aW5nLCBJRVRGIGRyYWZ0LCB3b3JrIGluIHByb2dyZXNzLCBN YXkgMTk5OC4JDQoNCiAgIFsxMF0gSy4gVGFuaWdhd2EsIFQuIEhvc2hpIGFuZCBLLiBUc3VrYWRh OiBBIFJUUCBzaW1wbGUgbXVsdGlwbGV4aW5nIA0KICAgICAgICB0cmFuc2ZlciBtZXRob2QgZm9y IEludGVybmV0IHRlbGVwaG9ueSBnYXRld2F5LCBJRVRGIGRyYWZ0LCANCiAgICAgICAgd29yayBp biBwcm9ncmVzcywgSnVuZSAxOTg4DQoNCiAgIFsxMV0gSC4gU2NodWx6cmlubmUsIEUuIFNjaG9v bGVyLCBKLiBSb3NlbmJlcmc6IFNlc3Npb24gSW5pdGlhdGlvbiANCglQcm90b2NvbCwgSUVURiBk cmFmdCwgd29yayBpbiBwcm9ncmVzcywgSnVseSAxOTk4Lg0KDQoNCg0KDQoNCg0KDQoNCkIuIFN1 YmJpYWgsIFMuIFNlbmdvZGFuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdl IDE3XQ0KDQoNCg== --===_1998Aug23.102100.1991.302464===_-- From rem-conf Sun Aug 23 12:52:36 1998 From rem-conf-request@es.net Sun Aug 23 12:52:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zAg6Q-00061n-00; Sun, 23 Aug 1998 12:47:02 -0700 Received: from rumor.research.att.com [192.20.225.9] by mail1.es.net with smtp (Exim 1.81 #2) id 0zAg6P-00061d-00; Sun, 23 Aug 1998 12:47:01 -0700 Received: from research.att.com ([135.207.30.100]) by rumor; Sun Aug 23 15:40:20 EDT 1998 Received: from surfcity.research.att.com ([135.207.128.5]) by research; Sun Aug 23 15:44:18 EDT 1998 Received: from pcbasso.research.att.com (pcbasso [135.207.130.108]) by surfcity.research.att.com (8.8.7/8.8.7) with SMTP id PAA02583; Sun, 23 Aug 1998 15:43:49 -0400 (EDT) Message-ID: <35E0714F.4B46@research.att.com> Date: Sun, 23 Aug 1998 15:45:19 -0400 From: Andrea Basso Reply-To: basso@research.att.com Organization: AT&T Labs - Research X-Mailer: Mozilla 3.0Gold (Win95; U) MIME-Version: 1.0 To: osimcast@bbn.com, sc6wg4@ntd.comsat.com, xtp-relay@cs.concordia.ca, reres@laas.fr, prs@masi.ibp.fr, comswtc@gmu.ed, multicomm@cc.bellcore.com, giga@tele.pitt.edu, tccc@ieee.org, itc%ieee.org.isadsoc@fokus.gmd.de, ctc-members@redbank.tinac.com, ieee_rtc_list@cs.tamu.edu, enternet@bbn.com, gcomlist1@manjaro.ece.iit.edu, comsoc.bog@tab.ieee.org, sigmedia@bellcore.com, comsoc.tac@tab.ieee.org, comsoc-gicb@ieee.org, commsoft@cc.bellcore.com, BM-List1@cs.ucdavis.edu, modern-heuristics@uk.ac.mailbase.ucdavis.edu, cellular@dfv.rwth-aachen.edu, cost237-transport@comp.lancs.ac.uk, testnet@canarie.ca, itc@fokus.gmd.de, dbworld@cs.wisc.edu, end2end-interest@isi.edu, f-troup@codex.cis.upenn.edu, hipparch@sophia.inria.fr, rem-conf@es.net, mobile-ip@tadpole.com, ieeetcpc@ccvm.sunysb.edu, epr@infotest.com, golshani@asu.edu, ni@cps.msu.edu, park@cstp.umkc.edu, tcp-over-satellite@achtung.sp.trw.com, udlr@sophia.inria.fr, knom@nile.postech.ac.kr, han-announce@news.postech.ac.kr, han-net-announce@news.postech.ac.kr, info@nmf.org, comsoc-cii@ieee.org, ifip-nm@bbn.com, nmf-objects@nmf.org, ietf@venera.isi.edu, fli@ee.pdx.edu, mpeg4ipr@research.kpn.com, mpeg4reqs@research.kpn.com, mux-sys@fzi.de CC: rem-conf@es.net Subject: Packet Video 99 Call for Papers Content-Type: multipart/mixed; boundary="------------24BE748D25A3" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------24BE748D25A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- Andrea Basso Senior Technical Staff Member AT&T Labs - Research Room 3-219, 100 Schultz Drive, Red Bank, NJ 07701 tel:+1 732 345 3302 fax:+1 732 345 3033 E-mail: basso@research.att.com WWW : http://www.research.att.com/info/basso --------------24BE748D25A3 Content-Type: text/plain; charset=us-ascii; name="pkvd99cfpnew.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pkvd99cfpnew.txt" CALL FOR PAPERS Packet Video '99 The 9th International Packet Video Workshop 26-27 April 1999 New York City, U.S.A http://www.research.att.com/~mrc/PacketVideo99.html In Europe: http://www.inria.fr/rodeo/turletti/pv99/ Sponsored by: AT&T, Columbia University, EURASIP, IEEE Signal Processing Society IMDSP & MMSP Technical Committees The ninth International Packet Video Workshop (PV' 99) will be held at the Davis auditorium, of Columbia University in New York City. The workshop is devoted to presenting technological advancements and innovations in video transmission over packet networks, in particular, the Internet. Packet Video Workshops have been unique in providing a common ground for people from video coding and networking fields. Presentations on theory and practice, standards activities, and business and consumer applications are encouraged. We cordially invite you to take part in this workshop by submitting your work and look forward to seeing you in New York City in April 1999 for what will be a most rewarding and exciting experience! PV'99 is scheduled to take place in the week following Picture Coding Symposium 99 (PCS' 99) which is being held in Portland Oregon, on 21-23 April 1999. For information on PCS'99 please contact: pcs@pcs.ece.orst.edu TECHNICAL PROGRAM The technical program of Packet Video '99 will consist of invited talks, submitted paper presentations, poster sessions and a plenary session: "After Internet Telephony, Internet Television..." Topics of interest include, but are not limited to, the following: * Video streaming over the Internet * Network adaptive video coding and transport * Packetized video for home LAN's * Packetized video for wireless/mobile systems * Layered coding for error resilience and heterogeneous networks * Packet loss resilient coding and transport * Terminal and server architectures for Internet TV * Efficient transcoding for heterogeneous networks * Congestion control * Error concealment * Statistical multiplexing for greater network and terminal utilization * Traffic shaping for efficient network and terminal utilization * Interstream synchronization for multiple video presentations * Performance modeling and evaluation * Rate control for VBR video * International Standards: MPEG-4, MPEG-7, H.263+, RTP, RTSP, SIP, SDP * Multicasting, MBONE applications * Implementations and commercial applications Best Paper Award: The author of the best paper will receive: A $250 cash prize graciously donated by NEC USA, C&C Research Laboratories. Manuscripts submitted to PV'99 will be considered for publication in the special issue of EURASIP Journal Signal Processing: Image Communication, REAL-TIME VIDEO OVER THE INTERNET also. Submissions Please submit an electronic manuscript written in HTML, not exceeding 7 Mbytes and 10 printed pages. We will produce a CD-ROM containing the accepted papers. Electronic components accompanying your submission are strongly encouraged. Submit your work in ONE of the following forms: 1) a set of HTML files organized in a single directory OR 2) as a URL (you must have the rights to all the material there, and guarantee stability of the files until the conference). to: pv99-submissions@research.att.com Detailed instructions for authors and help with manuscript preparation with HTML can be found on the conference web page: http://www.research.att.com/~mrc/PacketVideo99.html ALL SUBMISSIONS MUST BE RECEIVED no later than: December 15th, 1998, NOTIFICATION OF ACCEPTANCE: February 1, 1999 FINAL PAPERS DUE: March 15, 1999 GENERAL CHAIR PUBLICATION & LOCAL ARRANGEMENTS M. Reha Civanlar Andrea Basso AT&T Labs - Research AT&T Labs - Research 100 Schultz Drive, 3-213 100 Schultz Drive, 3-219 Red Bank, NJ 07701 Red Bank, NJ 07701 USA USA civanlar@research.att.com basso@research.att.com PACKET VIDEO' 99 INTERNATIONAL STEERING COMMITTEE John Arnold, University of New South Wales, Australia Andrea Basso, AT&T Labs - Research, USA Stephen Casner, Precept Software, USA Shih-Fu Chang, Columbia University, USA Leonardo Chiariglione, CSELT, Italy M. Reha Civanlar, AT&T Labs - Research, USA Jon Crowcroft, University College of London, UK Mohammed Ghanbari, University of Essex UK Barry G. Haskell AT&T Labs - Research, USA Steven McCanne, U. C. Berkeley, USA Geoff Morrison, BT Labs, UK Joerg Ott, University of Bremen, Germany Sakae Okubo, Graphics Communication Labs, Japan D. Raychaudhuri, NEC Research, USA Amy Reibman, AT&T Labs - Research, USA Henning Schulzrinne, Columbia University, USA Gary Sullivan, PictureTel, USA Toshitaka Tsuda, Fujitsu, Japan Thierry Turletti, INRIA, France Stephan Wenger, Technical University of Berlin, Germany Hiroshi Yasuda, NTT, Japan --------------24BE748D25A3-- From rem-conf Mon Aug 24 01:34:22 1998 From rem-conf-request@es.net Mon Aug 24 01:34:22 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zAs1I-00046v-00; Mon, 24 Aug 1998 01:30:32 -0700 Received: from ss3000e.cselt.it [163.162.4.10] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zAs1F-00046k-00; Mon, 24 Aug 1998 01:30:29 -0700 Received: from rabadan.cselt.stet.it by ss3000e.cselt.stet.it (PMDF V5.1-12 #29348) with ESMTP id <0EY600JIZQ6Z3Y@ss3000e.cselt.stet.it> for rem-conf@es.net; Mon, 24 Aug 1998 10:28:12 +0200 (MET DST) Received: by rabadan.cselt.stet.it with Internet Mail Service (5.5.1960.3) id ; Mon, 24 Aug 1998 10:30:21 +0200 Content-return: allowed Date: Mon, 24 Aug 1998 10:30:39 +0200 From: Franceschini Guido Subject: RE: Proposed agenda for AVT WG at IETF in Chicago To: Olivier AVARO - France Telecom - CNET , 'Dave Singer' Cc: Mark Handley , Vahe Balabanian , casner@cisco.com, rem-conf@es.net Message-id: <7FC1C9AF63BAD111ADEA0008C728A50F222AD2@xnole.cselt.stet.it> Old-X-Envelope-to: rem-conf@es.net MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-type: text/plain; charset="iso-8859-1" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dave, all, your mail on SDP & MPEG4 anticipates a planned contribution of mine on this issue. I summarize here what I plan to describe in better detail for the MPEG october meeting in Atlantic City. Maybe you know that I have implemented for MPEG-4 IM1 (and demonstrated to the DMIF group at the MPEG Dublin meeting) MPEG-4 over IP multicast. We are now planning a second, better demo for the Atlantic City MPEG meeting. I have implemented: - a simple server which delivers content in UDP multicast sockets, using the MPEG-4 Sync Layer and the MPEG-4 FlexMux: it does not use RTP - a DMIF instance at the receiver side able to read content from multicast sockets. The design of this instance also includes the parsing of SDP-like descriptions of MPEG-4 content. I was planning to prepare a contribution to Atlantic City describing my implementation, and the addition I put to SDP to make it MSDP (MPEG-SDP ;-). I was also willing to demonstrate how we added a simple plugin to SDR in order to let it start the IM1 player (but probably this demo will not be made, because out of context. However it works already) In order to make my implementation work withouth changing the basic features of SDP and SDR (and thus integrating with SDR), I accepted unoptimized solutions. I had 2 obstacles with respect to SDP and SDR - in SDP there is no keyword nor attribute for MPEG and for MPEG-4 Flexmuxes - SDR associates an application to each media described, making it impossible to run a single player for managing all the media at once My solution (which is unoptimal, but at least working ;-) extends SDP introducing keywords for the "MPEG" media, and an attribute (URL) to point to the MSDP file. The MSDP file, in turn, looks similar to normal SDP, but is obviously a bit different, and needs a different parser. With this trick, I just had to write a plugin for SDR; SDR associates the IM1 player to the "MPEG-4 media", and the IM1 player then processes the URL pointing to the MSDP file. At the moment, there is no reason for such MSDP file to be text based, thus I could have introduced the Initial OD in it. I haven't done it yet (I use yet another URL to get the IOD). Best regards Guido Franceschini ------------------------------- CSELT, Via Reiss Romoli 274 , I-10148 Torino - Italy Tel + 39 011 228 6137 Fax + 39 011 228 6190 Email guido.franceschini@cselt.it > ---------- > From: Dave Singer[SMTP:singer@apple.com] > Sent: Saturday, August 22, 1998 1:16 AM > To: Olivier AVARO - France Telecom - CNET > Cc: Mark Handley; Vahe Balabanian; casner@cisco.com; rem-conf@es.net > Subject: Re: Proposed agenda for AVT WG at IETF in Chicago > > Olivier > > > SDP is a simple text description format which declares basic > information > about the set of streams forming a session. Here is an example of a > simple > two-stream SDP: > > v=0 > o=qts 3104776650 3104776819 IN IP4 17.0.0.255 > s=Faucet > i=Vic/Vat from the Lab Sun called faucet > u=http://www.apple.com > e=Ingrid Flowmore > p=Ingrid Flowmore 408 996 1010 > c=IN IP4 224.2.210.93/15 > t=0 0 > a=tool:sdr v2.2a23 > a=type:test > m=audio 22584 RTP/AVP 3 > c=IN IP4 224.2.210.93/15 > m=video 57736 RTP/AVP 31 > c=IN IP4 224.2.255.62/15 > > you'll note that it is text-based. The initialization information > needed > for Mpeg4 streams (e.g. the object descriptor) doesn't fit very > comfortably > into this format. We discussed this a little at a recent IETF -- what > to do > about 'codecs' which need significant setup information? I'm not sure > we > reached a conclusion. > > I suspect (?) that what SDP could tell you is the set of Mpeg4 streams > being used, and the mapping from IP RTP stream to Mpeg4 streamID. I > would > treat the SDP file then as also presenting the 'initial object > descriptor' > in the sense that it should say which are the 'root' streams of the > presentation. One of these might be an object descriptor stream, which > would use Mpeg4 streamIDS (as usual) and carry full object descriptors > for > the streams. Using the mapping info in the SDP file, the StreamIDs > could > then be mapped to RTP sessions. Such an approach assumes that any > 'root' > streams do not use extension descriptors etc. and that all the > information > needed about them (which would normally be in the initial object > descriptor) could be in the SDP file. > > I am speculating without having detailed such a design, but I suspect > some > approach along these lines is possible without doing violence to > either > RTP/SDP etc. or to MPEG4. > > At 5:30 AM -0700 8/21/98, Olivier AVARO - France Telecom - CNET wrote: > >Hi Dave, all, > > > > > Clearly there are questions here about the overlap -- e.g. between > SDP > > > which describes streams and their format, and the Mpeg4 descriptor > stream. > > > >I don't know yet SDP and if someone has got entry point I would be > >grateful. From the little knowledge I have, it seems that SDP could > >carry : > >- the first object descriptor needed by MPEG that tell where and what > is > >the MPEG-4 content. > >- the complete MPEG-4 descriptor streams. > > > >Is it what you guys (Vahe, ohers, ...) have in mind ? > > > >Thanx for the feed back in any case. > > > >See you, > > > >Olivir > > > > > David Singer > Apple Computer/QuickTime 408-974-3162 > > > From rem-conf Mon Aug 24 14:06:32 1998 From rem-conf-request@es.net Mon Aug 24 14:06:31 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zB3Vr-0003zG-00; Mon, 24 Aug 1998 13:46:51 -0700 Received: from (proxy2.activetouch.com) [202.47.133.202] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zB3Vp-0003yN-00; Mon, 24 Aug 1998 13:46:50 -0700 Received: from ANEWORLD by proxy2.activetouch.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id RSBZHGYK; Mon, 24 Aug 1998 13:44:30 -0700 Message-ID: <35E1D2E7.EE8F2215@activetouch.com> Date: Mon, 24 Aug 1998 13:53:59 -0700 From: Tony Zhao X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: unsubscript Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscript unsubscription remove me, I will use other account to join, thanks From rem-conf Mon Aug 24 14:06:32 1998 From rem-conf-request@es.net Mon Aug 24 14:06:32 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zB3aV-00043C-00; Mon, 24 Aug 1998 13:51:39 -0700 Received: from (proxy2.activetouch.com) [202.47.133.202] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zB3aU-00041e-00; Mon, 24 Aug 1998 13:51:38 -0700 Received: from ANEWORLD by proxy2.activetouch.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id RSBZHGZG; Mon, 24 Aug 1998 13:49:24 -0700 Message-ID: <35E1D40C.934B4EBD@activetouch.com> Date: Mon, 24 Aug 1998 13:58:52 -0700 From: Tony Zhao X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: subscript Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list subscript subscription Please Sign me on, thanks From rem-conf Mon Aug 24 16:51:50 1998 From rem-conf-request@es.net Mon Aug 24 16:51:48 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zB6Bu-0006Z1-00; Mon, 24 Aug 1998 16:38:26 -0700 Received: from caboose.zip.com.au [203.12.97.11] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zB6Bs-0006Yq-00; Mon, 24 Aug 1998 16:38:25 -0700 Received: from zip.com.au (jeff12.zip.com.au [203.62.150.140]) by caboose.zip.com.au (8.9.1/8.9.1) with ESMTP id JAA31091 for ; Tue, 25 Aug 1998 09:38:16 +1000 Message-ID: <35E1FA97.18F3293B@zip.com.au> Date: Tue, 25 Aug 1998 09:43:19 +1000 From: Phil Brewer X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: unsubscript Content-Type: multipart/mixed; boundary="------------66203A17789B3847914B3911" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------66203A17789B3847914B3911 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscript unsubscription remove me, please --------------66203A17789B3847914B3911 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Phil Brewer Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Phil Brewer n: Brewer;Phil org: Chubb VISION adr: 87 Racecourse Road;;North Melbourne;Melbourne;Victoria;3051;AUSTRALIA email;internet: brewerp@zip.com.au title: CCTV/Video Support Engineer tel;work: +61 3 9241 5522 tel;fax: +61 3 9328 2304 tel;home: 0417 054 099 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------66203A17789B3847914B3911-- From rem-conf Tue Aug 25 01:56:27 1998 From rem-conf-request@es.net Tue Aug 25 01:56:26 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zBEqU-0002o1-00; Tue, 25 Aug 1998 01:52:54 -0700 Received: from tkrn6.informatik.uni-hamburg.de [134.100.15.166] (root) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zBEqS-0002nQ-00; Tue, 25 Aug 1998 01:52:52 -0700 Received: from tkrn7.informatik.uni-hamburg.de (richter@tkrn7.informatik.uni-hamburg.de [134.100.15.167]) by tkrn6.informatik.uni-hamburg.de (8.8.8/8.8.8) with ESMTP id KAA23318; Tue, 25 Aug 1998 10:49:03 +0200 (MET DST) From: Jan-Peter Richter Received: (from richter@localhost) by tkrn7.informatik.uni-hamburg.de (8.8.8/8.8.8) id KAA09655; Tue, 25 Aug 1998 10:49:02 +0200 (MET DST) Message-Id: <199808250849.KAA09655@tkrn7.informatik.uni-hamburg.de> To: mbone@isi.edu, rem-conf@es.net, cabernet-events@newcastle.ac.uk, mmt-liste@tu-dresden.de, int-serv@isi.edu, rsvp@isi.edu Date: Tue, 25 Aug 1998 10:49:02 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Subject: Unidentified subject! X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list --> We apologize if you receive multiple copies of this. <-- ======================================================================= ******************************************************************** Preliminary Call for Papers Workshop on Modeling Multimedia Support in Next Generation High Speed Networks (NGHSN99) Warsaw, Poland, June 1st to 2nd, 1999 co-located with ESM'99 European Simulation Multiconference Highly demanding applications such as multimedia are becoming more and more important in today's high speed networks. The design of future communication infrastructures will be strongly influenced by experiences made today, and support for modern application will be available. However, making such applications feasible will not work when based on ad-hoc solutions due to the high complexity of the whole problem field. Rather, models, simulation and analysis should be employed to direct future developments. The goal of this workshop is to survey and advance the state of the art in modeling and simulation support for future generation high-speed networks and applications. Possible topics include, but are not limited to - traffic models - modeling techniques (automata-based techniques, Markov chains, Petri Nets etc.) - simulation (languages, tools) - real-time issues - Quality of Service (modeling, Internet support, pricing and charging etc.) - multimedia in the Internet and WWW - multicast and Group Communication (modeling, simulation, QoS support) - programmable networks: active networks and open signalling Requested Contributions and Submission Procedure: ------------------------------------------------- Please submit your full-length paper (Postscript or PDF, 11pt font min, 8 pages max.) electronically using our web site at http://www.i-u.de/resources/events/NGHSN99/. You will find further instructions about the submission process there. If you cannot submit electronically, please send 5 hardcopies of your paper to Dr. Stefan Fischer International University School of Information Technology International University Campus 1 D-76646 Bruchsal Germany Accepted papers will be published in workshop proceedings (by SCS). Important Dates: ---------------- November 1st, 1998: Submission of papers January 15th, 1999: Notification of Acceptance March 1st, 1999: Camera-Ready Copy General Chair: -------------- Hermann de Meer, Columbia University, New York, USA Program Chair: -------------- Stefan Fischer, International University, Bruchsal, Germany Program Committee: ------------------ Gregor v. Bochmann, University of Ottawa, Canada Gunter Bolch, University of Erlangen, Germany Torsten Braun, University of Berne, Sitzerland Jan Bredereke, McMaster University, Hamilton, Canada Stanislaw Budkowski, INT Evry, France Michel Diaz, LAAS, France Reinhard Gotzhein, University of Kaiserslautern, Germany Abdelhakim Hafid, University of Western Ontario, London, Canada Stefan Leue, University of Waterloo, Canada Jozef Lubacz, Warsaw University of Technology, Poland Jan de Meer, GMD FOKUS, Berlin, Germany Bruno Mueller-Clostermann, University of Essen, Germany Andrzej Pach, Cracow University of Mining, Poland Otto Spaniol, RWTH Aachen, Germany Heinrich Stuettgen, NEC Europe, Germany Janos Sztrik, University of Debrecin, Hungary Miklos Telek, University of Budapest, Hungary Kishor S. Trivedi, Duke University, USA Ralph Wittmann, TU Braunschweig, Germany Lars Wolf, TU Darmstadt, Germany Martina Zitterbart, TU Braunschweig, Germany For further information, contact: Hermann de Meer (hdm@comet.columbia.edu) or Stefan Fischer (Stefan.Fischer@i-u.de) From rem-conf Tue Aug 25 02:19:10 1998 From rem-conf-request@es.net Tue Aug 25 02:19:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zBFEi-0003VO-00; Tue, 25 Aug 1998 02:17:56 -0700 Received: from (outside2.enea.se) [192.36.1.249] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zBFEg-0003VC-00; Tue, 25 Aug 1998 02:17:54 -0700 Received: by outside2.enea.se (8.9.0/8.6.9) id KAA25986 for ; Tue, 25 Aug 1998 10:06:32 +0200 X-Authentication-Warning: outside2.enea.se: bin set sender to using -f Received: from freja(172.16.1.3) by outside2.enea.se via smap (V2.1) id xma025980; Tue, 25 Aug 98 10:06:25 +0200 Received: from enea.se () by (8.8.5/8.8.0) with ESMTP id LAA07167 for ; Tue, 25 Aug 1998 11:16:01 +0200 (MET DST) Message-ID: <35E281E7.EA086F5A@enea.se> Date: Tue, 25 Aug 1998 11:20:39 +0200 From: Rikard Fooladi X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: unsubscript Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubscript please remove me from your account ! From rem-conf Tue Aug 25 09:33:41 1998 From rem-conf-request@es.net Tue Aug 25 09:33:41 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zBLwk-0000Vi-00; Tue, 25 Aug 1998 09:27:50 -0700 Received: from pmc02ext.pmc.philips.com (pmc02.pmc.philips.com) [208.198.161.202] by mail1.es.net with smtp (Exim 1.81 #2) id 0zBLwj-0000VB-00; Tue, 25 Aug 1998 09:27:49 -0700 Received: from amalia-1.pmc.philips.com by pmc02.pmc.philips.com via SMTP (SMI-8.6/SMI-SVR4) for id JAA05364; Tue, 25 Aug 1998 09:26:38 -0700 Message-Id: <3.0.32.19980825092626.006fb72c@mailhost> X-Sender: amalia@mailhost X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 25 Aug 1998 09:26:27 -0700 To: rem-conf@es.net From: Amalia Garay Subject: Re: unsubscript Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please remove me from your account. - - - - - - At 11:20 AM 8/25/98 +0200, Rikard Fooladi wrote: >unsubscript > >please remove me from your account ! > > > From rem-conf Wed Aug 26 12:03:04 1998 From rem-conf-request@es.net Wed Aug 26 12:03:02 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zBkgL-0007X5-00; Wed, 26 Aug 1998 11:52:33 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zBkgK-0007Wv-00; Wed, 26 Aug 1998 11:52:32 -0700 Received: from quimby.cs.berkeley.edu (quimby.CS.Berkeley.EDU [128.32.131.169]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id LAA28310 for ; Wed, 26 Aug 1998 11:52:31 -0700 (PDT) Message-Id: <199808261852.LAA28310@gumby.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 From: "Larry Rowe" To: rem-conf@es.net Subject: [REMINDER] Berkeley MIG Seminar Today: D. Glazer "Implementing an On-demand Internet Streaming Media Business Reply-To: Rowe@bmrc.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Aug 1998 11:52:31 -0700 Sender: larry@bmrc.berkeley.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Implementing an On-Demand Internet Streaming Media Business (Wednesday August 26, 1998 12:30-2:00 PDT 405 Soda Hall) Dave Glazer (Eloquent, Inc. ) The delivery of knowledge is being revolutionized by the influence of desktop multimedia technology. The ability to digitize and distribute various media and documents has created new possibilities that can increase the effectiveness of information while lowering the cost of its delivery. While much of today's technology-based training uses sophistcated custom-built applications, most organizations do not have the time or money to build them. This talk will describe an Enterprise Knowledge Development System that can be used to provide on-demand, computer-based training. The system is based on streaming digital audio and video with synchronized slides and transcript. The authoring process, media server, delivery protocol, and client application will be described. --- MBone addresses: video (vic) 224.2.231.74/44332 audio (vat) 224.2.196.31/18208 http://bmrc.berkeley.edu/mig/ From rem-conf Wed Aug 26 12:29:38 1998 From rem-conf-request@es.net Wed Aug 26 12:29:38 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zBlE4-0000bv-00; Wed, 26 Aug 1998 12:27:24 -0700 Received: from gumby.cs.berkeley.edu [128.32.32.38] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zBlE3-0000bk-00; Wed, 26 Aug 1998 12:27:23 -0700 Received: from quimby.cs.berkeley.edu (quimby.CS.Berkeley.EDU [128.32.131.169]) by gumby.CS.Berkeley.EDU (8.8.4/8.6.9) with ESMTP id MAA28555 for ; Wed, 26 Aug 1998 12:27:22 -0700 (PDT) Message-Id: <199808261927.MAA28555@gumby.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 From: "Larry Rowe" To: rem-conf@es.net Subject: Berkeley MIG Seminar -- MBone address error... Reply-To: Rowe@bmrc.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Aug 1998 12:27:22 -0700 Sender: larry@bmrc.berkeley.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In the previous message, I gave the wrong addresses. The correct addresses are: video 224.2.163.7/57076 audio 224.2.147.61/27202 The session is also being announced in sdr as "Berkeley MIG Seminar" Sorry for the confusion, this is the first seminar this semester and we've changed a lot of things... Larry -- Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU Computer Science Division - EECS Phone: 510-642-5117 University of California, Berkeley Fax: 510-642-5615 Berkeley, CA 94720-1776 URL: http://www.bmrc.berkeley.edu/~larry From rem-conf Thu Aug 27 11:29:45 1998 From rem-conf-request@es.net Thu Aug 27 11:29:43 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zC6gQ-0007BV-00; Thu, 27 Aug 1998 11:22:06 -0700 Received: from nobozo.cs.berkeley.edu [128.32.34.58] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zC6gP-0007BH-00; Thu, 27 Aug 1998 11:22:05 -0700 Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.8.8/8.6.3) with SMTP id LAA29191 for ; Thu, 27 Aug 1998 11:22:04 -0700 (PDT) Message-Id: <3.0.3.32.19980827112204.00a7ddb0@gumby.cs.berkeley.edu> X-Sender: cwilliams@gumby.cs.berkeley.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 27 Aug 1998 11:22:04 -0700 To: rem-conf@es.net From: Chris Williams Subject: Sept. 2 Berkeley Multimedia, Interfaces, and Graphics Seminar/Webcast Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list
Visualizing the Evolution of Web Ecologies Wednesday September 2, 1998 12:30-2:00 PDT 405 Soda Hall Ed Chi Department of Computer Science and Engineering University of Minnesota
Several visualizations have emerged which attempt to visualize the World Wide Web. Those visualizations, however, fail to present the dynamically changing ecology of users and documents on the Web. We present new techniques for Web Ecology and Evolution Visualization. Disk Trees represent a discrete time slice of the Web ecology. A collection of Disk Trees forms a Time Tube, representing the evolution of the Web over longer periods of time. These visualizations are intended to aid authors and webmasters with the production and organization of content, assist web surfers making sense of information, and help researchers understand the Web. Given the infancy of the Web, it is not surprising that the interactions and relationships within Web ecologies are not very well understood. The visualization system presented in this paper pushes the capabilites of current Web analysis programs in the amount of data it is able to handle as well as making the evolutionary patterns of Web ecologies more apparent. As the World Wide Web continues to grow in the number of users and the number of documents made accessible, the problem of understanding the correlations between the producers of the information, the charateristics of the information, and the users of the information will most likely remain. While the Time Tube was able to address several real world analysis scenarios that are not possible with other systems, we look forward to expanding the capabilites of the Time Tube, and as a result, our understanding of Web ecologies and other time-dependent document ecologies. Published in Proceedings of the SIGCHI Conference on Human Factors in Computing Systems 1998. Paper available at: http://www.cs.umn.edu/~echi/papers.html Joint work with James Pitkow, Jock Mackinlay, Peter Pirolli, Rich Gossweiler, Stuart K. Card ____________________________________________ Chris Williams Berkeley Multimedia Research Center (BMRC) http://bmrc.berkeley.edu/ 626 Soda Hall #1776 University of California Berkeley, CA 94720-1776 Phone: (510) 643-0800 FAX: (510) 642-5615 Email: cwilliams@bmrc.berkeley.edu From rem-conf Thu Aug 27 14:46:43 1998 From rem-conf-request@es.net Thu Aug 27 14:46:42 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zC9jb-0001ja-00; Thu, 27 Aug 1998 14:37:35 -0700 Received: from hercules.cs.ucsb.edu [128.111.41.30] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zC9ja-0001jQ-00; Thu, 27 Aug 1998 14:37:34 -0700 Received: from jackson.cs.ucsb.edu (almeroth@jackson [128.111.52.10]) by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id OAA18463; Thu, 27 Aug 1998 14:37:07 -0700 (PDT) Received: by jackson.cs.ucsb.edu (8.8.8+Sun/SMI-SVR4) id OAA10108 for ; Thu, 27 Aug 1998 14:37:03 -0700 (PDT) Date: Thu, 27 Aug 1998 14:37:03 -0700 (PDT) From: almeroth@cs.ucsb.edu (Kevin C. Almeroth) Message-Id: <199808272137.OAA10108@jackson.cs.ucsb.edu> To: almeroth@cs.ucsb.edu Subject: 42nd IETF on IMJ X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list (lists bcc'ed to prevent accidents). *** Announcing Availability of the 42nd IETF Sessions on the IMJ I'm ready to announce that most of the sessions from the 42nd IETF in Chicago, IL that were transmitted on the MBone are now available on the IMJ (http://imj.gatech.edu) for on-demand playback The IETF isn't over yet but sessions will be made available as soon as the sessions are over. You can schedule programs via the WWW page and start the MBone sessions via SDR (or the WWW page with a simple plug-in). For additional information about the MBone see http://mbone.com. The big challenge this time around was to digitally record all of the sessions. That went almost flawlessly. A big thanks go to Evi Nemeth and the MBone support staff for helping out. Now, instead of having to convert everything from VHS tape to rtpdump format we were able to record everything straight to rtpdump format. Notice the quick turnaround time... sessions are now available within days after actually occuring. The one interesting challenge is that I don't want to replay all the RTCP data in those files... well, because those people and their reported losses, etc. aren't really part of the session. I modified the rtpplay script to not play back any RTCP from the file but this also includes RTCP packets about the source... so the IMJ source does not resolve to a name. A subtle artifact, but something to work on for next time. For the record, the plan is to have the last 3 sets of IETF meetings archived on the MBone. We've got the last three available now: 40th, 41st, and 42nd. Future plans in regard to content include making talks from conferences available as well. I'm working on some angles here. Also, A NEW SERVICE has been started for those who want access to the source files themselves. The latest batch of IETF files are available at ftp://FTP.cc.gatech.edu/pub/people/kevin/. Please be gentle on the ftp server since these files are around 100 MB for video and 40 MB for audio. And finally, one interesting characteristic of the IMJ that most of you won't notice but is interesting is that we now have three servers on the back end of the IMJ. There are two servers at Georgia Tech and one at UCSB. The exact location of playout will depend on the request and where the content is located. There is no duplication of content, and this "distributed playout" system was implemented as a first step of a new project and because we ran out of disk space at Georgia Tech. Finally, and as usual, I've included the original IMJ e-mail announcement for those who want additional information about the IMJ. Any suggestions for improvement are welcome. -Kevin **** Announcing the Interactive Multimedia Jukebox At one point on the MBone list there was a discussion of what on-demand servers exist or are being developed. Well, I'd like to announce our version called the Interactive Multimedia Jukebox (IMJ). The IMJ web page is a request and scheduling interface for the playout of content over the MBone. CONTENT IS ENCODED SO THAT IT CAN BE RECEIVED WITH THE LATEST VERSIONS OF VIC AND VAT (ANY PLATFORM). Also check out mcontrol (http://imj.ucsb.edu/mcontrol/) a new MBone VCR tool for real-time broadcasts written in Java. A parallel effort, called PicPat, uses Tcl/Tk (http://www.cc.gatech.edu/fac/Mostafa.Ammar/picpat/). The IMJ page is located at http://imj.gatech.edu. Information about the IMJ including general info, a postscript version of a paper about the IMJ, how-to-use information, and how it was implemented can be found at http://www.cc.gatech.edu/computing/Telecomm/IMJ/. (Recent note: the paper will be appearing in the WWW7 conference in Brisbane, Australia) Some quick additional information about the IMJ is included below: IMJ Audio/Video ----------------- The IMJ uses the WWW to submit requests which are then scheduled for playout on the MBone. Right now we are offering three channels: Channels 1 and 2 are being broadcast at a TTL of 127. Channel 3 is for internal testing and has a a TTL of 15. Each channel provides DVI-2 audio and 128 Kbps H.261 video. The encoding was done using Henning Schulzrinne's rtpplay and rtpdump. Scheduling ---------- Program scheduling uses a set of criteria to decide on which channel to schedule a program. The current set of criteria are listed just below the interactive schedule. We are exploring lots of different options. Content ------- We have been working on the jukebox paradigm with Turner Broadcasting, and as a result of their interest they have agreed to let us broadcast content on the MBone. I am particularly excited about this aspect because of their help and interest in investigating new applications on the Internet. The plan is to add a new set of content about every two weeks. When this happens, the old content will be moved to the secondary request menu for two weeks. The old-old stuff will be removed. Hopefully I'll be able to advertise on the MBone list when the new stuff is available. Development Platform -------------------- As is mentioned in the paper on the IMJ information page we are using the IMJ as a platform for a variety of research issues including providing interactivity, supporting multiple heterogeneous streams, video server organization, tracking usage, program scheduling, and pricing. Acknowledgments ---------------- In addition to Turner Broadcasting, several other groups have made the IMJ possible. The GT Broadband Telecommunications Center sponsored much of the research and some of the equipment, and GT Office of Information Technology offered technical assistance and additional equipment. Please send any feedback or suggestions to almeroth@cs.ucsb.edu or kevin@cc.gatech.edu. From rem-conf Fri Aug 28 01:08:37 1998 From rem-conf-request@es.net Fri Aug 28 01:08:36 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zCJTr-00071m-00; Fri, 28 Aug 1998 01:01:59 -0700 Received: from dxmint.cern.ch [137.138.26.76] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zCJTp-0006qO-00; Fri, 28 Aug 1998 01:01:58 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch (8.8.8/8.8.8) with SMTP id JAA15834; Fri, 28 Aug 1998 09:57:05 +0200 (MET DST) Received: from localhost by dxcoms.cern.ch (5.65v4.0/1.1.10.5/15Nov97-1020AM) id AA22125; Fri, 28 Aug 1998 09:57:04 +0200 Date: Fri, 28 Aug 1998 09:57:04 +0200 (MET DST) From: Martin Fluckiger To: rem-conf@es.net, hepnet-l@slacvm.slac.stanford.edu, HRC@in2p3.fr, htasc@listbox.cern.ch, net-teleconferencing@listbox.cern.ch Cc: Martin Fluckiger Subject: MBone broadcast of the LHCC session on 3rd Sept. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list CERN is pleased to announce the MBONE broadcast of the LARGE HADRON COLLIDER COMMITTEE Session --------------------------------------- on Thursday 3rd of September from the CERN Main Auditorium OPEN SESSION: 9.00 - 9.10 Status of the LHC project (C. Llewellyn Smith) 9.15 - 10.00 ALICE status report (J. Schukraft) 10.15 - 10.45 COFFEE BREAK 10.45 - 11.30 ALICE HMPID TDR (G. Paic, F. Piuz) The broadcast is announced via sdr as "CERN LHCC". vat and vic applications will be used with a ttl of 127. The sessions will also be recorded using the wrtp application. They can be downloaded from our vod server: http://sunmed2.cern.ch/cgi-bin/nph-MBone-sessions/ In case of questions or problems please contact: multicast@noc.cern.ch This message is sent to distribution lists, sorry if you receive multiple copies of it. Best regards, -------------------------------------------------------------------- Martin Fluckiger & Christian Isnard CERN - IT/CS/EN multicast@noc.cern.ch European Laboratory for Particle Physics Computers and Networks division CH-1211 Geneva 23 - Switzerland From rem-conf Fri Aug 28 02:56:07 1998 From rem-conf-request@es.net Fri Aug 28 02:56:06 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zCLDe-0000hd-00; Fri, 28 Aug 1998 02:53:22 -0700 Received: from network2.cs.usm.my [161.142.8.104] (sunthar) by mail1.es.net with esmtp (Exim 1.81 #2) id 0zCLDc-0000hT-00; Fri, 28 Aug 1998 02:53:20 -0700 Received: from localhost (sunthar@localhost) by network2.cs.usm.my (8.8.7/8.8.7) with SMTP id RAA03462 for ; Fri, 28 Aug 1998 17:53:37 +0800 Date: Fri, 28 Aug 1998 17:53:37 +0800 (MYT) From: "S.Sunthar" To: rem-conf@es.net Subject: unsubcribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list unsubcribe From rem-conf Sat Aug 29 12:40:23 1998 From rem-conf-request@es.net Sat Aug 29 12:40:22 1998 Received: from list by mail2.es.net with local (Exim 1.92 #1) for rem-conf-dist@es.net id 0zCqeZ-0005TU-00; Sat, 29 Aug 1998 12:27:15 -0700 Received: from stn-on2-174.netcom.ca ([207.181.100.174] helo=mgajcvvcpsy) by mail2.es.net with smtp (Exim 1.92 #1) id 0zCqeX-0005T7-00; Sat, 29 Aug 1998 12:27:13 -0700 DATE: Tue, 08 Sep 1998 15:25:23 -0500 Message-ID: Subject: 99 Toyotas as low as 2% over invoice From: accutone@bellsouth.net To: $user@fuyi.es.net Reply-To: accutone@bellsouth.net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please accept our appologies for your inconvenience if you are not interested in this e-mail offer. If you are interested in a new 99' toyota car, truck, or van at prices as low as 2% over invoice on selected models and/or huge savings on pre-owned certified toyotas as well as 100's of other pre-owned vehicles of all makes and models below kelly blue book, please respond with your name, phone #, e-mail address and the specific model you are interested in. We thank you for your time. please accept our appologies for the intrusion and de-select yourself from our mailing list if not interested. Thank you. From rem-conf Sun Aug 30 23:46:09 1998 From rem-conf-request@es.net Sun Aug 30 23:46:09 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zDNR8-0000f2-00; Sun, 30 Aug 1998 23:27:34 -0700 Received: from nscolmar.colmar.uha.fr [194.167.108.34] by mail1.es.net with smtp (Exim 1.81 #2) id 0zDNQZ-0000ec-00; Sun, 30 Aug 1998 23:27:04 -0700 Received: by nscolmar.colmar.uha.fr; (5.65v3.2/1.3/10May95) id AA14891; Mon, 31 Aug 1998 08:16:24 +0200 Message-Id: <3.0.5.32.19980831083049.00798770@colmar.colmar.uha.fr> X-Sender: conf@colmar.colmar.uha.fr X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 31 Aug 1998 08:30:49 +0200 To: conf@colmar.colmar.uha.fr From: conf@colmar.uha.fr (by way of conf@colmar.colmar.uha.fr) Subject: Call for papers of ICATM'99 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Colleague, We have enclosed the CFP for ICATM'99 below. Please feel free to circulate the CFP to interested colleagues. Please accept our sincere apologies if you receive multiple copies of this CFP. Best regards, __________________________________________________________________________ PRELIMINARY CALL FOR PAPERS 2nd International IEEE Conference on ATM ICATM'99 June 21-23, 1999 - Colmar, France GENERAL INFORMATION ICATM'99 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 Monday June 21, 1999 to Wednesday June 23, 1999. 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. In order to encourage closer interaction between academic and industrial ATM research communities, we solicit both academic research papers and industrial contributions. TOPICS OF SPECIAL INTEREST Topics of interest include, but are not limited to the following: MPOA LAN Emulation IP over ATM, IPv6 over ATM VLANs High-Speed Routing I-PNNI NHRP Java, Tina, Corba architectures Interconnection CTI (Computer Telephony Integration) IP Switching, MPLS, Tag Switching, Fast IP, Aris ... Multicast ATM and Internet/Intranet Wireless ATM (LEO, MEO, GEO, from GSM to UMTS and IMT2000, Hyperlan2, ...) IP and ATM over xDSL Security IP and ATM Telephony Video (Davic, ...) Practical experiences results User applications QoS WDM Scheduling Resource allocation These topics can be discussed in term of concepts, state of the art, standards, implementations, performance, security and confidentiality, traffic management, running experiments, QoS (Quality of Service) and applications. INSTRUCTIONS FOR AUTHORS Mail four papers versions 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, 1998 with notification of acceptance by February 10, 1999. Submission of camera-ready paper is by March 30, 1999. Authors of accepted papers will be invited to submit full-length manuscripts for inclusion in the proceedings. All submitted papers should be sent to the following address: Pascal LORENZ University of Haute Alsace IUT - Department GTR 34 rue du Grillenbreit 68008 Colmar, France Phone: 33 (0)389202366 Fax: 33 (0)389202359 Mobile: 33 (0)603658042 E-mail: lorenz@colmar.uha.fr Check our Web page at http://iutsun1.colmar.uha.fr/ICATM99.html for the latest information concerning the conference. Best papers will be forwarded for consideration in a special issue of the journal Telecommunication Systems published by Baltzer Science Publishers. TUTORIALS AND WORKSHOPS Tutorials and workshops provide overviews of current high interest topics. Proposals for half of full day tutorials are due by December 10, 1999. ORGANIZATION OF ICATM'99 International Advisory Committee: R. Addie (Australia) - University of Southern Queensland K. Begain (Jordan) - Mu'tah University B. Bing (Singapore) - Ngee Ann Polyechnic D. Bonjour (France) - CNET A. Brandwajn (USA) - University of California Santa Cruz J.P. Coudreuse (France) - Mitsubishi J. Crowcroft (UK) - University College London B. Gavish (USA) - Vanderbilt University J. Halpern (USA) - Newbridge R. Israel (France) - IEEE S. Komandur (USA) - Ascend Communications D. Kouvatsos (UK) - University of Bradford S. Kumar (USA) - Ericsson F. Le Faucheur (France) - Cisco P. Lorenz (France) - University of Haute Alsace J.J. Pansiot (France) - University of Strasbourg M. Potts (Switzerland) - Martel Z. Mammeri (France) - University of Le Havre S. Moyer (USA) - Bellcore R. Muraine (France) - Newbridge G. Pujolle (France) - University of Versailles-Saint-Quentin S. Rao (Switzerland) - Ascom A. Reid (UK) - British Telecom S. Ritzenthaler (France) - Newbridge P. Rolin (France) - ENST Bretagne R. Saracco (Italy) - CSELT G. Swallow (USA) - Cisco H. Tobiet (France) - Clemessy V.A. Villagra (Spain) - University of Madrid E. Vazquez Gallo (Spain) - University of Madrid IMPORTANT DATES Extended Abstract due: December 10, 1998 Notification of acceptance: February 10, 1999 Deadline for full-length camera-ready manuscript: March 30, 1999 From rem-conf Mon Aug 31 08:24:15 1998 From rem-conf-request@es.net Mon Aug 31 08:24:14 1998 Received: from list by mail1.es.net with local (Exim 1.81 #2) id 0zDVhN-0004uB-00; Mon, 31 Aug 1998 08:16:53 -0700 Received: from rolex.csc.ncsu.edu [152.1.213.197] by mail1.es.net with esmtp (Exim 1.81 #2) id 0zDVhL-0004tz-00; Mon, 31 Aug 1998 08:16:51 -0700 Received: (from rhee@localhost) by rolex.csc.ncsu.edu (8.8.4/UC02Jan97) id LAA02870 for rem-conf@es.net; Mon, 31 Aug 1998 11:16:49 -0400 (EDT) Date: Mon, 31 Aug 1998 11:16:49 -0400 (EDT) From: rhee@eos.ncsu.edu Message-Id: <199808311516.LAA02870@rolex.csc.ncsu.edu> To: rem-conf@es.net Subject: CFP for Internet Computing X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Call for Papers IEEE Internet Computing (http://www.computer.org/internet) ----------------------------------------------------------- Special Issue on Multimedia and Collaborative Computing over the Internet (March/April 1999). ------------------------------------------------------------ Submission deadline: 31 October 1998 Guest Editor: Injong Rhee Department of Computer Science North Carolina State University Raleigh, NC 27695-7534 Phone: 919-515-3305 Fax: 919-515-7925 WWW: www.csc.ncsu.edu/faculty/rhee email: rhee@csc.ncsu.edu The Internet is evolving to bring an integrated communication service supporting data, voice, and video to classrooms, workplaces, and homes. Using this enabling network infrastructure, novel computer-supported collaboration technologies are emerging to allow geographically dispersed groups of co-workers to conduct a range of work-related activities. This special issue covers these emerging technologies for Internet-based multimedia collaboration. Topics of interest for technical papers include: * long-distance collaboration tools, application-sharing tools, * user interface design for CSCW applications * synchronous and asynchronous collaboration techniques, * real-time multimedia delivery, * operating systems and network support for real-time collaboration, * techniques for handling user migration, * comparative studies of existing collaboration tools and technologies, * security and authentication methods for distributed collaboration, * algorithms for synchronization among multiple users in collaboration sessions, * multicast techniques for collaboration involving many participants, * techniques for handling heterogeneous user environments. We are especially interested in research papers that describe real Internet experiments using developed collaboration technologies. Work-in-progress papers describing the state of on-going research projects in multimedia collaboration are also encouraged. Papers should explicate the technical issues related to the Internet. Research papers should demonstrate the feasibility of the approach and describe the state of realization. Case studies and applied papers should discuss the key factors that made the system work and should also mention the pitfalls and problems encountered and how they may be overcome. Paper should explicate the technical issues related to the Internet. Research papers should demonstrate the feasibility of the approach and describe the state of realization. Case studies and applied papers should discuss the key factors that made the system work and should also mention the pitfalls and problems encountered and how they may be overcome. Submission, Approval, Review, and Acceptance. --------------------------------------------- The submission process for IC differs from other IEEE Computer Society publications. Authors should send e-mail to a member of the IC Editorial Board (rhee@csc.ncsu.edu), giving a URL where the editor can review the article, preferably in HTML format with GIF artwork (postscript or pdf format is also accepted). Upon approval by a member of the Editorial Board, all feature articles will then undergo a technical peer review consistent with other archival publications. Articles for review should be in HTML or a common format easily read by reviewers. Authors will send all files to an anonymous ftp site provided by the IC managing editor in the Computer Society's publications office. When an article consists of a collection of HTML and GIF files, all internal links pointing to this file should be relative. More information about submission guideline can be found in http://www.computer.org/internet/edguide.htm