From rem-conf-request@es.net Tue Feb 01 00:51:30 1994 Received: from netcom5.netcom.com by osi-west.es.net via ESnet SMTP service id <10873-0@osi-west.es.net>; Mon, 31 Jan 1994 21:51:14 +0000 Received: from localhost by mail.netcom.com (8.6.4/SMI-4.1/Netcom) id VAA18265; Mon, 31 Jan 1994 21:21:02 -0800 Date: Mon, 31 Jan 1994 21:20:12 -0800 (PST) From: Mark Lucas Subject: ACM Multimedia '94 Conference To: ACM MM 94 #10 <71431.3312@compuserve.com>, asood@gmuvax.gmu.edu, bam@a.gp.cs.cmu.edu, ben@cs.umd.edu, bjshep@ausvm6.vnet.ibm.com, blattner@ocfkms.llnl.gov, cap1@thumper.bellcore.com, cts@cs.hut.fi, deborah@citi.umich.edu, dlee@cis.ohio-state.edu, edward.martini@eng.sun.com, fl08+@andrew.cmu.edu, h133mar@ella.hu, haim@cs.ulowell.edu, hfk@mitl.com, hlinger@fcit.monash.edu.au, jks@usa.ece.cmu.edu, jol@hpl.hp.com, jurban@enws104.eas.asu.edu, jxr@thumper.bellcore.com, kahn@parc.xerox.com, kawagoe@tsl.cl.nec.co.jp, keith@pioneer.arc.nasa.gov, klara@grad1.cis.upenn.edu, klas@icsi.berkeley.edu, klaus@informatik.rwth-aachen.de, klwu@watson.ibm.com, kmw@informatik.uni-erlangen.de, korfhage@icarus.lis.pitt.edu, korfhage@weston.poly.edu, kywhang@mozart.kaist.ac.kr, lam@cs.utexas.edu, laukee@canon.co.uk, liu@ernie.siemens.com, magda@ee.upenn.edu, maraninx@imag.imag.fr, marek@uh.edu, masui@shpcsl.sharp.co.jp, midkiff@vtvm1.cc.vt.edu, miyamoto@shpcsl.sharp.co.jp, miyao@mis.hiroshima-u.ac.jp, mmm-people@isi.edu, morimoto@trlvm.vnet.ibm.com, mshakar@vrit01.eg, neuhold@darmstadt.gmd.de, nigam@mitre.org, nik@clos.nnov.su, okamoto@csd.sumikin.co.jp, ola@adm.csc.ncsu.edu, osborne@software.org, ozsu@cs.ualberta.ca, paterno@icnucevm.cnuce.cnr, pax@ankh.metrolink.com, pds@cis.ufl.edu, pete@icbl.heriot-watt.ac.uk, pezze@ipmel2.elet.polimi.it, pmatsira@wcu.bitnet, psyu@watson.ibm.com, rajiv@ms.uky.edu, rakow@darmstadt.gmd.de, rem-conf@es.net, riedl@hannibal.cs.umn.edu, rmarcus@atc.boeing.com, rnk@sei.cmu.edu, roman@cs.wustl.edu, s.reisman@compmail.com, sato@huis.hiroshima-u.ac.jp, schnorf@canon.com, schooler@isi.edu, schwan@cc.gatech.edu, sdl@mitre.org, senay@seas.gwu.edu, shan@hplmcs.hpl.hp.com, shekhar@cs.umn.edu, sheng@mis.arizona.edu, sinha@trl.mei.co.jp, sklar@era.com, sms@sei.cmu.edu, son@cs.virginia.edu, speegle@mercury.baylor.edu, steinmet@dhdibm1.bitnet, stro@merl.com, sugihara@freiland.ics.hawaii.edu, tanimoto@cs.washington.edu, tappan@software.org, tdcl@buenga.bu.edu, tkarren@ingres.com, tsotras@pucatt.poly.edu, ventre@icsi.berkeley.edu, vetter@cs.umn.edu, walpole@cse.ogi.edu, wei@csufres.csufresno.edu, wilko@informatik.rwth-aachen.de, wuu@ctt.bellcore.com, yama@trdc008.csc.ti.com, ying@saturn.cs.swin.oz.au, ylien@ihlpy.att.com, yoshi@huis.hiroshima-u.ac.jp, yu@dbis.eecs.uic.edu, znati@cs.pitt.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, My name is Mark Lucas and I am president of The Lucas Group, a consortium of music composer-producers from Los Angeles who specialize in Multimedia and Virtual Reality work. Last year at the ACM SIGGRAPH-Multimedia '94 Town Hall meeting, the question was raised as to how the next conference would address the issues of sound, music and audio. Since there was no strategic plan in place, myself and some others volunteered for the planning committee to create valuable conference content in this area. The best way for us to do that is to understand your needs... "your requirements". I have constructed a questionnaire which takes a very broad sweep of the issues in sound, music and audio in an effort to understand what it is you want from the conference and from that we intend to create curriculum content. If you are not planning to attend ACM Multimedia '94, have no interest in it, and don't know why you got this message, please be courteous and ignore this message. To everyone else... this is your chance to get what you want out of this year's conference! 20 questions follow this e-mail. Please complete them as thoroughly as possible and respond no later than February 10th, 1994. Thank you for your interest and support! Mark Lucas The Lucas Group -------------------------------------------------------------------- ACM Multimedia '94 - Sound, Music & Audio Questionnaire: Please rate your level of interest by placing the appropriate number to the left of the suggested curriculum: [1=Extreme Interest 2=Mild Interest 3=No Interest] ___ Synchronization: SMPTE and others... what are they/how to make them work. ___ Reciprocity & Synchronicity: The art of creating a soundtrack to enhance the visual. ___ Interactive Composition/Random-access music: how to create soundtracks when users control the sequence of events. ___ Audio Engineering (i.e. fidelity, clarity, audio editing, effects, EQ, multitracking, mix down, recording live instruments & vocals, noise reduction, managing ambience, etc.) ___ MIDI, SMDI & related musical/sample information formats: Untangling the techno-sound jungle. ___ Alternatives to digital audio recordings (samples). ___ Sound synthesis based on physical models. ___ New sound synthesis techniques ___ Music Composition 101: understanding intellectual & technical creative processes of the composer for beginners and non-composers. ___ MIDI Composition: for all you John Williams Juniors ___ Music Libraries: how to get the most out of your investment. ___ Legal Issues in Music: licensing, copyright infringement and fair use. ___ Sound Effects Design: beyond boinks, zweeps and clunks ___ Sound in virtual environments ___ Psycho-Acoustics ___ Sound over the network ___ Data structures that combine digital audio and graphics ___ Audio product domains: what product "genres" are there and for which applications are they best suited. That concludes the content portion of the questionnaire. Please feel free to add any categories you think we missed! To better understand how to deliver the content, we need to know to whom we will be presenting the curriculum. Please tell us a little about yourself. Place an X beside the line which best describes your attributes. Your business... are you a ___ MM Content Developer ___ Production Facility ___ Software Developer/Vendor ___ Hardware Developer/Vendor ___ Mastering or other medium ___ Distribution/Retail entity ___ Educator ___ Consultant ___ Other (please specify below) Your position... ___ Executive ___ Business Management ___ Creative Management ___ Sales Management ___ Technical Management ___ Creative Talent ___ Technical Talent ___ Sales/Marketing Representative ___ Other (please specify below) Thank You! Mark Lucas The Lucas Group From rem-conf-request@es.net Tue Feb 01 14:21:07 1994 Received: from ringding.cs.umd.edu by osi-west.es.net via ESnet SMTP service id <17796-0@osi-west.es.net>; Tue, 1 Feb 1994 11:20:52 +0000 Received: by ringding.cs.UMD.EDU (5.64/UMIACS-0.9/04-05-88) id AA21674; Tue, 1 Feb 94 14:20:49 -0500 Date: Tue, 1 Feb 94 14:20:49 -0500 From: junesong@cs.UMD.EDU (Junehwa Song) Message-Id: <9402011920.AA21674@ringding.cs.UMD.EDU> To: rem-conf@es.net Subject: Subscription and deletion. 1. Please subscribe me, with the address "byha@wam.umd.edu". 2. Pleasse delete my old email address from the list which is "junesong@cs.umd.edu". Thank you very much. --Junehwa Song. From rem-conf-request@es.net Wed Feb 02 07:12:36 1994 Received: from daiduk.kaist.ac.kr by osi-west.es.net via ESnet SMTP service id <27790-0@osi-west.es.net>; Wed, 2 Feb 1994 04:12:13 +0000 Received: from datacom1.kaist.ac.kr.noname by daiduk.kaist.ac.kr (4.1/KAISTNet-Relay-3.2) id AA01377; Wed, 2 Feb 94 21:08:53 KST Received: by datacom1.kaist.ac.kr.noname (4.1/SMI-4.1) id AA04215; Wed, 2 Feb 94 21:06:21 KST Date: Wed, 2 Feb 94 21:06:21 KST From: hskim%datacom1.kaist.ac.kr@daiduk.kaist.ac.kr (Kim Hyung Soo) Message-Id: <9402021206.AA04215@datacom1.kaist.ac.kr.noname> To: rem-conf@es.net Subject: Subscribe Please subscribe me to the mailing list. From rem-conf-request@es.net Wed Feb 02 17:48:27 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <05741-0@osi-west.es.net>; Wed, 2 Feb 1994 14:48:09 +0000 Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Wed, 2 Feb 1994 14:48:04 -0800 Date: Wed, 2 Feb 1994 14:47:56 -0800 From: schooler@ISI.EDU Posted-Date: Wed, 2 Feb 1994 14:47:56 -0800 Message-Id: <199402022247.AA10432@elm.isi.edu> Received: by elm.isi.edu (5.65c/4.0.3-4) id ; Wed, 2 Feb 1994 14:47:56 -0800 To: rem-conf@es.net Subject: Re: New version of mmcc Cc: schooler@ISI.EDU Thanks to Dave Meyer from the University of Oregon, there is now a version of mmcc that has been ported to run under Solaris. Along with the other tar files, it is available from the directory ftp.isi.edu:confctrl/mmcc. It is file mmcc-solaris.tar.Z. E. ----- Begin Included Message ----- >From schooler@ISI.EDU Mon Jan 24 20:10:35 1994 Date: Mon, 24 Jan 1994 20:10:28 -0800 From: schooler@ISI.EDU To: rem-conf@es.net Subject: New version of mmcc Cc: schooler@ISI.EDU, touch@ISI.EDU, casner@ISI.EDU Content-Length: 992 X-Lines: 26 Hi, The mmcc session orchestration tool was first released a few months ago to run on Sun Sparcs. It allows a caller to explictly invite others to participate in point-to-point or multipoint teleconferences, and alerts them to accept or decline. It automatically spawns underlying audio, video and groupware programs among members of a session, then tears them down at session completion. We've now ported mmcc to run on SGIs running IRIX, HPs running HPUX, IBM PCs running Mach3.0, Dec 5000's running Ultrix V4.3, and Dec Alphas running OSF. The release software is now available from ftp.isi.edu:confctrl/mmcc, as files mmcc-{sparc,sgi,dec5k,decalpha,intel,hp}.tar.Z. The ports have been tested more thoroughly on some configurations than others. In addition to the porting activity, we fixed a number of serious bugs, including a few addressing-related ones. Comments and feedback are most welcome (and encouraged). Eve Schooler & Joe Touch {schooler, touch}@isi.edu ----- End Included Message ----- From rem-conf-request@es.net Wed Feb 02 21:31:32 1994 Received: from brownvm.brown.edu by osi-west.es.net via ESnet SMTP service id <08440-0@osi-west.es.net>; Wed, 2 Feb 1994 18:31:16 +0000 Received: from BROWNVM.BROWN.EDU by BROWNVM.brown.edu (IBM VM SMTP V2R2) with BSMTP id 9239; Wed, 02 Feb 94 21:28:54 EST Received: from BROWN.EDU (NJE origin LEE@BROWNVM) by BROWNVM.BROWN.EDU (LMail V1.1d/1.7f) with BSMTP id 5825; Wed, 2 Feb 1994 21:28:55 -0500 Date: Wed, 02 Feb 94 21:24:02 EST From: Lee Silverman Subject: Macintosh Audio Conferencing? To: "Origin of LISTS.REM-CONF" I've read some back issues on this list and most of the discussion seems to be for Unix based software (there was one windows package mentioned). However, what I really need is a package that allows me to establish an audio connection over a TCP/IP network from a Mac, or even from a Mac to a Sparcstation. Is there a cross-platform package that allows me to connect two or more machines on the internet? Email would be appreciated; I'll be sure to post a summary to the list. Set the Record Levels for the high gear of your soul!! Pandion Pandion@Brown.edu (Lee Silverman) LEE@BROWNVM From rem-conf-request@es.net Thu Feb 03 08:09:32 1994 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <13113-0@osi-west.es.net>; Thu, 3 Feb 1994 05:09:14 +0000 Via: uk.ac.lse; Thu, 3 Feb 1994 12:55:25 +0000 Received: from smtplink.lse.ac.uk by mailhost.lse.ac.uk with SMTP (PP) id <26740-0@mailhost.lse.ac.uk>; Thu, 3 Feb 1994 12:47:16 +0000 Received: from cc:Mail by smtplink.lse.ac.uk (1.30/SMTPLink) id A15002; Thu, 03 Feb 94 12:58:04 GMT Date: Thu, 03 Feb 94 12:58:04 GMT From: S Dustdar Message-ID: <9402031258.A15002@smtplink.lse.ac.uk> To: wg-imm@rare.nl, rem-conf@es.net, com-priv@psi.com Subject: Networked Multimedia:Commercial sites Dear Colleague At the London School of Economics, Information Systems Dept., we are investigating the impacts of networked multimedia information systems on organisations.(ONLY COMMERCIAL-sites) Since YOU are *networked* and probably interested in using multimedia systems you might be interested how these networked multimedia systems CHANGE the way we work in our organisations and with our customers. I would be very thankful if you as a commercial site would participate in this survey. Thank you very much in advance and please excuse any cross-postings of this questionnaire. Dr. Schahram Dustdar London School of Economics Information Systems Department S.Dustdar@lse.ac.uk * the questionnaire takes only 10 minutes to complete * upon request, I will forward an E-Mail-copy of the results free of charge to you * please send all replies until 14.FEB. 1994 to S.Dustdar@lse.ac.uk * please feel free to forward the survey (e.g. to your IS/IT director, etc.) Thank you vey much in advance for your help and co-operation! <<< For Your Information >>> Please read the following definition, as it will help you understand the context in which it is used in the questionnaire: networked Multimedia information systems -- are computer-based interactive information systems which use the media types - data and audio, (Level 1) - data, audio and images (Level 2) - data, audio, images and video (Level 3) over the same networked infrastructure (like local area networks and wide area networks) **** A. Background questions **** 1. What is the name of your company? 2. How many people are employed by your company? 3. What is the approximate annual turnover of your company in US-D? 4. What is the primary business area of your company? 5. What is your job title? B. The use of Networked Multimedia information systems in your company **** 1. What media types (Level 1, 2 or 3) do you use in your information systems NOW? 2. What media types will you use in your information systems in 2 YEARS? 3. Do you use or plan to use Networked Multimedia information systems for critical applications of your organisation? (Y/N) If YES, which application area: 4. To what extent are telecommunication systems and information systems integrated? (measured on a 5 point scale: 1 very low to 5 very high, X not relevant/do not know) 5. Who is responsible for the planning and implementation of Networked Multimedia information systems? (eg. LAN-Manager, IT-director, ...) C. Strategic Issues **** (measured on a 5 point scale: 1 very low to 5 very high, X not relevant/do not know) Networked Multimedia information systems... 1. are included in our organisational IS/IT plan. 2. enhance our core business. 3. will be used for new products and services. 4. will increase our competetive advantage. 5. strengthen our customer relationship. 6. will lead to new customers, which we would not have reached otherwise. 7. others: D. Organisational Issues **** (measured on a 5 point scale: 1 very low to 5 very high, X not relevant/do not know) Networked Multimedia information systems lead to.... 1. redesign of work procedures. 2. redesign of the organisational scope. 3. smaller organisations. 4. higher quality of decisions. 5. enhanced personal communications. 6. others: E. Technical Issues **** (measured on a 5 point scale: 1 very low to 5 very high, X not relevant/do not know) To what extent does your company use ... 1. Computer supported Telephony now / in 2 years? 2. Networked Fax systems now / in 2 years? 3. Document-Image Handling Services now / in 2 years? 4. Internal E-Mail now / in 2 years? 5. External E-Mail now / in 2 years? 6. Internet Services now / in 2 years ? 8. Desktop-Video Conferencing now / in 2 years? 9. Multimedia Training systems now / in 2 years? 10. others: F. What are, in your view, the main BENEFITS of Networked Multimedia systems? G. What are, in your view, the main CONSTRAINTS in using Networked Multimedia systems? H. Do you offer or plan to offer Networked Multimedia Services over the Internet to your customers? (Y/N) If YES, when and which services: If NO, why: I. Are you interested in receiving a copy of the results? (Y/N) J. Would you like to participate in a more detailed questionnaire? (Y/N) Thank you very much for participating and for your patience and please excuse any cross-postings of this questionnaire. From rem-conf-request@es.net Thu Feb 03 12:05:36 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <15401-0@osi-west.es.net>; Thu, 3 Feb 1994 09:05:18 +0000 Received: from rover.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Feb 1994 17:04:39 +0000 To: mbone@ISI.EDU, rem-conf@es.net Subject: MICE International Seminars in February 1994. Date: Thu, 03 Feb 94 17:04:35 +0000 From: Gordon Joly This is a regular series, currently every two weeks. Please limit traffic on Tuesday 8 and 22 February. ----------------------- Feb 8 14.00 UCL Toshikazu Kato (ETL/MITI) will speak on Human Media Technology - New Perspectives on Human-Media Interaction Feb 22 14.00 Bruno Struif (GMD) - Electronic Prescription It is to be transmitted on the usual multicast addresses: vat 224.5.17.12/3456 ivs 224.5.17.12/2232 wb 224.5.17.12/32416 and advertised in "sd". Further information is kept in the URL http://www.cs.ucl.ac.uk/mice/seminars.html Here is the abtract for Dr. Kato's talk: Human Media Technology -- New Perspectives on Human-Media Interaction -- Dr. Toshikazu Kato, Electrotechnical Laboratory (ETL), MITI This talk introduces a general idea of "human media technology" which is a new aspect of multimedia information technology. A human-centred approach to system designing has been discussed, examined and made a progress in human-computer interaction (HCI) research to meet the user's requirement. Now, we have to go further to understand behaviours of human beings, such as perception, memorisation, associative recall, communication, and creation of multimedia objects, for the next generation multimedia information society. In this context, we have to deeply investigate into intelligent human-media interaction (HMI), which is a general style of human-computer interaction (HCI), human-robot interaction (HRI), human-human interaction (CSCW), and so on. To enable HMI, we need basic technologies on the following points; (a) modelling physiological perception process for multimedia objects (media model), (b) modelling subjective and psychological perception process for multimedia objects (cognitive user model), (c) modelling a human's skill of behaviour (skill model), such as creative action, (d) understanding user's intention behind the given message in multimedia presentation based on the media model and the cognitive user model, and (e) simulating human beings behaviour based on the user's skill model. This talk presents, as typical examples, how to organise multimedia information systems which have user interfaces for visual interaction from this viewpoint. We adopted an image model and a cognitive user model which take important role as well as a data model, in conventional meaning, in design and management of database systems. The image model describes the physical features of image data, which is a computational-physiological model of human's early vision mechanism, and which is basis of designing graphical feature parameters for pattern recognition and classification. We can design the model as an approximation of physiological feature of human's early vision mechanism, such as grey level distribution, spatial frequency, local contrast, local correlation, etc. The cognitive user model reflects the visual perception process of each user (or user group), which is a computational- cognitional model of human's sense and emotion, and which gives subjective criteria in flexible query and pattern interpretation from the user's viewpoint. We can build the model by statistical learning using multivariate analysis on multimedia data, such as classification, weighted adjective, etc. Based on the models above, we developed the algorithms for typical visual interaction styles; (i) a query by visual example (QVE) enables to retrieve the ori ginal (or similar) pictures from a hand-written rough sketch, (ii) a query by subjective descriptions (QBD) enables to find some pictures which may satisfy user's ambiguous description on visual impression, and (iii) an associative query on colour and category enables to consult and create suitable co-ordination of visual objects. In this talk, I will give a brief sketch of human media technology project at first, then go through our experimental result. Related keywords: SOFT science and technology, mind-based technology. Gordon Joly Phone +44 71 380 7777 3703 FAX +44 71 387 1397 Email: G.Joly@cs.ucl.ac.uk UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly Comp Sci, University College London, Gower Street, LONDON WC1E 6BT WWW:- http://www.cs.ucl.ac.uk/mice/gjoly.html -:WWW From rem-conf-request@es.net Thu Feb 03 14:49:33 1994 Received: from csdc.com by osi-west.es.net via ESnet SMTP service id <17961-0@osi-west.es.net>; Thu, 3 Feb 1994 11:49:08 +0000 From: ncho@csdc.com (Nam Cho) Received: from core.csdc.com by csdc.com (4.1/3.1.090690-CSDC) id AA01067; Thu, 3 Feb 94 14:53:55 EST Message-Id: <9402031953.AA01067@csdc.com> Subject: Multicast on sun4m kernal ? To: rem-conf@es.net Date: Thu, 3 Feb 1994 14:51:56 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 122 Hello, Has anyone had success in appling the ipmulti patches to a sun4m kernal ? (SunOS4.1.3) running on a Sparc10 ? From rem-conf-request@es.net Thu Feb 03 15:18:37 1994 Received: from mercury.unt.edu by osi-west.es.net via ESnet SMTP service id <18290-0@osi-west.es.net>; Thu, 3 Feb 1994 12:18:18 +0000 Received: from noc.unt.edu by mercury.unt.edu with SMTP id AA26316 (5.65c/IDA-1.4.4 for ); Thu, 3 Feb 1994 14:18:14 -0600 Received: from localhost (darren@localhost) by noc.unt.edu (8.6.4/8.6.4) id OAA11225; Thu, 3 Feb 1994 14:18:20 -0600 Date: Thu, 3 Feb 1994 14:18:20 -0600 (CST) From: Darren Paul Loher Subject: Re: Multicast on sun4m kernal ? To: Nam Cho Cc: rem-conf@es.net In-Reply-To: <9402031953.AA01067@csdc.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 3 Feb 1994, Nam Cho wrote: > Hello, > > Has anyone had success in appling the ipmulti patches to a sun4m kernal ? > (SunOS4.1.3) running on a Sparc10 ? > Tried to install it, but without good results. The kernal runs fine, I'm running it right now, mrouted runs fine, and will tunnel ip multicast fine. However, I cannot get sd nor any other tool to see ongoing sessions of the mbone. Yet, sites that our Sparc10 tunnels to are working fine. We tried configuring the Sparc10 as an end node, and no luck there either. Alas. Is this problem similar to yours? -- Darren Loher University of North Texas darren@unt.edu Datacommunications 817-565-4168 From rem-conf-request@es.net Thu Feb 03 16:57:00 1994 Received: from MITCHELL.CIT.CORNELL.EDU by osi-west.es.net via ESnet SMTP service id <19647-0@osi-west.es.net>; Thu, 3 Feb 1994 13:56:16 +0000 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU [132.236.199.54]) by mitchell.cit.cornell.edu (8.6.4/8.6.4) with SMTP id QAA24978; Thu, 3 Feb 1994 16:56:03 -0500 Message-Id: <199402032156.QAA24978@mitchell.cit.cornell.edu> X-Sender: rhx@132.236.199.25 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Feb 1994 16:59:28 -0500 To: rem-conf@osi-west.es.net, cu-seeme-l@cornell.edu From: R.Cogger@cornell.edu (Richard Cogger) Subject: CU-SeeMe0.60b1 Folks, A new version of Cornell's desktop video-conferencing program for the Macintosh is now available. Version 0.60b1 is the first beta version of what will eventually be 0.60. Since this is beta software, if you download and use it you become, by definition, a beta-tester. If you don't want to chance running into any little glitches, you might want to wait a few weeks. We have also, a Windows version under development, now in "pre-alpha" status functioning in receive only mode. If you would be willing to be a tester for that version, send mail to r.cogger@cornell.edu. CU-SeeMe0.60 is available free, by anonymous ftp, from Cornell University. Both the "About CU-SeeMe..." obtainable from the Apple Menu in the application itself and the README file on the ftp server carry Cornell's copyright and disclaimer-- essentially, you can do anything you want with it as long as you keep our copyright notice on it, don't use Cornell's name without permission, and understand and accept that we offer no warrantees and accept no liabilities. If you get the application downloaded and want to test (receiving only, if you're not equipped to send), connect to me, Dick Cogger, by typing in the following IP address: 192.35.82.96 which is a reflector at Cornell. You will usually find me or my empty chair there. If you see folks having a conference, please back out. If you see me and want to chat, call me at 607-255-8205. Also, I would like to hear of any uses to which CU-SeeMe is being put. Send to me or post to the list noted below. If you want to discuss CU-SeeMe, in addition to rem-conf, there is a list just for that: cu-seeme-l@cornell.edu To join the list, send a message with the following line as the entire message body to listserv@cornell.edu: subscribe cu-seeme-l (Substitute your actual name, please; it's amazing how many don't.) You should receive a confirming message with extensive instructions on use of the list. At this time, we are releasing only the object code (the application program) and not the sources. We plan to make sources available in the future, perhaps later in the spring. In the meantime, if you want to contribute to the development by adding particular functionality, please get in touch. Obtain the README file from: gated.cornell.edu /pub/video/CU-SeeMe0.60.README.2-2.txt The README will explain what you need to know, equipment needed, etc. You can then download the program from the same place. A few excerpts from the README: "CU-SeeMe provides a one-to-one connection, or by use of a reflector, a one-to-many, a several-to-several, or a several-to-many conference depending on user needs and hardware capabilities. It displays 4-bit grayscale video windows at 160x120 pixels or at double that diameter, and does not (yet) include audio. So far as we know, CU-SeeMe was the first and may still be the only software available for the Macintosh which supports real-time multi-party videoconferencing on the Internet. "CU-SeeMe is intended to provide useful conferencing at minimal cost. Receiving requires only a Mac with a screen capable of displaying 16 grays and a connection to the Internet. Sending requires the same plus a camera and either an AV-Mac or a SuperMac VideoSpigot board plus Quicktime and SpigotVDIG extensions added to the system folder. "CU-SeeMe was initially written for the Macintosh by Tim Dorcey with design assistance and sponsorship by Richard Cogger of the Advanced Technology group in the Network Resources division of Cornell University's Information Technology department (CIT). Important early contributions came from: Cornell University Medical Colleges (CUMC), Scott Brim, and John Lynn. "Since Oct. 1, 1993, the CU-SeeMe Project receives funding from the National Science Foundation. A very significant collaborative effort at Cornell University Medical Colleges (CUMC) is contributing substantial expertise and code. "Development contributers to CU-SeeMe0.60: Cornell: Richard Cogger (Project Director/PI), Tim Dorcey, Scott Brim (Co-PI), John Lynn, Larry Chace; CUMC: Steven Erde, Aaron Freimark, Aaron Giles. "This material is partially based on work sponsored by the National Science Foundation under Cooperative Agreement No. NCR-9318337. The Government has certain rights in this material." Compared to the previous release, 0.42, main differences are: * You don't have to switch to 16-grays (but you should use something that includes 16 grays). * There's a nickname facility so you don't have to type IP addresses all the time anymore (yea!). * There are brightness and contrast controls. * The user interface is much spiffier, thanks mostly to good work from the folks at the Cornell Medical College (CUMC), Steve Erde, Aaron Giles, and Aaron Freimark. * The AV Macs are supported. * Multiple monitors are handled correctly. * There are much better status indicators and controls to keep track of connection status, see "lurking" receive-only participants, check stats on errors, "pause" your video, etc. There are known deficiencies in the following areas: * When the button-bar, rates-bar, or other window extensions are drawn, an empty white area appears briefly as drawing starts. When some of the local-window controls are manipulated, there is unnecessary flashing as elements are drawn and redrawn. As far as we know these problems are only cosmetic. * On the AV Mac, the first time you launch CU-SeeMe after powering up, the local image (and the one you send) is strangely cropped. Just quit and launch again. And, for those who agree to help with the testing, Thanks! We appreciate it. Cheers, -Dick From rem-conf-request@es.net Thu Feb 03 17:22:39 1994 Received: from crusher.concert.net by osi-west.es.net via ESnet SMTP service id <19941-0@osi-west.es.net>; Thu, 3 Feb 1994 14:22:06 +0000 Received: by crusher.concert.net (5.59/tas-concert/6-19-91) id AA21977; Thu, 3 Feb 94 17:21:23 -0500 From: Fengmin Gong Message-Id: <9402032221.AA21977@crusher.concert.net> Subject: Re: Multicast on sun4m kernal ? To: darren@unt.edu (Darren Paul Loher) Date: Thu, 3 Feb 1994 17:21:23 -0500 (EST) Cc: ncho@csdc.com, rem-conf@es.net In-Reply-To: from "Darren Paul Loher" at Feb 3, 94 02:18:20 pm X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1051 Darren Paul Loher wrote earlier: > >On Thu, 3 Feb 1994, Nam Cho wrote: > >> Hello, >> >> Has anyone had success in appling the ipmulti patches to a sun4m kernal ? >> (SunOS4.1.3) running on a Sparc10 ? >> > >Tried to install it, but without good results. > >The kernal runs fine, I'm running it right now, mrouted runs fine, and >will tunnel ip multicast fine. However, I cannot get sd nor any other >tool to see ongoing sessions of the mbone. Yet, sites that our Sparc10 >tunnels to are working fine. We tried configuring the Sparc10 as an end >node, and no luck there either. > >Alas. > >Is this problem similar to yours? > >-- >Darren Loher University of North Texas >darren@unt.edu Datacommunications 817-565-4168 > > We have being running with the IP multicast patches released last June on a number of Sparc10/30's and have not noticed any problems. Are you using the same release? -- Fengmin Gong E-mail: gong@concert.net Network Research Engineer Phone: 919 248-9214 MCNC Information Technologies FAX: 919 248-1405 From rem-conf-request@es.net Thu Feb 03 17:35:31 1994 Received: from merit.edu by osi-west.es.net via ESnet SMTP service id <20125-0@osi-west.es.net>; Thu, 3 Feb 1994 14:34:58 +0000 Received: from localhost (ljb@localhost) by merit.edu (8.6.5/8.6.5) with SMTP id RAA08177; Thu, 3 Feb 1994 17:34:46 -0500 Message-Id: <199402032234.RAA08177@merit.edu> X-Authentication-Warning: merit.edu: Host localhost didn't use HELO protocol X-Authentication-Warning: merit.edu: ljb owned process doing -bs To: Darren Paul Loher cc: Nam Cho , rem-conf@es.net Subject: Re: Multicast on sun4m kernal ? In-reply-to: Your message of "Thu, 03 Feb 1994 14:18:20 CST." Date: Thu, 03 Feb 1994 17:34:45 -0500 From: "Larry J. Blunk" > On Thu, 3 Feb 1994, Nam Cho wrote: > > > Hello, > > > > Has anyone had success in appling the ipmulti patches to a sun4m kernal ? > > (SunOS4.1.3) running on a Sparc10 ? > > > > Tried to install it, but without good results. > > The kernal runs fine, I'm running it right now, mrouted runs fine, and > will tunnel ip multicast fine. However, I cannot get sd nor any other > tool to see ongoing sessions of the mbone. Yet, sites that our Sparc10 > tunnels to are working fine. We tried configuring the Sparc10 as an end > node, and no luck there either. > > Alas. > > Is this problem similar to yours? > Which version of the ip multicast release are you using? I've seen these problems with the 1.0 release. The 2.0 release fixed them. -Larry Blunk Merit Network, Inc. From rem-conf-request@es.net Thu Feb 03 18:04:22 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <20596-0@osi-west.es.net>; Thu, 3 Feb 1994 15:03:37 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Thu, 3 Feb 1994 15:03:32 -0800 Posted-Date: Thu 3 Feb 94 15:02:30 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 3 Feb 94 15:02:32 PST Date: Thu 3 Feb 94 15:02:30 PST From: Stephen Casner Subject: Re: Multicast on sun4m kernal ? To: darren@unt.edu, ncho@csdc.com Cc: rem-conf@es.net Message-Id: <760316550.0.CASNER@XFR.ISI.EDU> In-Reply-To: Mail-System-Version: I believe many people are successfully running the ipmulti patches in 4.1.3 on sun4m Sparc10. Several machines at ISI run this. You say you cannot get sd or any tool to see ongoing sessions on the MBone, but that machines at the site on the other end of the tunnel are working fine. Have you tried manually invoking vat on some multicast address on machines at both ends of your tunnel, and if so, can those vats see each other? My guess would be that this would not work either. I suspect that your tunnel is not really working, even though it may appear to be up. Sometimes a tunnel can be half up. You might also have a problem with some sort of packet filtering along the path of the tunnel that is not allowing the data packets to pass. Or, if one end of the tunnel is configured as "srcrt" and the other is not, the tunnel will appear to be up, but data will only flow in one direction (I forget which). -- Steve ------- From rem-conf-request@es.net Thu Feb 03 18:10:36 1994 Received: from rpi.edu by osi-west.es.net via ESnet SMTP service id <20694-0@osi-west.es.net>; Thu, 3 Feb 1994 15:09:50 +0000 Received: from client.its.rpi.edu (ryoohki.its.rpi.edu) by rpi.edu (4.1/SMHUB41); id AA24783; Thu, 3 Feb 94 18:09:42 EST for rem-conf@es.net Received: from rpi.edu (localhost.rpi.edu) by client.its.rpi.edu (4.1/SUB16); id AA18092; Thu, 3 Feb 94 17:14:54 EST for rem-conf@es.net Message-Id: <9402032214.AA18092@client.its.rpi.edu> To: Darren Paul Loher Cc: Nam Cho , rem-conf@es.net Subject: Re: Multicast on sun4m kernal ? In-Reply-To: Your message of "Thu, 03 Feb 1994 14:18:20 CST." X-Mailer: exmh version 1.2delta 1/6/94 Date: Thu, 03 Feb 1994 17:14:49 EST From: Scanner > Tried to install it, but without good results. Curious. I believe quite a few people do indeed have it running on an SS10, 4.1.3 (I am one of them.. Xerox PARC has them also..) --Scanner (scanner@rpi.edu) From rem-conf-request@es.net Thu Feb 03 19:28:53 1994 Received: from brolga.cc.uq.oz.au by osi-west.es.net via ESnet SMTP service id <21728-0@osi-west.es.net>; Thu, 3 Feb 1994 16:28:02 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Fri, 4 Feb 1994 10:27:13 +1000 To: R.Cogger@cornell.edu (Richard Cogger) cc: rem-conf@osi-west.es.net, cu-seeme-l@cornell.edu Subject: Re: CU-SeeMe0.60b1 In-reply-to: Your message of "Thu, 03 Feb 1994 16:59:28 EST." <199402032156.QAA24978@mitchell.cit.cornell.edu> X-Mailer: exmh version 1.3alpha 1/28/94 Date: Fri, 04 Feb 1994 10:27:04 +1000 Message-ID: <11640.760321624@brolga.cc.uq.oz.au> From: George Michaelson Without any intent to chastise or criticize authors of packages, could you consider prioritizing codework to ensure clean interop with existing deployed systems such as the NV/IVS imaging tools? We definately want to interop multicast/multimedia with macintoshes but we don't want to deploy multiple isolated pools of protocols. A one-way reflector is only of limited use, we would love bi-directional flow with NV/IVS! -George From rem-conf-request@es.net Thu Feb 03 21:50:21 1994 Received: from itd.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <23127-0@osi-west.es.net>; Thu, 3 Feb 1994 18:49:55 +0000 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA01364; Thu, 3 Feb 94 21:49:50 EST Date: Thu, 3 Feb 94 21:49:50 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9402040249.AA01364@itd.nrl.navy.mil> To: rem-conf@es.net Subject: Multicast on Sun4m We have several SS10/30s running 4.1.3 with the IP Multicast mods from about June 1993 working just fine. They installed easily and worked "out of the box" as they say. One of these machines is our mrouted(8) system and has not only the standard Ethernet interface but also a Network Peripherals Dual-Attach FDDI interface. It supports IP Multicast on both interfaces. Ran atkinson@itd.nrl.navy.mil PS I'm looking for recommendations on (not terribly expensive) S-bus video boards and small color cameras for use with the above SS10s running 4.1.3 Multicast. Must be nv compatible. Please email me privately with responses and I'll post a short summary in a week or so. Or is there a FAQ on this subject that I missed ? From rem-conf-request@es.net Thu Feb 03 22:36:59 1994 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by osi-west.es.net via ESnet SMTP service id <23346-0@osi-west.es.net>; Thu, 3 Feb 1994 19:36:18 +0000 Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU) by postoffice3.mail.cornell.edu with SMTP id AA15421 (5.67a/IDA-1.5 for ); Thu, 3 Feb 1994 22:36:12 -0500 Message-Id: <199402040336.AA15421@postoffice3.mail.cornell.edu> X-Sender: swb1@postoffice3.mail.cornell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Feb 1994 22:35:57 -0500 To: rem-conf@osi-west.es.net, cu-seeme-l@cornell.edu From: Scott W Brim Subject: Re: CU-SeeMe0.60b1 George, I've thought about this a lot, having been on both sides of this issue several times. I believe that when an area is young, and when the possibilities are unknown -- which is how one must characterize desktop conferencing -- that it is a Just Fine for people to venture off into incompatible spaces for a while. We are all learning a lot from the different behaviors of the available tools. Interoperability is a good thing, but in this case I firmly believe that discovery is just as important. Having said that, I'll admit that RTP and a two-way reflector are on the horizon. ...Scott At 19:29 2/3/94 -0500, George Michaelson wrote: >Without any intent to chastise or criticize authors of packages, could >you consider prioritizing codework to ensure clean interop with >existing deployed systems such as the NV/IVS imaging tools? >We definately want to interop multicast/multimedia with macintoshes >but we don't want to deploy multiple isolated pools of protocols. A >one-way reflector is only of limited use, we would love >bi-directional flow with NV/IVS! >George From rem-conf-request@es.net Fri Feb 04 05:03:12 1994 Received: from cs.tut.fi by osi-west.es.net via ESnet SMTP service id <25690-0@osi-west.es.net>; Fri, 4 Feb 1994 02:02:51 +0000 Received: from isosotka.cs.tut.fi (isosotka.cs.tut.fi [130.230.5.14]) by cs.tut.fi (8.6.4/8.6.4) with SMTP id MAA01927; Fri, 4 Feb 1994 12:01:23 +0200 Received: by isosotka.cs.tut.fi id AA06568 (5.65c/IDA-1.4.4 for darren@unt.edu); Fri, 4 Feb 1994 12:00:15 +0200 Date: Fri, 4 Feb 1994 12:00:15 +0200 From: Mikko Tsokkinen Message-Id: <199402041000.AA06568@isosotka.cs.tut.fi> To: Scanner Cc: Darren Paul Loher , Nam Cho , rem-conf@es.net Subject: Re: Multicast on sun4m kernal ? In-Reply-To: <9402032214.AA18092@client.its.rpi.edu> References: <9402032214.AA18092@client.its.rpi.edu> Scanner writes: >> Tried to install it, but without good results. > >Curious. I believe quite a few people do indeed have it running >on an SS10, 4.1.3 (I am one of them.. Xerox PARC has them also..) > >--Scanner (scanner@rpi.edu) I have SS10/40 running version 3.1 patchlevel 1 and it used to be version 1.4. Both work/worked fine. -- Cheers Mikko Tsokkinen xxxxx Mit "I do not fear computers. I fear the lack of them." From rem-conf-request@es.net Fri Feb 04 07:22:23 1994 Received: from cs.tut.fi by osi-west.es.net via ESnet SMTP service id <26684-0@osi-west.es.net>; Fri, 4 Feb 1994 04:21:55 +0000 Received: from isosotka.cs.tut.fi (isosotka.cs.tut.fi [130.230.5.14]) by cs.tut.fi (8.6.4/8.6.4) with SMTP id OAA03672 for ; Fri, 4 Feb 1994 14:22:15 +0200 Received: by isosotka.cs.tut.fi id AA08654 (5.65c/IDA-1.4.4 for rem-conf@es.net); Fri, 4 Feb 1994 14:25:43 +0200 Date: Fri, 4 Feb 1994 14:25:43 +0200 From: Mikko Tsokkinen Message-Id: <199402041225.AA08654@isosotka.cs.tut.fi> To: rem-conf@es.net Subject: VideoPix vs XVideo speed with nv I made some measurements on Parallax XVideo and Sun VideoPix framegrabber framerates with static NTSC and PAL video signal using mbone tool 'nv'. Unfortunately 'nv' does not support Sun SunVideo card so it is left out of the chart untill situation gets better Both XVideo and VideoPix were attached to SunIPX running SunOS4.1.3 and the framebuffer used was tv2 (8bit pseudocolor, nv used 24bit truecolor visual). The receiver was SunIPX running Solaris2.3 with GX framebuffer (8bit pseudocolor). Both machines were running OpenWindows server and olvwm window manager. Machines were connected to each other with regular Ethernet in same non-busy segment. There were no missed packets. The 'nv' used was version '3.3alpha' and was downloaded as a binary from ftpparc. Same binary was used in both machines. The video signal was static white from PAL Panasonic Palmcorder, the NTSC signal was generated from camera signal with Panasonic NW-1 "World Standard" Videorecorder. The numbers below mean "frames per second" as reported by 'nv', first with color images and in brackets greyscale. Local means normal sized local monitor. No local means the speed is reported only in the receiver end. PAL color (greyscale) NTSC color (greyscale) local no local local no local XVideo 2.8 (3.7) 3.6 (5.4) 3.7 (5.3) 4.9 (7.2) VideoPix 3.1 (3.6) 4.1 (4.8) 3.7 (4.3) 5.0 (6.0) Notes: - As seen the performance is very similar between the boards - NTSC is faster because the frame size is smaller. - Motion speed was left out of the charts because it is hard to measure accurately. - XVideo card has JPEG-compress engine which is not used with 'nv', with it special applications speed is totally different from these values, nearing full motion (25 fps PAL). Also the XVideo shows full motion local display. - XVideo card grabs both odd and even fields which causes motion in static images because 'nv' sends odd and even fields next to each other which causes worse speed due to 'nv' encoding non-existing motion in static images where odd and even fields differ (all regular signals). I hope this can be fixed either in 'XVideo' and/or 'nv' sofware. This causes Parallax to perform worse than VideoPix in regular situation. PS: - I also found a bug in 'nv3.3alpha', if you change framegrabber board it "forgets" the 'send greyscale' option. -- Cheers Mikko Tsokkinen xxxxx Mit "I do not fear computers. I fear the lack of them." From rem-conf-request@es.net Fri Feb 04 08:45:19 1994 Received: from bronze.ucs.indiana.edu by osi-west.es.net via ESnet SMTP service id <27178-0@osi-west.es.net>; Fri, 4 Feb 1994 05:45:01 +0000 Original-Received: by bronze.ucs.indiana.edu PP-warning: Illegal Received field on preceding line Date: Fri, 4 Feb 1994 08:44:39 -0500 (EST) From: Allen Robel Subject: When ( GMT/UTC offset) will these presentations occur? To: G.Joly@cs.ucl.ac.uk Cc: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, You said: > Feb 8 14.00 UCL Toshikazu Kato (ETL/MITI) will speak on > > Human Media Technology - New Perspectives on Human-Media Interaction > > Feb 22 14.00 Bruno Struif (GMD) - Electronic Prescription Are the times given local times in the UK? If so, what offset are you with respect to GMT/UTC? many thanks, Allen Robel UCS Network Systems robelr@indiana.edu From rem-conf-request@es.net Fri Feb 04 09:45:20 1994 Received: from aquarius.rutgers.edu by osi-west.es.net via ESnet SMTP service id <27656-0@osi-west.es.net>; Fri, 4 Feb 1994 06:44:53 +0000 Received: by aquarius.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01873; Fri, 4 Feb 94 09:44:50 EST Date: Fri, 4 Feb 94 09:44:50 EST From: azia@aquarius.rutgers.edu (Ashar Zia) Message-Id: <9402041444.AA01873@aquarius.rutgers.edu> To: rem-conf@es.net Subject: nv3.3alpha Hi, This is regarding your recent posting in rem-conf@es.net. You said that you have got nv3.3alpha from parcftp. Well I just tried to ftp the 3.3 release of nv from "parcftp.xerox.com". And in the directory for nv i.e. /pub/net-research, all I could find was the 3.2 release. Can you give a pointer to where I could find the 3.3 release. I am posting it in rem-conf so that others might also benefit from this info. Thanx. -Ashar azia@aquarius.rutgers.edu From rem-conf-request@es.net Fri Feb 04 10:07:30 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <27881-0@osi-west.es.net>; Fri, 4 Feb 1994 07:06:55 +0000 Received: from rover.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 4 Feb 1994 15:06:29 +0000 To: mbone@ISI.EDU, rem-conf@es.net Subject: MICE International Seminars in February 1994. Date: Fri, 04 Feb 94 15:06:23 +0000 From: Gordon Joly Reposted: please note that times are in GMT/UTC. This is a regular series, currently every two weeks. Please limit traffic on Tuesday 8 and 22 February. NASA STS-60 admin have been contacted. ----------------------- Feb 8 14.00 (GMT) UCL Toshikazu Kato (ETL/MITI) will speak on Human Media Technology - New Perspectives on Human-Media Interaction Feb 22 14.00 (GMT) Bruno Struif (GMD) - Electronic Prescription It is to be transmitted on the usual multicast addresses: vat 224.5.17.12/3456 ivs 224.5.17.12/2232 wb 224.5.17.12/32416 and advertised in "sd". Further information is kept in the URL http://www.cs.ucl.ac.uk/mice/seminars.html Gordon Joly Phone +44 71 380 7777 3703 FAX +44 71 387 1397 Email: G.Joly@cs.ucl.ac.uk UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly Comp Sci, University College London, Gower Street, LONDON WC1E 6BT WWW:- http://www.cs.ucl.ac.uk/mice/gjoly.html -:WWW From rem-conf-request@es.net Fri Feb 04 11:13:25 1994 Received: from tutuila.gsfc.nasa.gov by osi-west.es.net via ESnet SMTP service id <28675-0@osi-west.es.net>; Fri, 4 Feb 1994 08:12:47 +0000 Received: by tutuila.gsfc.nasa.gov (930416.SGI/930416.SGI.AUTO) for rem-conf@es.net id AA18611; Fri, 4 Feb 94 11:21:02 -0500 From: gene carl feldman Message-Id: <9402041120.ZM18609@tutuila.gsfc.nasa.gov> Date: Fri, 4 Feb 1994 11:20:57 -0500 X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: mbone@ISI.EDU, rem-conf@es.net Subject: Request for Information: JASON Project Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Greetings, There is a real possibility that for selected periods during this year's JASON Project expedition to the rain forests, caverns, Mayan Ruins and coral reefs of Belize (Central America), that we might be able to actually try to have some real-time interactions (video and audio) over the mbone. From 1300-0100 GMT between February 28 - March 11 we should have a 56k satellite link to the Internet. I will be taking an SGI Indy workstation with me and would like to see what can be done. I presently use nv, sd and vat with great success. However, I am a bit concerned about the bandwidth limitations that are going to be available in the jungle. I would appreciate any advice as to exactly what configuration (i.e. vat settings) that would offer the best performance. If it works, I believe it could be a really interesting experience for all involved. Thanks for the help. regards, gene feldman nasa/goddard space flight center gene@manono.gsfc.nasa.gov From rem-conf-request@es.net Fri Feb 04 12:21:16 1994 Received: from crusher.concert.net by osi-west.es.net via ESnet SMTP service id <00130-0@osi-west.es.net>; Fri, 4 Feb 1994 09:20:57 +0000 Received: by crusher.concert.net (5.59/tas-concert/6-19-91) id AA22557; Fri, 4 Feb 94 12:20:32 -0500 From: Fengmin Gong Message-Id: <9402041720.AA22557@crusher.concert.net> Subject: Re: nv3.3alpha To: azia@aquarius.rutgers.edu (Ashar Zia) Date: Fri, 4 Feb 1994 12:20:32 -0500 (EST) Cc: rem-conf@es.net In-Reply-To: <9402041444.AA01873@aquarius.rutgers.edu> from "Ashar Zia" at Feb 4, 94 09:44:50 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 699 Ashar Zia wrote earlier: > >Hi, > This is regarding your recent posting in rem-conf@es.net. You said that you >have got nv3.3alpha from parcftp. Well I just tried to ftp the 3.3 release of >nv from "parcftp.xerox.com". And in the directory for nv i.e. /pub/net-research, >all I could find was the 3.2 release. Can you give a pointer to where I could >find the 3.3 release. > I am posting it in rem-conf so that others might also benefit from this info. >Thanx. >-Ashar >azia@aquarius.rutgers.edu > Look under /pub/net-research/exp and you can'nt miss it. -- Fengmin Gong E-mail: gong@concert.net Network Research Engineer Phone: 919 248-9214 MCNC Information Technologies FAX: 919 248-1405 From rem-conf-request@es.net Fri Feb 04 12:31:36 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <00335-0@osi-west.es.net>; Fri, 4 Feb 1994 09:31:16 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 4 Feb 1994 17:30:56 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: gene carl feldman cc: rem-conf@es.net Subject: Re: Request for Information: JASON Project In-reply-to: Your message of "Fri, 04 Feb 94 11:20:57 EST." <9402041120.ZM18609@tutuila.gsfc.nasa.gov> Date: Fri, 04 Feb 94 17:30:44 +0000 Sender: M.Handley@cs.ucl.ac.uk >I will be taking an SGI Indy workstation with me and would like to see what ca >be done. I presently use nv, sd and vat with great success. However, I am a b >concerned about the bandwidth limitations that are going to be available in th >jungle. I would appreciate any advice as to exactly what configuration (i.e. >vat settings) that would offer the best performance. Sounds really interesting. I would suggest that you use GSM encoding and substitute IVS for nv, as this works pretty well (especially in QCIF mode) down around the 20-30Kb/s you'll have to use. Mark From rem-conf-request@es.net Fri Feb 04 13:03:07 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <01097-0@osi-west.es.net>; Fri, 4 Feb 1994 10:02:31 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14985(4)>; Fri, 4 Feb 1994 10:02:24 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16143>; Fri, 4 Feb 1994 10:02:21 -0800 To: azia@aquarius.rutgers.edu (Ashar Zia) cc: rem-conf@es.net Subject: Re: nv3.3alpha In-reply-to: Your message of "Fri, 04 Feb 94 06:44:50 PST." <9402041444.AA01873@aquarius.rutgers.edu> X-Mailer: exmh version 1.3alpha 2/1/94 Date: Fri, 4 Feb 1994 10:02:06 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Feb4.100221pst.16143@ecco.parc.xerox.com> In message <9402041444.AA01873@aquarius.rutgers.edu> you write: > This is regarding your recent posting in rem-conf@es.net. You said that you > have got nv3.3alpha from parcftp. Well I just tried to ftp the 3.3 release of > nv from "parcftp.xerox.com". And in the directory for nv, /pub/net-research, > all I could find was the 3.2 release. Can you give a pointer to where I could > find the 3.3 release. > I am posting it in rem-conf so that others might also benefit from this info. Please note that the nv 3.3alpha release is an ALPHA release for a reason. I am not being at all careful about marking new versions of the alpha when I make them or making general announcements about it. There are several things in this release which are unfinished, and some things you see in this release may not be present in the final one, at least in the same form. If you do decide to grab the alpha release and compile it (I'm not providing any binaries at this time), I am happy to accept bug reports. However, I ask that you not install this release for general use at your site, and that you destroy all copies of whatever version you have once I announce the final version. To discourage casual grabbing of this release, I have moved it out of the /pub/net-research directory and into /pub/net-research/exp (experimental), with no pointers left behind. Unlike the official source releases, this tar file doesn't contain any documentation or other similar support files. It is really just a drop-off point for when I'm working with someone who is testing a hardware configuration I don't have access to myself. I apologize for the long time it is taking me to finalize this release. Between other projects and the large number of additional systems and video grabbers which have appeared since 3.2, the logistics of getting it finished and tested have been more difficult than I anticipated. Please bear with me and I'll get out the final version as soon as I can. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Fri Feb 04 13:21:55 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <01516-0@osi-west.es.net>; Fri, 4 Feb 1994 10:21:17 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <15030(7)>; Fri, 4 Feb 1994 10:21:06 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16143>; Fri, 4 Feb 1994 10:20:53 -0800 To: Mikko Tsokkinen cc: rem-conf@es.net Subject: Re: VideoPix vs XVideo speed with nv In-reply-to: Your message of "Fri, 04 Feb 94 04:25:43 PST." <199402041225.AA08654@isosotka.cs.tut.fi> X-Mailer: exmh version 1.3alpha 2/1/94 Date: Fri, 4 Feb 1994 10:20:38 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Feb4.102053pst.16143@ecco.parc.xerox.com> In message <199402041225.AA08654@isosotka.cs.tut.fi> you write: > - XVideo card grabs both odd and even fields which causes motion > in static images because 'nv' sends odd and even fields next to each > other which causes worse speed due to 'nv' encoding non-existing > motion in static images where odd and even fields differ (all regular > signals). I hope this can be fixed either in 'XVideo' and/or 'nv' > sofware. This causes Parallax to perform worse than VideoPix in regular > situation. > It sounds like the binary you have is based on a very early version of the Parallax grabber, before we were able to work around the problem that the Parallax has with scaling down live video images. The latest version of the grabber uses still frame grabs in the "Local camera" window. This does slow down the frame rate somewhat for non-moving sources, I believe, but it greatly improves the compression ratio on moving images and eliminates the annoying picture "wobble" that used to be present. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Fri Feb 04 13:31:06 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <00948-0@osi-west.es.net>; Fri, 4 Feb 1994 09:59:24 +0000 Received: from reynaldo.parc.xerox.com ([13.2.116.96]) by alpha.xerox.com with SMTP id <14978(6)>; Fri, 4 Feb 1994 09:59:07 PST Received: from localhost by reynaldo.parc.xerox.com with SMTP id <25548>; Fri, 4 Feb 1994 09:58:56 -0800 To: Allen Robel cc: G.Joly@cs.ucl.ac.uk, rem-conf@es.net, kerch@parc.xerox.com Subject: Re: When ( GMT/UTC offset) will these presentations occur? In-reply-to: Your message of "Fri, 04 Feb 94 05:44:39 PST." X-Mailer: exmh version 1.3alpha 2/3/94 Date: Fri, 4 Feb 1994 09:58:50 PST Sender: Berry Kercheval From: Berry Kercheval Message-Id: <94Feb4.095856pst.25548@reynaldo.parc.xerox.com> In message you wri te: >Are the times given local times in the UK? If so, what offset are you >with respect to GMT/UTC? Gee, I always thought that the UK offset to GMT was zero! From rem-conf-request@es.net Fri Feb 04 14:20:18 1994 Received: from sics.se by osi-west.es.net via ESnet SMTP service id <03027-0@osi-west.es.net>; Fri, 4 Feb 1994 11:19:25 +0000 Received: from sicsmac8A.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA03116; Fri, 4 Feb 94 20:18:26 +0100 Message-Id: <9402041918.AA03116@sics.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 4 Feb 1994 20:19:05 +0100 To: Berry Kercheval , Allen Robel From: hans@sics.se (Hans Eriksson) Subject: Re: When ( GMT/UTC offset) will these presentations occur? Cc: G.Joly@cs.ucl.ac.uk, rem-conf@es.net, kerch@parc.xerox.com At 09.58 94-02-04 -0800, Berry Kercheval wrote: >Gee, I always thought that the UK offset to GMT was zero! GMT never has daylight savimngs time. UK has... UK winter time = GMT, UK summer time = GMT + 0100 /hans From rem-conf-request@es.net Fri Feb 04 16:30:27 1994 Received: from relay.nswc.navy.mil by osi-west.es.net via ESnet SMTP service id <04825-0@osi-west.es.net>; Fri, 4 Feb 1994 13:30:03 +0000 Received: from sunoco.nswc.navy.mil by relay.nswc.navy.mil (4.1/SMI-4.1) id AA27265; Fri, 4 Feb 94 16:29:50 EST Received: from vaxless.b35ita.sunoco by sunoco.nswc.navy.mil (5.0/SMI-SVR4) id AA00779; Fri, 4 Feb 1994 16:26:50 +0500 Received: by vaxless.b35ita.sunoco (5.0/SMI-SVR4) id AA00882; Fri, 4 Feb 1994 16:26:47 +0500 Date: Fri, 4 Feb 1994 16:26:47 +0500 From: pirey%sunoco@relay.nswc.navy.mil (Phil Irey) Message-Id: <9402042126.AA00882@vaxless.b35ita.sunoco> To: rem-conf@es.net Subject: Hardware Multicast support X-Sun-Charset: US-ASCII Content-Length: 720 I am interested in getting information about the number of multicast addresses which can be registered in hardware for typical workstations with interfaces that support multicast. For example, how many hardware multicast addresses can be registered on a Sparcstation 10 with FDDI/DX card? Assuming that the registration of multiple addresses in hardware is available, is this generally used or do stations run in "promiscious mode" or "receive all multicasts" mode? Stations of interest are: Sun workstations with ethernet and FDDI cards Silicon Graphics workstations with ethernet and FDDI cards HP 9000 Series 700 workstations with ethernet and FDDI cards thanks in advance, phil irey (pirey@relay.nswc.navy.mil) From rem-conf-request@es.net Fri Feb 04 21:57:42 1994 Received: from Sun.COM by osi-west.es.net via ESnet SMTP service id <09183-0@osi-west.es.net>; Fri, 4 Feb 1994 18:57:13 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA29843; Fri, 4 Feb 94 18:57:08 PST Received: from jurassic.Eng.Sun.COM (jurassic-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA24521; Fri, 4 Feb 94 18:57:25 PST Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.0/SMI-SVR4) id AA14173; Fri, 4 Feb 1994 18:57:02 +0800 Received: by kandinsky.Eng.Sun.COM (5.0/SMI-SVR4) id AA04415; Fri, 4 Feb 1994 18:53:55 +0800 Date: Fri, 4 Feb 1994 18:53:55 +0800 From: Bob.Gilligan@Eng.Sun.COM (Bob Gilligan) Message-Id: <9402050253.AA04415@kandinsky.Eng.Sun.COM> To: rem-conf@es.net Subject: Unicast vat on Solaris 2.3 Cc: Bob.Gilligan@Eng.Sun.COM Content-Length: 549 A few people on the MBone recently discovered that "vat" does not work in unicast mode on Solaris 2.3 (it works fine in multicast mode). We are working on a fix for this problem for the next Solaris release. In the mean time, I have put together a simple work around for the problem. Anyone who would like to experiment with unicast "vat" on Solaris 2.3 can FTP the work around from "playground.sun.com". It is in the tar file "pub/solaris2/unicast-vat-workaround.tar". Bob Gilligan SunSoft Internet Engineering Group bob.gilligan@eng.sun.com From rem-conf-request@es.net Sat Feb 05 00:38:02 1994 Received: from exxilon.xx.rmit.EDU.AU by osi-west.es.net via ESnet SMTP service id <10197-0@osi-west.es.net>; Fri, 4 Feb 1994 21:37:42 +0000 Received: from localhost (richard@localhost) by exxilon.xx.rmit.EDU.AU (8.6.5/8.6.4/ram3) id QAA25436; Sat, 5 Feb 1994 16:40:34 +1100 From: "Richard A. Muirden" Message-Id: <199402050540.QAA25436@exxilon.xx.rmit.EDU.AU> Subject: Re: Request for Information: JASON Project To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Sat, 5 Feb 1994 16:40:34 +1100 (EDT) Cc: gene@tutuila.gsfc.nasa.gov, rem-conf@es.net In-Reply-To: <9402041938.AA04494@wraith.internode.com.au> from "Mark Handley" at Feb 4, 94 05:30:44 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 813 > Sounds really interesting. I would suggest that you use GSM encoding and > substitute IVS for nv, as this works pretty well (especially in QCIF mode) > down around the 20-30Kb/s you'll have to use. Small problem there: The IVS port for the Indy isn't done yet. You can receive fine, but can't send *pout* I believe the port isn't done because SGI hasn't released (finalised?) the VL code for the Indy/irix 5.1.1.x ... (or because the IVS team don't have access to a development Indy) > Mark -richard -- Richard A. Muirden, Systems Administrator | I love Shostakovich and Trek yes, RMIT Computer Centre richard@rmit.EDU.AU | but I love my dearest darling most P. O. Box 2476V +61 3 660 3814 | wonderful Heather far, far more... Melbourne 3000 Australia | and always...... From rem-conf-request@es.net Mon Feb 07 05:12:56 1994 Received: from sun2.mhs-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <28337-0@osi-west.es.net>; Mon, 7 Feb 1994 02:12:36 +0000 Via: uk.ac.edinburgh.castle; Mon, 7 Feb 1994 10:11:43 +0000 Received: from ucs.ed.ac.uk by castle.ed.ac.uk id aa26958; 7 Feb 94 10:11 GMT Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Mon, 7 Feb 94 10:11:28 GMT Date: Mon, 7 Feb 94 10:11:07 GMT Message-Id: <8636.9402071011@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: VideoPix vs XVideo speed with nv To: Ron Frederick , Mikko Tsokkinen In-Reply-To: Ron Frederick's message of Fri, 4 Feb 1994 10:20:38 PST Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Phone: +44 (0)31 650 5003 X-Fax: +44 (0)31 662 4712 Cc: rem-conf@es.net > In message <199402041225.AA08654@isosotka.cs.tut.fi> you write: > > - XVideo card grabs both odd and even fields which causes motion > > in static images because 'nv' sends odd and even fields next to each > > other which causes worse speed due to 'nv' encoding non-existing > > motion in static images where odd and even fields differ (all regular > > signals). I hope this can be fixed either in 'XVideo' and/or 'nv' > > sofware. This causes Parallax to perform worse than VideoPix in regular > > situation. > > > It sounds like the binary you have is based on a very early version of the > Parallax grabber, before we were able to work around the problem that the > Parallax has with scaling down live video images. The latest version of the > grabber uses still frame grabs in the "Local camera" window. This does slow > down the frame rate somewhat for non-moving sources, I believe, but it > greatly improves the compression ratio on moving images and eliminates the > annoying picture "wobble" that used to be present. The unfortunate side-effect of this is though, that you have to keep the "Local camera" window unobscured at all times otherwise you end up sending out either a blank screen or bits of your display overlayed on top of the video image. From rem-conf-request@es.net Mon Feb 07 08:28:59 1994 Received: from crusher.concert.net by osi-west.es.net via ESnet SMTP service id <29442-0@osi-west.es.net>; Mon, 7 Feb 1994 05:28:43 +0000 Received: by crusher.concert.net (5.59/tas-concert/6-19-91) id AA24072; Mon, 7 Feb 94 08:27:45 -0500 From: Fengmin Gong Message-Id: <9402071327.AA24072@crusher.concert.net> Subject: Re: VideoPix vs XVideo speed with nv To: Graeme.Wood@edinburgh.ac.uk Date: Mon, 7 Feb 1994 08:27:44 -0500 (EST) Cc: frederic@parc.xerox.com, mit@cs.tut.fi, rem-conf@es.net In-Reply-To: <8636.9402071011@scorpio.ucs.ed.ac.uk> from "Graeme Wood" at Feb 7, 94 10:11:07 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1724 Graeme Wood wrote earlier: > >> In message <199402041225.AA08654@isosotka.cs.tut.fi> you write: >> > - XVideo card grabs both odd and even fields which causes motion >> > in static images because 'nv' sends odd and even fields next to each >> > other which causes worse speed due to 'nv' encoding non-existing >> > motion in static images where odd and even fields differ (all regular >> > signals). I hope this can be fixed either in 'XVideo' and/or 'nv' >> > sofware. This causes Parallax to perform worse than VideoPix in regular >> > situation. >> > >> It sounds like the binary you have is based on a very early version of the >> Parallax grabber, before we were able to work around the problem that the >> Parallax has with scaling down live video images. The latest version of the >> grabber uses still frame grabs in the "Local camera" window. This does slow >> down the frame rate somewhat for non-moving sources, I believe, but it >> greatly improves the compression ratio on moving images and eliminates the >> annoying picture "wobble" that used to be present. > >The unfortunate side-effect of this is though, that you have to keep the >"Local camera" window unobscured at all times otherwise you end up >sending out either a blank screen or bits of your display overlayed on >top of the video image. > Could explain what do you mean by "side-effect of this"? As far as I know, the problem of insisting on "Local camera" to be exposed to grab the correct video image is with XVideo design and it has nothing to do with how nv3.3alpha grabs its image. -- Fengmin Gong E-mail: gong@concert.net Network Research Engineer Phone: 919 248-9214 MCNC Information Technologies FAX: 919 248-1405 From rem-conf-request@es.net Mon Feb 07 09:02:52 1994 Received: from relay2.nswc.navy.mil by osi-west.es.net via ESnet SMTP service id <29728-0@osi-west.es.net>; Mon, 7 Feb 1994 06:02:22 +0000 Received: from galaxy.nswc.navy.mil by relay2.nswc.navy.mil (4.1/SMI-4.1) id AA03580; Mon, 7 Feb 94 09:02:14 EST Received: from rigel.galaxy (rigel.nswc.navy.mil) by galaxy.nswc.navy.mil (4.1/SMI-4.1) id AA02924; Mon, 7 Feb 94 09:02:11 EST Date: Mon, 7 Feb 94 09:02:11 EST From: wking@relay.nswc.navy.mil (Lawton King - E81) Message-Id: <9402071402.AA02924@galaxy.nswc.navy.mil> To: rem-conf-request@es.net Subject: subscribe rem-conf Cc: rem-conf@es.net subscribe rem-conf thank you - Lawton King (wking@relay.nswc.navy.mil) From rem-conf-request@es.net Mon Feb 07 09:26:41 1994 Received: from bnl.gov by osi-west.es.net via ESnet SMTP service id <29907-0@osi-west.es.net>; Mon, 7 Feb 1994 06:26:01 +0000 Received: by bnl.gov (5.57/Ultrix3.0-C) id AA04260; Mon, 7 Feb 94 07:00:33 -0500 Received: by sirius.ccd.bnl.gov (930416.SGI/930416.SGI) for @bnl.gov:rem-conf@es.net id AA02199; Mon, 7 Feb 94 09:25:18 -0500 From: Graham Campbell Message-Id: <9402070925.ZM2197@sirius.ccd.bnl.gov> Date: Mon, 7 Feb 1994 09:25:17 -0500 In-Reply-To: Graeme Wood "Re: VideoPix vs XVideo speed with nv" (Feb 7, 10:11am) References: <8636.9402071011@scorpio.ucs.ed.ac.uk> Reply-To: gc@bnl.gov X-Mailer: Z-Mail (3.0B.0 25aug93 MediaMail) To: Graeme.Wood@edinburgh.ac.uk, Ron Frederick , Mikko Tsokkinen Subject: Re: VideoPix vs XVideo speed with nv Cc: rem-conf@es.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Feb 7, 10:11am, Graeme Wood wrote: > Subject: Re: VideoPix vs XVideo speed with nv ................................ > > The unfortunate side-effect of this is though, that you have to keep the > "Local camera" window unobscured at all times otherwise you end up > sending out either a blank screen or bits of your display overlayed on > top of the video image. >-- End of excerpt from Graeme Wood This might even be viewed as a feature. Our only experience with the Parallax board is using Communique!, which has the same characteristic. We have discovered that overlaying the local window with another window (e.g. output of a graphical display program) is a quick and easy way to transmit the other window. -- Graham gc@bnl.gov From rem-conf-request@es.net Mon Feb 07 10:42:27 1994 Received: from sun2.mhs-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <01094-0@osi-west.es.net>; Mon, 7 Feb 1994 07:42:04 +0000 Via: uk.ac.edinburgh.castle; Mon, 7 Feb 1994 15:41:53 +0000 Received: from ucs.ed.ac.uk by castle.ed.ac.uk id aa20817; 7 Feb 94 15:41 GMT Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Mon, 7 Feb 94 15:41:43 GMT Date: Mon, 7 Feb 94 15:41:21 GMT Message-Id: <467.9402071541@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: VideoPix vs XVideo speed with nv To: gc@bnl.gov, Graeme.Wood@edinburgh.ac.uk, Ron Frederick , Mikko Tsokkinen In-Reply-To: Graham Campbell's message of Mon, 7 Feb 1994 09:25:17 -0500 Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Phone: +44 (0)31 650 5003 X-Fax: +44 (0)31 662 4712 Cc: rem-conf@es.net > On Feb 7, 10:11am, Graeme Wood wrote: > > Subject: Re: VideoPix vs XVideo speed with nv > ................................ > > > > The unfortunate side-effect of this is though, that you have to keep the > > "Local camera" window unobscured at all times otherwise you end up > > sending out either a blank screen or bits of your display overlayed on > > top of the video image. > >-- End of excerpt from Graeme Wood > > This might even be viewed as a feature. Our only experience with the Parallax > board is using Communique!, which has the same characteristic. We have > discovered that overlaying the local window with another window (e.g. output of > a graphical display program) is a quick and easy way to transmit the other > window. Yes I find this useful too sometimes. However, most of the time I have chronic shortage of desktop space, especially if I am trying to run a whiteboard at the same time as some video windows. At the moment I am down one display (I normally have two connected to my machine) thus making the matter worse. From rem-conf-request@es.net Mon Feb 07 10:43:00 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <01105-0@osi-west.es.net>; Mon, 7 Feb 1994 07:42:32 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14517(6)>; Mon, 7 Feb 1994 07:42:19 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16143>; Mon, 7 Feb 1994 07:42:05 -0800 To: Fengmin Gong cc: Graeme.Wood@edinburgh.ac.uk, mit@cs.tut.fi, rem-conf@es.net Subject: Re: VideoPix vs XVideo speed with nv In-reply-to: Your message of "Mon, 07 Feb 94 05:27:44 PST." <9402071327.AA24072@crusher.concert.net> Date: Mon, 7 Feb 1994 07:41:51 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Feb7.074205pst.16143@ecco.parc.xerox.com> In message <9402071327.AA24072@crusher.concert.net> you write: > Graeme Wood wrote earlier: > >The unfortunate side-effect of this is though, that you have to keep the > >"Local camera" window unobscured at all times otherwise you end up > >sending out either a blank screen or bits of your display overlayed on > >top of the video image. > > Could explain what do you mean by "side-effect of this"? As far as I know, > the problem of insisting on "Local camera" to be exposed to grab the > correct video image is with XVideo design and it has nothing to do with > how nv3.3alpha grabs its image. > This is correct. No matter how nv chose to do a grab, it would be required that the local camera window be unobscured for things to work correctly. Except for getting JPEG compressed data, the XVideo board gives you no choice. The only way to get bits from the camera is to get them by reading (VERY slowly) out of the frame buffer. In another message Graeme mentioned being able to use this trick to transmit another X window. That actually doesn't work very well when the other window is not 24-bit deep. If you want to do that, you'll find it supported directly for _any_ X server in nv 3.3 as a different grabber. An early version of it is done in the alpha release, but right now it only follows the mouse around. I haven't yet put in the other features to transmit a fixed area of the screen or change the image size. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Mon Feb 07 11:02:24 1994 Received: from MOON.MIT.EDU by osi-west.es.net via ESnet SMTP service id <01376-0@osi-west.es.net>; Mon, 7 Feb 1994 08:02:05 +0000 Received: by moon.mit.edu (AIX 3.2/UCB 5.64/4.03) id AA07337; Mon, 7 Feb 1994 10:59:01 -0500 Message-Id: <9402071559.AA07337@moon.mit.edu> To: rem-conf@es.net Cc: John.Erickson@Dartmouth.EDU, dgb@nyquist.bellcore.com (Dave Boyer 21342), Jon Crowcroft , d.lewis@cs.ucl.ac.uk, Carl Silva <"lacv01::silva"@akocoa.enet.dec.com>, Gordon Joly , uwe@philabs.Philips.COM (Uwe Trode - Philips Broadband Networks), moritz_farbstein@il.us.swissbank.com (Moritz Farbstein), John Jensen , Paul Bosco , Lou Steinberg , dlt@lcs.mit.edu, Marshall Rose , venkat@cs.ucsd.edu Subject: Multimedia MIB from MMCF. Date: Mon, 07 Feb 94 10:59:00 -0500 From: Jim Perchik A MIB for monitoring and managing Multimedia Applications from the non-profit Multimedia Communications Forum (MMCF) is planned to be demonstrated in mid-1994, according to Data Communications, December 1993, p. 18. MM/MIB will define a set of management attributes for real-time, interactive multimedia services over both local- and wide-area networks, including ATM, FDDI, ISDN, and Iso-Enet. Glenn Maiden, editor of MMCF's network management workgroup, is involved in MM/MIB. AT&T, IBM, L.M. Ericsson A.B. (Stockholm), and Luxcom Inc. (Fremont, CA) are helping to put the MIB together. Does anyone know an email address and/or or phone number for MMCF? Or anything else about this organization or MM/MIB described in this newsclip? Thanks. Jim Perchik MIT Center for Advanced Engineering Study, 9-470 77 Massachusetts Avenue Cambridge, MA 02139 (617)253-1967 From rem-conf-request@es.net Mon Feb 07 12:45:01 1994 Received: from crusher.concert.net by osi-west.es.net via ESnet SMTP service id <03221-0@osi-west.es.net>; Mon, 7 Feb 1994 09:44:42 +0000 Received: by crusher.concert.net (5.59/tas-concert/6-19-91) id AA24347; Mon, 7 Feb 94 12:44:01 -0500 From: Fengmin Gong Message-Id: <9402071744.AA24347@crusher.concert.net> Subject: Re: VideoPix vs XVideo speed with nv To: gc@bnl.gov Date: Mon, 7 Feb 1994 12:44:01 -0500 (EST) Cc: Graeme.Wood@edinburgh.ac.uk, frederic@parc.xerox.com, mit@cs.tut.fi, rem-conf@es.net In-Reply-To: <9402070925.ZM2197@sirius.ccd.bnl.gov> from "Graham Campbell" at Feb 7, 94 09:25:17 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1204 Graham Campbell wrote earlier: > >On Feb 7, 10:11am, Graeme Wood wrote: >> Subject: Re: VideoPix vs XVideo speed with nv > ................................ >> >> The unfortunate side-effect of this is though, that you have to keep the >> "Local camera" window unobscured at all times otherwise you end up >> sending out either a blank screen or bits of your display overlayed on >> top of the video image. >>-- End of excerpt from Graeme Wood > >This might even be viewed as a feature. Our only experience with the Parallax >board is using Communique!, which has the same characteristic. We have >discovered that overlaying the local window with another window (e.g. output of >a graphical display program) is a quick and easy way to transmit the other >window. > >-- >Graham >gc@bnl.gov > > You may consider it a feature when you don't have anything better. For one thing, it may not be an efficient way to get some graphics over the network, or even for loopback testing of the video. It will be more like a feature if you can turn it on/off. -- Fengmin Gong E-mail: gong@concert.net Network Research Engineer Phone: 919 248-9214 MCNC Information Technologies FAX: 919 248-1405 From rem-conf-request@es.net Tue Feb 08 14:44:19 1994 Received: from paul.rutgers.edu by osi-west.es.net via ESnet SMTP service id <21702-0@osi-west.es.net>; Tue, 8 Feb 1994 11:43:55 +0000 Received: by paul.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00477; Tue, 8 Feb 94 14:43:52 EST Date: Tue, 8 Feb 94 14:43:52 EST From: klemets@paul.rutgers.edu (Anders Klemets) Message-Id: <9402081943.AA00477@paul.rutgers.edu> To: rem-conf@es.net Subject: Media on Demand distribution I have made a tar file of the half a dozen scripts that make up my WWW Media on Demand server. I also tried to write a little bit of documentation, describing how the different scripts should be puzzled together. This is not a product -- it might be necessary to do some tweaking to the scripts for them to work in a different environment. I can't promise that it will work immediately on your machine. If you can't accept this, well don't retrieve the code then. My Media on Demand server uses NCSA HTTPD 1.0a5. It is pretty much required that you run this server, although it should not be all that difficult to port it to some other server that understands HTML+. The server runs on a Sparc 10 with SunOS 4.1.3, but that should be of lesser importance. The distribution is available with anonymous ftp from sics.se. The file name is archive/media_on_demand.tar.Z. You should also make sure to retrieve the latest version of the vat/nv record and playback tools which are available from the same site, as archive/vat_nv_record.tar.Z. This latest versions includes GSM audio file support in vat_play_audio and a couple of bug fixes. I replaced calls to usleep() in the playback programs with calls to select() so that those program can still act upon remote control commands while sleeping. I have been unable to test this latest fix thoroughly, but it should work :-) You may want to save your old versions just in case. Anders From rem-conf-request@es.net Tue Feb 08 16:12:50 1994 Received: from chang.austin.ibm.com by osi-west.es.net via ESnet SMTP service id <22743-0@osi-west.es.net>; Tue, 8 Feb 1994 13:12:29 +0000 Received: by chang.austin.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA27419; Tue, 8 Feb 1994 15:12:22 -0600 From: chang@chang.austin.ibm.com (SYSTEM ) Message-Id: <9402082112.AA27419@chang.austin.ibm.com> Subject: IP Multicast patch on AIX 3.2.5 available To: rem-conf@es.net, mbone@isi.edu Date: Tue, 8 Feb 1994 15:12:21 -0600 (CST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6667 This is announcement on IP multicast pathch on AIX 3.2.5, RISC SYSTEM/6000 availability. Prior to get this code, please read appended README. This is NOT Supported, use your own risk. The software is available from annomous FTP from gated.cornell.edu, /pub/multicast/aix325-ipmcast.tar.Z. You can also get it from www gopher 'gopher://gated.cornell.edu', look under the Multicast tools and Software menu. -------------------- README ---------------------------------- This is an experimental IP multicast enhancement for the Risc System/6000* running AIX 3.2.5. It is based on the original version by Steve Deering (deering@parc.xerox.com). This release is a test version. No >fatal< bugs have been encountered on my machines (see the bugs section below), but we can't guarantee that installing this software will leave your system unscathed (i.e., it works for me...). There has been a report of this stuff not quite working on another test machine, but I have not been able to reproduce that problem here; therefore, I strongly recommend that you install this only if the possibility of rebuilding your system from scratch doesn't bother you. That said... The minor changes necessary to make mrouted and nv 3.2 work on AIX 3.2.5 have been sent to Steve Deering and Ron Frederick and will hopefully show up in later releases of these programs. The nv port currently runs in receive-only mode. Much of the kernel work was done by Tom Pusateri at IBM Raleigh and John Leddy, now at Advantis. I've taken that work, merged in support for encapsulated tunnels, and built it into a 3.2.5 base. Currently, there is support for the "high performance" ethernet and token ring adapters, which show up under lsdev -C as ent0 Available 00-04 Ethernet High-Performance LAN Adapter tok0 Available 00-05 Token-Ring High-Performance Adapter There is not yet support for other adapters. In particular, there is no support for the integrated ethernet which shows up as ent0 Available 00-00-0E Standard Ethernet Adapter This ethernet is common on the 3xx and 2xx series of machines. Support for other network devices may be possible in the future if we have some time available. Support for the token ring adapter includes an extension to the "no" command. By default, the token ring functional address is used as specified in RFC 1469. However, if a broadcast mac address is required to interoperate with other token ring multicast products, it can be dynamically reconfigured using "no -o rfc1469_use_fa=0". Please refer to RFC 1469 for further details. By default, the netinet.mcast extension is loaded with IP forwarding disabled. If you really want to enable forwarding, you must use the "no" command to turn it back on. If you do this, be prepared to annoy your enemies and (former) friends if you ever enable promiscuous mode (as does mrouted for ethernet). We could hack around a bit to filter ICMP transmissions better so that we're less of an annoyance, but since this is experimental code it was just easier to disable forwarding. ********************** I M P O R T A N T ************************** Once you replace these files, the AIX support center will not diagnose any problems you may be experiencing. If you are having a problem with these files installed, first replace them with the original versions, reboot, and see if the problem persists. If so, then use normal problem reporting procedures. Note that if you are having a big problem such that the machine will not boot, you will need to have the AIX 3.2.5 boot floppies available from which to boot, getrootfs, and then restore the original modules. Applying an update to a machine running with these modifications will result in unpredictable behavior. Do not expect updates from the AIX support center to work with these mods. If these modifications are not working as expected, send a note to me, Steve Heimlich (heimlich@watson.ibm.com). I'll try to fix things as time allows. *********************************************************************** This package includes the following files. README.1st you're reading it now README.deering Steve Deering's June 1993 README file NOTICE copyrights applicable to this distribution if_en.mcast high perf ether kernel extension if_tr.mcast token ring kernel extension ifconfig.mcast replacement ifconfig command netinet.mcast IP kernel extension netstat.mcast replacement netstat command include directory of changed include files needed for compiling new applications unix.mcast kernel with mcast support for loopback On the system here, there is a copy of the original files (e.g., if_en.325), and a symbolic link to the mcast file (e.g., if_en -> if_en.mcast). Once you have everything in place and set up with links or copies, you will need to run bosboot to rebuild the boot image from unix.mcast (I do a bosboot -a -D -d hdisk0) and reboot. If you should ever switch back to the original unix, you need to rerun the bosboot command. Known Bugs ---------- Once the ether goes into promiscuous mode, it's always in promiscuous mode. Once a multicast MAC address is added to the ethernet receive filter, it's always in there. Notice ------ Read the NOTICE file in this distribution. Remember, this code enhancement to AIX 3.2.5 is experimental and is not supported. And now a note from our attorneys: NOTICE TO USERS OF THESE CODE MODULES INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THESE CODE MODULES, BOTH INDIVIDUALLY AND AS ONE OR MORE GROUPS, "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THESE MODULES, BOTH INDIVIDUALLY AND AS ONE OR MORE GROUPS, IS WITH YOU. SHOULD ANY PART OF THESE MODULES PROVE DEFECTIVE, YOU (AND NOT IBM OR AN AUTHORIZED RISC System/6000* WORKSTATION DEALER) ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. * RISC System/6000 is a trademark of International Business Machines Corporation. -- ----------------------------------------------------------------------------- Kay Chang AIX Communication Architecture, IBM Tel: (512) 838-3542 E-mail: chang@chang.austin.ibm.com Zip 9551, 11400 Burnet Rd. Austin, Tx. 78758-3493 ----------------------------------------------------------------------------- From rem-conf-request@es.net Tue Feb 08 16:45:40 1994 Received: from paris.nisc.sri.com by osi-west.es.net via ESnet SMTP service id <23196-0@osi-west.es.net>; Tue, 8 Feb 1994 13:45:24 +0000 Received: by paris.nisc.sri.com (5.65/SRI-NISC1.2) id AA00290; Tue, 8 Feb 94 13:45:12 -0800 Message-Id: <9402082145.AA00290@paris.nisc.sri.com> To: rem-conf@es.net Cc: rlang@NISC.SRI.COM Subject: vat on Sparc10 problems Date: Tue, 08 Feb 94 13:45:10 PST From: Ruth Lang We have experienced episodic problems with vat on our Sparc10. IP multicasting is properly installed and vat runs fine at times. At other times, both input and output meters show a high level of activity although neither is being provided. Any audio that can be generated by or received on that Sparc10 is unintelligible. Has anyone experienced similar problems? We have had Sun field engineers out to check the hardware and they claim there are no problems. One theory we have is that vat performs internal calibration to pick a silence level and that the problem can be attributed to the difference in the audio chip in the Sparc10. Any input on solving or working around this problem would be appreciated. Thanks, Ruth Lang rlang@nisc.sri.com From rem-conf-request@es.net Tue Feb 08 16:55:48 1994 Received: from en.ecn.purdue.edu by osi-west.es.net via ESnet SMTP service id <23385-0@osi-west.es.net>; Tue, 8 Feb 1994 13:55:17 +0000 Received: by en.ecn.purdue.edu (5.65/1.32jrs) id AA22439; Tue, 8 Feb 94 16:55:14 -0500 From: bhoja@ecn.purdue.edu (Sudeep Bhoja) Message-Id: <9402082155.AA22439@en.ecn.purdue.edu> Subject: Using VAT as a Mixer. To: rem-conf@es.net Date: Tue, 8 Feb 1994 16:55:11 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 327 Hi, I am currently running SD and all the other video-conferencing tools on SPARC running Solaris. I wish to use the SPARC as a mixer and play audio on a machine that runs SUNOS 4.1 without multicast extensions. I am running VAT version 3.2. I read the MAN pages for VAT but that did not help. Thanks for any help -Sudeep From rem-conf-request@es.net Wed Feb 09 04:07:49 1994 Received: from sics.se by osi-west.es.net via ESnet SMTP service id <29004-0@osi-west.es.net>; Wed, 9 Feb 1994 01:07:32 +0000 Received: from hans.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA24018; Wed, 9 Feb 94 10:07:24 +0100 Message-Id: <9402090907.AA24018@sics.se> Mime-Version: 1.0 Content-Type: text/plain; charset="x-Mac->8559" Content-Transfer-Encoding: 8bit Date: Wed, 9 Feb 1994 10:07:28 +0100 To: rem-conf@es.net, mice@cs.ucl.ac.uk From: hans@sics.se (Hans Eriksson) Subject: Swedish Primeminister demo Folks, I$d like to thank everybody that showed up for the demo. Primeminister Carl Bildt was duly impressed by the stuff we showed him. Beside teleconferencing (vat, ivs, wb), I showed him Mosaic, and the Space Shuttle. There is a nice picture in the Swedish "Financial Times" which I will scan and place in our WWW server eventually. Mats Brunell also took the opportunity to make Bildt a memeber of the ISOC (with Vint Cerf OK). Bildt is already on the Internet and he has sent me a "thank-you" note. The first Boss actively on the net! cheers /hans Hans Eriksson, SICS, Box 1263, 164 28 Kista, Sweden Tel: +46 8 752 1527 Fax: +46 8 751 7230 email: hans@sics.se From rem-conf-request@es.net Wed Feb 09 13:40:06 1994 Received: from en.ecn.purdue.edu by osi-west.es.net via ESnet SMTP service id <04826-0@osi-west.es.net>; Wed, 9 Feb 1994 10:39:49 +0000 Received: by en.ecn.purdue.edu (5.65/1.32jrs) id AA13704; Wed, 9 Feb 94 13:39:41 -0500 From: bhoja@ecn.purdue.edu (Sudeep Bhoja) Message-Id: <9402091839.AA13704@en.ecn.purdue.edu> Subject: Re: Using VAT as a Mixer. To: roediger@nhmxw0.fnal.gov (Gary Roediger) Date: Wed, 9 Feb 1994 13:39:40 -0500 (EST) Cc: rem-conf@es.net In-Reply-To: <9402091709.AA01748@nhmxw0.fnal.gov> from "Gary Roediger" at Feb 9, 94 11:09:40 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 875 Yes I am running Solaris - 2.3. I installed from the following sites. nv - parcftp.xerox.com//pub/net-research/nv.tar.Z sd - ftp.ee.lbl.gov//sd.tar.Z vat - ftp.ee.lbl.gov//vat.tar.Z I saw this clip in the MBONE FAQ. ************************************************************************** You can add it now to SunOS 4.1.1 (regarding IP multicast) 4.1.2, or 4.1.3; Sun includes it the standard kernel with Solaris 2.1 (though these programs may not yet run on Solaris). ********************************************************************* I am not able to receive either audio/video, though I am able to pick up session announcements (SD) and participant info (on VAT). Is there any problem? Thanks -Sudeep > > > You mentioned you are running under Solaris - is it 2.3? If so where did > you find the code for nv, vat, sd for Solaris 2.3? > Thankx > Gary > From rem-conf-request@es.net Thu Feb 10 01:18:14 1994 Received: from en.ecn.purdue.edu by osi-west.es.net via ESnet SMTP service id <12953-0@osi-west.es.net>; Wed, 9 Feb 1994 22:17:48 +0000 Received: by en.ecn.purdue.edu (5.65/1.32jrs) id AA29409; Thu, 10 Feb 94 01:17:44 -0500 From: bhoja@ecn.purdue.edu (Sudeep Bhoja) Message-Id: <9402100617.AA29409@en.ecn.purdue.edu> Subject: NV on monochrome To: rem-conf@es.net Date: Thu, 10 Feb 1994 01:17:43 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 212 Has anybody had success on using NV on monochrome displays? I can run it on Color without problems but can't get it to work on monochrome. Also, has anybody tried using VAT as a mixer ("-m")? Thanks -Sudeep From rem-conf-request@es.net Thu Feb 10 03:00:24 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <13598-0@osi-west.es.net>; Wed, 9 Feb 1994 23:59:38 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14565(8)>; Wed, 9 Feb 1994 23:59:29 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16143>; Wed, 9 Feb 1994 23:59:18 -0800 To: bhoja@ecn.purdue.edu (Sudeep Bhoja) cc: rem-conf@es.net Subject: Re: NV on monochrome In-reply-to: Your message of "Wed, 09 Feb 94 22:17:43 PST." <9402100617.AA29409@en.ecn.purdue.edu> Date: Wed, 9 Feb 1994 23:59:15 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Feb9.235918pst.16143@ecco.parc.xerox.com> In message <9402100617.AA29409@en.ecn.purdue.edu> you write: > > Has anybody had success on using NV on monochrome displays? > I can run it on Color without problems but can't get it to work on monochrome > . By monochrome, do you mean 1-bit deep displays or 8-bit greyscale? It should work on either, but a 1-bit display doesn't really offer much to work with. The image quality is pretty poor. You can sort of make out whether it's a person or not, but I wouldn't hope for much beyond that. :) On 8-bit greyscale, it should work fine, though you probably want to set up the receive defaults so that it always dithers in greyscale. I would do that automatically if I could, but silly X11 isn't capable of distinguishing an 8-bit color display from an 8-bit greyscale one, at least on the systems I use. What exactly do you mean when you say you can't get it to work? -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Feb 10 13:37:15 1994 Received: from viipuri.nersc.gov by osi-west.es.net via ESnet SMTP service id <18406-0@osi-west.es.net>; Thu, 10 Feb 1994 10:37:00 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA14472; Thu, 10 Feb 94 10:36:58 PST Date: Thu, 10 Feb 94 10:36:58 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9402101836.AA14472@viipuri.nersc.gov> To: rem-conf@es.net Subject: FWD: Stuck getting VAT to run under Solaris 2.3 Found this message in my requests mailbox... NOTE to the originator: messages meant for the rem-conf at large need to be addressed to rem-conf@es.net while messages requesting addition, deletion, or changes to list membership must be addressed to rem-conf-request@es.net ----- Begin Included Message ----- >From fwp@CC.MsState.Edu Tue Feb 8 15:26:29 1994 Date: Tue, 8 Feb 1994 17:26:34 -0600 From: Frank Peters To: rem-conf-request@es.net ^^^^^^^ Subject: Stuck getting VAT to run under Solaris 2.3 X-Sun-Charset: US-ASCII Content-Length: 862 Hello, Sorry to bother the group with what is probably a FAQ (though I've looked through the mbone FAQ). I have a Sun system (SPARC 10) running Solaris 2.3. This machine is our mbone router and seems to work fine in that capacity. In addition nv and sd work fine. I downloaded vat.dyn-3.2 from ftp.ee.lbl.gov. The README for this suggests that it should run under Solaris 2.3. When I try to start it I get a library version warning and a core dump: ld.so.1: vat: warning: /usr/4lib/libX11.so.4.3 has older revision than expected 10 Segmentation Fault (core dumped) Since this is a Solaris 1.x (SunOS 4.x) executable the core file doesn't provide me with any useful information. Has anyone seen this problem before? Does this version of VAT indeed work under Solaris 2.3? Thanks in advance for any advice. Frank Peters Mississippi State University ----- End Included Message ----- ari@es.net _/_/ _/_/_/_/ _/ Ari Ollikainen {VOX: 510 423-5962} _/ _/ _/ _/ _/ Energy Sciences Network {FAX: 510 423-8744} _/_/_/_/ _/_/_/_/ _/ National Energy Research Supercomputer Center _/ _/ _/ _/ _/ Lawrence Livermore National Laboratory _/ _/ _/ _/ _/ MailStop L-561, PO BOX 5509, Livermore, CA. 94551 From rem-conf-request@es.net Thu Feb 10 15:06:00 1994 Received: from intrepid.ecn.purdue.edu by osi-west.es.net via ESnet SMTP service id <19695-0@osi-west.es.net>; Thu, 10 Feb 1994 12:05:32 +0000 Received: from localhost (localhost [127.0.0.1]) by intrepid.ecn.purdue.edu (8.6.4/3.0davy) with ESMTP id PAA02556; Thu, 10 Feb 1994 15:05:25 -0500 Message-Id: <199402102005.PAA02556@intrepid.ecn.purdue.edu> To: Frank Peters Cc: rem-conf@es.net Subject: Re: FWD: Stuck getting VAT to run under Solaris 2.3 In-reply-to: Message from ari@es.net (Ari Ollikainen) of "Thu, 10 Feb 1994 10:36:58 -0800" Date: Thu, 10 Feb 1994 15:05:18 EST From: "David A. Curry" From: Frank Peters Date: Tue, 8 Feb 1994 17:26:34 -0600 Subject: Stuck getting VAT to run under Solaris 2.3 Has anyone seen this problem before? Does this version of VAT indeed work under Solaris 2.3? I can confirm that the "vat-dyn" version of VAT 3.2 works just fine in "receive mode" on Solaris 2.3 on a SPARCstation LX... I was watching NASA Select with it just the other day. --Dave From rem-conf-request@es.net Thu Feb 10 15:12:22 1994 Received: from en.ecn.purdue.edu by osi-west.es.net via ESnet SMTP service id <19768-0@osi-west.es.net>; Thu, 10 Feb 1994 12:11:45 +0000 Received: by en.ecn.purdue.edu (5.65/1.32jrs) id AA12697; Thu, 10 Feb 94 15:11:39 -0500 From: bhoja@ecn.purdue.edu (Sudeep Bhoja) Message-Id: <9402102011.AA12697@en.ecn.purdue.edu> Subject: Re: NV on monochrome To: frederic@parc.xerox.com (Ron Frederick) Date: Thu, 10 Feb 1994 15:11:37 -0500 (EST) Cc: rem-conf@es.net In-Reply-To: <94Feb9.235918pst.16143@ecco.parc.xerox.com> from "Ron Frederick" at Feb 9, 94 11:59:15 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1167 I am running NV on a SPARC 10 machine but setting the display on a SPARC station IPC(running SUNOS 4.1.1 without multicast) with a 8-bit greyscale display. The pictures, are black and white lines, constantly changing. ^^^^^^^^^^^^^^^^^^^^ However, when I set the display to a color monitor instead of the monochrome, everything is perfect. Where do I set the receive defaults to dither in greyscale?. Thanks -Sudeep > By monochrome, do you mean 1-bit deep displays or 8-bit greyscale? It should > work on either, but a 1-bit display doesn't really offer much to work with. > The image quality is pretty poor. You can sort of make out whether it's a > person or not, but I wouldn't hope for much beyond that. :) > > On 8-bit greyscale, it should work fine, though you probably want to set up > the receive defaults so that it always dithers in greyscale. I would do that > automatically if I could, but silly X11 isn't capable of distinguishing an > 8-bit color display from an 8-bit greyscale one, at least on the systems I > use. > > What exactly do you mean when you say you can't get it to work? > -- > Ron Frederick > frederick@parc.xerox.com > From rem-conf-request@es.net Fri Feb 11 01:19:10 1994 Received: from swifty.dap.CSIRO.AU by osi-west.es.net via ESnet SMTP service id <25500-0@osi-west.es.net>; Thu, 10 Feb 1994 22:18:43 +0000 Received: by swifty.dap.CSIRO.AU (920330.SGI/920502.SGI) for rem-conf@es.net id AA26055; Fri, 11 Feb 94 17:18:04 +1100 From: alan@swifty.dap.CSIRO.AU (Alan Hargreaves) Message-Id: <9402110618.AA26055@swifty.dap.CSIRO.AU> Subject: stills over nv To: rem-conf@es.net Date: Fri, 11 Feb 1994 17:18:04 +1100 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 621 like the subject says, is there any way to send a still over nv? (ie i don't currently have a camera and frame grabber). alan. -- Alan Hargreaves (VK2KVF) alan@dap.csiro.au, Ph: +61 2 413 7752 CSIRO Division of Applied Physics, PO Box 218 Lindfield 2070 "This terminal is no more. It has ceased to be. It's expired and gone to meet its maker. This is a late terminal. It's a stiff. Bereft of life, it rests in peace. If you hadn't nailed it to the bench, it would be pushing up the daisies. It's run down the curtain and joined the choir invisible. This is an X-Terminal!" From rem-conf-request@es.net Fri Feb 11 02:04:58 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <25673-0@osi-west.es.net>; Thu, 10 Feb 1994 23:04:34 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14410(7)>; Thu, 10 Feb 1994 23:04:21 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16143>; Thu, 10 Feb 1994 23:04:07 -0800 To: alan@swifty.dap.csiro.au (Alan Hargreaves) cc: rem-conf@es.net Subject: Re: stills over nv In-reply-to: Your message of "Thu, 10 Feb 94 22:18:04 PST." <9402110618.AA26055@swifty.dap.CSIRO.AU> Date: Thu, 10 Feb 1994 23:04:06 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Feb10.230407pst.16143@ecco.parc.xerox.com> In message <9402110618.AA26055@swifty.dap.CSIRO.AU> you write: > like the subject says, is there any way to send a still over nv? (ie > i don't currently have a camera and frame grabber). > Not at present, but the next version of nv will have a screen grabber that you can use to send whatever you can put up on your workstation display (either stills or animation)... -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Fri Feb 11 04:18:49 1994 Received: from noc.BelWue.DE by osi-west.es.net via ESnet SMTP service id <26510-0@osi-west.es.net>; Fri, 11 Feb 1994 01:18:33 +0000 Received: from kssun7.rus.uni-stuttgart.de by noc.BelWue.DE with SMTP id AA17956 (5.65c8/IDA-1.4.4 for ); Fri, 11 Feb 1994 10:12:53 +0100 Received: by kssun7.rus.uni-stuttgart.de (4.1/BelWue-1.3SUN) id AA08188; Fri, 11 Feb 94 10:10:40 +0100 Date: Fri, 11 Feb 94 10:10:40 +0100 From: Schulz@rus.uni-stuttgart.de (Claus-Dieter Schulz) Message-Id: <9402110910.AA08188@kssun7.rus.uni-stuttgart.de> To: fwp@cc.msstate.edu, davy@ecn.purdue.edu Subject: Re: FWD: Stuck getting VAT to run under Solaris 2.3 Cc: rem-conf@es.net, mbone@isi.edu > From: Frank Peters > Date: Tue, 8 Feb 1994 17:26:34 -0600 > Subject: Stuck getting VAT to run under Solaris 2.3 > > Has anyone seen this problem before? Does this version of VAT indeed work under > Solaris 2.3? > > I can confirm that the "vat-dyn" version of VAT 3.2 works just fine in > "receive mode" on Solaris 2.3 on a SPARCstation LX... I was watching > NASA Select with it just the other day. > I'm running vat on a Sparc10SX (Solaris2.3), both sending and recieving multicast audio works fine. Unicast didn't work (known problem) VAT crashed (segmentation fault) on a Sparc10 (Solaris2.3) (don't know why) !! Claus-Dieter From rem-conf-request@es.net Fri Feb 11 09:30:23 1994 Received: from sirius.brunel.ac.uk by osi-west.es.net via ESnet SMTP service id <28004-0@osi-west.es.net>; Fri, 11 Feb 1994 06:30:05 +0000 Received: from dawes.brunel.ac.uk by sirius.brunel.ac.uk with SMTP (PP) id <18864-0@sirius.brunel.ac.uk>; Fri, 11 Feb 1994 14:29:34 +0000 From: John P Moore Message-Id: <22988.9402111429@dawes.brunel.ac.uk> Subject: Subscribe To: rem-conf@es.net Date: Fri, 11 Feb 1994 14:29:10 +0000 (GMT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 42 Please subscribe me to the mailing list. From rem-conf-request@es.net Fri Feb 11 11:22:39 1994 Received: from enfm.utcc.utoronto.ca by osi-west.es.net via ESnet SMTP service id <29053-0@osi-west.es.net>; Fri, 11 Feb 1994 08:22:20 +0000 Received: from localhost by enfm.utcc.utoronto.ca with SMTP id <41412>; Fri, 11 Feb 1994 11:22:06 -0500 To: rem-conf@es.net Subject: NCD MCX MBONE tools Organization: UTCC Network & Operations Services, External Network Fac. Mgmt. Phone: +1 416 978 3328 Date: Fri, 11 Feb 1994 11:21:56 -0500 From: "Eric M. Carroll" Message-Id: <94Feb11.112206est.41412@enfm.utcc.utoronto.ca> Hi, Last August someone posted a request for information about vat, et al and their compatability with the new NCD MCX with audio server capabilities. I saw no answer, and now find myself downgraded from a Sparc to an MCX. Can anyone point me to MBONE capable tools that will talk to the MCX audio server TCP port, or any known hacks to make it all work? I am most familiar with vat, but will take anything. If one of these can dump audio to a file, I may be able to redirect that across the net to the audio server port. I have done some work in the past on debugging vat and the MBONE up north here, and we will likely be in a position (with new routers) to run the MBONE again. I would be willing to look at porting code if necessary in order to get the tools back on the X terminal I am now using. Any suggestions would be appreciated... Eric Carroll University of Toronto Computing & Communications Network & Operations Services, External Network Fac. Management From rem-conf-request@es.net Mon Feb 14 03:46:50 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <22535-0@osi-west.es.net>; Mon, 14 Feb 1994 00:46:27 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Mon, 14 Feb 1994 00:46:24 -0800 Posted-Date: Mon 14 Feb 94 00:45:28 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Mon, 14 Feb 94 00:45:30 PST Date: Mon 14 Feb 94 00:45:28 PST From: Stephen Casner Subject: STS-60 viewership record To: rem-conf@es.net Message-Id: <761215528.0.CASNER@XFR.ISI.EDU> Mail-System-Version: Congratulations to the folks who brought us the rebroadcast of the NASA Select video of the STS-60 Shuttle mission for setting a new record for the cumulative number of session participants. The total over 8 days was 906, half again as much as the 600 for each of the last two IETFs. The number of countries was lower, though, at 12. I've made a list of the participants as I've done previously for the IETF meetings. It is available from ftp.isi.edu in the file mbone/nasa-sts60-list.txt. I also saw the number of subnets routed by DVMRP hit 829 in one sample (Van Jacobson says the cumulative number of subnets in the MBONE is around 850). I guess we've got to admit that Pandora's box is definitely open by now! -- Steve ------- From rem-conf-request@es.net Mon Feb 14 07:27:16 1994 Received: from domen.uninett.no by osi-west.es.net via ESnet SMTP service id <23657-0@osi-west.es.net>; Mon, 14 Feb 1994 04:26:52 +0000 Received: from localhost by domen.uninett.no with SMTP (PP) id <05907-0@domen.uninett.no>; Mon, 14 Feb 1994 13:26:25 +0100 To: "Eric M. Carroll" cc: rem-conf@es.net Subject: Re: NCD MCX MBONE tools In-reply-to: Your message of "Fri, 11 Feb 1994 11:21:56 EST." <94Feb11.112206est.41412@enfm.utcc.utoronto.ca> Date: Mon, 14 Feb 1994 13:26:21 +0100 From: Olav Kvittem > Hi, > > Last August someone posted a request for information about vat, et al > and their compatability with the new NCD MCX with audio server > capabilities. I saw no answer, and now find myself downgraded from a > Sparc to an MCX. Can anyone point me to MBONE capable tools that will > talk to the MCX audio server TCP port, or any known hacks to make it > all work? I am most familiar with vat, but will take anything. If one > of these can dump audio to a file, I may be able to redirect that > across the net to the audio server port. > > I have done some work in the past on debugging vat and the MBONE up > north here, and we will likely be in a position (with new routers) to > run the MBONE again. I would be willing to look at porting code if > necessary in order to get the tools back on the X terminal I am now > using. > > Any suggestions would be appreciated... I(we) are in the same situation and have scarcely looked into this and my first finding was that NCD has released the source client/server package for audio (similar to the X-concepts) called Netaudio. The server part is running in the MSX. There is also a client library for ea general UNIX platform and a server for at least Sun-platfrom. There is an active distributionlist for the product supported by NCD netaudio-request@ncd.com. My current ideas is to adapt a VAT-capable packeage to use the Netaudio client library. VAT was the first that came to my mind, but the problem here is that the source is not available. There is an indication in the alst VAT-release that source might be release, but that could be limited to the user interface code (tcl/tk). The second finding was a package that is called Nevot. It has sourcecode. I have however not had the resources to look deeper into doing the job of fitting in Netaudio. Olav I am not shure if this is the latest but here it is : NEVOT - A network voice terminal (BETA RELEASE 2.1 12/10/93) Henning Schulzrinne AT&T Bell Laboratories 1 Description The network voice terminal (NEVOT) allows audio-capable workstations to participate in audio conferences across local and wide area networks. Features: o platforms: -- Sun SPARCstation * SunOS 4.1.x * Solaris 2.x -- Silicon Graphics 4D/30 and 4D/35 (Indigo) and Indy * Irix 4.0.5 * Irix 5.1 o audio protocols: -- vat audio packet format -- real-time transport protocol (RTP), September 1993 draft 1 o transport protocols: -- unicast UDP -- multicast UDP -- TCP o operation as gateway or end system o compatible with vat session protocol o user interfaces: -- Tk -- dumb terminal (stdio) o control through Tcl language: -- initialization file -- command line arguments -- interactive o several independent concurrent conferences, each with different encoding and compression o DES-based voice encryption o current audio encodings supported: -- 16 bit linear encoding, with all hardware-supported sample rates (SPARCstation 10 and SGI) -- 64 kb/s -law PCM (CCITT G.711) -- 32 kb/s ADPCM (CCITT G.721) (SPARCstation) -- 32 kb/s Intel/DVI ADPCM -- 24 kb/s ADPCM (CCITT G.723) (SPARCstation) -- 13 kb/s GSM 06.10 -- 4.8 kb/s LPC (linear-predictive coding) with setable vocoder interval 2 o mono or stereo o each site can use different audio encodings o playback and recording of audio files (.au and AIFF/AIFC formats), with encoding translation o extensive statistics and tracing facilities o arbitrary voice packet length, which may differ for each site o lost packet substitution o setable audio buffer occupancy o configurable adjustment mechanisms for playout delay, VU meter, silence detector and automatic gain control o redefinable session identifier string with variable substitution 2 Documentation A compressed PostScript file describing Nevot is available through anonymous ftp (file://gaia.cs.umass.edu/pub/nevot.ps.Z). RTP is described in Internet drafts available from any Internet drafts directory, e.g., ds.internic.net: o the specification itself (ftp://ds.internic.net/internet-drafts/draft- ietf-avt-rtp-04.ps) o a profile for audio and video (ftp://ds.internic.net/internet- drafts/draft-ietf-avt-profile-04.txt) o a general design document (ftp://ds.internic.net/internet-drafts/draft- ietf-avt-issues-01.ps) A technical report (ftp://gaia.cs.umass.edu/pub/Schu92:Voice.ps.Z) is also available: Henning Schulzrinne, Voice Communication Across the Internet: A Network Voice Terminal, Dept. of Computer Science, University of Massachusetts, Amherst, Massachusetts, Technical Report TR 92-50, July 1992 Voice conferencing has attracted interest as a useful and viable first real-time application on the Internet. This report describes NEVOT, a network voice terminal meant to support multiple concurrent both two-party and multi-party conferences on top of a variety of transport protocols and using audio encodings offering from vocoder to multi-channel CD quality. As it is to be used as an experimental tool, it offers extensive configuration, trace and statistics options. The design is kept modular so that additional audio encodings, transport and real-time protocols as well as user interfaces can be added readily. In the first part, the report describes the X-based graphical user interface, the configuration and operation. The second part describes the individual components of NEVOT and compares alternate implementations. An appendix 3 covers the installation of NEVOT. ============================================================================= netaudio> less README *********************************************************************** * * * The Network Audio System * * * * An Audio Protocol For Networks * * * *********************************************************************** or open ("/dev/audio")? Just Say No! This directory tree contains sources for the Network Audio System, a network-transparent, client/server audio system, including: o a sample server implementation for /dev/audio on Suns, (Tested on SunOS 4.1.3 and Solaris 2.2) o a sample server implementation for SGI's Indigo, (Tested on IRIX 5.x) o an application programming interface library, and o a variety of sample applications. netaudio> cat README *********************************************************************** * * * The Network Audio System * * * * An Audio Protocol For Networks * * * *********************************************************************** or open ("/dev/audio")? Just Say No! This directory tree contains sources for the Network Audio System, a network-transparent, client/server audio system, including: o a sample server implementation for /dev/audio on Suns, (Tested on SunOS 4.1.3 and Solaris 2.2) o a sample server implementation for SGI's Indigo, (Tested on IRIX 5.x) o an application programming interface library, and o a variety of sample applications. The client software can also be used with NCD MCX X terminals running NCDware 3.1 or later. Key features of the Network Audio System include: o Device-independent audio over the network o Lots of audio data formats o Can store sounds in server for rapid replay o Extensive mixing, separating, and manipulation of audio data o Simultaneous use of audio devices by multiple applications o Use by a growing number of ISVs o Small size o Free! No obnoxious licensing terms Please note that the Network Audio System has no relationship to the NetAudio products from Townshend Computer Tools. Look at the file doc/slides.ps for a brief presentation on the Network Audio System. For more details, read doc/overview.ps. * * * * * I. Roadmap Here is a quick guide to where things are in this distribution (relative to the directory netaudio/): doc/ not enough documentation; overview, slides, lib config/ a little bit of imake stuff lib/audio/ API used by sample programs clients/audio/ sample programs server/ server code dia/ device-independent bits dda/sun/ device-dependent audio driver for Sun /dev/audio dda/sgi/ device-dependent audio driver for SGI Indigo When built, the server will be in server/ausun or server/ausgi, the library in lib/audio/libaudio.a, and the sample applications in clients/audio/aufoo/aufoo. In addition, the separate distribution sounds.tar.Z contains a directory of example sounds: examples/sounds/ various sounds that can be played If you don't have your own sound bites to nibble, grab these. * * * * * From rem-conf-request@es.net Tue Feb 15 03:14:25 1994 Received: from en.ecn.purdue.edu by osi-west.es.net via ESnet SMTP service id <05576-0@osi-west.es.net>; Tue, 15 Feb 1994 00:14:07 +0000 Received: by en.ecn.purdue.edu (5.65/1.32jrs) id AA17843; Tue, 15 Feb 94 03:14:04 -0500 From: bhoja@ecn.purdue.edu (Sudeep Bhoja) Message-Id: <9402150814.AA17843@en.ecn.purdue.edu> Subject: Suggestion for a VideoConferencing Workstation. To: rem-conf@es.net, frederic.PARC@xerox.com Date: Tue, 15 Feb 1994 03:14:03 -0500 (EST) Cc: meyer@ecn.purdue.edu (Dave Meyer) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1451 I have been asked to suggest a Workstation and a video digitizer for use with MBONE applications (like nv, IVS). This is for a distance education project in the Dept. of EE at Purdue University under Prof. Dave Meyer. I have seen the Summary of Video-Digitisers by Christopher Davis, in the rem-conf mailing list. I have also been following the Workstation Vs Digitizer, performance issues. This is what I have gathered, Sun VideoPix FrameGrabber: Cheap, not particularly fast or featureful, but for multicast use with NV works just fine. Performance with Parallax XVideo is not much better than VideoPix, although Parallax XVideo is much costlier. Does anybody have information on SunVideo? Workstation: On a SPARC 2 or above, the limiting factor by far in speed is the SBus performance. So a SPARC 10 is not much faster than a SPARC 2 when using VideoPix. Anything above a SPARC 2 would be CPU limited. ****It appears that a SPARC 2 with a VideoPix, would be the way to go. Is there anybody out there who feels otherwise? ***** The workstation should also accept Serial link (ISDN) connections and relay between serial link protocol (CCITT H.320) and RTP. I believe that the SPARC 10 comes with an ISDN interface. Considering this and the extra load to relay between H.320 & RTP, would SPARC 10 be a better choice? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ what are your experiences with it?. -Sudeep From rem-conf-request@es.net Tue Feb 15 04:37:27 1994 Received: from Merlin.Telcom.Arizona.EDU by osi-west.es.net via ESnet SMTP service id <06012-0@osi-west.es.net>; Tue, 15 Feb 1994 01:37:08 +0000 Received: from helios.ece.arizona.edu by Arizona.EDU (PMDF V4.2-14 #2381) id <01H8WCZ1ISWGBSJSQC@Arizona.EDU>; Tue, 15 Feb 1994 02:36:39 MST Received: from gpacs1.ece.arizona.edu.cerl by helios.ece.arizona.edu; Tue, 15 Feb 94 02:36:28 MST Date: Tue, 15 Feb 1994 02:36:28 -0700 (MST) From: Gwi Moon Subject: Re: Suggestion for a VideoConferencing Workstation. To: bhoja@ecn.purdue.edu Cc: frederic.PARC@xerox.com, rem-conf@es.net Message-id: <9402150936.AA06166@helios.ece.arizona.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > > I have been asked to suggest a Workstation and a video digitizer for use with > MBONE applications (like nv, IVS). This is for a distance education project in > the Dept. of EE at Purdue University under Prof. Dave Meyer. > > I have seen the Summary of Video-Digitisers by Christopher Davis, in the > rem-conf mailing list. I have also been following the Workstation Vs Digitizer, > performance issues. > > This is what I have gathered, > > Sun VideoPix FrameGrabber: > Cheap, not particularly fast or featureful, but for multicast use with NV > works just fine. Performance with Parallax XVideo is not much better > than VideoPix, although Parallax XVideo is much costlier. > Does anybody have information on SunVideo? > > Workstation: > On a SPARC 2 or above, the limiting factor by far in speed is the SBus > performance. So a SPARC 10 is not much faster than a SPARC 2 when using > VideoPix. Anything above a SPARC 2 would be CPU limited. > > ****It appears that a SPARC 2 with a VideoPix, would be the way to go. Is > there anybody out there who feels otherwise? ***** > > The workstation should also accept Serial link (ISDN) connections and > relay between serial link protocol (CCITT H.320) and RTP. I believe that > the SPARC 10 comes with an ISDN interface. Considering this and the > extra load to relay between H.320 & RTP, would SPARC 10 be a better choice? > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > what are your experiences with it?. > > -Sudeep > What about SunVideo under Solaris 2.3+? ---- Moon, Gwi e-mail to ----->>moongw@ece.arizona.edu Lab: 602-621-6099 Computer Engineering and Research Laboratory(CERL) Carrel:602-621-6099 Dept. of Electrical & Computer Engineering Home: 602-884-1231 University of Arizona || Tucson, Arizona 85721 =================Included Messages======================================== New Video and Multimedia Products *********************************************************************** * * * Multimedia Goes Mainstream with New Products * * * *********************************************************************** * * * - SunVideo SBus card completes Sun's video on every SPARCstation * * vision, which began with XIL and Solaris LIVE last spring. * * Now users can capture and compress video in real time at a * * full 30 frames/sec. * * * * - The new multimedia kit turns any SPARCstation into a video * * ready system. It includes the SunVideo card, a color video * * camera and a CDware CD disc with sample applications to try * * * * - Two multimedia SPARCstation packages have been created to offer * * unprecedented pricing at the low end and unmatched image * * performance at the high end * * * * SPARCclassic M provides a low cost video conference station * * SPARCstation 10 M offers 24-bit image manipulation * * * *********************************************************************** ANNOUNCEMENT BRIEF ------------------ Sun Microsystems Computer Corporation (SMCC) announces new multimedia products. Now video capabilities for conferencing and communication will be a reality. This marks the start of a new age of visual computing for workstation users. New SunVideo(TM) technology makes realtime video capture and compression a reality. With Solaris(R) LIVE(TM), any workstation can playback video without any special hardware. The combination means video ready networked multimedia for solving communication and collaboration needs today. New multimedia kits and workstations provide customers with an easy way to get started with video and multimedia. By providing a camera, SunVideo SBus board, and sample software, customers can enjoy the power of networked multimedia. Packages that include this kit and workstations based on Sun's low cost SPARCclassic(TM) system and newly announced SPARCstation(TM) 10SX system provide easy to order multimedia systems. SunVideo SBus Card ------------------ Computer video technology has taken a giant leap forward with Sun's new SunVideo technology. The SunVideo card captures and compresses video input in realtime, making it possible to have realtime video conferencing over standard Ethernet networks without expensive specialized video equipment. Alternatively, users can create multimedia applications, combining video and text into one file. The SunVideo board is able to compress video data in multiple formats, including MPEG1, JPEG and Sun's Cell compression technique. SunVideo technology is targeted at video conferencing, multimedia authoring systems, digital video creation and video server/video on demand applications. The SunVideo board is supported on the SPARCstation 10, SPARCstation IPX(TM), SPARCstation LX(TM), SPARCclassic, SPARCstation 1, SPARCstation 1+, SPARCstation 2, the SPARCserver(TM) 1000 and the SPARCcenter(TM) 2000 systems. The SunVideo card is not supported on the SPARCstation X X-terminal. All systems must run Solaris 2.3 in order to use the board. Multimedia Kit -------------- Sun recognizes that many customers would like to have video capabilities for conferencing and don't want to worry about cameras, software and compatibility issues. Sun is offering a bundled kit which includes a color NTSC video camera, the SunVideo SBus card, and a CDware(TM) CD containing sample software. This enables existing SPARCstation systems as well as new systems to become video ready. Users can try the different multimedia software before purchasing the license from the vendor. Note: The camera has a different power cord for UK and Europe. The CD provided is media only. No CD-ROM drive is included. Multimedia Workstation Packages ------------------------------- The SPARCclassic M packages the popular low-cost SPARCclassic workstation with the multimedia kit to provide an even better value for those desiring an entry level video conferencing system. After purchasing one of the popular conferencing applications from the CDware disc, this package is an unbeatable price point for a fully configured, diskful system that offers compressed video and a color video camera. This system is targeted at cost sensitive environments desiring conferencing or low cost multimedia authoring, such as customer service and general office workers. For more demanding uses and multimedia authoring, the SPARCstation 10 M system, configured around the revolutionary SX imaging technology offers true color (24-bit with 8-bit overlay). Ideal for financial analysts that need dual monitors or pre-press workers, this system performs 2-D and 3-D graphics operations common in CAD or design work as well. The CD provided is media only. No CD-ROM drive is included. SunVideo PERFORMANCE -------------------- SunVideo offers capture and compression of video at SIF resolution (320 x 240) in several formats: CellB 30 fps (frames per second) JPEG 30 fps MPEG1 I frames 30 fps MPEG1 IP frames 17 fps Capture YUV 30 fps Capture RGB-8 30 fps Capture RGB-24 12 fps FEATURES AND BENEFITS --------------------- SunVideo SBus Option o SunVideo delivers with realtime video capture and compression, allowing digital video to be broadcast over standard Ethernet networks at a full 30 frames/sec. o SunVideo offers multiple compression techniques including MPEG1, JPEG and Cell, providing customers the flexibility to use the compression technique that best suits their application o Sun developed Cell compression technique offers compression ratios of up to 200 to 1 o XIL(TM) library in Solaris 2.3 decompresses video, allowing video playback on any workstation using MPEG1, JPEG, H.261 or Cell and a regular frame buffer without a SunVideo board o Multiple SunVideo boards can be used in a single system to provide multi-channel video to a network SPARCstation 10 M system o Video capture and compression coupled with the SPARCstation 10SX provide a powerful video, imaging, graphics configuration o SX technology offers high-end imaging capability in a desktop system, making advanced imaging capability more affordable o SX image processor accelerates panning, zooming, rotating, various types of convolution and color space conversion, important capabilities for imaging applications o Fast decompression of video files helps video authoring and multimedia applications o Double buffering using standard memory routines supports smooth video playback o In addition to imaging, SX technology also accelerates 2-D and 3-D graphics. However when imaging is not important and 2-D and 3-D graphics performance is the key, the TurboGXplus(TM) and ZX frame buffers are more appropriate HARDWARE AND SOFTWARE CONSIDERATIONS ------------------------------------ - SunVideo requires Solaris 2.3 or later operating system - SPARCstation 10SX requires Solaris 2.3 or later operating system - Both multimedia packages require Solaris 2.3 - A CD-ROM drive is NOT included with the multimedia packages REMOVAL OF VIDEOPIX SOFTWARE AND DOCUMENTATION FROM THE PRICE LIST ------------------------------------------------------------------ VideoPix (X218A) will continue to ship as a Solaris 1.x image capture solution. The supporting software and documentation will be removed from the price list with this announcement. Only the bundled board with documentation and software will be offered. The following products will be removed from the price list: o VPX-1.0-4.1-4-21 Media, Documentation and License o VPX-1.0-X-X-9 Documentation only SCHEDULE TO REMOVE PRODUCT OFF THE PRICE LIST --------------------------------------------- o Last Quote: November 19, 1993 o Last Order: January 21, 1994 o Last Ship: March 1, 1994 There will be no upgrade offered from the VideoPix to the SunVideo board. AVAILABILITY ------------ - The SunVideo SBus card can be ordered immediately and will begin shipment November 8, 1993 - The Multimedia kit, SPARCclassic M and SPARCstation 10 M systems are orderable November 15 and will begin shipment December 13, 1993 QUESTIONS AND ANSWERS --------------------- Q. I have customers with VideoPix, can they upgrade to SunVideo? A. No, the low cost of these products do not make an upgrade path possible. VideoPix will continue as a Solaris 1.X image capture solution supported under Solaris 2.x by 3rd party software. Your users may find the full video capture of SunVideo a vast improvement over the low frame rate of VideoPix. Q. Will SunVideo be supported on other Solaris releases? A. SunVideo will be supported on 2.3 or later releases. No attempt will be made to go backwards. Q. What software ships with SunVideo? A. No software is included with SunVideo because it is part of Solaris 2.3. Application software is available from a number of vendors and will be part of the multimedia CDware disc offered in the bundles. Q. My customer wants to develop with SunVideo, what do they need? A. The Solaris 2.3 Software Developer's Kit (SDK) provides all the XIL and SunVideo support needed. Example programs with source code are part of the package. Q. How does SunVideo differ from other video cards for SPARC e.g. Parallax? A. SunVideo is a capture and compression board. It is designed for video conference application with software playback. Some applications will still want the more expensive solutions provided by Parallax Graphics. The Parallax boards include 24-bit frame buffers increasing the cost, but offering advantage for "viewing" video in a window. For full frame 640 x 480 JPEG video capture and compress the Xvideo and PowerVideo equipped with the CCube chip are still the right solutions. Most of our customers don't need that capability and don't want to pay that price. SECTION II COMPETITIVE COMPARISONS ----------------------- Video Boards are not standard and there are no direct measurements which can be used to compare them. Some of the features and benefits of different boards on different systems are highlighted. SPARC SBus cards: SunVideo - Multi Compression - JPEG, MPEG1, Cell (H.261 future) Low Cost without separate frame buffer Supported on all SPARC platforms Uses XIL for video format Parallax - JPEG compression and decompression (with optional CCube chip) Higher priced system includes 24-bit frame buffer Requires separate window system from Parallax Excellent video quality US$3,295 to US$10,595 Vitec - Punch through video only, no compression Formerly RasterOps board Low cost for video in a window US$1295 VideoMail- Punch through video or JPEG compression option US$1995 SGI Indy video: Basic - No hardware compression in base system Optional compression daughter card expected in US$4,000 range Software compression similar to Cell Not really ready for video conferencing as sold HP Workstations: RasterOps -Punch through video only, no compression InSoft has ported Communique! to this product Called VideoLive by HP Special priced US$1995 IBM RS/6000: Expected - DVI based compression and decompression Soon Pricing not announced IBM PC Compatibles: (Many software only compression cards) ActionMedia II - DVI based compression and decompression hardware required on every system high quality video but proprietary US$1995 and up Intel Smart Recorder - Software compression Will not do 30fps US$699 M&M Pro - Has JPEG daughter board option Capture and compress 30 fps at 320 by 240 US$2950 PictureTel - 2 board set for conferencing supports Px64 US$5995 U.S. PRICING AND ORDERING INFORMATION ------------------------------------- Order List Discount SunSpectrum Description Number Price Category Silver Price ------------------------------------------------------------------------------- Multimedia X-Options ==================== SunVideo X-option Board ---------------------- Video Capture and Compression SBus Board X1085A $1495 A N/C =============================================================================== Multimedia Kit -------------- SunVideo Board, Camera CDware CD (media only) X487A $1895 A N/C From rem-conf-request@es.net Wed Feb 16 14:04:56 1994 Received: from ninet.research.att.com by osi-west.es.net via ESnet SMTP service id <24898-0@osi-west.es.net>; Wed, 16 Feb 1994 11:04:28 +0000 Received: by research.att.com; Wed Feb 16 14:00 EST 1994 Date: Wed, 16 Feb 94 14:00:06 EST From: hgs@research.att.com (Henning G. Schulzrinne) To: rem-conf@es.net Subject: IBM acpa card/AIX Rumor has it that the acpa audio card for IBM systems can only be opened in simplex mode (either reading or writing). Is there a work-around? Thanks. Henning From rem-conf-request@es.net Wed Feb 16 16:57:42 1994 Received: from wugate.wustl.edu by osi-west.es.net via ESnet SMTP service id <27260-0@osi-west.es.net>; Wed, 16 Feb 1994 13:57:06 +0000 Received: by wugate.wustl.edu (5.67b+/WUSTL-0.3) with SMTP id AA09742; Wed, 16 Feb 1994 15:56:27 -0600 Received: by dworkin.wustl.edu (4.1/sendmail.cf=yuck-4.1) id AA02230; Wed, 16 Feb 94 15:57:16 CST Date: Wed, 16 Feb 94 15:57:16 CST From: zubin@dworkin.wustl.edu (Zubin Dittia) Message-Id: <9402162157.AA02230@dworkin.wustl.edu> To: end2end-interest@venera.isi.edu, f-troup@AURORA.CIS.UPENN.EDU, icad-request@santafe.edu, icad@santafe.edu, ietf@venera.isi.edu, ir-l@uccvma.bitnet, rem-conf-request@es.net, rem-conf@es.net, sigmedia@bellcore.com, sound@acm.org, tccc@cs.umass.edu Subject: ACM MULTIMEDIA '94 -- CALL FOR PAPERS NOTE: Please send all your responses and/or questions to the various program chairs listed in this posting; I am only concerned with publicity for the event, so do not direct any queries to me. Also, please accept my apologies if you receive more than one copy of this posting. -- Zubin. ====================================================================== ACM MULTIMEDIA 94 ----------------- October 15-20, 1994, San Francisco, California THE SECOND ACM INTERNATIONAL CONFERENCE ON MULTIMEDIA Sponsored by the Association for Computing Machinery SIGBIO, SIGBIT, SIGCHI, SIGCOMM, SIGGRAPH, SIGIR, SIGLINK, SIGMM, and SIGOIS in cooperation with SIGAPP, SIGCAPH, SIGCPR, SIGMOD, SIGOPS, and the IEEE Communications Society. CALL FOR PARTICIPATION ACM Multimedia 94 will provide an international forum for papers, panels, courses, workshops, and exhibits focusing on the synergies between processing and communicating information represented in multiple media (multimedia). Research ideas, emerging technologies, engineering methodologies, prototype demonstrations, and experiences should be submitted for review. Technical areas for Multimedia 94 include, but are not limited to: applications and tools; video information systems; interactive television; collaboration environments; database and information systems; distributed systems; operating system extensions; hardware and architectures; networking and communication; media integration and synchronization; image, video and audio compression techniques; programming paradigms and environments; storage and I/O architectures; and user interfaces. PAPERS: ------- Technical papers, preferably accompanied by electronic and videotape software, on completed or in-progress research, innovative applica- tions, or experience with multimedia systems are solicited. Where applicable, prototype demonstrations or videotape presentations are encouraged to supplement the talks. Outstanding papers on different areas of multimedia will be given awards. Selected papers will be forwarded to ACM/Springer-Verlag Multimedia Systems, the Communications of the ACM (CACM), the ACT Transactions on Information Systems, or the IEEE/ACM Transactions on Networking. Submit six copies of each paper (no more than 15 double-spaced pages including figures, tables, and references) and four copies of any accompanying videotape to: Prof. Domenico Ferrari, Program Chair Computer Science Division EECS Department University of California Berkeley, CA 94720 USA. Voice: +1 510 642 3806 Fax: +1 510 642 5775 Email: multimedia94@tenet.berkeley.edu PANELS: ------- We are soliciting proposals for panels that examine an innovative, controversial, or otherwise provocative issue of interest to the field. Panel proposals should include the issue to be addressed, the members of the panel with a brief statement of their positions on the issue, and a description of the panel format. The best panels, in our experience, have been structured as a debate with an opportunity for audience participation, but we are open to other stimulating ideas. Panels consisting of a collection of short paper presentations are not encouraged. The Panel chair is willing to work with prospective session chairs in advance of submission to discuss panel concepts or the form of a proposal. Panel proposals should be at most 3 pages, and should include a brief description of each panelist's relevant expertise. Submit six copies of each panel proposal to: Allan Kuchinsky, Panels Co-Chair Hewlett-Packard Co. 1501 Page Mill Rd. M/S 1U-17 Palo Alto, CA 94304 USA. Voice: +1 415 857 7423 Fax: +1 415 857 8526 Email: kuchinsk@hpl.hp.com COURSES: -------- Proposals (at most 5 pages, including biographical sketches of instructors) for both 1/2- and 1-day tutorial courses are solicited. Evaluation of proposals will be based on expertise and experience of instructors, relevance of subject matter, and the use of multimedia technology in the presentation. Submit six copies of each course proposal to: Ephraim Glinert, Courses Chair Department of Computer Science and Engineering FR-35 University of Washington Seattle, WA 98195 USA. Voice: +1 206 543 4305 Fax: +1 206 543 2969 Email: glinert@cs.washington.edu WORKSHOPS: ---------- During the first two days of Multimedia 94, we would like to hold workshops on specific areas of multimedia research and technology. Evening sessions during the main conference (last three days) will be held to report on the results of the workshops. For more information, contact: D. Shepherd, Workshops Chair Computer Center University of Lancaster Lancaster, UK LA1 4YW. Voice: 44-52-459-3827 Fax: 44-52-484-4011 Email: doug@comp.lancs.ac.uk EXHIBITS: --------- ACM Multimedia 94 offers a unique opportunity for vendors and researchers to exhibit and demonstrate multimedia products and research prototypes. For more information, contact: Multimedia 94 Exhibit Sales c/o Danieli & O'Keefe Associates, Inc. 490 Boston Post Road Sudbury, MA 01776 USA. Voice: +1 508 443 3330 Ext. 1227 Fax: +1 508 443 4715 Email: DOK.Boston@applelink.apple.com DEMONSTRATIONS: --------------- As part of ACM Multimedia 94, we plan to hold a referreed technical and artistic demonstration program. We solicit working systems that demonstrate the essence of multimedia: the integration of technologies and media (e.g., computers, television, facsimile, communications/networking, databases, user interfaces, hypermedia, operating systems, virtual reality, data compression, interface hardware, publishing, etc.). Submissions (at most 4 pages) should consist of a description of the exhibit, demo requirements, biography, and a single VHS video. Electronic submission of the description is encouraged. Send submissions to: Tom Little, Demonstrations Chair Department of Electrical and Computer Engineering Boston University 44 Cummington Street Boston, MA 02215 USA. Voice: +1 617 353 9877 Fax: +1 617 353 6440 Email: tdcl@spiderman.bu.edu VIDEO: ------ We are solicting videos of innovative multimedia technology. Videotape submissions should be between 5 to 8 minutes, and should be accompanied by a 2 page overview. We expect to show the Multimedia 94 Video Program in a special room in the Conference Center during the conference, and the videotape will be available for purchase. For more information, contact: Marc Brown or Dave Redell, Video Co-Chairs DEC Systems Research Center 130 Lytton Ave. Palo Alto, CA 94301 USA. Voice: +1 415 853 2152 or 2131 Fax: +1 415 853 2104 Email: {mhb,redell}@src.dec.com ELECTRONIC PUBLISHING: ---------------------- The proceedings of Multimedia 94 will be available both on CD-ROM and via electronic network. Accepted papers will be expected to be finally provided in several formats including postscript, and authors are strongly encouraged to provide about 2 minutes of video and also software and other relevant information that complements the content of the paper. For more information, contact: Roy Rada, Electronic Publishing Chair Department of Computer Science University of Liverpool Liverpool, UK L69 3BX. Voice: 44-51-794-3669 Fax: 44-51-794-3715 Email: rada@compsci.liverpool.ac.uk ---------------------------------------------------------------------------- STUDENT PARTICIPATION: ---------------------- Papers with a student as the primary author can enter the student paper award competition. A cover letter must identify the paper as a candidate for the competition. Graduate and undergraduate students are invited to participate in Multimedia 94. Student volunteers receive complimentary registration, complimentary meals and the opportunity to interact with conference attendees in return for helping with day-to-day operations of the conference. Housing costs for student volunteers may be reduced by sharing hotel rooms. IMPORTANT DATES: ---------------- All submissions due: March 10, 1994. Notification of acceptance: June 10, 1994. Submissions in final form due: July 20, 1994. ---------------------------------------------------------------------------- CONFERENCE COMMITTEE: --------------------- Co-Chairs: J. O. Limb, Hewlett-Packard. M. Blattner, Lawrence Livermore National Laboratory and University of California, Davis. Steering Committee Chair: E. Fox, Virginia Polytechnic Institute and SU. Treasurer: R. Allen, Bellcore. Proceedings: J.J. Garcia-Luna, University of California, Santa Cruz. Workshops: D. Shepherd, Lancaster University, UK. Demonstrations: T. Little, Boston University. Video: M. Brown, Digital Equipment Corporation. D. Redell, Digital Equipment Corporation. Elec. Publishing: R. Rada, University of Liverpool, UK. Panels: A. Kuchinsky, Hewlett-Packard. S. Bulick, US WEST Advanced Technologies. Courses: E. Glinert, Renssaeler Polytechnic Institute. Local Arrangements: J.D. Smith, Lawrence Livermore National Laboratory. Publicity: G. Parulkar, Washington University in St. Louis. PROGRAM COMMITTEE: ------------------ Chair: Prof. Domenico Ferrari Computer Science Division EECS Department University of California Berkeley, CA 94720 USA. +1 510 642 3806 multimedia94@tenet.berkeley.edu Co-Chairs: S. Ahuja, AT & T Bell Laboratories. F. Kitson, Hewlett-Packard. T. Kunii, University of Aizu, Japan. R. Phillips, Los Alamos National Laboratory. R. Rada, University of Liverpool, UK. R. Sacks-Davis, University of Melbourne, Australia. From rem-conf-request@es.net Wed Feb 16 17:45:05 1994 Received: from fnal.fnal.gov by osi-west.es.net via ESnet SMTP service id <27990-0@osi-west.es.net>; Wed, 16 Feb 1994 14:44:44 +0000 Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01H8YKTPPRLC00Q13N@FNAL.FNAL.GOV>; Wed, 16 Feb 1994 16:42:59 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA00401; Wed, 16 Feb 94 16:42:28 CST Date: Wed, 16 Feb 1994 16:42:28 -0600 From: Matt Crawford Subject: sun4m, panic: mclput To: rem-conf@es.net Message-id: <9402162242.AA00401@munin.fnal.gov> Content-transfer-encoding: 7BIT I've been following this group, but I didn't see the answer to my new problem. My new sparc-10/30 running 4.1.3 with patches 100173-09 (jumbo nfs) and 100726-12 (jumbo patch for kernel performance and memory bugs) crashed with the following stack trace. Neither patch touched any sys/net or sys/netinet files, but the latter patch did replace uipc_mbuf.o. _panic _mclput _m_freem _leintr level6 _splnet _rtfree _ip_output _encap_send _ip_mforward _ipintr _softint softlvl1 _klock_exit _idlework _main Any advice? T.I.A. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From rem-conf-request@es.net Wed Feb 16 18:17:48 1994 Received: from huey.udel.edu by osi-west.es.net via ESnet SMTP service id <28437-0@osi-west.es.net>; Wed, 16 Feb 1994 15:17:24 +0000 Received: by huey.udel.edu id aa02301; 16 Feb 94 18:10 EST Date: Wed, 16 Feb 94 18:03:37 EST From: Myrie@udel.edu To: rem-conf@es.net Subject: Please remove me from the mailing list. Message-ID: <9402161803.aa02268@huey.udel.edu> From rem-conf-request@es.net Thu Feb 17 03:14:25 1994 Received: from daiduk.kaist.ac.kr by osi-west.es.net via ESnet SMTP service id <03271-0@osi-west.es.net>; Thu, 17 Feb 1994 00:13:54 +0000 Received: from datacom1.kaist.ac.kr.noname by daiduk.kaist.ac.kr (4.1/KAISTNet-Relay-3.2) id AA15984; Thu, 17 Feb 94 17:09:54 KST Received: by datacom1.kaist.ac.kr.noname (4.1/SMI-4.1) id AA03588; Thu, 17 Feb 94 17:07:16 KST From: hskim%datacom1.kaist.ac.kr@daiduk.kaist.ac.kr (Kim Hyung Soo) Message-Id: <9402170807.AA03588@datacom1.kaist.ac.kr.noname> Subject: Looking for video board for PC To: rem-conf@es.net Date: Thu, 17 Feb 94 17:07:13 JST Cc: bcshin%datacom1.kaist.ac.kr@daiduk.kaist.ac.kr (Shin Byong Cheol) Is there anybody out there who help me? I was involved in Videoconferencing using PC. I used JPEG Video Development Kit from C-Cube MicroSystems(revision F board and version 1.0 software) for making videoconferencing system. But I found that this board compress the signal and store it in the hard disk. Moreover it does not compress the video signal by frame. It compresses the video at least 1 second unit and stores it to the hard disk. I tried to modify CL550.DLL but I found it very difficult. I need a video compression/decompression board(JPEG or MPEG) that can grab and compress video by frame and send it to another PC by networking rather than hard disk.(real time is required) If anyone knows that kind of board, please let me know. Any other advices on PC based videoconferencing will be helpfull. Thanks. Kim Hyoung Soo From rem-conf-request@es.net Thu Feb 17 08:06:02 1994 Received: from stone.ucs.indiana.edu by osi-west.es.net via ESnet SMTP service id <04631-0@osi-west.es.net>; Thu, 17 Feb 1994 05:04:42 +0000 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA01901; Thu, 17 Feb 94 08:04:13 EST Date: Thu, 17 Feb 1994 07:52:52 -0500 (EST) From: Allen Robel Subject: Re: Looking for video board for PC To: Kim Hyung Soo Cc: rem-conf@es.net, Shin Byong Cheol In-Reply-To: <9402170807.AA03588@datacom1.kaist.ac.kr.noname> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 17 Feb 1994, Kim Hyung Soo wrote: >I need a video compression/decompression board(JPEG or MPEG) that can grab >and compress video by frame and send it to another PC by networking rather >than hard disk.(real time is required) You might want to look at a product that Scientific-Atlanta sells. I've only got a short description and have not used it. Scientific-Atlanta, Inc. 4356 Communications Drive Norcross, Georgia 30093, USA 1 404 903-6001 1 404 903-6245 FAX The PC-Based DSR digital storage and retrieval platform are four IBM-compatible PC boards (real-time encoder, uplink interface to a digital multiplexer, transport card with conditional access, and decoder). It enables encoding, storage, distribution, and playback of ISO MPEG-standard data files. It is CCIR-601 and MPEG-compliant. Other features include CD-quality audio, "Genlock" capability, SCSI controller for each board, and customizable software for applications. Data rates from 1 to 8.3-Mbps are supported, along with I, B, and P frame encoding. DSR requires a PC/AT of 386/25 DX or higher. This probably doesn't packetize the output for you so you'd have to write something to do that if that's what you're after. They also sell the digital multiplexer described above which probably channelizes the video stream over a dedicated circuit to another multiplexer at the other end. Again, I've not used this product so take my interpretation with a grain of salt... Allen Robel Internet: robelr@indiana.edu Network Engineer voice: (812)855-0962 Indiana University FAX: (812)855-8299 From rem-conf-request@es.net Thu Feb 17 12:51:43 1994 Received: from forsythe.Stanford.EDU by osi-west.es.net via ESnet SMTP service id <07447-0@osi-west.es.net>; Thu, 17 Feb 1994 09:51:19 +0000 Date: Thu, 17 Feb 94 09:45:37 PST From: Andy DiPaolo To: rem-conf@es.net Subject: Please unsubscribe Please unsubscribe. To: REM-CONF@ES.NET From rem-conf-request@es.net Thu Feb 17 14:50:46 1994 Received: from june.cs.washington.edu by osi-west.es.net via ESnet SMTP service id <08809-0@osi-west.es.net>; Thu, 17 Feb 1994 11:50:16 +0000 Return-Path: Received: from localhost (glinert@localhost) by june.cs.washington.edu (8.6.4/7.1ju+) id KAA03147; Thu, 17 Feb 1994 10:49:14 -0800 Date: Thu, 17 Feb 1994 10:49:14 -0800 From: glinert@cs.washington.edu (Ephraim P. Glinert) Message-Id: <199402171849.KAA03147@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, sound@PASCAL.ACM.ORG, tccc@cs.umass.edu Subject: Call For Participation Hi! I'd like to bring the following to your attention, in the hope that you'll find it of interest. Please feel free to distribute this announcement to all your colleagues and friends. Thanks! \/\/\/\/\/\/\/\/\/\/\/ Call For Participation /\/\/\/\/\/\/\/\/\/\/\ ASSETS '94 The First Annual International ACM/SIGCAPH Conference on Assistive Technologies October 31-November 1, 1994, 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. The conference scope spans impairments and disabilities of all kinds, including but not limited to: sensory (hearing, vision, touch); motor (orthopedic); cognitive (learning, speech, mental); and emotional. Technical papers (up to 8 pgs in length) should be of the high quality expected at the best ACM conferences, and should either (a) present significant, original research results of a theoretical nature, or (b) report the results of relevant and rigorous empirical studies, or (c) describe the ``look and feel'' and discuss the internal workings of an implemented system. Where possible and appropriate, papers should be accompanied by a video to clarify and reinforce the concepts discussed. Panel proposals (up to 3 pgs in length) on timely and controversial topics are also welcome! All submissions will be refereed, and no more will be accepted than can be comfortably presented in a single track (no parallel sessions). Send 7 copies of full papers and 4 copies of panel proposals, all formatted in accordance with standard ACM two-column conference style, to the Program Chair: Ephraim P. Glinert Dept. of Computer Science and Engineering, FR-35 University of Washington Seattle, WA 98195 ALL SUBMISSIONS MUST BE RECEIVED NO LATER THAN APRIL 30, 1994. Questions should be directed to glinert@cs.washington.edu. NOTE: ASSETS'94 will immediately precede UIST'94, which will take place at the same site on November 2-4. See you in Marina del Rey! ======================================================================== General Chair: Theodor D. Sterling, Simon Fraser University Program Committee: Ephraim P. Glinert (Chair) University of Washington and RPI 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) Ralph Guertin, MITRE Corp. Robert J.K. Jacob, Naval Research Labs 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, Cornell University Gregg C. Vanderheiden, TRACE Center at U. Wisconsin A. Rudy Vener, AT&T Bell Labs Bryant W. York, Northeastern University From rem-conf-request@es.net Thu Feb 17 16:45:42 1994 Received: from Sun.COM by osi-west.es.net via ESnet SMTP service id <10417-0@osi-west.es.net>; Thu, 17 Feb 1994 13:45:22 +0000 Received: from Eng.Sun.COM (engmail1-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA07100; Thu, 17 Feb 94 13:44:26 PST Received: from rebma.noname by Eng.Sun.COM (4.1/SMI-4.1) id AB18619; Thu, 17 Feb 94 13:42:52 PST Received: by rebma.noname (4.1/SMI-4.1) id AA02208; Thu, 17 Feb 94 13:43:10 PST Date: Thu, 17 Feb 94 13:43:10 PST From: hoffman@rebma.Eng.Sun.COM (Don Hoffman) Message-Id: <9402172143.AA02208@rebma.noname> To: rem-conf@es.net Subject: Advance Notice of MBONE multicast: "SUNERGY #9 - Creativity in the Digital Domain" Cc: dhoward@doffice.Corp.Sun.COM, hoffman@Eng.Sun.COM, speer@Eng.Sun.COM Reply-To: Don.Hoffman@Eng.Sun.COM The following will be multicast on March 15, at 8:30 - 10:00 am PST. Session will be advertised one week before via sd. Questions or comments about the MBONE broadast to hoffman@eng.sun.com. For general questions or comments about the broadcast, contact sunergy@sun.com. Thanks, Don Hoffman email - hoffman@eng.sun.com, phone - +1 415 336 4339, fax - +1 415 336 6035 ----- Begin Included Message ----- NOTE: This program will be broadcast out on the MBONE and will be available for viewing in Sun MTV6 Stanford Room. Please forward this to any interested parties. ##################################### ***ANNOUNCING*** SUNERGY #9 LIVE/INTERACTIVE SATELLITE BROADCAST "CREATIVITY IN THE DIGITAL DOMAIN" MARCH 15, 1994 8:30 - 10:00 am PST ##################################### Multimedia, information highways, virtual corporations, electronic libraries...these terms are becoming commonplace in our daily language. Sunergy #9 will take a look at some of the current uses of digital data (how it is manipulated, stored, shared and accessed), what the latest applications look like and what the technical future holds in store. Guests include: John Gage (HOST) - Director of the Science Office, Sun Microsystems Computer Corporation Marc Andreessen - Enterprise Integration Technologies (EIT) Philip V.W. Dodds - Executive Director, Interactive Multimedia Association (IMA) Tom Van Sant, M.F.A. - Founder and CEO, The GeoSphere Project IF YOU HAVE SATELLITE RECEIVE CAPABILITIES AND WOULD LIKE THE SATELLITE COORDINATES* FOR THIS BROADCAST, EMAIL THE SUNERGY OFFICE AT sunergy@sun.com. (*As coordinates can vary from broadcast to broadcast, please be sure to contact the Sunergy office for the coordinates specific to this broadcast if you are planning to downlink this show.) ###################### GUEST BIOGRAPHIES ###################### Marc Andreessen, Enterprise Integration Technologies Marc Andreessen works for Enterprise Integration Technologies of Palo Alto, CA on commercial applications of Internet technologies. As an undergraduate he was one of the original two people behind NCSA Mosaic, a state-of-the-art Internet- based hypermedia information discovery and retrieval system now being used by hundreds of thousands of people in both industry and academia. He has a B.S. in Computer Science from the University of Illinois at Urbana-Champaign. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Philip V.W. Dodds, Executive Director, Interactive Multimedia Association Philip V.W. Dodds was named Executive Director of the Interactive Multimedia Association (IMA) in January 1993. Previous to being appointed Managing Director in March 1992, Mr. Dodds served as IMA Compatibility Project Director. As the founding Vice President of the Interactive Video Industry Association (now the IMA), his efforts on the IVIA's Compatibility Committee were a continuation of his work to establish compatibility among multimedia systems. Mr. Dodds began spending a major part of his time toward this goal more than five years ago. Prior to serving as IMA Compatibility Project Director, Mr. Dodds was project analyst and software engineer at Randall House Associates, Inc., in Annapolis, Maryland, a multimedia software consulting firm specializing in digital audio and desktop video products. In 1983, Mr. Dodds founded Visage, Inc., in Framingham, Massachusetts, a developer and manufacturer of multimedia products, including interactive video systems, digital audio products, development tools, and system software. He served as President, Chairman and CEO of Visage before joining Randall House Associates in 1989. Prior to 1983, Mr. Dodds served as Vice President, Engineering, of Kurzweil Music, during the development of Kurzweil's first digital keyboard products. Before his position at Kurzweil, Mr. Dodds was Vice President of Engineering for ARP Instruments, Inc. ARP was a leading manufacturer of professional music instruments and produced the first electronic keyboard that connected to Apple and IBM PC computers, a forerunner of the MIDI standard. After the sale of ARP to CBS, Inc., Mr. Dodds became Director of Engineering, Music Division, at CBS, where he was responsible for electric keyboard design for Fender Rogers Rhodes. Mr. Dodds has been appointed chairman of the Executive Committee for the National Association of Broadcasters (NAB) MultiMedia World Conference and Exhibition to be held in March 1994, having served in the same capacity for last year's conference. Also, he is editing a book entitled "The Digital Multimedia Cross-Industry Guide" to be published in early 1994. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tom Van Sant, M.F.A., Founder and CEO The GeoSphere Project Tom Van Sant is a sculptor, painter, muralist, architectural designer and environmental planner. In forty years of professional work he has executed over seventy major sculpture and mural commissions for public spaces around the world. These include the Central Lobby of Honolulu International Airport, the Los Angeles International Airport, the Taipei International Airport, the Pacific Mutual Life Insurance headquarters, the City of Inglewood Civic Center, the Century Park Sheraton Hotel in Manila and the Kona Surf, Wailea Beach and Yacht Harbor Hotels in Hawaii. Tom Van Sant has had fifteen one-man exhibits in the United States, Europe and Australia. His work is represented in both public and private collections around the world. He is also known for his innovative design of large-scale kites, which have been flown and exhibited in museums of art and museums of science around the world. In 1968 Van Sant served the Congressional Library and the Commandant of the Marine Corps as a war combat artist with the First Marine Division in Vietnam. Van Sant has done extensive work in environmental planning and architectural design, and has won three design awards from the American Institute of Architects. From 1967 to 1975 he served as Environmental Master Planner for the Los Angeles Community Redevelopment Agency, the City of Inglewood Civic Center, the Irvine Financial Plaza of Newport Beach, and the Davies Pacific Center in Honolulu. Long recognized for his attention to issues of scale and perception, Tom Van Sant's interest in space and technology have resulted in unique environmental projects. In 1980 he created "Reflections from Earth" for the City of Los Angeles Bicentennial, in cooperation with NASA and the U.S. Geological Survey. At 1.4 miles in size, it is the world's largest man-made image. A year later, Van Sant created the world's smallest man-made image, "Ryan's Eye". One-quarter micron large, "Ryan's Eye" was made in cooperation with The National Center for Sub-Micron Studies, Cornell University. His "Eyes On Earth From Space", a real-time zoom from a space satellite to the surface of the Earth, was commissioned by the Los Angeles Pacific Design Center in 1986. In 1989 Tom Van Sant founded, with associates from the scientific and art communities, the California Non-Profit Corporation EYES ON EARTH for environmental research and education, and the GeoSphere Project for dissemination of the products and systems developed by EYES ON EARTH. The GeoSphere products include the GeoSphere Image, the Earth Situation Room Network, the electronic Global Visual Library and the Global Ground-truth Monitoring System. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ John Gage - Director, Science Office, Sun Microsystems Computer Corporation John Gage works for Bill Joy, the Chief Technical Officer of Sun, and is responsible for Sun's relationships with the world scientific and public policy communities, international scientific institutions and groups developing new forms of scientific research involving computing. He is on scientific and advisory panels of the United States National Science Foundation, the US Congress Office of Technology Assessment, the European Institute of Technology and the United States National Academy of Sciences. He has recently been appointed to the US National Research Council Mathematical Sciences Education Board. He is a member of ACM, IEEE, SIAM, AMS, AAAS, and SMPTE. He attended the Harvard Business School and the Harvard Graduate School of Public Policy. He did doctoral work in economics and mathematics at the University of Berkeley at the same time as Bill Joy. Gage subsequently left Berkeley with Joy to start Sun in 1982. Gage is on the Board of Directors of Unicode, an industry consortium of IBM, Microsoft, Apple, Novell, Sun, GO Corporation, and others to provide multilingual capability in all world scripts for all documents and applications. ----- End Included Message ----- From rem-conf-request@es.net Thu Feb 17 17:36:19 1994 Received: from caip.rutgers.edu by osi-west.es.net via ESnet SMTP service id <11134-0@osi-west.es.net>; Thu, 17 Feb 1994 14:35:30 +0000 Received: by caip.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA02525; Thu, 17 Feb 94 17:35:26 EST Date: Thu, 17 Feb 94 17:35:26 EST From: azia@caip.rutgers.edu (Ashar Zia) Message-Id: <9402172235.AA02525@caip.rutgers.edu> To: rem-conf@es.net Subject: vat for DECalpha I downloaded the binary for vat (for DECalpha platform). But when I tried to use it I got the following error:- "SO_REUSEPORT: Option not supported by protocol" I probably need some different version for unix on my machine. If anyone had a similar problem please let me know how to fix it so that I can use vat on alpha. Thanx. -Ashar From rem-conf-request@es.net Thu Feb 17 20:13:38 1994 Received: from galaxy.net.Hawaii.Edu by osi-west.es.net via ESnet SMTP service id <13118-0@osi-west.es.net>; Thu, 17 Feb 1994 17:13:13 +0000 Received: by galaxy.net.Hawaii.Edu id <120555>; Thu, 17 Feb 1994 15:12:56 -1000 From: wkd@Hawaii.Edu (Winston Dang ) Message-Id: <9402171512.ZM5320@galaxy.net.Hawaii.Edu> Date: Thu, 17 Feb 1994 15:12:54 -1000 In-Reply-To: Anders Klemets "Re: Problems with Sun FDDI/S and IP Multicast" (Aug 30, 1:12am) References: <9308301112.AA25276@sics.se> X-Mailer: Z-Mail (2.1.5 20sep93) To: rem-conf@es.net Subject: IMM 3.3 is now available Hi All, I'd like to announce that IMM version 3.3 is now available at ftp.hawaii.edu in subdirectory /paccom/imm-3.3. The main idea behind this release is to provide an environment where many people with common interests can share GIF/JPEG images with many people (A many to many transmission model). To further promote a group environment, the following additions have been made: IMM has been redesigned to allow users to collect stat info to see who is watching and who is sending images. A log listbox shows the last 48 files received and who sent them. A new transmit listbox makes it as painless as possible to transmit images of your own. Name aliasing implemented to allow users to identify themselves. GIF files are now being accepted for transmission. The revised server program will still service the older client such as ver 2.7. I'd like to thank all the guys who helped get this project out. Thanks to Craig Ruff for providing the SGI irix 5 port. Thanks to John Brezak for providing the HPUX90 port. Thanks for Jim Martin for his code improvements. Thanks to Andrew Grossa, Kevin Mayeshiro and Ryan Lee for their generous input. Sincerely Winston Winston From rem-conf-request@es.net Thu Feb 17 22:09:38 1994 Received: from clavin.cs.tamu.edu by osi-west.es.net via ESnet SMTP service id <14223-0@osi-west.es.net>; Thu, 17 Feb 1994 19:08:59 +0000 Received: from photon.cs.tamu.edu (425@photon.cs.tamu.edu [128.194.134.1]) by cs.tamu.edu (8.6.4/8.6.4) with ESMTP id QAA15657 for ; Thu, 17 Feb 1994 16:43:07 -0600 From: Wei Zhao Received: from localhost (zhao@localhost) by photon.cs.tamu.edu (8.6.4/8.6.4) id QAA16810 for ieee_rtc_list; Thu, 17 Feb 1994 16:42:56 -0600 Date: Thu, 17 Feb 1994 16:42:56 -0600 Message-Id: <199402172242.QAA16810@photon.cs.tamu.edu> To: ieee_rtc_list@cs.tamu.edu Subject: IEEE Real-Time Systems Symposium 15th IEEE Real-Time Systems Symposium December 7-9, 1994 San Juan, Puerto Rico FIRST ANNOUNCEMENT AND CALL FOR PAPERS The purpose of this symposium is to bring together researchers and developers from academia, industry and government to advance the science and technology in real-time computing. Papers on all aspects of real-time computing are sought, including operating systems and scheduling, fault-tolerance, databases, programming languages, tools, communication networks, architectures, performance modeling, formal methods, case studies, and applications. Of particular interests are reports describing practical experiences and experimental results based on system building efforts, and real-time issues in applications such as avionics, multimedia, robotics, automated process control and manufacturing. Papers should describe original work, and be 20 double-spaced pages (5,000 words) or less in length. Synopses (5 double-spaced pages or less in length) of real-time applications, experimental results, and practical experiences in the design and development of real-time systems are also invited. The synopses should contain enough information for the program committee to understand the scope of the project and evaluate the novelty of the problem or approach. All accepted submissions will appear in the proceedings. Please send 5 copies of your submission to arrive by April 29, 1993 -- a FIRM deadline -- to the program chair at the following address. (Please include e-mail and fax number with the author's address.) Krithi Ramamritham, RTSS94 Dept. of Computer Science, LGRC Campus Box 34610 University of Massachusetts Amherst MA 01003-4610 e-mail: rtss94@cs.umass.edu Phone: (413) 545-0196 FAX: (413) 545-1249 Sponsor: IEEE Computer Society Technical Committee on Real-Time Systems General Chair: Farnam Jahanian, University of Michigan Program Chair: Krithi Ramamritham, University of Massachusetts, Amherst Program Committee: George Avrunin, Univ. of Mass. Amherst Azer Bestavros, Boston Univ. Alex Buchmann, Tech. Hochschule, Darmstadt Alan Burns, Univ. of York Flaviu Cristian, UC San Diego Wolfgang Halang, Fern Univ. Jayant Haritsa, Indian Institute of Science Michelle Hugue, Trident Systems Kane Kim, UC Irvine Hermann Kopetz, Tech. Univ. Vienna Christian Koza, Alcatel Austria John Lehoczky, CMU Jay Lala, Draper labs Jane Liu, Univ. of Illinois, Urbana Miroslaw Malek, Univ of Texas, Austin Al Mok, Univ of Texas, Austin Frank Olken, Lawrence Berkeley Labs Raj Rajkumar, SEI Parmesh Ramanathan, Univ. of Wisconsin Karsten Schwan, Georgia Tech. Alan Shaw, Univ of Washington Chia Shen, Mitsubishi Electric Research Labs Kang Shin, Univ. of Michigan Lorenzo Strigini, IEI-CNR, Pisa Jay Strosnider, CMU Morikazu Takegaki, Mitsubishi Electric Hide Tokuda, Keiu Univ. Satish Tripathi, Univ. of Maryland Frits Vaandrager, CWI, Amsterdam Tetsuo Wasano, NTT Victor Yodaiken, New Mexico IMT Publicity Chair: Wei Zhao (zhao@cs.tamu.edu), Texas A&M University Industrial Chair: Prabha Gopinath, Honeywell Local Arrangements Chair: Sandra Ramos-Thuel, AT&T Treasurer: Walter Heimerdinger, Honeywell Ex-Officio: Jack Stankovic (RTS-TC Chair) IMPORTANT DATES FIRM deadline for Papers/Synopses -- April 29, 1994 Acceptance Letters -- July 22, 1994 Camera-Ready Papers -- September 15, 1994 Symposium -- December 7-9, 1994 A one-day workshop on the ``Composability of Fault-Resilient Real-Time Systems'' is also being planned, to be held December 6, 1994. For further details, please contact Michelle Hugue (meesh@nemo.cs.umd.edu). From rem-conf-request@es.net Thu Feb 17 23:54:09 1994 Received: from clavin.cs.tamu.edu by osi-west.es.net via ESnet SMTP service id <14906-0@osi-west.es.net>; Thu, 17 Feb 1994 20:53:31 +0000 Received: from bochap (bochap.iss.nus.sg [137.132.248.11]) by cs.tamu.edu (8.6.4/8.6.4) with SMTP id TAA19176 for ; Thu, 17 Feb 1994 19:54:55 -0600 Received: from iss.nus.sg (piglet.iss.nus.sg) by bochap (4.1/SMI-4.1) id AA14250; Fri, 18 Feb 94 10:00:09+080 Message-Id: <9402180200.AA14250@bochap> To: ieee_rtc_list@cs.tamu.edu Cc: bhonsle@iss.nus.sg Subject: subscribe bhonsle@iss.nus.sg Date: Fri, 18 Feb 1994 10:00:08 +0800 From: Shailendra K Bhonsle subscribe bhonsle@iss.nus.sg From rem-conf-request@es.net Fri Feb 18 07:25:46 1994 Received: from en.ecn.purdue.edu by osi-west.es.net via ESnet SMTP service id <17399-0@osi-west.es.net>; Fri, 18 Feb 1994 04:25:27 +0000 Received: by en.ecn.purdue.edu (5.65/1.32jrs) id AA18159; Fri, 18 Feb 94 07:25:10 -0500 From: bhoja@ecn.purdue.edu (Sudeep Bhoja) Message-Id: <9402181225.AA18159@en.ecn.purdue.edu> Subject: Gateway between Serial link(H.320) & RTP. To: M.Handley@cs.ucl.ac.uk Date: Fri, 18 Feb 1994 07:25:09 -0500 (EST) Cc: casner@ISI.EDU, rem-conf@es.net X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1658 Mr. Handley, This is in reference to an earlier post on the suggestion of a VideoConferencing workstation for a distance education project at Purdue University. > .................. (Stuff deleted) > The workstation should also accept Serial link (ISDN) connections and > relay between serial link protocol (CCITT H.320) and RTP. I believe that > the SPARC 10 comes with an ISDN interface. Considering this and the > extra load to relay between H.320 & RTP, would SPARC 10 be a better choice? > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ............. (Stuff deleted). Your question about connecting between H.320 over ISDN and RTP glosses over a bunch of issues. The SS10 does have an ISDN interface, but I think the software is all for sending packets over that link, not video with H.221 framing. Also, trying to pick H.221 apart with the computer is VERY HARD AND UGLY. -- Steve I had a look at your paper on the "Piloting of MICE". I have reproduced a line from that. ** ..... to enable hardware codecs producing H.221 framed streams to be used (on packet networks), we have developed workstation software to add and remove H.221 framing. ** ************************************************************************** What are the issues involved in doing this? What kind of workstation does this software reside on? If there is any document that addresses this, please let me know. ************************************************************************** -Sudeep From rem-conf-request@es.net Fri Feb 18 07:51:32 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <17516-0@osi-west.es.net>; Fri, 18 Feb 1994 04:51:01 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Feb 1994 12:50:24 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: bhoja@ecn.purdue.edu (Sudeep Bhoja) cc: casner@ISI.EDU, rem-conf@es.net Subject: Re: Gateway between Serial link(H.320) & RTP. In-reply-to: Your message of "Fri, 18 Feb 94 07:25:09 EST." <9402181225.AA18159@en.ecn.purdue.edu> Date: Fri, 18 Feb 94 12:50:14 +0000 Sender: M.Handley@cs.ucl.ac.uk >Mr. Handley, > >This is in reference to an earlier post on the suggestion of a >VideoConferencing workstation for a distance education project at >Purdue University. > > > > .................. (Stuff deleted) > > The workstation should also accept Serial link (ISDN) connections and > > relay between serial link protocol (CCITT H.320) and RTP. I believe that > > the SPARC 10 comes with an ISDN interface. Considering this and the > > extra load to relay between H.320 & RTP, would SPARC 10 be a better choic > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > ............. (Stuff deleted). > Your question about connecting between H.320 over ISDN and RTP glosses > over a bunch of issues. The SS10 does have an ISDN interface, but I > think the software is all for sending packets over that link, not > video with H.221 framing. Also, trying to pick H.221 apart with the > computer is VERY HARD AND UGLY. Both Steve's comments here are very relevant! 1. ISDN. I don't know about in the US, but currently in Europe Sun only support PPP over a single B channel. To talk to a videophone or similar codec, you really want two B channels aggregated, and you need the ISDN signalling to tell the net and the other end that you're making a video call. If anyone knows of any software for Sun's ISDN that's available right now that can do this, we'd be really interested too. 2. H221. It's very icky. It was certainly never intended to be encoded or decoded in software! Having said that, I have a partial implementation which does work, as a gateway between H320 codecs and IVS. It's incomplete (doesn't support multiple B channels properly, doesn't support audio yet), but I hope I'll get another chance to work on those in the next month or two. If enough people are interested, I could make it a higher priority (maybe!). I can currently run it at up to 256Kb/s on a sparc 10, using an HSI/S card. Though the H.221 software should easily manage 512Kb/s, we're a bit limited by the very primitive HSI hardware. The most expensive part of this is that when you're generating H.221, you have to generate a CRC over all the video data. That and a hell of a lot of shifting :-) > I had a look at your paper on the "Piloting of MICE". I have reproduced > a line from that. > ** ..... to enable hardware codecs producing H.221 framed streams to be > used (on packet networks), we have developed workstation software to add > and remove H.221 framing. ** > >************************************************************************** > What are the issues involved in doing this? What kind of workstation does > this software reside on? The current implementation is on Suns running SunOS4.1.x. The SS10 is obviously significantly better at all of this than a SS2. > If there is any document that addresses this, please let me know. There's quite a lot of information on the MICE project on our WWW server: http://www.cs.ucl.ac.uk/mice/mice.html and http://www.cs.ucl.ac.uk/mice/index.html This was all demonstrated at the IETF in Amsterdam and at InterOp Paris in October. >************************************************************************** I will probably be able to release source code for some of this in a month or two. Please don't ask right now - I'd rather clean it up some first - too much of this is a result of reverse engineering codecs as the spec is so bad! I'll be away from email for the next week - I'll talk more when I get back. ----------------------------------------------------------------------------- Mark Handley Multimedia Integrated Conferencing for Europe (MICE) Project UCL Computer Science Gower Street London, UK From rem-conf-request@es.net Fri Feb 18 08:34:53 1994 Received: from philabs.philips.com by osi-west.es.net via ESnet SMTP service id <17801-0@osi-west.es.net>; Fri, 18 Feb 1994 05:34:31 +0000 Received: from mars.Philabs.Philips.Com by philabs.Philips.COM (smail2.5/12-15-87/4.1) id AA00156; Fri, 18 Feb 94 08:34:26 EST Received: by mars.Philabs.Philips.Com (4.1/SMI-4.1) id AA06505; Fri, 18 Feb 94 08:34:24 EST Date: Fri, 18 Feb 94 08:34:24 EST From: jec@philabs.Philips.COM (Jorge E. Caviedes) Message-Id: <9402181334.AA06505@mars.Philabs.Philips.Com> To: rem-conf@es.net Subject: teleconf software Hi, I am new to this group. Can somebody indicate where to get started? e.g. introductory notes, where to get the software (nv,etc), what are the requirements for Sun Sparc platforms, etc. thanks, Jorge Caviedes Philips Labs Briarcliff Manor, NY From rem-conf-request@es.net Fri Feb 18 10:14:53 1994 Received: from ludwig.ctd.ornl.gov by osi-west.es.net via ESnet SMTP service id <18516-0@osi-west.es.net>; Fri, 18 Feb 1994 07:14:28 +0000 Date: Fri, 18 Feb 1994 10:14:20 -0500 (EST) From: "Lawrence MacIntyre - 615.576.0824" To: azia@caip.rutgers.edu CC: rem-conf@es.net, LPZ@LUDWIG.CTD.ORNL.GOV Message-Id: <940218101420.604000c0@LUDWIG.CTD.ORNL.GOV> Subject: Re: vat for DECalpha Ashar: Multicast support will be in OSF/1 v2.0. Until then, running the mbone tools on Alphas is point-to-point only. Also, for vat to work, you need the AudioFile server (AF), which is available via anonymous FTP from gatekeeper.dec.com. Lawrence ~ ----------------------------------------------------------------------------- Internet: MACINTYRELP@ORNL.GOV RealWorld: Lawrence MacIntyre LPZ@ORNL.GOV AT&T: 615.576.0824 From rem-conf-request@es.net Fri Feb 18 10:34:43 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <18720-0@osi-west.es.net>; Fri, 18 Feb 1994 07:34:24 +0000 Received: from rover.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Feb 1994 15:33:49 +0000 To: rem-conf@es.net CC: mice-seminars@cs.ucl.ac.uk Subject: MICE Seminar for February 22 at 14:00 GMT. Date: Fri, 18 Feb 94 15:33:43 +0000 From: Gordon Joly You are invited to the next MICE International Seminar which will take place next week. Please limit traffic for two hours from 14:00 GMT on Tuesday, February 22. This seminar will be transmitted on the usual multicast addresses (please see the sd entry), and will be advertised in sd from Tuesday morning. Further information of this and future seminars is kept in the URL http://www.cs.ucl.ac.uk/mice/seminars.html Bruno Struif (GMD) speaking from Darmstadt, Germany will give a presentation on: "The Privacy Enhanced Electronic Prescription". Abstract -------- In Germany, more than 500 millions prescriptions are issued per year. Normally, the patient receives the prescription in the doctor's practice and takes it to a pharmacy where he gets his medicaments. From the pharmacy, the prescription is physically transported to a pharmacy computer center where it will be processed in different ways. Finally the patient health insurance gets this prescription with listings containing the result of the processing in the pharmacy computer center. Since the prescription is a paper document, the processing is difficult, time-consuming and cost-intensive. The introduction of the health insurance card in Germany will improve the technological environment in the doctor's practices.The prescriptions will be produced in the future by using the health insurance card, a personal computer and a printer. The model presented shows that the electronic presentation of the prescription produced in the doctor's PC can be maintained so that the difficult and expensive way of processing paper prescriptions in the pharmacy, the pharmacy's computer center and finally by the health insurance can be avoided. The solution described and already implemented at GMD is - to sign the electronic prescription by the doctor with its physician smartcard capable to compute digital signatures - to write the electronic prescription in the patient's smartcard - to prove the authorization of a pharmacist for the access to the patient's smartcard by using a pharmacist smartcard - to electronically transmit the electronic prescription together with pharmacy information (name of the pharmacy, prescription cost etc) to the pharmacy computer center or the health insurance computing center where it can be automatically processed. The patient gets therefore two representation forms of the prescription, the electronic form and the paper form. The paper form is still necessary in the relationship doctor/patient/pharmacist, since - the patient has a right to look on the issued prescription, - in case of malfunction of the patient's smartcard in the pharmacy the delivery of the medicaments has still to be possible and - the assembly of the medicaments is easier with a paper form in the hand. In the new release of the electronic prescription model a step in the direction of data privacy has been made. The personal data of the patient and the doctor are replaced by digital pseudonyms in a way that the pharmacy computing center and the health insurance can verify only certain characteristics, e.g. that the prescription has been issued by a registered doctor and that the related patient is a member of the respective health insurance. In special cases, a re-identification of the doctor or the patient is possible by using re-identification smartcards. Gordon Joly Phone +44 71 380 7934 FAX +44 71 387 1397 Email: G.Joly@cs.ucl.ac.uk UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly Comp Sci, University College, London, Gower Street, LONDON WC1E 6BT WWW WWW WWW http://www.cs.ucl.ac.uk/mice/gjoly.html WWW WWW WWW From rem-conf-request@es.net Fri Feb 18 11:07:49 1994 Received: from iraun1.ira.uka.de by osi-west.es.net via ESnet SMTP service id <19032-0@osi-west.es.net>; Fri, 18 Feb 1994 08:07:03 +0000 Received: from groucho.telematik.informatik.uni-karlsruhe.de by iraun1.ira.uka.de id <17164-0@iraun1.ira.uka.de>; Fri, 18 Feb 1994 17:06:27 +0100 Received: by groucho.telematik.informatik.uni-karlsruhe.de (5.65/DEC-Ultrix/4.3) id AA00570; Fri, 18 Feb 1994 17:06:23 +0100 Received: from localhost (localhost [127.0.0.1]) by pirelli.telematik.informatik.uni-karlsruhe.de (8.6.2/8.6.2) with SMTP id RAA00967 for rem-conf@es.net; Fri, 18 Feb 1994 17:06:17 +0100 Message-Id: <199402181606.RAA00967@pirelli.telematik.informatik.uni-karlsruhe.de> X-Authentication-Warning: pirelli: Host localhost didn't use HELO protocol To: rem-conf@es.net Subject: Re: vat for DECalpha In-Reply-To: Your message of "Thu, 17 Feb 94 17:35:26 EST." <9402172235.AA02525@caip.rutgers.edu> Date: Fri, 18 Feb 94 17:06:16 +0100 From: Oliver Frick X-Mts: smtp > I downloaded the binary for vat (for DECalpha platform). But when I tried to > use it I got the following error:- > "SO_REUSEPORT: Option not supported by protocol" This turns out to be and FAQ, so I post my experiences: The actually available vat binary kit seems to require multicast support (also in unicast mode!) and uses that ugly SO_REUSEPORT option when opening a socket. Yet, this socket option is not supported on OSF/1 v1.3. (I have tried vat with OSF/1 2.0 and it works.) So, the only solution to the problem I know is: Switch to OSF/1 2.0! There should be an official OSF/1 2.0 release pretty soon: > Sender: alpha-osf-managers-relay@sws1.ctd.ornl.gov > Date: Fri, 14 Jan 1994 13:17:00 -0500 > From: Sheila Hollenbaugh > Reply-To: Sheila Hollenbaugh > Followup-To: poster > To: alpha-osf-managers@ornl.gov > Subject: SUMMARY: Latest version of the OS > > > This may be the quickest summary on record. Dr. Tom Blinn of the DEC > UNIX Software Group (speaking on behalf of himself, and not the company, > of course, and all usual cautions apply on his behalf :-) says that the > next general release will not occur until late February or early March, > and it will be OSF 2.0. > > --Sheila > ------------------- > Sheila Hollenbaugh Sr. Computer Systems Engineer > Wright State University College of Engineering & Computer Science > Dayton, OH 45435 Voice: (513) 873-5077 FAX: (513) 873-5009 > shollen@cs.wright.edu or shollen@valhalla.cs.wright.edu but who knows ... BTW, are there any plans to make a *source* kit for vat available? The plug and play idea is o.k., but there is no "play" as soon as even little changes are necessary. (E.g, we run a different version of the AudioFile software which "only" requires a recompilation.) -- Oli. --------------------------------------------------------------------------- Oliver Frick | University of Karlsruhe | Informatics Department - Telecooperation Group Phone: +49-721-608-4046 | Kaiserstr. 12 Fax: +49-721-388097 | 76128 Karlsruhe | Germany Email: oli@tk.telematik.informatik.uni-karlsruhe.de --------------------------------------------------------------------------- ---- Abstinence is a good thing, but it should always be practiced in moderation ... ---- --------------------------------------------------------------------------- From rem-conf-request@es.net Fri Feb 18 12:07:58 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <19939-0@osi-west.es.net>; Fri, 18 Feb 1994 09:07:26 +0000 Received: from rover.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Feb 1994 17:05:36 +0000 To: rem-conf@es.net, mice-seminars@cs.ucl.ac.uk Subject: Re: MICE Seminar for February 22 at 14:00 GMT. In-reply-to: Your message of "Fri, 18 Feb 94 15:33:43 GMT." Date: Fri, 18 Feb 94 17:05:33 +0000 From: Gordon Joly Apologies: there was an error in the URL. Please see http://www.cs.ucl.ac.uk/mice/seminars/ Gordon. >>>>> On Fri, 18 Feb 94 15:33:43 GMT, Gordon Joly said: GCJ> -- using template mhl.format -- GCJ> From: Gordon Joly GCJ> Subject: MICE Seminar for February 22 at 14:00 GMT. GCJ> Return-Path: GCJ> You are invited to the next MICE International Seminar which will GCJ> take place next week. GCJ> Please limit traffic for two hours from 14:00 GMT on Tuesday, GCJ> February 22. This seminar will be transmitted on the usual multicast GCJ> addresses (please see the sd entry), and will be advertised in sd GCJ> from Tuesday morning. Further information of this and future seminars GCJ> is kept in the URL GCJ> http://www.cs.ucl.ac.uk/mice/seminars.html GCJ> Bruno Struif (GMD) speaking from Darmstadt, Germany will give a GCJ> presentation on: GCJ> "The Privacy Enhanced Electronic Prescription". GCJ> Abstract GCJ> -------- GCJ> In Germany, more than 500 millions prescriptions are issued per GCJ> year. Normally, the patient receives the prescription in the doctor's GCJ> practice and takes it to a pharmacy where he gets his GCJ> medicaments. From the pharmacy, the prescription is physically GCJ> transported to a pharmacy computer center where it will be processed GCJ> in different ways. Finally the patient health insurance gets this GCJ> prescription with listings containing the result of the processing in GCJ> the pharmacy computer center. Since the prescription is a paper GCJ> document, the processing is difficult, time-consuming and GCJ> cost-intensive. GCJ> The introduction of the health insurance card in Germany will improve GCJ> the technological environment in the doctor's practices.The GCJ> prescriptions will be produced in the future by using the health GCJ> insurance card, a personal computer and a printer. The model GCJ> presented shows that the electronic presentation of the prescription GCJ> produced in the doctor's PC can be maintained so that the difficult GCJ> and expensive way of processing paper prescriptions in the pharmacy, GCJ> the pharmacy's computer center and finally by the health insurance GCJ> can be avoided. GCJ> The solution described and already implemented at GMD is GCJ> - to sign the electronic prescription by the doctor with its physician smartcard GCJ> capable to compute digital signatures GCJ> - to write the electronic prescription in the patient's smartcard GCJ> - to prove the authorization of a pharmacist for the access to the patient's GCJ> smartcard by using a pharmacist smartcard GCJ> - to electronically transmit the electronic prescription together with pharmacy GCJ> information (name of the pharmacy, prescription cost etc) to the pharmacy GCJ> computer center or the health insurance computing center where it can be GCJ> automatically processed. GCJ> The patient gets therefore two representation forms of the GCJ> prescription, the electronic form and the paper form. The GCJ> paper form is still necessary in the relationship GCJ> doctor/patient/pharmacist, since GCJ> - the patient has a right to look on the issued prescription, GCJ> - in case of malfunction of the patient's smartcard in the pharmacy GCJ> the delivery of the medicaments has still to be possible and GCJ> - the assembly of the medicaments is easier with a paper form in the hand. GCJ> In the new release of the electronic prescription model a step in the GCJ> direction of data privacy has been made. The personal data of the GCJ> patient and the doctor are replaced by digital pseudonyms in a way GCJ> that the pharmacy computing center and the health insurance can GCJ> verify only certain characteristics, e.g. that the prescription has GCJ> been issued by a registered doctor and that the related patient is a GCJ> member of the respective health insurance. In special cases, a GCJ> re-identification of the doctor or the patient is possible by using GCJ> re-identification smartcards. GCJ> Gordon Joly Phone +44 71 380 7934 FAX +44 71 387 1397 GCJ> Email: G.Joly@cs.ucl.ac.uk UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly GCJ> Comp Sci, University College, London, Gower Street, LONDON WC1E 6BT GCJ> WWW WWW WWW http://www.cs.ucl.ac.uk/mice/gjoly.html WWW WWW WWW From rem-conf-request@es.net Fri Feb 18 15:34:24 1994 Received: from aplcomm.jhuapl.edu by osi-west.es.net via ESnet SMTP service id <23668-0@osi-west.es.net>; Fri, 18 Feb 1994 12:34:07 +0000 Received: from matrix.jhuapl.edu (bix-brg-mac.jhuapl.edu) by aplcomm.jhuapl.edu (4.1/SMI-4.1) id AA04459; Fri, 18 Feb 94 15:34:27 EST X-Mailer: InterCon TCP/Connect II 1.2 Message-Id: <9402181535.AA31373@matrix.jhuapl.edu> Date: Fri, 18 Feb 1994 15:35:31 -0500 From: Barry Raveendran Greene To: rem-conf@es.net Cc: greenebr@aplcomm.jhuapl.edu (Barry Raveendran Greene), Camil_Samaha@aplmail.jhuapl.edu, gregh@aplcomm.jhuapl.edu Subject: Advanced Notice: RAPID SYSTEM VIRTUAL PROTOTYPING (RSVP) SYMPOSIUM Hello, This is an advanced notice for a Mbone broadcast. We will be broadcasting the RSVP Symposium from 08:00 am - 6:00 pm on March 10, 1994. Please check SD for specifics. If you have any questions, please contact Camil Samaha or Barry Greene . Thanks, Barry Raveendran Greene Internet: greenebr@aplcomm.jhuapl.edu Network Engineer (301) 953-6064 (301) 953-5727 FAX Johns Hopkins University / Applied Physics Lab =========================================================================  RAPID SYSTEM VIRTUAL PROTOTYPING (RSVP) SYMPOSIUM Sponsored by: The Johns Hopkins University Applied Physics Laboratory In cooperation with: The IEEE Technical Committee on SIMULATION The IEEE Technical Committee on COMPUTER GRAPHICS The IEEE Technical Committee on DESIGN AUTOMATION DATE: MARCH 10, 1994 TIME: 8:45 am - 6:00 pm EST LOCATION: The Johns Hopkins University, Applied Physics Laboratory Johns Hopkins Road, Laurel, MD, USA General Chair: Paul Hazan, Johns Hopkins Applied Physics Laboratory Program Co-Chairs: Ken Anderson, Siemens Corporate Research Walter Beam, Consultant Nahum Gershon, The MITRE Corporation Stanley Winkler, The Winkler Group  ADVANCE PROGRAM RAPID SYSTEM VIRTUAL PROTOTYPING (RSVP) SYMPOSIUM SESSION 1: INTRODUCTION (8:45 am - 9:35 am) "WELCOME AND INTRODUCTION," Gary Smith, Director, JHU/APL "RSVP, CHALLENGES AND OPPORTUNITIES," Paul Hazan, JHU/APL "RSVP...TOOLS OF THE TRADE," Stanley Winkler, The Winkler Group "RSVP AND THE INFORMATION SUPERHIGHWAY," Mark Pullen, George Mason University "STANDARDS FOR OPEN SYSTEM ENVIRONMENTS IN RSVP," Gary Fisher, NIST SESSION 2: TOOLS (9:35 am - 12:40 pm) "RAPID PROTOTYPING USING PERSONAL VISUALIZATION SYSTEMS," Quentin Dolecek, JHU/APL "RAPID PROTOTYPING FOR 2-3D DATA VISUALIZATION," David Shreiner, Silicon Graphics "ARENA - A RAPID PROTOTYPING SIMULATION/MODELING LANGUAGE," Dennis Pegden, Systems Modeling Corporation "VISUAL ENGINEERING ENVIRONMENTS," Kerri Meyer, Hewlett Packard "VIRTUAL INSTRUMENTATION," Stepan Riha, National Instruments "ADVANCED SYSTEMS ENGINEERING AUTOMATION," Edward Comer, Software Productivity Solutions LUNCH BREAK (12:40 pm - 1:40 pm) SESSION 3: SYSTEMS APPLICATIONS (1:40 pm - 4:35 pm) "DISTRIBUTED VIRTUAL SIMULATIONS (DUAL USE APPLICATIONS)," David Bartlett, Defense Modeling and Simulation Office, and Mark Pullen, George Mason University "RAPID PROTOTYPING OF FUTURE AIR TRAFFIC MANAGEMENT CONCEPTS," Glenn Roberts, The MITRE Corporation "DIGITAL LIBRARY OF THE FUTURE," Nahum Gershon, The MITRE Corporation "MULTIMEDIA RAPID PROTOTYPING," Louis Biggie, JHU/APL "RAPID PROTOTYPING FOR NON-INVASIVE VISUALIZATION AND QUANTIFICATION OF CORONARY ARTERY DISEASE," Justin Pearlman, Harvard Medical School "RAPID PROTOTYPING OF THE ENVIRONMENT, ACCIDENT MANAGEMENT, AND REMOTE HEALTH CARE," Bernd Bruegge, Carnegie Mellon University SESSION 4: FLEXIBLE MANUFACTURING APPLICATIONS (4:35 pm - 6:00 pm) "VISUAL COMPUTING FOR MANUFACTURING SYSTEM PROTOTYPES," Nicholas Tarnoff, NIST  "SIMULATION-BASED DESIGN FOR COMPLEX SYSTEMS," Gary Jones, Maritime Systems Technology Office, ARPA "DESK-TOP MANUFACTURING USING 3-DIMENSIONAL PRINTING TECHNOLOGY," Emmanuel (Eli) Sachs, MIT "FUTURE DIRECTIONS," Walter Beam, Consultant; and Stanley Winkler, The Winkler Group  From rem-conf-request@es.net Fri Feb 18 16:52:59 1994 Received: from csi.ns.nts.uci.edu by osi-west.es.net via ESnet SMTP service id <24681-0@osi-west.es.net>; Fri, 18 Feb 1994 13:52:43 +0000 Received: by csi.ns.nts.uci.edu id AA01437 (5.65c/IDA-1.4.4 for rem-conf@es.net); Fri, 18 Feb 1994 13:52:39 -0800 Received: from [128.200.132.121] (red-october.nts.uci.edu) by csi.ns.nts.uci.edu with SMTP id AA01433 (5.65c/IDA-1.4.4 for rem-conf@es.net); Fri, 18 Feb 1994 13:52:22 -0800 Message-Id: <199402182152.AA01433@csi.ns.nts.uci.edu> X-Sender: kchong@mothra.nts.uci.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Feb 1994 13:52:29 -0800 To: rem-conf@es.net From: kchong@uci.edu (Keith Chong) Subject: Video out from a Sun Hi all, We are looking for some way to get composite video out from the a Sun Sparc IPX. Is Parallax the only choice we have. Is there any other manufacturer of Video out cards. How can we display the mbone tools on to a larger monitor(31" TV). Any help is much appreciated Keith Chong UCI OAC-ECS From rem-conf-request@es.net Fri Feb 18 17:07:39 1994 Received: from carson-oms1.u.washington.edu by osi-west.es.net via ESnet SMTP service id <24922-0@osi-west.es.net>; Fri, 18 Feb 1994 14:07:12 +0000 Received: from carson.u.washington.edu by carson-oms1.u.washington.edu (5.65+UW94/UW-NDC Revision: 2.30 ) id AA10103; Fri, 18 Feb 94 14:07:10 -0800 Date: Fri, 18 Feb 1994 14:07:10 -0800 (PST) From: Karl-Ake Omnell Subject: To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Unsubscribe rem-conf@es.net From rem-conf-request@es.net Fri Feb 18 19:34:37 1994 Received: from YFN.YSU.EDU by osi-west.es.net via ESnet SMTP service id <27171-0@osi-west.es.net>; Fri, 18 Feb 1994 16:34:12 +0000 Received: by yfn.ysu.edu id AA09810 (5.65c/IDA-1.4.4 for rem-conf@es.net); Fri, 18 Feb 1994 19:35:57 -0500 Date: Fri, 18 Feb 1994 19:35:57 -0500 Message-Id: <199402190035.AA09810@yfn.ysu.edu> From: as715@yfn.ysu.edu (John Meeks) To: rem-conf@es.net Subject: question Reply-To: as715@yfn.ysu.edu When you mention that there is going to be a brodcast and/ot a teleconfernce; it is mentioined to refrence the sd. What is that and where does one find that/ Thanks in advance for your response! JLM From rem-conf-request@es.net Sun Feb 20 20:12:16 1994 Received: from jarrah.itd.adelaide.edu.au by osi-west.es.net via ESnet SMTP service id <11360-0@osi-west.es.net>; Sun, 20 Feb 1994 17:11:59 +0000 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.28) id AA26322; Mon, 21 Feb 1994 11:41:47 +1030 Message-Id: <9402210111.AA26322@jarrah.itd.adelaide.edu.au> To: "Lawrence MacIntyre - 615.576.0824" Cc: rem-conf@es.net Subject: Re: vat for DECalpha In-Reply-To: Your message of "Fri, 18 Feb 1994 10:14:20 CDT." <940218101420.604000c0@LUDWIG.CTD.ORNL.GOV> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Feb 1994 11:41:47 +1030 From: Mark Prior Multicast support will be in OSF/1 v2.0. Until then, running the mbone tools on Alphas is point-to-point only. Also, for vat to work, you need the AudioFile server (AF), which is available via anonymous FTP from gatekeeper.dec.com. Multicast is available for 1.3 (I'm using it!) but it's not generally available. If you want it you should speak to your DEC support people nicely and they will track it down for you (or you can wait for 2.0 to ship in the next couple of months). Mark. From rem-conf-request@es.net Sun Feb 20 20:23:50 1994 Received: from mcigateway.mcimail.com by osi-west.es.net via ESnet SMTP service id <11417-0@osi-west.es.net>; Sun, 20 Feb 1994 17:23:18 +0000 Received: by MCIGATEWAY.MCIMail.com id fo05398; 21 Feb 94 0:30 GMT Received: from mcimail.com by MCIGATEWAY.MCIMail.com id bg17844; 19 Feb 94 6:43 GMT Date: Fri, 18 Feb 94 15:35 EST From: Lynda Greer <0004444851@mcimail.com> To: Zubin Dittia Cc: end2end interest Cc: f troup Cc: icad request Cc: icad Cc: ietf Cc: ir l Cc: rem conf request Cc: rem conf Cc: sigmedia Cc: sound Cc: tccc Cc: "borland." Subject: RE: ACM MULTIMEDIA '94 -- CALL FOR PAPERS Message-Id: <25940218203552/0004444851NA1EM@mcimail.com> Could someone please remove me from this list! Thank you Lynda From rem-conf-request@es.net Mon Feb 21 07:17:29 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <14827-0@osi-west.es.net>; Mon, 21 Feb 1994 04:17:06 +0000 Received: from rover.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 21 Feb 1994 12:16:37 +0000 To: rem-conf@es.net Subject: privacy and multicast Date: Mon, 21 Feb 94 12:16:33 +0000 From: Jon Crowcroft i have read a couple of things recently which imply people seem to believe that using thye mbonme is inherently less 'private' than other technology. this is wrong. if you have n sites that want to talk to each other, then you either send everything to a central site, and out again, or ypu have n*n-1/2 connections, or use multicast.... whatever, the number of links traversed is similar (though the number of times each link is trversed will be vastly worse for the middle case), you don't get any better privacy the only way to get privacy is to use encryption, either on all the links traversed, or better, at each source (or best, both) in fact, there seeemed to be a basic misunderstanding about security - although the mbone v. 2 was truncated broadcast (and 3 improves this to be delivery tree from soruce to listeners only), there is _no_ additional security through having control over the delivery tree in the internet, or lack of it in mbone 2. that is a misconception based on 'security through obscurity', or else in some idea that the links in a center based tree are somehow safer.... if the tree consisted of a single telco/pno/ptt's net, then this might just about be true (if you trust the telco:-) in the internet, you will be badly wrong if you believe this... cheers jon From rem-conf-request@es.net Mon Feb 21 14:51:26 1994 Received: from leland.Stanford.EDU by osi-west.es.net via ESnet SMTP service id <17873-0@osi-west.es.net>; Mon, 21 Feb 1994 11:51:10 +0000 Received: from popserver.Stanford.EDU (popserver.Stanford.EDU [36.21.0.17]) by leland.Stanford.EDU (8.6.5/8.6.5) with ESMTP id LAA22585; Mon, 21 Feb 1994 11:51:04 -0800 From: aubrey harris Received: from DialupEudora (tip-forsytheb.Stanford.EDU [36.170.0.13]) by popserver.Stanford.EDU (8.6.5/8.6.5) with SMTP id LAA09173; Mon, 21 Feb 1994 11:50:58 -0800 Date: Mon, 21 Feb 1994 11:50:58 -0800 Message-Id: <199402211950.LAA09173@popserver.Stanford.EDU> To: rem-conf@es.net Subject: Unsubscribe Cc: na.aha@forsythe.Stanford.EDU, aharris@leland.stanford.edu please unsubscribe From REM-CONF-request@es.net Mon Feb 21 15:50:29 1994 Received: from vms3.macc.wisc.edu by osi-west.es.net via ESnet SMTP service id <18409-0@osi-west.es.net>; Mon, 21 Feb 1994 12:50:13 +0000 Received: from VMSmail by vms3.macc.wisc.edu; Mon, 21 Feb 94 14:49 CDT Message-Id: <24022114493667@vms3.macc.wisc.edu> Date: Mon, 21 Feb 94 14:49 CDT From: Michael Dorl Subject: unsubscribe To: REM-CONF@ES.NET X-VMS-To: IN%"REM-CONF@ES.NET",DORL unsubscribe Michael Dorl (608) 262-0466 fax (608) 262-4679 dorl@vms.macc.wisc.edu MACC / University of Wisconsin - Madison dorl@wiscmacc.bitnet 1210 W. Dayton St. / Madison, WI 53706 From rem-conf-request@es.net Mon Feb 21 16:16:26 1994 Received: from Osprey.Telcom.Arizona.EDU by osi-west.es.net via ESnet SMTP service id <18654-0@osi-west.es.net>; Mon, 21 Feb 1994 13:15:49 +0000 Received: from helios.ece.arizona.edu by Arizona.EDU (PMDF V4.2-14 #2381) id <01H95F4OJ5VKCXQ93Q@Arizona.EDU>; Mon, 21 Feb 1994 14:15:34 MST Received: from gpacs1.ece.arizona.edu.cerl by helios.ece.arizona.edu; Mon, 21 Feb 94 14:15:27 MST Date: Mon, 21 Feb 1994 14:15:27 -0700 (MST) From: Gwi Moon Subject: Re: privacy and multicast To: J.Crowcroft@cs.ucl.ac.uk Cc: rem-conf-request@es.net, rem-conf@es.net Message-id: <9402212115.AA03128@helios.ece.arizona.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > From: Jon Crowcroft > > > i have read a couple of things recently which imply people seem to > believe that using thye mbonme is inherently less 'private' than other > technology. > > this is wrong. > > if you have n sites that want to talk to each other, then you either > send everything to a central site, and out again, or ypu have n*n-1/2 > connections, or use multicast.... > > whatever, the number of links traversed is similar (though the number > of times each link is trversed will be vastly worse for the middle case), > you don't get any better privacy > > the only way to get privacy is to use encryption, either on all the > links traversed, or better, at each source (or best, both) > > in fact, there seeemed to be a basic misunderstanding about security - > although the mbone v. 2 was truncated broadcast (and 3 improves this > to be delivery tree from soruce to listeners only), there is _no_ > additional security through having control over the delivery tree in > the internet, or lack of it in mbone 2. that is a misconception based > on 'security through obscurity', or else in some idea that the links > in a center based tree are somehow safer.... > > if the tree consisted of a single telco/pno/ptt's net, then this > might just about be true (if you trust the telco:-) > > in the internet, you will be badly wrong if you believe this... > > cheers > > jon > I am wondering about MBONE privacy for video conferencing. Suppose we want to conduct video conferencing with a specific group of sites participating and no one else. In this case, do we have to use enscription for the security? sd can detect the multicast sessions on MBONE and thus we can not restrict the participants. Anyboby has other solutions rather than enscription for privacy. Thank you Moon, Gwi From rem-conf-request@es.net Tue Feb 22 00:17:02 1994 Received: from wraith.internode.com.au by osi-west.es.net via ESnet SMTP service id <22067-0@osi-west.es.net>; Mon, 21 Feb 1994 21:16:43 +0000 Received: from simon.brain-space by wraith.internode.com.au with DMSP (5.64+1.3.1+0.50/UA-5.23) id AA02944; Tue, 22 Feb 1994 15:43:09 +1030 Date: Tue, 22 Feb 1994 15:43:09 +1030 Message-Id: <9402220513.AA02944@wraith.internode.com.au> To: rem-conf@es.net Subject: Re: privacy and multicast From: simon@internode.com.au (Simon Hackett) Reply-To: simon@internode.com.au Sender: simon@internode.com.au Repository: internode.com.au Originating-Client: brain-space > > I am wondering about MBONE privacy for video conferencing. > Suppose we want to conduct video conferencing with a specific group of sites > participating and no one else. > In this case, do we have to use enscription for the security? > sd can detect the multicast sessions on MBONE and thus we can not restrict > the participants. > Anyboby has other solutions rather than enscription for privacy. > If you really want a private multicast web between a set of sites, I can't see anything stopping you constructing your very own private MBONE equivalent on a smaller scale - just run a set of mrouted's between the networks that you wish to "mesh" into. And don't run mrouted's from any of those networks into the "real" MBONE at the same time. Otherwise, point to point connections will always be _relatively_ private (relatively in the sense that they can still be eavesdropped but they won't just get multicast to other sites in the Internet). Cheers, Simon ------------------------------------------------------------------------ "Simon Hackett, Internode Systems Pty Ltd" Phone: +61 8 373 1020 Fax: +61 8 373 4911 Mail: PO Box 69, Daw Park, SA 5041 AUSTRALIA From rem-conf-request@es.net Tue Feb 22 03:11:23 1994 Received: from Penny.Telcom.Arizona.EDU by osi-west.es.net via ESnet SMTP service id <23360-0@osi-west.es.net>; Tue, 22 Feb 1994 00:11:07 +0000 Received: from helios.ece.arizona.edu by Arizona.EDU (PMDF V4.2-14 #2381) id <01H961XMIZ0WCXQBV6@Arizona.EDU>; Tue, 22 Feb 1994 01:08:50 MST Received: from gpacs1.ece.arizona.edu.cerl by helios.ece.arizona.edu; Tue, 22 Feb 94 01:08:42 MST Date: Tue, 22 Feb 1994 01:08:42 -0700 (MST) From: Gwi Moon Subject: Re: privacy and multicast To: simon@internode.com.au Cc: mbone@isi.edu, rem-conf@es.net Message-id: <9402220808.AA13746@helios.ece.arizona.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > > Gwi Moon writes: > > > > I am wondering about MBONE privacy for video conferencing. > > Suppose we want to conduct video conferencing with a specific group of sites > > participating and no one else. > > In this case, do we have to use enscription for the security? > > sd can detect the multicast sessions on MBONE and thus we can not restrict > > the participants. > > Anyboby has other solutions rather than enscription for privacy. > > > Simon Hackett writes: > > If you really want a private multicast web between a set of sites, I > can't see anything stopping you constructing your very own private > MBONE equivalent on a smaller scale - just run a set of mrouted's > between the networks that you wish to "mesh" into. And don't run > mrouted's from any of those networks into the "real" MBONE at the > same time. > > Otherwise, point to point connections will always be _relatively_ > private (relatively in the sense that they can still be eavesdropped > but they won't just get multicast to other sites in the Internet). > > Cheers, > Simon > > ------------------------------------------------------------------------ > "Simon Hackett, Internode Systems Pty Ltd" > Phone: +61 8 373 1020 Fax: +61 8 373 4911 > Mail: PO Box 69, Daw Park, SA 5041 AUSTRALIA > Thanks Simon, I have never think about having a private multicast web between a set of sites. If some group of people want to develop their own multicast groups other than current MBONE network, this kind of subgroup may work more efficiently since it can get to its destination via shorter path. This may also reduce the network load. However, there must be only one mrouted running on each specific subnet of multicast subgroup. Any comment? What about other ways of achieving privacy with the current MBONE? Actually, we are developing remote consultation and diagnosis systems for medical applications. Privacy or security is an important issue involved in this project. To perform more realistic consultation, we decide to include video conferencing via MBONE network. We are currently considering to employ enscriptions for privacy. But, I think having a private multicast web may has its merits. Moon, Gwi ---- Moon, Gwi e-mail to ----->>moongw@ece.arizona.edu Lab: 602-621-6099 Computer Engineering and Research Laboratory(CERL) Carrel:602-621-6099 Dept. of Electrical & Computer Engineering Home: 602-884-1231 University of Arizona || Tucson, Arizona 85721 From rem-conf-request@es.net Tue Feb 22 03:38:14 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <23530-0@osi-west.es.net>; Tue, 22 Feb 1994 00:37:48 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 22 Feb 1994 08:37:33 +0000 To: Gwi Moon cc: rem-conf@es.net Subject: Re: privacy and multicast In-reply-to: Your message of "Mon, 21 Feb 94 14:15:27 MST." <9402212115.AA03128@helios.ece.arizona.edu> Date: Tue, 22 Feb 94 08:37:31 +0000 From: Jon Crowcroft It has been pointed out that my posting was a little obscure the point is that when worrying about privacy, the fact that the mbone has an "open" model of joining in and therefore getting traffic is not actually significantly less secure than unicast in the current internet - i can subvert routing to divert traffic to traverse my LAN, and get a view of unicast traffic, unless people do inter-router authentication, and link layer encryption it is a feature of the current mbone routing and host group model, partly, but it would be almost easier to add host<-> router IGMP authtentication, and thus make 'private' groups possible...especially with the advent of mrotue 3.1 and pruning.. >I am wondering about MBONE privacy for video conferencing. >Suppose we want to conduct video conferencing with a specific group of sites >participating and no one else. >In this case, do we have to use enscription for the security? you always do for assured privacy...do you want to authenticate who is listening too? >sd can detect the multicast sessions on MBONE and thus we can not restrict >the participants. >Anyboby has other solutions rather than enscription for privacy. for a good level of assurance, iff (thats if and only if) there is inter-router and host to router authentication, then it would be easy to devise an extension to provide private host groups in the mbone.... also, it is not true that you can 'trawl' the mbone from a host (e.g. via sd) for a particular multicast transmission - it is _not_ a broadcast net now it has pruiniing (even before pruning, traffic did not get onto a site lan unless a host was in a the group it was addressed to) - so to randomly join a mul,ticast transmission currently, you would have to join all possible multicast groups it is a feature of some of the applications that they send session messages, and of the way sd works that you can find out more, but still cannot randomly 'tune in' unless you know the addr.... but i still assert that IF you want to talk on the Internet, between N sites, then you get N*(N-1)/2 connections for a unicast approach, N inbound, and N outbound for a star (central video mixer) approach, and 1 address to listen on for multicast, but i can't see why people believe the first two to be inherently less private (or to put it another way, more expesnive to crack). steve deering may correct me! jon From rem-conf-request@es.net Tue Feb 22 07:35:04 1994 Received: from stone.ucs.indiana.edu by osi-west.es.net via ESnet SMTP service id <25004-0@osi-west.es.net>; Tue, 22 Feb 1994 04:34:46 +0000 Received: by stone.ucs.indiana.edu (4.1/9.7jsm) id AA14503; Tue, 22 Feb 94 07:34:19 EST Date: Tue, 22 Feb 1994 07:29:57 -0500 (EST) From: Allen Robel Subject: Re: privacy and multicast To: Jon Crowcroft Cc: Gwi Moon , rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >internet - i can subvert routing to divert traffic to traverse my LAN, >and get a view of unicast traffic, unless people do inter-router >authentication, and link layer encryption Or configure my router not to believe routing updates from your router (or only to believe updates for specific networks from your router), which is what normally is done. Too, I can configure my router to believe updates from your router only in the absence of updates from other, more "reliable/trustworthy" sources. Allen Robel Internet: robelr@indiana.edu Network Engineer voice: (812)855-0962 Indiana University FAX: (812)855-8299 From rem-conf-request@es.net Tue Feb 22 09:16:21 1994 Received: from KARIBA.BBN.COM by osi-west.es.net via ESnet SMTP service id <25483-0@osi-west.es.net>; Tue, 22 Feb 1994 06:15:41 +0000 Date: Tue, 22 Feb 94 9:15:03 EST From: Chip Elliott To: rem-conf@es.net Subject: Privacy vs. Security Jon, I'd argue that "privacy" and "security" are two different things, or perhaps that privacy is a very weak (but not zero) form of security. In life outside computer networks, I'd expect that my phone conversations are "more private" than any communication I made over say a taxicab radio. Neither of course is secure, but casual bystanders are unlikely to tap into my phone conversations. In the computer network world, it is currently child's play to eavesdrop on an IP multicast; but it's not at all easy to tap into an ST-II stream. That's because IP multicast is receiver directed -- anyone can tune in -- but ST-II is sender-directed. It's reasonable to say that ST-II multicast trees are private, but that IP multicast trees are open to all. Again, neither is *secure* without encryption. It's also interesting to compare how easy it is for a random bystander to *transmit* into a multicast tree. Again such jamming is fairly difficult with telephone-like systems, but quite easy with systems that look like broadcast media. -- Chip From rem-conf-request@es.net Tue Feb 22 10:37:04 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <26079-0@osi-west.es.net>; Tue, 22 Feb 1994 07:36:34 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 22 Feb 1994 15:35:21 +0000 To: Gwi Moon cc: simon@internode.com.au, mbone@ISI.EDU, rem-conf@es.net Subject: Re: privacy and multicast In-reply-to: Your message of "Tue, 22 Feb 94 01:08:42 MST." <9402220808.AA13746@helios.ece.arizona.edu> Date: Tue, 22 Feb 94 15:35:20 +0000 From: Jon Crowcroft >I have never think about having a private multicast web between a set of sites. >If some group of people want to develop their own multicast groups other than >current MBONE network, this kind of subgroup may work more efficiently since >it can get to its destination via shorter path. This may also reduce the network >load. However, there must be only one mrouted running on each specific subnet >of multicast subgroup. Any comment? the current mbone is fairly carefully engineered (not everywhere, but most places) to know about the real underlying topology. If you have a set of sites that are disjoint, and have no other mbone traffic, you could certainly construct a seperate mbone. Also if you replicate mbone routers at sites, and somehow restrict the host groups to only join to the 'mbone' of your choice (i don't know how to do this !), then simon's approac is valid. Otherwise, you may increase the net traffic. >What about other ways of achieving privacy with the current MBONE? as i said, what is the issue? - if you dont advertise in sd, then how do people get to find out about your traffic/group address? answer: they don't easily... >We are currently considering to employ enscriptions for privacy. But, I think >having a private multicast web may has its merits. yes, a virtual private multicast internet! not a bad interim hack... jon From rem-conf-request@es.net Tue Feb 22 11:14:42 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <26533-0@osi-west.es.net>; Tue, 22 Feb 1994 08:14:23 +0000 Received: from kant.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 22 Feb 1994 16:13:39 +0000 To: Chip Elliott cc: rem-conf@es.net, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Privacy vs. Security In-reply-to: Your message of "Tue, 22 Feb 94 09:15:03 EST." Date: Tue, 22 Feb 94 16:13:38 +0000 From: Jon Crowcroft >In the computer network world, it is currently >child's play to eavesdrop on an IP multicast; but it's >not at all easy to tap into an ST-II stream. That's >because IP multicast is receiver directed -- anyone >can tune in -- but ST-II is sender-directed. i don't accept that it is necessarily childs play. i can think of easy ways to make it hard - in fact, i don't believe most people who use the mbone are aware of more than a small fracti0on of the dynamic multicast address space use ... but i do think you've characterised the view very nicely... >It's reasonable to say that ST-II multicast trees are >private, but that IP multicast trees are open to all. >Again, neither is *secure* without encryption. totally agree! >It's also interesting to compare how easy it is >for a random bystander to *transmit* into a multicast >tree. Again such jamming is fairly difficult with >telephone-like systems, but quite easy with systems >that look like broadcast media. that is an excellent point too! the denial of service problem is amplified by multicast (though that'd be true of ST too...though somewhat less so) jon From rem-conf-request@es.net Tue Feb 22 13:32:29 1994 Received: from sirius.ctr.columbia.edu by osi-west.es.net via ESnet SMTP service id <28888-0@osi-west.es.net>; Tue, 22 Feb 1994 10:32:03 +0000 Received: from navajo.ctr.columbia.edu (eleft@navajo.ctr.columbia.edu [128.59.66.22]) by sirius.ctr.columbia.edu (8.6.5/8.6.4.287) with ESMTP id NAA29782; Tue, 22 Feb 1994 13:31:55 -0500 Received: from localhost (eleft@localhost) by navajo.ctr.columbia.edu (8.6.5/8.6.4.788743) with SMTP id NAA24077; Tue, 22 Feb 1994 13:31:53 -0500 Message-Id: <199402221831.NAA24077@navajo.ctr.columbia.edu> To: Chip Elliott cc: rem-conf@es.net Subject: Re: Privacy vs. Security In-reply-to: Your message of "Tue, 22 Feb 1994 09:15:03 EST." <199402221539.KAA27182@sirius.ctr.columbia.edu> Date: Tue, 22 Feb 1994 13:31:50 -0500 From: Alexandros Eleftheriadis On Tue, 22 Feb 94 9:15:03 EST, Chip Elliott wrote: Jon, I'd argue that "privacy" and "security" are two different things, or perhaps that privacy is a very weak (but not zero) form of security. [stuff deleted] It's also interesting to compare how easy it is for a random bystander to *transmit* into a multicast tree. Again such jamming is fairly difficult with telephone-like systems, but quite easy with systems that look like broadcast media. These are both very good points. Since this (and related) subjects seem to surface here from time to time, I thought I'd mention that there are ways to incorporate private (not secure) sessions into the existing multicast architecture of IP, together with distributed address management. This can also partially take care of the jamming problem. I refer interested people to a paper I wrote with S. Pejhan and D. Anastassiou, and that is available by anonymous FTP at ftp.ctr.columbia.edu, /CTR-Research/advent/public/papers/93/eleft93b.ps.Z. --Alexandros From rem-conf-request@es.net Tue Feb 22 13:35:28 1994 Received: from KARIBA.BBN.COM by osi-west.es.net via ESnet SMTP service id <28988-0@osi-west.es.net>; Tue, 22 Feb 1994 10:35:12 +0000 Date: Tue, 22 Feb 94 13:34:49 EST From: Chip Elliott To: rem-conf@es.net Subject: Enhancing Mbone Privacy I agree with Jon that the mbone provides perfectly adequate privacy (since its address space is so large) even without any real security. Not as good as the telephone system, I'm sure, but certainly good enough for most of us. I'm not sure that anyone has bothered to write this down, but this privacy could be perhaps be enhanced by a few simple techniques. First, I could split up my transmissions and send packets over various multicast addresses. Second I could switch addresses every so often, ie, do some frequency hopping. Then all I need to do is encrypt a little bit of information, eg, the schedule for which addresses are used when, and I'd have good privacy. (Assuming that no one had access to a link where they could simply capture all the packets!) It would also make jamming and traffic analysis hard. Of course, it would stress the routers a bit as multicast trees would be coming and going. Possibly it would increase the variance in packet arrival times, but I'm not sure that it would. So much for my simple sketch. Now, I'd be interested to know if anyone has been seriously thinking of using these techniques on multicast IP (whether or not in combination with encrypted media streams). It seems computationally cheaper than actually encrypting all the media though of course not really secure. -- Chip From rem-conf-request@es.net Wed Feb 23 07:55:05 1994 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <10725-0@osi-west.es.net>; Wed, 23 Feb 1994 04:54:49 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA09336; Wed, 23 Feb 94 04:55:29 -0800 Message-Id: <9402231255.AA09336@rx7.ee.lbl.gov> To: Chip Elliott Cc: rem-conf@es.net Subject: Re: Enhancing Mbone Privacy In-Reply-To: Your message of Tue, 22 Feb 94 13:34:49 EST. Date: Wed, 23 Feb 94 04:55:28 PST From: Van Jacobson I'm afraid I don't understand the point of `security through obscurity' addressing kludges. They put an unreasonable burden on the network, they're much harder for the end users to set up, they provide little, if any, privacy enhancement over the existing pruned multicast, and, as almost everyone has noted, they don't really solve the problem. If you want privacy, why not use machinery that provides privacy? Vat & wb packets all start with random numbers (to be immune to known plaintext attacks) and can be encrypted with cipher-block-chained triple DES. So far as I know, this means that only people with the key (and, of course, the NSA) can listen in. Since the encryption and decryption code run at 5 Mb/s on a crummy old IPX, you get good privacy at a maximum cost of 1.3% of your cpu for a typical 64Kb/s audio conference. Why do nasty things to the multicast routers, and in the process through away most of your privacy, for a 1% gain in cpu cycles? - Van From rem-conf-request@es.net Wed Feb 23 09:29:36 1994 Received: from KARIBA.BBN.COM by osi-west.es.net via ESnet SMTP service id <11267-0@osi-west.es.net>; Wed, 23 Feb 1994 06:29:05 +0000 Date: Wed, 23 Feb 94 9:28:32 EST From: Chip Elliott To: Van Jacobson cc: rem-conf@es.net Subject: Re: Enhancing Mbone Privacy Van, As mentioned in my postings, I'm quite content with the (virtually nonexistent) privacy that I already have on the mbone; and I think we all know that if we wanted real security we would not be using any of the techniques we've been talking about. In particular, I'm not advocating "security through obscurity". Where security is really an issue, neither obscurity nor DES suffice. And masking traffic becomes interesting... I *do* think it would be useful to experiment with frequency hopping techniques, to see how well routers could handle this kind of usage. As multicast becomes universally available, without some kind of closed-group mechanism, we may well see people using this technique. (Like it or not!) As a further aside, I guess I'm thinking of much heavier dataflows than 64kbs audio. A couple of windows of good-quality video would chew up a lot more cycles to encrypt/decrypt. In short, it may be that "security" is sufficiently more expensive than "privacy" that a noticeable fraction of multicast users adopt mechanisms that you are not happy with, ie, will use techniques other than encryption. In particular they may not be using vat, wb, and nv! -- Chip From rem-conf-request@es.net Thu Feb 24 17:16:20 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <28383-0@osi-west.es.net>; Thu, 24 Feb 1994 01:08:36 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Thu, 24 Feb 1994 01:08:33 -0800 Posted-Date: Thu 24 Feb 94 01:07:41 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 24 Feb 94 01:07:42 PST Date: Thu 24 Feb 94 01:07:41 PST From: Stephen Casner Subject: Re: Enhancing Mbone Privacy To: celliott@bbn.com, van@ee.lbl.gov Cc: rem-conf@es.net Message-Id: <762080861.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199402231616.AA29051@venera.isi.edu> Mail-System-Version: Chip, > I *do* think it would be useful to experiment with > frequency hopping techniques, to see how well routers could handle > this kind of usage. As multicast becomes universally available, > without some kind of closed-group mechanism, we may well see > people using this technique. (Like it or not!) I cannot see any value in this technique. In radio, spread spectrum has a number of advantages, but in multicast, it only serves to make the multicast routing more expensive. I am by no means a security expert, but I don't think anyone uses spread spectrum for serious security, except perhaps as the first line of defense. It seems that the primary value is in avoiding interference such as jamming. In the (wired) packet world, the most appropriate techniques to avoid jamming would be much different (such as cutting off traffic as close as possible to the source). > As a further aside, I guess I'm thinking of much heavier > dataflows than 64kbs audio. A couple of windows of good-quality > video would chew up a lot more cycles to encrypt/decrypt. The level of privacy we desire can be achieved by encrypting only part of the higher-rate data, thereby bringing it back into the realm of feasibility. -- Steve ------- From rem-conf-request@es.net Thu Feb 24 17:16:26 1994 Received: from sanson.dit.upm.es by osi-west.es.net via ESnet SMTP service id <00763-0@osi-west.es.net>; Thu, 24 Feb 1994 05:40:31 +0000 Original-Received: from yeti.dit.upm.es by sanson.dit.upm.es (5.65c/1.6.28) Thu, 24 Feb 1994 14:27:39 +0100 PP-warning: Illegal Received field on preceding line Original-Received: by yeti.dit.upm.es (5.65c/1.6.28) Thu, 24 Feb 1994 14:27:35 +0100 PP-warning: Illegal Received field on preceding line Date: Thu, 24 Feb 1994 14:27:35 +0100 From: quemada@dit.upm.es (Juan Quemada Vives) Message-Id: <199402241327.AA19110@yeti.dit.upm.es> To: distribution: @yeti.dit.upm.es:; (see end of body) .gr>, Asko Vilavaara , Markku Savela , Atte Kortekangas Atte.Kortekangas@tic.vtt.fi>, Seamus Kearney , Denise Puech , Markku Renfors , Subject: SS'94 Dear colleagues, Please find attached the preliminary announcement of the "Second International Summer School on Advanced Broadband Communications" (SS'94) to take place from 11th to 15th July 1994. Juan Quemada =================================================================== SS'94 Second International Summer School on Advanced Broadband Communications July 11-15 1994 =================================================================== After the success of the "First International Summer School on Advanced Broadband Communications - Towards ABC" distributed between Aveiro (Central Site) and Madrid in July 93, RACE Project BRAIN is pleased to announce its ``Second International Summer School on Advanced Broadband Communications" to take place from 11th to 15th July 1994. This year the School will be distributed to at least four different and geographically distant sites and will constitute a unique event joining a thorough presentation of ABC (Advanced Broadband Communications) with it's real use and demonstration. It will include tutorials, in depth lectures, panels and active syndicate sessions covering the most relevant topics of ABC. Among others: - Cell based technologies (ATM, Frame Relay, SMDS). - Access Networks: Mobility, LANs, ATM, ... - Network interconnection. - Corporate and Virtual Private Networks. - Cost Modeling. - Systems Engineering and ABC. - Management of ABC Systems. - Multimedia Interfaces and Applications. - Entertainment and ABC. Most important, the 1994 Summer School itself will be a demonstration of ATM based broadband communications, applications and services were the results from different RACE projects will be shown in real operation. The 1994 Summer School will be a distributed event where a multimedia CSCW (Computer Supported Cooperative Work) tele-education application will join the lecture rooms of the different physical sites into a unique virtual lecture room such that lecturers and participants loose the sense of physical separation and work together with full interaction. At least, the following sites will join SS'94: - ETSI Telecomunicacion, Madrid-Spain (Central Site) - University of Aveiro, Aveiro-Portugal - CET, Aveiro-Portugal - TIDSA, Madrid-Spain Feasibility studies are underway for incorporating more sites. Existing trans-national ATM links connecting European Broadband Islands provide the necessary communication infrastructure for SS'94. This will require a complex collaboration between several projects most of them belonging to the RACE program. For example, the ISABEL-IBER projects will provide the RIA (Aveiro-Portugal) and RECIBA (Madrid-Spain) Broadband Islands interconnection, thus supplying the core infrastructure of SS'94. In addition, feasibility studies are underway with RACE Projects CATALYST, EXPLOIT and BETEUS and with the Spanish Tele-education project ETSIT for interconnecting more sites in Switzerland, France, Germany and Spain. ORGANIZING COMMITTEE Rui Aguiar, University of Aveiro, Portugal Jerome Camus, Institut Theseus, France Pedro Chas, Telefonica, Spain Pierre Courtois, AIB, Belgium John Dobson, University of Newcastle, UK Jose Domingues, CET, Portugal (BRAIN Project Manager) Manuel Duarte, University of Aveiro, Portugal (Aveiro Site SS'94 Manager) Klaus Franke, Technical University of Chemnitz, Germany Jeff Gould, Data Strategies, France Vasco Lagarto, CET, Portugal Pierre Lagasse, University of Gent, Belgium Hans Melchior, Swiss Federal Institut of Technology, Switzerland Tomas de Miguel, Technical University of Madrid, Spain John O'Reilly, University College North Wales, UK Steven Plagemann, SHP Systems Services, Ireland (BRAIN Technical Manager) Juan Quemada, Technical University of Madrid, Spain (SS'94 Manager) Silvia Ruiz, Technical University of Catalunya, Spain Eric Scharf, Queen Mary Westfield College, UK Reg Teesdale, SESTEL, France I Venieris, National Technical University of Athens, Greece Robert Vinckier, SHP Systems Services, Belgium George Williamson, British Telecom, UK ================================================================= If you are interested in receiving direct information about SS'94 please send the following questionnaire by mail, fax or e-mail to: Dept Ing. Telematica (SS'94) ETSI Telecomunicacion E-28040 Madrid, Spain tf: +34 1 3367332, fax: +34 1 3367333, email: SS94@dit.upm.es ================================================================= Name: Company: Address: Telephone: Fax: Email: ================================================================= \documentstyle[12pt]{article} \setlength{\oddsidemargin}{0cm} \setlength{\evensidemargin}{0cm} \setlength{\textwidth}{17cm} \setlength{\textheight}{25cm} \setlength{\topmargin}{-3cm} \begin{document} \setlength{\parindent}{0mm} \setlength{\parskip}{2mm} \thispagestyle{empty} \pagestyle{empty} \begin{center} \rule{17cm}{2mm} {\Huge \bf SS'94} {\LARGE \bf Second International Summer School on} {\LARGE \bf Advanced Broadband Communications} {\Large \bf July 11-15 1994} \rule{17cm}{2mm} \end{center} After the success of the ``First International Summer School on Advanced Broadband Communications - Towards ABC" distributed between Aveiro (Central Site) and Madrid in July 93, RACE Project BRAIN is pleased to announce its ``Second International Summer School on Advanced Broadband Communications" to take place from 11th to 15th July 1994. This year the School will be distributed to at least four different and geographically distant sites and will constitute a unique event joining a thorough presentation of ABC (Advanced Broadband Communications) with it's real use and demonstration. It will include tutorials, in depth lectures, panels and active syndicate sessions covering the most relevant topics of ABC. Among others: \begin{quote} - Cell based technologies (ATM, Frame Relay, SMDS). \\ - Access Networks: Mobility, LANs, ATM, ... \\ - Network interconnection. \\ - Corporate and Virtual Private Networks. \\ - Cost Modeling. \\ - Systems Engineering and ABC. \\ - Management of ABC Systems. \\ - Multimedia Interfaces and Applications. \\ - Entertainment and ABC. \end{quote} Most important, the 1994 Summer School itself will be a demonstration of ATM based broadband communications, applications and services were the results from different RACE projects will be shown in real operation. The 1994 Summer School will be a distributed event where a multimedia CSCW (Computer Supported Cooperative Work) tele-education application will join the lecture rooms of the different physical sites into a unique virtual lecture room such that lecturers and participants loose the sense of physical separation and work together with full interaction. At least, the following sites will join SS'94: \begin{quote} - ETSI Telecomunicacion, Madrid-Spain (Central Site) \\ - University of Aveiro, Aveiro-Portugal \\ - CET, Aveiro-Portugal \\ - TIDSA, Madrid-Spain \end{quote} Feasibility studies are underway for incorporating more sites. %, such as % ASCOM (Basel-Switzerland), ETSI Telecomunicacion (several locations in % Spain), Technical University of Chemnitz (Chemnitz-Germany), Institut % THESEUS (Nice-France), .. Existing trans-national ATM links connecting European Broadband Islands provide the necessary communication infrastructure for SS'94. This will require a complex collaboration between several projects most of them belonging to the RACE program. For example, the ISABEL-IBER projects will provide the RIA (Aveiro-Portugal) and RECIBA (Madrid-Spain) Broadband Islands interconnection, thus supplying the core infrastructure of SS'94. In addition, feasibility studies are underway with RACE Projects CATALYST, EXPLOIT and BETEUS and with the Spanish Tele-education project ETSIT for interconnecting more sites in Switzerland, France, Germany and Spain. %{\bf The Summer School is organized by the RACE Project BRAIN} % {\bf Honoray Committee} % % \begin{quote} % To be decided, Telefonica, Spain \\ % Rector, University of Aveiro, Portugal \\ % Paolo Nordeste, CET, Portugal \\ % Rector, Technical University of Madrid, Spain \\ % Michel Roy, CEC, Brussels \\ % ..... % \end{quote} {\bf Organizing Committee} \begin{quote} Rui Aguiar, University of Aveiro, Portugal \\ Jerome Camus, Institut Theseus, France \\ Pedro Chas, Telefonica, Spain \\ Pierre Courtois, AIB, Belgium \\ John Dobson, University of Newcastle, UK \\ Jose Domingues, CET, Portugal (BRAIN Project Manager) \\ Manuel Duarte, University of Aveiro, Portugal (Aveiro Site SS'94 Manager) \\ Klaus Franke, Technical University of Chemnitz, Germany \\ Jeff Gould, Data Strategies, France \\ Vasco Lagarto, CET, Portugal \\ Pierre Lagasse, University of Gent, Belgium \\ Hans Melchior, Swiss Federal Institut of Technology, Switzerland \\ Tomas de Miguel, Technical University of Madrid, Spain \\ John O'Reilly, University College North Wales, UK \\ Steven Plagemann, SHP Systems Services, Ireland (BRAIN Technical Manager) \\ Juan Quemada, Technical University of Madrid, Spain (SS'94 Manager) \\ Silvia Ruiz, Technical University of Catalunya, Spain \\ Eric Scharf, Queen Mary Westfield College, UK \\ Reg Teesdale, SESTEL, France \\ I Venieris, National Technical University of Athens, Greece \\ Robert Vinckier, SHP Systems Services, Belgium \\ George Williamson, British Telecom, UK \end{quote} \rule{17cm}{.5mm} If you are interested in receiving direct information about SS'94 please send the following questionnaire by mail, fax or e-mail to: Dept Ing. Telematica (SS'94) \\ ETSI Telecomunicacion \\ E-28040 Madrid, Spain \\ tf: +34 1 3367332, fax: +34 1 3367333, email: SS94@dit.upm.es \rule{17cm}{.5mm} Name: \hrulefill Company: \hrulefill\\ Address: \hrulefill\\ (cont.): \hrulefill\\ Telephone: \hrulefill Fax: \hrulefill Email: \hrulefill \end{document} %%% overflow headers %%% To: Pere Brunet , aedima@fme.upc.es, bierduempel@gmd.de, ercim-execom@inria.fr, dt@castle.gmd.de, josef.schaefer@gmd.de, iinfd@ccuab1.uab.es, brunet@lsi.upc.es, defrutos@dia.ucm.es, bermudez@aimat.cesga.es, santiago@etsii.unizar.es, mantaras@ceab.es, laita@fi.upm.es, rovayo@esi.us.es, mdelgado@ugr.es, a_valle@ccuma.uma.es, revilla@cpd.uva.es, pla@cerber.ub.es, Serge FDIDA , abensour@ralvm29.vnet.ibm.com, aa@ICSI.Berkeley.EDU, bill@cs.concordia.ca, pfb@hplb.hpl.hp.com, erbi@eurocom.cica.fr, binder@cnri.reston.va.us, bisdik@watson.ibm.com, chrisb@cs.kun.nl, boyer@lannion.cnet.fr, tmpo@intranet.gr, stan@int-evry.fr, ajc@inesc.pt, olga@ac.upc.es, chen@res.enst.fr, greg@xtp.wpd.sgi.com, jean-pierre.claude@prism.uvsq.fr, colemen@nutmeg.ntu.edu.au, courtiat@laas.fr, walid.dabbous@sophia.inria.fr, danthine@vm1.ulg.ac.be, bsd@bellcore.com, diaz@laas.fr, christophe.diot@sophia.inria.fr, duchien@cnam.cnam.fr, jescobar@bbn.com, gagnaire@res.enst.fr, galand@vnet.ibm.com, andreas.grebe@fernuni-hagen.de, guerin@watson.ibm.com, guillemi@lannion.cnet.fr, gun@vnet.ibm.com, haas@boole.att.com, hariri@cat.syr.edu, horlait@masi.ibp.fr, dh@comp.lancs.ac.uk, ishibasi@nap.elcom.nitech.ac.jp, jezequel@irisa.fr, mjj@riacs.edu, kamal@eng.kuniv.edu.kw, ulfk@tts.lu.se, kuendig@tik.ethz.ch, fuyung@ralvm29.vnet.ibm.com, leduc@montefiore.ulg.ac.be, luigi@csi.uottawa.ca, jwmark@ccng.waterloo.edu, mas, martini@uni-paderborn.de, meleis@rdgeng.enet.dec.com, guven@atri.curtin.edu.au, isatom@informatik.rwth-aachen.de, michel@imag.fr, onvural@vnet.ibm.com, craig@aland.bbn.com, hp@cscn.ncsu.edu, steve@sics.se, zeletin@fokus.berlin.gmd.dbp.de, pujolle@masi.ibp.fr, svr@iitm.ernet.in, james.roberts@issy.cnet.fr, rolin@rennes.enst-bretagne.fr, cath@comm.polymtl.ca, SCHOTT@DHDIBM1.BITNET, ahmed@res.enst.fr, seret@res.enst.fr, spaniol@rwthinf.ibp.fr, yutaka@kuamp.kyoto-u.ac.jp, thai@masi.ibp.fr, thomesse@loria.fr, tohme@res.enst.fr, vas@zurich.ibm.com, ventre@cps.na.cnr.it, vissers@cs.utwente.nl, carey@cs.usask.ca, wolisz@ftsu00.ee.TU-Berlin.de, zit@t500m0.telematik.informatik.uni-karlsruhe.de, labetoul@eurecom.fr, dit, claude.petitpierre@lti.di.epfl.ch, ifip-6-1@labs-n.bbn.com, Harry Rudin , cabernet-announce@ncl.ac.uk, cabernet-events@ncl.ac.uk, drury@fore.com, eedjak@chapelle.ericcson.se, Kerstin@emp-d.uucp, erbi@eurecom.fr, dubois@eurecom.fr, delaye@eurecom.fr, gueguen@eurecom.fr, Toni Willi , Michel Roy , ietf-request@IETF.CNRI.Reston.VA.US, Zubin Dittia , end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, icad-request@santafe.edu, icad@santafe.edu, ietf@isi.edu, ir-l@uccvma.bitnet, rem-conf-request@es.net, rem-conf@es.net, sigmedia@bellcore.com, sound@acm.org, @ntasun.ntt.jp:tccc@cs.umass.edu simon, ibrahim@ece.upm.my, awu@dg13.cec.be, ripe-list@ripe.net, zein@enst-tlse.fr, Bruno.Traverson@der.edf.fr, Jacques Saint-Blancat , Josie Scarr , Dr. Fiona Williams , Michael Rupprecht , Kai Jakobs , Klaus Lenssen , Wilko Reinhardt , Prof. Dr. Shindler , Dr. Bauerfeld , Nelly Kerforn , Karl Jeacle , Niall Fallon , Joao Mota , Jorge Caetano , Theodoros Bozios tmpo@intranet %%% end overflow headers %%% From rem-conf-request@es.net Thu Feb 24 17:16:30 1994 Received: from KARIBA.BBN.COM by osi-west.es.net via ESnet SMTP service id <01476-0@osi-west.es.net>; Thu, 24 Feb 1994 07:20:02 +0000 Date: Thu, 24 Feb 94 10:19:34 EST From: Chip Elliott To: rem-conf@es.net Subject: Hopping Okay, I will sit down and behave! :-) --Chip From rem-conf-request@es.net Thu Feb 24 17:24:04 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <28167-0@osi-west.es.net>; Thu, 24 Feb 1994 00:57:31 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Thu, 24 Feb 1994 00:57:28 -0800 Posted-Date: Thu 24 Feb 94 00:56:30 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 24 Feb 94 00:56:31 PST Date: Thu 24 Feb 94 00:56:30 PST From: Stephen Casner Subject: Re: privacy and multicast To: moongw@helios.ece.arizona.edu, simon@internode.com.au Cc: rem-conf@es.net Message-Id: <762080190.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9402222358.AA24774@helios.ece.arizona.edu> Mail-System-Version: [I've returned this thread to rem-conf, since Moon,Gwi pointed out that's where it started, and I think most of the mbone participants are also there. I agree that it's bad to include both lists.] A private set of multicast nodes and tunnels will work fine, and assuming that it is set up with a reasonable topology, will provide the most efficient carriage of the private data. However, I want to point out some cautions on this approach: 1. It is important to avoid having multiple tunnels carrying the same traffic and crossing the same physical link if the link speed is T1 or lower. Therefore, if the private tunnels go over physical paths that also carry tunnels of the "public" MBONE, you must keep the private net separate from the MBONE. That means you can't have any Ethernet that connects to both, or the two mrouters will exchange routes with each other and the private net will become part of the MBONE. More to the point, this means that you can't have some workstations on the Ethernet participating in MBONE sessions while others are participating in sessions on the private net. Those on the private net have to remain isolated from the MBONE. I, for one, don't think that is desirable. On the other hand, if the private multicast net is all within some physical network boundary (one company's private network system, say) that doesn't carry MBONE tunnels, then it is fine to hook that private net to the MBONE at one or more points, making it part of the MBONE. You can use mrouted TTL thresholds to keep "private" (or more accurately, "local") traffic within this subsection of the MBONE. That's what we do in DARTnet, with thresholds of 64 to the rest of the MBONE. 2. Related to the above concerns, it is reasonable for network managers to restrict the use of private tunnels within their networks because management of multicast traffic is in a primitive state at this point. By insisting that all multicast traffic flow over tunnels that they maintain, network managers can monitor the traffic and exercise at least a little bit of control. -- Steve ------- From rem-conf-request@es.net Thu Feb 24 17:38:44 1994 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <04261-0@osi-west.es.net>; Thu, 24 Feb 1994 09:58:05 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA11103; Thu, 24 Feb 94 09:58:49 -0800 Message-Id: <9402241758.AA11103@rx7.ee.lbl.gov> To: rem-conf@es.net Subject: vat problem with "idvi" Date: Thu, 24 Feb 94 09:58:48 PST From: Van Jacobson Due to an unfortunate misunderstanding, vat 3.2 exits if told to use the audio format "idvi" (it expects the name "dvi" instead and the backwards compatability code for the old name got left out of the release). This will be fixed in the next release of vat (which is imminent). In the interim, you can add the following workaround to the start_audio proc in your .sd.tcl (add this line immediately before the "set confaddr ..." line): if {$audiofmt=="idvi"} { set audiofmt dvi } We apologize for this screw-up and will try not to let it happen again. - Van & Steve From rem-conf-request@es.net Thu Feb 24 19:43:15 1994 Received: from jon.bellcore.com by osi-west.es.net via ESnet SMTP service id <13560-0@osi-west.es.net>; Thu, 24 Feb 1994 16:35:06 +0000 Received: from localhost (zia@localhost) by jon.bellcore.com (8.6.4/8.6.4) id TAA10947 for rem-conf@es.net; Thu, 24 Feb 1994 19:35:01 -0500 Date: Thu, 24 Feb 1994 19:35:01 -0500 From: zia@jon.bellcore.com (Ashar Zia) Message-Id: <199402250035.TAA10947@jon.bellcore.com> To: rem-conf@es.net Subject: Re: vat on Sparc10 problems >We have experienced episodic problems with vat on our Sparc10. IP >multicasting is properly installed and vat runs fine at times. At >other times, both input and output meters show a high level of >activity although neither is being provided. Any audio that can be >generated by or received on that Sparc10 is unintelligible. > >Has anyone experienced similar problems? We have had Sun field >engineers out to check the hardware and they claim there are no >problems. One theory we have is that vat performs internal >calibration to pick a silence level and that the problem can be >attributed to the difference in the audio chip in the Sparc10. > >Any input on solving or working around this problem would be >appreciated. > >Thanks, > >Ruth Lang >rlang@nisc.sri.com I have had a very similar problem with vat on Sparcstation10 and Sparcstation2. Although IP multicasting is properly installed, sometimes input meters show a high level of activity even though the mic is turned off. The resulting speech is unintelligible. Can someone please shed some light on possible solutions? Thanks. -zia From rem-conf-request@es.net Thu Feb 24 19:49:31 1994 Received: from jon.bellcore.com by osi-west.es.net via ESnet SMTP service id <13752-0@osi-west.es.net>; Thu, 24 Feb 1994 16:45:39 +0000 Received: from localhost (zia@localhost) by jon.bellcore.com (8.6.4/8.6.4) id TAA10955 for rem-conf@es.net; Thu, 24 Feb 1994 19:45:32 -0500 Date: Thu, 24 Feb 1994 19:45:32 -0500 From: zia@jon.bellcore.com (Ashar Zia) Message-Id: <199402250045.TAA10955@jon.bellcore.com> To: rem-conf@es.net Subject: Re: vat on Sparc10, correction Regarding my recent posting about vat on Sparcstation10... I said that I have experienced problems on Sparcstation10 and Sparcstation2. I would like to correct myself. I have only experienced it on Sparcstation10. Sorry for the confusion. Thanks. -zia From rem-conf-request@es.net Thu Feb 24 23:17:31 1994 Received: from brolga.cc.uq.oz.au by osi-west.es.net via ESnet SMTP service id <16204-0@osi-west.es.net>; Thu, 24 Feb 1994 20:16:21 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Fri, 25 Feb 1994 14:15:27 +1000 To: Scott W Brim cc: rem-conf@osi-west.es.net, cu-seeme-l@cornell.edu Subject: Re: CU-SeeMe0.60b1 In-reply-to: Your message of "Thu, 03 Feb 1994 22:35:57 EST." <199402040336.AA15421@postoffice3.mail.cornell.edu> X-Mailer: exmh version 1.3alpha 1/28/94 Date: Fri, 25 Feb 1994 14:15:22 +1000 Message-ID: <16921.762149722@brolga.cc.uq.oz.au> From: George Michaelson From rem-conf-request@es.net Thu Feb 24 23:23:37 1994 Received: from brolga.cc.uq.oz.au by osi-west.es.net via ESnet SMTP service id <16393-0@osi-west.es.net>; Thu, 24 Feb 1994 20:23:11 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Fri, 25 Feb 1994 14:22:23 +1000 To: Scott W Brim cc: rem-conf@osi-west.es.net, cu-seeme-l@cornell.edu Subject: Re: CU-SeeMe0.60b1 In-reply-to: Your message of "Thu, 03 Feb 1994 22:35:57 EST." <199402040336.AA15421@postoffice3.mail.cornell.edu> X-Mailer: exmh version 1.3alpha 1/28/94 Date: Fri, 25 Feb 1994 14:22:16 +1000 Message-ID: <17221.762150136@brolga.cc.uq.oz.au> From: George Michaelson (sorry about that.. pressed the wrong button) Thanks for a thoughtful response Scott. I think I'm happy. I was concerned that CuSeeMe was being 'deployed' in ways which would mean Mac users remained isolated from the rest of us and vice-versa. I can now rest happy since interop of some kind is forseeable. As ever, if you let your code escape outside the research pool (and I'm only marginally at the D end of R&D these days) it very quickly becomes relied on and not simply played with. As Mike Lesk used to say about mailsystems, its easier to fill a vacuum than to move a released product aside in favour of better solutions. Some of this multicast stuff is oozing out of the playground and into the classroom... -George From rem-conf-request@es.net Fri Feb 25 09:07:53 1994 Received: from ibminet.awdpa.ibm.com by osi-west.es.net via ESnet SMTP service id <20594-0@osi-west.es.net>; Fri, 25 Feb 1994 06:07:20 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA24074; Fri, 25 Feb 94 06:11:29 -0800 Received: from [9.228.10.10] by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA12733; Fri, 25 Feb 94 04:17:34 -0800 Received: by beo.heidelbg.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA42889; Fri, 25 Feb 1994 13:09:33 +0100 From: ibmpa!beo.heidelbg.ibm.com!goebel@ibminet.awdpa.ibm.com (Thomas Goebel) Message-Id: <9402251209.AA42889@beo.heidelbg.ibm.com> Subject: 2nd cfp: IWACA To: PP-Warning: Parse error in original version of preceding line Original-To: distribution.@beo.heidelbg.ibm.com@ibmpa.awdpa.ibm.com; (see end of body) Date: Fri, 25 Feb 1994 13:09:33 +0100 (MEZ) Content-Length: 5855 ----------------------------------------------------------------------------- | | | 2nd call for paper 2nd call for paper 2nd call for paper | | | | | | If you have already noticed the cfp for this year's IWACA and returned | | the form below simply ignore this mail. | | | | | | | | 2nd call for paper 2nd call for paper 2nd call for paper | | | ----------------------------------------------------------------------------- 2nd IWACA 2nd International Workshop on Advanced Teleservices and High-Speed Communication Architectures 26.-28. September 1994 Heidelberg, Germany This workshop will focus on `teleservices' as a central topic for high-speed communication networks. Advances in multimedia technology, high-speed systems and networks make distributed multimedia applications a reality today. Networks in the future will p ovide end-user applications with advanced services like multimedia mail, video-conferencing, joint-viewing, access to multimedia databases, etc. At the first IWACA in Munich, Germany, March 1992, it became obvious that the scope of future telecommunicatio services will range from simple bearer services to sophisticated multimedia services. This will give rise to enormous business opportunities. Therefore this workshop focuses on teleservices and the appropriate high-speed communication facilities together with the respective standards. Original contributions discussing the following topics are solicited: - distributed multimedia applications - multimedia teleservices - real-time multimedia traffic analysis - resource management - multimedia communication subsystems - high-speed network design for multimedia applications - mobile communications for teleservices - multimedia protocols - intelligent network services The workshop will present three tutorials, one on distributed multimedia systems, one on multimedia protocols and one on ATM. Multimedia demonstration are planned. Important dates: Return form below: immediately Submit 2000-word summary: March 31, 1994 Acceptance decision: May 31, 1994 Final papers due: July 31, 1994 (length of appr. 10 pages) Tutorials: September 26, 1994 Workshop: September 27-28, 1994 ------------------------------------------------------------------------ Chair: ----- Ralf Steinmetz, IBM-ENC, Heidelberg, Germany Co-Chair: -------- Bob Ip, Siemens, Munchen, Germany Alfred Weaver, University of Virginia, VA, USA Technical Program Committee: ---------------------------- Derek McAuley, University of Cambridge, UK Ernst Biersack, Eurecom, Sophia-Antipolis, France Simon Bernstein, Virginia, Sprint, USA Guillermo Cisneros, GTI, Univ.Politecnica Madrid, Spain Andre Danthine, University of Liege, Belgium Joerg Eberspaecher, Technical Univ. Muenchen, Germany Wolfgang Effelsberg, Univ. of Mannheim, Germany Jose Encarnacao, T.H. Darmstadt, Germany Edward A. Fox, Virginia Tech, VA, USA Charles N. Judice, Bell Atlantic, USA Juergen Kanzow, DeTeBerkom, DBP Telekom, Berlin, Germany Paul J. Kuehn, University of Stuttgart, Germany Joerg Liebeherr, University of Virginia, VA, USA Philippe Loiret, France Telecom, France Takeshi Nishida, NEC, Japan Stephen Pink, SICS, Stockholm, Sweden Venkat Rangan, UCSD, San Diego, CA, USA Russell Sasnett, GTE, Waltham, MA, USA Otto Spaniol, RWTH Aachen, Germany David Sutherland, British Telecom, UK Radu Popescu-Zeletin, GMD Fokus, Berlin, Germany ------------------------------------------------------------------------ To register your intent to submit a paper and/or attend, please fill out the form below and return it immediately. In order to keep the flavor of a "workshop" participation will be restricted to 100 participants. It is intended to publish the proceedings n time for distribution at the workshop with Springer in the `Lecture Notes in Computer Science' series. To submit a paper, prepare five copies of a 2000-word summary, in English, and submit it by March 31, 1994, to: Dr. Ralf Steinmetz IBM Deutschland Informationssysteme GmbH, European Networking Center Vangerowstrae 18 Telephone: +49-6221-59 4280 69115 Heidelberg FAX: +49-6221-59 3400 Germany E-mail: STEINMET@DHDIBMIP.BITNET ------------------------------------------------------------------------ Return this form to: Dr. Ralf Steinmetz, IBM ENC, Vangerowstr. 18 69115 Heidelberg, Germany, STEINMET@DHDIBM1.BITNET I intend to: - attend the workshop - attend a tutorial - submit a paper Name: ____________________________ Organization: ____________________________ Address: ____________________________ ____________________________ ____________________________ Telephone: ____________________ FAX: ____________________ E-mail: ____________________ ------------------------------------------------------------------------ in cooperation with: IEEE Industrial Electronics IEEE Computer Sciety, Taskforce on Multimedia Computing ACM (final approval pending) GI %%% overflow headers %%% To: rajiv%ms.uky.edu@ibmpa.awdpa.ibm.com, rakow%darmstadt.gmd.de@ibmpa.awdpa.ibm.com, rama%gti.ssr.upm.es@ibmpa.awdpa.ibm.com, rao%tech.ascom.ch@ibmpa.awdpa.ibm.com, raynetintl%connectinc.com@ibmpa.awdpa.ibm.com, rba%bellcore.com@ibmpa.awdpa.ibm.com, rcbox%roke.co.uk@ibmpa.awdpa.ibm.com, rdi%ler.thomson.fr@ibmpa.awdpa.ibm.com, rebensburg%prz.tu-berlin.d400.de@ibmpa.awdpa.ibm.com, redell%src.dec.com@ibmpa.awdpa.ibm.com, reible%deteberkom.detecon.d400.de@ibmpa.awdpa.ibm.com, reibman%research.att.com@ibmpa.awdpa.ibm.com, reichel%freia.inf.tu-dresden.de@ibmpa.awdpa.ibm.com, reijo.juvonen%research.nokia.fi@ibmpa.awdpa.ibm.com, reimer%swssai.uu.ch@ibmpa.awdpa.ibm.com, rem-conf%es.net@ibmpa.awdpa.ibm.com, reuter%informatik.uni-stuttgart.de@ibmpa.awdpa.ibm.com, rgleaton@vnet.ibm.com, rhodgson%cix.compulink.co.uk@ibmpa.awdpa.ibm.com, rhp%ipsys.co.uk@ibmpa.awdpa.ibm.com, rich%cc.gatech.edu@ibmpa.awdpa.ibm.com, richard.marsden%rd.eng.bbc.co.uk@ibmpa.awdpa.ibm.com, rick%cs.arizona.edu@ibmpa.awdpa.ibm.com, riedl%hannibal.cs.umn.edu@ibmpa.awdpa.ibm.com, riglet%lep.lep-philips.fr@ibmpa.awdpa.ibm.com, rl%case.co.uk@ibmpa.awdpa.ibm.com, rmarcus%atc.boeing.com@ibmpa.awdpa.ibm.com, rmc%gandalf.inesc.pt@ibmpa.awdpa.ibm.com, rmerino%cc.unizar.es@ibmpa.awdpa.ibm.com, rmr%inesc.pt@ibmpa.awdpa.ibm.com, rnk%sei.cmu.edu@ibmpa.awdpa.ibm.com, robert.primrose%mari.co.uk@ibmpa.awdpa.ibm.com, roberto.minerva%cselt.stet.it@ibmpa.awdpa.ibm.com, roki%dfv.rwth-aachen.de@ibmpa.awdpa.ibm.com, roko%ensae.ericsson.se@ibmpa.awdpa.ibm.com, rolf_schuetze%m2tek.fido.de@ibmpa.awdpa.ibm.com, rolin%rennes.enst-bretagne.fr@ibmpa.awdpa.ibm.com, roman%cs.wustl.edu@ibmpa.awdpa.ibm.com, ronchett%phoenix.fatme.it@ibmpa.awdpa.ibm.com, ronr%dgp.utoronto.ca@ibmpa.awdpa.ibm.com, rothermel%informatik.uni-stuttgart.de@ibmpa.awdpa.ibm.com, rrhein%rcs.sel.de@ibmpa.awdpa.ibm.com, rsd%soton.ac.uk@ibmpa.awdpa.ibm.com, rtsai%e0sun3.ccl.itri.org.tw@ibmpa.awdpa.ibm.com, rudinger%uni-bonn.de@ibmpa.awdpa.ibm.com, rudolf.kuechler%sp1.y-net.dbp.de@ibmpa.awdpa.ibm.com, rudolph%ztivax.zfe.siemens.de@ibmpa.awdpa.ibm.com, s.dustdar%lse.ac.uk@ibmpa.awdpa.ibm.com, s.j.bruyn%bnr.co.uk@ibmpa.awdpa.ibm.com %%% end overflow headers %%% From rem-conf-request@es.net Fri Feb 25 15:15:21 1994 Received: from paul.rutgers.edu by osi-west.es.net via ESnet SMTP service id <25997-0@osi-west.es.net>; Fri, 25 Feb 1994 12:14:57 +0000 Received: by paul.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27293; Fri, 25 Feb 94 15:14:53 EST Date: Fri, 25 Feb 94 15:14:53 EST From: klemets@paul.rutgers.edu (Anders Klemets) Message-Id: <9402252014.AA27293@paul.rutgers.edu> To: rem-conf@es.net Cc: CASNER@isi.edu In-Reply-To: Stephen Casner's message of Thu 24 Feb 94 00:56:30 PST <762080190.0.CASNER@XFR.ISI.EDU> Subject: Re: privacy and multicast > More to the point, this means that you can't > have some workstations on the Ethernet participating in MBONE > sessions while others are participating in sessions on the private > net. Those on the private net have to remain isolated from the > MBONE. I, for one, don't think that is desirable. It actually only requires some minor modifications to the current multicast code for Suns to allow multiple parallel MBONE's. Currently the multicast packets sent on Ethernet have the first three bytes of the ethernet header set to 01-00-5E. By setting these bytes (the 'vendor ID') to something different, one can have a different multicast network that can coexist with the current one on the same physical Ethernet. It is possible to have 2^23 such networks. To implement this, one must make sure that the Ethernet driver checks that any multicast packets that are received really were sent to a Ethernet destination address that the host is prepared to receive. I don't think this is currently done in most drivers since ignoring the check is an efficiency optimization. Also, multicast routers that put the Ethernet interface in 'ALLMULTI' mode should make sure that only multicast packets with the right 'vendor ID' are being received. Anders From rem-conf-request@es.net Fri Feb 25 16:11:23 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <26906-0@osi-west.es.net>; Fri, 25 Feb 1994 13:10:56 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Fri, 25 Feb 1994 13:10:50 -0800 Posted-Date: Fri 25 Feb 94 13:09:57 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 25 Feb 94 13:09:58 PST Date: Fri 25 Feb 94 13:09:57 PST From: Stephen Casner Subject: Re: privacy and multicast To: klemets@paul.rutgers.edu Cc: rem-conf@es.net Message-Id: <762210597.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9402252014.AA27293@paul.rutgers.edu> Mail-System-Version: > Currently the multicast packets sent on Ethernet have the first three > bytes of the ethernet header set to 01-00-5E. By setting these bytes > (the 'vendor ID') to something different, one can have a different > multicast network that can coexist with the current one on the same > physical Ethernet. You are supposed to buy those numbers. IANA bought only one for IP use. -- Steve ------- From rem-conf-request@es.net Sat Feb 26 09:58:15 1994 Received: from fenris.dhhalden.no by osi-west.es.net via ESnet SMTP service id <06625-0@osi-west.es.net>; Sat, 26 Feb 1994 06:57:49 +0000 Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) id <11124-0@fenris.dhhalden.no>; Sat, 26 Feb 1994 15:57:44 +0100 Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.11); Sat, 26 Feb 94 15:57:20 GMT+1 Received: from MERCURY by SOFUS (Mercury 1.11); Sat, 26 Feb 94 15:57:16 GMT+1 To: rem-conf@es.net From: Jardar Sunde Olsen Organization: Ostfold College Date: 26 Feb 1994 16:00:27 +0100 Subject: Reply-to: jardarso@dhhalden.no Priority: normal X-mailer: Pegasus Mail/Mac v2.02 Message-ID: <181C28652E4@sofus.dhhalden.no> subscribe rem-conf Jardar Olsen From rem-conf-request@es.net Sat Feb 26 10:05:38 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <06650-0@osi-west.es.net>; Sat, 26 Feb 1994 07:05:11 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 26 Feb 1994 15:04:38 +0000 To: klemets@paul.rutgers.edu (Anders Klemets) cc: rem-conf@es.net, CASNER@isi.edu Subject: Re: privacy and multicast In-reply-to: Your message of "Fri, 25 Feb 94 15:14:53 EST." <9402252014.AA27293@paul.rutgers.edu> Date: Sat, 26 Feb 94 15:04:34 +0000 From: Jon Crowcroft >It actually only requires some minor modifications to the current >multicast code for Suns to allow multiple parallel MBONE's. >Currently the multicast packets sent on Ethernet have the first three >bytes of the ethernet header set to 01-00-5E. you're o nan ethernet, and your talking about privacy? :-) >(the 'vendor ID') to something different, one can have a different >multicast network that can coexist with the current one on the same >physical Ethernet. >It is possible to have 2^23 such networks. and it'd work on any 802 LAN....actually, on a switched network it 'd be much easier...once you've worked out how to do IP multicast ojn a switched network:-) jon From rem-conf-request@es.net Sat Feb 26 10:09:20 1994 Received: from fenris.dhhalden.no by osi-west.es.net via ESnet SMTP service id <06677-0@osi-west.es.net>; Sat, 26 Feb 1994 07:08:53 +0000 Received: from sofus.dhhalden.no by fenris.dhhalden.no with SMTP (PP) id <11254-0@fenris.dhhalden.no>; Sat, 26 Feb 1994 16:08:48 +0100 Received: from SOFUS/MERCURY by sofus.dhhalden.no (Mercury 1.11); Sat, 26 Feb 94 16:08:24 GMT+1 Received: from MERCURY by SOFUS (Mercury 1.11); Sat, 26 Feb 94 16:08:19 GMT+1 From: B}rd Arve Evjen Organization: Ostfold College To: rem-conf@es.net Date: Sat, 26 Feb 1994 16:08:10 +0100 Subject: Reply-to: baarde@dhhalden.no Priority: normal X-mailer: PMail v3.0 (R1a) Message-ID: <181F1B041CB@sofus.dhhalden.no> SUBSCRIBE rem-conf Bard Arve Evjen =-=-=-=-----=-=-=-=-----=-=-=-=-----=-=-=-=-----=-=-=-= | Bard Arve Evjen Username: baarde@dhhalden.no, | " baardae@darkwing.dhhalden.no (HP)" | Servers : Fenris/Sofus/Gyda | " Ostfold Regional Department of Computer Science " | College Multimedia-student | " " | Features: | " - PC (Windows/Dos) programming " | - Macintosh (SuperCard/HyperCard) programming | " - IP Multicast (HP-UX) programming " =-=-=-=-----=-=-=-=-----=-=-=-=-----=-=-=-=-----=-=-=-= From rem-conf-request@es.net Sat Feb 26 13:40:43 1994 Received: from paul.rutgers.edu by osi-west.es.net via ESnet SMTP service id <07740-0@osi-west.es.net>; Sat, 26 Feb 1994 10:40:17 +0000 Received: by paul.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12517; Sat, 26 Feb 94 13:40:13 EST Date: Sat, 26 Feb 94 13:40:13 EST From: klemets@paul.rutgers.edu (Anders Klemets) Message-Id: <9402261840.AA12517@paul.rutgers.edu> To: rem-conf@es.net In-Reply-To: Stephen Casner's message of Fri 25 Feb 94 13:09:57 PST <762210597.0.CASNER@XFR.ISI.EDU> Subject: Re: privacy and multicast > You are supposed to buy those numbers. IANA bought only one for IP > use. What I am suggesting is to use the 'vendor ID' number to multiplex multiple IP address spaces onto the same physical Ethernet. (Whether it has any impact on the security of the traffic is immaterial to the discussion.) These vendor ID's can be assigned dynamically. The choice of vendor ID for parallel MBONE's need not be universal. Each participating LAN may use a different vendor ID for the parallel MBONE if necessary. So the assignement of these ID's is really at the discretion of the system administrator of each LAN. That anybody would claim the right and actually try to sell these numbers is downright silly. Just say No. What's next? Will somebody start selling other numbers that can be used to multiplex traffic between private parties, such as UDP port numbers? Anders From rem-conf-request@es.net Sat Feb 26 14:15:56 1994 Received: from ibminet.awdpa.ibm.com by osi-west.es.net via ESnet SMTP service id <07964-0@osi-west.es.net>; Sat, 26 Feb 1994 11:15:32 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA13620; Sat, 26 Feb 94 11:19:40 -0800 Received: by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA12844; Sat, 26 Feb 94 11:13:31 -0800 Received: from taurus.cs.nps.navy.mil by ibminet.awdpa.ibm.com (5.61/1.15) id AA13368; Sat, 26 Feb 94 11:10:27 -0800 Received: from trouble.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA02680; Sat, 26 Feb 94 11:07:31 PST Received: by trouble.cs.nps.navy.mil (920330.SGI/911001.SGI) for @taurus.cs.nps.navy.mil:rem-conf%es.net@ibmpa.awdpa.ibm.com id AA16506; Sat, 26 Feb 94 11:07:23 -0800 Date: Sat, 26 Feb 94 11:07:23 -0800 From: ibmpa!ibminet.awdpa.ibm.com!trouble.cs.nps.navy.mil!zyda@ibminet.awdpa.ibm.com (Professor Michael J. Zyda) Message-Id: <9402261907.AA16506@trouble.cs.nps.navy.mil> To: rem-conf%es.net@ibmpa.awdpa.ibm.com Subject: NPSNET-DI Presentation in Washington, DC on the 1st of March 94 NPSNET Presentation in DC on the 1st of March 1994 at 3:15pm - 4:00pm A number of people have asked me for additional information on our NPSNET-DI dismounted infantry demo of last week. Some people have asked for a videotape of that demo. To satisfy these requests, I have become a last minute speaker at the TMSA Synthetic Environments Conference being held in Washington, DC on the 28th of Feb and the 1st of March. My presentation is on the 1st of March at 3:15pm through 4:00pm. The official title of the talk is "Software for Large-Scale Virtual Environments". That talk includes a video demonstration of NPSNET-IV, NPSNET-DI and NPSNET-DI-WISE (dismounted infantry, walk in synthetic environment). The conference is being held at the Ritz-Carlton, Pentagon City. You can probably register on site. There is a phone number and fax number for registration but it is probably too late to use them (310-534-3922, 310-534-0743/fax). At a later date, I am planning on generating an SGI Moviemaker video clip for our Mosaic Home Page of the NPSNET-DI demo (assuming our anonymous ftp site has sufficient space). Michael Zyda, NPSNET Research Group The NPSNET Research Group is a reimbursable organization. For further information, contact Michael J. Zyda (zyda@cs.nps.navy.mil) or David R. Pratt (pratt@cs.nps.navy.mil). NPSNET Papers & Mosaic & Anonymous ftp The NPSNET Research Group has a Mosaic Home Page. We are placing all our NPSNET papers there in Postscript. See: file://taurus.cs.nps.navy.mil/pub/NPSNET_MOSAIC/npsnet_mosaic.html The most common Mosaic error/complaint I receive is that our machine is not accessible or that Mosaic has generated an error. ALL of these complaints so far have been people starting the above line with http: instead of file: as listed above. TYPE IT AS ABOVE. BETTER YET, COPY THE ABOVE LINE WITH YOUR MOUSE AND PASTE IT INTO THE OPEN URL DIALOGUE BOX. If you don't have Mosaic, get it. Its available via anonymous ftp from ftp.ncsa.uiuc.edu for most flavors of machine. Mosaic is THE interface to the InfoBahn. Don't be left homeless without it. If you still persist in not getting Mosaic, our papers are available via anonymous ftp. They are Postscript files on machine: taurus.cs.nps.navy.mil In directory: pub/NPSNET_MOSAIC Michael Zyda zyda@trouble.cs.nps.navy.mil From rem-conf-request@es.net Sat Feb 26 16:09:35 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <08501-0@osi-west.es.net>; Sat, 26 Feb 1994 13:09:12 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Sat, 26 Feb 1994 13:09:09 -0800 Posted-Date: Sat 26 Feb 94 13:08:16 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sat, 26 Feb 94 13:08:17 PST Date: Sat 26 Feb 94 13:08:16 PST From: Stephen Casner Subject: Re: privacy and multicast To: klemets@paul.rutgers.edu Cc: rem-conf@es.net Message-Id: <762296896.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9402261840.AA12517@paul.rutgers.edu> Mail-System-Version: Anders, > So the assignement of these ID's is really at the discretion of the > system administrator of each LAN. It does seem reasonable that at least part of that space could be set aside for local use at the discretion of the system administrator, but I don't know if that has been done. I assume the motivation of IEEE (or is that part still Xerox?) in charging for ID's is to insure that they not be wasted. > What's next? Will somebody start selling other numbers that can be > used to multiplex traffic between private parties, such as UDP port > numbers? Well, the idea of charging for IP addresses has been discussed. There are many issues involved that might make the idea impractical, but if the charge were per address allocated and not just those that were used, it's likely that quite a few under-utilized class A and B addresses would be turned in for a collection of addresses at the next class down (to be aggregated under CIDR). -- Steve ------- From rem-conf-request@es.net Sun Feb 27 18:54:34 1994 Received: from orion.arc.nasa.gov by osi-west.es.net via ESnet SMTP service id <15451-0@osi-west.es.net>; Sun, 27 Feb 1994 15:54:09 +0000 Original-Received: Sun, 27 Feb 94 15:52:13 PST by orion.arc.nasa.gov (4.1/1.2) PP-warning: Illegal Received field on preceding line From: Nora Lavelle Message-Id: <9402272352.AA27929@orion.arc.nasa.gov> Subject: NASA Shuttle Mission STS-62 To: rem-conf@es.net Date: Sun, 27 Feb 1994 15:52:12 -0800 (PST) Cc: anaops@atlas.arc.nasa.gov X-Mailer: ELM [version 2.4 PL3] Content-Type: text Content-Length: 834 I am planning to multicast the NASA Select coverage of STS-62 on a 24 hour basis starting on Mar 3,1994 and lasting until Mar 17, 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 Advance Network Applications Sterling Software NASA Ames Research Center nlavelle@orion.arc.nasa.gov -------------------------------------------------------------------------------- From rem-conf-request@es.net Mon Feb 28 18:53:01 1994 Received: from swifty.dap.CSIRO.AU by osi-west.es.net via ESnet SMTP service id <26835-0@osi-west.es.net>; Mon, 28 Feb 1994 15:52:34 +0000 Received: by swifty.dap.CSIRO.AU (920330.SGI/920502.SGI) for rem-conf@es.net id AA03896; Tue, 1 Mar 94 10:52:29 +1100 From: alan@swifty.dap.CSIRO.AU (Alan Hargreaves) Message-Id: <9402282352.AA03896@swifty.dap.CSIRO.AU> Subject: sts-62 To: rem-conf@es.net Date: Tue, 1 Mar 1994 10:52:28 +1100 (EDT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 600 Sorry to post this to the whole group, I have lost the name of the originator. Would you please consider using different multicast addresses for the video and audio. Some of us have comparatively slow links. If we only want to listen to the audio, we get the video running across the link as well (we are running pruning code). If they are run seperately, the pruning code will stop anything being transmitted that is not being watched/listened to. alan. -- Alan Hargreaves (VK2KVF) alan@dap.csiro.au, Ph: +61 2 413 7752 CSIRO Division of Applied Physics, PO Box 218 Lindfield 2070