From rem-conf-request@es.net Mon Aug 01 02:19:30 1994 Received: from june.cs.washington.edu by osi-west.es.net via ESnet SMTP service id <18513-0@osi-west.es.net>; Sun, 31 Jul 1994 23:18:48 +0000 Return-Path: Received: (glinert@localhost) by june.cs.washington.edu (8.6.9/7.2ju) id XAA11235; Sun, 31 Jul 1994 23:10:48 -0700 Date: Sun, 31 Jul 1994 23:10:48 -0700 From: glinert@cs.washington.edu (Ephraim P. Glinert) Message-Id: <199408010610.XAA11235@june.cs.washington.edu> To: end2end-interest@venera.isi.edu, f-troup@AURORA.CIS.UPENN.EDU, ietf@venera.isi.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, rem-conf@es.net, sig11@roses.stanford.edu, sound@PASCAL.ACM.ORG, tccc@cs.umass.edu, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com Subject: Advance Program - ASSETS '94 Cc: glinert@cs.washington.edu /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ADVANCE PROGRAM AND REGISTRATION FORMS ASSETS '94 The First Annual International ACM/SIGCAPH Conference on Assistive Technologies October 31 - November 1, 1994 Doubletree Hotel Marina del Rey, California Sponsored by the ACM's Special Interest Group on Computers and the Physically Handicapped, ASSETS '94 is the first of a new annual series of conferences whose goal is to provide a forum where researchers and developers from academia and industry can meet to exchange ideas and report on new developments relating to computer-based systems to help people with impairments and disabilities of all kinds. This announcement includes 5 parts: o ASSETS '94 Advance Program o ASSETS '94 Registration Form o Hotel and Travel Arrangement Information o ACM / SIGCAPH Membership Application o Who are the organizers of ASSETS '94? If you have any questions or would Ephraim P. Glinert like further information, please Dept. of Computer Science contact the ASSETS '94 Program Chair: R. P. I. Troy, NY 12180 E-mail: glinert@cs.rpi.edu /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ASSETS '94 ADVANCE PROGRAM ========================== SUN 10/30: 18:00-21:00 Registration 19:00-21:00 Reception MON 10/31: 8:00-17:00 Registration 8:00- 9:00 Continental Breakfast 8:45- 9:00 Welcome to ASSETS '94! 9:00-10:00 Keynote I 10:00-10:30 Break 10:30-12:00 Papers I: Hearing Impairments "Pattern Recognition and Synthesis for Sign Language Translation System" Masaru Ohki, Hirohiko Sagawa, Tomoko Sakiyama, Eiji Oohira, Hisashi Ikeda and Hiromichi Fujisawa - Hitachi (Japan) "Multimedia Dictionary of American Sign Language" Sherman Wilcox and Joanne Scheibman - University New Mexico (USA) Doug Wood - Brains Software (USA) William C. Stokoe - Linstok Press (USA) "A System for Teaching Speech to Profoundly Deaf Children using Synthesized Acoustic and Articulatory Patterns" Elizabeth Keate, Hector Javkin, Norma Antonanzas-Barroso and Ranjun Zou - Panasonic Technologies (USA) 12:00-14:00 Lunch + SIGCAPH Business Meeting 14:00-15:00 Papers II: Augmentative Communication A "Iconic Language Design for People with Significant Speech and Multiple Impairments" Shi-Kuo Chang, P. L Albacete and G. Polese - University of Pittsburgh (USA) B. Baker - Semantic Compaction Systems (USA) "The Application of Spatialization and Spatial Metaphor to Augmentative and Alternative Communication" Patrick Demasco, U. Delaware (USA), Alan F. Newell and John L. Arnott - University of Dundee (UK) 15:00-15:30 Break 15:30-17:30 Papers III: Vision Impairments A "Screen Reader/2: Access to OS/2 and the Graphical User Interface" Jim Thatcher - IBM Research (USA) "Providing Access to Graphical User Interfaces - Not Graphical Screens" W. Keith Edwards, Elizabeth D. Mynatt and Kathryn Stockton - Georgia Institute of Technology (USA) "Increasing Access to Information for the Print Disabled through Electronic Documents in SGML" Bart Bauwens, Jan Engelen and Filip Evenepoel - Katholieke Universiteit Leuven (Belgium) Tom Wesley and Chris Tobin - U. Bradford (UK) "Interactive Audio Documents" T. V. Raman, Digital Equipment Corporation (USA) David Gries, Cornell (USA) 18:00-21:00 Buffet Dinner + Keynote II 21:00-22:00 ASSETS '95 Organizational Meeting TUE 11/1: 8:00-12:00 Registration 8:00- 9:00 Continental Breakfast 9:00-10:00 Papers IV: Motor Impairments "An Overview of Programs and Projects at the Rehabilitation Research and Development Center" David L. Jaffe - Dept. of Veteran Affairs Medical Center (USA) "Using the Baby-Babble-Blanket for Infants with Motor Problems: A Case Study" Harriet J. Fell, Linda J. Ferrier, Hariklia Delta, Regina Peterson, Zehra Mooraj and Megan Valleau - Northeastern University (USA) 10:00-10:30 Break 10:30-12:00 Papers V: Vision Impairments B "Personal Guidance System for the Visually Impaired" Jack M. Loomis and Reginald G. Golledge - University of California at Santa Barbara (USA) Roberta L. Klatzky, Carnegie Mellon (USA) Jon M. Speigle and Jerome Tietz - University of California at Santa Barbara (USA) "Hyperbraille: A Hypertext System for the Blind" Thomas Kieninger and Norbert Kuhn - Deutsches Forschungszentrum fuer Kuenstliche Intelligenz (Germany) "Automatic Impact Sound Generation for use in Nonvisual Interfaces" Helmut Schauer - University of Zurich (Switzerland) A. Darvishi, V. Guggiana, E. Munteanu, M. Motavalli and M. Rauterberg - Swiss Federal Institute of Technology/ETH (Switzerland) 12:00-14:00 Lunch + Panel (Elizabeth Mynatt, moderator) 14:00-15:00 Papers VI: Augmentative Communication B "A Writing Tool for Physically Disabled Individuals: Lexical Semantics for Filling in the Pieces" Kathleen F. McCoy, Patrick W. Demasco, Mark A. Jones, Christopher A. Pennington, Peter B. Vanderheyden and Wendy M. Zickus - University of Delaware (USA) "Validation of a Keystroke-Level Model for a Text Entry System Used by People with Disabilities" Heidi H. Koester and Simon P. Levine - University of Michigan (USA) 15:00-15:30 Break 15:30-17:30 Papers VII: New Directions and Work-in-Progress "An Experimental Sound-Based Hierarchical Menu Navigation System for Visually Handicapped Use of Graphical User Interfaces" Arthur I. Karshmer, Pres Brawner and George Reiswig - New Mexico State University (USA) "A Rule-Based System that Suggests Computer Adaptations for Users with Special Needs" William W. McMillan, Michael Zeiger and Lech Wisniewski - Eastern Michigan University (USA) "LVRS: The Low Vision Research System" Mitchell Krell, University of Southern Mississippi (USA) "EEG as a Means of Communication: Preliminary Experiments in EEG Analysis using Neural Networks" Charles W. Anderson, Saikumar V. Devulapalli and Erik Stolz - Colorado State University (USA) "Audio Formatting of a Graph" Sophie H. Zhang and Mukkai Krishnamoorthy - Rensselaer Polytechnic Institute (USA) "Disabilities, Opportunities, Internetworking and Technology (DO-IT) on the Electronic Highway" Sheryl Bergstahler and Dan Comden - University of Washington (USA) 17:30 Close ASSETS '94 REGISTRATION FORM ############################################# ============================ This form is 2 pages long. Please print it out, complete both pages and mail it WITH FULL PAYMENT to: Ephraim P. Glinert, ASSETS '94 Dept. of Computer Science R. P. I. Troy, NY 12180 We're sorry, but e-mail registration forms and/or forms not accompanied by full payment (check or credit card information) CANNOT be accepted. CONFERENCE REGISTRATION FEES EARLY LATE / ON-SITE -------------------------------------------------------- ACM member: $ 395 $ 475 Nonmember: $ 580 $ 660 Full time student: $ 220 $ 270 -------------------------------------------------------- 1: CONFERENCE REGISTRATION (from the table): $ ___________ 2: EXTRA RECEPTION TICKET (Monday, Oct. 31): $ 40 ___YES ___NO 3: EXTRA COPY OF THE CONFERENCE PROCEEDINGS: $ 30 ___YES ___NO TOTAL AMOUNT DUE: $ ___________ NOTES: o Registration fee includes: ADMISSION to all sessions, one copy of the conference PROCEEDINGS, and MEALS as indicated in the program above. o To qualify for the EARLY rate, your registration must be postmarked on or before FRIDAY, SEPTEMBER 23, 1994. If you are an ACM MEMBER, please supply your ID# __________________ (OR use the membership application below to join ACM and SIGCAPH today!). STUDENTS, please attach a clear photocopy of your valid student ID. o CANCELLATIONS will be accepted up to FRIDAY, OCTOBER 14, 1994 subject to a 20% handling fee. ASSETS '94 REGISTRATION FORM (continued) ======================================== PERSONAL INFORMATION: Name __________________________________________________________________________ Affiliation ___________________________________________________________________ Address _______________________________________________________________________ City _______________________________ State/Province __________________________ Country __________________________________ Zip/Postal Code ___________________ E-mail ___________________________________ Telephone _________________________ ***I have a disability for which I require special accommodation ___YES ___NO If YES, please attach a separate sheet with details. Thank you! PAYMENT INFORMATION: ___CHECK in U.S. funds enclosed, made payable to "ACM ASSETS '94" ___Please charge $ ___________ to my CREDIT CARD: Card type: ___AMEX ___VISA ___MasterCard Card # _______________________________________ Expiration Date ___________ Name On Card ______________________________________________________________ Billing Address ___________________________________________________________ Cardholder Signature _______________________________________ (ASSETS '94) ############################################################################### HOTEL AND TRAVEL ARRANGEMENT INFORMATION ======================================== All conference events will take place at the Doubletree hotel in Marina del Rey (the precise address is 4100 Admiralty Way, Marina del Rey CA 90292). The hotel is located within easy driving distance of Los Angeles International Airport. A block of rooms for attendees of ASSETS '94 has been set aside at a special discounted rate of $86 per night (single or double), plus applicable taxes. To reserve space at this price, please call the hotel directly BEFORE OCTOBER 9 at (800) 353 6664 toll free, or (310) 301 3000, and refer to "ACM ASSETS '94". BIRKMAYER TRAVEL, the official travel agency for ASSETS '94, is offering discounted airfares to attendees on United, Delta and USAir. The terms vary for each airline, but in general discounts of up to 50% and more are available, and no Saturday night stay is required. Please note that the reduced fares apply only to travel within the continental United States or originating in Canada, that all prices are subject to change without notice, and fares are guaranteed only after tickets are actually purchased. Space is limited, and some restrictions apply. Please call Birkmayer Travel directly during normal East Coast business hours for further information/reservations: Birkmayer Travel, Inc. 2 Third Street Troy, NY 12180 Tel. (800) 338 5735 (continental U.S. and Canada) (518) 272 2650 (New York State and international) (518) 272 7257 (fax) Special discounted rates have also been arranged with HERTZ for attendees who wish to rent a car. For more information or to make reservations, just call Hertz Conference Services at 1 (800) 654 2240 and mention CV# 13646 (international attendees please contact your local Hertz office with this information). ACM / SIGCAPH MEMBERSHIP APPLICATION ==================================== USE THIS 2-PAGE FORM TO JOIN ACM + SIGCAPH TODAY AND SAVE ON CONFERENCE FEES! Please mark the appropriate box(es) and indicate total: ___ACM Associate Member Dues $82 (___Expedited Air Option: $32) ___ACM Student Member Dues $25 (___Expedited Air Option: $32) ___Add SIGCAPH to ACM Membership $15 (___Expedited Air Option: $3) ___Add SIGCAPH to ACM Student Membership $6 (___Expedited Air Option: $3) ___SIGCAPH Membership only (non-ACM) $42 (___Expedited Air Option: $3) ACM Membership No. (if applicable) ____________________ Total due: $__________ Membership in SIGCAPH includes a subscription to Computers and the Physically Handicapped newsletter (published three times a year) and discounted registration fees for any ACM sponsored CAPH conferences and publications. ACM Membership includes a full year's subscription to Communications of the ACM, substantial discounts on Publication Subscriptions, Conference Proceedings, Conference Registration, Special Interest Group (SIG) Memberships and the Member Value Plus program. You may join as an Associate Member and convert to Voting Member status by requesting a "Self Certification" form from ACM's Member Services Department. Purposes: To advance the sciences and arts of information processing; to promote the free interchange of information processing among computing specialists and the public; and to develop and maintain the integrity and competence of individuals engaged in the practice of information processing. As an ACM member, I subscribe to the purposes of ACM: Signature __________________________________________________ (___YES ___NO) ACM / SIGCAPH MEMBERSHIP APPLICATION (continued) ================================================ Name __________________________________________________________________________ Address ____________________________________ Telephone _______________________ City _______________________________ State/Province __________________________ Country __________________________________ Zip/Postal Code ___________________ E-mail ___________________________________ Fax _______________________________ PAYMENT INFORMATION: ___Check enclosed payable to "ACM, Inc." ___Please charge my Credit Card: Card type: ___AMEX ___VISA ___MasterCard Card #__________________________________________Expiration Date____________ Signature_______________________________________________________ (CAPH94) If you're completing this application online, please e-mail to: ACMHELP@ACM.org If you're printing this application out, please remit to: ACM P.O. Box 12115 Church St. Station New York, NY 10257 USA For inquiries regarding membership, contact the service center nearest you: ACM Member Services Department ACM European Service Center 1515 Broadway, 17th Floor Avenue Marcel Thiry 204 New York, NY 10036, USA 1200 Brussels, BELGIUM Phone: +1-212-626-0500 Phone: +32 2 774 9602 Fax: +1-212-944-1318 Fax: +32 2 774 9690 Email: ACMHELP@ACM.org Email: ACM_EUROPE@ACM.org WHO ARE THE ORGANIZERS OF ASSETS '94? ==================================== General Chair: Theodor D. Sterling, Simon Fraser University Program Committee: Norman Alm, University of Dundee Julie Baca, Waterways Experiment Station Meera M. Blattner, LLNL and U. California at Davis James L. Caldwell, IBM RISC Adaptive Technologies S.-K. Chang, University of Pittsburgh Patrick Demasco, University of Delaware Alistair D.N. Edwards, University of York Gerald L. Engel, National Science Foundation Carl Friedlander, ISX Corp. Hiromichi Fujisawa, Hitachi (Japan) Ephraim P. Glinert (Chair), RPI Ralph Guertin, MITRE Corp. Robert J.K. Jacob, Tufts University David L. Jaffe, Palo Alto VA Medical Center Earl Johnson, Sun Microsystems Labs Karen Kukich, Bell Communications Research Richard E. Ladner, University of Washington Clayton Lewis, University of Colorado at Boulder Elizabeth D. Mynatt, Georgia Inst. of Technology Randy Pausch, University of Virginia T.V. Raman, DEC Cambridge Research Laboratory Gregg C. Vanderheiden, TRACE Center at U. Wisconsin A. Rudy Vener, AT&T Bell Labs Bryant W. York, Northeastern University Treasurer: David H. Leserman, NOAA If you have any questions or would Ephraim P. Glinert like further information, please Dept. of Computer Science contact the ASSETS' 94 Program Chair: R. P. I. Troy, NY 12180 E-mail: glinert@cs.rpi.edu /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ From rem-conf-request@es.net Mon Aug 01 16:59:22 1994 Received: from research.ftp.com by osi-west.es.net via ESnet SMTP service id <22437-0@osi-west.es.net>; Mon, 1 Aug 1994 13:58:53 +0000 Received: by Research.Ftp.Com (931110.SGI/) for rem-conf@es.net id AA07801; Mon, 1 Aug 94 16:53:36 -0400 Received: by Research.Ftp.Com id AA07801; Mon, 1 Aug 94 16:53:36 -0400 Date: Mon, 1 Aug 1994 16:53:35 +0059 (EDT) From: Frank Kastenholz Subject: rtp comments To: casner@isi.edu Cc: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII steve, i've finally had a chance to read through the rtp document, draft-ietf-avt-rtp-05.ps. here are my comments. most of them are editorial in nature... (if some of these are things which have already been thrashed out in the wg or the mailing lists, i apologise ahead of time and feel free to inform me of this in no uncertain terms :-) first, figure 1, on page 6, is very confusing. it should be broken up, with little figures and the little figures co-located with the text that describes the concept which the figure illustrates. also, in the figure, there are some numbers which are not obviously related to anything -- for example, in the upper-left of the figure, there is an E1:17 - what's the 17? where does it come from? what does it mean? etc... with respect to translators (section 2.3) - is this really that important? the goal of the ietf is to build the internet, not write standards (ah, that's why i asked that question in the iesg meeting last week! :-) and it would seem to me that translators are more for 'writing standards' and less for 'the-ip-on-everything-internet'. as a design/architecture point, i'd probably tend to make decisions favoring operations over pure-ip vs being nice to translators. re bridges -- this name is confusing. whenever i pick up the document it takes a moment for my brain to make the context switch from '802.1 mac bridges' to 'rtp bridges'. i'd suggest changing the name if possible. (the document says that the term is common in the telecommunications industry. we're not in the telecomms industry...) on page 8, the second paragraph from the bottom, beginning "A recorder records RTP..." this paragraph is confusing. the last sentence can sort of be taken to mean that timestamps can be encrypted but not the data (which is a) probably not what you mean to say and b) would be silly). i assume that a recorder's function is to record packets and then re-transmit them later on? it does not actually say this in the 'graf. or am i very very very confused? i'm not sure that i like the extension header bit. why not use the SIPP chained header scheme? it should not cost any more or less wrt to bandwidth or processing power. and this will give the added architectural flexibility of allowing someone to use multiple 'extended headers', if they (are silly enough to) wish to, and are willing to pay the cost. i am concerned about the marker bit. i believe that it may be extraneous. consider. for all intents and purposes, rtp packets will be carried over udp (or similar) services. udp does not provide a guaranteed service (ala tcp). so, the packet with the M bit set may be lost in the network. therefore, one can not rely on getting the M bit when one is supposed to. if the M bit has a vital role in the system, then one will have to develop a more robust method of signalling the information that the M bit is supposed to be signalling. if the M bit's role is not vital, then it is nothing more than a minor hint -- one which i may not even pay attention to... on page 15, for the rtcp packet length. why is this in 4-byte words? the length field is 16 bits. is it possible that an rtcp packet can be longer than 65535 bytes? if so, i'd respectfully suggest that there is a design problem someplace. why doesn't the reception report indicate the number of bytes received? this would be a reasonable indication of the bandwidth that is getting through to the receiver, and the sender could then make adjustements as appropriate. is it reasonable to use 1/65535 of a second for the units of the 'delay since last sr' value? most systems can do milliseconds or the like. doing the conversion adds overhead that's really not needed. even more, the conversion would, no doubt, be done simply: take the millisecond difference and multiply by 65, or perhaps even just shift-left by 6 bits -- multiply by 64. for the sender and receiver report packets, how often should they be sent? real numbers are required here. i'd consider adding a phone number to the sdes items. this way i could call up the source and try to get things fixed if they are broken... instead of a c enum, please explicitly assign values to the various enumerated values (rtcp types, sdes elements, etc). Frank Kastenholz From rem-conf-request@es.net Mon Aug 01 23:07:34 1994 Received: from sirius.ctr.columbia.edu by osi-west.es.net via ESnet SMTP service id <23445-0@osi-west.es.net>; Mon, 1 Aug 1994 20:06:55 +0000 Received: from gauss.ctr.columbia.edu (zhang@gauss.ctr.columbia.edu [128.59.74.14]) by sirius.ctr.columbia.edu (8.6.7/8.6.4.287) with ESMTP id XAA18079; Mon, 1 Aug 1994 23:06:25 -0400 From: zhang@ctr.columbia.edu (Zhensheng Zhang) Received: (zhang@localhost) by gauss.ctr.columbia.edu (8.6.7/8.6.4.788743) id XAA21834; Mon, 1 Aug 1994 23:06:22 -0400 Date: Mon, 1 Aug 1994 23:06:22 -0400 Message-Id: <199408020306.XAA21834@gauss.ctr.columbia.edu> To: end2end-interest@venera.isi.edu, f-troup@aurora.cis.upenn.edu, ietf@venera.isi.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, rem-conf@es.net, sig11@roses.stanford.edu, sound@pascal.acm.org, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com Subject: job opportunity at InterDigital InterDigital Join the team that's developing the communication technology of the future. We are a leading edge, high technology wireless communications firm with proven technical leadership skills. Experience in Communication System Engineering is required, with an emphasis on Spread Spectrum and Cellular Telephony. The ideal candidate shall have background in one or more of the following area: Communication Nets and Protocols, ATM, Switching and Mobility Management, Systems Analysis and Simulation, Detection, Estimation and Filtering, Operation Research. Our aggressive technical agenda requires motivated people with excellent communications skills. Commercial product development experience is desired. MS or equivalent experience required, Ph.D preferred. Individuals please send resume to Dr. Emmannuel Kanterakis InterDigital Communications Corporation 833 Northern Boulevard Great Neck, NY 11021 Fax: (516) 466-0766 Equal Opportunity Employer From rem-conf-request@es.net Tue Aug 02 00:00:30 1994 Received: from glare.cisco.com by osi-west.es.net via ESnet SMTP service id <23576-0@osi-west.es.net>; Mon, 1 Aug 1994 20:59:41 +0000 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by glare.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id UAA09843; Mon, 1 Aug 1994 20:53:25 -0700 Message-Id: <199408020353.UAA09843@glare.cisco.com> X-Authentication-Warning: glare.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: Zhensheng Zhang Cc: end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, ietf@isi.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, rem-conf@es.net, sig11@roses.stanford.edu, sound@pascal.acm.org, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com Subject: Re: job opportunity at InterDigital In-Reply-To: Your message of "Mon, 01 Aug 1994 23:06:22 EDT." <199408020306.XAA21834@gauss.ctr.columbia.edu> Date: Mon, 01 Aug 1994 20:53:24 -0700 From: David Getchell From rem-conf-request@es.net Tue Aug 02 10:25:41 1994 Received: from relay.nswc.navy.mil by osi-west.es.net via ESnet SMTP service id <25692-0@osi-west.es.net>; Tue, 2 Aug 1994 07:25:13 +0000 Received: from sunoco.nswc.navy.mil by relay.nswc.navy.mil (4.1/SMI-4.1) id AA15766; Tue, 2 Aug 94 10:25:03 EDT Received: from timewarp.b35ita.sunoco by sunoco.nswc.navy.mil (5.0/SMI-SVR4) id AA01523; Tue, 2 Aug 1994 10:25:07 +0500 Received: by timewarp.b35ita.sunoco (5.0/SMI-SVR4) id AA03261; Tue, 2 Aug 1994 10:25:05 +0500 Date: Tue, 2 Aug 1994 10:25:05 +0500 From: pirey%sunoco@relay.nswc.navy.mil (Phil Irey) Message-Id: <9408021425.AA03261@timewarp.b35ita.sunoco> To: rem-conf@es.net Subject: Multicast support for Ultrix 4.4 X-Sun-Charset: US-ASCII Content-Length: 320 Is there a version of the IP multicast for Ultrix 4.4? The distribution on gregorio.stanford.edu is for Ultrix 4.2a and may possbily work on 4.3. A note on the mbone list said there were some problems compiling this version on 4.3 and kernel source may be required. We don't have a source distribution. thanks, phil From rem-conf-request@es.net Tue Aug 02 13:32:12 1994 Received: from rain.org by osi-west.es.net via ESnet SMTP service id <26450-0@osi-west.es.net>; Tue, 2 Aug 1994 10:31:41 +0000 Received: by rain.org (4.1/25-eef) id AA01228; Tue, 2 Aug 94 10:28:51 PDT Date: Tue, 2 Aug 1994 10:28:50 -0700 (PDT) From: John Lynch Subject: cuseeme To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII How can I get more information on cuseeme video conferencing developed by cornell John Lynch From rem-conf-request@es.net Tue Aug 02 15:26:56 1994 Received: from research.ftp.com by osi-west.es.net via ESnet SMTP service id <27215-0@osi-west.es.net>; Tue, 2 Aug 1994 12:26:28 +0000 Received: by Research.Ftp.Com (931110.SGI/) for rem-conf@es.net id AA09945; Tue, 2 Aug 94 15:21:29 -0400 Received: by Research.Ftp.Com id AA09945; Tue, 2 Aug 94 15:21:29 -0400 Date: Tue, 2 Aug 1994 15:21:29 +0059 (EDT) From: Frank Kastenholz Subject: glitches in the rtp document To: casner@isi.edu, rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII the 'c' source code in the rtp document, appendix a, does not match the packet headers in the main body of the document. the SR packet has fields in the order ssrc ntp timestamp (ms) ntp timestamp (ls) rtp timestamp packet count bytecount yet the c code defines this packet as rtp timestamp ssrc ntp timestamp (ms) ntp timestamp (ls) the rtcp_rr_t structure does not include the ssrc the RR receiver report structure in 'graf 6.4 has two ssrc fields at the head of the packet. it is not clear what 'ssrc' is for (as opposed to 'ssrc_[123...]'. furthermore, the 'c' code in appendix a includes an 'rtp_ts" field for the RR structure which does not appear in section 6.4 the 'c' definition of the format structure is missing the 'reserved', 'rtp-pt', and 'ssrc' fields. Frank Kastenholz From rem-conf-request@es.net Tue Aug 02 21:37:40 1994 Received: from Sun.COM by osi-west.es.net via ESnet SMTP service id <29119-0@osi-west.es.net>; Tue, 2 Aug 1994 18:37:11 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA09449; Tue, 2 Aug 94 18:37:09 PDT Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA12785; Tue, 2 Aug 94 18:37:25 PDT Received: by auckland.Eng.Sun.COM (5.0/SMI-SVR4) id AA01160; Tue, 2 Aug 1994 18:36:02 +0800 Date: Tue, 2 Aug 1994 18:36:02 +0800 From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson) Message-Id: <9408030136.AA01160@auckland.Eng.Sun.COM> To: rem-conf@es.net Subject: IETF multicast audio quality Reply-To: finlayson@Eng.Sun.COM X-Sun-Charset: US-ASCII Content-Length: 2856 > Date: Mon 1 Aug 94 19:39:52 PDT > From: Stephen Casner > Subject: Thanks to IETF multicast crew > To: IETF@CNRI.Reston.VA.US > Cc: oattes@rathaus.utcs.utoronto.ca > Mail-System-Version: > > While "thank you's" were being doled out at the start of the Thursday > evening session at IETF, I think Lee Oattes and the others on the > audio/video multicast crew were overlooked and I did not get a chance > to speak up at the time. Getting all that equipment set up requires a > lot of planning and work. > > In particular, I'd like to thank the camera operators for a job well > done. They really concentrated on keeping the camera zoomed in so the > viewgraph text would fill the video image and be readable. > > From the reports I heard while there, the transmission quality was > very good. Now that I've returned home and listened to the online > recordings I captured here of my two AVT sessions, I can confirm that. > Thanks, folks. As a remote viewer/listener, I agree with Steve Casner that the quality of the IETF multicast video was very good. However, I was less satisfied with the audio. The frequency of dropped packets (especially during the day) seemed higher than usual. This may have been due to our own firewall relay and/or internal routers, or it may have been due to traffic problems elsewhere in the network. But in any case, dropped audio packets tend to be very noticeable and annoying - much more so than video (at least, IETF-style video). Audio encoding is way outside my area of expertise, but I can't help but wonder if there isn't some way to make dropped audio packets less noticeable - e.g., by adding some redundancy to the audio stream. Obviously, you don't want to increase the bandwidth too much by doing this, and of course nothing can help you much if dropped packets tend to occur in clumps. Comments? I also found the variations in volume (especially between different speakers) to be annoying - I constantly found myself having to fiddle with vat's volume control. The problem was especially noticeable when Van was talking; he's softly-spoken, but always interesting to listen to :-) How do TV stations deal with this problem? Do they simply rely on there being a human flunky in the studio adjusting the audio gain in real time? Is there anything better we can do? BTW, for each of the IETF vat sessions, I set the conference/lecture 'bit' to "lecture" (from its default value of "conference"). I don't know how much perceptable improvement this makes in practice, but it's yet another annoying decision that's left to the human user. Why not have vat set this policy automatically, accoring to some heuristic? E.g., if the same speaker has been active for >= 5 minutes, assume "lecture" mode, otherwise assume "conference" mode. Ross. From rem-conf-request@es.net Thu Aug 04 03:31:40 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <05645-0@osi-west.es.net>; Thu, 4 Aug 1994 00:30:48 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <22777-0@ceres.fokus.gmd.de>; Thu, 4 Aug 1994 09:31:37 +0200 To: casner@isi.edu, kasten@Research.Ftp.Com Subject: Re: rtp comments Cc: rem-conf@es.net Date: Thu, 4 Aug 1994 09:31:37 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de Frank, thank you for your extensive comments. I'll try to address the technical issues here (and try to fix the editorial ones...). I'm sure Steve, Ron or Van will provide additional comments where needed. > > first, figure 1, on page 6, is very confusing. it should be broken up, > with little figures and the little figures co-located with the text that > describes the concept which the figure illustrates. also, in the figure, > there are some numbers which are not obviously related to anything -- for > example, in the upper-left of the figure, there is an E1:17 - what's the > 17? where does it come from? what does it mean? etc... There is a legend at the bottom right, but it would probably be appropriate to add some explanatory text. E1:17 means that media data comes from end system 1 and gets SSRC 17 slapped on. > > with respect to translators (section 2.3) - is this really that important? > the goal of the ietf is to build the internet, not write standards (ah, > that's why i asked that question in the iesg meeting last week! :-) and it > would seem to me that translators are more for 'writing standards' and > less for 'the-ip-on-everything-internet'. as a design/architecture point, > i'd probably tend to make decisions favoring operations over pure-ip vs > being nice to translators. Unfortunately, translators are a fact of life even if no other network protocol intrudes. They take the form of firewalls and filters (see paper in NOSDAV 94 paper by Hoffman et al.). For example, AT&T uses such a device to let hand-selected MBONE sessions into the internal network. With the choice of mandatory SSRC identifiers instead of optional ones as in earlier drafts, translators are handled more or less transparently, but they remain a useful concept, in my opinion. > > re bridges -- this name is confusing. whenever i pick up the document it > takes a moment for my brain to make the context switch from '802.1 mac > bridges' to 'rtp bridges'. i'd suggest changing the name if possible. > (the document says that the term is common in the telecommunications > industry. we're not in the telecomms industry...) We struggled with the name for a while and couldn't find a name which was descriptive, not a three-letter acronym and not otherwise occupied. Gateway was mentioned but has obvious other connotations. The term 'to bridge' is standard currency for folks doing mixing of audio and video. MCU is even worse, I'd say. RTP is sufficiently far removed from the data link layer, I hope... > > on page 8, the second paragraph from the bottom, beginning "A recorder > records RTP..." this paragraph is confusing. the last sentence can sort of > be taken to mean that timestamps can be encrypted but not the data (which > is a) probably not what you mean to say and b) would be silly). i assume > that a recorder's function is to record packets and then re-transmit them > later on? it does not actually say this in the 'graf. or am i very very > very confused? This should be clarified. It does, however, say "a recorder records RTP and RTCP packets for later playback", which is pretty much what you just said, or? The encryption problem is the opposite, actually: Ideally, a recorder should reconstruct the timing at the sender rather than any delay jitter accumulated. For that, it needs timestamps. The current encryption encompasses the whole packet, so I must hand the recorder the keys to the session in order to have the recorder play it back with the original timing. Usually, that's no problem, but there are situations where I want to have a technician/operator/etc. record a session, store it encrypted on some fileserver and then play it back, without handing the key to either storage server or technician. This case is probably infrequently enough that it was decided to handle untrusted recorders by forcing them to recreate the packet sequence as received, jitter and all. > > i'm not sure that i like the extension header bit. why not use the SIPP > chained header scheme? it should not cost any more or less wrt to > bandwidth or processing power. and this will give the added architectural > flexibility of allowing someone to use multiple 'extended headers', if > they (are silly enough to) wish to, and are willing to pay the cost. Indeed, that would be a reasonable alternative. It would mean setting aside some (how much?) payload type space for extension header types. The effort at the receiver seems to be equivalent: check bit/bytes to see if there's more header; if not, pass on directly to audio/video/... output, if so, parse next header. The limitation to a single extension is also somewhat convenient in that I know I only have to do a single step through extensions I don't know about. > > i am concerned about the marker bit. i believe that it may be extraneous. > consider. for all intents and purposes, rtp packets will be carried over > udp (or similar) services. udp does not provide a guaranteed service (ala > tcp). so, the packet with the M bit set may be lost in the network. > therefore, one can not rely on getting the M bit when one is supposed to. > if the M bit has a vital role in the system, then one will have to develop > a more robust method of signalling the information that the M bit is > supposed to be signalling. if the M bit's role is not vital, then it is > nothing more than a minor hint -- one which i may not even pay attention > to... For audio, the marker bit is indeed a hint. Missing one only delays playout delay adaptation by a talkspurt. That information is needed "in the long run", however, and must be carried somehow. At a number of points, RTP and RTCP relies on "eventual" reliability (if that's the appropriate term), meaning that the likelihood that a receiver will get the bit of information eventually is very high. The design of receivers must be such that they shouldn't fail if they don't get that information right away or miss a beat. > > on page 15, for the rtcp packet length. why is this in 4-byte words? the > length field is 16 bits. is it possible that an rtcp packet can be longer > than 65535 bytes? if so, i'd respectfully suggest that there is a design > problem someplace. Van suggested this optimization. Since the packet length can only be multiples of 4 bytes, there's no point in carrying around the lower two bits and (more importantly) checking them to make sure they are indeed zero. This does allow to RTCP packets to be longer than 65 k in theory. However, we specify that an RTP packet has to fit into one lower layer packet, which may be even less than 65 k. (Ideally, it should fit into one MTU, to avoid IP-level fragmentation.) What's the specific problem with allowing longer lengths? > > why doesn't the reception report indicate the number of bytes received? > this would be a reasonable indication of the bandwidth that is getting > through to the receiver, and the sender could then make adjustements as > appropriate. It would appear that the number of packets getting through would be a reasonable approximation. Since sequence numbers number packets, not bytes, receivers can only compute the expected number of packets, not bytes. Since video and audio data rates can vary dramatically, it's very difficult (except over very long time periods) to align byte counts and get good loss estimates. (The receiver would have to say that it got N bytes, starting at seq. # S1, with the last being # S2, and the sender > > is it reasonable to use 1/65535 of a second for the units of the 'delay > since last sr' value? most systems can do milliseconds or the like. doing > the conversion adds overhead that's really not needed. even more, the > conversion would, no doubt, be done simply: take the millisecond > difference and multiply by 65, or perhaps even just shift-left by 6 bits > -- multiply by 64. There was a basic decision to use NTP timestamps throughout, as I would have a hard time justifying having NTP units in one place, milliseconds in a second, fortnights in a third, etc. From what I can tell, to get below a second for Posix, you use gettimeofday() to get microseconds, which you would need to convert as well to get milliseconds. Milliseconds and kin are also a pain because they don't add and subtract as nicely as 2^N based units. (Subtracting or adding two timeval's requires "manual" carry into the seconds if the microseconds wrap.) > > for the sender and receiver report packets, how often should they be sent? > real numbers are required here. Indeed, that algorithm (function of estimate of others in session) is missing, as indicated. A minimal RTCP packet consists of SR/RR (depending on whether I have sent anything since the last one [or some small multiple thereof, yet to be specified]) and SDES. > > i'd consider adding a phone number to the sdes items. this way i could > call up the source and try to get things fixed if they are broken... Good idea, it seems to me. I'm sure those that see IP multicast as the likely successor to the phone system as we know it might object :-) > > instead of a c enum, please explicitly assign values to the various > enumerated values (rtcp types, sdes elements, etc). That was planned. Would you prefer a single table (easier to keep consistent) or list them with each description? Henning From rem-conf-request@es.net Thu Aug 04 03:37:04 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <05675-0@osi-west.es.net>; Thu, 4 Aug 1994 00:36:30 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <22782-0@ceres.fokus.gmd.de>; Thu, 4 Aug 1994 09:37:38 +0200 To: casner@isi.edu, rem-conf@es.net, kasten@Research.Ftp.Com Subject: Re: glitches in the rtp document Date: Thu, 4 Aug 1994 09:37:38 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de Frank, Thanks for the checking. > > > the 'c' source code in the rtp document, appendix a, does > not match the packet headers in the main body of the document. Indeed, I discovered the same while implementing RTPv2 for Nevot. This has been fixed. > > the RR receiver report structure in 'graf 6.4 has two ssrc fields > at the head of the packet. it is not clear what 'ssrc' is for (as opposed > to 'ssrc_[123...]'. This requires further explanation. It's the sender of the report vs. the source it reports about. (It seems to get messy to talk about receivers that send reports about data received from senders. Maybe we need some better terminology, like data senders or some such.) Henning From rem-conf-request@es.net Thu Aug 04 11:15:26 1994 Received: from NS1.CTC.COM by osi-west.es.net via ESnet SMTP service id <07203-0@osi-west.es.net>; Thu, 4 Aug 1994 08:14:56 +0000 Received: by server1.ctc.com (5.65/DEC-Ultrix/4.3) id AA09229; Thu, 4 Aug 1994 11:16:47 -0400 Received: by sgi11.ctc.com (931110.SGI/930416.SGI.AUTO) for @server1.ctc.com:rem-conf@es.net id AA06063; Thu, 4 Aug 94 11:16:45 -0400 From: Brian Antonishek Message-Id: <9408041116.ZM6061@sgi11.ctc.com> Date: Thu, 4 Aug 1994 11:16:43 -0400 Organization: Concurrent Technologies Corporation (CTC) Reply-To: antonis@ctc.com X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: rem-conf@es.net Subject: add to mailing list Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Please add me to your mailing list. I would like to find out about any broadcasts going on over MBONE this week. Thanks. -Brian antonis@ctc.com ---------------- Brian Antonishek antonis@ctc.com Concurrent Technologies Corporation Voice: (814) 269-2636 1450 Scalp Ave. FAX: (814) 269-2666 Johnstown, PA 15904 From rem-conf-request@es.net Thu Aug 04 23:52:09 1994 Received: from fafner.Stanford.EDU by osi-west.es.net via ESnet SMTP service id <10726-0@osi-west.es.net>; Thu, 4 Aug 1994 20:51:33 +0000 Received: (from mosedale@localhost) by fafner.Stanford.EDU (8.6.8.1/8.6.6) id UAA22750; Thu, 4 Aug 1994 20:51:28 -0700 From: Dan Mosedale Message-Id: <199408050351.UAA22750@fafner.Stanford.EDU> Subject: MolBio conference announce & questions To: mbone@isi.edu, rem-conf@es.net Date: Thu, 4 Aug 1994 20:51:27 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2011 The Second International Conference on Intelligent Systems for Molecular Biology Stanford University Live AUDIO, VIDEO, and WHITEBOARD broadcast over the Internet MBONE August 15-17, 1994 8:30 AM - 5:30 PM, PDT (UTC-7) The ISMB conference is intended to bring together scientists who are applying the technologies of advanced data modeling, machine learning, artificial intelligence, robotics, parallel computing, and other computational methods to problems in molecular biology. More information about the conference itself (including a preliminary schedule) is available at ftp://camis.stanford.edu/pub/altman/www/ismb.html. We plan to broadcast the refereed paper presentations as well as those of the invited speakers over the MBONE. The plan is to broadcast 4 world-wide sessions: - NV format video of the speaker at 128 kbs - NV format video of the overhead screen at much lower bandwidth - a shared whiteboard session - a vat audio session (possibly a second one for questions) Questions: - since a TTL of 127 is considered "world-wide", what are higher TTL's for? - how do I choose a good bandwidth for overhead video and speaker audio? Presumably, higher bandwidth means that individual dropped packets have a smaller effect on audio/video quality... but... the higher bandwidth itself may cause more packets to be dropped. I noticed that the IETF used dvi (46 Kb/s) for its high-quality audio and gsm (17 Kb/s) for the low-quality stuff. What kind of real world experiences do people have with this? I'd be especially interested in input from folks in areas whose MBONE connectivity is not so good -- what do you find comes in the best? The conference will be announced in sd (the multicast session directory) shortly beforehand (probably Sunday). Thanks in advance to Digital Equipment Corp., as they will be providing us with the necessary computer hardware to make this happen. Dan From rem-conf-request@es.net Fri Aug 05 04:58:12 1994 Received: from mgate.uni-hannover.de by osi-west.es.net via ESnet SMTP service id <12212-0@osi-west.es.net>; Fri, 5 Aug 1994 01:57:35 +0000 Received: from helios.tnt.uni-hannover.de by mgate.uni-hannover.de with SMTP (PP); Fri, 5 Aug 1994 10:58:18 +0200 Received: from ikarus.tnt.uni-hannover.de by helios.tnt.uni-hannover.de (4.1/SMI-4.1) id AA10928; Fri, 5 Aug 94 10:57:04 +0200 Date: Fri, 5 Aug 94 10:57:04 +0200 From: bloemer@tnt.uni-hannover.de (Arnold Bloemer) Message-Id: <9408050857.AA10928@helios.tnt.uni-hannover.de> To: mosedale@genome.Stanford.EDU Subject: Re: MolBio conference announce & questions Cc: mbone@ISI.EDU, rem-conf@es.net > What kind of real world experiences do people have with this? I'd > be especially interested in input from folks in areas whose MBONE > connectivity is not so good -- what do you find comes in the > best? My experience is that audio should have absolute priority, shared whiteboard should be used for transmission of transparencies and video of the speaker should have lower priority. A second whiteboard could be used for feedback from particpants of the conference. Video is at the current state of the MBone only good for seeing the context and doesn't contribute much to understanding, at least for world-wide transmissions of conferences. If you could arrange it, you should try to transmit the transparencies via wb. It is much better with respect to quality and functionality than to use nv for overhead screen. You should consider to use the new Sun CellB Coder of nv. My experience is approximately doubled frame rate and half data rate compared to the native nv coder and the image quality is only a little bit worse. Arnold ________________________________________________________________________________ Dipl.-Ing. Arnold Bloemer Universitaet Hannover Institut fuer Theoretische Nachrichtentechnik und Informationsverarbeitung bloemer@tnt.uni-hannover.de Appelstrasse 9A fax: +49 511 762-5333 D-30167 Hannover phone: +49 511 762-5320 Germany ________________________________________________________________________________ From rem-conf-request@es.net Fri Aug 05 17:06:56 1994 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <15303-0@osi-west.es.net>; Fri, 5 Aug 1994 14:06:24 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA20204; Fri, 5 Aug 94 14:08:18 -0700 Message-Id: <9408052108.AA20204@rx7.ee.lbl.gov> To: mbone@isi.edu, rem-conf@es.net Subject: v1.58 of wb (the LBL whiteboard tool) available Date: Fri, 05 Aug 94 14:08:17 PDT From: Van Jacobson A new version of the LBL whiteboard tool `wb' is available for anonymous ftp from ftp.ee.lbl.gov in directory conferencing/wb, files *-wb-v1.58.tar.Z (where '*' can be decalpha, decmips, hp, i386, sgi or sun). Attached is a list of the major changes since the last release. The most significant change is probably the `soft read-only' mode recently suggested by Mark Handley on the MBone list. Please note that you will have to update your .sd.tcl in order to advertise wb sessions as receive-only and/or start wb as receive-only when the announcement says to do so. A new version of the wb .sd.tcl script is in the file NOTES. Please let us know of any problems, suggestions, etc., via email to wb@ee.lbl.gov. Thanks. - Van Jacobson & Steve McCanne --------------------- v1.58, Fri Jul 29 21:13:32 PDT 1994 ****** PLEASE NOTE ****** Version 1.58 of wb requires changes to your .sd.tcl file. The file NOTES contains a new wb script that should replace the one in your .sd.tcl. ************************* - Added soft `receive only' mode. If wb is set receiveOnly, the user can't make any marks on a page, import files or force remote page flips. 'ReceiveOnly' mode is controlled by the X resource "wb.receiveOnly" (which defaults to 'false'), the command line flags -r (sets receiveOnly to true) & +r (sets receiveOnly to false) and the "Receive Only" check box in the sitebox window. (this mode suggested by Angela Sasse & Mark Handley of UCL.) - Keep names in sitebox sorted. (Collating order is case-independent on letters with all ip addresses after all names). - Added "wb.IconMark" X resource that will add mark to iconified wb's title when it is drawn on (similar to IconMark resource in vat). (suggested by Mark Handley of UCL) - Changed Interviews font machinery so that fonts are scaled by picking closest size X font rather than scaling bitmaps. - Changed brush machinery so that drawing line thickness is scaled appropriately when window is resized. - Added 'wb.CompactLayout' X resource to force a more compact screen layout (color palatte turned into menu). Also removed `clone page' button since `history' machinery to support its intended use hasn't been implemented yet & it is frequently abused. Result of this, font & brush change it that it's possible to shrink a wb down to ~1/4 screen size & still use it. (changes suggested by Atanu Ghosh & Mark Handley of UCL) - Correct mapping of font numbers to X LFD names (was turning 'oblique' into italic so helvetica oblique wouldn't work; also had most of the weights wrong & was missing 6 of the Adobe 'standard 15' faces). - Printing of ellipses was broken (used wrong coordinate system for brush size). - Added b-spline fit to smooth freehand lines (when drawing button released the straight line segments are replaced by a smoother b-spline approximation). The X resource "wb.LineSmoothness" can be used to control the "smoothness" of the final line. Larger numbers make the line "smoother" but a poorer approximation to the user's line segments. Smaller values make the spline a better approximation to the user's line segments but 'rougher'. The default LineSmoothness is 16. The lower limit is probably 2 (the fit may blow up if smoothness gets too small) and the upper limit is probably 200 (more than this & the fit will bear no resemblance to the user's line). Setting wb.SmoothLines to "true" will turn on the b-spline fit (default is false). Can also toggle line smoothing on/off via "Smooth Lines" check box on sitebox window. - Added 'wb.dpsUseColor' to control whether Display Postscript displays in color or just with grayscale. If wb.dpsUseColor is false, DPS will use a 32 level gray ramp (the same one used by nv) and map colors to gray. (This is to free color map cells for video use since it seems to be impossible to force DPS to use a color map that doesn't conflict with nv on SGIs.) - Added PointerMotionHintMask back to drawing window so motion events get compressed & wb doesn't get so far behind when doing arrows, moves or copies on busy pages. This allowed passive grabs on buttons to be removed which seems to make 'point to type' mode work much more reliably. - Did some work to try to reduce X traffic during drawing (the Interviews redraw model is just fundamentally broken). Hacked library so clip mask never messed with in drawing window so we don't have to reset it every drawop. Made sitebox highlighting and activity updates be done directly rather than going through IV (which cut X traffic by a factor of 70). (problems reported by Chris Kantarjiev of PARC.) - Still had packet source stuff wrong -- was using ip src addr instead of src id field in packet header. - Fixed abort on invalid font id (were passing 0 to strlen). - Try to do a better job infering when click-and-type is allowed. - Port to DEC OSF/1 v2.0 (i.e., undo all the workarounds we had for bugs with the v1.3 C++ environment). - Deal with BSDI's gratuitous change to the multicast sockopt numbers: If running on x86, try both the correct & BSDI's numbers for the sockopts & use whichever works (so program will run on both versions on BSD/386, NetBSD, etc.). From rem-conf-request@es.net Fri Aug 05 19:23:33 1994 Received: from ibminet.awdpa.ibm.com by osi-west.es.net via ESnet SMTP service id <16302-0@osi-west.es.net>; Fri, 5 Aug 1994 16:23:00 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA06857; Fri, 5 Aug 94 16:29:29 -0700 Received: by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA17574; Fri, 5 Aug 94 16:19:26 -0700 Received: from taurus.cs.nps.navy.mil by ibminet.awdpa.ibm.com (5.61/1.15) id AA06674; Fri, 5 Aug 94 16:22:31 -0700 Received: from trouble.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA02915; Fri, 5 Aug 94 16:17:54 PDT Received: by trouble.cs.nps.navy.mil (940715.SGI.52/911001.SGI) for @taurus.cs.nps.navy.mil:rem-conf%es.net@ibmpa.awdpa.ibm.com id AA21616; Fri, 5 Aug 94 16:17:57 -0700 From: Your VE info source Message-Id: <9408051617.ZM21603@trouble.cs.nps.navy.mil> Date: Fri, 5 Aug 1994 16:17:56 -0700 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: rem-conf%es.net@ibmpa.awdpa.ibm.com Subject: Call for Participation: 1995 Symposium on Interactive 3D Graphics Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Call for Participation 1995 Symposium on Interactive 3D Graphics In cooperation status anticipated from ACM SIGGRAPH. Symposium Specifics Important Dates 9th - 12th of April 1995 Abstracts for contributed papers due: 15 Oct. 94 Monterey, California USA Acceptance notification: 15 Nov. 94 (Proceedings at the symposium.) Final papers for proceedings due: 20 Dec. 94 The focus of the symposium is on the topic: Where is the frontier today in real-time, interactive 3D graphics ? The purpose of the symposium is to look at what research groups are doing with their high-performance, real-time, interactive graphics systems, to find out what special purpose graphics engines and input/output devices are on the drawing board, to discuss which are the most user-friendly paradigms for interaction with such systems and to learn what applications are still waiting for an appropriate 3D interactive system. The symposium will consist of technical sessions in which formal papers are presented and discussed, and of hands-on demonstrations where research groups and vendors of equipment demonstrate the state-of-the-art in this field. We are particularly interested in such notions as: -- moving through virtual worlds, i.e. visual simulation systems that move us through buildings or cities, over terrain or over the sea at multiple updates per second; -- interactively shaping, building or sculpting objects; or interactive assembly and manipulation of systems of parts, with consideration of ease of use, precision, and physical constraints; -- graphics hardware for high performance interactive displays; novel input technologies such as gloves, bodysuits and tracking systems; display technologies such as projected stereo, head mounted displays, and true volumetric 3D displays; -- techniques for interacting with and displaying information and data in 3D, i.e. methods for displaying non-spatial data such as abstract relationships. -- 3D graphical toolkits and user interface paradigms; higher level methods for prototyping, implementing, and verifying 3D graphics applications. Finally, we solicit contributions concerning systems that demand real-time graphics performance that is not currently achievable, along with recommendations for the development of future hardware and software architectures that may meet this demand. Symposium Chair Michael Zyda, Naval Postgraduate School Program Co-Chairs Pat Hanrahan Jim Winget Stanford Silicon Graphics Fundraising Chair S. Kicha Ganapathy, AT&T Bell Labs skg@research.att.com (908) 949-7860 Paper Submissions and Requests for Registration Prospective authors should submit 6 copies of an extended abstract and a short videotape (if appropriate) to the address below on or before the 15th of October 1994. The abstracts should be 3 to 6 pages long and reflect what will be contained in the final 8 to 12 page paper in the proceedings and in the 25 minute presentation at the symposium. Abstracts should clearly state what has been achieved and how this makes a contribution to the advancement of the state-of-the-art in interactive 3D graphics. Authors of papers describing systems are strongly encouraged to submit a videotape demonstrating their system in action. This videotape should show key features of the system, but need not be "professional" quality. Abstracts and papers to: Pat Hanrahan 1995 Symposium on Interactive 3D Graphics Stanford University Department of Computer Science Stanford, CA 94305-4070 Requests for registration forms should be E-mailed to: Michael Zyda zyda@trouble.cs.nps.navy.mil Naval Postgraduate School Code CS/Zk, Dept. of Computer Science Spanagel Hall 516 Monterey, California 93943-5100 (408) 656-2305 (408) 656-2814 (fax) The symposium is limited to 250 registrants. The registration fee for the symposium is $300 ($350 after January 31, 1995) and $100 for students. That fee includes the proceedings, reception, banquet and lunches. From rem-conf-request@es.net Tue Aug 09 09:20:02 1994 Received: from herman.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <11378-0@osi-west.es.net>; Tue, 9 Aug 1994 06:19:32 +0000 Received: (from fenner@localhost) by herman.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id JAA14909 for rem-conf@es.net; Tue, 9 Aug 1994 09:19:26 -0400 Date: Tue, 9 Aug 1994 09:19:26 -0400 From: "William C. Fenner" Message-Id: <199408091319.JAA14909@herman.cmf.nrl.navy.mil> To: rem-conf@es.net Subject: IP:NG Design Review We will be holding a public IP:NG design review on August 22, 1994 from 1-5pm EDT (17:00-21:00 GMT). We plan to use two 128kbps video channels, one audio, and one wb. We may restrict the video to DARTNet only, or lower the bandwidth sent, if there is a conflict with another event. I will be helping to coordinate the session, so please let me know of any conflicts. Please see http://herman.cmf.nrl.navy.mil:8001/sd/2261714691/2261714691/ IP:NG%20Design%20Review [URL broken for readability]. More information will be forthcoming from the IP:NG area directors on the IETF list soon. Thanks, Bill Fenner From rem-conf-request@es.net Tue Aug 09 17:32:42 1994 Received: from ftp.com by osi-west.es.net via ESnet SMTP service id <23098-0@osi-west.es.net>; Tue, 9 Aug 1994 14:30:04 +0000 Received: from ftp.com by ftp.com ; Tue, 9 Aug 1994 17:29:42 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 9 Aug 1994 17:29:42 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA01078; Tue, 9 Aug 94 17:27:15 EDT Date: Tue, 9 Aug 94 17:27:15 EDT Message-Id: <9408092127.AA01078@mailserv-D.ftp.com> To: schulzrinne@fokus.gmd.de, casner@isi.edu, rem-conf@es.net Subject: RTP Question From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 1868 I have a question about the use of RTP profiles. Suppose that I have some data stream that can have several different formats. In my case, this would be a Windows video stream that I could send as, eg, 24-bit RGB, 16-bit RGB, or 8-bit Windows pallete data. Now, I could: 1. Assign each of these different formats a different format name and map each one of those to a separate RTP payload type. So I might have format names Win3, Win2, and Win1 and use the FMT packet to map them to payload values 13, 86, and 99. 2. I could use one format name and map that one format to the three different payload type values and then use the format dependent data of the FMT packet to indicate the different encodings. 3. I could use a single format name and payload type value and then add the encoding type to some profile-specific data in the extended header of the data packet. 4. I could use a single format name and payload type and then dynamically change the association of that format type/name to different encodings by sending out new FMT packets, with the new information contained in the format-dependent data. (This, actually, is a bad idea since if the FMT packet that changes the payload-type-to-format mapping gets lost, the receiver will attempt to interpret newly received data using the old format leading to some very ugly images. I figured I'd include it for completeness...) Is there an 'official' way to do this? Does there need to be an "official" way? I do want to be able to change the encoding used to send the data in mid session so saying 'why would you ever want to do this?' is not an option :-) In order to let the applications adapt to the underlying network characteristics, I'd like to be able to make a tradeoff between network resource requirements and image fidelity). -- Frank Kastenholz From rem-conf-request@es.net Tue Aug 09 18:07:50 1994 Received: from ftp.com by osi-west.es.net via ESnet SMTP service id <00734-0@osi-west.es.net>; Tue, 9 Aug 1994 15:07:20 +0000 Received: from ftp.com by ftp.com ; Tue, 9 Aug 1994 18:07:18 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 9 Aug 1994 18:07:18 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA01468; Tue, 9 Aug 94 18:04:52 EDT Message-Id: <9408092204.AA01468@mailserv-D.ftp.com> Date: Tue Aug 09 17:25:27 1994 To: rem-conf@es.net Subject: Another RTP Question From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 230 In generating a particular machine's SSRC value, is there any reason why it should not/must not use its own IP address (assuming that it does not 'need' more SSRC values than it has IP addresses of course) -- Frank Kastenholz From rem-conf-request@es.net Tue Aug 09 21:09:28 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <05690-0@osi-west.es.net>; Tue, 9 Aug 1994 18:08:54 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14404(2)>; Tue, 9 Aug 1994 18:08:49 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16150>; Tue, 9 Aug 1994 18:08:38 -0700 To: kasten@ftp.com cc: rem-conf@es.net Subject: Re: RTP Question In-reply-to: Your message of "Tue, 09 Aug 94 14:27:15 PDT." <9408092127.AA01078@mailserv-D.ftp.com> X-Mailer: exmh version 1.4.2 8/7/94 Date: Tue, 9 Aug 1994 18:08:29 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <94Aug9.180838pdt.16150@ecco.parc.xerox.com> In message <9408092127.AA01078@mailserv-D.ftp.com> you write: > Suppose that I have some data stream that can have several different > formats. In my case, this would be a Windows video stream that I > could send as, eg, 24-bit RGB, 16-bit RGB, or 8-bit Windows pallete > data. Now, I could: > > [various schemes involving FMT deleted] > > Is there an 'official' way to do this? Does there need to be an > "official" way? > At the last IETF, we actually decided to remove the FMT option. Defining formats is now strictly the responsibility of the profile document and out-of-band session information. As for the above question, I see two equally viable solutions: The first is just to define three different payload type values, and assign one to each of the available formats. That's how we currently distinguish between H.261, nv, CU-SeeMe, and other very distinct formats. The other option is to define a single payload type but distinguish between them in the first part of the video data immediately following the RTP header. That's how nv distinguishes between different sizes, or between color and greyscale. If the different encodings are really just minor variations of one another and you expect to always implement all of them as a set, I'd tend to prefer this approach. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Aug 10 02:19:57 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <06330-0@osi-west.es.net>; Tue, 9 Aug 1994 23:19:28 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <16118-0@ceres.fokus.gmd.de>; Wed, 10 Aug 1994 08:20:49 +0200 To: rem-conf@es.net, kasten@ftp.com Subject: Re: Another RTP Question Date: Wed, 10 Aug 1994 08:20:49 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de > Date: Tue Aug 09 17:25:27 1994 > To: rem-conf@es.net > Subject: Another RTP Question > From: kasten@ftp.com (Frank Kastenholz) > Reply-To: kasten@ftp.com > > In generating a particular machine's SSRC value, is there any reason > why it should not/must not use its own IP address (assuming that it > does not 'need' more SSRC values than it has IP addresses of course) After some discussion, we decided that using IP addresses is temptingly convenient, but fraught with problems. 1) Unless everybody uses IPv4 addresses that are still globally unique AND you never have more than one application on a host AND you don't have silly things like local-use-only (Net 10) IP addresses, your application need a collision resolution mechanism to handle the case where something does pick "your" IP address. Thus, you need an algorithm to generate a new identifier different from your IP address and not based on it in a predictable way. If you have that algorithm, why not use it to begin with and avoid systematic collisions, i.e., collisions that occur every time you start up two applications on your host or every time two Net-10 folks with the same IP address talk to each other (through a NAT, RTP bridge or RTP translator). 2) It seemed that picking anything that depended on globally unique IPv4 addresses at this point in time is not exactly prudent. Fixing FTP and various other such protocols is work enough. 3) If you treat IPv4 addresses as just the initial "random" value, then you are limiting yourself to a fairly small subset of 32 bits, since a good fraction will never appear as an IP address (most class A, all of class D and E.) Given that a viable algorithm with Posix C code is provided in the spec, the effort for an application writer is pretty minimal. Henning From rem-conf-request@es.net Wed Aug 10 03:56:06 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <06968-0@osi-west.es.net>; Wed, 10 Aug 1994 00:55:34 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-18) id ; Wed, 10 Aug 1994 00:55:30 -0700 Posted-Date: Wed 10 Aug 94 00:54:25 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 10 Aug 94 00:54:26 PDT Date: Wed 10 Aug 94 00:54:25 PDT From: Stephen Casner Subject: Re: Another RTP Question To: kasten@ftp.com, rem-conf@es.net Message-Id: <776505265.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9408092204.AA01468@mailserv-D.ftp.com> Mail-System-Version: Frank, Thanks for your comments and questions in the past few messages. They help point out some places where intents have not been explained well enough. Henning and Ron provided good answers on most of the points, so I'll just try to fill in. > first, figure 1, on page 6, is very confusing. it should be broken up, > with little figures and the little figures co-located with the text that > describes the concept which the figure illustrates. This is a plausible suggestion, though multiple diagrams are more of a pain to deal with in the document. > with respect to translators (section 2.3) - is this really that important? I agree with Henning and Dan that there are compelling reasons, like firewalls, that we should accept the extra complexity of translators. > re bridges -- this name is confusing. One hates to flip flop around on names. Perhaps Dan's suggestion of "mixer" would be better, so long as that is general enough to include other forms of combination for other media and not just audio mixing. The term mixer has been used wrt vat. > i'm not sure that i like the extension header bit. why not use the SIPP > chained header scheme? it should not cost any more or less wrt to > bandwidth or processing power. and this will give the added architectural > flexibility of allowing someone to use multiple 'extended headers', if > they (are silly enough to) wish to, and are willing to pay the cost. In part, the choice of a constrained extension mechanism was intended to apply negative pressure on silliness and coerce new information or mechanisms where they belong. > why doesn't the reception report indicate the number of bytes received? > this would be a reasonable indication of the bandwidth that is getting > through to the receiver, and the sender could then make adjustements as > appropriate. In Van's original design, the number of bytes received was included. However, we must be conservative about the space in reception reports, so we traded this when we added the number of packets expected (which we can add because of the presence of sequence numbers in RTP (vs vat)) to convey receiver-calculated packet loss rate. If the packets are all about the same size, then the approximate data rate can be calculated from the packet rate. Third party monitors can calcluate the average packet size from the packet count and byte count in the sender report. > I have a question about the use of RTP profiles. Let me ask what an "RTP profile" means to you, because some others have commented to me that their understanding was different than what we meant, and we may need to explain it better somewhere. A profile is a document that further specifies the protocol for a particular class of applications. A profile defines a set of encodings (payload type values), among other things (see Sec. 9). There is nothing in the protocol to indicate which profile is selected; that is implicit in the application. Ron gave a good answer to your question about defining formats / payload type values. He said: If the different encodings are really just minor variations of one another and you expect to always implement all of them as a set, I'd tend to prefer this approach. I agree, except that two of the three formats you mentioned are 24-bit RGB and 16-bit RGB which I would expect to be useful more generally than just as a subtype of a Windows format. That is, unless there would be some data header information specific to Windows video. A couple of other comments: > So I might > have format names Win3, Win2, and Win1 and use the FMT packet > to map them to payload values 13, 86, and 99. As Ron mentioned, we elected not to include FMT. You don't need FMT in this example because the profile can predefine both the format names and the associated payload values. Only if there were combinatorially too many format variations to assign predefined payload values would you need to use dynamic payload values. Those dynamic values are to be specified out-of-band with using information similar to what would be in a FMT packet. For example, sd could pass those dynamic payload type definitions to the tools it invokes. From the June memo on the RTPv2 changes: An argument in favor of keeping FMT is that there are combinatorially more formats that a workstation's audio hardware and software may support than may be encoded into the payload type field, and that the creator of a session won't know which of those formats some participant may need to use to play a prerecorded clip during a session, so this method of defining dynamic payload type values is required. The counter argument is that only a few of the many possible formats will actually be used to record clips due to requirements for compatibility, and that including this method of defining payload types requires keeping track of the payload types per source. > 2. I could use one format name and map that one format to the three > different payload type values and then use the format dependent data > of the FMT packet to indicate the different encodings. Except that the information of the FMT packet is carried elsewhere than RTCP, this is correct and would make sense if the encodings are similar but only differ in parameters. > 3. I could use a single format name and payload type value and then add > the encoding type to some profile-specific data in the extended header > of the data packet. The extended header is not intended for this purpose. That extra information should be considered part of the encoding and be carried in the payload section of the packet, probably near the beginning, as Ron suggested. > 4. I could use a single format name and payload type and then dynamically > change the association of that format type/name to different encodings > by sending out new FMT packets, with the new information contained in > the format-dependent data. (This, actually, is a bad idea since if the > FMT packet that changes the payload-type-to-format mapping gets lost, > the receiver will attempt to interpret newly received data using the > old format leading to some very ugly images. I figured I'd include > it for completeness...) No, because of problem you mention, redefining payload types is specifically disallowed. Or that is, it would be if FMT were included. > Is there an 'official' way to do this? Does there need to be an > "official" way? As Ron indicated, the choice depends on the nature of the collection of encodings. > I do want to be able to change the encoding used to send the data in > mid session so saying 'why would you ever want to do this?' is not an > option :-) We'd never say that. Of course you want to be able to do this. > In generating a particular machine's SSRC value, is there any reason > why it should not/must not use its own IP address (assuming that it > does not 'need' more SSRC values than it has IP addresses of course) Yes, the program is supposed to (carefully) generate a random value. For the arguments behind this, see the minutes of the Seattle meeting where there was plenty of good discussion. (And I'd hope to get some use out of the effort put into writing the minutes.) They are available from your nearest IETF repository or from ftp.isi.edu in mbone/avt/minutes.94mar. See especially section 2.6.1. If you are interested, you can also look at transcript.94mar there. -- Steve ------- From rem-conf-request@es.net Wed Aug 10 13:21:33 1994 Received: from research.att.com by osi-west.es.net via ESnet SMTP service id <09431-0@osi-west.es.net>; Wed, 10 Aug 1994 10:21:04 +0000 Received: by research.att.com; Wed Aug 10 13:18 EDT 1994 Received: by physics.att.com (4.1/SMI-4.1) id AA29905; Wed, 10 Aug 94 13:16:59 EDT Date: Wed, 10 Aug 94 13:16:59 EDT From: ramac@physics.att.com (Robert Mac Harrie) Message-Id: <9408101716.AA29905@physics.att.com> To: rem-conf@es.net Subject: subscribe From rem-conf-request@es.net Wed Aug 10 20:06:29 1994 Received: from Sun.COM by osi-west.es.net via ESnet SMTP service id <11888-0@osi-west.es.net>; Wed, 10 Aug 1994 17:06:01 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA02699; Wed, 10 Aug 94 17:05:52 PDT Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA08315; Wed, 10 Aug 94 17:06:08 PDT Received: by auckland.Eng.Sun.COM (5.0/SMI-SVR4) id AA18646; Wed, 10 Aug 1994 17:04:37 +0800 Date: Wed, 10 Aug 1994 17:04:37 +0800 From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson) Message-Id: <9408110004.AA18646@auckland.Eng.Sun.COM> To: rem-conf@es.net Subject: IETF multicast audio quality Reply-To: finlayson@Eng.Sun.COM X-Sun-Charset: US-ASCII Content-Length: 2934 I first sent this out last week, but I don't think it made it. Resending... > Date: Mon 1 Aug 94 19:39:52 PDT > From: Stephen Casner > Subject: Thanks to IETF multicast crew > To: IETF@CNRI.Reston.VA.US > Cc: oattes@rathaus.utcs.utoronto.ca > Mail-System-Version: > > While "thank you's" were being doled out at the start of the Thursday > evening session at IETF, I think Lee Oattes and the others on the > audio/video multicast crew were overlooked and I did not get a chance > to speak up at the time. Getting all that equipment set up requires a > lot of planning and work. > > In particular, I'd like to thank the camera operators for a job well > done. They really concentrated on keeping the camera zoomed in so the > viewgraph text would fill the video image and be readable. > > From the reports I heard while there, the transmission quality was > very good. Now that I've returned home and listened to the online > recordings I captured here of my two AVT sessions, I can confirm that. > Thanks, folks. As a remote viewer/listener, I agree with Steve Casner that the quality of the IETF multicast video was very good. However, I was less satisfied with the audio. The frequency of dropped packets (especially during the day) seemed higher than usual. This may have been due to our own firewall relay and/or internal routers, or it may have been due to traffic problems elsewhere in the network. But in any case, dropped audio packets tend to be very noticeable and annoying - much more so than video (at least, IETF-style video). Audio encoding is way outside my area of expertise, but I can't help but wonder if there isn't some way to make dropped audio packets less noticeable - e.g., by adding some redundancy to the audio stream. Obviously, you don't want to increase the bandwidth too much by doing this, and of course nothing can help you much if dropped packets tend to occur in clumps. Comments? I also found the variations in volume (especially between different speakers) to be annoying - I constantly found myself having to fiddle with vat's volume control. The problem was especially noticeable when Van was talking; he's softly-spoken, but always interesting to listen to :-) How do TV stations deal with this problem? Do they simply rely on there being a human flunky in the studio adjusting the audio gain in real time? Is there anything better we can do? BTW, for each of the IETF vat sessions, I set the conference/lecture 'bit' to "lecture" (from its default value of "conference"). I don't know how much perceptable improvement this makes in practice, but it's yet another annoying decision that's left to the human user. Why not have vat set this policy automatically, accoring to some heuristic? E.g., if the same speaker has been active for >= 5 minutes, assume "lecture" mode, otherwise assume "conference" mode. Ross. From rem-conf-request@es.net Thu Aug 11 09:32:27 1994 Received: from mcenroe.cs.unc.edu by osi-west.es.net via ESnet SMTP service id <14337-0@osi-west.es.net>; Thu, 11 Aug 1994 06:31:49 +0000 Received: from jeffay by mcenroe.cs.unc.edu (8.6.9/UNC_06_21_94) id JAA02004; Thu, 11 Aug 1994 09:31:47 -0400 Message-Id: <199408111331.JAA02004@mcenroe.cs.unc.edu> To: rem-conf@es.net Subject: Re: IETF multicast audio quality In-reply-to: Your message of "Wed, 10 Aug 1994 17:04:37 +0800." <9408110004.AA18646@auckland.Eng.Sun.COM> Date: Thu, 11 Aug 1994 09:31:45 -0400 From: Kevin Jeffay > Date: Wed, 10 Aug 1994 17:04:37 +0800 > From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson) > To: rem-conf@es.net > Subject: IETF multicast audio quality > > ... > Audio encoding is way outside my area of expertise, but I can't help but > wonder if there isn't some way to make dropped audio packets less noticeable > - e.g., by adding some redundancy to the audio stream. Obviously, you don't > want to increase the bandwidth too much by doing this, and of course nothing > can help you much if dropped packets tend to occur in clumps. Comments? > ... My group at UNC experimented w/ a simple forward error correction scheme for audio that involved duplicating audio packets. We found that on a congested campus-area network our scheme "recovered" approx. 80% of the lost audio samples. The protocol we developed for this work transmitted audio and video separately but attempted to maintain limited synchronization between the streams. In our system there was a significant difference in the hardware latencies of the audio and video pipelines (one digitizes and compresses sequentially, the other in parallel) and this difference was exploited to separate the transmission of redundant audio samples in time by a protocol tunable parameter. In our experiments redundant audio samples were typically separated by 90-150ms. The 80% result occurred when redundant sample were separated by approx. 150 ms. The cost of this scheme in terms of additional total bandwidth was approximately 10%. (We were transmitting high-quality, high-bandwidth video and hence audio bandwidth by comparison was nearly negligible (i.e., 10% is probably a little misleading).) These experiments only considered point-to-point transmission of media. More details on these experiments can be found in: Transport and Display Mechanisms For Multimedia Conferencing Across Packet-Switched Networks K. Jeffay, D.L. Stone, F.D. Smith Computer Networks and ISDN Systems Vol. 26, No. 10, (July 1994) pp. 1281-1304. (Also available via anonymous ftp from ftp.cs.unc.edu in /pub/jeffay/papers.) From rem-conf-request@es.net Thu Aug 11 10:28:51 1994 Received: from bstgw1.bst.bls.com by osi-west.es.net via ESnet SMTP service id <14467-0@osi-west.es.net>; Thu, 11 Aug 1994 07:28:09 +0000 Received: from bstgw.bst.bls.com by bstgw1.bst.bls.com with smtp (Smail3.1.28.1 #11) id m0qYb9l-0000bkC; Thu, 11 Aug 94 10:30 EDT Received: from beavis by bstgw.bst.bls.com (4.1/SMI-4.1) id AA12781; Thu, 11 Aug 94 10:29:37 EDT Received: by beavis (5.0/SMI-SVR4) id AA29016; Thu, 11 Aug 1994 09:27:53 +0600 Date: Thu, 11 Aug 1994 09:27:53 +0600 From: mike.richards@bst.bls.com (Mike Richards) Message-Id: <9408111427.AA29016@beavis> To: rem-conf@es.net Subject: mrouted 2.0 problems on Sunos 4.1.3U1B X-Sun-Charset: US-ASCII Content-Length: 1089 "mrouted 2.0 problems on Sunos 4.1.3U1B" vat, sd, nv, imm run fine. Box is SS10 w/128mb memory. Anyone have any ideas? sunny#mrouted -d 3 debug level 3 mrouted version 2.0 installing le0 (90.10.104.7 on subnet 90.10.104) as vif #0 installing le1 (198.79.7.7 on subnet 198.79.7) as vif #1 installing tunnel from 90.10.104.7 to 90.10.4.187 as vif #2 setsockopt DVMRP_ADD_VIF: Can't assign requested address sunny# /etc/mrouted.conf # phyint [disable] [metric ] [threshold ] # tunnel [srcrt] [metric ] [threshold ] # # any phyint commands MUST precede any tunnel commands # tunnel 90.10.104.7 90.10.4.187 metric 1 threshold 16 ***************************************************************** * Mike Richards (205-977-5193) ATG - BellSouth Telecommunications * E8B1, 3535 Colonnade Pkwy, Birmingham, Al. 35243 * Fax: 205-977-1351 * The views expressed are those of the author and may * not reflect the views of BellSouth Telecommunications Inc. ***************************************************************** From rem-conf-request@es.net Thu Aug 11 11:36:38 1994 Received: from bgate.lut.ac.uk by osi-west.es.net via ESnet SMTP service id <14789-0@osi-west.es.net>; Thu, 11 Aug 1994 08:35:31 +0000 Received: from co_eroute_1_b02.lut.ac.uk by hpd.lut.ac.uk (15.11/SMI-4.1) id AA08970; Thu, 11 Aug 94 16:35:14 bst Date: Thu, 11 Aug 94 16:35:14 bst Message-Id: <9408111535.AA08970@hpd.lut.ac.uk> X-Mailer: Macintosh Eudora v1.3 To: rem-conf@es.net From: Ben Anderson X-Sender: coba@hpd Subject: Reminder: Sunday 14th August - BBC Radio 5 Live broadcast This is a reminder of: The FIRST EVER BBC RADIO BROADCAST on the MBONE on Sunday 14th August 12:15 to 13:04 BST (11:15 to 12:04 UTC/GMT) The British Broadcasting Corporation (BBC), in collaboration with the Department of Computer Studies at Loughborough University of Technology, UK, will be broadcasting BBC Radio 5's 'The Big Byte' programme live on the MBONE. This particular 'Big Byte' is devoted entirely to the Internet. Contrary to earlier rumours, an IRC channel will NOT be set up. Instead, the Big Byte production team can be emailed at: big-byte@bbcnc.org.uk. The team are extremely keen to hear YOUR views on the future of broadcasting corporations and interactive programming in the digital age. They also welcome queries and feedback on this particular broadcast of the Big Byte. Since MBONE developers and users are at the forefront of this new medium for communication, your opinions will be highly valued. You may even be mentioned on air if you email them this week.. There will be separate sd announcements for (a) the audio signal, and (b) a whiteboard for feedback to LUT about the multicast. FOR MORE INFORMATION: On this broadcast: see http://pipkin.lut.ac.uk/~ben/big_byte.html ****************************************************************************** Ben Anderson Research Assistant, PhD Student and LUTCHI WWW Maintainer (http://pipkin.lut.ac.uk/~ben/benhome.shtml) - note the 's' in .shtml! ...still searching for something (funny) to say. From rem-conf-request@es.net Thu Aug 11 16:17:39 1994 Received: from gatech.edu by osi-east.es.net via ESnet SMTP service id <29437-0@osi-east.es.net>; Thu, 11 Aug 1994 13:17:12 +0000 Received: from armani.gatech.edu by gatech.edu with SMTP id AA05569 (5.65c/Gatech-10.0-IDA); Thu, 11 Aug 1994 16:18:02 -0400 Received: by armani.gatech.edu (4.1/SMI-4.1) id AA11884; Thu, 11 Aug 94 16:22:48 EDT Date: Thu, 11 Aug 94 16:22:48 EDT From: ian@armani.gatech.edu (Ian F. Akyildiz) Message-Id: <9408112022.AA11884@armani.gatech.edu> To: cost237-transport@comp.lancs.ac.uk, end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, hipparch@sophia.inria.fr, rem-conf-request@es.net, rem-conf@es.net, reres@laas.fr, sigmedia@bellcore.com, xtp-relay@cs.concordia.ca Subject: WORKSHOP_ANNOUNCEMENT ********************************************************** * THE NINTH ANNUAL IEEE WORKSHOP ON * * * * COMPUTER COMMUNICATIONS * * * * Hawk's Cay Resort, Duck Key, Marathon, Florida * * October 24-26, 1994 * * * * * * Sponsored by the IEEE Communications Society * * Technical Committee on Computer Communications * ********************************************************** The Ninth IEEE Workshop on Computer Communications will be held October 24-26, 1994, at Hawk's Cay Resort, Duck Key, Marathon, Florida, located within two hours of Miami and one hour from Key West. The objective of this workshop is to foster the exchange of information among researchers in this fast-moving field. The program includes presentations by distinguished researchers, speaking on recent advances in theory and practice, with ample time for discussions both between presentations and at the end of each session. As it is now traditional in our workshop, all attendees are encouraged to participate actively in the discussions, comment on presentations, challenge the speakers, and present different viewpoints. Please direct inquiries to: Ian F. Akyildiz Imrich Chlamtac Workshop Chair Workshop Co-Chair School of ECE Department of ECE Georgia Tech UMASS Atlanta, GA 30332 Amherst, MA 01003 Tel.: 404-894-5141 Tel.: 413-545-0712 Fax.: 404-853-9410 Fax.: 413-545-4611 E_Mail: ian@armani.gatech.edu E_Mail: chlamtac@ecs.umass.edu -------------------------------------------------------------------------- ADVANCED PROGRAM The Ninth Annual IEEE Workshop on COMPUTER COMMUNICATIONS Hawk's Cay Resort, Duck Key, Marathon, Florida October 24-26, 1994 Sunday, October 23, 1994 ------------------------ 6-9pm Registration: Wine and Cheese Party Monday, October 24, 1994 ------------------------ 8-10am Session 1: OPTICAL NETWORKS Organizer: HISASHI KOBAYASHI, Princeton University. "A Re-examination of WDM Networks, their Advantages and Limitations" Charles A. Bracket, Bellcore "Wavelength Division Multiplexed Networks for Local, Metropolitan, and Regional Applications" Ivan P. Kaminow, AT&T Bell Laboratories "All-optical Demultiplexing of TDM Data at 250 Gbps". Paul R. Prucnal, Princeton University "A Bridge for Packet Switched WDM Networks" Andrea Fumagalli and Imrich Chlamtac, University of Massachusetts 10-10:30am Break 10:30am-12:30pm Session 2: VIDEO SERVICES AND NETWORKING SUPPORT Organizer: SIMON S. LAM, University of Texas at Austin "Video Transport in ATM Networks: A Systems View," D. Raychaudhuri, NEC, Princeton, NJ "Delay Guarantee of Virtual Clock Server," Gong Xie, University of Texas at Austin "Burst Scheduling: Architecture and Algorithm for Switching VBR Video," Simon S. Lam, University of Texas at Austin "Real-time Packet Video Transport Using Feedbacks," Hemant Kanakia, AT&T Bell Laboratories 12:30-3pm Lunch 3-6pm Session 3: MOBILE COMPUTING Organizer: NACHUM SHACHAM, SRI International "Mobile Networking with DHCP", Charlie Perkins, IBM T.J. Watson Research Center "A Distributed Control Strategy for Wireless ATM Networks", Malathi Veeraraghavan, AT&T Bell Laboratories "Multimedia Support in a Mobile Packet Radio Net", Mario Gerla, Univ. of California, Los Angeles "Satellite-Augmented Cellular Networks", Anthony Ephremides, Univ. of Maryland, College Park "Mobile Host Security", Nachum Shacham, SRI International 4:30-5pm Break 7pm. Buffet Dinner Tuesday, October 25, 1994 ------------------------- 8-10am Session 4: NETWORK PERFORMANCE Organizers: KHOSROW SOHRABY, University of Missouri at Kansas City (UMKC) KAZEM SOHRABY, AT&T Bell Laboratories, Holmdel, NJ. "Distributed Autonomous Wireless Channel Assignment Algorithm with Power Control" G. J. Foschini, Z. Miljanic, AT&T Bell Laboratories, Holmdel, NJ "Blocking and Forced Termination in Pico-Cellular Wireless Networks: Asymptotic Analysis" Khosrow Sohraby, University of Missouri at Kansas City (UMKC). "Rate Estimation For Heterogeneous ATM Traffic" Denis Khotimsky and Alan Konheim, University of California, Santa Barbara "Performance of an Access Protocol for a Wireless ATM Local Area Network" Mark J. Karol, AT&T Bell Laboratories, Holmdel, NJ 10-10:30am Break 10:30am-12:30pm Session 5: WIRELESS NETWORKS Organizer: GORDON STUBER, Georgia Institute of Technology "Scalable Support for Transparent Mobile Host Internetworking." Dave Johnson, Carnegie Mellon University. "Optimal Design of Two-tier Cellular Radio Systems." Aura Ganz, D. Tang and C.M. Krishna, University of Massachusetts. "Wireless Data: Systems, Standard Applications." Sanjiv Nanda and Antonio DeSimone, AT&T Bell Laboratories. "Issues for ATM over Wireless." John Daigle (Ole Miss), 12:30-3pm Lunch 3-6pm Session 6: MULTIMEDIA NETWORKING Organizers: DOMENICO FERRARI, UC Berkeley and ICSI HUI ZHANG, LAWRENCE BERKELEY LABORATORY (LBL) "Multimedia Protocols: Where Are We?" Domenico Ferrari, UC Berkeley and International Computer Science Institute (ICSI) "Multimedia Networks for Large Scale Networked Application Services" Monsong Chen, IBM "Routing Support for Reservation-Based Multimedia Networks" Deborah Estrin, USC/ISI, Scott Shenker, Xerox PARC; D. Zappala, USC/ISI "A New Architecture for Multimedia Distribution in Integrated Services Networks" Wei Yen and Ian Akyildiz, Georgia Tech "OS Support for Multimedia Communication", R. Gopalakrishnan and Guru Parulkar, Washington University 4:30-5pm Break 7pm. Buffet Dinner Wednesday, October 26, 1994 --------------------------- 8-10am Session 7: ATM LANs Organizers: IZHAK RUBIN, Univ. of California at Los Angeles (UCLA) YORAM OFEK, IBM TJ Watson "SMARTNET: A High Speed Meshed Ring ATM LAN" Izhak Rubin, Univ. of California at Los Angeles (UCLA) "Washington University's 622 Mbps ATM Desk Area Network" Zubin D. Dittia, Jerome R. Cox, Jr., and Guru M. Parulkar, Washington University "Using ATM as a LAN" Jean-Yves LeBoudec, EPFL-DI, Switzerland. "Topological Design of Loss-Free Switch-Based LANs" Bulent Yener, Columbia Univ., Yoram Ofek and Moti Yung, IBM TJ Watson. 10-10:30am Break 10:30am-1:00pm Session 8: TRAFFIC MANAGEMENT IN ATM NETWORKS Organizers: JOHN DAIGLE, OLE MISS BRAD MAKRUCKI, Bell South, Atlanta. "Traffic Management in ATM Networks: Problem Statement and Issues" Brad Makrucki, BellSouth and John Daigle, OLE MISS "Traffic Management in ATM Networks: A Rate-Based Approach" Michael G. Hluchyj, Summa Four Systems. "Traffic Management in ATM Networks: A Credit-Based Approach" James Scott, Digital Equipment Corporation. PANEL DISCUSSION: QUO VADIS "TRAFFIC MANAGEMENT IN ATM"? Panel Members: TO BE ANNOUNCED. (The panel will discuss the merits of the approaches in achieving the goals together with entertaining questions of the audience). ------------------------------------------------------------------------- 1994 IEEE COMPUTER COMMUNICATIONS WORKSHOP REGISTRATION FORM Name: _______________________________ Company/Affiliation: _________________________________ Address: ____________________________________ ____________________________________ Tel.: ____________________ Fax.: ___________________ E_Mail: _________________ ___ $90 enclosed (Make check payable to "WORKSHOP'94") Mail to: Prof. Ian F. Akyildiz School of ECE Georgia Tech Atlanta, GA 30332 Tel.: (404)-894-5141 Fax.: (404)-853-9410 E_Mail.: ian@armani.gatech.edu --------------------------------------------------------------------- HAWK'S CAY RESORT AND MARINA REGISTRATION FORM FOR THE 9TH IEEE WORKSHOP ON COMPUTER COMMUNICATIONS OCTOBER 23, 1994 - OCTOBER 26, 1994 Arrival Date ........... Arrival Time ....... Departure Date ...... (List early arrival/late departure dates, if applicable) (GROUP RATES MAY NOT BE AVAILABLE TO EARLY ARRIVALS/LATE DEPARTURES) NAME ....................... SIGNATURE ........... COMPANY ................... PHONE# .............. ADDRESS ............................................ CITY ............. STATE ........... ZIP ....... CREDIT CARD TYPE (Circle One) MC VISA DISCOVER DINERS AMEX CREDIT CARD# ..................... EXPIRATION DATE ............. NAME ON CARD ..................... SIGNATURE ................... # OF GUESTS IN ROOM (Ages if Children) ........................... Children 11 and under are free, extra person charge $25.00 per night. For children, 11 and under, to attend group dinners there is a non-refundable $50.00 charge. For children 12 and over, full price. Will children be attending group dinners? ____ Yes ____ No Number of Children atrending ............. Ages ............ Smoking ................. Non-smoking ......... (Accommodations in each category are limited. We will make every effort to honor your request, however, it cannot be guaranteed) ACCOMMODATIONS $498.10 per person, based on a single occupancy $320.29 per person, based on double occupancy Additional nights are available at $105.00 per room, per night, plus tax single or double occupancy. Meals except for breakfast, not included in additional night price. Refunds will not be made on any portion of the IEEE three night package. A non-refundable meal program for children 4-11 years including two dinners, chef's choice, is $50.00 additional. Check in time is 3:00 pm/Check out time is 11:00am. INCLUDED IN RATES: * Three nights accommodations (October 23-25 nights), inclusive of tax * Lavish Breakfast Buffet on October 24-26, 1994 * Buffet Dinners on October 24 and 25, 1994 * Wine and Cheese Reception, October 23, 1994 * Coffee Breaks during the workshop * Morning Newspaper * Transportation to/from Marathon Airport (24 hour notice needed) * Nightly Turndown Service * All gratuities, maid, bellman and breakfast server * Dolphin training sessions (three times daily) ___ Please check here if you require vegeterian meals at the group dinners. Number of people ___ REGSITRATION FORMS MUST BE COMPLETED AND RETURNED TO: Reservations Department OR FAX TO: Reservations Department Hawk's Cay Resort and Marina (305) 743-5215 Mile Marker 61, Duck Key Marathon, FL 33050 1-(800)-432-2242 COMPLETE ONE FORM FOR EACH ROOM NEEDED - A CONFIRMATION WILL BE MAILED ENTIRE PACKAGE PRICE WILL AUTOMATICALLY BE CHARGED TO YOUR CREDIT CARD CANCELLATION POLICY IS THIRTY DAYS PRIOR TO ARRIVAL CANCELLATION WITHIN THIRTY DAYS WILL RESULT IN FORFEITURE OF DEPOSIT. ** RESERVATIONS MUST BE RECEIVED BY SEPTEMBER 15, 1994 TO GUARANTEE YOUR ROOM ** ** AND TO GUARANTEE THE GROUP RATE FOR YOUR ROOM** ---------------------------------------------------------------------------------- HAWK'S CAY RESORT AND MARINA Duck Key, Marathon, Florida. GROUND TRANSPORTATION --------------------- Rental Cars: ----------- Budget Rent a Car Avis Rent a Car General Rent a Car Marathon Airport, FL Marathon Airport, FL Marathon, FL 305-743-3998 305-743-5428 800-327-7607 800-527-0700 305-377-2531 (Miami) Motor Coach ----------- A-1 Bus lines Miami Bus & Limo American Meetings and Conventions Miami, FL Miami, FL Miami Lakes, FL 305-325-1000 305-633-3377 305-621-4181 800-826-6754 Go Tours Grayline Bus Company Marathon, FL Miami, FL 305-743-9876 305-587-8080 Car Services ------------ Ambassador Limo Service Island Taxi Paradise to Reality & Back Miami, FL Marathon, FL Miami, FL 305-931-3111 305-743-6004 305-852-4656 800-245-4667 Miami Airport to Hawk's Cay Resort and Marina --------------------------------------------- Miami International Airport to 836 West until you reach the Florida Turnpike. Stay South on the Turnpike until it ends at US-1. Continue South on US-1 to Mile Marker 61 - Hawk's Cay Resort and Marina !! The drive from Miami International Airport to Hawks' Cay Resort is an hour and forty five minutes. It is a beautiful drive, and is described by Rand-McNally as one of the most scenic drives in the United States, "where the sky and the ocean meet". HAWK's CAY RESORT PROVIDES COMPLIMENTARY TRANSPORTATION TO AND FROM THE MARATHON AIRPORT (please give 24 hours notice). American Airlines 800-433-7300 USAir 800-428-4322 Gulfstream International Airlines 800-992-8532 With expansion of the Marathon Airport (scheduled for completion November 1994), the capacity and number of flights will increase. ------------------------------------------------------------------ If you have any questions/requests, please contact Dr. I. F. Akyildiz at ian@armani.gatech.edu; 404-894-5141 (tel); 404-853-9410 (fax). From rem-conf-request@es.net Thu Aug 11 16:44:10 1994 Received: from tadpole.Tadpole.COM by osi-east.es.net via ESnet SMTP service id <29986-0@osi-east.es.net>; Thu, 11 Aug 1994 13:43:51 +0000 Received: by tadpole.tadpole.com (4.1/SMI-4.1-jim) id AA13704; Thu, 11 Aug 94 15:43:41 CDT Date: Thu, 11 Aug 94 15:43:41 CDT From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9408112043.AA13704@tadpole.tadpole.com> To: van@ee.lbl.gov Subject: SPARCbook3 multicast-enabled kernel Cc: mbone@isi.edu, rem-conf@es.net There is now a kernel built for multicast (and mrouter, but that isn't tested) for SPARCbook3 (and 3LC) machines available in: tadpole.com:~ftp/pub/multicast/vmunix.S3-A.2.1-multicast All the usuall gibberish about 'not-supported, your milage may vary, ...' applies. Jim From rem-conf-request@es.net Thu Aug 11 19:50:57 1994 Received: from atlas.arc.nasa.gov by osi-east.es.net via ESnet SMTP service id <03874-0@osi-east.es.net>; Thu, 11 Aug 1994 16:50:40 +0000 Received: from atlas.arc.nasa.gov by atlas.arc.nasa.gov id <18553-0@atlas.arc.nasa.gov>; Thu, 11 Aug 1994 16:50:35 -0700 From: Nora Lavelle Message-Id: <9408111650.ZM18550@atlas.arc.nasa.gov> Date: Thu, 11 Aug 1994 16:50:33 -0700 X-Mailer: Z-Mail (3.0.1 04apr94) To: rem-conf@es.net Subject: NASA Shuttle Mission STS-68 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: nlavelle@atlas.arc.nasa.gov I am planning to multicast the NASA Select coverage of STS-68 on a 24 hour basis starting on August, 18.1994 and lasting until August, 27, 1994. This coverage will consist of nv and vat sessions. If this coverage interferes with other multicast conferences, I will be standing by to reduce bandwidth or suspend coverage in order to share the MBONE. I will be multicasting with a ttl of 127. If there are any problems with this schedule or practice, please contact me. E-mail all questions or comments to anaops@atlas.arc.nasa.gov -------------------------------------------------------------------------------- Nora Lavelle System Adminstrator Advanced Network Applications Sterling Software NASA Ames Research Center nlavelle@atlas.arc.nasa.gov -------------------------------------------------------------------------------- From rem-conf-request@es.net Fri Aug 12 03:20:10 1994 Received: from bunyip.cc.uq.oz.au by osi-east.es.net via ESnet SMTP service id <08795-0@osi-east.es.net>; Fri, 12 Aug 1994 00:19:50 +0000 Received: from trapdoor.dstc.edu.au by bunyip.cc.uq.oz.au with SMTP (PP); Fri, 12 Aug 1994 17:17:59 +1000 Received: from azure.dstc.edu.au by trapdoor.dstc.edu.au (5.65/DSTC-Server) id ; Fri, 12 Aug 1994 17:16:55 +1000 Message-Id: <21767.9408120716@azure.dstc.edu.au> To: rem-conf@es.net Subject: IVS and DEC J300 Date: Fri, 12 Aug 94 17:16:54 +1000 From: frank@dstc.edu.au X-Mts: smtp Hi everyone, I'm interested in any pointers to implementations and/or interface code which allows IVS 3.2 to transmit video using DEC's Sound and Motion J300 board as a frame grabber. I have this version working on an Alpha AXP (OSF/1 v1.3 & v2.0) in audio-only mode. If you can help, please e-mail, otherwise we will attempt to implement the interface from scratch. Thanks in advance. Regards, Frank ----- Francis Edwards R&D Engineer frank@dstc.edu.au CRC for Distributed Systems Technology Tel: +61 7 365 4310 Gehrmann Laboratories Fax: +61 7 365 4399 The University of Queensland Q 4072 Australia ----- From rem-conf-request@es.net Fri Aug 12 03:35:00 1994 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <08926-0@osi-east.es.net>; Fri, 12 Aug 1994 00:34:44 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-18) id ; Fri, 12 Aug 1994 00:33:22 -0700 Posted-Date: Fri 12 Aug 94 00:32:17 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 12 Aug 94 00:32:18 PDT Date: Fri 12 Aug 94 00:32:17 PDT From: Stephen Casner Subject: Re: IETF multicast audio quality To: finlayson@eng.sun.com, rem-conf@es.net Message-Id: <776676737.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9408110004.AA18646@auckland.Eng.Sun.COM> Mail-System-Version: Ross, > As a remote viewer/listener, I agree with Steve Casner that the quality of > the IETF multicast video was very good. However, I was less satisfied with > the audio. Actually, both the audio and video were good in what I recorded on my local disk at ISI (though I've only listened to part of it). > The frequency of dropped packets (especially during the day) seemed > higher than usual. ... dropped audio packets tend to be very > noticeable and annoying > > Audio encoding is way outside my area of expertise, but I can't help but > wonder if there isn't some way to make dropped audio packets less noticeable > - e.g., by adding some redundancy to the audio stream. For this IETF, we needed to reduce the packet rate and data rate to allow for parallel IETF and SIGGRAPH transmissions, so dvi4 encoding was selected. The lower packet rate (larger packets) means that a single packet loss produces a longer and more noticeable outage. When pcm encoding is used, each packet contains only 20ms. With that short a gap, it is possible to fill in the gap with artificial sound and make the loss unnoticed. This doesn't increase the bandwidth at all. However, that packet rate would be 4 times higher, which would likely produce more loss if there was congestion. As you note, if the packets are lost in clumps, you're out of luck. > I also found the variations in volume (especially between different > speakers) to be annoying - I constantly found myself having to fiddle with > vat's volume control. I think the operators tried to make some adjustments in level at the sending side as well, but it is hard to do. Next IETF, Carl Malamud is going to run the multicast and will supply some automatic leveling devices from his collection, and that may help. Unfortunately, automatic gain control can also produce unwanted artifacts. -- Steve ------- From rem-conf-request@es.net Fri Aug 12 04:06:53 1994 Received: from taurus.cs.nps.navy.mil by osi-east.es.net via ESnet SMTP service id <09223-0@osi-east.es.net>; Fri, 12 Aug 1994 01:06:29 +0000 Received: by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA16671; Fri, 12 Aug 94 01:06:59 PDT Date: Fri, 12 Aug 94 01:06:59 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9408120806.AA16671@taurus.cs.nps.navy.mil> To: CASNER@ISI.EDU, finlayson@eng.sun.com, rem-conf@es.net Subject: Re: IETF multicast audio quality Our basic rule of thumb is that getting the audio right is * harder * than video, and therefore you should spend more time on it during your broadcast preparations. Things to do include checking mikes, spare batteries, shielding cables, connecting to PA, ensuring your audio machine isn't overloaded & losing cycles, sound checks, backups, etc. etc. etc. regards, Don From rem-conf-request@es.net Fri Aug 12 13:32:55 1994 Received: from giskard.holonet.net by osi-east.es.net via ESnet SMTP service id <16085-0@osi-east.es.net>; Fri, 12 Aug 1994 10:32:40 +0000 Received: from localhost (fran@localhost) by holonet.net (Frances Kelly) id KAA25311; Fri, 12 Aug 1994 10:30:56 -0700 Message-Id: <199408121730.KAA25311@holonet.net> Subject: The Nature of Space and Time To: rem-conf@es.net Date: Fri, 12 Aug 94 10:30:55 PDT From: Frances Kelly Hello: I'm interested in obtaining the text from Stephen Hawking's speech on computer viruses as a life form. Can I get that through you, or could you point me in the right direction? I'd really appreciate it. Thanks Fran Kelly fran@holonet.net 907-265-5338 From rem-conf-request@es.net Fri Aug 12 16:00:13 1994 Received: from overdrive3.ccrl.nj.nec.com by osi-west.es.net via ESnet SMTP service id <03002-0@osi-west.es.net>; Fri, 12 Aug 1994 12:58:53 +0000 Received: by overdrive.ccrl.nj.nec.com (4.1/YDL1.9-920708.13) id AA21346(overdrive.ccrl.nj.nec.com); Fri, 12 Aug 94 15:58:50 EDT Received: by europa.ccrl.nj.nec.com (4.1/YDL1.9-920708.13) id AA13035(europa.ccrl.nj.nec.com); Fri, 12 Aug 94 15:54:33 EDT From: bansal@ccrl.nj.nec.com (Vivek Bansal) Received: by depot (4.1/CNC-Client) id AA06289; Fri, 12 Aug 94 15:58:52 EDT Date: Fri, 12 Aug 94 15:58:52 EDT Message-Id: <9408121958.AA06289@depot> To: rem-conf@es.net Subject: program of ITS94 Arrangements are been made for a live broadcast over the Internet MBONE of the plenary, technical sessions, and invited talk at the ITS'94 to be held in Rio de Janeiro, Brazil, on August 22-25, 1994. The software requirements to view the broadcast include the Internet tools: nv, vat, and sd (More information on the MBONE is available from venera.isi.edu:mbone/faq.txt). Please find enclosed below the final program for the ITS'94. Parties involved in the whole setup are: Comsat World Systems, Embratel, MFS, NEC, SURAnet (and possibly others in Brazil that I am not aware of). ****************************************************************************** ITS'94 Technical Program Overview Rio de Janeiro, Brazil August 22-25, 1994 Sponsored by: Sociedade Brasileira de Telecomunicacoes IEEE Communications Society ****************************************************************************** Monday, Aug. 22, 1994 TUTORIALS (all from 9:00 to 16:30) 1) From Copper to Fiber in the Subscriber Loop: Challenges and Opportunities. Instructor: Agostino Moncalvo 2) Evolution towards TMN. Instructor: Roberto Saracco 3) Personal Communications in the U.S. and World. Instructor: Ray W. Nettleton 4) High Speed Networks and Multimedia Communications: Applications, Infrastructure and Protocols. Instructor: Fouad A. Tobagi Tuesday, Aug.23 9:30-10:15 Opening Session 10:30-11:30 Plenary Session: The future of Telecommunications, John S. Mayo 14:00-15:00 Invited Talk: Perspectives on Integrated Services, High Speed and Congestion, Robert G. Gallager Invited Talk: Advanced Topics in Digital Signal Processing for Telecommunication Systems, Maurice Bellanger 15:20-17:30 Technical Session 1: Adaptive Signal Processing Technical Session 2: Routing in Multiservice Network Technical Session 3: Communication Theory Technical Session 4: Communications Software Design Analysis and Applications Wednesday, Aug.24 8:30-9:50 Panel Session: Multimedia Applications and Networking (Weinstein, Derby, Martins, Watanabe, Decina) Technical Session 5: Protocol Design and Testing 8:30-11:30 Technical Session 6: Coding and Modulation I Technical Session 7: Propagation, Antennas and Devices 10:05-11:30 Panel Session: Design Issues in High Speed Multimedia Networks (Towsley, Gallager, Tobagi, Maxemchuck) Technical Session 8: Speech Processing 11:30-12:30 Plenary Session: The Coming Ubiquity of Digital Wireless Access Intelligent Network, Irwin M. Jacobs 14:00-15:00 Invited Talk: Will ATM be the end of MAN, Nicholas Maxemchuck Invited Talk: Future Trends in Satellite Communications Services, Systems and Technology, Benjamin J. Pontano 15:20-17:30 Technical Session 9: Digital Signal Processing Algorithms Technical Session 10: Wireless Personal Communications: Protocols, Architectures and Routing Technical Session 11: Optical Communications Technical Session 12: Design Issues for Provision of Multimedia Services Thursday, Aug.25 8:30-9:50 Panel Session: Digital Signal Processing for Multimedia Communications (Bellanger, Gonzalez, Cuperman, Constantinides, Nunes) Technical Session 13: Performance Analysis of ATM Networks Technical Session 14: Coding and Modulation II 8:30-11:30 Technical Session 15: Mobile Radio System Issues 10:05-11:30 Technical Session 16: Image Processing and Compression Technical Session 17: ATM Congestion Control in Integrated Services Networks Technical Session 18: Communiocations Switching 11:30-12:30 Plenary Session: Global Telecommunication Standardization in a Changing World - A Challenge for the International Telecommunication Union (ITU), Theodor Irmer 14:00-15:15 Technical Session 19: ASIC for Telecommunications Technical Session 20: Quality of Services in High Speed Networks 14:00-17:30 Technical Session 21: Transmission Lines and Waveguides Technical Session 22: Emerging Network Operation Technologies and Applications 15:30-17:30 Technical Session 23: Topics in Satellite Communications Technical Session 24: High Speed Network Architectures and Protocols Friday, August 26 9:00-17:30 International Workshop on Network Management PROGRAM ----------------------------------------------------------------------- 9:00-9:15 OPENING REMARKS Thomas Plevyak, IEEE ComSoc Raul Colcher, Workshop Co-Chairman 9:15-10:15 INTRODUCTION Albuquerque, Embratel 10:15-10:30 Coffee Break 10:30-11:15 STANDARDS David Sidor, BNR 11:15-12:00 INFORMATION MODELING * Lakshmi Raman, Bellcore 12:00-1:30 Lunch 1:30-2:45 APPLICATIONS & CHALLENGES Carey Anderson and Jim Goett, Bellcore 2:45-3:00 Coffee Break 3:00-3:45 IMPLEMENTATION EXPERIENCES Stefan Brock, DBP Telekom 3:45-4:15 PLATFORMS/INTEGRATION ISSUES Joseph Lias, Premisys Communications 4:15-5:15 PANEL DISCUSSION A 5:15-5:30 CLOSING REMARKS Salah Aidarous, CNOM J.Roberto B. de Marca, General Chairman, ITS'94 ******************************************************************************* ----- End Included Message ----- ----- End Included Message ----- From rem-conf-request@es.net Mon Aug 15 12:33:45 1994 Received: from funet.fi by osi-west.es.net via ESnet SMTP service id <12905-0@osi-west.es.net>; Mon, 15 Aug 1994 09:33:21 +0000 Received: from localhost by funet.fi with SMTP (PP); Mon, 15 Aug 1994 19:32:52 +0300 Reply-To: Harri.Salminen@funet.fi To: rem-conf@es.net Cc: mbone@uiah.fi, susanna@uiah.fi Organization: Finnish University & Research Network Subject: The 5th International Symposium on Electronic Art 22-24.8.1994 Date: Mon, 15 Aug 94 19:32:49 +0300 From: Harri.Salminen@funet.fi will take place in Helsinki, Finland in 1994, August 20 trough 25. ISEA'94 Helsinki will be a lively forum for scholars, artists, critics, scientists and educators - all those who share a professional interest in electronic art. With the help of FUNET, SGI and Telecom Finland the main conference sessions are planned to be broadcasted using nv, vat, wb and imm at the conventional slow rate (around 100Kbit/s nv?) via our 2Mbit/s connection to NORDUnet and rest of Mbone. Faster rates may be experimented within the Finnish high speed backbones though with another Indy. In technical issues please contact the mbone team at mbone@uiah.fi during the broadcasts or me before it. We are still open for suggestions. The current plan is to broadcast each day around 0600 - 1800 UTC. Most of the day it will be live broadcast from the sessions in the Europea Hall in the Marina Congress Centre and when there's no presentations (mainly after 14 UTC) plan is to send some first cuts from the mobile camera crew making a documentary tape of the event mainly for the traditional TV media. Situation may still change though. More information including the program is available and evolving (even through the event) using WWW with the URL http://www.uiah.fi/isea/index.html If there's real interest we could consider sending a shorter taped documentary later at local night time (US day time) but no promises. Harri Salminen FUNET From rem-conf-request@es.net Mon Aug 15 13:06:28 1994 Received: from research.ftp.com by osi-west.es.net via ESnet SMTP service id <13147-0@osi-west.es.net>; Mon, 15 Aug 1994 10:06:10 +0000 Received: by Research.Ftp.Com (931110.SGI/) for rem-conf@es.net id AA02010; Mon, 15 Aug 94 13:01:07 -0400 Received: by Research.Ftp.Com id AA02010; Mon, 15 Aug 94 13:01:07 -0400 Date: Mon, 15 Aug 1994 13:01:06 +0059 (EDT) From: Frank Kastenholz Subject: SDES suggestion To: rem-conf@es.net Cc: casner@isi.edu, schulzrinne@fokus.gmd.de In-Reply-To: <9408040731.AA11504@Research.Ftp.Com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm currently writing the code to receive and parse SDES packets. It would make life a lot easier if we had a specific SDES item called End_of_list_and_pad (or the like). It would A) specifically mark the end of the SDES item list for a specific SSRC/CSRC (much as the byte of 0 does in the 18 july spec), and B) the length field of the item (and of course, the item's length itself) would give the pad length in the next SSRC/CSRC. It would make the coding a bit easier. It would add another byte to the packet for the padding. Frank Kastenholz From rem-conf-request@es.net Mon Aug 15 13:45:27 1994 Received: from research.ftp.com by osi-west.es.net via ESnet SMTP service id <13325-0@osi-west.es.net>; Mon, 15 Aug 1994 10:44:59 +0000 Received: by Research.Ftp.Com (931110.SGI/) for rem-conf@es.net id AA02059; Mon, 15 Aug 94 13:39:50 -0400 Received: by Research.Ftp.Com id AA02059; Mon, 15 Aug 94 13:39:50 -0400 Date: Mon, 15 Aug 1994 13:39:50 +0059 (EDT) From: Frank Kastenholz Subject: Re: rtp comments To: Henning Schulzrinne Cc: casner@isi.edu, rem-conf@es.net In-Reply-To: <9408040725.AA11498@Research.Ftp.Com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Henning, Sorry it took me so long to get back to you. Thanks for your response. On Thu, 4 Aug 1994, Henning Schulzrinne wrote: > > on page 8, the second paragraph from the bottom, beginning "A recorder > > records RTP..." this paragraph is confusing. the last sentence can sort of > > be taken to mean that timestamps can be encrypted but not the data (which > > is a) probably not what you mean to say and b) would be silly). i assume > > that a recorder's function is to record packets and then re-transmit them > > later on? it does not actually say this in the 'graf. or am i very very > > very confused? > > This should be clarified. It does, however, say "a recorder records RTP > and RTCP packets for later playback", which is pretty much what you > just said, or? The encryption problem is the opposite, actually: > Ideally, a recorder should reconstruct the timing at the sender rather > than any delay jitter accumulated. For that, it needs timestamps. The > current encryption encompasses the whole packet, so I must hand the > recorder the keys to the session in order to have the recorder play it > back with the original timing. Usually, that's no problem, but there > are situations where I want to have a technician/operator/etc. record a > session, store it encrypted on some fileserver and then play it back, > without handing the key to either storage server or technician. This case > is probably infrequently enough that it was decided to handle untrusted > recorders by forcing them to recreate the packet sequence as received, > jitter and all. It depends on what is meant by 'playback'. If it includes transmitting the packets back on to the net for later viewing/... by others (which I think is what you mean) then you are correct. However, if 'playback' means that I record it on my workstation and then watch/listen to the session later on then it all gets silly. If I record a session on my workstation, for later viewing, then I must have the encryption keys to actually watch the session. Therefore, how could there be a problem, because of encrypted timestamps, in reconstructing the timing? I imagine that if you completely describe the scenario (i.e. record on a semi-trusted host for later retransmission over the network for viewing by trusted hosts) then it all becomes very clear. > > on page 15, for the rtcp packet length. why is this in 4-byte words? the > > length field is 16 bits. is it possible that an rtcp packet can be longer > > than 65535 bytes? if so, i'd respectfully suggest that there is a design > > problem someplace. > > Van suggested this optimization. Since the packet length can only be > multiples of 4 bytes, there's no point in carrying around the lower two > bits and (more importantly) checking them to make sure they are indeed > zero. Packet lengths are multiples of 4 only because we require padding to make it so. Without padding, an SDES packet may have any length, the BYE packet may have any length (the optional 'reason for leaving' field... which, by the way, does not have a 'length' field in it so I can not disambiguate trailing pad bytes from 'valid' bytes), and most packets allow for application specific extensions, which could be any length. Anyway, assuming that the lengths all are a multiple of 4, checking to see that the length is a multiple of 4 is not really needed. For safety I'd always check that the length is 'correct' -- i.e. compare the length of the packet with the sizeof(the structure in the packet) so there's no extra 'make sure the low 2 bits are 0'... > > why doesn't the reception report indicate the number of bytes received? > > this would be a reasonable indication of the bandwidth that is getting > > through to the receiver, and the sender could then make adjustements as > > appropriate. > > It would appear that the number of packets getting through would be > a reasonable approximation. Since sequence numbers number packets, not > bytes, receivers can only compute the expected number of packets, not > bytes. Since video and audio data rates can vary dramatically, it's > very difficult (except over very long time periods) to align byte counts > and get good loss estimates. (The receiver would have to say that > it got N bytes, starting at seq. # S1, with the last being # S2, and > the sender grrrrr. I didn't state myself very clearly. The basic idea is that the receiver would report the number of bytes it's received. The sender could then calculate the bytes/sec throughput that the receiver gets and then make adjustments accordingly. I do not think that it has to be correlated to an actual packet -- if I am sending X bytes/sec and you are receiving only .75X then I know that there is a problem. Counting _just_ packets could be a problem since the packets might not all be the same size... > > is it reasonable to use 1/65535 of a second for the units of the 'delay > > since last sr' value? most systems can do milliseconds or the like. doing > > the conversion adds overhead that's really not needed. even more, the > > conversion would, no doubt, be done simply: take the millisecond > > difference and multiply by 65, or perhaps even just shift-left by 6 bits > > -- multiply by 64. > > There was a basic decision to use NTP timestamps throughout, as I would > have a hard time justifying having NTP units in one place, milliseconds > in a second, fortnights in a third, etc. The real issue will be in terms of how accurate the delay-since-last-sr must be. If the loss of accuracy in going from local ms to something close to 1/65535 (eg 1/65000 or 1/64000 of a second) then this is ok. > From what I can tell, to get > below a second for Posix, you use gettimeofday() to get microseconds, > which you would need to convert as well to get milliseconds. Not everyone uses a posix-like system. To design the protocol for such a system would be a bad thing. > > instead of a c enum, please explicitly assign values to the various > > enumerated values (rtcp types, sdes elements, etc). > > That was planned. Would you prefer a single table (easier to keep > consistent) or list them with each description? A single table. Frank Kastenholz From rem-conf-request@es.net Mon Aug 15 15:44:59 1994 Received: from SGI.COM by osi-west.es.net via ESnet SMTP service id <14184-0@osi-west.es.net>; Mon, 15 Aug 1994 12:44:16 +0000 Received: from entropy.wpd.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:rem-conf@es.net> id MAA27193; Mon, 15 Aug 1994 12:44:08 -0700 Received: by entropy.wpd.sgi.com (931110.SGI/911001.SGI) for @sgi.sgi.com:rem-conf@es.net id AA10257; Mon, 15 Aug 94 12:43:49 -0700 From: Kameran Kashani Message-Id: <9408151243.ZM10255@entropy.wpd.sgi.com> Date: Mon, 15 Aug 1994 12:43:48 -0700 In-Reply-To: Stephen Casner "Re: rem-conf mailing list" (Aug 10, 15:42) References: <776558520.0.CASNER@XFR.ISI.EDU> X-Face-Info: Deth Specula: Band on the Web X-Face: 88YO&XZ=E?4l"0P-m!,CW?!.)vARIPk0VY;@3)TbM|wvq{SK Z.l#Y-wjJa$]Ptd6^}dO9aw)7>?h(=J=pcY+Fr~u'Oc5or1^,vH 07L'|.hi#o#bpXNN{+'l|NO`]^F76Lu>&xqcg-*Sf3tGO|_ WWbL)hpJO1sH,?%K3[tRi`0K;"N?OQu^cEZ2*xDH!)9HW"t!a3M#kn>4[GDk X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: rem-conf@es.net Subject: Announce Cc: kamk@entropy.wpd.sgi.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 This is to announce an audio, video, and whiteboard broadcast of a live rock concert, Tuesday night, August 23rd, from 7:30pm to 8:30pm PDT over MBONE. Assuming there are no conflicts with this time, we'll announce the port, address and TTL over sd. Thanks, Kam Kashani Silicon Graphics Computer Systems -- "After Alpine Valley, they did Love Light, into Sugarree, into Dark Star, into Love Light, into Sugarree, into Love Light, into Dark Star, into Sugarree... and then the *moon* came out, and it was like Jerry willed it!" -- MST3K #603 kamk@sgi.com From rem-conf-request@es.net Mon Aug 15 17:26:33 1994 Received: from stimpy.acofi.edu by osi-west.es.net via ESnet SMTP service id <14712-0@osi-west.es.net>; Mon, 15 Aug 1994 14:26:04 +0000 Received: from [198.60.192.26] by stimpy.acofi.edu with SMTP (1.37.109.7/16.2) id AA18386; Mon, 15 Aug 94 15:24:55 -0600 Date: Mon, 15 Aug 94 15:24:55 -0600 X-Sender: ssaunder@stimpy.acofi.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: ssaunder@stimpy.acofi.edu (Shari Saunders) Subject: Comdex X-Mailer: Anyone out there have any info regarding the 1994 Comdex convention? Your comments and info is very much appreciated. Thanks, Shari From rem-conf-request@es.net Mon Aug 15 19:00:59 1994 Received: from SGI.COM by osi-west.es.net via ESnet SMTP service id <15091-0@osi-west.es.net>; Mon, 15 Aug 1994 16:00:36 +0000 Received: from entropy.wpd.sgi.com by sgi.sgi.com via SMTP (940627.SGI.8.6.9/910110.SGI) for <@sgi.sgi.com:rem-conf@es.net> id QAA26683; Mon, 15 Aug 1994 16:00:30 -0700 Received: by entropy.wpd.sgi.com (931110.SGI/911001.SGI) for @sgi.sgi.com:rem-conf@es.net id AA10506; Mon, 15 Aug 94 16:00:28 -0700 From: Kameran Kashani Message-Id: <9408151600.ZM10504@entropy.wpd.sgi.com> Date: Mon, 15 Aug 1994 16:00:27 -0700 X-Face-Info: Deth Specula: Band on the Web X-Face: 88YO&XZ=E?4l"0P-m!,CW?!.)vARIPk0VY;@3)TbM|wvq{SK Z.l#Y-wjJa$]Ptd6^}dO9aw)7>?h(=J=pcY+Fr~u'Oc5or1^,vH 07L'|.hi#o#bpXNN{+'l|NO`]^F76Lu>&xqcg-*Sf3tGO|_ WWbL)hpJO1sH,?%K3[tRi`0K;"N?OQu^cEZ2*xDH!)9HW"t!a3M#kn>4[GDk X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: rem-conf@es.net Subject: Re: Announce Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Well, several people have asked me for more information about my announcement. Here it is: The show that we're broadcasting is the SF Bay Area band "Deth Specula." We (I'm in the band) play 70s influenced rock, filtered through 80s punk, with a 90s feel. Whatever the hell that means. We'll be performing a slew of computer-industry parody songs (such as "Internet Band" to the tune of "American Band," "UNIX Bugs" to the tune of "Jungle Love," and "They Wanna Be Updated" to the tune of "I Wanna Be Sedated") plus a couple of original tunes to boot. We're playing at this year's SCO developer's conference, SCO Forum94, which is taking place at U.C. Santa Cruz. Again, showtime is approx 7:30 to 8:30, but we're only playing for about 1/2 hr somewhere in there. SCO is not certain of their own schedule -- they are a *software* company after all ;-) ;-). Before we actually take the stage we'll be showing some of the home-grown videos we've made of our parody songs. If you'd like more info on the band, see: http://klinzhai.iuma.com/specula/index.html Besides broadcasting on MBONE, we'll be encoding the music in MPEG format as we play it and uploading the resulting files to the Internet Underground Music Archive (IUMA) Web site (http://www.iuma.com/). That way folks w/o MBONE access can "tune in" after a fashion. Kam Kashani -- "After Alpine Valley, they did Love Light, into Sugarree, into Dark Star, into Love Light, into Sugarree, into Love Light, into Dark Star, into Sugarree... and then the *moon* came out, and it was like Jerry willed it!" -- MST3K #603 kamk@sgi.com From rem-conf-request@es.net Mon Aug 15 19:06:33 1994 Received: from fnal.fnal.gov by osi-west.es.net via ESnet SMTP service id <15102-0@osi-west.es.net>; Mon, 15 Aug 1994 16:05:58 +0000 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HFY46MHBJK006EA4@FNAL.FNAL.GOV>; Mon, 15 Aug 1994 18:05:51 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA12815; Mon, 15 Aug 94 18:05:05 CDT Date: Mon, 15 Aug 1994 18:05:04 -0500 From: Matt Crawford Subject: live on MBONE: Fermilab Industrial Affiliates To: rem-conf@es.net Cc: demar@FNAL.FNAL.GOV, kaletka@FNAL.FNAL.GOV Reply-to: crawdad@FNAL.FNAL.GOV, demar@FNAL.FNAL.GOV, kaletka@FNAL.FNAL.GOV Message-id: <9408152305.AA12815@munin.fnal.gov> Content-transfer-encoding: 7BIT The annual Fermilab Industrial Affiliates meeting will take place here at Fermilab September 8th and 9th. Portions of the meeting, including the keynote address on networking and "information highway" will be carried live on the MBONE. (A schedule will follow at a later date.) If a bandwidth conflict should occur, we may restrict most of our multicasting to ESNET. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From rem-conf-request@es.net Tue Aug 16 06:33:05 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <17576-0@osi-west.es.net>; Tue, 16 Aug 1994 03:32:38 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <03937-0@ceres.fokus.gmd.de>; Tue, 16 Aug 1994 08:08:05 +0200 Subject: Re: SDES suggestion To: kasten@Research.Ftp.Com Cc: casner@isi.edu, rem-conf@es.net Date: Tue, 16 Aug 1994 08:08:05 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de Frank Kastenholz wrote: >> >> >> I'm currently writing the code to receive and parse SDES packets. It would >> make life a lot easier if we had a specific SDES item called >> End_of_list_and_pad (or the like). It would A) specifically mark the end >> of the SDES item list for a specific SSRC/CSRC (much as the byte of 0 does >> in the 18 july spec), and B) the length field of the item (and of course, >> the item's length itself) would give the pad length in the next SSRC/CSRC. >> It would make the coding a bit easier. It would add another byte to the >> packet for the padding. >> I think it's fine either way, but I'm not sure of the complication: My write code "at the end" is: /* terminate with zero byte */ mtod(m, char *)[0] = '\0'; m->m_len++; m->m_off++; /* if necessary, pad with zeroes to next 4-byte boundary */ pad = PAD(m->m_len); memset(mtod(m, char *), RTCP_SDES_END, pad); m->m_len += pad; m->m_off += pad; where #define PAD(x) ((4 - ((x) & 0x3)) & 0x3) The read code is: for (; rsp->type; rsp = (rtcp_sdes_item_t *)((char *)rsp + rsp->length)) { if (rsp->length < 2 || rsp->type > RTCP_SDES_TXT) return 0; site_set_sdes(rsp->type, s, rsp->data, rsp->length - 2); } We could save the "< 2" check if we did the same redefinition trick we played for the RTCP packets. Can't be much shorter than that... Maybe we should put some "good" SDES code in the spec appendix. Henning -- --- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 219 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin From rem-conf-request@es.net Tue Aug 16 08:47:15 1994 Received: from dxmint.cern.ch by osi-west.es.net via ESnet SMTP service id <17845-0@osi-west.es.net>; Tue, 16 Aug 1994 05:46:47 +0000 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18146; Tue, 16 Aug 1994 14:46:44 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11923; Tue, 16 Aug 1994 14:46:40 +0200 From: isnard@dxcoms.cern.ch (Christian Isnard) Message-Id: <9408161246.AA11923@dxcoms.cern.ch> Subject: CERN broadcast on MBONE To: rem-conf@es.net Date: Tue, 16 Aug 1994 14:46:40 +0200 (MET DST) Cc: teleconf@cearn.cern.ch, tele-ext@cearn.cern.ch, Evans@cernvm.cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1395 CERN is pleased to announce that the lecture "The Large Hadron Collider" by Lyndon Evans (CERN) will be broadcast on MBONE on Friday August 19th between 16:00 GMT and 16:45 GMT This lecture was given on August 9th at 08:00 GMT in CERN main auditorium in the context of the Summer Student Lectures. It was recorded on VHS tape. Summary of Proposed Talk The Large Hadron Collider (LHC) will be built in the years 1995-2001 and will provide the world's particle physics community with the means of taking the next big step in the understanding of the fundamental constituents of matter. Following the long CERN tradition, it will use innovative technology in order to address the high energy frontier at affordable cost. This lecture will review the basic design of the machine and the technologies required to build it. The session will be advertised in sd as "CERN_Vnet - LHC Lecture". Please inform me if this broadcast may clash with an important event on MBONE. -- Christian Isnard Email: isnard@dxcoms.cern.ch European Laboratory for Particle Physics CERN - CN/CS/EN Computers and Networks division Tel: +41 22 767 23 94 CH-1211 Geneva 23 - Switzerland Fax: +41 22 767 71 55 From rem-conf-request@es.net Wed Aug 17 13:48:06 1994 Received: from hillhead.cent.gla.ac.uk by osi-west.es.net via ESnet SMTP service id <28086-0@osi-west.es.net>; Wed, 17 Aug 1994 10:47:38 +0000 Received: from kite.psy.gla.ac.uk by jess.glasgow.ac.uk with SMTP (PP) id <02104-0@jess.glasgow.ac.uk>; Wed, 17 Aug 1994 18:47:29 +0100 From: Anne Marie Date: Wed, 17 Aug 94 18:50:02 BST Message-Id: <1567.9408171750@dove.psy.gla.ac.uk> To: rem-conf@es.net Subject: Subscribe subscribe AnneMarie Fleming From rem-conf-request@es.net Wed Aug 17 16:39:18 1994 Received: from delphi.ndhm.gtegsc.com by osi-west.es.net via ESnet SMTP service id <29642-0@osi-west.es.net>; Wed, 17 Aug 1994 13:38:49 +0000 Received: from mail.ndhm.gtegsc.com by delphi.ndhm.gtegsc.com with SMTP; Wed, 17 Aug 1994 16:40:01 -0400 (EDT) Message-ID: Date: 17 Aug 1994 16:45:10 -0500 From: Murtland Jeff Return-Receipt-To: "Murtland Jeff" Subject: Unsubscribe To: rem-conf X-Mailer: Mail*Link SMTP/MS 3.0.0 I tried sending this to rem-conf-request@es.com, but got the following error. Bad address -- Error -- Address refused by receiver: (550 ... User unknown) please remove jeff.murtland@gtegsc3.sprint.com Thanks. Jeff From rem-conf-request@es.net Wed Aug 17 19:19:07 1994 Received: from bstgw1.bst.bls.com by osi-west.es.net via ESnet SMTP service id <00891-0@osi-west.es.net>; Wed, 17 Aug 1994 16:18:38 +0000 Received: from bstgw.bst.bls.com by bstgw1.bst.bls.com with smtp (Smail3.1.28.1 #11) id m0qauIO-0000bkC; Wed, 17 Aug 94 19:21 EDT Received: from beavis by bstgw.bst.bls.com (4.1/SMI-4.1) id AA01848; Wed, 17 Aug 94 19:19:56 EDT Received: by beavis (5.0/SMI-SVR4) id AA15490; Wed, 17 Aug 1994 18:18:17 +0600 Date: Wed, 17 Aug 1994 18:18:17 +0600 From: mike.richards@bst.bls.com (Mike Richards) Message-Id: <9408172318.AA15490@beavis> To: rem-conf@es.net Subject: Plans for MBONE at Interop'Sept 94 X-Sun-Charset: US-ASCII Content-Length: 571 Does anyone know what plans there are for MBONE at Interop in Atlanta. Will there be a feed/tunnel? Who must one coordinate with to create nv/vat sessions? General plans? Mike ***************************************************************** * Mike Richards (205-977-5193) ATG - BellSouth Telecommunications * E8B1, 3535 Colonnade Pkwy, Birmingham, Al. 35243 * Fax: 205-977-1351 * The views expressed are those of the author and may * not reflect the views of BellSouth Telecommunications Inc. ***************************************************************** From rem-conf-request@es.net Wed Aug 17 19:36:03 1994 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <07757-0@osi-east.es.net>; Wed, 17 Aug 1994 16:35:45 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA19756; Wed, 17 Aug 94 16:35:44 PDT Date: Wed, 17 Aug 94 16:35:44 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9408172335.AA19756@viipuri.nersc.gov> To: rem-conf@es.net Subject: FORWARDED: Broadcast announcement ----- Begin Included Message ----- >From moraes@alpha.coe.ufrj.br Wed Aug 17 14:55:42 1994 Date: Wed, 17 Aug 94 18:54:59 EST From: moraes@alpha.coe.ufrj.br (Luiz Felipe de Moraes) To: rem-conf-request@es.net Subject: Broadcast announcement Content-Length: 6740 Arrangements are been made for a live broadcast over the Internet MBONE of the plenary, technical sessions, and invited talk at the ITS'94 to be held in Rio de Janeiro, Brazil, on August 22-25, 1994. The software requirements to view the broadcast include the Internet tools: nv, vat, and sd (More information on the MBONE is available from venera.isi.edu:mbone/faq.txt). Please find enclosed below the final program for the part of ITS'94 which is going to be broadcast. Parties involved in the whole setup are: Comsat World Systems, Embratel, MFS, NEC, SURAnet, Federal University of Rio de Janeiro (UFRJ), FAPERJ/RedeRio and SUN Microsystems. ****************************************************************************** SBT/IEEE 1994 International Telecommunications Symposium - ITS'94 ITS'94 Program for Multicast Experiment ****************************************************************************** Venue: Rio Palace Hotel, Rio de Janeiro, Brazil Tuesday, Aug.23 9:30-10:15 Opening Session 10:30-11:30 Plenary Session: The Future of Telecommunications, John S. Mayo, President, AT&T Bell Laboratories (U.S.A.) 14:00-15:00 Invited Talk: Perspectives on Integrated Services, High Speed and Congestion, Robert G. Gallager (U.S.A.) 15:20-17:30 Technical Session 2: Routing in Multiservice Network Paper 2.1 - Performance Analysis of Broadcast Algorithms Based on Flooding P.A.Hosein (Trinidad and Tobago) Paper 2.2 - Optimal Routing in Shortest-Path Networks, M.A.Rodrigues (Brazil) and K.G.Ramakrishnan (U.S.A.) Paper 2.3 - Topology Reconfiguration of Multiservice ATM Networks, C.M.D.Pazos (U.S.A.), J.A.S.Monteiro (Brazil) and M.Gerla (U.S.A.) Paper 2.4 - Evaluation of Multicast Routing Algorithms for Multimedia Streams, C.A.Noronha-Jr. and F.A.Tobagi (U.S.A.) Wednesday, Aug.24 8:30-9:50 Panel Session: Multimedia Applications and Networking S.B.Weinstein, Chairman (U.S.A.) J. Derby (U.S.A.) J. Martins (Portugal) K. Watanabe (U.S.A.) M. Decina (Italy) 10:05-11:30 Panel Session: Design Issues in High Speed Multimedia Networks D. Towsley, Chairman (U.S.A.) R.G.Gallager (U.S.A.) F.A.Tobagi (U.S.A.) N. Maxemchuck (U.S.A.) 11:30-12:30 Plenary Session: The Coming Ubiquity of Digital Wireless Access Intelligent Network, Irwin M. Jacobs, Chairman and CEO Qualcomm, Inc., (U.S.A.) 14:00-15:00 Invited Talk: Will ATM be the end of MAN, Nicholas Maxemchuck (U.S.A.) 15:20-17:30 Technical Session 10: Wireless Personal Communications: Protocols, Architectures and Routing Paper 10.1 - Mobile IP, C.E.Perkins (U.S.A.) and A.M.Myles (Australia) Paper 10.2 - Selecting Router in Ad-Hoc Wireless Networks, A.K.Parekh (U.S.A.) Paper 10.3 - A MEO Constellation Network Architecture for a Global Personal Communication System, M.Dinis (Portugal), J.Neves (Portugal), R.Tafazoli (U.K.) and B.Evans (U.K.) Thursday, Aug.25 8:30-9:50 Technical Session 13: Performance Analysis of ATM Networks Paper 13.1 - Performance Analysis of a Non-Preemptive Priority Scheme for ATM Multimedia Services, M.Abbas (Malaysia) Paper 13.2 - Some Numerical Results on Finite-Buffer Markovian Multiserver Polling Systems, M.Ajmone-Marsan, S.Donatelli, F.Neri and G.Fantini (Italy) Paper 13.3 - On the Computation of End-to-End Delay in Feed-Forward ATM Networks, N.L.S.Fonseca and J.A.Silvester (U.S.A.) 10:05-11:30 Technical Session 17: ATM Congestion Control in Integrated Services Networks Paper 17.1 - Congestion Control with Double Threshold in ATM Networks, S.G.Jong and Y.O.Chu, K.Hee (Korea) Paper 17.2 - On the Efficiency of Policing Mechanisms for ATM Networks, J.A.Frazao-Jr. and J.A.S.Monteiro (U.S.A.) 11:30-12:30 Plenary Session: Global Telecommunication Standardization in a Changing World - A Challenge for the International Telecommunication Union (ITU), Theodor Irmer, Director, ITU Telecomm. Standards Bureau (ITU-T) 14:00-17:30 Technical Session 22: Emerging Network Operation Technologies and Applications Paper 22.1 - Performance Evaluation of Interconnected Networks, F.Georges (France) Paper 22.2 - Functional Architecture for Customer Service Operation, S.Uchikawa, Y.Fujida and K.Murata (Japan) Paper 22.3 - Recife-a Management Tool for the Greater Paris Telecommunications Network, M.Benzidi, L.Burity and G.Pichon (France) Paper 22.4 - Subnetwork Management and TMN in a Evolving Network, H.Dysart and S.Aidarous (Canada) Paper 22.5 - Design and Implementation of a Telecommunication Management Network: System and Information Viewpoints, N.Agoulmine, J.N. de Souza (France) and G.Pavlou (U.K.) Paper 22.6 - Integrated Service Mnagement within Heterogeneous Environment P.Ray (Australia) Friday, August 26 9:00-17:30 International Workshop on Network Management PROGRAM ----------------------------------------------------------------------- 9:00-9:15 OPENING REMARKS Thomas Plevyak, Workshop Co-Chair Raul Colcher, Workshop Co-Chair 9:15-10:15 INTRODUCTION Francisco Albuquerque, Embratel 10:30-11:15 STANDARDS David Sidor, BNR 11:15-12:00 INFORMATION MODELING * Lakshmi Raman, Bellcore 1:30-2:45 APPLICATIONS & CHALLENGES Carey Anderson and Jim Goett, Bellcore 3:00-3:45 IMPLEMENTATION EXPERIENCES Stefan Brock, DBP Telekom 3:45-4:15 PLATFORMS/INTEGRATION ISSUES Joseph Lias, Premisys Communications 4:15-5:15 PANEL DISCUSSION Brasil Bruno Vianna, CPqD Mexico Arturo Alaluf, Telmex USA Carey Anderson Germany Stefan Brock 5:15-5:30 CLOSING REMARKS Salah Aidarous, CNOM Roberto de Marca, ITS'94 General Chairman ------------------------------------------------------------------------ ----- End Included Message ----- From rem-conf-request@es.net Thu Aug 18 08:50:05 1994 Received: from vesuv.RZ.TU-Ilmenau.DE by osi-west.es.net via ESnet SMTP service id <03484-0@osi-west.es.net>; Thu, 18 Aug 1994 05:49:40 +0000 Received: from PrakInf.TU-Ilmenau.DE (actually atlantis.PrakInf.TU-Ilmenau.DE) by vesuv.rz.tu-ilmenau.de with SMTP (PP); Thu, 18 Aug 1994 14:49:01 +0000 Received: from nero.prakinf by PrakInf.TU-Ilmenau.DE (4.1/SMI-4.1(mailhost)) id AA01785; Thu, 18 Aug 94 14:49:00 +0200 From: Hans-Ulrich.Otto@PrakInf.TU-Ilmenau.DE (Otto) Message-Id: <9408181249.AA01785@PrakInf.TU-Ilmenau.DE> Subject: unsubscribe To: rem-conf@es.net Date: Thu, 18 Aug 94 14:49:00 MET DST X-Mailer: ELM [version 2.3 PL11] Please unsubscribe me . Thak You otto@prakinf.tu-ilmenau.de From rem-conf-request@es.net Thu Aug 18 13:15:16 1994 Received: from stone.ucs.indiana.edu by osi-west.es.net via ESnet SMTP service id <05707-0@osi-west.es.net>; Thu, 18 Aug 1994 10:14:58 +0000 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA18810; Thu, 18 Aug 94 12:14:52 EST Date: Thu, 18 Aug 1994 12:14:52 -0500 (EST) From: Cell-Relay Gopher Janitor Subject: Re: Plans for MBONE at Interop'Sept 94 To: Mike Richards Cc: rem-conf@es.net In-Reply-To: <9408172318.AA15490@beavis> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Does anyone know what plans there are for MBONE at > Interop in Atlanta. Will there be a feed/tunnel? > Who must one coordinate with to create nv/vat sessions? > General plans? I know that they plan on having one (cuz they mention it in their literature), but do not know what the specifics are.... allen From rem-conf-request@es.net Fri Aug 19 02:29:45 1994 Received: from fafner.Stanford.EDU by osi-west.es.net via ESnet SMTP service id <09587-0@osi-west.es.net>; Thu, 18 Aug 1994 23:29:21 +0000 Received: (from mosedale@localhost) by fafner.Stanford.EDU (8.6.8.1/8.6.6) id XAA10815 for rem-conf@es.net; Thu, 18 Aug 1994 23:29:20 -0700 From: Dan Mosedale Message-Id: <199408190629.XAA10815@fafner.Stanford.EDU> Subject: Comments on the ISMB conference To: rem-conf@es.net Date: Thu, 18 Aug 1994 23:29:20 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4262 I got some comments about the ISMB MBONE multicast from one of the viewers. Here are his comments and my responses. I figured you folks would find this interesting as food for thought... Dan > > Inclusion of Postscript versions of some speakers' slides on the > > whiteboard was very helpful, and should be made semi-mandatory if at > > all possible. > > Agreed. > > > We also liked the windows titles with the name of the current > > speaker. > > Glad to hear it; I was wondering whether people cared about this. > > > All in all, we were quite impressed by the broadcast. > > Great! We had fun doing it, and the conference attendees got a kick > out of it as well. > > > Unfortunately, the quality of dvi encoded audio is still marginal > > for understanding a human voice. It required a very sustained > > concentration effort to understand the speakers, let alone absorb > > the message they were trying to convey (by the way, we use good > > quality amplified speakers on our workstation, so it is not a local > > playback problem). Other audio encoding schemes or looser > > compression parameters, maybe using more bandwidth, would be > > desirable, even if at the expense of one of the video channels. > > Now this is interesting. In fact, due to software problems, I used > PCM on the first two days, and DVI on the third. If I had known that > it was hard to understand, I would have switched back. > > I wonder if the problem isn't so much DVI as the nature of the MBONE: > some parts of it lose many more packets than others. If so, PCM would > still perform better, but only because it happens to be more amenable > to dropouts (since it is a bulkier format). > > I actually performed a test with a buddy of mine in Germany a few days > beforehand, and we really couldn't notice much difference between DVI > and PCM. Did you happen to look at the statistics that VAT keeps and > notice what percentages of packets were being dropped and/or > misordered? > > > Second, the speakers should be made more aware of the constraints > > imposed by the broadcast. > > Agreed. > > > Particularly, a transparency or slide left on the projector for less > > than 30 s (there were many...) does not have time to appear clearly > > on the video. > > Yeah, this is very true. In fact, on the third day, I upped the slide > channel bandwidth from 60 kb/s to 100 kb/s, with the hopes of > alleviating this problem slightly. If everyone gave slides in > PostScript for the whiteboard, this wouldn't be a big deal. > > > Given the relatively poor audio quality, a slower and better > > articulated speech pattern would also help (dream on...) > > :-) Actually, I think this isn't such a big deal: net.bandwidth is > only growing, and as router software that does native multicast > routing (eliminating the need for tunnels) comes into wider use, MBONE > packet lossage should become somewhat less of a problem. > > > > > [some suggestions for the whiteboard] > > > > rotation of figures, > > That's already in there; I think it's described in the lblwb.ps > document that comes with wb. > > > construction of thumbnails of the pages to allow faster navigation > > and retrieval > > Good idea; I like this! > > > ability to quickly mute all but one of the participants (they can > > only be turned off one at a time now). > > Another good idea. > > > By the way, it would be helpful to have a whiteboard page with the > > conference program and tick marks next to the talks already given. > > Yes, I agree; I'll try and do this next time I work on an MBONE > conference. > > > To summarize, we were very impressed by the demonstration, but not > > ready to use the current technology to follow entire conferences or > > seminars, at least until the audio quality gets better. > > As mentioned before, try testing PCM encoding, and if large-scale > packet-lossage is a recurring problem, see if you can track down which > mrouter/tunnel is causing it. > > > Thank you for organizing this broadcast, which has helped us > > tremendously in understanding the possibilities and limitations of > > MBONE-based transmissions. > > You're very welcome; thanks for taking the time to pass along your > thoughts. > > Dan From rem-conf-request@es.net Fri Aug 19 09:17:19 1994 Received: from Mailer.er.doe.gov by osi-west.es.net via ESnet SMTP service id <11644-0@osi-west.es.net>; Fri, 19 Aug 1994 06:16:27 +0000 Received: by mailer.er.doe.gov (1.37.109.4/16.2) id AA00531; Fri, 19 Aug 94 09:17:30 -0400 From: ROBERT.LUPINACCI@mailgw.er.doe.gov Received: by mailgw.er.doe.gov via Worldtalk with X400 (2.3.0/1.52) id WT03813.288; Fri, 19 Aug 1994 09:17:30 EDT Date: 19 Aug 94 09:21:00 -0400 To: rem-conf@es.net Subject: Unsubscribe Message-Id: unsubscribe I have tried every address to unsubscribe to no avail, and this was the last resort. From rem-conf-request@es.net Sun Aug 21 11:48:23 1994 Received: from cs.rpi.edu by osi-west.es.net via ESnet SMTP service id <19731-0@osi-west.es.net>; Sun, 21 Aug 1994 08:47:42 +0000 Received: from colossus.cs.rpi.edu by cs.rpi.edu (5.67a/1.4-RPI-CS-Dept) id AA18178; Sun, 21 Aug 1994 11:35:34 -0400 (glinert from colossus.cs.rpi.edu) Date: Sun, 21 Aug 94 11:35:33 EDT From: glinert@cs.rpi.edu Received: by colossus.cs.rpi.edu (4.1/2.2-RPI-CS-client) id AA28091; Sun, 21 Aug 94 11:35:33 EDT Message-Id: <9408211535.AA28091@colossus.cs.rpi.edu> To: end2end-interest@venera.isi.edu, f-troup@AURORA.CIS.UPENN.EDU, ietf@venera.isi.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, rem-conf@es.net, sound@PASCAL.ACM.ORG, tccc@cs.umass.edu Subject: Come To ASSETS'94 In Los Angeles! /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ADVANCE PROGRAM AND REGISTRATION FORMS ASSETS '94 The First Annual International ACM/SIGCAPH Conference on Assistive Technologies October 31 - November 1, 1994 Doubletree Marina del Rey Hotel Los Angeles, California Sponsored by the ACM's Special Interest Group on Computers and the Physically Handicapped, ASSETS '94 is the first of a new annual series of conferences whose goal is to provide a forum where researchers and developers from academia and industry can meet to exchange ideas and report on new developments relating to computer-based systems to help people with impairments and disabilities of all kinds. This announcement includes 5 parts: o ASSETS '94 Advance Program o ASSETS '94 Registration Form o Hotel and Travel Arrangement Information o ACM / SIGCAPH Membership Application o Who are the organizers of ASSETS '94? If you have any questions or would Ephraim P. Glinert like further information, please Dept. of Computer Science contact the ASSETS '94 Program Chair: R. P. I. Troy, NY 12180 E-mail: glinert@cs.rpi.edu /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ASSETS '94 ADVANCE PROGRAM ========================== SUN 10/30: 18:00-21:00 Registration 19:00-21:00 Reception MON 10/31: 8:00-17:00 Registration 8:00- 9:00 Continental Breakfast 8:45- 9:00 Welcome to ASSETS '94! 9:00-10:00 Keynote I 10:00-10:30 Break 10:30-12:00 Papers I: Hearing Impairments "Pattern Recognition and Synthesis for Sign Language Translation System" Masaru Ohki, Hirohiko Sagawa, Tomoko Sakiyama, Eiji Oohira, Hisashi Ikeda and Hiromichi Fujisawa - Hitachi (Japan) "Multimedia Dictionary of American Sign Language" Sherman Wilcox and Joanne Scheibman - University New Mexico (USA) Doug Wood - Brains Software (USA) William C. Stokoe - Linstok Press (USA) "A System for Teaching Speech to Profoundly Deaf Children using Synthesized Acoustic and Articulatory Patterns" Elizabeth Keate, Hector Javkin, Norma Antonanzas-Barroso and Ranjun Zou - Panasonic Technologies (USA) 12:00-14:00 Lunch + SIGCAPH Business Meeting 14:00-15:00 Papers II: Augmentative Communication A "Iconic Language Design for People with Significant Speech and Multiple Impairments" P. L. Albacete, S. K. Chang and G. Polese - University of Pittsburgh (USA) B. Baker - Semantic Compaction Systems (USA) "The Application of Spatialization and Spatial Metaphor to Augmentative and Alternative Communication" Patrick Demasco, U. Delaware (USA), Alan F. Newell and John L. Arnott - University of Dundee (UK) 15:00-15:30 Break 15:30-17:30 Papers III: Vision Impairments A "Screen Reader/2: Access to OS/2 and the Graphical User Interface" Jim Thatcher - IBM Research (USA) "Providing Access to Graphical User Interfaces - Not Graphical Screens" W. Keith Edwards, Elizabeth D. Mynatt and Kathryn Stockton - Georgia Institute of Technology (USA) "Increasing Access to Information for the Print Disabled through Electronic Documents in SGML" Bart Bauwens, Jan Engelen and Filip Evenepoel - Katholieke Universiteit Leuven (Belgium) Tom Wesley and Chris Tobin - U. Bradford (UK) "Interactive Audio Documents" T. V. Raman, Digital Equipment Corporation (USA) David Gries, Cornell (USA) 18:00-21:00 Buffet Dinner + Keynote II 21:00-22:00 ASSETS '95 Organizational Meeting TUE 11/1: 8:00-12:00 Registration 8:00- 9:00 Continental Breakfast 9:00-10:00 Papers IV: Motor Impairments "An Overview of Programs and Projects at the Rehabilitation Research and Development Center" David L. Jaffe - Dept. of Veteran Affairs Medical Center (USA) "Using the Baby-Babble-Blanket for Infants with Motor Problems: A Case Study" Harriet J. Fell, Linda J. Ferrier, Hariklia Delta, Regina Peterson, Zehra Mooraj and Megan Valleau - Northeastern University (USA) 10:00-10:30 Break 10:30-12:00 Papers V: Vision Impairments B "Personal Guidance System for the Visually Impaired" Jack M. Loomis and Reginald G. Golledge - University of California at Santa Barbara (USA) Roberta L. Klatzky, Carnegie Mellon (USA) Jon M. Speigle and Jerome Tietz - University of California at Santa Barbara (USA) "Hyperbraille: A Hypertext System for the Blind" Thomas Kieninger and Norbert Kuhn - Deutsches Forschungszentrum fuer Kuenstliche Intelligenz (Germany) "Automatic Impact Sound Generation for use in Nonvisual Interfaces" Helmut Schauer - University of Zurich (Switzerland) A. Darvishi, V. Guggiana, E. Munteanu, M. Motavalli and M. Rauterberg - Swiss Federal Institute of Technology/ETH (Switzerland) 12:00-14:00 Lunch + Panel (Elizabeth Mynatt, moderator) 14:00-15:00 Papers VI: Augmentative Communication B "A Writing Tool for Physically Disabled Individuals: Lexical Semantics for Filling in the Pieces" Kathleen F. McCoy, Patrick W. Demasco, Mark A. Jones, Christopher A. Pennington, Peter B. Vanderheyden and Wendy M. Zickus - University of Delaware (USA) "Validation of a Keystroke-Level Model for a Text Entry System Used by People with Disabilities" Heidi H. Koester and Simon P. Levine - University of Michigan (USA) 15:00-15:30 Break 15:30-17:30 Papers VII: New Directions and Work-in-Progress "An Experimental Sound-Based Hierarchical Menu Navigation System for Visually Handicapped Use of Graphical User Interfaces" Arthur I. Karshmer, Pres Brawner and George Reiswig - New Mexico State University (USA) "A Rule-Based System that Suggests Computer Adaptations for Users with Special Needs" William W. McMillan, Michael Zeiger and Lech Wisniewski - Eastern Michigan University (USA) "LVRS: The Low Vision Research System" Mitchell Krell, University of Southern Mississippi (USA) "EEG as a Means of Communication: Preliminary Experiments in EEG Analysis using Neural Networks" Charles W. Anderson, Saikumar V. Devulapalli and Erik Stolz - Colorado State University (USA) "Audio Formatting of a Graph" Sophie H. Zhang and Mukkai Krishnamoorthy - Rensselaer Polytechnic Institute (USA) "Disabilities, Opportunities, Internetworking and Technology (DO-IT) on the Electronic Highway" Sheryl Bergstahler and Dan Comden - University of Washington (USA) 17:30 Close ASSETS '94 REGISTRATION FORM ############################################# ============================ This form is 2 pages long. Please print it out, complete both pages and mail it WITH FULL PAYMENT to: Ephraim P. Glinert, ASSETS '94 Dept. of Computer Science R. P. I. Troy, NY 12180 We're sorry, but e-mail registration forms and/or forms not accompanied by full payment (check or credit card information) CANNOT be accepted. CONFERENCE REGISTRATION FEES EARLY LATE / ON-SITE -------------------------------------------------------- ACM member: $ 395 $ 475 Nonmember: $ 580 $ 660 Full time student: $ 220 $ 270 -------------------------------------------------------- 1: CONFERENCE REGISTRATION (from the table): $ ___________ 2: EXTRA RECEPTION TICKET (Monday, Oct. 31): $ 40 ___YES ___NO 3: EXTRA COPY OF THE CONFERENCE PROCEEDINGS: $ 30 ___YES ___NO TOTAL AMOUNT DUE: $ ___________ NOTES: o Registration fee includes: ADMISSION to all sessions, one copy of the conference PROCEEDINGS, and MEALS as indicated in the program above. o To qualify for the EARLY rate, your registration must be postmarked on or before FRIDAY, SEPTEMBER 23, 1994. If you are an ACM MEMBER, please supply your ID# __________________ (OR use the membership application below to join ACM and SIGCAPH today!). STUDENTS, please attach a clear photocopy of your valid student ID. o CANCELLATIONS will be accepted up to FRIDAY, OCTOBER 14, 1994 subject to a 20% handling fee. ASSETS '94 REGISTRATION FORM (continued) ======================================== PERSONAL INFORMATION: Name __________________________________________________________________________ Affiliation ___________________________________________________________________ Address _______________________________________________________________________ City _______________________________ State/Province __________________________ Country __________________________________ Zip/Postal Code ___________________ E-mail ___________________________________ Telephone _________________________ ***I have a disability for which I require special accommodation ___YES ___NO If YES, please attach a separate sheet with details. Thank you! PAYMENT INFORMATION: ___CHECK in U.S. funds enclosed, made payable to "ACM ASSETS '94" ___Please charge $ ___________ to my CREDIT CARD: Card type: ___AMEX ___VISA ___MasterCard Card # _______________________________________ Expiration Date ___________ Name On Card ______________________________________________________________ Billing Address ___________________________________________________________ Cardholder Signature _______________________________________ (ASSETS '94) ############################################################################### HOTEL AND TRAVEL ARRANGEMENT INFORMATION ======================================== All conference events will take place at the Doubletree hotel in Marina del Rey (the precise address is 4100 Admiralty Way, Marina del Rey CA 90292). The hotel is located just a few minutes from Los Angeles International Airport (LAX). A block of rooms for attendees of ASSETS '94 has been set aside at a special discounted rate of $86 per night (single or double), plus applicable taxes. To reserve space at this price, please call the hotel directly BEFORE OCTOBER 9 at (800) 353 6664 toll free, or (310) 301 3000, and refer to "ACM ASSETS '94". BIRKMAYER TRAVEL, the official travel agency for ASSETS '94, is offering discounted airfares to attendees on United, Delta and USAir. The terms vary for each airline, but in general discounts of up to 50% and more are available, and no Saturday night stay is required. Please note that the reduced fares apply only to travel within the continental United States or originating in Canada, that all prices are subject to change without notice, and fares are guaranteed only after tickets are actually purchased. Space is limited, and some restrictions apply. Please call Birkmayer Travel directly during normal East Coast business hours for further information/reservations: Birkmayer Travel, Inc. 2 Third Street Troy, NY 12180 Tel. (800) 338 5735 (continental U.S. and Canada) (518) 272 2650 (New York State and international) (518) 272 7257 (fax) Special discounted rates have also been arranged with HERTZ for attendees who wish to rent a car. For more information or to make reservations, just call Hertz Conference Services at 1 (800) 654 2240 and mention CV# 13646 (international attendees please contact your local Hertz office with this information). ACM / SIGCAPH MEMBERSHIP APPLICATION ==================================== USE THIS 2-PAGE FORM TO JOIN ACM + SIGCAPH TODAY AND SAVE ON CONFERENCE FEES! Please mark the appropriate box(es) and indicate total: ___ACM Associate Member Dues $82 (___Expedited Air Option: $32) ___ACM Student Member Dues $25 (___Expedited Air Option: $32) ___Add SIGCAPH to ACM Membership $15 (___Expedited Air Option: $3) ___Add SIGCAPH to ACM Student Membership $6 (___Expedited Air Option: $3) ___SIGCAPH Membership only (non-ACM) $42 (___Expedited Air Option: $3) ACM Membership No. (if applicable) ____________________ Total due: $__________ Membership in SIGCAPH includes a subscription to Computers and the Physically Handicapped newsletter (published three times a year) and discounted registration fees for any ACM sponsored CAPH conferences and publications. ACM Membership includes a full year's subscription to Communications of the ACM, substantial discounts on Publication Subscriptions, Conference Proceedings, Conference Registration, Special Interest Group (SIG) Memberships and the Member Value Plus program. You may join as an Associate Member and convert to Voting Member status by requesting a "Self Certification" form from ACM's Member Services Department. Purposes: To advance the sciences and arts of information processing; to promote the free interchange of information processing among computing specialists and the public; and to develop and maintain the integrity and competence of individuals engaged in the practice of information processing. As an ACM member, I subscribe to the purposes of ACM: Signature __________________________________________________ (___YES ___NO) ACM / SIGCAPH MEMBERSHIP APPLICATION (continued) ================================================ Name __________________________________________________________________________ Address ____________________________________ Telephone _______________________ City _______________________________ State/Province __________________________ Country __________________________________ Zip/Postal Code ___________________ E-mail ___________________________________ Fax _______________________________ PAYMENT INFORMATION: ___Check enclosed payable to "ACM, Inc." ___Please charge my Credit Card: Card type: ___AMEX ___VISA ___MasterCard Card #__________________________________________Expiration Date____________ Signature_______________________________________________________ (CAPH94) If you're completing this application online, please e-mail to: ACMHELP@ACM.org If you're printing this application out, please remit to: ACM P.O. Box 12115 Church St. Station New York, NY 10257 USA For inquiries regarding membership, contact the service center nearest you: ACM Member Services Department ACM European Service Center 1515 Broadway, 17th Floor Avenue Marcel Thiry 204 New York, NY 10036, USA 1200 Brussels, BELGIUM Phone: +1-212-626-0500 Phone: +32 2 774 9602 Fax: +1-212-944-1318 Fax: +32 2 774 9690 Email: ACMHELP@ACM.org Email: ACM_EUROPE@ACM.org WHO ARE THE ORGANIZERS OF ASSETS '94? ==================================== General Chair: Theodor D. Sterling, Simon Fraser University Program Committee: Norman Alm, University of Dundee Julie Baca, Waterways Experiment Station Meera M. Blattner, LLNL and U. California at Davis James L. Caldwell, IBM RISC Adaptive Technologies S.-K. Chang, University of Pittsburgh Patrick Demasco, University of Delaware Alistair D.N. Edwards, University of York Gerald L. Engel, National Science Foundation Carl Friedlander, ISX Corp. Hiromichi Fujisawa, Hitachi (Japan) Ephraim P. Glinert (Chair), RPI Ralph Guertin, MITRE Corp. Robert J.K. Jacob, Tufts University David L. Jaffe, Palo Alto VA Medical Center Earl Johnson, Sun Microsystems Labs Karen Kukich, Bell Communications Research Richard E. Ladner, University of Washington Clayton Lewis, University of Colorado at Boulder Elizabeth D. Mynatt, Georgia Inst. of Technology Randy Pausch, University of Virginia T.V. Raman, DEC Cambridge Research Laboratory Gregg C. Vanderheiden, TRACE Center at U. Wisconsin A. Rudy Vener, AT&T Bell Labs Bryant W. York, Northeastern University Treasurer: David H. Leserman, NOAA If you have any questions or would Ephraim P. Glinert like further information, please Dept. of Computer Science contact the ASSETS' 94 Program Chair: R. P. I. Troy, NY 12180 E-mail: glinert@cs.rpi.edu /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ From rem-conf-request@es.net Sun Aug 21 19:28:33 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <20432-0@osi-west.es.net>; Sun, 21 Aug 1994 16:27:59 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14486(6)>; Sun, 21 Aug 1994 16:27:51 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 21 Aug 1994 16:27:40 -0700 To: ietf@cnri.reston.va.us, rem-conf@es.net, mbone@isi.edu Cc: deering@parc.xerox.com Subject: IPng walkthrough -- change of 'sd' advertisements Date: Sun, 21 Aug 1994 16:27:31 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Aug21.162740pdt.12171@skylark.parc.xerox.com> There are now separate 'sd' sessions for the Audio, Video, and Whiteboard portions of the "IP:NG Design Review" presentations to be given at 10:00 am PDT (1700 GMT) on Monday, Aug 22. The Whiteboard session currently being advertised is for testing only; we will create a separate Whiteboard session before the meeting starts, to get a clean slate. Steve From rem-conf-request@es.net Mon Aug 22 01:47:19 1994 Received: from hplms26.hpl.hp.com by osi-west.es.net via ESnet SMTP service id <21163-0@osi-west.es.net>; Sun, 21 Aug 1994 22:46:26 +0000 Received: from telecomm.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA04220; Sun, 21 Aug 1994 22:41:51 -0700 Received: by telecomm.hpl.hp.com (1.37.109.8/15.5+ECS 3.3+HPL1.1) id AA15046; Sun, 21 Aug 1994 22:35:32 -0700 Date: Sun, 21 Aug 1994 22:35:32 -0700 From: NOSSDAV Workshop Message-Id: <9408220535.AA15046@telecomm.hpl.hp.com> To: nossdav-dist@telecomm.hpl.hp.com Subject: Workshop announcement 5th International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV '95) CALL FOR PAPERS April 19, 20, 21, 1995 Durham, New Hampshire, USA Sponsored by the IEEE Communications Society In cooperation with ACM SIGCOMM, SIGOPS, SIGMM, SIGGRAPH, and SIGIR Network and operating system support for digital audio and video are becoming increasingly important with the convergence of the computer, the TV, and communications. Innovation in this field is fueling the industry developments in interactive multimedia services to the home. In the past, research in this domain has largely originated as adaptations of specific technologies to support audio and video. This work has lead to an understanding of common cross-disciplinary problems. Increasingly, this work encompasses and integrates the diverse technology necessary to achieve end-to-end systems. To this end, research leading to complete solutions is viewed as particularly important to the workshop. The workshop is intended to bring together practitioners from a variety of areas, including communications and networks, operating systems, real-time systems and distributed computing. It is intended that an outcome of the workshop will be a statement of the the state of the art in this field, highlighting the major areas requiring future research. Relevant topics for the workshop include: High-speed/ATM networks Multimedia-oriented desk, local, and wide area networks Workstation architectures for multimedia Cell-based system architectures Multimedia network interfaces Communication protocols for multimedia Multicast Micro-kernel and OS support for real-time communications Resource management and reservation in the OS and network End-to-end admission control Quality of service and synchronization frameworks Multimedia storage, server, and I/O architectures Distributed multimedia systems APIs and CM programming abstractions for multimedia Community networking TV set-top device communication Instructions for Submitting Papers: Two types of submissions are solicited: position papers and research papers. For the purpose of paper review, position papers are restricted to three single-spaced ASCII pages. Research papers are restricted to an extended abstract no longer than five formatted postscript pages. Papers should be electronically mailed to nossdav95@spiderman.bu.edu Only if electronic submission is impossible, papers may be sent to: Prof. T.D.C. Little, Multimedia Communications Laboratory, Department of Electrical, Computer and Systems Engineering, Boston University, 44 Cummington Street, Boston, MA 02215 USA. Tel: +1 617 353-9877 Fax: +1 617 353-6440 tdcl@bu.edu. The proceedings of the workshop will be published by Springer-Verlag and the best papers will be forwarded to selected journals for publication. Important Dates: Abstracts due: December 12, 1994 Acceptance notification: January 25, 1995 Final paper due: March 8, 1995 Workshop: April 19, 1995 Program Co-Chairs: Riccardo Gusella, HP Labs, USA T.D.C. Little, Boston University, USA Program Committee: Stavros Christodoulakis, Technical University of Crete Domenico Ferrari, University of California, Berkeley Ralf Herrtwich, IBM Creative Multimedia Studios Andy Hopper, Olivetti & University of Cambridge Kevin Jeffay, University of North Carolina at Chapel Hill Chuck Kalmanek, AT&T Bell Laboratories Jim Kurose, University of Massachusetts at Amherst Aurel Lazar, Columbia University Derek McAuley, Cambridge University Duane Northcutt, Sun Microsystems Laboratories Guru Parulkar, Washington University Steve Pink, Swedish Institute of Computer Science Radu Popescu-Zeletin, GMD-FOKUS K.K. Ramakrishnan, Digital Equipment Corporation P. Venkat Rangan, University of California, San Diego Jon Rosenberg, Bell Communications Research Eve Schooler, USC/Information Sciences Institute Doug Shepherd, Lancaster University Cormac Sreenan, AT&T Bell Laboratories Jean-Bernard Stefani, France Telecom/CNET Daniel Swinehart, Xerox PARC Hideyuki Tokuda, Carnegie Mellon University/Keio University Jon Walpole, Oregon Graduate Institute of Science & Technology Raj Yavatkar, University of Kentucky This CFP is on-line at http://spiderman.bu.edu. From rem-conf-request@es.net Mon Aug 22 05:21:44 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <22741-0@osi-west.es.net>; Mon, 22 Aug 1994 02:21:16 +0000 Received: from zeus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Aug 1994 10:07:47 +0100 To: Dan Mosedale cc: rem-conf@es.net Subject: Re: Comments on the ISMB conference In-reply-to: Your message of "Thu, 18 Aug 94 23:29:20 PDT." <199408190629.XAA10815@fafner.Stanford.EDU> Date: Mon, 22 Aug 94 10:07:46 +0100 From: Gordon Joly We have been thinking along similar lines for the MICE and note the comments on audio with interest. Please see http://www.cs.ucl.ac.uk/mice/seminars/work.html for a summary of task we use in the management of the MICE International Seminars. Gordon Joly Phone +44 171 380 7934 FAX +44 171 387 1397 Email: G.Joly@cs.ucl.ac.uk http://www.cs.ucl.ac.uk/~gjoly/ Comp Sci, University College, London, Gower Street, LONDON WC1E 6BT From rem-conf-request@es.net Mon Aug 22 17:34:45 1994 Received: from SPEECH1.CS.CMU.EDU by osi-west.es.net via ESnet SMTP service id <26187-0@osi-west.es.net>; Mon, 22 Aug 1994 14:34:24 +0000 Received: by SPEECH1.CS.CMU.EDU id aa14891; 22 Aug 94 17:34:05 EDT Date: Mon, 22 Aug 94 17:24:17 EDT From: Ricky.Houghton@SPEECH1.CS.CMU.EDU To: rem-conf@ES.NET Subject: wb and source code Hello, We have a few touch screens that we would like to use with wb. However, the mouse emulation tools provided with the touch screen isn't adequate for drawing. Some problem with the way the left mouse button is implemented. I'd like to modify the source to use the touch screen directly, is it possible to get access to the source for this purpose? It seems others may want to add a graphics tablet since they are now so inexpensive. Thanks, Ricky.Houghton@cs.cmu.edu From rem-conf-request@es.net Tue Aug 23 10:09:43 1994 Received: from bgate.lut.ac.uk by osi-west.es.net via ESnet SMTP service id <29882-0@osi-west.es.net>; Tue, 23 Aug 1994 07:09:01 +0000 Received: by suna.lut.ac.uk (4.1/SMI-4.1) id AA28437; Tue, 23 Aug 94 15:07:52 BST Date: Tue, 23 Aug 1994 14:53:19 +0100 (BST) From: "Jon P. Knight" Sender: "Jon P. Knight" Reply-To: "Jon P. Knight" Subject: Possible British Association multicast To: rem-conf@es.net Cc: Martin Hamilton , Ben Anderson Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi all, We're looking at multicasting a few sessions from the British Association Annual Festival of Science which is being held at Loughborough from 5th-9th September 1994. Initially at least we're only planning on multicasting some of the Computing talks which will be held on Tuesday 6th September from 09:00-12:30 BST (08:00-11:30 GMT). This will involve a single audio stream, a video stream of the presenter and most probably a wb session for slides and feedback from the MBONE community. We hope to go for a worldwide multicast transmission. We'll put out a small programme introducing the talks nearer the date (once the speakers have given their permission to be multicast!) but we thought we'd best put out feelers now to see if we're going to be stepping on anyones toes. If there are clashes we'd be happy to restrict ourselves to Europe or the UK. Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Research Student in High Performance Networking and Distributed Systems in the Department of _Computer_Studies_ at Loughborough University. * It's not how big your share is, its how much you share that's important * From rem-conf-request@es.net Tue Aug 23 14:18:18 1994 Received: from apple.com by osi-west.es.net via ESnet SMTP service id <01894-0@osi-west.es.net>; Tue, 23 Aug 1994 11:17:44 +0000 Received: by apple.com (5.61/8-Oct-1993-eef) id AA18189; Tue, 23 Aug 94 11:17:39 -0700 for rem-conf@es.net Date: Tue, 23 Aug 94 11:17:39 -0700 From: Mark Green Message-Id: <9408231817.AA18189@apple.com> To: rem-conf@es.net Subject: Unsubscribe From rem-conf-request@es.net Tue Aug 23 15:22:53 1994 Received: from sbcs.sunysb.edu by osi-west.es.net via ESnet SMTP service id <02641-0@osi-west.es.net>; Tue, 23 Aug 1994 12:22:27 +0000 Message-Id: <199408231920.AA24301@cs.sunysb.edu> Received: from sbpub5.csdept (sbpub5.cs.sunysb.edu) by cs.sunysb.edu; Tue, 23 Aug 1994 15:20:37 -0400 Subject: un-subscribe To: rem-conf@es.net Date: Tue, 23 Aug 1994 15:20:56 -0400 (EDT) From: Cheng-mean Liu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 16 Unsubscribe! From rem-conf-request@es.net Tue Aug 23 18:24:31 1994 Received: from tadpole.Tadpole.COM by osi-west.es.net via ESnet SMTP service id <03993-0@osi-west.es.net>; Tue, 23 Aug 1994 15:23:51 +0000 Received: from chiba (chiba.Tadpole.COM) by tadpole (4.1/SMI-4.1-jim) id AA02204; Tue, 23 Aug 94 17:23:41 CDT Received: by chiba (5.x/SPARCbook_POP1.3) id AA00692; Tue, 23 Aug 1994 17:23:55 -0500 Date: Tue, 23 Aug 1994 17:23:55 -0500 From: jim@Tadpole.COM Message-Id: <9408232223.AA00692@chiba> To: kamk@entropy.wpd.sgi.com Subject: Re: Announce Cc: rem-conf@es.net Interesting. I'm out here on-tour with Lollapalooza. We've considered multicasting a few of the shows, but I though it a bit specious use of the mbone. Jim From rem-conf-request@es.net Wed Aug 24 01:03:39 1994 Received: from cleostratus.rutgers.edu by osi-west.es.net via ESnet SMTP service id <05651-0@osi-west.es.net>; Tue, 23 Aug 1994 22:03:12 +0000 Received: by cleostratus.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06233; Wed, 24 Aug 94 01:03:09 EDT Date: Wed, 24 Aug 94 1:03:08 EDT From: David Paul Zimmerman To: rem-conf@es.net Subject: Re: Plans for MBONE at Interop'Sept 94 Message-Id: >Does anyone know what plans there are for MBONE at >Interop in Atlanta. Will there be a feed/tunnel? >Who must one coordinate with to create nv/vat sessions? >General plans? Mike, I'm the NOCteam member coordinating the MBone activities for the Atlanta Networld+Interop show. Our plans are pretty fluid at this point. I've got two SPARCstation 10/512s to use as video sources, with SunVideo cards in them. Empirical evidence seems to be that each will be able to do 10-15fps at 500-750Kbps in CellB format, so any plans we might have don't include high-bandwidth stuff. We'll probably have camcorders attached to them, with various other standalone camcorders scattered around the show, so that we'll be able to multicast live or recorded shots of interesting places and events. I expect to have various tunnels to the outside through a number of Internet service providers. My current intentions are to leak a ~96Kbps video stream to the outside during the show construction and operation period, roughly late September 6th through September 16th-ish... hopefully I can keep the subject matter interesting. At this point, I'm planning to keep it within the States. If there are vendors that wish to use multicasting during the show, they should definately talk to me, since I'll be rate limiting our tunnels to a maximum of about 192Kbps. I note that Jon Knight is looking at multicasting a few sessions from the British Association Annual Festival of Science on September 6th, and Matt Crawford is going to be multicasting the annual Fermilab Industrial Affiliates meeting on September 8th and 9th. It would seem that we could all coexist in some fashion. dp From rem-conf-request@es.net Wed Aug 24 04:45:23 1994 Received: from lust.mrrl.lut.ac.uk by osi-west.es.net via ESnet SMTP service id <06985-0@osi-west.es.net>; Wed, 24 Aug 1994 01:44:52 +0000 Received: (martin@localhost) by lust.mrrl.lut.ac.uk (8.6.9/8.6.9) id JAA11576; Wed, 24 Aug 1994 09:44:29 +0100 From: Martin Hamilton Message-Id: <199408240844.JAA11576@lust.mrrl.lut.ac.uk> Subject: Re: Plans for MBONE at Interop'Sept 94 To: dpz@cleostratus.rutgers.edu (David Paul Zimmerman) Date: Wed, 24 Aug 1994 09:44:29 +0100 (BST) Cc: rem-conf@es.net, J.P.Knight@lut.ac.uk (Jon Knight) In-Reply-To: from "David Paul Zimmerman" at Aug 24, 94 01:03:08 am X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 443 | I note that Jon Knight is looking at multicasting a few sessions from the | British Association Annual Festival of Science on September 6th, and Matt | Crawford is going to be multicasting the annual Fermilab Industrial Affiliates | meeting on September 8th and 9th. It would seem that we could all coexist in | some fashion. The British Association sessions would be from 9am BST (UTC+1) until around midday, 12.30 at the latest Martin From rem-conf-request@es.net Wed Aug 24 05:18:31 1994 Received: from hp4at.eunet.co.at by osi-west.es.net via ESnet SMTP service id <07441-0@osi-west.es.net>; Wed, 24 Aug 1994 02:17:55 +0000 Received: from rcsun1.aaf.alcatel.at by hp4at.eunet.co.at with SMTP id AA17141 (5.65c8/hp4at for ); Wed, 24 Aug 1994 11:17:09 +0200 Received: from rcsw64 by rcsun1.aaf.alcatel.at (4.1/SMI-4.1/RC-%I%/main) id AA00315; Wed, 24 Aug 94 11:14:57 +0200 Date: Wed, 24 Aug 94 11:14:57 +0200 From: lan_leop@aaf.alcatel.at (Helmut Leopold) Message-Id: <9408240914.AA00315@rcsun1.aaf.alcatel.at> To: rem-conf@es.net Subject: Cost237 Workshop - Advance Program Dear Colleague, Please find enclosed the program of the COST237 workshop on "Multimedia Transport and Teleservices" to be held in Vienna, November 13-14, 1994. Apologies for any inconvenience caused by multiple receipt of this message, or if you are not interested on this subject. However, it would be very helpful, if you could forward this announcement to anyone who might be interested on this subject. Thank you very much for your cooperation, with best regards, Helmut Leopold (local organiser of the COST 237 Workshop) ============================================================================== Helmut LEOPOLD Alcatel Austria AG tel: +431 29 121 / 184 Ruthnergasse 1-7 fax: +431 29 21 452 A-1210 VIENNA, AUSTRIA e-mail: H.Leopold@aaf.alcatel.at ============================================================================== International COST 237 Workshop on MULTIMEDIA TRANSPORT AND TELESERVICES ADVANCE PROGRAM November 13th-15th, 1994 Vienna Marriott Hotel, Parkring 12 a, A-1010 Vienna, Austria ================================================================= Program Chairman David Hutchison Lancaster University, UK (Chair) Program Committee Jon Crowcroft UCL, UK Andre Danthine U. of Liege, Belgium Michel Diaz LAAS/CNRS, France Christophe Diot INRIA, France Domenico Ferrari U. of California, USA Serge Fdida U. of Paris, France Gary Herman Bellcore, USA Andrew Lister Queensland U., Australia Craig Partridge BBN, USA Joe Pasquale UCSD, USA Steve Pink SICS, Sweden Bernhard Plattner ETH Zurich, Switzerland R. Popescu-Zeletin GMD-Fokus, Germany Otto Spaniol Aachen U., Germany Jean-Bernard Stefani CNET, Paris, France Ralf Steinmetz IBM ENC, Germany Harmen van As IBM Zurich Research, Switzerland Giorgio Ventre U. of Napoli, Italy STEERING COMMITTEE Andre Danthine U. of Liege, Belgium (Chair) Christophe Diot INRIA, France David Hutchison Lancaster University, UK Svend Jager JYDSK, Denmark Helmut Leopold Alcatel, Austria Vassili Loumos NTUA, Greece Andonis Galetsas CEC, Brussels R. Popescu-Zeletin GMD-Fokus, Germany Melanie Pralong Swiss Telecom, Switzerland Sandor Stefler PKI, Hungary Giorgio Ventre U. of Napoli, Italy ORGANISING COMMITTEE Helmut Leopold Alcatel, Austria (Chair) Geoff Coulson Lancaster U., UK Gabriela Wuerth Alcatel, Austria Franz Edler Alcatel, Austria Eike Wolf Alcatel, Austria Gerhard Weiss Comms. Services, Austria ================================================================= Foreword Although many distributed multimedia applications now exist as pilot projects on local networks, these prototypes have yet to be translated into realistic applications running over large scale heterogeneous high-speed networks. To help bring about this important transition, a number of initiatives such as the COST 237 Multimedia Telecommunications Services project in Europe and the Multimedia Communications Forum in the US have recently been established. These groups identify a lack of generic system support as the primary technological factor holding back the deployment of realistic, large scale, distributed multimedia applications. There are two basic technologies required to make feasible such support: an appropriate transport service for communications needs, and a suitable set of generic multimedia teleservices to provide a framework for application development. It is now accepted that significant enhancements to existing transport services are needed to adequately support large scale distributed multimedia applications. In particular, the transport service must be extended to support quality of service configurability and multicast/ multipeer connectivity, and must be supported by a variety of high-speed network architectures. The area of multimedia teleservices is equally crucial. Generic high level services, such as multimedia enhanced email, conferencing frameworks and shared application frameworks, are necessary to ease the evolution from present day pilot applications to commercial, inter-operable, products. The workshop will address both of these technological areas with particular attention paid to the integration of the two. The emphasis of the workshop will be on service and architectural aspects of distributed multimedia application support from the transport layer upwards. In total, 46 papers were received from 14 countries. Following the review procedure, the program committee selected 18 papers to be presented at the workshop, and 6 papers to be presented at a poster/demo session to be held at the workshop. Two well known invited speakers will complete the workshop program. This workshop is organised by the CEC COST 237 Multimedia Telecommunications Services Project and hosted by Alcatel Austria AG. It is particularly pleasing to be able to hold this first COST 237 Workshop in Vienna, a communications and cultural centre in Europe for so many centuries and the capital of the most recent country to agree to join the European Union. Vienna was the residence of the Habsburg Dynasty and is still a modern metropolis at the heart of Europe. It is one of the three centres of the United Nations and one of the most sought-after conference venues anywhere in the world. Looking forward to meeting you at the COST237 workshop'94 in Vienna. David Hutchison, Lancaster University, Conference Chairman ==================================================================== Workshop Preliminary Program ======================== Sunday November 13, 1994 ======================== 20:00-22:00 Get-together party ======================== Monday November 14, 1994 ======================== 8:00-18:00 Welcome Desk, Registration 9:00 - 10:15 Opening Session Chairperson: David Hutchison, University of Lancaster (UK) Welcome Keynote Address: Dir. Roland Hueber, Commission of the European Union, DG XIII/B: Advanced Communication Technologies and Services, Brussels (B) 10:15 - 10:45 Break 10:45 - 12:15 Session A: Teleservices: Multimedia Mail, Archiving and Retrieving Chairperson: Radu Popescu-Zeletin, GMD-Fokus, (D) Towards a Complete Multimedia Mail: Use of MHEG in Standard Messaging Systems, B. Kervella, Universite Paris, Laboratoire MASI (F) A Mail-Based Teleservice Architecture for Archiving and Retrieving Dynamically Composable Multimedia Documents, H. Thimm, K. Rohr, GMD-IPSI and GMD-Fokus (D) The Global Store Server - A Multimedia Teleservice Component, C. Blum, L. Neumann, Fraunhofer Institut (D) 12:15 - 13:45 Lunch 13:45 - 14:45 Invited speaker Chairperson: Andre Danthine, Universite de Liege (B) 14:45 - 15:45 Session B - Part 1: Teleservice Support Chairperson: Geoff Coulson, University of Lancaster (UK) >From Broadband Network Services to a Distributed Multimedia Support-Environment, H. Leopold, K. Frimpong-Ansah, N. Singer, Alcatel Austria (A) Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism, S. Shenker, A. Weinrib, XEROX (USA) 15:45 - 16:15 Break 16:15 - 17:15 Session B - Part 2: Teleservice Support Chairperson: Geoff Coulson, University of Lancaster (UK) Computational Components for Real-Time Cooperation on Multimedia Objects, C. Loge, V. Gay, Universite Paris, Laboratoire MASI (F) A Binding Architecture for Multimedia Networks, A. Lazar, S. Bhonsle, Columbia University (USA) 20:00 - 23:00 Workshop Dinner ========================= Tuesday November 15, 1994 ========================= 8:30-17:30 Registration 08:30 - 10:00 Session C: Quality of Service and Synchronization Chairperson: Andre Danthine, Universite de Liege (B) Implementation of an End-to-end Quality of Service Management Scheme, L. Fedaoui, A. Seneviratne, Universite Paris, Laboratoire MASI (F) A Formal Description Technique Supporting Expression of Quality of Service and Media Synchronisation, H. Bowman, L. Blair, G.S. Blair, A. Chetwynd, University of Kent (GB) On the Synchronization Mechanisms for Multimedia Integrated Services Networks, W. Yen, I. Akyildiz, Georgia Insitute of Technology (USA) 10:00 - 10:30 Break 10:30 - 12:00 Session D: Multipeer Communication Chairperson: Georgio Ventre, Universita di Napoli (I) Efficient Support for Multiparty Communication, C. Szyperski, G. Ventre, Universita di Napoli (I) QoS Negotiation for Multicast Communications, L. Mathy, O. Bonaveture, Universite de Liege (B) Support for High-Performance Multipoint Multimedia Services, G. Carle, J. Schiller, Universitaet Karlsruhe (D) 12:00 - 13:30 Lunch 13:30 - 15:00 Session E: Broadband Network Transport Issues Chairperson: Serge Fdida, Universite Paris (F) Providing Support for Data Transfer in a New Networking Environment, R. Schatzmayr, R. Popescu-Zeletin, TU Berlin (D) Congestion Avoidence Control for Video over IP Networks, T. Sakatani, NTT (J) Networks Layer Scaling: Congestion Control in Multimedia Communication with Heterogeneous Networks and Receivers, H. Wittig, J. Winckler, IBM ENC (D) 15:00 - 15:30 Break 15:30 - 16:30 Session F: Variable Bit Rate Video Coding Transport Chairperson: Christophe Diot, INRIA (F) Resource Requirements for VBR MPEG Traffic in Interactive Applications, M. Hamdi, P. Rolin, Y. Duboc, M. Ferry, ENST de Bretagne (F) Transmission of MPEG2 Multimedia Applications over ATM Networks, M. Andrade, A. Alves, INESC (P) 16:30 - 16:45 Closing Session 16:45 End of the Workshop =============================================================================== Poster Session: The Poster Session will complement the technical presentations. It is a good opportunity to get first hand information on practical experiences with the state-of-the-art in distributed multimedia communication. Protocols for Multimedia Conferencing. An Introduction to the ITU-T T.120 series - "The Multilayer Protocol", W.J. Clark, BT Labs (GB) A Platform for Multimedia Telecooperation Bridging Endsystem Heterogeneity, G. Dermler, T. Gutekunst, E. Ostrowski, N. Pires, T. Schmidt, M. Weber, H. Wolf, Universitaet Stuttgart (D) The CIO Multimedia Communication Platform, A. Rozek, P. Christ, Universitaet Stuttgart (D) A Scheme for Multimedia and Hypermedia Synchronisation, N. Pronios, T. Bozios, Intracom SA (GR) Integration of Existing Applications into a Conference System, D. Riexinger, K. Werner, IBM ENC (D) Broadband Multimedia and collaboration Tools, M. Blanco, R. Montero, F. Almerico, G. Venuti, P. Cremonese, TELEFONICA I+D(P) ============================================================================== Workshop Location Vienna Marriott Hotel Parkring 12a A-1010 Vienna/Austria Tel.: +43 1 515 180 Fax.: +43 1 515 186 722 The Marriott Hotel is situated near the Metro station Stadtpark (U4). Workshop Information Dates Get-together party : Sunday 13th November 1994 at 20:00 - 22:00 Workshop : Monday 14th November to Tuesday 15 November 1994 Opening session : Monday 14th November 1994 at 9:00 Workshop dinner : Monday 14th November 1994 at 20:00 - 23:00 Closing session : Tuesday 15th November 1994 at 16:30 Language The official language of the Workshop is English. Registration fees Registration & payment received : by 14 October 94 after 14 October 94 Workshop fees 2900 ATS (+20% VAT) 3400 ATS (+20% VAT) Reduced Workshop Fees* 2500 ATS (+20% VAT) 2900 ATS (+20% VAT) Under excise regulation of the Austrian Goverment delegates from all countries are required to pay V.A.T. on any course taking place in Austria. The reduced workshop fee* is granted to Program Committee members, authors of submitted papers, reviewers, and Steering Committee members. The workshop fee includes: the access to all sessions, the final program, one copy of the participant's edition of the proceedings, the lunches for the two days, morning and afternoon refreshments during the breaks, access to the get-together party and the workshop dinner. Name badge An admission name badge will be delivered to each fully registered participant. Literature A participant's edition of the proceedings will be made available at the Welcome Desk of the Workshop. The final Proceedings will be published as a book or as a special issue of a well known journal. =============================================================================== Registration Procedure Please fill the enclosed registration form as soon as possible and send it together with the payment to Moser+Blechinger PR Singerstrasse 12, A-1010 Vienna, Austria Phone: ++43 1 513 97 43 Fax: ++43 1 513 91 16 76 E-mail: H.Leopold@aaf.alcatel.at Registration is only effective when payment is received. Please note, that due to space restrictions the number of participants will be limited to 100. Payment Payment of fees will be accepted in Austrian Schilling only. The fees can be paid : - by sending a certified cheque in Austrian Schilling made payable to Moser+Blechinger PR) - by bank transfer to Vorarlberger Landes und Hypothekenbank, account number : 20112809121 of Moser+Blechinger GmbH, Bank-Code 58000, A-1010 Vienna, Singerstr. 12 (be sure to clearly state your name and address). - by credit card (Eurocard - Visa - Amex - MC - Diners); when paying by credit card the billing address must be provided to ensure admission. Bank transfer and cheques should be made net of all bank charges and commissions. Confirmation Moser+Blechinger PR, upon receipt of the registration form and of the payment, will send to the participant a confirmation and an invoice for his/her accounting department. On his arrival the participant is requested to present himself at the Welcome Desk to get his/her workshop documents (badge, proceedings, lunch ticket, etc.). If you have not received an acknowledgement before the workshop, please call us to make sure we have registered your booking. Due to variable postal conditions your booking may have been held up on its way to us or your acknowledgement may have been delayed in a similar reason. Cancellation Refunds of 50% will be made if a written request is received by October 14, 1994. No refunds will be made for cancellations received after this date. Accommodation A number of rooms with special price conditions have been blocked for participants. Reservation will be handled on a first-come first-served basis. Early reservation is advisable. The hotel reservation must be received before November 11, 1994 otherwise the reservation can not be guaranteed. The accommodation form must be returned as soon as possible with the payment to Moser+Blechinger. If not paid by credit cards, a deposit equal to the first night have to be included with the payment. The price per night per person, taxes and service included: single room/double room Hotel Marriott (Category hotel 5*) 1800/1800 ATS (excluding breakfast; buffet breakfast/p.p: 200.- ATS) Hotel Rathauspark (Category hotel 4*) 900/1200 ATS (including breakfast) The Workshop itself will be located at the Marriott hotel. The hotel Rathaus is within easy walking distance. Get-together party Participants and their partners are invited to a get-together party on Sunday 13 November from 20:00 to 22:00 at the BelEtage in the highly acclaimed Haas Haus. The Haas Haus is in the heart of Vienna close to St. Stephan's Cathedral. It is within easy walking distance of both Hotels. Workshop Dinner Vienna is not only celebrated as one of the centers of European history, culture, music and architecture, it is also famous for its "heuriger" - a form of wine tavern unique to Vienna which has evolved due to the close proximity of vineyards to the city. The new wine served at the heuriger is also known as heuriger; after Martinmas (11th of November) the heuriger wine becomes an "alter" (old) wine. The majority of the Viennese vineyards are on the slopes of Kahlenberg and Nussberg located to the north of Vienna. The better known wine-growing districts such as Grinzing, Sievering and Neustift can also be found in this area. Our Workshop Dinner will celebrate the heuriger and will be held in the romantic and rural district of Neustift. The transportation from the Hotels will be arranged by the Workshop Organisers. Please confirm your attendance at the dinner along with your Workshop registration. Cost 237 Workshop Administrative Office For further detailed information regarding the registration and room reservation please contact George Blechinger Moser+Blechinger PR Singerstrasse 12, A-1010 Vienna, Austria phone: ++43 1 513 97 43 fax: ++43 1 513 91 16 76 =============================================================================== REGISTRATION AND ACCOMMODATION FORM First name : .................................................................. Family Name : ................................................................. Title (Mr/Mrs/Ms/Dr/Prof): .................................................... Company : ..................................................................... Address : ..................................................................... ............................................................................... City : ................................... Zip code : ......................... State : .......................... Country : .................................. Fax : ............................ Phone : ................................... E-mail : ........................... --------------------------------------------------------------------------- Please reserve : Single room Double room : (please circle selected items) single room/double room Hotel Marriott ***** 1800/1800 ATS (excl. breakfast) Hotel Rathauspark **** 900/1200 ATS (incl. breakfast) All room rates include one night and taxes. ARRIVAL DATE : ............................................................... DEPARTURE DATE : ............................................................. Sharing person : ............................................................. To guarantee your room, a one night deposit is required if not paid by credit card. I will attend the get-together party: yes/no I will attend the workshop dinner: yes/no --------------------------------------------------------------------------- Cost 237 Workshop fees: by 14 October 94 after 14 October 94 Workshop fees 2900 ATS (+580 VAT) = 3480 ATS 3400 ATS (+680 VAT) = 4080 ATS Reduced Workshop Fees* 2500 ATS (+580 VAT) = 3000 ATS 2900 ATS (+580 VAT) = 3480 ATS Additional Lunch Tickets (360 ATS each) ..... x 360 ATS = ........ ATS Additional Dinner Tickets (350 ATS each) ..... x 350 ATS = ........ ATS Room Deposit 900/1200/1800 ATS (Please CIRCLE selected items) TOTAL AMOUNT : ...............................ATS Date/Signature : .............................................................. --------------------------------------------------------------------------- Payment of the fees and deposit by (please circle selected mode of payment) CREDIT CARD: Eurocard VISA MC AMEX Other name : ........................................................................ number : ........................................... exp. date : .............. signature : ................................................................... BANK TRANSFER to Vorarlberger Landes und Hypothekenbank, account number : 20112809121 of Moser+Blechinger GmbH, Bank-Code 58000, A-1010 Vienna, Singerstr. 12 (be sure to clearly state your name and address). CHEQUE in Austrian Schilling drawn on an Austrian Bank made payable to Moser+Blechinger PR Please Note : Cancellation received after October 14, 1994 will not be refunded. Payment by cheque and bank transfer must be net of any charge. Please complete this form and return it with your payment to Moser+Blechinger PR Singerstrasse 12, A-1010 Vienna, Austria Phone: ++43 1 513 97 43 Fax: ++43 1 513 91 16 76 E-mail: H.Leopold@aaf.alcatel.at From rem-conf-request@es.net Wed Aug 24 09:38:37 1994 Received: from jon.bellcore.com by osi-west.es.net via ESnet SMTP service id <08896-0@osi-west.es.net>; Wed, 24 Aug 1994 06:38:14 +0000 Received: (zia@localhost) by jon.bellcore.com (8.6.9/8.6.4) id JAA12141; Wed, 24 Aug 1994 09:38:05 -0400 Date: Wed, 24 Aug 1994 09:38:05 -0400 From: zia@jon.bellcore.com (Ashar Zia) Message-Id: <199408241338.JAA12141@jon.bellcore.com> To: frederic@parc.xerox.com, rem-conf@es.net Subject: NV using Parallax XVideo card... Cc: zia@jon.bellcore.com I got the nv3.3beta release binary for SunOS4.1.3 from: parcftp.parc.xerox.com /pub/net-research When I run it (in unicast mode) at about 300-400 kbps with minimum motion, I can get 15+ fps with my XEROX PARC card in my Sparc10. In the same machine I have a PARALLAX XVideo card too. Using the same BW gives me hardly 2-4 fps with the parallax card (again with almost no motion). One more observation that might be relative is that each time the parallax card grabs a new frame, the screen flickers, becoming black for a very short period of time, though visible to the human eye. Now running a samply frame grabber for parallax will give about 25 frames per second, almost same quality as XEROX PARC. So can someone explain the poor quality of NV using the parallax card? I would certainly like to increase the frame rate for NV (using parallax) if its possible. Any suggestions? Thanks a lot. -Ashar From rem-conf-request@es.net Wed Aug 24 11:20:11 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <09457-0@osi-west.es.net>; Wed, 24 Aug 1994 08:19:48 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14573(5)>; Wed, 24 Aug 1994 08:19:26 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16145>; Wed, 24 Aug 1994 08:19:21 -0700 To: zia@jon.bellcore.com (Ashar Zia) cc: rem-conf@es.net Subject: Re: NV using Parallax XVideo card... In-reply-to: Your message of "Wed, 24 Aug 94 06:38:05 PDT." <199408241338.JAA12141@jon.bellcore.com> Date: Wed, 24 Aug 1994 08:19:18 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <94Aug24.081921pdt.16145@ecco.parc.xerox.com> In message <199408241338.JAA12141@jon.bellcore.com> you write: > I got the nv3.3beta release binary for SunOS4.1.3 from: > > parcftp.parc.xerox.com /pub/net-research > > When I run it (in unicast mode) at about 300-400 kbps with minimum motion, > I can get 15+ fps with my XEROX PARC card in my Sparc10. In the same machine > I have a PARALLAX XVideo card too. Using the same BW gives me hardly 2-4 fps > with the parallax card (again with almost no motion). One more observation > that might be relative is that each time the parallax card grabs a new frame, > the screen flickers, becoming black for a very short period of time, though > visible to the human eye. > The Parallax card is extremely good at getting video from a local source onto the screen, but extremely bad at getting that same video into the main memory of the computer, which is where nv needs it. The PARC video card, on the other hand, is designed to get video data into main memory, and it actually takes additional effort to get it up on the screen. So, for nv, the PARC video card wins hands down. Another problem is that the Parallax card seems to generate a video signal which bounces up and down slightly when sending small or medium size. It seems to be a bug in their handling of interlacing. The result is that nv falsely detects motion, and this can cause it to send at the full bandwidth you have set (and a fairly low frame rate) even when there's no real motion. So far, I have been unable to find a workaround for this problem. About the only way to get acceptable performance with the Parallax is to get the version of their card with the JPEG compression on it, and send that. They do have a means of efficiently reading & writing JPEG compressed video data. Unfortunately, that can be expensive to decompress in software on other systems. Also, even if the receiver has a Parallax card, it doesn't handle multiple simultaneous receive streams all that well without losing frame rate. Still, this was the way Parallax intended you to do network video with their cards, and at some point nv might support that. I'm just waiting for a software JPEG implementation that allows at least some (low frame rate) decoding on machines without any special hardware. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Aug 24 12:03:02 1994 Received: from faui45.informatik.uni-erlangen.de by osi-west.es.net via ESnet SMTP service id <09696-0@osi-west.es.net>; Wed, 24 Aug 1994 08:59:36 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA06082 (5.65c-6/7.3w-FAU); Wed, 24 Aug 1994 17:57:46 +0200 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA26113 (5.65c-6/7.3m-FAU); Wed, 24 Aug 1994 17:57:44 +0200 From: Toerless Eckert Message-Id: <199408241557.AA26113@faui43.informatik.uni-erlangen.de> Subject: Re: NV using Parallax XVideo card... To: Ashar Zia Date: Wed, 24 Aug 94 17:57:26 MET DST Cc: frederic@parc.xerox.com, rem-conf@es.net, zia@jon.bellcore.com In-Reply-To: <199408241338.JAA12141@jon.bellcore.com>; from "Ashar Zia" at Aug 24, 94 9:38 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] > I got the nv3.3beta release binary for SunOS4.1.3 from: > > parcftp.parc.xerox.com /pub/net-research > > When I run it (in unicast mode) at about 300-400 kbps with minimum motion, > I can get 15+ fps with my XEROX PARC card in my Sparc10. In the same machine > I have a PARALLAX XVideo card too. Using the same BW gives me hardly 2-4 fps > with the parallax card (again with almost no motion). One more observation that > might be relative is that each time the parallax card grabs a new frame, the > screen flickers, becoming black for a very short period of time, though visible > to the human eye. > > Now running a samply frame grabber for parallax will give about 25 frames per > second, almost same quality as XEROX PARC. So can someone explain the poor > quality of NV using the parallax card? I would certainly like to increase the > frame rate for NV (using parallax) if its possible. Any suggestions? The parallax line of video cards contains a chip that can do JPEG image compression and decompression in hardware. The frame grabbers delivered with the parallax software utilize this chip. NV does not, because it does not as of now support JPEG compression or decompression. Guessing your next question: If would be possible to decompress up to 16 frames/sec of JPEG encoded CIF images with a ss10/40, but there is no free software to do this. The freely available jpeg library is only about 1/4 speed of this, so it does not currently make sense to support JPEG in NV because it could only usefully be utilized by people with parallax cards, whereas with cellB (from Sun) tyou too have only hardware compression delivering up to 20 frames, but also software decompression for free that also delivers up to 15 frames. best regards Toerless P.S.: If anyone knows a good optimized JPEG encoder decoder software for free, pleae tell me, i am really looking for such a thing. From rem-conf-request@es.net Wed Aug 24 12:15:54 1994 Received: from amdext.amd.com by osi-west.es.net via ESnet SMTP service id <09858-0@osi-west.es.net>; Wed, 24 Aug 1994 09:15:12 +0000 Received: from amdint.amd.com by amdext.amd.com with SMTP id AA20205 (5.67a/IDA-1.5+AMD for ); Wed, 24 Aug 1994 09:14:51 -0700 Received: from diamond.amd.com by amdint.amd.com with SMTP id AA20670 (5.67a/IDA-1.5+AMD for ); Wed, 24 Aug 1994 09:14:50 -0700 Received: by diamond.amd.com (4.1/AMDSN-1.20) id AA20079; Wed, 24 Aug 94 09:09:37 PDT From: Andrew.Mills@amd.com (Andy Mills) Message-Id: <9408241609.AA20079@diamond.amd.com> Subject: MBONE for Windows - Any Support? To: rem-conf@es.net Date: Wed, 24 Aug 1994 09:09:36 -0700 (PDT) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 319 Hi, I asked a few months ago about MBONE support within the PC environment, and at the time there was very little activity reported. Has there been any developments in this area are yet? I am certainly interested to hear from anyone that has support in the Windows environment. Many thanks, Andy Mills AMD (UK) Ltd From rem-conf-request@es.net Wed Aug 24 13:15:43 1994 Received: from inet-gw-2.pa.dec.com by osi-west.es.net via ESnet SMTP service id <10393-0@osi-west.es.net>; Wed, 24 Aug 1994 10:15:05 +0000 Received: from bigpink.pa.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA17658; Wed, 24 Aug 94 10:00:31 -0700 Received: by bigpink.pa.dec.com; id AA06480; Wed, 24 Aug 1994 10:00:18 -0700 Message-Id: <9408241700.AA06480@bigpink.pa.dec.com> To: Ron Frederick Cc: zia@jon.bellcore.com (Ashar Zia), rem-conf@es.net Subject: Re: NV using Parallax XVideo card... In-Reply-To: Message of Wed, 24 Aug 1994 08:19:18 PDT from Ron Frederick <94Aug24.081921pdt.16145@ecco.parc.xerox.com> Date: Wed, 24 Aug 94 10:00:17 -0700 From: berc@src.dec.com X-Mts: smtp Another problem is that the Parallax card seems to generate a video signal which bounces up and down slightly when sending small or medium size. It seems to be a bug in their handling of interlacing. The result is that nv falsely detects motion, and this can cause it to send at the full bandwidth you have set (and a fairly low frame rate) even when there's no real motion. So far, I have been unable to find a workaround for this problem. The key is to be able to specifiy if you want only even fields, odd fields, or the next field that comes along. Several cards have this problem (the DEC J300 does the right thing, of course :-). The one scan-line bouncing is annoying even when watching JPEGed streams. lance From rem-conf-request@es.net Wed Aug 24 13:38:32 1994 Received: from everest.cclabs.missouri.edu by osi-west.es.net via ESnet SMTP service id <10563-0@osi-west.es.net>; Wed, 24 Aug 1994 10:37:56 +0000 Received: from indy44.gclab.missouri.edu (indy44.gclab.missouri.edu [128.206.48.208]) by everest.cclabs.missouri.edu (8.6.9/8.6.6) with SMTP id MAA08037 for ; Wed, 24 Aug 1994 12:38:11 -0500 Date: Wed, 24 Aug 1994 12:38:00 -0500 (CDT) From: Paul 'Shag' Walmsley Subject: Re: MBONE for Windows - Any Support? To: rem-conf@es.net In-Reply-To: <9408241609.AA20079@diamond.amd.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 24 Aug 1994, Andy Mills wrote: > Hi, > > I asked a few months ago about MBONE support within the PC environment, and > at the time there was very little activity reported. I seem to recall that someone had built multicast support into the WATTCP TCP libraries for DOS about 6-8 months ago. - Paul "Shag" Walmsley "I am learning and evolving." From rem-conf-request@es.net Wed Aug 24 13:43:52 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <10620-0@osi-west.es.net>; Wed, 24 Aug 1994 10:43:02 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14404(1)>; Wed, 24 Aug 1994 10:41:26 PDT Received: from localhost by ecco.parc.xerox.com with SMTP id <16145>; Wed, 24 Aug 1994 10:41:14 -0700 To: berc@src.dec.com cc: zia@jon.bellcore.com (Ashar Zia), rem-conf@es.net Subject: Re: NV using Parallax XVideo card... In-reply-to: Your message of "Wed, 24 Aug 94 10:00:17 PDT." <9408241700.AA06480@bigpink.pa.dec.com> X-Mailer: exmh version 1.5gamma 8/15/94 Date: Wed, 24 Aug 1994 10:41:01 PDT Sender: Ron Frederick From: Ron Frederick Message-Id: <94Aug24.104114pdt.16145@ecco.parc.xerox.com> In message <9408241700.AA06480@bigpink.pa.dec.com> you write: > Another problem is that the Parallax card seems to generate a > video signal which bounces up and down slightly when sending > small or medium size. It seems to be a bug in their handling > of interlacing. The result is that nv falsely detects motion, > and this can cause it to send at the full bandwidth you have > set (and a fairly low frame rate) even when there's no real motion. > So far, I have been unable to find a workaround for this problem. > > The key is to be able to specifiy if you want only even fields, odd > fields, or the next field that comes along. Several cards have this > problem (the DEC J300 does the right thing, of course :-). The one > scan-line bouncing is annoying even when watching JPEGed streams. > If the card dealt in fields, I'd agree with you. However, it claims to deal in frames. In the 640x480 case, it works correctly (except for the unavoidable visible field motion caused by reinterlacing). That image is rock solid. It is only when you ask it to scale down that you have a problem. However, even at the smaller sizes, the interface presented is that things are already reinterlaced, so it should either always reinterlace to a solid picture and then scale down, or automatically switch to even/odd field mode when it gets small enough. It does neither, and that seems to be the problem. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Aug 24 14:53:59 1994 Received: from overdrive3.ccrl.nj.nec.com by osi-west.es.net via ESnet SMTP service id <11001-0@osi-west.es.net>; Wed, 24 Aug 1994 11:52:15 +0000 Received: by overdrive.ccrl.nj.nec.com (4.1/YDL1.9-920708.13) id AA19652(overdrive.ccrl.nj.nec.com); Wed, 24 Aug 94 14:52:04 EDT Received: by europa.ccrl.nj.nec.com (4.1/YDL1.9-920708.13) id AA08400(europa.ccrl.nj.nec.com); Wed, 24 Aug 94 14:47:35 EDT From: bansal@ccrl.nj.nec.com (Vivek Bansal) Received: by depot (4.1/CNC-Client) id AA17395; Wed, 24 Aug 94 14:52:01 EDT Date: Wed, 24 Aug 94 14:52:01 EDT Message-Id: <9408241852.AA17395@depot> To: rem-conf@es.net Subject: Broadcast announcement Arrangements are been made for a live broadcast over the Internet MBONE of the plenary, technical sessions, and invited talk at the ITS'94 to be held in Rio de Janeiro, Brazil, on August 22-25, 1994. Also the "International Workshop on Network Management" on Aug 26 will be multicasted. The software requirements to view the broadcast include the Internet tools: nv, vat, and sd (More information on the MBONE is available from venera.isi.edu:mbone/faq.txt). Please find enclosed below the final program for the part of ITS'94 which is going to be broadcast. Parties involved in the whole setup are: Comsat World Systems, Embratel, MFS, NEC, SURAnet, Federal University of Rio de Janeiro (UFRJ), FAPERJ/RedeRio and SUN Microsystems. ****************************************************************************** SBT/IEEE 1994 International Telecommunications Symposium - ITS'94 ITS'94 Program for Multicast Experiment ****************************************************************************** Venue: Rio Palace Hotel, Rio de Janeiro, Brazil Tuesday, Aug.23 9:30-10:15 Opening Session 10:30-11:30 Plenary Session: The Future of Telecommunications, John S. Mayo, President, AT&T Bell Laboratories (U.S.A.) 14:00-15:00 Invited Talk: Perspectives on Integrated Services, High Speed and Congestion, Robert G. Gallager (U.S.A.) 15:20-17:30 Technical Session 2: Routing in Multiservice Network Paper 2.1 - Performance Analysis of Broadcast Algorithms Based on Flooding P.A.Hosein (Trinidad and Tobago) Paper 2.2 - Optimal Routing in Shortest-Path Networks, M.A.Rodrigues (Brazil) and K.G.Ramakrishnan (U.S.A.) Paper 2.3 - Topology Reconfiguration of Multiservice ATM Networks, C.M.D.Pazos (U.S.A.), J.A.S.Monteiro (Brazil) and M.Gerla (U.S.A.) Paper 2.4 - Evaluation of Multicast Routing Algorithms for Multimedia Streams, C.A.Noronha-Jr. and F.A.Tobagi (U.S.A.) Wednesday, Aug.24 8:30-9:50 Panel Session: Multimedia Applications and Networking S.B.Weinstein, Chairman (U.S.A.) J. Derby (U.S.A.) J. Martins (Portugal) K. Watanabe (U.S.A.) M. Decina (Italy) 10:05-11:30 Panel Session: Design Issues in High Speed Multimedia Networks D. Towsley, Chairman (U.S.A.) R.G.Gallager (U.S.A.) F.A.Tobagi (U.S.A.) N. Maxemchuck (U.S.A.) 11:30-12:30 Plenary Session: The Coming Ubiquity of Digital Wireless Access Intelligent Network, Irwin M. Jacobs, Chairman and CEO Qualcomm, Inc., (U.S.A.) 14:00-15:00 Invited Talk: Will ATM be the end of MAN, Nicholas Maxemchuck (U.S.A.) 15:20-17:30 Technical Session 10: Wireless Personal Communications: Protocols, Architectures and Routing Paper 10.1 - Mobile IP, C.E.Perkins (U.S.A.) and A.M.Myles (Australia) Paper 10.2 - Selecting Router in Ad-Hoc Wireless Networks, A.K.Parekh (U.S.A.) Paper 10.3 - A MEO Constellation Network Architecture for a Global Personal Communication System, M.Dinis (Portugal), J.Neves (Portugal), R.Tafazoli (U.K.) and B.Evans (U.K.) Thursday, Aug.25 8:30-9:50 Technical Session 13: Performance Analysis of ATM Networks Paper 13.1 - Performance Analysis of a Non-Preemptive Priority Scheme for ATM Multimedia Services, M.Abbas (Malaysia) Paper 13.2 - Some Numerical Results on Finite-Buffer Markovian Multiserver Polling Systems, M.Ajmone-Marsan, S.Donatelli, F.Neri and G.Fantini (Italy) Paper 13.3 - On the Computation of End-to-End Delay in Feed-Forward ATM Networks, N.L.S.Fonseca and J.A.Silvester (U.S.A.) 10:05-11:30 Technical Session 17: ATM Congestion Control in Integrated Services Networks Paper 17.1 - Congestion Control with Double Threshold in ATM Networks, S.G.Jong and Y.O.Chu, K.Hee (Korea) Paper 17.2 - On the Efficiency of Policing Mechanisms for ATM Networks, J.A.Frazao-Jr. and J.A.S.Monteiro (U.S.A.) 11:30-12:30 Plenary Session: Global Telecommunication Standardization in a Changing World - A Challenge for the International Telecommunication Union (ITU), Theodor Irmer, Director, ITU Telecomm. Standards Bureau (ITU-T) 14:00-17:30 Technical Session 22: Emerging Network Operation Technologies and Applications Paper 22.1 - Performance Evaluation of Interconnected Networks, F.Georges (France) Paper 22.2 - Functional Architecture for Customer Service Operation, S.Uchikawa, Y.Fujida and K.Murata (Japan) Paper 22.3 - Recife-a Management Tool for the Greater Paris Telecommunications Network, M.Benzidi, L.Burity and G.Pichon (France) Paper 22.4 - Subnetwork Management and TMN in a Evolving Network, H.Dysart and S.Aidarous (Canada) Paper 22.5 - Design and Implementation of a Telecommunication Management Network: System and Information Viewpoints, N.Agoulmine, J.N. de Souza (France) and G.Pavlou (U.K.) Paper 22.6 - Integrated Service Mnagement within Heterogeneous Environment P.Ray (Australia) Friday, August 26 9:00-17:30 International Workshop on Network Management PROGRAM ----------------------------------------------------------------------- 9:00-9:15 OPENING REMARKS Thomas Plevyak, Workshop Co-Chair Raul Colcher, Workshop Co-Chair 9:15-10:15 INTRODUCTION Francisco Albuquerque, Embratel 10:30-11:15 STANDARDS David Sidor, BNR 11:15-12:00 INFORMATION MODELING * Lakshmi Raman, Bellcore 1:30-2:45 APPLICATIONS & CHALLENGES Carey Anderson and Jim Goett, Bellcore 3:00-3:45 IMPLEMENTATION EXPERIENCES Stefan Brock, DBP Telekom 3:45-4:15 PLATFORMS/INTEGRATION ISSUES Joseph Lias, Premisys Communications 4:15-5:15 PANEL DISCUSSION Brasil Bruno Vianna, CPqD Mexico Arturo Alaluf, Telmex USA Carey Anderson Germany Stefan Brock 5:15-5:30 CLOSING REMARKS Salah Aidarous, CNOM Roberto de Marca, ITS'94 General Chairman ------------------------------------------------------------------------ ----- End Included Message ----- ----- End Included Message ----- From rem-conf-request@es.net Wed Aug 24 16:16:08 1994 Received: from is.rice.edu by osi-west.es.net via ESnet SMTP service id <11475-0@osi-west.es.net>; Wed, 24 Aug 1994 13:15:13 +0000 Received: by is.rice.edu (AA20391); Wed, 24 Aug 94 15:15:10 CDT From: darren@is.rice.edu (Darren Keith Bolding) Message-Id: <9408242015.AA20391@is.rice.edu> Subject: sd confused? To: rem-conf@es.net Date: Wed, 24 Aug 1994 15:15:10 -0500 (CDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1327 Hello, I've been having some dificulties with the session director and I hope this is the appropriate place to ask about them. I've got the Multicast patches applied to our Sparc 10 (SunOs 4.1.3_U1), and I can get mrouted to run happily on it; I can even verify the tunnel is up with the nice tools provided at www.it.kth.se. I can even get sd to run, start vat and nv and start new sessions. I was even able to verify that my packets were being broadcast. Unfortunately, sd refuses to show me any sessions other than the ones that were started locally, it also will only show myself as in the active group. I verified that this behavior occured on other servers running mrouted (with two universities). The solution seemed to be to turn one of our bsdi machines into a reflector (since sd is not available for bsdi :( ) and run the clients on the Sun. Well, the BSDI kernel claims its multicast, the ifconfig'd interface claims its multicast, and mrouted claims its not. Unfortunately, in this case, mrouted wins. Anyone have any ideas? Any clue when sd source code will be available (if it already runs on many bsd derived things, it shouldn't be THAT hard to port to bsdi....)? Thanks for the help (and time) Machines of interest: tattoo.sccsi.com, tempeh.sesqui.net, bsdi.sccsi.com -- Darren darren@sccsi.com From rem-conf-request@es.net Wed Aug 24 16:23:39 1994 Received: from oaunx1.ctd.ornl.gov by osi-west.es.net via ESnet SMTP service id <11609-0@osi-west.es.net>; Wed, 24 Aug 1994 13:22:31 +0000 Received: from OCU3.PRIV.ORNL.GOV by oaunx1.ctd.ornl.gov (8.6.9/Ultrix3.0-C) id QAA23528; Wed, 24 Aug 1994 16:22:15 -0400 Received: from conversion.ornl.gov by OCU3.PRIV.ORNL.GOV (PMDF V4.3-9 #5221) id <01HGAL61SECW9ARZ1P@OCU3.PRIV.ORNL.GOV>; Wed, 24 Aug 1994 16:22:03 -0400 (EDT) Received: from ocu-2mr.mr.ornl.gov by OCU3.PRIV.ORNL.GOV (PMDF V4.3-9 #5221) id <01HGAL26EK009AS3BZ@OCU3.PRIV.ORNL.GOV>; Wed, 24 Aug 1994 16:21:54 -0400 (EDT) Received: with PMDF-MR; Wed, 24 Aug 1994 16:19:22 EDT MR-Received: by mta OCU2; Relayed; Wed, 24 Aug 1994 16:19:22 -0400 Alternate-recipient: prohibited Disclose-recipients: prohibited Date: Wed, 24 Aug 1994 16:17:00 -0400 (EDT) From: Lawrence P Macintyre Subject: Re(2): NV using Parallax XVideo card... To: Toerless.Eckert@Informatik.Uni-Erlangen.de Cc: zia@jon.bellcore.com, frederic@parc.xerox.com, rem-conf@es.net, zia@jon.bellcore.com Message-id: <01HGAL4XHCPK9AS3BZ@ocu-2mr.mr.ornl.gov> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Posting-date: Wed, 24 Aug 1994 16:18:00 -0400 (EDT) Importance: normal Priority: normal X400-MTS-identifier: [;22916142804991/7406096@OCU] A1-type: MAIL Hop-count: 1 Toerless: The jv300 card from DEC can do jpeg compression and decompression as well. I get 30 frames/sec (about 850 kbs) on a 3000/600. Lawrence ~ From rem-conf-request@es.net Wed Aug 24 17:11:10 1994 Received: from faui45.informatik.uni-erlangen.de by osi-west.es.net via ESnet SMTP service id <11935-0@osi-west.es.net>; Wed, 24 Aug 1994 14:10:39 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA19320 (5.65c-6/7.3w-FAU); Wed, 24 Aug 1994 23:06:35 +0200 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA05290 (5.65c-6/7.3m-FAU); Wed, 24 Aug 1994 23:06:32 +0200 From: Toerless Eckert Message-Id: <199408242106.AA05290@faui43.informatik.uni-erlangen.de> Subject: Re: NV using Parallax XVideo card... To: Ron Frederick Date: Wed, 24 Aug 94 23:06:18 MET DST Cc: berc@src.dec.com, zia@jon.bellcore.com, rem-conf@es.net In-Reply-To: <94Aug24.104114pdt.16145@ecco.parc.xerox.com>; from "Ron Frederick" at Aug 24, 94 10:41 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] > If the card dealt in fields, I'd agree with you. However, it claims to deal > in frames. In the 640x480 case, it works correctly (except for the unavoidable > visible field motion caused by reinterlacing). That image is rock solid. It is > only when you ask it to scale down that you have a problem. However, even at > the smaller sizes, the interface presented is that things are already > reinterlaced, so it should either always reinterlace to a solid picture and > then scale down, or automatically switch to even/odd field mode when it gets > small enough. It does neither, and that seems to be the problem. And another 2cent of parallax bashing from me. Even when using full resolution video (which is of course 768*576, and not 640 * 480, if you are living in a civilised country *grin*), you still have the problem that compression or grabbing of uncompressed video is in no way synchronised to the video source. This means that you always end up with half the picture contents of say frame N and half from frame N+1. This gets worse the more you are near to 25 frames/sec. It is really embarrasing to know that there is software who knows how to grab frames correctly synchronised, but there is no way to interface to that software in a sensible way (i'm talking about the RTV toolkit). Best regards Toerless Eckert From rem-conf-request@es.net Wed Aug 24 19:10:39 1994 Received: from inet2.tek.com by osi-west.es.net via ESnet SMTP service id <12762-0@osi-west.es.net>; Wed, 24 Aug 1994 16:10:11 +0000 Received: from tektronix.tek.com by inet2.tek.com id ; Wed, 24 Aug 1994 16:10:06 -0700 Received: from dtl.labs.tek.com (crl.labs.tek.com) by tektronix.TEK.COM (4.1/8.2) id AA15046; Wed, 24 Aug 94 16:09:59 PDT Received: from icebox.LABS.TEK.COM (icebox.TEK) by dtl.labs.tek.com (4.1/8.0) id AA17405; Wed, 24 Aug 94 16:09:32 PDT Received: from icebox (localhost) by icebox.LABS.TEK.COM (5.0/SMI-SVR4) id AA00373; Wed, 24 Aug 1994 16:09:24 +0800 Message-Id: <9408242309.AA00373@icebox.LABS.TEK.COM> To: darren@is.rice.edu Cc: rem-conf@es.net Subject: Re: sd confused? In-Reply-To: Your message of Wed, 24 Aug 1994 13:15:10 -0700. <9408242015.AA20391@is.rice.edu> Date: Wed, 24 Aug 1994 16:09:24 -0700 From: Ted Brunner Content-Length: 907 > I've got the Multicast patches applied to our Sparc 10 (SunOs > 4.1.3_U1), and I can get mrouted to run happily on it; I can even > verify the tunnel is up with the nice tools provided at www.it.kth.se. > I can even get sd to run, start vat and nv and start new sessions. I > was even able to verify that my packets were being broadcast. > Unfortunately, sd refuses to show me any sessions other than the ones > that were started locally, it also will only show myself as in the > active group. I ran into a similar problem, and it turned out that I had not applied the 3.1beta patch (also available at eg. parcftp.xerox.com) Once I did, the sessions showed up on sd on the mrouted machine. Hope that helps... > -- Darren > darren@sccsi.com Ted Brunner Communication Systems Research Lab Tektronix MS 50-370 ted.brunner@tek.com 14150 SW Karl Braun 503.627.1317 Beaverton OR 97005 From rem-conf-request@es.net Thu Aug 25 03:11:36 1994 Received: from leonis.nus.sg by osi-west.es.net via ESnet SMTP service id <15436-0@osi-west.es.net>; Thu, 25 Aug 1994 00:11:02 +0000 Received: (from mcbtantc@localhost) by leonis.nus.sg (8.6.9/8.6.9/CNS-3.5) id PAA19427; Thu, 25 Aug 1994 15:10:57 +0800 Date: Thu, 25 Aug 1994 15:10:56 +0800 (SST) From: TAN THIAN CHIA RICHA Subject: unsubscribe To: rem-conf@es.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII i'll like to unsubscribe. thanks. From rem-conf-request@es.net Thu Aug 25 03:19:54 1994 Received: from dxmint.cern.ch by osi-west.es.net via ESnet SMTP service id <15480-0@osi-west.es.net>; Thu, 25 Aug 1994 00:19:31 +0000 Received: from VXCERN.DECnet MAIL11D_V3 by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA12913; Thu, 25 Aug 1994 09:19:02 +0200 Date: Thu, 25 Aug 1994 09:19:01 +0200 Message-Id: <9408250719.AA12913@dxmint.cern.ch> From: julian@vxcern.cern.ch (Julian J. Bunn, CN Division, CERN, Geneva) X-Vms-To: mint::rem-conf@es.net X-Vms-Cc: JULIAN Subject: Frame Grabbing X-Mail11-Ostype: VAX/VMS Apparently-To: I asked the following question in the IBM PC video hardware group on Usenet, with no replies. As there seems to be quite a bit of frame grabber expertise with you nv experts (Ron, Toersten), I thought I'd ask here. Sorry if it's off the beaten track! I'm developing an application that uses the MediaVision Pro Movie Spectrum card as a grabber. The SDK for this card poorly documents how to program the various card registers. The application that will work in the higher available resolutions (320x240, 640x280). Initialising the card, and capturing frames with a suitable ISR is no problem. However, there is a piece of code in the SDK which I don't understand. There are several registers on the Spectrum card that need to be set correctly so that the card grabs at the desired resolution. One register takes the width (e.g. 320), one takes the height (e.g. 240), and then there are four other registers which are supposed to take horizontal and vertical DECIMATION DENOMINATOR and NUMERATOR, whatever these may be! E.g. for PAL, one calls PMSSetHorzDeci(wWidth,768); PMSSetVertDeci(wHeight,270); with wWidth=320,wHeight=240. The HorzDeci routine then calculates a "decimation numerator" of 8, and a "decimation denominator" of 19 (well, 147 actually, as it is ORed with 0x80), and writes each of these to the appropriate registers. VertDeci calculates 8,9 for the numerator/denominator. What are these numbers for ? Where do 768 and 270 for PAL come from? (They are 640 and 240 for NTSC.) Can anyone shed any light on this? (There is also a Field Decimation register, which is programmed with value 1 ...) For info, the routines mentioned above yield the following values for the different supported Spectrum resolutions: HorzDeci with 80 768 yields Num,Den 2 19 | 0x80 VertDeci with 60 270 yields Num,Den 2 9 HorzDeci with 160 768 yields Num,Den 4 19 VertDeci with 120 270 yields Num,Den 4 9 HorzDeci with 320 768 yields Num,Den 8 19 VertDeci with 240 270 yields Num,Den 8 9 HorzDeci with 640 768 yields Num,Den 16 19 VertDeci with 480 270 yields Num,Den 16 9 From rem-conf-request@es.net Thu Aug 25 06:10:49 1994 Received: from nic.cerf.net by osi-west.es.net via ESnet SMTP service id <16778-0@osi-west.es.net>; Thu, 25 Aug 1994 03:10:24 +0000 Received: from calvin.vigra.com (dbrown.extern.ucsd.edu [137.110.12.105]) by nic.cerf.net (8.6.8/8.6.6) with SMTP id DAA09332 for ; Thu, 25 Aug 1994 03:10:14 -0700 Received: from susie.vigra.com by calvin.vigra.com (4.1/Vigra-8.11-extern) id AA00779; Wed, 24 Aug 94 22:35:03 PDT Received: by susie.vigra.com (4.1/Vigra-8.11-smtp) id AA08789; Wed, 24 Aug 94 22:35:03 PDT Date: Wed, 24 Aug 94 22:35:03 PDT From: Steve Haehnichen Message-Id: <9408250535.AA08789@susie.vigra.com> To: rem-conf@es.net Subject: Commercial release of PARC Video. Wish lists? Reply-To: steve@vigra.com Hello! I work for Vigra in San Diego, where we are gearing up to announce the VigraPix SBus video digitizer. Since we licensed the design from Xerox, it is completely identical to the PARC Video card, except that it's got our name on it, and it should be shipping in mass quanities Real Soon Now. (I'm guessing two months.) I've been given the honor of refining and documenting the existing PARC driver/libraries for public consumption (Hi Ron!). I'm pretty pleased with the structure and interface of the existing code, so I'm not inclined to change a whole lot more than the function names to start with. Since it seems the PARC card is fairly popular among subscribers to this list, I'm hoping to get some input on what features I should plan on adding to the VigraPix software, both before the first release, and in future updates. If you have made any significant changes to the software, or wish there was some feature you didn't have to hack in yourself, I would love to hear from you. Also, if you have written software for the PARC Video card, I'm curious to know what aspects you found difficult, so that they can be carefully documented. I'm also trying to get a batch of several VigraPix cards to hand out to up-and-coming video hackers for "undirected research". If you have a cool piece of video software (free or commercial) and would like to support the PARC Video/VigraPix hardware, please drop me a note. If you wrote any neat freely-distributable programs that use PARC Video, and wouldn't mind seeing it distributed with the VigraPix "contrib/" software, please let me know. If you have questions on sales stuff, like price or availability, you have to ask , since I try to stay out of that. I'm , and I'll probably be parenting the VigraPix project for a while. Thanks! -Steve -- Steve Haehnichen Vigra, Inc. San Diego, CA steve@vigra.com (619) 597-7080 x116 Fax: (619) 597-7094 From rem-conf-request@es.net Fri Aug 26 07:01:11 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <28366-0@osi-west.es.net>; Fri, 26 Aug 1994 04:00:43 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <08363-0@ceres.fokus.gmd.de>; Fri, 26 Aug 1994 13:02:23 +0200 Subject: MPEG-1/2 boards To: rem-conf@es.net Date: Fri, 26 Aug 1994 13:02:23 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de Since video codecs were mentioned: Any information about MPEG-1 and particularly MPEG-2 boards for either PC or workstation would be much appreciated. The MPEG FAQs that I found didn't have much. Thanks. -- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 219 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin hphone: +49 117 432 4741 From rem-conf-request@es.net Fri Aug 26 09:50:25 1994 Received: from bstgw1.bst.bls.com by osi-west.es.net via ESnet SMTP service id <29040-0@osi-west.es.net>; Fri, 26 Aug 1994 06:49:59 +0000 Received: from bstgw.bst.bls.com by bstgw1.bst.bls.com with smtp (Smail3.1.28.1 #11) id m0qe1iA-0000bkC; Fri, 26 Aug 94 09:52 EDT Received: from beavis by bstgw.bst.bls.com (4.1/SMI-4.1) id AA27821; Fri, 26 Aug 94 09:51:14 EDT Received: by beavis (5.0/SMI-SVR4) id AA17699; Fri, 26 Aug 1994 08:49:39 +0600 Date: Fri, 26 Aug 1994 08:49:39 +0600 From: mike.richards@bst.bls.com (Mike Richards) Message-Id: <9408261349.AA17699@beavis> To: rem-conf@es.net Subject: Re: mrouted 2.0 problems on Sunos 4.1.3U1B X-Sun-Charset: US-ASCII Content-Length: 1072 > From casner@ISI.EDU Thu Aug 11 12:04 CDT 1994 > Date: Thu 11 Aug 94 10:03:16 PDT > From: Stephen Casner > Subject: Re: mrouted 2.0 problems on Sunos 4.1.3U1B > To: mike.richards@bst.bls.com > Mail-System-Version: > > That one is simple: assuming you installed the 4.1.3U1B multicast > release from parcftp, you must use the pruning version of mrouted > (version 3.1 or 3.2) (e.g. from the 3.1beta file) and not the > released non-pruning version (2.0, 2.1 or 2.2). > -- Steve Where does one obtain a 3.1 or 3.2 version of mrouted? The 3.1U1B beta multicast distribution contains the mrouted 2.0 code. ***************************************************************** * Mike Richards (205-977-5193) ATG - BellSouth Telecommunications * E8B1, 3535 Colonnade Pkwy, Birmingham, Al. 35243 * Fax: 205-977-1351 * The views expressed are those of the author and may * not reflect the views of BellSouth Telecommunications Inc. ***************************************************************** From rem-conf-request@es.net Fri Aug 26 11:05:02 1994 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <29434-0@osi-west.es.net>; Fri, 26 Aug 1994 08:04:27 +0000 Via: uk.ac.edinburgh.festival; Fri, 26 Aug 1994 16:02:53 +0100 Received: from cancer.ucs.ed.ac.uk by festival.ed.ac.uk id aa07462; 26 Aug 94 16:02 BST Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Fri, 26 Aug 94 16:02:41 BST Date: Fri, 26 Aug 94 16:02:41 BST Message-Id: <10639.9408261502@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: mrouted 2.0 problems on Sunos 4.1.3U1B To: Mike Richards In-Reply-To: Mike Richards's message of Fri, 26 Aug 1994 08:49:39 +0600 Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Cc: rem-conf@es.net > > Where does one obtain a 3.1 or 3.2 version of mrouted? The 3.1U1B > beta multicast distribution contains the mrouted 2.0 code. That is strange, because the version of the 3.1 distribution I have for 4.1.3 U1B is supplemental to the 3.1 multicast release ie. it does not contain mrouted at all. You will, find mrouted either in the 3.1 release on parcftp or you can pick it up from ftp://ftp.ucs.ed.ac.uk/pub/videoconference/mrouted/mrouted.3.2b.tar.Z Graeme From rem-conf-request@es.net Fri Aug 26 17:09:46 1994 Received: from noc.msc.edu by osi-west.es.net via ESnet SMTP service id <02125-0@osi-west.es.net>; Fri, 26 Aug 1994 14:09:22 +0000 Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA28760; Fri, 26 Aug 94 16:09:17 -0500 Received: from sparky.drad.umn.edu by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA13349; Fri, 26 Aug 94 16:09:15 -0500 Date: Fri, 26 Aug 94 16:04:41 CDT From: "Dr. R. E. Ritenour" Message-Id: <9408262104.AA10707@sparky.drad.umn.edu> Received: by sparky.drad.umn.edu; Fri, 26 Aug 94 16:04:41 CDT To: rem-conf@es.net Subject: unsubscribe Cc: ritenour@sparky.drad.umn.edu I would like to unsubscribe Thanks From rem-conf-request@es.net Fri Aug 26 21:55:16 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <04430-0@osi-west.es.net>; Fri, 26 Aug 1994 18:54:47 +0000 Received: from dude.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA17304; Fri, 26 Aug 94 18:56:49 PDT Received: by dude.cs.nps.navy.mil (940715.SGI.52/911001.SGI) for @taurus.cs.nps.navy.mil:rem-conf@es.net id AA09691; Fri, 26 Aug 94 18:56:48 -0700 Date: Fri, 26 Aug 1994 18:56:48 -0700 (PDT) From: Michael Macedonia Subject: OS Support for Mcast To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone know the status of multicast support in Chicago, NT, Mac OS or OS/2, or any other non-UNIX OS? I find it strange that these "modern" OS's do not advertise at least future support for mcast. Chicago and Warp (OS/2) will both come with TCP/IP. How do the developers expect to support teleconferencing and groupware apps without mcast? Is the reflector model the current paradigm? Thanks for any insight. Mike Macedonia | macedonia@cs.nps.navy.mil ------------------------------------------------------------ From rem-conf-request@es.net Sat Aug 27 14:00:40 1994 Received: from relay.acns.nwu.edu by osi-west.es.net via ESnet SMTP service id <08386-0@osi-west.es.net>; Sat, 27 Aug 1994 11:00:15 +0000 Received: from annie.astro.nwu.edu by relay.acns.nwu.edu with SMTP (1.37.109.11/16.2) id AA271070196; Sat, 27 Aug 1994 12:56:36 -0500 Received: by annie.astro.nwu.edu; (5.65/1.1.8.2/15Jul94-0806PM) id AA03361; Sat, 27 Aug 1994 13:00:06 -0500 From: Robert "A." Lentz Message-Id: <9408271800.AA03361@annie.astro.nwu.edu> Subject: Re: OS Support for Mcast To: macedoni@dude.cs.nps.navy.mil (Michael Macedonia) Date: Sat, 27 Aug 1994 13:00:06 -0500 (CDT) Cc: rem-conf@es.net In-Reply-To: from "Michael Macedonia" at Aug 26, 94 06:56:48 pm Reply-To: lentz@annie.astro.nwu.edu X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 908 > Does anyone know the status of multicast support in Chicago, NT, Mac > OS or OS/2, or any other non-UNIX OS? > > I find it strange that these "modern" OS's do not advertise at least > future support for mcast. Chicago and Warp (OS/2) will both come with > TCP/IP. How do the developers expect to support teleconferencing and > groupware apps without mcast? Is the reflector model the current paradigm? Well, actually Apple has told us that multicasting wil be in the upcoming Open Transport (the successor to MacTCP, for starters). The CU-SeeMe folks have said they will support MBONE once multicasting is available. This actually is not too bad because currently our routers on campus do not support multicasting anyhow. -Robert -- lentz@rossi.astro.nwu.edu http://www.astro.nwu.edu/lentz/plan.html "You have to push as hard as the age that pushes against you." -Flannery O'Connor From rem-conf-request@es.net Sat Aug 27 14:52:56 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <08576-0@osi-west.es.net>; Sat, 27 Aug 1994 11:52:29 +0000 Received: from dude.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA02765; Sat, 27 Aug 94 11:54:29 PDT Received: by dude.cs.nps.navy.mil (940715.SGI.52/911001.SGI) for @taurus.cs.nps.navy.mil:rem-conf@es.net id AA10966; Sat, 27 Aug 94 11:54:26 -0700 Date: Sat, 27 Aug 1994 11:54:26 -0700 (PDT) From: Michael Macedonia Subject: Re: OS Support for Mcast To: "Robert A. Lentz" Cc: rem-conf@es.net In-Reply-To: <9408271800.AA03361@annie.astro.nwu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 27 Aug 1994, Robert A. Lentz wrote: > Well, actually Apple has told us that multicasting wil be in the upcoming > Open Transport (the successor to MacTCP, for starters). > Robert, Who at Apple should I contact to find out more about Open Transport? Thanks, Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From rem-conf-request@es.net Sat Aug 27 18:14:46 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <09281-0@osi-west.es.net>; Sat, 27 Aug 1994 15:14:14 +0000 Received: from gravy1.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA05616; Sat, 27 Aug 94 15:16:16 PDT Received: by gravy1.cs.nps.navy.mil (931110.SGI/911001.SGI) for @taurus.cs.nps.navy.mil:rem-conf@es.net id AA04878; Sat, 27 Aug 94 15:16:15 -0700 Date: Sat, 27 Aug 1994 15:16:14 -0700 (PDT) From: Michael Macedonia Sender: Michael Macedonia Reply-To: Michael Macedonia Subject: Re: OS Support for Mcast To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Two items regarding Open Transport. Thanks to Charley Kline. ---------- Forwarded message ---------- Date: Sat, 27 Aug 1994 15:28:25 -0500 From: Charley Kline To: Michael Macedonia Subject: Re: OS Support for Mcast At 1:54p 8/27/94, Michael Macedonia wrote: >Who at Apple should I contact to find out more about Open Transport? Try Garry Hornbuckle (garryh@seeding.apple.com). /cvk ------------------------------------------------------------------ MacTCP 3.0!! I found this info at seeding.apple.com in the directory ess/pub/mactcp. Here is a quote from the file: =============================================================== A look at the future of MacTCP.... =============================================================== Apple is investing significantly in completely new TCP/IP stack technology. The new stack will be STREAMS based. The new stack will have an XTI interface, as well as a backward compatibility interface to the old MacTCP API, allowing existing well behaved application to run unmodified. The new stack will support many new features, like PPP, multicast, multi-homing, recursive DNR, dynamic timers and path MTU discovery; making it, in my opinion, one of the best stacks available on a PC. This new technology is available to developers in seedings now. For the most current information, refer to the "Open Transport" folder on this server. ---- Yotam -- Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From rem-conf-request@es.net Sat Aug 27 18:39:08 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <09417-0@osi-west.es.net>; Sat, 27 Aug 1994 15:38:36 +0000 Received: from gravy1.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA05901; Sat, 27 Aug 94 15:40:35 PDT Received: by gravy1.cs.nps.navy.mil (931110.SGI/911001.SGI) for @taurus.cs.nps.navy.mil:mbone@isi.edu id AA04929; Sat, 27 Aug 94 15:40:33 -0700 Date: Sat, 27 Aug 1994 15:40:32 -0700 (PDT) From: Michael Macedonia Subject: ISDN, PPP, and MBONE To: rem-conf@es.net Cc: mbone@isi.edu In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone know of someone using ISDN to support an MBONE connection? I would be particularly interested to know if anyone is using an SGI Indy or Sun (which have a ISDN port) with ISDN for MBONE use. Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From rem-conf-request@es.net Sun Aug 28 07:21:29 1994 Received: from sphere.csl.ntt.jp by osi-west.es.net via ESnet SMTP service id <13515-0@osi-west.es.net>; Sun, 28 Aug 1994 04:20:57 +0000 Received: by sphere.csl.ntt.jp (8.6.9/core*csl.mx8) with TCP; Sun, 28 Aug 1994 20:20:50 +0900 Message-Id: <199408281120.UAA20627@sphere.csl.ntt.jp> To: rem-conf@es.net, mbone@isi.edu Subject: Re: ISDN, PPP, and MBONE In-reply-to: Your message of "Sat, 27 Aug 1994 15:40:32 MST." Date: Sun, 28 Aug 1994 20:20:49 +0900 From: Hitoaki Sakamoto > Does anyone know of someone using ISDN to support an MBONE connection? > > I would be particularly interested to know if anyone is using an SGI > Indy or Sun (which have a ISDN port) with ISDN for MBONE use. I am using the MBONE with ISDN at home. I have a Sun IPX with ISDN S-bus board (from CSR, not SUN original). This board is very useful , because it can use 2 Bch(128Kbps). [ISDN 64kbps*2] |[Ethernet] The MBONE <--> NTT.JP <---------------->Sun IPX-->| (Tokyo,Japan) (Kawasaki) | | ----- Hitoaki Sakamoto (hitoaki@sphere.csl.ntt.jp) NTT Network Service Systems Labs. From rem-conf-request@es.net Sun Aug 28 18:41:45 1994 Received: from anu.anu.edu.au by osi-west.es.net via ESnet SMTP service id <15247-0@osi-west.es.net>; Sun, 28 Aug 1994 15:41:21 +0000 Received: from moggie (moggie.anu.edu.au) by anu.anu.edu.au (4.1/SMI-4.1) id AA04720; Mon, 29 Aug 94 08:41:16 EST Received: by moggie (5.0/SMI-SVR4) id AA01431; Mon, 29 Aug 1994 08:41:12 --1000 Date: Mon, 29 Aug 1994 08:41:12 --1000 From: sjm@moggie.anu.edu.au (Stephen Meatheringham) Message-Id: <9408282241.AA01431@moggie> To: rem-conf@es.net Subject: unsuscribe X-Sun-Charset: US-ASCII Content-Length: 64 please unsuscribe me from this mailing list. sjm@mso.anu.edu.au From rem-conf-request@es.net Sun Aug 28 22:01:24 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <16795-0@osi-west.es.net>; Sun, 28 Aug 1994 19:00:41 +0000 Received: from gravy1.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA06284; Sun, 28 Aug 94 19:02:41 PDT Received: by gravy1.cs.nps.navy.mil (931110.SGI/911001.SGI) for @taurus.cs.nps.navy.mil:rem-conf@es.net id AA01541; Sun, 28 Aug 94 19:02:48 -0700 Date: Sun, 28 Aug 1994 19:02:47 -0700 (PDT) From: Michael Macedonia Subject: Multicast and OSs To: rem-conf@es.net In-Reply-To: <199408281120.UAA20627@sphere.csl.ntt.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I find it interesting to note that no one seemed to know of any effort to put mcast support into the "advanced" OSs of IBM and Microsoft. Great to hear about future Mac efforts with Open Transport. It could be an interesting combination with ISDN and CU-SeeME. Could sell alot of ISDN lines for PACBELL. Question: why do SGI, Sun, Dec, and Apple and just about every router vendor go through the effort to support mcast and not IBM and Microsoft? Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ From rem-conf-request@es.net Mon Aug 29 00:10:38 1994 Received: from brolga.cc.uq.oz.au by osi-west.es.net via ESnet SMTP service id <17202-0@osi-west.es.net>; Sun, 28 Aug 1994 21:09:54 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Mon, 29 Aug 1994 14:09:17 +1000 To: Henning Schulzrinne Subject: Re: MPEG-1/2 boards cc: rem-conf@es.net, ccdvu@cc.uq.oz.au In-reply-to: Your message of "Fri, 26 Aug 1994 13:02:23 +0200." <9408281251.AA28745@wraith.internode.com.au> Date: Mon, 29 Aug 1994 14:09:13 +1000 From: David Vu Message-ID: <"brolga.cc.uq:224140:940829040920"@cc.uq.oz.au> I know the following MPEG I codecs for PC. I think they're still about 3-4 times the price of H.261 codecs. However, the MPEG I decoder card is fairly inexpensive, which is good for 1 codec-to-many-decoders type applications. OptiVision OptiVideo 1477 Drew Avenue Suite 102 Davis CA 95616 Tel 916-757-4850 FAX 916-756-1309 OptiBase MPEGLabPro 4006 Beltline Rd Suite 200 Dallas, Texas 75244 Tel 214-386-2040 FAX 214-386-2295 FutureTel PriveView 1092 E. Arques Ave Sunnyvale CA 94086 Tel 408-522-1400 FAX 408-522-1439 David Vu | Prentice Centre Internet: D.Vu@cc.uq.oz.au | The University of Queensland Phone: +61 7 365 3941 | Brisbane Q 4072 FAX: +61 7 365 4477 | Australia From rem-conf-request@es.net Mon Aug 29 06:24:02 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <19380-0@osi-west.es.net>; Mon, 29 Aug 1994 03:23:31 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <15691-0@ceres.fokus.gmd.de>; Mon, 29 Aug 1994 12:25:22 +0200 Subject: Sound card To: rem-conf@es.net Date: Mon, 29 Aug 1994 12:25:22 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de For a spanking new 586, we are trying to identify a sound card that: - works with NetBSD/FreeBSD/BSDI or Linux - is full duplex if possible - does not induce programmers to jump in front of commuter trains after trying to program them (i.e., have some usable programming documentation or a reputation for helpful manufacturers) We hope to be able to run vat and port NeVoT, among other uses. Thanks for any pointers. I'll add them to my emerging hardware list. -- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 219 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin hphone: +49 117 432 4741 From rem-conf-request@es.net Mon Aug 29 14:24:42 1994 Received: from stone.ucs.indiana.edu by osi-west.es.net via ESnet SMTP service id <23236-0@osi-west.es.net>; Mon, 29 Aug 1994 11:24:20 +0000 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA02916; Mon, 29 Aug 94 13:24:10 EST Date: Mon, 29 Aug 1994 13:24:09 -0500 (EST) From: Cell-Relay Gopher Janitor Subject: Re: Multicast and OSs To: Michael Macedonia Cc: rem-conf@es.net In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Question: why do SGI, Sun, Dec, and Apple and just about every > router vendor go through the effort to support mcast and not IBM and > Microsoft? Microsoft doesn't have to because, well, they're Microsoft. Actually, in this week's Network World "CyberSpeak" section the question was posed "Is Microsoft Corp.'s networking strategy too Windows-centric." All four respondents answered "yes" and I agree. Given that one of the next "great marketing frontiers" is the Internet, I'd suggest that they open their eyes and start implementing some of the protocols that, by concensus, will make this net work. Apple is starting to realize that there is a lot of potential in making their OS Internet friendly. IBM has been playing around with "Internety" things like ST-II (probably RTP/RSVP by now, but don't quote me) for a while but, IMHO, suffers from an inability to get things out of the Lab and into the Market. regards, allen From rem-conf-request@es.net Mon Aug 29 14:35:18 1994 Received: from jacks.gsfc.nasa.gov by osi-west.es.net via ESnet SMTP service id <23312-0@osi-west.es.net>; Mon, 29 Aug 1994 11:34:54 +0000 Received: by jacks.gsfc.nasa.gov (4.1/1.35) id AA10853; Mon, 29 Aug 94 14:39:34 EDT Date: Mon, 29 Aug 1994 14:39:33 -0400 (EDT) From: "Shahed I. Husain" Subject: subscribe To: rem-conf@es.net Cc: "Shahed I. Husain" Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe From REM-CONF-request@es.net Mon Aug 29 14:52:14 1994 Received: from alink-gw.apple.com by osi-west.es.net via ESnet SMTP service id <23487-0@osi-west.es.net>; Mon, 29 Aug 1994 11:51:25 +0000 Received: by alink-gw.apple.com (921113.SGI.UNSUPPORTED_PROTOTYPE/7-Oct-1993-eef) id AA17256; Mon, 29 Aug 94 11:50:54 -0700 for REM-CONF@ES.NET Date: 29 Aug 94 18:36 GMT From: HORNBUCKLE1@AppleLink.Apple.COM (Hornbuckle, Garry) Subject: MacOS Support for Mcast To: LENTZ@ANNIE.ASTRO.NWU.EDU, MACEDONI@DUDE.CS.NPS.NAVY.MIL, REM-CONF@ES.NET Cc: HORNBUCKLE1@AppleLink.Apple.COM (Hornbuckle, Garry) Message-Id: <778186253.8694785@AppleLink.Apple.COM> TWIMC, Apple's next major release of TCP/IP protocols for the MacOS includes support for IP Multicast. This product, "Open Transport/TCP", is scheduled to ship in first calendar quarter 1995. Alpha seeding gets underway this month; for information on access to pre-release software, send email to 'SeedMe@seeding.apple.com'. Documentation on the Open Transport Communications Architecture and the Open Transport protocol stacks is available by anonymous ftp from 'seeding.apple.com'. Best Regards, Garry Hornbuckle Product Line Manager Communications Products & Technologies AppleSoft OS Platforms Group Apple Computer, Inc. From rem-conf-request@es.net Mon Aug 29 17:32:32 1994 Received: from grimaldi.rutgers.edu by osi-west.es.net via ESnet SMTP service id <25301-0@osi-west.es.net>; Mon, 29 Aug 1994 14:31:25 +0000 Received: (from jim@localhost) by grimaldi.rutgers.edu (8.6.8.1+bestmx/8.6.6) id RAA06358; Mon, 29 Aug 1994 17:31:06 -0400 Date: Mon, 29 Aug 94 17:31:03 EDT From: Jim Martin To: Cell-Relay Gopher Janitor Cc: Michael Macedonia , rem-conf@es.net, jallard@microsoft.com Subject: Re: Multicast and OSs In-Reply-To: Your message of Mon, 29 Aug 1994 13:24:09 -0500 (EST) Message-ID: > > Question: why do SGI, Sun, Dec, and Apple and just about every > > router vendor go through the effort to support mcast and not IBM and > > Microsoft? > > Microsoft doesn't have to because, well, they're Microsoft. Actually, you're wrong. Microsoft will be supporting IP Multicast in Chicago, Daytona, and a forthcoming TCP/IP release for WFW 3.11. In fact, I've got a Daytona beta on my machine right now that I'm using for development of my PC based multicast tools. I've been really impressed with the way Microsoft seems to be aproaching TCP/IP in their new line of products. For example, when you're doing the net configuration, it'll happily go off and use DHCP. Now, I know it's not a big deal to code that in, but it does indicate that they're current with the protocol development coming out of the IETF, something I would not have expected, say, a year ago. Also, they seem to be at least reasonably aware of some of the real concerns with using IP services today. When you go to install their FTP server component, it warns you that using FTP involves typing a password in cleartext over the net, and if someone has access to the physical path, it might be snooped. Again, not a big deal to put in, but it shows someone is thinking. Jim P.S. I'm CCing James Allard, Program Manager of TCP/IP Technologies at Microsoft, in case he has anything else to add, or to correct me if I blew any of the details. Jim Martin Internet: jim@noc.rutgers.edu Network Services UUCP: {backbone}!rutgers!jim Rutgers University Phone: (908) 445-3719 From rem-conf-request@es.net Tue Aug 30 02:35:05 1994 Received: from dxmint.cern.ch by osi-west.es.net via ESnet SMTP service id <29143-0@osi-west.es.net>; Mon, 29 Aug 1994 23:34:34 +0000 Received: from VXCERN.DECnet MAIL11D_V3 by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24710; Tue, 30 Aug 1994 08:34:09 +0200 Date: Tue, 30 Aug 1994 08:34:08 +0200 Message-Id: <9408300634.AA24710@dxmint.cern.ch> From: julian@vxcern.cern.ch (Julian J. Bunn, CN Division, CERN, Geneva) X-Vms-To: mint::rem-conf@es.net X-Vms-Cc: JULIAN Subject: Microsoft and IP X-Mail11-Ostype: VAX/VMS Apparently-To: I'd like to echo Jim Martin's enthusiasm over Microsofts newfound IP awareness. If you've been used to fiddly IP installations on non-Unix boxes (e.g. VMS) then configuring IP in Windows/NT is a delight. I've heard a rumour that we'll even have an NFS Client bundled with Daytona, when it finally ships. Julian From rem-conf-request@es.net Tue Aug 30 20:40:23 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <06552-0@osi-west.es.net>; Tue, 30 Aug 1994 17:39:58 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-18) id ; Tue, 30 Aug 1994 17:39:52 -0700 Posted-Date: Tue 30 Aug 94 17:38:45 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 30 Aug 94 17:38:46 PDT Date: Tue 30 Aug 94 17:38:45 PDT From: Stephen Casner Subject: Minutes of AVT Toronto meeting (long) To: rem-conf@es.net Message-Id: <778293525.0.CASNER@XFR.ISI.EDU> Mail-System-Version: To those interesting in the Audio/Video Transport working group and the Real-time Transport Protocol (RTP): Enclosed below are the minutes of the AVT meeting at IETF in Toronto, July 27 & 28. On ftp.isi.edu in the directory mbone/avt/toronto-july94 you may find the following related files: minutes.94jul These minutes transcript.94jul Rough transcript of the discussion casner-rtp.ps.Z Slides of presentation on RTP and open issues huitema-h261.ps.gz Slides of presentation on H.261 over RTP fenner-jpeg.ps.Z Slides of presentation on JPEG over RTP Reported by Steve Casner/USC-ISI Minutes of Audio/Video Transport Working Group (AVT) 1. Overview In the first AVT session, rough consensus was given to submit the revised Real-time Transport Protocol specification for Area Directorate review and IESG Last Call as a Proposed Standard. This revision, denoted RTP version 2, incorporates changes requested by the first AD review in November 1993. It is the refinement by Steve Casner, Ron Frederick, Van Jacobson and Henning Schulzrinne of the rough protocol changes presented and discussed at the March 1994 IETF meeting in Seattle. An overview of the revised RTP was presented and discussed in the first AVT session and part of the second. The group concurred with the choices made on all of the previously open issues. It was agreed that the hooks provided for protocol extensions were adequate for planned experiments with mechanisms not included in the current protocol. More details on the issues discussed are included in the sections below. There are a few explanatory paragraphs and example algorithm appendices that need to be completed in the draft RTP specification, then it will be submitted. This should be done well before the next IETF meeting. Later in the second AVT session, presentations were given on specifications for the encapsulation in RTP of three different video encodings: Christian Huitema presented the H.261 encoding, Bill Fenner presented the JPEG encoding, and Don Hoffman presented the MPEG encoding. These specifications will also be completed as Internet Drafts and then submitted as Proposed Standards. On-line versions of the slides are available via FTP from ftp.isi.edu in directory mbone/avt/toronto-july94/. 2. Changes in RTP version 2 In a message posted to the working group mailing list (rem-conf) in June, a list of the protocol changes from version 1 to version 2 was given. The changes may be summarized as follows: - Carry the control and data traffic on separate ports - New control packet format, including mandatory reception reports - No options in data packet; CSRC count in fixed header - Locally unique 16-bit SSRC ID is now a 32-bit random global ID, always present (header now 12 octets) - Media-specific timestamps (vs. fixed 65536 Hz rate) - Remove the application-level multiplexing of the Channel ID and move it to an encapsulation for the cases where it's needed - Application-specific sync marker bit - Encryption covers the whole packet; authentication omitted - With the change to global and potentially encrypted SSRC IDs, translators can't do unicast reverse path control packets - Beginning of sync unit (BOS) option was eliminated; encodings that need the info should include it in their own headers - Length fields changed to count 32-bit words not including the length word to eliminate some validity checks at receiver Comments were sought both on the changes that were proposed in a finished form as well as on some open issues that were undecided. Some comments were received, but no major objections. Although not all the open issues were discussed, the authors completed the spec and posted it as Internet Draft draft-ietf-avt-rtp-05.txt before this meeting. During this meeting, each of the open issues was discussed as outlined in the sections below, and the email comments were addressed. 2.1 Provision for testing Bolot/Turletti/Wakeman scheme RTPv2 includes a receiver-initiated congestion reporting scheme based on multicast reception reports. An alternative scheme is the one based on sender-initiated polling described in a paper by Bolot, Turletti and Wakeman at SIGCOMM '94. This was implemented in RTPv1 using options carried in the data packets. Christian Huitema and Ian Wakeman argued that it was important that RTPv2 not preclude further experimentation with this scheme. RTPv2 does not include control options, but does provide a header extension mechanism intended for application-specific extensions. It was agreed that provision should be made for further experiments to compare the two schemes, and that the header extension mechanism would be suitable. Details of the extension format for this use must be defined in the Audio/Video profile that accompanies the RTP spec. 2.2 Provision for testing unicast feedback mechanism In the Bolot/Turletti/Wakeman scheme, reports from the polled receivers are returned to the sender using the "unicast reverse path control packet" mechanism of RTPv1. This mechanism was eliminated in RTPv2 because the change of SSRC ID scheme and complete encryption of the packets preclude translators from passing the reverse packets. Van Jacobson suggested that it would be better to multicast the reports even under the sender-initiated polling scheme, and Ian Wakeman agreed this might be the best method. However, Christian Huitema did not want to rule out entirely the possibility of sending unicast reports as it might have lower cost especially for symmetric sessions with many very small sources. Unicast control packets are also utilized in the H.261 video packetization scheme. It was again agreed that provision should be made for experimentation with both unicast and multicast methods. Since it is feasible to do these experiments in scenarios that do not include translators, receivers can use the IP/UDP source information to return unicast replies directly. The INRIA folks prefer that the source port of the data packets be used as the destination port for the unicast replies. INRIA will take responsibility for designing the details of unicast packet use under RTPv2 in this scenario, and provide a report back to the group on the results of the experiments. 2.3 Need to define encapsulations for protocols other than UDP In RTPv2, control and data are sent on separate ports when using UDP. For other protocols, either two associations must be used or some encapsulation must be defined to provide multiplexing of control and data on one association. The RTPv2 spec does not specify any such encapsulations; instead, that task is left to separate specifications in the same manner as the IP encapsulation on Ethernet is defined separately from the IP spec. Don Hoffman suggested that it was the responsibility of ancillary groups, such as ATM Forum for AAL5, to decide whether to provide multiplexing or use two associations, and to define the details of the encapsulations. It was agreed that the RTP spec would simply state the requirement for the underlying layers to provide the multiplexing for separate control and data. 2.4 Removal of FMT control packet Van Jacobson, Ron Frederick and Christian Huitema all lobbied for the removal of the FMT control packet. Henning Schulzrinne was the primary proponent but was not present. Henning's argument is that due to the combinatorics of encoding parameters, one can't define ahead of time all the payload types that you may need to use in a session. The creator of the session can't know all the ones that others in the session may want to use. Van countered that only a small number of the combinations will ever be used. The group was asked about other uses of dynamically defined payload types that might affect this decision, but none were identified. It as agreed that FMT should not be defined in the main RTP spec, but that it could be defined in profiles as needed. For the initial Audio/Video profile, it was further agreed not to include FMT at this time. If a clear need is demonstrated later, we can define it then, as a profile extension. 2.5 Authentication omitted The RTPv2 spec does not specify any authentication methods. Encryption is defined because the primary security concern is for privacy in conversations, which seems to be a stronger concern for audio that for typed words. Furthermore, Ron Frederick asserted that without a key management system to use for the authentication, it's a moot point. There were no objections to omitting authentication from the spec. 2.6 Rules for sending receiver reports There are a few items that remain to be fully specified in the RTP draft. One is to clarify when reception reports are required and when they may be omitted. The current statement is simply that they are required when IP multicast is being used. It may not make sense for the spec to describe in detail under what circumstances reports might not be used; we know about the IP multicast case, but we have not really learned about the others yet (e.g., unidirectional systems). Van Jacobson has promised to supply an algorithm for calculating the interval between reception reports such that the overall rate of control traffic from all sources is kept to a small fraction (1%) of the data rate. This will go in an appendix of the RTP specification. Van also brought up a new aspect to be considered for this algorithm that was suggested by Henning Schulzrinne. If more of the control bandwidth is allocated to senders than to receivers so that they can send CNAMEs more often, this will allow receivers to more quickly establish the cross-media binding for functions such as audio/video synchronization. For example, giving 50% of the bandwidth to senders and the rest to receivers seems reasonable. If all participants get the same amount of control bandwidth, in a 1000-person conference it might be 5 minutes before a new participant received the senders CNAME. The details need to be designed for clamping the sender control rate to a reasonable maximum and insuring that randomization of the sending interval will avoid exceeding the overall control bandwidth on a transient basis over the scale of session sizes. This new feature should be tested before it goes into the spec. 2.7 Bit allocations, lengths in 32-bit units, control packet types The RTP spec defines a particular allocation of bits to functions in the data header. In particular, only 4 bits are allocated to the count of CSRC identifiers following the header so that 7 bits may be allocated to the payload type field. There were no objections to this allocation. A recent change in the spec was that all length fields covering areas required to be a multiple of 32-bits should be counted in units of 32-bits rather than octets, and should not count the first 32-bit word that contains the length field. This avoids a validity check that the bottom two bits of length are zero and a second validity check that the value is not zero. No objections were voiced. Steve Casner proposed that the control packet type space be partitioned among the main spec, profiles, and applications within a profile, as was done with option codes in RTPv1. This allows profiles and applications to define types without conflicting with each other or future definitions in the main spec. This topic was not yet addressed in the spec, but was agreed and will be added. 2.8 RTP Timestamps and relationship to real time Although it was not listed as an open issue, some questions were raised about how the RTP timestamp should be related to real time for purposes of synchronization. Christian Huitema pointed out that the RTPv1 timestamp provided the relationship to real time directly in the signal stream where it fits naturally. In RTPv2 the relationship is carried in the control packets to optimize data packet processing, and this may be less convenient for some implementations. Julio Escobar noted that for some applications such as data fusion, the limitations on control traffic bandwidth might make they delay before synchronization too long. For such applications, the profile may specify that the RTP timestamp will carry part of a real-time timestamp and/or that additional real-time timestamp information may be carried in a header that's part of the encoding or in an RTP header extension. However, the RTP timestamp is supposed to have a random initial offset for stronger encryption, so for the RTP timestamp to carry part of an NTP timestamp this offset must be communicated to the receivers out of band so it can be subtracted. Christian said the IVS implementors had also observed a problem that the audio input on some workstations skips samples under heavy load, thereby causing the media clock to drift with respect to real time. It should be possible for the normal playout buffer adaptation to accommodate this. For synchronized playback, the relationship to real time may be adjusted at the next start of talkspurt following each Sender Report control packet that is received. These must be sent often enough that the drift out of sync does not become too large in between, which relates back to the control packet bandwidth limit. 3. Open questions about A/V profile In addition to the open issues regarding the RTP spec itself, there were a few open issues to be settled for the specification of the initial Audio/Video profile. These are described below. 3.1 Number and meaning of Marker bits The RTP spec allows a profile to trade off the number of marker bits and payload type bits in the second octet of the data header. The proposal for the Audio/Video Profile is to have one marker bit, and that it would mark the start of a talkspurt for audio and the end of a frame for video. There was some discussion of the value of marking the end of a talkspurt, but Van Jacobson argued that the functions to be performed were independent of the bit. The choice of marker bit was accepted by the group. 3.2 Default encryption method Encryption at the RTP level is defined to cover the entire packet, and header validity checks are used to verify decryption with the correct key. The spec also identifies an alternative to not use encryption at the RTP level, but instead to allow both unencrypted and encrypted payload types to be defined. For example, two payload types, one for unencrypted PCM and one for encrypted PCM. This allows feeding an encrypted, compressed stream to hardware that expects such a stream. It was proposed that the A/V Profile should specify RTP-level encryption as the default, based on the general principle to encrypt all information that does not have to be left in the clear. This was accepted by the group. 3.3 Relationship between control and data port numbers The RTP spec currently defines the default relationship between the control and data port numbers to be control = data + 1, but allows profiles to define a different relationship. Van Jacobson proposed to change this default to be more strict, that the data port must be even (making the control port odd), and that we use this choice in the A/V Profile. This change would allow a network provider to notice traffic on either port and find the control channel to monitor without having any external information about the conference. This proposed changed was agreed, and in addition it was agreed that both the address allocator and the media applications should force the data port number to be even. This policy could be implemented only in the address allocator, such as the sd tool. However, since the current implementation of sd does not force the data port to be even, it was agreed that enforcing the policy in both places would ensure that it was upheld and avoid compatibility problems. 4. Profiles for packetization of video encodings During the second session, presentations were given on the specifications of how the H.261, JPEG and MPEG video encodings should be packetized for carriage over RTP. These specs will be companions to the RTP spec. 4.1 Packetization of H.261 video encoding Christian Huitema gave a presentation on the revision of the H.261 video packetization spec. This encoding works without the H.221 bit-level multiplexing that is used with H.261 over circuits, carrying GOBs (groups of blocks) in packets instead. INRIA implemented compression in software; UCL has interfaced a hardware codec and stripped off the H.221 framing. The packet format allows for arbitrary bit alignment of the data to accommodate the hardware codecs. After the RTP header, there is a 16-bit header that describes the format of the encoding that follows. Included are the bit positions of the starting and ending bits within their bytes. These are now constrained to be zero (byte aligned) except at the beginning and end of a GOB. Also in the header are several flags and the image size. Van Jacobson requested a change to allow reassembly of the packets of a GOB into a contiguous buffer even when packets arrive out of order. The contiguous buffer permits a simpler and faster decoding loop. This can be achieved by establishing the rule that all packets of a GOB other than the last are the same size; or, alternatively, by adding a fragment offset field to the H.261 packetization header. Christian preferred the first option because it did not introduce an incompatibility in the packet format and did not add more overhead. It was agreed to make this change in the spec. Steve Casner pointed out that the recent draft still requires some changes in packet formats to reflect the use of RTCP control packets on the control port rather than options in the data packets. As was noted above, some detail on the use of unicast reverse packets must also be specified. When these steps are completed, it was agreed that this draft should be submitted in conjunction with the RTP spec as a Proposed Standard. 4.2 Packetization of JPEG video encoding Bill Fenner gave a description of the JPEG over RTP spec which has resulted from discussions with Ron Frederick, Steve McCanne and Lance Berc. (See the slides for details.) An Internet Draft on the JPEG packetization spec will be produced by the next IETF meeting in December. The encoding has a 64-bit header including a fragment offset since it is not possible to guarantee same-size packets in JPEG. JPEG markers are defined to be 0xFF bytes in the data stream; if you have a hardware codec that doesn't support this, you have to remove them in software. (Since there are also hardware codecs that require the 0xFF stuffing, you can't always win, and including them allows additional functions.) The only JPEG markers supported are restarts which allow recovery in case some data is lost. A type field has replaced the collection of individual parameters in the previous version of this spec. Types 0-127 will be statically defined, with type 0 being YUV 4:2:2 and type 1 being YUV 4:2:0. Since not all hardware supports restarts, type 0 is defined to exclude them to maximize interoperability. Restart codes will be supported in the future in some future types after all the details are determined. Types 128-255 are dynamically defined by the session protocol or by a control packet, basically by sending all of the JFIF header describing that type. 4.3 Packetization of MPEG video encoding Don Hoffman gave an update on the changes in the MPEG packetization draft for RTPv2. (The Cell-B draft will just be re-issued and discussed via email.) MPEG-2 is in development as an ISO/IEC standard. In the MPEG profile for RTP, two formats are proposed. The first translates and encapsulates the information in the MPEG-2 Systems environment for interoperation with other transport mechanisms. The second is a much simpler for "native" Internet uses (eliminating a lot of the application-level functionality that does not apply). It is expected that MPEG hardware will provide an interface at the Packetized Elementary Stream (PES) level to make this possible. For both the MPEG and Cell-B specs, the goal is to have Internet Drafts completed by the next meeting. This spec uses the 90 kHz MPEG presentation timestamp clock for RTP timestamps. There is a transport header at the start of the RTP payload that carries a translation of the MPEG transport information. The transport header includes some optional fields whose presence is indicated by a bit field in the first word. There is one issue with regard to MPEG timing. There are I, P and B frames that are produced and interpolated at the receiver. The output >from the encoder is not in temporal order, it is in frame dependency order. Therefore, the presentation timestamps in the RTP header will be transmitted out of order with respect to the sequence numbers. The group did not see this as a problem. For the PES encapsulation, will need payload types assigned for MPEG 1 video, MPEG 2 video, and MPEG 2 audio. A 16-bit header was proposed at start of the payload to carry some flag bits and slice counter. One of the flag bits indicates that another 16 bits follow to carry the macro-block absolute position field. However, Ron Frederick suggested that 32-bit alignment was valuable, so the second 16 bits should always be included. Ron agreed this was a worthy consideration. 5. Conclusion During this meeting, the group agreed on essentially all of the open issues for the RTP spec. At the end of the meeting, the group was asked for a show of hands from those who thought the specification choices that had been made were fine, and that we should proceed with filling in the example algorithms and completing the areas in the spec where it now says "to be determined" and then submit this protocol spec to the Area Directorate again for publication as a Proposed Standard RFC. The chair interpreted the response as consensus that we should proceed. There is now nothing in the way except completing the remaining details; the people who are responsible know who they are. The spec should be completed and submitted well in advance of the next meeting. ------- From rem-conf-request@es.net Wed Aug 31 03:22:04 1994 Received: from sangam.ncst.ernet.in by osi-west.es.net via ESnet SMTP service id <08290-0@osi-west.es.net>; Wed, 31 Aug 1994 00:21:35 +0000 Received: (from uucp@localhost) by sangam.ncst.ernet.in (8.6.8.1/8.6.6) with UUCP id MAA24352; Wed, 31 Aug 1994 12:50:57 +0530 Received: by henna.iitd.ernet.in (4.1/SMI-4.1-MHS-7.0 ) id AA13930; Tue, 30 Aug 94 21:37:07 IST X-Organisation: Indian Institute of Technology, New Delhi. Date: Tue, 30 Aug 1994 21:32:49 +0530 (IST) From: Palepu Srinivas Subject: Real Time Audio Compression To: mbone@ISI.EDU, rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello everybody: I am interested in having a source code for real-time audio compression, any standards / non-standard technique is OK. Preferably something that can compress audio down to 9.6kbps. I believe Van Jacobson's vat does that, but the source code is not in public domain, if I am right. So, am looking for some other alternatives. Any pointers / comments? Thanks in advance -srinivas palepu From rem-conf-request@es.net Wed Aug 31 04:39:26 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <08678-0@osi-west.es.net>; Wed, 31 Aug 1994 01:38:56 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <22724-0@ceres.fokus.gmd.de>; Wed, 31 Aug 1994 10:41:57 +0200 Subject: Re: Real Time Audio Compression To: rem-conf@es.net Date: Wed, 31 Aug 1994 10:41:57 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de > I am interested in having a source code for real-time audio compression, > any standards / non-standard technique is OK. > > Preferably something that can compress audio down to 9.6kbps. Look at the GSM (roughly 13 kbps) and lpc (5 kbps) code in NeVoT. (ftp://gaia.cs.umass.edu/pub/hgschulz/nevot).(I wrote neither.) GSM is also available separately (mirrored in same directory). -- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 219 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin hphone: +49 117 432 4741 From rem-conf-request@es.net Wed Aug 31 06:25:27 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <09509-0@osi-west.es.net>; Wed, 31 Aug 1994 03:25:00 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <23558-0@ceres.fokus.gmd.de>; Wed, 31 Aug 1994 12:26:58 +0200 Subject: PC audio summary To: rem-conf@es.net Date: Wed, 31 Aug 1994 12:26:58 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de I collected the information kindly provided after my query at http://www.fokus.gmd.de/minos/employees/hgs/audio/audio.html As most of it is second-hand, I'd appreciate corrections. -- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 219 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin hphone: +49 117 432 4741 From rem-conf-request@es.net Wed Aug 31 14:24:01 1994 Received: from taurus.cs.nps.navy.mil by osi-west.es.net via ESnet SMTP service id <12242-0@osi-west.es.net>; Wed, 31 Aug 1994 11:23:38 +0000 Received: from patton.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA02124; Wed, 31 Aug 94 11:25:39 PDT Date: Wed, 31 Aug 1994 11:25:38 +48000 From: Michael Macedonia To: rem-conf@es.net Subject: New Fully Scalable Software Video Codec Release Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I thought this might interest the group. Mike Macedonia | macedonia@cs.nps.navy.mil MAJ, USA | CS Dept, Naval Postgraduate School, | Monterey, CA 93943 | PH:(408) 656-2903 FAX:(408) 656-2814 ------------------------------------------------------------ Archive-Name: auto/comp.multimedia/New-Fully-Scalable-Software-Video-Codec-Release Public Software Release ----------------------- FULLY SCALABLE, LOW-LATENCY VIDEO CODEC BASED ON 2 & 3 DIMENSIONAL SUBBAND TRANSFORMATION AND INTER-FRAME PROGRESSIVE CODING OF SUBBAND COEFFICIENTS WITH SCALING FOR CONSTANT BIT RATE (CBR) OR CONSTANT DISTORTION (VBR) CRITERION by David S. Taubman University of California, Berkeley ----------------------- I am pleased to announce the release of scalable video compression and decompression software. This software may be regarded as a sequel to our previously released scalable image and video codec (June 30, 1994). The previously released codec is available from robotics.eecs.berkeley.edu in /pub/multimedia/scalable.tar.Z whereas the new codec may be found at robotics.eecs.berkeley.edu in /pub/multimedia/scalable2.tar.Z Unlike conventional compression standards, these codecs perform fully scalable compression of both video and images. This means that subsets may be extracted from the compressed data stream so as to satisfy virtually any constraint on bit rate and a wide range of compatible display frame resolutions and frame rates. That is, the video is compressed once only, after which scaling may occur to meet unpredictable demands imposed by storage, distribution and display systems. The new codec differs from our previously released software codec in two primary respects: 1) The new codec exploits temporal redundancy by using both temporal subband decomposition and inter-frame progressive coding techniques, rather than temporal subband decomposition alone. As a consequence, fewer levels of temporal subband decomposition are required to achieve good compression with the new codec than with the previously released one. As such, the new compression/decompression algorithm is able to achieve good compression efficiency with much less memory and much lower end-to-end delay than that implemented by our previous software release. 2) Whereas our previously released software compression algorithm generated a bit stream, the new software generates a packet stream. The distinction between these two cases is that scaling entities must be intimately familiar with the detailed bit stream syntax if scaling is to take place within the context of a raw bit stream. On the other hand, the packet stream imposes a higher level abstraction on top of this syntax, so as to enable simple, generic scaling entities to select from a pre-defined set of bit rate targets. Simple headers in the packet stream provide sufficient information to perform scaling with either a constant bit rate or constant distortion criteria. These concepts are explained in the technical paper included with the software release. Note: All correspondence should be directed to: scalable@robotics.eecs.berkeley.edu For suggestions or questions regarding envisaged hardware or software implementations, algorithm enhancements or further developments, feel free to contact Professor Avideh Zakhor at avz@robotics.eecs.berkeley.edu The `scalable2.tar.Z' file contains: software and documentation; a technical paper, discussing the theoretical aspects of the algorithm, scaling operations and experimental performance results; and examples. Software is driven by a general configuration language, enabling numerous compression algorithms to be generated within the scalable context. Decompression with compatible, but not identical configurations enables frame resolution and frame rate scalability. Although frame rate and frame resolution scalability are primarily of value for compatible decompression, bit rate scalability is of value throughout the path from compression, possibly to storage, through distribution and eventually to decompression. Bit rate scalability is currently only implemented within the decompression software, so that bit rate constraints may be imposed immediately before decompression. We note, however, that the packetization scheme enables simple, generic rate scaling operations to be implemented anywhere in the distribution path taken by the scalable data stream. The decompression software may be used in conjunction with a separate viewing console with VCR-like controls for video playback, rewind, fast forward, etc., on high end workstations. The viewing console software itself is not included in `scalable2.tar.Z', but may be recovered from the `scalable.tar.Z' file containing our previously released scalable codec. Initial investigations suggest the following: For video compression of progressively scanned video sequences, the compression efficiency is comparable to that of the non-scalable MPEG-1 standard. Generally, performance is significantly better than MPEG when camera motion conforms to a pan model (i.e. still, jitter, and true pan), regardless of the amount of foreground motion. On the other hand, performance can be significantly worse (2-3 dB) than MPEG when camera motion is zoom or translation and when there is little or no complex foreground motion. It is important to appreciate, however, that the primary feature of this suite of compression algorithms is scalability. Computational complexity appears to be perhaps several times that of MPEG, however the algorithm is inherently amenable to highly parallel hardware or software implementation. Feel free to experiment with the software and send us feedback regarding your experiences and/or application ideas. David Taubman (August 29, 1994) From rem-conf-request@es.net Wed Aug 31 20:54:18 1994 Received: from ncb.gov.sg by osi-west.es.net via ESnet SMTP service id <15052-0@osi-west.es.net>; Wed, 31 Aug 1994 17:53:52 +0000 Received: by ncb.gov.sg (4.1/SMI-4.1) id AA15991; Thu, 1 Sep 94 08:50:51 SST Date: Thu, 1 Sep 1994 08:50:50 +0800 (SST) From: Tan Pow Hwee Subject: sending audio to vat To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I need to write an application that can send audio to vat and have it play back. In a way, using vat as a continuous audio player. I've read the RTP draft and profile document; and would appreciate other references that can help me implement this, as vat source code is not available. Thanks much for any help. Regards, Pow-hwee Tan powhwee@ncb.gov.sg