From rem-conf-request@es.net Fri Oct 01 04:55:14 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <01536-0@osi-east.es.net>; Fri, 1 Oct 1993 01:46:00 +0000 Received: from benji.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 1 Oct 1993 09:45:53 +0100 To: rem-conf@es.net Subject: MICE seminars Date: Fri, 01 Oct 93 09:45:50 +0100 From: A.Sasse@cs.ucl.ac.uk The MICE (Multimedia Integrated Conferencing for Europe) project will attempt to hold a joint seminar series between Unviersity College London (UCL) and the Swedish Institute of Computer Science (SICS). Most seminars will take place on Monday afternoons, starting Oct 4 (the events of the first few weeks are given below. As this is currently all very experimental, we may not advertise the first couple of seminars in sd. Also initially we will attempt to keep the traffic within Europe if we can. People are welcome to listen in, and constructive feedback is welcome. Once we have found our feet, we'll advertise the seminars more widely and institute a mechanism for taking remote questions. The seminars will either be given from UCL (University College London), or SICS (Swedish Institute of Computer Science). We intend to send a constant 128k stream, from a hardware codec, currently it requires a Sparc 10 to decode this stream. Hopefully this data rate will not cause any problems. Angela Sasse --------------------------------------------------------------------- Forthcoming MICE Seminars Date Start Finsh Start Trans Speaker(s) (Organisation) (CET) (CET) (UK) site Oct 4 14.00 15.30 14.00 UCL Ian Wakeman & Jon Crowcroft (UCL) Congestion Control Schemes Principal Discussant: Eric Lin (SICS) Oct 11 15.00 16.30 15.00 UCL Graham Knight (UCL) Interworking with Narrow-band ISDN at UCL Principal Discussant (TBA) Oct 19 09.30 12.00 09.30 SICS Workshop with various speakers Mobile personal computing and communication Oct 19 13.00 16.00 13.00 SICS Steve Deering (Xerox PARC) Multicast: State of the Art and Research Issues ----------------------------------------------------------------- Angela Sasse The MICE project at UCL Dept. of Computer Science University College London tel. : +44-71-380 7212 Gower Street fax : +44-71-3871397 London WC1E 6BT email: a.sasse@uk.ac.ucl.cs From rem-conf-request@es.net Fri Oct 01 13:10:28 1993 Received: from relay1.pipex.net by osi-east.es.net via ESnet SMTP service id <04683-0@osi-east.es.net>; Fri, 1 Oct 1993 10:01:19 +0000 Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <05850-0@relay1.pipex.net>; Fri, 1 Oct 1993 17:55:41 +0100 Received: by widow.spider.co.uk; Fri, 1 Oct 93 18:02:18 +0100 From: Michael "S." "A." Robb Date: Fri, 1 Oct 93 17:51:13 +0100 Message-Id: <2121.9310011651@raft.spider.co.uk> Received: by raft.spider.co.uk; Fri, 1 Oct 93 17:51:13 +0100 To: GA-List-Request@aic.nrl.navy.mil, owner-mp-render@icase.edu, program-2600-list@raven.alaska.edu, rem-conf@es.net, wavelet@math.scarolina.edu Subject: unsubscribe unsubscribe michaelr@spider.co.uk From rem-conf-request@es.net Fri Oct 01 13:10:46 1993 Received: from relay1.pipex.net by osi-east.es.net via ESnet SMTP service id <04724-0@osi-east.es.net>; Fri, 1 Oct 1993 10:03:13 +0000 Received: from widow.spider.co.uk by relay1.pipex.net with SMTP (PP) id <05942-0@relay1.pipex.net>; Fri, 1 Oct 1993 18:03:06 +0100 Received: by widow.spider.co.uk; Fri, 1 Oct 93 18:09:43 +0100 Date: Fri, 1 Oct 93 17:58:37 +0100 Message-Id: <2190.9310011658@raft.spider.co.uk> Received: by raft.spider.co.uk; Fri, 1 Oct 93 17:58:37 +0100 Subject: Subscribe msar@dcs.ed.ac.uk From: msar <@spider.co.uk (Michael S. A. Robb): msar@dcs.ed.ac.uk> Apparently-To: michaelr Apparently-To: program-2600-list@raven.alaska.edu Apparently-To: wavelet@math.scarolina.edu Apparently-To: GA-List-Request@AIC.NRL.NAVY.MIL Apparently-To: owner-mp-render@icase.edu Apparently-To: rem-conf@es.net From rem-conf-request@es.net Mon Oct 04 07:57:31 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <20756-0@osi-east.es.net>; Mon, 4 Oct 1993 04:38:50 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 4 Oct 1993 12:37:44 +0100 To: mbone@isi.edu, rem-conf@es.net Subject: Mice Seminar #1, as Announced on sd Cc: mice@cs.ucl.ac.uk, mm-local@cs.ucl.ac.uk Date: Mon, 04 Oct 93 12:37:37 +0100 From: Atanu Ghosh Sorry, if some people receive this twice I have sent this mail both to the mbone@edu.isi and the rem-conf@net.es list. The video is now being announced in sd but it requires the following change to your .sd.tcl. ivs { global ivs exec $ivs -a -r -recvonly -T $sd_sess(ttl) \ $sd_sess(address)/$sd_video(port) & } Obviously you will need to restart sd. Please note that that you really will need a sparc 10 at least to perform the decode. If you do not have a copy of ivs 3.2 then it is currently available for anonymous ftp here at at UCL cs.ucl.ac.uk:mice/ivs/* If for some reason you do not want to use wb to see the slides, then the slides are also available from cs.ucl.ac.uk:car/mice-1-jon.shar.Z Atanu. From rem-conf-request@es.net Mon Oct 04 09:10:34 1993 Received: from hardees.rutgers.edu by osi-east.es.net via ESnet SMTP service id <21142-0@osi-east.es.net>; Mon, 4 Oct 1993 06:09:57 +0000 Received: from grimaldi.rutgers.edu by hardees.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04297; Mon, 4 Oct 93 09:09:55 EDT Date: Mon, 4 Oct 93 09:09:55 EDT From: jim@hardees.rutgers.edu (Jim Martin) Message-Id: <9310041309.AA04297@hardees.rutgers.edu> To: rem-conf@es.net Subject: Flexicam? Content-Length: 400 A few months back, someone posted an article about a Flexicam (?). It's a camera and mic mounted on a flexible stalk, designed specifically for videoconferencing via computer. Unfortunately, I managed to loose my reference, and now desperately need it for a proposal. If anyone has that pointer, or perhaps even experience with this product, I'd greatly appreciate a word or two. Thanks! Jim From rem-conf-request@es.net Mon Oct 04 11:56:07 1993 Received: from inet-gw-2.pa.dec.com by osi-east.es.net via ESnet SMTP service id <22651-0@osi-east.es.net>; Mon, 4 Oct 1993 08:55:33 +0000 Received: by inet-gw-2.pa.dec.com; id AA03951; Mon, 4 Oct 93 08:55:29 -0700 Received: by oreo.pa.dec.com; id AA05390; Mon, 4 Oct 93 08:55:29 -0700 Message-Id: <9310041555.AA05390@oreo.pa.dec.com> To: jim@hardees.rutgers.edu (Jim Martin) Cc: rem-conf@es.net Subject: Re: Flexicam? In-Reply-To: Message of Mon, 4 Oct 93 09:09:55 EDT from jim@hardees.rutgers.edu (Jim Martin) <9310041309.AA04297@hardees.rutgers.edu> Date: Mon, 04 Oct 93 08:55:28 -0700 From: berc@src.dec.com X-Mts: smtp We've been using FlexCams for several months, and now reccomend them as the camera of choice for desktop video (to those who ask us). Give up on the audio, though. We're considering having recieving dyke off the mic RCAs to remove their temptation. lance From rem-conf-request@es.net Mon Oct 04 16:21:16 1993 Received: from Sun.COM by osi-east.es.net via ESnet SMTP service id <26985-0@osi-east.es.net>; Mon, 4 Oct 1993 13:10:06 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA29984; Mon, 4 Oct 93 13:10:04 PDT Received: from auckland.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA01235; Mon, 4 Oct 93 13:10:07 PDT Received: by auckland.Eng.Sun.COM (5.0/SMI-SVR4) id AA00522; Mon, 4 Oct 93 13:08:55 PDT Date: Mon, 4 Oct 93 13:08:55 PDT From: Ross.Finlayson@Eng.Sun.COM (Ross Finlayson) Message-Id: <9310042008.AA00522@auckland.Eng.Sun.COM> To: rem-conf@es.net Subject: MTV on the net (in case you hadn't noticed...) Reply-To: finlayson@Eng.Sun.COM X-Sun-Charset: US-ASCII Content-Length: 1191 I'm not totally sure that this isn't a joke, but yes, there really is a site "mtv.com", and yes, this README file is there (the only file present, as far as I could tell). Could someone open a window - I feel faint... Ross. ----- Begin Included Message ----- >From @Xenon.Stanford.EDU,@Sunburn.Stanford.EDU:com-priv20-forw@lists.psi.com Mon Oct 4 13:01 PDT 1993 From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian) Subject: MTV on the net (in case you hadn't noticed...) To: com-priv@psi.com Date: Mon, 4 Oct 1993 11:42:28 -0700 (PDT) Content-Transfer-Encoding: 7bit Regarding MTV: They are now an official Internet site: mtv.com. Here is the README obtained via anonymous ftp from mtv.com:/pub >Welcome to mtv.com! > >As you can tell, the site hasn't been configured completely yet, but look >for lots of stuff to be happening here in the next couple of weeks. > >Anonymous ftp will get you digital audio, video, you name it. The gopher >server will be up soon to, as will several mailing lists. > >In the meantime, all comments and suggestions should be sent to me at >adam@mtv.com > >Enjoy for now.... > >Adam Curry Watch out MBone! mb ----- End Included Message ----- From rem-conf-request@es.net Mon Oct 04 17:10:24 1993 Received: from norman.nwnet.net by osi-east.es.net via ESnet SMTP service id <28074-0@osi-east.es.net>; Mon, 4 Oct 1993 13:59:35 +0000 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA11385; Mon, 4 Oct 93 13:59:32 -0700 Date: Mon, 4 Oct 1993 13:57:19 -0700 (PDT) From: Allen Robel Subject: Re: MTV on the net (in case you hadn't noticed...) To: finlayson@Eng.Sun.COM Cc: rem-conf@es.net In-Reply-To: <9310042008.AA00522@auckland.Eng.Sun.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 4 Oct 1993, Ross Finlayson wrote: > I'm not totally sure that this isn't a joke, but yes, there really is a site > "mtv.com", and yes, this README file is there (the only file present, > as far as I could tell). > > Could someone open a window - I feel faint... whois for mtv.com is included below. I'm not sure if CurryCo has anything to do with the MTV we all know and hate... -allen CurryCo, Ltd. (MTV-DOM) 30 Glen Rd. Montclair, NJ 07044 Domain Name: MTV.COM Administrative Contact: Humphrey, Douglas E. (DEH18) doug@DIGEX.COM (301) 220-2020 Technical Contact, Zone Contact: Kern, Edward (EK6) ejk@DIGEX.NET 301-220-2020 Record last updated on 17-Aug-93. Domain servers in listed order: NS.DIGEX.NET 164.109.1.3 NS2.DIGEX.NET 164.109.10.23 The InterNIC Registration Services Host ONLY contains Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. From rem-conf-request@es.net Mon Oct 04 23:46:52 1993 Received: from optics.wc.novell.com by osi-east.es.net via ESnet SMTP service id <01866-0@osi-east.es.net>; Mon, 4 Oct 1993 20:34:39 +0000 Received: from by wc.novell.com (4.1/smi4.1.1.v91190) id AF14800; Mon, 4 Oct 93 20:33:54 PDT Date: Mon, 4 Oct 93 20:33:54 PDT Message-Id: <9310050333.AF14800@wc.novell.com> To: hgs@research.att.com (Henning G. Schulzrinne) From: minshall@wc.novell.com X-Sender: minshall@optics.wc.novell.com (Unverified) Subject: Re: RTP, conferences, ports and flow-ID Cc: rem-conf@es.net Henning, >> This >> is, IMHO, silly. Most of our implementations are based on UDP sockets, which >> demux based on port numer. Using same port for audio and video obliges the >> audio driver to also process the video packets.. > >That's only true if you cannot bind to a multicast address. (SunOS and >Irix kernels equipped with the current version of multicast have >handled multicast group binding for quite a while). It's a tradeoff: a >common port has advantages (accounting/traffic statistics, less >likelihood that the port on a given system will already have been taken >by some other application when I want to join a conference, fire walls, >...); it does require the per-multicast-group binding. In my opinion, >that should actually be part of host requirements, as it simplifies a >whole range of issues, in particular once we send different quality >video streams to different multicast groups to allow receivers to pick >the most appropriate one. Actually, isn't this last point (using m'cast addresses to decide which quality to receive) orthogonol from the issue of allowing a given (m'cast addr, UDP port) to be bound to a given application? If i want low quality video, i will use (eventually) IGMP to join *only* the low quality video m'cast group for a given conference. Greg Minshall From rem-conf-request@es.net Tue Oct 05 05:38:29 1993 Received: from survis.surfnet.nl by osi-east.es.net via ESnet SMTP service id <03078-0@osi-east.es.net>; Tue, 5 Oct 1993 02:26:34 +0000 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <03703-0@survis.surfnet.nl>; Tue, 5 Oct 1993 10:26:24 +0100 Received: from localhost.surfnet.nl by surgeon.surfnet.nl (4.1/SMI-4.1(EJB01)) id AA24249; Tue, 5 Oct 93 10:26:22 +0100 Message-Id: <9310050926.AA24249@surgeon.surfnet.nl> To: Allen Robel Cc: finlayson@eng.sun.com, rem-conf@es.net Subject: Re: MTV on the net (in case you hadn't noticed...) In-Reply-To: Your message of Mon, 04 Oct 93 13:57:19 -0700. From: Erik-Jan.Bos@SURFnet.nl X-Mailer: MH X-Organization: SURFnet bv, Utrecht, The Netherlands X-Phone-Number: +31 30 310290 X-Fax-Number: +31 30 340903 Date: Tue, 05 Oct 93 10:26:19 +0100 Sender: Erik-Jan.Bos@SURFnet.nl Allen, > > I'm not totally sure that this isn't a joke, but yes, there really is a site > > "mtv.com", and yes, this README file is there (the only file present, > > as far as I could tell). > > > > Could someone open a window - I feel faint... > > whois for mtv.com is included below. I'm not sure if CurryCo has anything > to do with the MTV we all know and hate... -allen > > CurryCo, Ltd. (MTV-DOM) > 30 Glen Rd. > Montclair, NJ 07044 > > Domain Name: MTV.COM CurryCo sounds like "Adam Curry Company". Adam Curry is one of the DJs of MTV, formerly working at Veronica (one of the TV stations in The Netherlands). During his work in The Netherlands he also was active on The Net. __ Erik-Jan. From rem-conf-request@es.net Tue Oct 05 14:28:59 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <07223-0@osi-east.es.net>; Tue, 5 Oct 1993 11:19:16 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11712>; Tue, 5 Oct 1993 11:18:00 PDT Received: by ecco.parc.xerox.com id <16181>; Tue, 5 Oct 1993 11:17:56 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Tue, 5 Oct 1993 11:17:50 -0700 (PDT) Message-ID: Date: Tue, 5 Oct 1993 11:17:50 PDT Sender: Ron Frederick From: Ron Frederick To: minshall@wc.novell.com Subject: Re: RTP, conferences, ports and flow-ID CC: rem-conf@es.net In-Reply-To: <9310050333.AF14800@wc.novell.com> References: <9310050333.AF14800@wc.novell.com> >> [argument about binding to multicast address deleted] > > Actually, isn't this last point (using m'cast addresses to decide which > quality to receive) orthogonol from the issue of allowing a given (m'cast > addr, UDP port) to be bound to a given application? If i want low > quality video, i will use (eventually) IGMP to join *only* the low > quality video m'cast group for a given conference. Actually, we have to be careful in this case. If we want to support the notion of multiple qualities of encoding on different multicast addresses, and we expect these encoding to be hierarchical such that you need to listen to more than one to receive high quality video, we can't use the "bind to multicast address" trick. Either that, or we can only use it by actually opening up _multiple_ sockets and binding each to one address. In general, I'm nervous about the notion of using one port for all audio and video applications. I think it's important to use _well known_ ports, so that you have some reasonable guarantee that all the machines that wish to participate will have that port available. However, I don't see a problem with having multiple well-known ports. In particular, two applications that don't ever have any intention of interoperating might decide to be on different ports. With that in mind, choosing one port for audio and a different port for video doesn't seem awful to me. I realize that there may be applications which want to do both, and that they might even want to go as far as putting both audio and video data into a single packet. Doing that would require bundling multiple RTP PDUs into one packet, though, and that would mean a separate profile. For the combined audio/video application that didn't bundle data into one packet, it could easily continue to use two different port numbers for the two streams by using two sockets. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Tue Oct 05 14:50:01 1993 Received: from vlsi.cs.caltech.edu by osi-east.es.net via ESnet SMTP service id <07256-0@osi-east.es.net>; Tue, 5 Oct 1993 11:21:19 +0000 Received: from vlsi (troop.cs.caltech.edu) by vlsi.cs.caltech.edu (4.1/1.34.1) id AA18782; Tue, 5 Oct 93 11:21:28 PDT Message-Id: <9310051821.AA18782@vlsi.cs.caltech.edu> To: rem-conf@es.net Subject: Re: MTV on the net (in case you hadn't noticed...) Date: Tue, 05 Oct 1993 11:19:33 -0700 From: John Garnett ------- Forwarded Message From: James Waldrop To: John Garnett Subject: Re: MTV on the Internet In-Reply-To: Your message of Mon, 04 Oct 1993 14:27:54 -0700 Message-Id: ]On Mon, 4 Oct 1993, Ross Finlayson wrote: ] ]> I'm not totally sure that this isn't a joke, but yes, there really is a site ]> "mtv.com", and yes, this README file is there (the only file present, ]> as far as I could tell). ]> ]> Could someone open a window - I feel faint... ] ]whois for mtv.com is included below. I'm not sure if CurryCo has anything ]to do with the MTV we all know and hate... -allen ] ]CurryCo, Ltd. (MTV-DOM) ] 30 Glen Rd. ] Montclair, NJ 07044 MTV.com is a sortof joke by Adam Curry. Adam (I think that's his first name) was/is a user on Panix in NYC (panix.com) who tried to start a 'Zine published through his .plan (you fingered him to see the latest issue). Alex Rosen, the guy who runs Panix, got wind of this and told him he couldn't do it, cause it would tie up the net connection, etc. Mr Curry quickly got together his own domain and is running it off his PC in New Jersey. Regarding the *real* MTV on the net, I know some people working with them trying to get them on the net, sort of in the same fashion Turner wants on, and AOL is already on, i.e. a commercial service of some sort. I'm not sure if Adam Curry has anything to do with that, but he's a fairly well-known name in certain NYC net-related circles. You can forward this to that list, I've forgotten the address. James ------- End of Forwarded Message From rem-conf-request@es.net Wed Oct 06 04:59:48 1993 Received: from jerry.inria.fr by osi-east.es.net via ESnet SMTP service id <14875-0@osi-east.es.net>; Wed, 6 Oct 1993 01:44:24 +0000 Received: by jerry.inria.fr (5.65c8/IDA-1.2.8) id AA21885; Wed, 6 Oct 1993 09:46:15 +0100 Message-Id: <199310060846.AA21885@jerry.inria.fr> To: Ron Frederick Cc: rem-conf@es.net Subject: Re: RTP, conferences, ports and flow-ID In-Reply-To: Your message of Tue, 05 Oct 93 11:17:50 -0700. Reply-To: Thierry.Turletti@sophia.inria.fr Date: Wed, 06 Oct 93 09:46:14 +0100 From: Thierry TURLETTI > In particular, two applications that don't ever have any intention of > interoperating might decide to be on different ports. With that in mind, > choosing one port for audio and a different port for video doesn't seem > awful to me. I realize that there may be applications which want to do > both, and that they might even want to go as far as putting both audio > and video data into a single packet. Doing that would require bundling > multiple RTP PDUs into one packet, though, and that would mean a > separate profile. For the combined audio/video application that didn't > bundle data into one packet, it could easily continue to use two different > port numbers for the two streams by using two sockets. > -- > Ron Frederick > frederick@parc.xerox.com I completely agree with you. The point is that the new RTP draft does not include such option ... Thierry From rem-conf-request@es.net Wed Oct 06 06:28:21 1993 Received: from mitsou.inria.fr by osi-east.es.net via ESnet SMTP service id <15171-0@osi-east.es.net>; Wed, 6 Oct 1993 03:15:35 +0000 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA23298; Wed, 6 Oct 1993 11:17:37 +0100 Message-Id: <199310061017.AA23298@mitsou.inria.fr> To: Ron Frederick Cc: minshall@wc.novell.com, rem-conf@es.net Subject: Re: RTP, conferences, ports and flow-ID In-Reply-To: Your message of "Tue, 05 Oct 93 11:17:50 PDT." Date: Wed, 06 Oct 93 11:17:35 +0100 From: Christian Huitema I would make one further comment. While the focus of RTP is audio and video over mcast, applications like vat, nv or ivs are also capable of point ot point operation. And I certainly don't want to use different headers for syncing point to point and point to multipoint transmission. The "multiple mcast groups" argument have some value for mcast groups. None for point to point. I think that Ron's view is the correct one -- muxing audio and video on same port requires a specific media type. For all the trouble they give and the exactly zero amount of usage I perceive, I would like to just remove any notion of flow-id from RTP. Well, maybe we could just use the VAT header if Van would document it :-) Christian Huitema From rem-conf-request@es.net Thu Oct 07 04:31:24 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <27848-0@osi-east.es.net>; Thu, 7 Oct 1993 01:03:43 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Thu, 7 Oct 1993 01:03:38 -0700 Posted-Date: Thu 7 Oct 93 01:02:54 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 7 Oct 93 01:02:56 PDT Date: Thu 7 Oct 93 01:02:54 PDT From: Stephen Casner Subject: RTP port numbers To: rem-conf@es.net Message-Id: <749980974.0.CASNER@XFR.ISI.EDU> Mail-System-Version: There are some difficult tradeoffs in choosing a strategy for port number use in RTP, both for multicast and unicast use. I thought we had reached a concensus, but apparently not. In August, Ron Frederick summarized some of the discussion as follows: Ron> The point I was really making was that the notion of choosing a Ron> _well known_ port number in the >1024 space, as long as we pick Ron> something in the >5000 space, is not all that difficult. We can Ron> get other applications in the world to pretty much stay out of Ron> our way, as X has with port 6000. This is _very_ different than Ron> saying that we can get away with sd picking a random port number Ron> for every new session and expecting at that moment in time all Ron> the hosts in the world which might want to join the session will Ron> have that port free... There are good motivations for sd's current strategy of sharing the multicast address for all media in a session, and using dynamically allocated port numbers to differentiate the media (there are probably more that I haven't listed): - Conserving multicast addresses, since they have a cost in routing. - On systems that do not allow (the equivalent of) binding to a multicast address, applications can only bind to the port number, so the port numbers must be different not only for each application but also for the same application in different sessions. Hence, only dynamically allocated port numbers are practical, and for a distributed mechanism, random allocation is the best choice. An extra 16 bits of randomly allocated conference-id is provided to allow applications to discard packets that aren't for them in the event of a collision of port numbers. I think the situation has changed somewhat, so the strategy may also need to change: - In order to take advantage of multicast tree pruning, we need separate addresses to allow end sites to receive only some of the media. At current levels of utilization, we don't yet have a problem of running out of addresses or exceeding the routing capacity. We have to assume that the recent efforts to make multicast routing efficient for sparse trees will be successful, and that the multicast address space will be expanded along with the rest of the IP address space in IPng. - Patches to allow binding to mulicast addresses have been distributed with the multicast software release, and it appears that this change is being adopted in those systems that support IP multicast. This enables the use of a well-known port number rather than randomly allocated ones, which is desired for the reasons Ron stated. Now, to address the comments in recent messages. How many well-known port numbers should we use? Ron> In particular, two applications that don't ever have any intention of Ron> interoperating might decide to be on different ports. With that in mind, Ron> choosing one port for audio and a different port for video doesn't seem Ron> awful to me. It doesn't seem awful to me, either. But what's unclear to me is how many kinds of traffic we would need to differentiate, and what that differentiation is intended to achieve. I think that is the key point. Should there be different ports for nv and ivs since you might want to run a stream of each during a session to carry two different kinds of video? Probably not, since we expect the two programs may interoperate in the future, but what about when someone comes up with a new video application for a purpose different enough from nv and ivs that it doesn't make sense to interoperate with them? Should that program define a new port number? Since allocating separate port numbers for audio and video is not going to eliminate the requirement to bind to a multicast address among multiple video programs or copies of one program, what are the separate port numbers intended to indicate? In the current profile, one port number is established as the default to indicate operation under that profile (Andrew Cherenson pointed out that the phrase "for this profile" is missing from the text). Other reasons Henning listed in the earlier discussion: - a single port number makes it easier to detect if a host is the unwitting receiver of unsolicited multicast traffic (with the same multicast group, but different port number) - a fixed port number eases the keeping of service statistics by Merit and gateways; right now, IP-over-IP serves as a rough indicator for multicast traffic, but this ceases to work as native multicast becomes popular and/or IP-over-IP is used for other purposes (e.g., tunneling IPng) - a fixed port numbers may simplify carrying RTP through firewalls In addition, Bob Braden explained to me that he was trying to monitor audio and video traffic on DARTnet and asked me how he could distinguish vat and RTP traffic from other traffic. I explained that since both run over UDP (so the protocol number gives no clue) and the port numbers are currently random, it is rather difficult. He wondered how the traffic classification schemes that have proposed using port numbers will work. For example, the priority mechanism in the new 3.1beta multicast code faces this problem. So, I don't think having separate port numbers for audio and video will make any difference to the application programs themselves, but it may be useful for monitoring and classification purposes to have more than one port number. Then is two the right number? How do we characterize how many port numbers will be needed in the long term for all the profiles we expect to be generated? IANA is concerned about this number; order 10 is OK but order 100 may not be. I believe the identification of the profile by the port number is useful. Should we have separate profiles for audio and video, though perhaps still combined in one document? Ron> I realize that there may be applications which want to do both, Ron> and that they might even want to go as far as putting both audio Ron> and video data into a single packet. Doing that would require Ron> bundling multiple RTP PDUs into one packet, though, and that Ron> would mean a separate profile. For the combined audio/video Ron> application that didn't bundle data into one packet, it could Ron> easily continue to use two different port numbers for the two Ron> streams by using two sockets. Thierry> I completely agree with [Ron]. The point is that the new RTP Thierry> draft does not include such option ... Thierry, I am not sure whether which of Ron's points (choosing two ports for audio and video, or those in the paragraph above) you felt the RTP draft precluded, but in any case I don't think that's true. The main RTP spec itself does not establish any restrictions on port numbers; that is left to profiles. The profile draft establishes a *default* port number for that profile, but does not require that port number to be used. In particular, for unicast traffic it says "Unicast connections may use the this or a set of mutually agreed-upon port numbers." If you were talking about bundling audio and video in a single packet, the RTP spec says a profile may allow for that, and we just need to write that profile. Christian> I would make one further comment. While the focus of RTP is Christian> audio and video over mcast, applications like vat, nv or Christian> ivs are also capable of point ot point operation. And I Christian> certainly don't want to use different headers for syncing Christian> point to point and point to multipoint transmission. I agree that unicast traffic is also very important. I'm not sure what you mean by "different headers". I don't think anyone has suggested that. The two might use different port number conventions. Christian> The "multiple mcast groups" argument [binding] have some Christian> value for mcast groups. None for point to point. There may be a similar argument for point-to-point. For those applications that use separate sockets for sending and receiving (nv does, I believe), could multiple copies of the program bind to the fixed port (with SO_REUSEADDR) for receiving and then restrict the packets received by connecting to the dynamically allocated send port of the other party? I haven't tested this, nor do I know if it would complicate the implementation too much. If this is not practical, then yes, unicast applications will have to use different port numbers. But the dynamic allocation problem is much simpler in the unicast case. Christian> I think that Ron's view is the correct one -- muxing audio Christian> and video on same port requires a specific media type. I don't think Ron said this, although it is another possibility for tightly integrated audio and video encodings to be multiplexed within the data portion of one RTP packet. Ron was talking about a new profile that would allow multiple RTP packets to be framed into one UDP packet, in which case the the RTP packets would be distinguished by differenct channel IDs. Christian> For all the trouble they give and the exactly zero amount Christian> of usage I perceive, I would like to just remove any notion Christian> of flow-id from RTP. The term "flow ID" has been changed to "channel ID", except that this was missed in a few spots in the profile draft. In any case, I disagree. The ID causes no trouble if you don't want to use it. We did have a long discussion about conflicting interpretations of it a couple of months ago, but that was all resolved. And while the ID may not be used yet (except nv uses 32 for backward version matching), I believe it will be, as stated in the previous paragraph and when RTP is used directly over IP (as some folks are already doing). Christian> Well, maybe we could just use the VAT header if Van would Christian> document it :-) In which ways would you prefer to use the vat header? Note that the vat header allocates 16 bits to the conference ID function which is somewhat similar to the 6 bits allocated in RTP for the channel ID (that is, you have to check to make sure it matches in received packets, and either could be used for intentionally multiplexing within one destination address/port if desired). -- Steve ------- From rem-conf-request@es.net Thu Oct 07 08:33:07 1993 Received: from itd.nrl.navy.mil by osi-east.es.net via ESnet SMTP service id <28718-0@osi-east.es.net>; Thu, 7 Oct 1993 05:08:50 +0000 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03781; Thu, 7 Oct 93 08:08:46 EDT Date: Thu, 7 Oct 93 08:08:46 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9310071208.AA03781@itd.nrl.navy.mil> To: rem-conf@es.net Subject: RTP port numbers I would be MUCH more comfortable with fixed port numbers for RTP. The need to firewall is real and will be for the foreseeable future and floating port numbers conflict with most kinds of extant firewalls (e.g. Cisco routers with their port blocking capability). It seems to me that we have 4 kinds of real-time traffic in use just now: audio, video, session directory, whiteboard. I can't think of a lot more possible applications, so the order(10) estimate for port numbers seems reasonable. Ran atkinson@itd.nrl.navy.mil From rem-conf-request@es.net Thu Oct 07 09:21:52 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <28983-0@osi-east.es.net>; Thu, 7 Oct 1993 06:01:31 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 7 Oct 1993 14:01:08 +0100 To: atkinson@itd.nrl.navy.mil (Ran Atkinson) cc: rem-conf@es.net Subject: Re: RTP port numbers In-reply-to: Your message of "Thu, 07 Oct 93 08:08:46 EDT." <9310071208.AA03781@itd.nrl.navy.mil> Date: Thu, 07 Oct 93 14:01:07 +0100 From: Jon Crowcroft > It seems to me that we have 4 kinds of real-time traffic in use just >now: audio, video, session directory, whiteboard. I can't think of a >lot more possible applications, so the order(10) estimate for port >numbers seems reasonable. Ran in 10 years, TCP had telnet/ftp/smtp and a couple of others. however, in about 1 year, RTP has vat/nevot nv/ivs sd wb metoesatm spealing clock and we have a couple of other dubious local uses i'd say order 1/10 the number of bits you need for an IPng destination address:-) jon From rem-conf-request@es.net Thu Oct 07 09:50:01 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <29040-0@osi-east.es.net>; Thu, 7 Oct 1993 06:19:53 +0000 Received: from kant.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 7 Oct 1993 14:19:40 +0100 To: rem-conf@es.net Subject: Re: RTP port numbers In-reply-to: Your message of "Thu, 07 Oct 93 08:08:46 EDT." <9310071208.AA03781@itd.nrl.navy.mil> Date: Thu, 07 Oct 93 14:19:38 +0100 From: I.Wakeman@cs.ucl.ac.uk Since we will be living with rtp over udp for some time to come, I would prefer a fixed port number so that rtp packets can be recognised by j. random packet filter. We're going to field van's class based link sharing stuff on the fat pipe rsn, and it makes life a lot easier if we can actually recognise a packet. There's b*gg*r all chance otherwise. This is, of course, expediency, as is carrying the rtp over udp anyway. cheers ian From rem-conf-request@es.net Thu Oct 07 10:25:56 1993 Received: from sun2.nsfnet-relay.ac.uk by osi-east.es.net via ESnet SMTP service id <29438-0@osi-east.es.net>; Thu, 7 Oct 1993 07:25:04 +0000 Via: uk.ac.edinburgh.castle; Thu, 7 Oct 1993 15:23:42 +0100 Received: from scorpio.castle.ed.ac.uk by castle.ed.ac.uk id aa23124; 7 Oct 93 15:23 BST Date: Thu, 7 Oct 93 15:23:34 BST Message-Id: <8557.9310071423@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: [Graeme Wood: Re: RTP port numbers] To: rem-conf@es.net 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 Sender: jaw <@uk.ac.ed.castle.scorpio:jaw@castle.edinburgh.ac.uk> > in 10 years, TCP had telnet/ftp/smtp and a couple of others. > > however, in about 1 year, RTP has > vat/nevot nv/ivs sd wb metoesatm spealing clock and we have a couple > of other dubious local uses > > i'd say order 1/10 the number of bits you need for an IPng destination > address:-) > > jon A spealing clock? What a lovely idea. Would this be something like "Listening with Mother", every hour we would get a pleasant story to help us through our stress-filled days. Sorry about this I couldn't resist it but I agree with Jon. You cannot foretell the future. Who knows what applications are just waiting around the corner? Graeme From rem-conf-request@es.net Thu Oct 07 10:38:18 1993 Received: from mitsou.inria.fr by osi-east.es.net via ESnet SMTP service id <29367-0@osi-east.es.net>; Thu, 7 Oct 1993 07:16:48 +0000 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA26459; Thu, 7 Oct 1993 15:18:44 +0100 Message-Id: <199310071418.AA26459@mitsou.inria.fr> To: I.Wakeman@cs.ucl.ac.uk Cc: rem-conf@es.net Subject: Re: RTP port numbers In-Reply-To: Your message of "Thu, 07 Oct 93 14:19:38 +0100." <199310071400.AA11994@sophia.inria.fr> Date: Thu, 07 Oct 93 15:18:39 +0100 From: Christian Huitema => Since we will be living with rtp over udp for some time to come, I => would prefer a fixed port number so that rtp packets can be recognised => by j. random packet filter. We're going to field van's class based => link sharing stuff on the fat pipe rsn, and it makes life a lot easier => if we can actually recognise a packet. There's b*gg*r all chance => otherwise. => => This is, of course, expediency, as is carrying the rtp over udp => anyway. => => cheers => ian => This is also what you get for using an end to end information inside gateways. There MUST be a better way. At the very least, if you do that, you don't want "an RTP" port, but rather separate ports for voice, video and "other data". All the MICE results show that you need voice priority > video; white board can probably do with services equivalent to those of TCP. Christian Huitema From rem-conf-request@es.net Thu Oct 07 11:19:12 1993 Received: from zephyr.isi.edu by osi-east.es.net via ESnet SMTP service id <29762-0@osi-east.es.net>; Thu, 7 Oct 1993 08:04:08 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Thu, 7 Oct 1993 08:04:06 -0700 Date: Thu, 7 Oct 1993 08:04:06 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199310071504.AA25112@zephyr.isi.edu> To: rem-conf@es.net, I.Wakeman@cs.ucl.ac.uk Subject: Re: RTP port numbers *> From rem-conf-request@es.net Thu Oct 7 07:13:17 1993 *> To: rem-conf@es.net *> Subject: Re: RTP port numbers *> In-Reply-To: Your message of "Thu, 07 Oct 93 08:08:46 EDT." <9310071208.AA03781@itd.nrl.navy.mil> *> Date: Thu, 07 Oct 93 14:19:38 +0100 *> From: I.Wakeman@cs.ucl.ac.uk *> Content-Length: 444 *> X-Lines: 13 *> *> Since we will be living with rtp over udp for some time to come, I *> would prefer a fixed port number so that rtp packets can be recognised *> by j. random packet filter. We're going to field van's class based *> link sharing stuff on the fat pipe rsn, and it makes life a lot easier *> if we can actually recognise a packet. There's b*gg*r all chance *> otherwise. *> *> This is, of course, expediency, as is carrying the rtp over udp *> anyway. *> *> cheers *> ian *> *> I would like to emphatically agree with Ian. Barring the introduction of a new user class identifier (with all its requirements for security) at the IP layer, classification of packets for the purposes of link-sharing and monitoring will be very difficult without a small set of recognizable port numbers for realtime traffic streams. The wonderful Patricia, Celelia, etc algorithms have a time O(n); has anyone thought about how large n can grow? Bob Braden From rem-conf-request@es.net Thu Oct 07 14:58:50 1993 Received: from norman.nwnet.net by osi-east.es.net via ESnet SMTP service id <03913-0@osi-east.es.net>; Thu, 7 Oct 1993 11:57:52 +0000 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA22460; Thu, 7 Oct 93 11:57:48 -0700 Date: Thu, 7 Oct 1993 11:47:41 -0700 (PDT) From: Allen Robel Subject: Re: RTP port numbers To: Ran Atkinson Cc: rem-conf@es.net In-Reply-To: <9310071208.AA03781@itd.nrl.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 7 Oct 1993, Ran Atkinson wrote: > > I would be MUCH more comfortable with fixed port numbers for RTP. > The need to firewall is real and will be for the foreseeable future > and floating port numbers conflict with most kinds of extant firewalls > (e.g. Cisco routers with their port blocking capability). Cisco routers *can* filter by a range of port numbers (e.g. exclude tcp/udp ports greater then 1024 but less than 2048). So could you use a predefined range of port numbers for RTP (assuming other vendors also implement what Cisco calls "extended access lists")? And if you got smart about allocating those ranges, admins could be given more flexibility as to what type of traffic could be filtered. I don't hold a position pro or con wrt fixed ports (I don't know enough about the issues) but I just wanted to let the list know that this particular filtering option is available in at least one vendor's implementation... Allen Robel Internet: allen@nwnet.net Network Engineer voice: (206)562-3000 NorthWestNet FAX: (206)562-4822 From rem-conf-request@es.net Thu Oct 07 15:09:38 1993 Received: from itd.nrl.navy.mil by osi-east.es.net via ESnet SMTP service id <04018-0@osi-east.es.net>; Thu, 7 Oct 1993 12:02:38 +0000 Received: from ascent.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20331; Thu, 7 Oct 93 15:02:34 EDT Date: Thu, 7 Oct 93 15:02:34 EDT From: atkinson@itd.nrl.navy.mil (Randall Atkinson) Message-Id: <9310071902.AA20331@itd.nrl.navy.mil> To: allen@nwnet.net Subject: Re: RTP port numbers Cc: rem-conf@es.net Allen, Filtering on a range is not very secure, particularly when you have to filter on a fairly good sized range as appears to be the case for the proposal of dynamic port assignment for RTP. Range filtering is much less secure than just allowing the exact ports that one wants to permit through. So I don't think range filtering ameliorates my (and other folks') concerns. Regards, Ran atkinson@itd.nrl.navy.mil From rem-conf-request@es.net Thu Oct 07 17:18:49 1993 Received: from ninet.research.att.com by osi-east.es.net via ESnet SMTP service id <06017-0@osi-east.es.net>; Thu, 7 Oct 1993 14:18:15 +0000 Received: by research.att.com; Thu Oct 7 17:18 EDT 1993 Date: Thu, 7 Oct 93 17:17:21 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: rem-conf@es.net Subject: Re: port numbers Cc: casner@isi.edu Given the arguments back and forth, it appears that we might be able to reach agreement on setting aside a very small number of ports for AUDIO and VIDEO MULTICAST (audio and video is all the profile deals with, after all). Maybe we need some stronger language dealing with the unicast case. Regarding Ron's argument: The hierarchical coding case is not clear cut. There are at least two approaches for sending the high-quality video: - send two independent streams, one low and one high since true hierarchical coding doesn't seem to work very well (hierarchical coding has higher bandwidth for the same quality as non-hierarchical) and the saving of bandwidth to the high quality stream isn't that high. If I understand things correctly, MPEG-2 takes this approach. - do what Ron surmised (you need both streams to reconstruct the high- quality image) Having two sockets for two quality grades doesn't seem that big a deal, even if the second case is true. Now, having an audio and video port may have some advantages: My gateway administrator may well decide that the internal network isn't ready for video and thus allow only audio or he may decide that audio should be carried by AT&T (don't worry, I'm making the last one up...) That way, he doesn't have to rely on people not subscribing to multicast video addresses. Now, we can probably all agree on assigning audio and video two port numbers. It may even be nice to know the relative statistics of the two traffic classes separately. Separate ports also have the advantage that crippled workstations (those without multicast address binding) can work as long as they only need to receive one audio and one video stream concurrently. Note also that we don't have to worry RIGHT NOW about IMM, active badges, etc., even if they would use RTP, since they fall outside the scope of the profile (it says 'audio and video'). Thus, my modified proposal: audio: 5005 video: 5006 As other applications emerge, we can then decide whether to lump them into 5005/5006 or grant them a different port. Other applications are the subject of a separate profile (they have to be since encodings haven't been specified for them, for example). Are there real, major problems with this compromise? Henning From rem-conf-request@es.net Thu Oct 07 20:59:59 1993 Received: from nps.navy.mil by osi-east.es.net via ESnet SMTP service id <10173-0@osi-east.es.net>; Thu, 7 Oct 1993 17:59:24 +0000 Received: from alioth.cc.nps.navy.mil by nps.navy.mil (4.1/SMI-4.1) id AA19849; Thu, 7 Oct 93 17:54:21 PDT Received: by alioth.cc.nps.navy.mil (920330.SGI/911001.SGI) for @nps.navy.mil:mbone@isi.edu id AA06212; Thu, 7 Oct 93 17:56:28 -0700 Date: Thu, 7 Oct 93 17:56:28 -0700 From: mccann@alioth.cc.nps.navy.mil (Mike McCann) Message-Id: <9310080056.AA06212@alioth.cc.nps.navy.mil> To: rem-conf@es.net, mbone@isi.edu Subject: Discovery Day on Saturday Cc: mbmg@nps.navy.mil, ccstaff@nps.navy.mil Hello, people on the MBONE- This Saturday is the day we open up our campus to school kids, parents, and teachers from around our area. Some groups are coming from as far away as the San Francisco bay area (a 2 hour drive). The theme of this open house is "Discover what the world has to offer". In support of this theme our Lab is hosting several mbone stations; one of them will be sending video at a default rate of 128 kbs. The time of demonstration will be 0930-1500 PDT (1630-2200 UT) Saturday, 9 Oct 93. If you have a video (or even just audio) capable machine and can operate it at this time we would love to have you join in. I'm sure that it will mean a lot to our visitors. The session is now advertised in sd with the name "Discovery Day", it invokes vat, nv, and wb. I have seen no other conference announcements at this time, but if our traffic is a problem for anyone (the scope is set to 'world') please let me know. Looking forward to 'seeing' you this Saturday! -Mike P.S. Apologies if you get this twice, or more. Mike McCann Naval Postgraduate School (mccann@nps.navy.mil) Vis Lab, Code 51 (In-102a) Monterey, CA 93943 (408) 656-2752 From rem-conf-request@es.net Fri Oct 08 03:53:29 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <12547-0@osi-east.es.net>; Fri, 8 Oct 1993 00:52:52 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Fri, 8 Oct 1993 00:52:49 -0700 Posted-Date: Fri 8 Oct 93 00:52:07 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 8 Oct 93 00:52:08 PDT Date: Fri 8 Oct 93 00:52:07 PDT From: Stephen Casner Subject: Re: port numbers To: hgs@research.att.com Cc: rem-conf@es.net Message-Id: <750066727.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199310072118.AA02736@venera.isi.edu> Mail-System-Version: Henning, I have no objection to the two-port proposal: > audio: 5005 > video: 5006 > > As other applications emerge, we can then decide whether to lump them > into 5005/5006 or grant them a different port. > > Other applications are the subject of a separate profile (they have to > be since encodings haven't been specified for them, for example). -- Steve ------- From rem-conf-request@es.net Fri Oct 08 11:16:12 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <15256-0@osi-east.es.net>; Fri, 8 Oct 1993 08:02:51 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Oct 1993 16:02:01 +0100 To: rem-conf@es.net Subject: Mice Seminar #2 Cc: mice@cs.ucl.ac.uk Date: Fri, 08 Oct 93 16:01:57 +0100 From: Atanu Ghosh The second mice seminar will be held on Monday October 11th 14:00 GMT. The seminar is announced in sd. Speaker: Graham Knight, UCL Title: Interworking with Narrowband ISDN at UCL Abstract: For the past couple of years UCL has been experimenting with the use of narrowband ISDN for video and data applications. So far, the principle focus of the work has been a "gateway" which acts as an IP router between Ethernet and Primary Rate ISDN. At present this router is being used mainly to support a "homeworking" experiment in which several staff members have Basic Rate ISDN workstations/PCs in their homes. In this seminar I will discuss the design, capabilities and performance of the equipment installed so far. I will also introduce some of our planned activities which include the introduction of non-data applications to the gateway (voice and video) and the use of versions of the Primary Rate hardware to interface video CODECs to computers. Atanu. From rem-conf-request@es.net Sun Oct 10 11:16:33 1993 Received: from ninet.research.att.com by osi-east.es.net via ESnet SMTP service id <29680-0@osi-east.es.net>; Sun, 10 Oct 1993 08:15:57 +0000 Received: by research.att.com; Sun Oct 10 11:16 EDT 1993 Date: Sun, 10 Oct 93 11:15:40 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: rem-conf@es.net Subject: Merging encoding and profile documents Since there is a fair amount of cross referencing between the profile and encoding documents (for implementations, you will always need both) and both cover the same terrain (audio and video), I am tempted to merge the two documents. The combined length would only be about 10 pages. Note that for some of the more complicated encodings with format-specific options, for example H.261, the combined document would still refer to a separate document. The other anticipated use of the encoding format names (PCMU, G722, etc.) might be in the yet-to-be-written conference control protocol. However, I would anticipate that it would reference the list maintained by IANA, which would look something like: \begin{quote} Format Numbers In the RTP [998] there is a field called "name of format" to identify the format carried in RTP packets. This is a four-character ASCII field. ASCII meaning references 'PCMU' Pulse code modulation, mu-law [999] 'NEWE' some new encoding [1000] \end{quote} where [999] is the profile/encoding RFC. Please let me know ASAP if you believe this document merger should NOT take place. Henning From rem-conf-request@es.net Mon Oct 11 06:10:21 1993 Received: from rx7.ee.lbl.gov by osi-east.es.net via ESnet SMTP service id <04830-0@osi-east.es.net>; Mon, 11 Oct 1993 02:47:52 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA15222; Mon, 11 Oct 93 02:48:32 -0700 Message-Id: <9310110948.AA15222@rx7.ee.lbl.gov> To: rem-conf@es.net Cc: mice@cs.ucl.ac.uk Subject: new version of wb (v1.54) available for anonymous ftp Date: Mon, 11 Oct 93 02:48:31 PDT From: Van Jacobson A new version of the LBL whiteboard is available for anonymous ftp from ftp.ee.lbl.gov:wb/{sun,dec}-wb.tar.Z. Several major bugs that were observed during last week's MICE seminar have been fixed (I hope). In particular, postscript problems that would almost always cause the previous wb to `hang' and stop rendering all postscript should not cause any problems with this version of wb. Note that there are new Sun & DEC distributions but no SGI distribution: Like a fool I installed the new video board and system distribution that SGI sent us. The release notes failed to mention that the new system would not allow the machine to boot unless the libraries, compilers & NFS were deleted (rather than booting it prints a message telling you to remove the files). They also failed to note that the previous version of the system would not boot with the new board installed. So our SGI development machine has been converted into an attractive, expensive, boat anchor. Our SGI salesman is "out of the office" whenever we call so I have no idea when or if we will once again be able to produce SGI binaries. My apologies for getting this out so late -- after Jon & Ian identified all the bugs :(, I'd hoped to have a fix out by the middle of last week but I didn't count on wasting 48 hours futzing with our Indigo. Appended is a list of the changes from the previous version. If you are using wb to distribute postscript slides for a seminar, note particularly the MaxPostScriptSize change and the -P flag. Wb will now refuse to export postscript pages that are 'too big'. You should check ahead of time that your slides are small enough and perhaps look into lzps & distill if there are not. As always, let us know (via mail to wb@ee.lbl.gov) if there are questions, problems or suggestions for improvement. Thanks. - Van ------------------------------ v1.54, Mon Oct 11 00:13:46 PDT 1993 - Added -S (suppress/mute new sites) flag and checkbox control on bottom of sitebox. If this flag is on, new sites will come up muted (e.g., their scribbling won't show up on your display). For example, if you are watching a lecture you might want to start wb with the -S flag then unmute the lecturer's site. This will save your view of the lecture from being interrupted by random scribbling or page changes. - Finished implementing 'point to type' mode and added checkbox control to turn it on. (In point to type mode the text you type is placed at the current cursor position. You don't have to click before typing.) (change requested by Deborah Estrin). - Fixed several problems with gs locking up when importing badly formed postscript files (files missing a showpage, files containing infinite loops, non-conforming files containing multiple pages, etc.). Pretty much re-wrote the way wb talks to gs so data to be imaged is written to a temp file & gs is fed something that looks a lot like a ps printer's server loop so we can detect `stopped' programs, eof, etc. (Bugs reported by Jon Crowcroft et. al. of the MICE project.) - Made default page 'name' use IP address rather than hostname. The hostname lookup on SunOS/Solaris is so pathetic that huge delays were being introduced from wb doing a 'gethostbyaddr' to construct the page name. (Problem reported by Mark Handley at UCL.) - Added a MaxPostScriptSize X resource and "-P size_in_bytes" command line flag. People have been importing multi-megabyte screendumps into wb which take forever to send and do horrible things to the network. Wb now refuses to send a PS page that's bigger than MaxPostScriptSize. MaxPostScriptSize defaults to 32KB but can be changed (up to a max of 1MB) be setting the X resource or supplying -P on the command line. NOTE: If you get the error: -wb: can't send PS pages larger than NNN bytes (is SSS) take a look at the file NOTES for suggestions on how to reduce the size of PostScript files (and investigate 'lzps' and 'distill'). - Fixed a bug that could result in binding to the wrong local address for unicast conferences on a multi-homed host. - Fixed a bunch of bugs in site muting (were several ways that a 'muted' site could put marks on screen or change page -- there shouldn't be any now). - Fixed DefaultBrushColor X resource (was intended to select which brush color is initially selected but thing that build menu was using wrong name for resource). - Timers were still too aggressive. Need to average at least 300ms between replyers & want >100ms before first reply to accumulate multiple requests (otherwise if request arrives while we're in middle of reply we'll do duplicate reply). - Fixed DPS bug: was always using screen 0 for DPS context even if wb window on some other screen. (problem reported by Tom Kessler at Sun.) - Fixed several bugs in repair of pages that had been `cloned' from some other page (old code simply didn't work). From rem-conf-request@es.net Mon Oct 11 06:56:19 1993 Received: from rx7.ee.lbl.gov by osi-east.es.net via ESnet SMTP service id <05021-0@osi-east.es.net>; Mon, 11 Oct 1993 03:24:06 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA15234; Mon, 11 Oct 93 03:24:46 -0700 Message-Id: <9310111024.AA15234@rx7.ee.lbl.gov> To: rem-conf@es.net Cc: mbone@isi.edu Subject: new version of vat (2.16) available Date: Mon, 11 Oct 93 03:24:45 PDT From: Van Jacobson There's a new version of vat available for anonymous ftp from ftp.ee.lbl.gov in files sun-vat.tar.Z, sun-vat-dyn.tar.Z, dec-vat.tar.Z and decalpha-vat.tar.Z. A lot of bugs have been fixed (see attached list). Note that there's not a new SGI distribution (see the flame in the previous message about a new version of wb). However there is an 'alpha' snapshop of 2.16 taken about a month ago available as sgi-vat-2.16alpha.Z. It's missing about half the fixes listed below but it does fix the problem with multiple vats not working on an SGI Indy (or any SGI running Irix 5.x). If you have an Indy, you might want to grab this binary. - Van --------------------------------- v2.1[56]beta, Mon Oct 11 03:20:53 PDT 1993 - Changed default of PushToTalk from "false" to "true" since that's a 'safer' choice for novice users. - Changed right button semantics so that 'down' always means 'unmute' and 'up' always means 'mute' rather than up/down toggling current state. Toggling isn't particularly intuitive & is easy to get mute in wrong state. - Changed X resource names of `speakerphone' modes to match labels in control box. "SpeakerPhone" is now "MikeMutesNet" and "VTSpeakerPhone" is now "NetMutesMike". (problem reported by Greg Ryan (gregr@barossa.cs.su.oz.au)). - Fixed bugs in setting audio format (-f on command line): Was sending specified format but selection in control box was wrong, e.g., "pcm" when "pcm4" was selected. (bug reported by Eve Schooler) - SGI's IRIX 5.x seems to have broken the audio access socket when running multiple vats. Changed setup to set SO_REUSEPORT (which is hack to get around problems introduced by not having the real in_pcb.c fix). (problem report by Jim Martin; fix suggested by Andrew Cherenson) - Added checkbox controls for 'Keep All Sites' (-k) option and 'Mute New Sites' (-S) option. Fixed 'keep sites' logic so control would work with clobbering SiteDropTime setting. - added -M (make mike start unmuted), -J (make speaker start muted) and "-F audiodev" (use 'audiodev' as audio device rather than /dev/audio). (suggested by Ron Frederick) - fixed bug where site that re-used the empty slot of a site that had been muted came up muted. (analyzed by Matt Crawford.) - fixed bug where new site inherited 'rank' of last user of empty slot so dislay could end up with multiple 'last speaker' marks only one of which was real. (bug reported by Jim Martin & Steve Casner.) - Made bsd_audio work right for 2nd & later active vats (since 2nd & later think they're running with sun-audio). - Fixed lots of bugs in sun_audio processing when multiple vat windows active (was I asleep when I coded this?) - sites were vanishing after SiteDropTime minutes even if -k (keep sites) specified. Now make -k set SiteDropTime to 0 so inactive sites are really kept. (problem reported by Steve Casner.) - Change audio device model to support totally braindead, half-duplex PC audio cards (like SoundBlaster). - Fixed bug in Interviews that was sending a truncated WM_SIZE_HINTS struct to X server (this may have been cause of huge windows under DEC window manager). (problem reported by George Michaelson and Simon Coppins) - Added "vat.AF.blocks" resource (which defaults to 2) to try to get AudioFile cpu hogging down to reasonable levels. This resource multiplies the vat 20ms blocksize & is the unit that AF I/O is done in (e.g., 2 means 40ms blocks to/from AF, 3 means 60ms blocks, etc.). - Tried to get around bugs in Ultrix scheduler that seemed to be triggered by 20ms timeouts when vat released audio (a vat without audio should have been taking ~0% of cpu & was taking ~90%). Changed timeout to 200ms & cpu util went to 0 as expected. - Gave controls window same title as main window but with a preceeding "@". Made controls window pop up first time over vat window but, if you move it, it now stays where you put it. (suggested by Jim Martin & Daniel Karrenberg). - Made yet another try at making 'speakerphone' labels comprehensible. "Speakerphone (mike pri)" is now called "Mike mutes net", "Speakerphone (net pri)" is now called "Net mutes mike" and "Headphone" is now called "Full duplex". (too many people to list complained about old labels) - Fixed interviews to color field editor typein box gray, not pink. (color problem reported by Ken Hayes & Ron Frederick). - Fixed core dump that resulted when site vanished then re-appeared within two audio frame times (bug found by Steve Casner). From rem-conf-request@es.net Mon Oct 11 09:42:54 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <05777-0@osi-east.es.net>; Mon, 11 Oct 1993 06:42:19 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 11 Oct 1993 14:41:47 +0100 From: Angela Sasse Organisation: Computer Science, University College London Phone: +44-71-380-7212 To: mice-seminars@cs.ucl.ac.uk Subject: Slides for today's MICE seminar 15.00 GMT cc: rem-conf@es.net Date: Mon, 11 Oct 93 14:41:42 +0100 Sender: A.Sasse@cs.ucl.ac.uk The slides for today's talk are available by ftp from cs.ucl.ac.uk directory /cs/ftp/ftp/mice/seminars/gknight slides_1.ps - slides_17.ps I had some problems reading some of the diagram slides into wb because they are too large, so you might want to have hardcopy of slides 5, 6, 14-17 handy. Sorry about the short notice. If you are not picking the seminar from sd, please note that the address has changed to 224.5.17.12 port 32415 for wb. Angela ------------------------------------------------------------------ Angela Sasse The MICE project at UCL Dept. of Computer Science University College London tel. : +44-71-380 7212 Gower Street fax : +44-71-3871397 London WC1E 6BT email: a.sasse@uk.ac.ucl.cs From rem-conf-request@es.net Mon Oct 11 17:04:51 1993 Received: from piano.concert.net by osi-east.es.net via ESnet SMTP service id <11168-0@osi-east.es.net>; Mon, 11 Oct 1993 14:04:14 +0000 Received: by piano.concert.net (5.59/tas-concert/8-12-92) id AA09691; Mon, 11 Oct 93 17:04:00 -0400 Date: Mon, 11 Oct 93 17:04:00 -0400 From: Tom Sandoski Message-Id: <9310112104.AA09691@piano.concert.net> To: rem-conf@es.net Subject: Clinton Speech will be broadcast Cc: MBONE@ISI.EDU We are planning to broadcast President Clinton's speech at the University of North Carolina's 200th Birthday Celebration. The speech will be a part of festivities which will begin in UNC's Kenan Stadium tomorrow evening (October 12th) at 7:00pm. The session in sd is "UNC Bicentenial Celebration". From rem-conf-request@es.net Mon Oct 11 18:29:24 1993 Received: from sled.gsfc.nasa.gov by osi-east.es.net via ESnet SMTP service id <12085-0@osi-east.es.net>; Mon, 11 Oct 1993 15:20:07 +0000 Received: by sled.gsfc.nasa.gov (4.1/1.35) id AA00592; Mon, 11 Oct 93 18:20:04 EDT From: rogers@sled.gsfc.nasa.gov (Scott W. Rogers) Message-Id: <9310112220.AA00592@sled.gsfc.nasa.gov> Subject: NASA Select coverage of STS-58 (Columbia) Mission. To: rem-conf@es.net Date: Mon, 11 Oct 1993 18:20:04 -0400 (EDT) Cc: mbone@isi.edu Precedence: bulk X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1095 NASA Plans to launch STS-58 (Columbia) on Tuesday, October 12, 1993. The launch window opens at 10:53am EDT. A 14 day mission should conclude with a landing at Edwards Air Forse Base on SUnday, October 24, 1993 at 11:22am EDT.. I will create "sd" sessions entitled "NASA Select (STS-58/Columbia)" and will begin broadcasting about 10:30am EDT from NASA GOddard Space Flight Center. The "sd" session will be set to live for 15 days, however *I* will only be broadcasting during times of activety. I plan to cover launch through 12noon tomorrow (unless the launch is scrubbed). If anyone else is interested in providing a feed during other times, please let us (me) know. Since the landing is scheduled for a Sunday, it would be especially nice if someone would volunteer to broadcast it. -- -------------------------------------------------------------------------- Scott W. Rogers +1-301-286-1377 Computer Networking Branch --- Code 933 ---- Greenbelt, MD 20771 NASA Goddard Space Flight Center FAX: 301-286-1777 From rem-conf-request@es.net Mon Oct 11 20:28:43 1993 Received: from mothra.nts.uci.edu by osi-east.es.net via ESnet SMTP service id <13770-0@osi-east.es.net>; Mon, 11 Oct 1993 17:18:42 +0000 Received: by mothra.nts.uci.edu id AA07742 (5.65c/IDA-1.4.4 for rem-conf@es.net); Mon, 11 Oct 1993 17:18:36 -0700 Received: from [128.200.132.104] (godzilla.nts.uci.edu) by mothra.nts.uci.edu with SMTP id AA07736 (5.65c/IDA-1.4.4 for rem-conf@es.net); Mon, 11 Oct 1993 17:18:22 -0700 Message-Id: <199310120018.AA07736@mothra.nts.uci.edu> Date: Mon, 11 Oct 1993 17:23:09 -0800 To: rem-conf@es.net From: David Walker X-Sender: dhwalker@mothra.nts.uci.edu Subject: Joint UC Regents-CSU Trustees meeting to be broadcast Cc: Willi.Bokenkamp@ucop.edu, WWNail@uci.edu, oac_directors_meeting@oac.uci.edu People, We will be broadcasting the following meeting over the MBONE on Wednesday, October 13, 1993, for the benefit of other UC campuses and any others who are interested in higher education in California. I've attached an excerpt from an announcement of the meeting. I'll distribute an agenda tomorrow; however, the meeting starts at 9:00 and ends at 4:15 Pacific Daylight Time. David Walker Assistant Director, ECS Office of Academic Computing Addresses: Electronic Communication Services University of California Irvine, CA 92717-5475 (714) 856-7037 (714) 725-2270 (FAX) DHWalker@uci.edu ____________________________________________________________________ JOINT REGENTS-CSU TRUSTEES MEETING TO BE BROADCAST TO CAMPUSES Next Wednesday, Oct. 13, the Regents and CSU Board of Trustees will hold an unprecedented joint meeting from 9 a.m.- 4:15 p.m. in Sacramento. This historic first meeting between the two boards will be televised over the California Channel, which is carried by 62 cable stations to some 2 million viewers. The entire meeting also is available to all CSU and UC campuses via satellite. From rem-conf-request@es.net Tue Oct 12 07:19:36 1993 Received: from dns.ksc.nasa.gov by osi-east.es.net via ESnet SMTP service id <16089-0@osi-east.es.net>; Tue, 12 Oct 1993 04:08:52 +0000 Received: from escact.ksc.nasa.gov.nasa.gov ([128.159.177.14]) by dns.ksc.nasa.gov (4.1/SMI-4.1) id AA17209; Tue, 12 Oct 93 07:09:42 EDT Received: by escact.ksc.nasa.gov.nasa.gov (4.1/SMI-4.1) id AA01099; Tue, 12 Oct 93 07:09:07 EDT Date: Tue, 12 Oct 93 07:09:07 EDT From: mark@escact.ksc.nasa.gov (Mark Gibbons) Message-Id: <9310121109.AA01099@escact.ksc.nasa.gov.nasa.gov> To: rem-conf@es.net, rogers@sled.gsfc.nasa.gov Subject: Re: NASA Select coverage of STS-58 (Columbia) Mission. Cc: mbone@ISI.EDU NASA Plans to launch STS-58 (Columbia) on Tuesday, October 12, 1993. The launch window opens at 10:53am EDT. A 14 day mission should conclude with a landing at Edwards Air Forse Base on SUnday, October 24, 1993 at 11:22am EDT.. I think you mean Thursday, October 14. meg :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: mark e. gibbons mark@luke.ksc.nasa.gov M.S. INI-18 (v)407.867.4847 mark-gibbons@ksc.nasa.gov Kennedy Space Center, (f)407.867.4079 Florida 32899 "Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor." -- Wernher von Braun From rem-conf-request@es.net Tue Oct 12 10:27:04 1993 Received: from sled.gsfc.nasa.gov by osi-east.es.net via ESnet SMTP service id <17115-0@osi-east.es.net>; Tue, 12 Oct 1993 07:26:30 +0000 Received: by sled.gsfc.nasa.gov (4.1/1.35) id AA02585; Tue, 12 Oct 93 10:26:24 EDT From: rogers@sled.gsfc.nasa.gov (Scott W. Rogers) Message-Id: <9310121426.AA02585@sled.gsfc.nasa.gov> Subject: Re: NASA Select coverage of STS-58 (Columbia) Mission. To: mark@escact.ksc.nasa.gov (Mark Gibbons) Date: Tue, 12 Oct 1993 10:26:23 -0400 (EDT) Cc: rem-conf@es.net, mbone@isi.edu In-Reply-To: <9310121109.AA01099@escact.ksc.nasa.gov.nasa.gov> from "Mark Gibbons" at Oct 12, 93 07:09:07 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1433 > Date: Tue, 12 Oct 93 07:09:07 EDT > From: mark@escact.ksc.nasa.gov (Mark Gibbons) > Message-Id: <9310121109.AA01099@escact.ksc.nasa.gov.nasa.gov> > To: rem-conf@es.net, rogers@sled.gsfc.nasa.gov > Subject: Re: NASA Select coverage of STS-58 (Columbia) Mission. > Cc: mbone@ISI.EDU > NASA Plans to launch STS-58 (Columbia) on Tuesday, October 12, 1993. > The launch window opens at 10:53am EDT. A 14 day mission should > conclude with a landing at Edwards Air Force Base on Sunday, October > 24, 1993 at 11:22am EDT.. > > I think you mean Thursday, October 14. > mark e. gibbons mark@luke.ksc.nasa.gov M.S. INI-18 Oops, your right. Actually I think the press release I copied it from may have been wrong :-) Launch coverage will begin at 10:00am EDT (1400 UTC) on Thursday 14 October 1993. The launch window starts at 10:53am EDT (1453 UTC). I've modified the "sd" entry accordingly. Sorry for the confusion. The mission is still scheduled for 14 days. Landing should be at Edwards Air Force Base on Thursday, 28-October at 11:22am EDT (1522 UTC). Since this is a workday/hour, I will probably also broadcast this. -- -------------------------------------------------------------------------- Scott W. Rogers +1-301-286-1377 Computer Networking Branch --- Code 933 ---- Greenbelt, MD 20771 NASA Goddard Space Flight Center FAX: 301-286-1777 From rem-conf-request@es.net Tue Oct 12 13:27:20 1993 Received: from vitto.nts.uci.edu by osi-east.es.net via ESnet SMTP service id <19654-0@osi-east.es.net>; Tue, 12 Oct 1993 10:13:30 +0000 Received: by vitto.nts.uci.edu id AA09707 (5.65c/IDA-1.4.4 for rem-conf@es.net); Tue, 12 Oct 1993 10:13:22 -0700 Received: from [128.200.132.121] (red-october.nts.uci.edu) by vitto.nts.uci.edu with SMTP id AA09697 (5.65c/IDA-1.4.4 for rem-conf@es.net); Tue, 12 Oct 1993 10:13:11 -0700 Message-Id: <199310121713.AA09697@vitto.nts.uci.edu> Date: Tue, 12 Oct 1993 10:17:56 -0800 From: Keith CHONG To: rem-conf@es.net, mbone@ISI.EDU Subject: RS6000 and the MBONE I thought there was some discussion about getting the mbone software to work on an RS6000 a while back. I can't seem to find any record of it and I can't seem to find any software for an RS6000. So am I just confused or is there MBONE software that runs on the RS6000 and if so where is it. Keith Chong UCI OAC-ECS From rem-conf-request@es.net Tue Oct 12 13:49:20 1993 Received: from mothra.nts.uci.edu by osi-east.es.net via ESnet SMTP service id <20140-0@osi-east.es.net>; Tue, 12 Oct 1993 10:44:47 +0000 Received: by mothra.nts.uci.edu id AA01300 (5.65c/IDA-1.4.4 for rem-conf@es.net); Tue, 12 Oct 1993 10:44:39 -0700 Received: from [128.200.132.104] (godzilla.nts.uci.edu) by mothra.nts.uci.edu with SMTP id AA01280 (5.65c/IDA-1.4.4 for rem-conf@es.net); Tue, 12 Oct 1993 10:44:14 -0700 Message-Id: <199310121744.AA01280@mothra.nts.uci.edu> Date: Tue, 12 Oct 1993 10:49:06 -0800 To: ari@es.net (Ari Ollikainen) From: David Walker X-Sender: dhwalker@mothra.nts.uci.edu Subject: Re: Joint UC Regents-CSU Trustees meeting to be broadcast Cc: rem-conf@es.net, mbone@isi.edu, KChong@uci.edu, Willi.Bokenkamp@ucop.edu, WWNail@uci.edu, oac_directors_meeting@oac.uci.edu, RDHobby@uci.edu Ari, At 6:38 PM 10/11/93 -0700, Ari Ollikainen wrote: >I appreciate your sending this notice to rem-conf, but don't you think you >ALSO need to set up the appropriate MBONE multicast information AS WELL AS >inform the MBONE community (MBONE@ISI.EDU)? > >Just a thought... > > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Ari Ollikainen ari@es.net National Energy Research Supercomputer Center >ESnet (Energy Sciences Network) Lawrence Livermore National Laboratory >510-423-5962 FAX:510-423-8744 P.O. BOX 5509, MS L-561, Livermore, CA 94550 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sorry about that; I should have let our expert, Keith Chong, send the announcement. We will be broadcasting audio and video with a TTL of 126; the video will be at 128KB. Also, I've attached the agenda I promised yesterday. The times are Pacific Daylight Time. David Walker Office of Academic Computing University of California, Irvine _____________________________________________________________________ JOINT MEETING THE REGENTS OF THE UNIVERSITY OF CALIFORNIA THE TRUSTEES OF THE UNIVERSITY OF THE CALIFORNIA STATE ____________________________________________________________________________ _ Location: Assembly Chambers, State Capitol Sacramento Date: October 13,1993 ____________________________________________________________________________ _ I. INTRODUCTION (9:00 a.m.) Welcome and Remarks Willie L. Brown, Jr. Speaker of the Assembly David Roberti, President Pro Tempore of the Senate Leo T. McCarthy, Lieutenant Governor (9:15 a.m.) Convene Proceedings Pete Wilson, Governor ROLL CALL (9:25 a.m.) Opening Remarks Anthony M. Vitti, Chairman, The California State University Board of Trustees Howard H. Leach, Chairman, The Regents of the University of California II. HIGHER EDUCATION ISSUES (9:35 a.m.) The effect on higher education of changing demographies and population growth. Leo Estrada, Associate Professor, Graduate School of Architecture and Urban Planning, University of California, Los Angeles. (9:55 a.m.) The value of research and an educated work force to the social and economic health of California. John O. Wilson, Executive Vice President and Cheif Economist, Bank of America (10:15 a.m.) Long range financing constraints. Thomas Hayes, former Director, State Department of Finance (10:40 a.m.) Board Discussion III. THE CALIFORNIA MASTER PLAN FOR HIGHER EDUCATION (11:10 a.m.) Responding to a new stage in the history of higher education. Clark Kerr, President Emeritus, University of California (11:40 a.m.) Board Discussion. IV. DISCUSSION: A REVIEW AND SYNTHESIS OF MORNING PRESENTATIONS (1:30 p.m.) Panel Discussion. Questions and comments from Board Members. Warren H. Fox, Director, California Postsecondary Education Commission ( Moderator) Jack W. Peltason, President, University of California Barry Munitz, Chancellor, California State University David Mertes, Chancellor, California Community College Rev. Paul L/ Locatelli, Chair, Executive Commitee of the Association of Independent California College and Universities. V. INSTITUTIONAL RESPONSE (2:30 p.m.) Coping with the short-term financial problem; initiatives for the improvement in the long term, including new technology and modernization of educational delivery. Walter E. Massey, Provost, University of California Molly Corbett Broad, Executive Vice Chancellor Cailfornia State University (3:00 p.m.) Board discussion. VI. SUMMARY PRESENTATION (3:30 p.m.) Observations Neil Morgan, Associate Editor, San Diego Union-Tribune VII. CLOSING REMARKS (4:00 p.m.) Chairman Vitti Chairman Leach (4:15 p.m.) Adjourn. From rem-conf-request@es.net Tue Oct 12 14:01:42 1993 Received: from fenris.dhhalden.no by osi-east.es.net via ESnet SMTP service id <20292-0@osi-east.es.net>; Tue, 12 Oct 1993 10:57:05 +0000 Received: from sigallah.dhhalden.no by fenris.dhhalden.no with SMTP (PP) id <00248-0@fenris.dhhalden.no>; Tue, 12 Oct 1993 18:55:35 +0100 Received: by sigallah.dhhalden.no (NX5.67c/NX3.0S) id AA14556; Tue, 12 Oct 93 17:53:18 GMT Date: Tue, 12 Oct 1993 17:50:47 +0000 (GMT) From: Borre Ludvigsen Subject: Re: NASA Select coverage of STS-58 (Columbia) Mission. To: "Scott W. Rogers" Cc: Mark Gibbons , rem-conf@es.net, mbone@isi.edu In-Reply-To: <9310121426.AA02585@sled.gsfc.nasa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Just in case people might be interested on a regular basis: finger news@sseop.jsc.nasa.gov for the shuttle launch schedule finger nasanews@space.mit.edu for NASA Daily News - Barre Ludvigsen From rem-conf-request@es.net Tue Oct 12 14:55:06 1993 Received: from duke.cs.duke.edu by osi-east.es.net via ESnet SMTP service id <00887-0@osi-east.es.net>; Tue, 12 Oct 1993 11:48:20 +0000 Received: from macbeth.cs.duke.edu by duke.cs.duke.edu (5.65/3.6G/4.1.3) id AA01193; Tue, 12 Oct 93 14:48:11 -0400 Received: from localhost by macbeth.cs.duke.edu (5.65/3.6L/4.1.3) id AA05008; Tue, 12 Oct 93 14:48:09 -0400 Message-Id: <9310121848.AA05008@macbeth.cs.duke.edu> To: Keith CHONG Cc: rem-conf@es.net, mbone@ISI.EDU Subject: Re: RS6000 and the MBONE In-Reply-To: Your message of "Tue, 12 Oct 1993 10:17:56 -0800." <199310121713.AA09697@vitto.nts.uci.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Oct 1993 14:48:09 -0400 From: Thomas Pusateri In message <199310121713.AA09697@vitto.nts.uci.edu> you write: > >I thought there was some discussion about getting the mbone software to >work on an RS6000 a while back. I can't seem to find any record of it and >I can't seem to find any software for an RS6000. So am I just confused or >is there MBONE software that runs on the RS6000 and if so where is it. > >Keith Chong >UCI OAC-ECS > > I did the port some time ago but have not yet released it. I hope to do so soon but it depends on time and the consent of IBM. There is still one or two last bugs to work out when running mrouted. Also, since vat and sd source is not available, only nv was ported. Tom Pusateri pusateri@cs.duke.edu From rem-conf-request@es.net Wed Oct 13 09:38:45 1993 Received: from faui45.informatik.uni-erlangen.de by osi-east.es.net via ESnet SMTP service id <12911-0@osi-east.es.net>; Wed, 13 Oct 1993 06:20:25 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA06906 (5.65c-5/7.3v-FAU); Wed, 13 Oct 1993 14:19:52 +0100 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA25612 (5.65c-5/7.3m-FAU); Wed, 13 Oct 1993 09:45:29 +0100 From: Toerless Eckert Message-Id: <199310130845.AA25612@faui43.informatik.uni-erlangen.de> Subject: Looking for product To: rem-conf@es.net Date: Wed, 13 Oct 93 9:45:19 MET Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] Hello Can anybody give me a hint to an overhead projection panel with built in touch screen capabilities, i.e.: the tool for wb to put on an overhead projector run wb on it and use some kind of pen on it to interact. Any hints welcome. Any resolution and color or bw. Thanks -- Toerless Eckert Universitaet Erlangen Nuernberg Lehrstuhl fuer Betriebsysteme Martensstrasse 1 D-91058 Erlangen, Germany Tel.: +49 9131 85 7278 FAX: +49 9131 85 8732 / +49 9131 39388 eckert@informatik.uni-erlangen.de /C=de/A=dbp/P=uni-erlangen/OU=informatik/S=eckert/ From rem-conf-request@es.net Wed Oct 13 13:12:57 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <15124-0@osi-east.es.net>; Wed, 13 Oct 1993 10:12:18 +0000 Received: from btn.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Wed, 13 Oct 1993 10:12:09 -0700 Date: Wed, 13 Oct 93 10:12:07 -0700 From: touch@ISI.EDU Posted-Date: Wed, 13 Oct 93 10:12:07 -0700 Message-Id: <9310131712.AA02099@btn.isi.edu> Received: by btn.isi.edu (NX5.67c/4.0.3-4) id ; Wed, 13 Oct 93 10:12:07 -0700 Original-Received: by NeXT.Mailer (1.87.1) PP-warning: Illegal Received field on preceding line Original-Received: by NeXT Mailer (1.87.1) PP-warning: Illegal Received field on preceding line To: Toerless Eckert Subject: Re: Looking for product Cc: rem-conf@es.net > From: Toerless Eckert > Subject: Looking for product > To: rem-conf@es.net > Date: Wed, 13 Oct 93 9:45:19 MET > > Can anybody give me a hint to an overhead projection panel with > built in touch screen capabilities, i.e.: the tool for wb to put on > an overhead projector run wb on it and use some kind of pen on it to > interact. Any hints welcome. Any resolution and color or bw. > > Thanks > -- > Toerless Eckert > Sure - we use an Ovation LCD panel. The panel is placed on a *bright* overhead, and the images are displayed in color. The Ovation has an option called "Cyclops" which allows use of a laser pointer *on the projector screen* to be used as a mouse on the computer where the video is sourced. Cyclops uses a primitive CCD camera pointed at the display screen to read the position of the laserpointer, and feeds that information back to a PC-clone or Mac portable (not Duo - needs ADB port) as a mouse position or button action. It's not quite what you asked for (touchscreen), but considering the wattage of overhead projector required to use overhead display panels, looking down into the light source to touch the screen could be hazardous. Ovations were advertized in the latest Byte, MacWorld, etc, and are sold by (among others) MacWarehouse in the US. Hope that helps. Joe Touch touch@isi.edu (PS - we reviewed a number of panels and chose Ovation, for a number of reasons. There are other panels available, but not many have mouse feedback, let alone touch-screens). From rem-conf-request@es.net Wed Oct 13 14:02:56 1993 Received: from faui45.informatik.uni-erlangen.de by osi-east.es.net via ESnet SMTP service id <15422-0@osi-east.es.net>; Wed, 13 Oct 1993 10:27:13 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA21807 (5.65c-5/7.3v-FAU); Wed, 13 Oct 1993 18:26:53 +0100 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA12174 (5.65c-5/7.3m-FAU); Wed, 13 Oct 1993 18:26:52 +0100 From: Toerless Eckert Message-Id: <199310131726.AA12174@faui43.informatik.uni-erlangen.de> Subject: Re: Looking for product To: touch@ISI.EDU Date: Wed, 13 Oct 93 18:26:48 MET Cc: Toerless.Eckert@informatik.uni-erlangen.de, rem-conf@es.net In-Reply-To: <9310131712.AA02099@btn.isi.edu>; from "touch@ISI.EDU" at Oct 13, 93 10:12 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] > From touch@ISI.EDU Wed Oct 13 18:13 MET 1993 > Received: from faui45.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; > id AA10009 (5.65c-5/7.3m-FAU); Wed, 13 Oct 1993 18:13:12 +0100 > Received: from venera.isi.edu by uni-erlangen.de with SMTP; > id AA21228 (5.65c-5/7.3v-FAU); Wed, 13 Oct 1993 18:12:42 +0100 > Received: from btn.isi.edu by venera.isi.edu (5.65c/5.61+local-13) > id ; Wed, 13 Oct 1993 10:12:09 -0700 > Date: Wed, 13 Oct 93 10:12:07 -0700 > From: touch@ISI.EDU > Posted-Date: Wed, 13 Oct 93 10:12:07 -0700 > Message-Id: <9310131712.AA02099@btn.isi.edu> > Received: by btn.isi.edu (NX5.67c/4.0.3-4) > id ; Wed, 13 Oct 93 10:12:07 -0700 > Received: by NeXT.Mailer (1.87.1) > Received: by NeXT Mailer (1.87.1) > To: Toerless Eckert > Subject: Re: Looking for product > Cc: rem-conf@es.net > > > > > From: Toerless Eckert > > Subject: Looking for product > > To: rem-conf@es.net > > Date: Wed, 13 Oct 93 9:45:19 MET > > > > > Can anybody give me a hint to an overhead projection panel with > > built in touch screen capabilities, i.e.: the tool for wb to put on > > an overhead projector run wb on it and use some kind of pen on it to > > interact. Any hints welcome. Any resolution and color or bw. > > > > > Thanks > > -- > > > Toerless Eckert > > > > > Sure - we use an Ovation LCD panel. The panel is placed on a *bright* > overhead, and the images are displayed in color. > > The Ovation has an option called "Cyclops" which allows use of a laser > pointer *on the projector screen* to be used as a mouse on the computer where > the video is sourced. Cyclops uses a primitive CCD camera pointed at the > display screen to read the position of the laserpointer, and feeds that > information back to a PC-clone or Mac portable (not Duo - needs ADB port) as > a mouse position or button action. > > It's not quite what you asked for (touchscreen), but considering the wattage > of overhead projector required to use overhead display panels, looking down > into the light source to touch the screen could be hazardous. > > Ovations were advertized in the latest Byte, MacWorld, etc, and are sold by > (among others) MacWarehouse in the US. Well, would be interesting to test, but i don't think it's that useful for wb, because it's quite difficult to draw anything useful free hand with a laser pointer. It's probably only good for pointing. Anyhow, thanks for the information. Toerless Eckert From rem-conf-request@es.net Wed Oct 13 14:23:24 1993 Received: from norman.nwnet.net by osi-east.es.net via ESnet SMTP service id <15544-0@osi-east.es.net>; Wed, 13 Oct 1993 10:39:09 +0000 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA03960; Wed, 13 Oct 93 10:38:44 -0700 Date: Wed, 13 Oct 1993 10:29:38 -0700 (PDT) From: Allen Robel Subject: Re: RTP port numbers To: Randall Atkinson Cc: Allen Robel , rem-conf@es.net In-Reply-To: <9310071902.AA20331@itd.nrl.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 7 Oct 1993, Randall Atkinson wrote: > Filtering on a range is not very secure, particularly when you have to > filter on a fairly good sized range as appears to be the case for the proposal > of dynamic port assignment for RTP. Range filtering is much less secure > than just allowing the exact ports that one wants to permit through. So > I don't think range filtering ameliorates my (and other folks') concerns. I'm sorry Ran, but I don't understand this. The semantics of a range of ports that mean "video" would, to me, be the same as that for one port that meant "video." Are you saying that, for some reason, software is less reliable when filtering on ranges, or that, semantically, there is a difference between a range of ports, and one port, that both meant "video" (entirely possible since, like I said before, I haven't followed this discussion very closely). If you mean the former, then I disagree. If you mean the latter, I'd appreciate hearing what the difference between the two cases is that causes security concerns. thanks, Allen Robel Internet: allen@nwnet.net Network Engineer voice: (206)562-3000 NorthWestNet FAX: (206)562-4822 From rem-conf-request@es.net Wed Oct 13 17:39:24 1993 Received: from itd.nrl.navy.mil by osi-east.es.net via ESnet SMTP service id <18942-0@osi-east.es.net>; Wed, 13 Oct 1993 14:29:41 +0000 Received: from ascent.itd.nrl.navy.mil by itd.nrl.navy.mil (4.1/SMI-4.1) id AA04634; Wed, 13 Oct 93 17:29:30 EDT Date: Wed, 13 Oct 93 17:29:30 EDT From: atkinson@itd.nrl.navy.mil (Randall Atkinson) Message-Id: <9310132129.AA04634@itd.nrl.navy.mil> To: allen@nwnet.net Subject: Re: RTP port numbers Cc: rem-conf@es.net % > Filtering on a range is not very secure, particularly when you have to % > filter on a fairly good sized range as appears to be the case for the proposal % > of dynamic port assignment for RTP. Range filtering is much less secure % > than just allowing the exact ports that one wants to permit through. So % > I don't think range filtering ameliorates my (and other folks') concerns. % % I'm sorry Ran, but I don't understand this. Allen, The proposal at the time of my note was that the port numbers used by RTP would be _dynamic_ within a certain range (e.g. over 1024). Other protocols might also exist in the range (e.g. from portmapper or similar ilk). For that case, if one permitted all traffic in that range through the firewall (as necessary to let RTP traffic through), then one would also create a hole in the firewall that other (possibly malicious or otherwise undesirable) traffic could use to get through. If there are a set of RTP ports that are dedicated only to RTP by IANA, then letting that traffic through would be less risky than the case where port assignment was dynamic and not limited to ports predetermined by IANA. In short, firewall techniques work better for protocols which have fixed, predetermined port numbers and do not use any form of dynamic port assignment. Those who are interested in this sort of thing should read Steve Bellovin's recent article in ACM CCR. Regards, Ran atkinson@itd.nrl.navy.mil From rem-conf-request@es.net Wed Oct 13 19:16:17 1993 Received: from achilles.ctd.anl.gov by osi-east.es.net via ESnet SMTP service id <20413-0@osi-east.es.net>; Wed, 13 Oct 1993 16:06:01 +0000 Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA29020; Wed, 13 Oct 93 18:05:49 CDT Message-Id: <9310132305.AA29020@achilles.ctd.anl.gov> To: Toerless Eckert Cc: touch@isi.edu, rem-conf@es.net, b32357@achilles.ctd.anl.gov Subject: Re: Looking for product In-Reply-To: (Your message of Wed, 13 Oct 93 18:26:48 +0700.) <199310131726.AA12174@faui43.informatik.uni-erlangen.de> Date: Wed, 13 Oct 93 18:05:48 -0500 From: b32357@achilles.ctd.anl.gov Has anyone tried connecting a stylus and tablet to a Sun for use with wb? Linda From rem-conf-request@es.net Thu Oct 14 05:34:16 1993 Received: from sics.se by osi-east.es.net via ESnet SMTP service id <23857-0@osi-east.es.net>; Thu, 14 Oct 1993 02:21:23 +0000 Received: by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) id AA25306; Thu, 14 Oct 93 10:21:09 +0100 Date: Thu, 14 Oct 93 10:21:09 +0100 From: Ulf Bilting Message-Id: <9310140921.AA25306@sics.se> To: mice-seminars@cs.ucl.ac.uk, rem-conf@es.net Subject: MICE seminar Oct 19 The third international MICE seminar will be held on Tuesday October 19, 1993 from KTH in Stockholm It will be multicast on the MBONE on the following addresses audio: vat on 224.5.17.12 port default video: ivs on 224.5.17.12 port default whiteboard: wb on 224.5.17.12 port 32416 Please limit other traffic during times below Listening participants should limit their video send rate to very low (~10kb/s) and be prepared to shut off completely if audio goes below tolerable quality threshold. Seminar program: Tuesday October 19, 9.30 - 11.30 CET (= 8.30-10.30 GMT) Informal workshop on Multicast Conferencing - Steve Deering, Xerox PARC, state of the art and research issues (45 min) - Presentation of experiences from the MICE project (Volunteer form UCL?) - Discussion Tuesday October 19, 13.00 - 16.00 CET Informal workshop on Mobile personal computing and communication (mpc&c) 20 minute presentations - Gerald Maguire, Columbia Univ and KTH, State of the art in mpc&c,Walkstation - Frank Reichert, KTH, Walkstation and the ERIC testbed - Franco Davoli, University of Genoa, DIST Radio Net - Sudheer Grandhi, WINLAB, Resource allocation in Multi User Radio Systems - H. Tenhunen, KTH, VLSI Trends for Mobile Communication - Discussion ----------------------------------------------------------------------------- Abstracts: Internet Multicasting Routing: State of the Art and Open Research Issues Steve Deering, Xerox PARC Multicast routing protocols have enabled the development of a number of exciting new Internet applications, most notably real-time audio, video, and shared-workspace conferencing and collaboration tools. In this talk, I will describe the work to date on multicast routing protocols for internetworks and the current state of the Internet multicast routing infrastructure known as "the MBone". I will also discuss a number of important, open research issues, including bandwidth management for real-time multicast applications and scaling of multicast routing, and I will briefly describe efforts now underway to address some of those issues. ------------------------------------------------- State of the Art in Mobile Personal Computing and Communication (MPC&C) and a Router for this setting Gerald Maguire, Columbia Univ. and KTH This talk gives a brief overview of state of the art in computing and communications with an emphasis on issues relevant to mobile personal devices. The focus of the talk will be upon an experimental platform for exploring new interfaces and routing. We call this device "MINT" for Mobile INTernet router. Its key features and our initial experimental directions will be described. ------------------------------------------------------------------ Walkstation II - Project Presentation G. Maguire, F. Reichert Abstract - Today, mobility of portable computers and workstations is not transparent to users. They adjust to reduced services as long as they have no connection to a supporting infrastructure. The goal of the Walkstation project is to realize a user transparent mobile communication system based on wireless links (infrared / radio) operating at 1-10 Mbit/sec. The Walkstation II project will not only investigate wireless networks but a complete radio based cellular system for interactive mobile multimedia applications including aspects of VLSI design, radio communication, network protocols and mobile application services. We have developed a device for mobile internet routing (MINT) which has sufficient computational power to perform all necessary communication protocol operations, including access to TCP/IP networks. The MINT hardware had been developed in a pre-project phase in conjunction with HP Labs (Palo Alto). The Mobile*IP network implementation developed at Columbia University, USA will act as a starting point. Network performance measurements (planned are at least 50 to 100 users) and network simulations will give further directions for improvements and network management. In cooperation with Stockholm Gigabit Network (SGN) we will also examine the use of ATM as a high-speed backbone technology. ------------------------------------------------------------------- DIST RADIO NET Franco Davoli DIST, University of Genua, Italy Protocol development and experimental testbed. This talk will give an overview of the current status and ongoing activity in packet radio at the Department of Communications, Computer and Systems Science (DIST) of the University of Genoa. DIST Radio Net is a small amateur packet radio network based on the AVC-R-ISA access protocol, which is centered around a base station in a cellular fashion, handling peripheral packet transmissions with a sort of "adaptive polling" algorithm, and using TCP/IP at the upper layers. Two major developments are being currently undertaken, regarding the introduction of 56 kbps modems and the modification of the protocol to handle packet voice and data. --------------------------------------------------------------------- RESOURCE ALLOCATION IN MULTIUSER RADIO SYSTEMS Sudheer A. Grandhi WINLAB, Rutgers University, New Jersey, U.S.A. This talk is on a distributed dynamic resource allocation(DDRA) scheme based on local signal and interference measurements is proposed for multiuser mobile radio systems. This scheme is obtained by integrating distributed dynamic channel assignment(DDCA) with distributed power control. The DDRA scheme allows for asynchronous power control and incorporates a maximum transmitter power level for the system. The power control of the DDRA scheme is shown to converge to power levels less than or equal to the chosen maximum. Simulation results show that the DDRA scheme offers a higher system capacity than the DDCA scheme alone. ------------------------------------------------------------------------- VLSI Trends for Mobile COmmunication H. Tenhunen, KTH-ELECTRUM, ESDlab This presentation will overview the requirements for system level integration of mobile communication equipment and related design methodology and technology challenges. The vital part is new reciever and tranmsmitter architectures based on DSP and on-chip low voltage analog integration. -------------------------------------------------------------------- From rem-conf-request@es.net Thu Oct 14 08:00:54 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <24374-0@osi-east.es.net>; Thu, 14 Oct 1993 05:00:18 +0000 Received: from benjy.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Oct 1993 12:57:35 +0100 From: Angela Sasse Organisation: Computer Science, University College London Phone: +44 71 380 7212 To: Ulf Bilting cc: mice-seminars@cs.ucl.ac.uk, rem-conf@es.net Subject: Re: MICE seminar Oct 19 In-reply-to: Your message of "Thu, 14 Oct 93 10:21:09 BST." <9310140921.AA25306@sics.se> Date: Thu, 14 Oct 93 12:57:32 +0100 Sender: A.Sasse@cs.ucl.ac.uk >The third international MICE seminar will be held >on Tuesday October 19, 1993 from KTH in Stockholm >Tuesday October 19, 9.30 - 11.30 CET (= 8.30-10.30 GMT) ^^^^^^^^^^^^^^^^^^ UK switches to GMT on Oct 24, there 09.30 BST start in the UK. Angela From rem-conf-request@es.net Thu Oct 14 11:08:29 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <25755-0@osi-east.es.net>; Thu, 14 Oct 1993 08:07:55 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 14 Oct 1993 16:07:31 +0100 To: rem-conf@es.net Subject: Whether shuttle launch and weather Date: Thu, 14 Oct 93 16:07:30 +0100 From: Jon Crowcroft i'm sitting here litening to nasa select on the mbone, and watching the shuttle, and in the background i have a meteosat feed of the weather over the US... i wasnt surprised just now when they said it was too stormy to launch - maybe they need to use this technology more:-) jon From rem-conf-request@es.net Thu Oct 14 11:16:47 1993 Received: from norman.nwnet.net by osi-east.es.net via ESnet SMTP service id <25728-0@osi-east.es.net>; Thu, 14 Oct 1993 08:04:18 +0000 Received: by norman.nwnet.net (5.65/UW-NDC Revision: 2.27 ) id AA25833; Thu, 14 Oct 93 08:04:13 -0700 Date: Thu, 14 Oct 1993 08:02:11 -0700 (PDT) From: Allen Robel Subject: Re: RTP port numbers To: Randall Atkinson Cc: rem-conf@es.net In-Reply-To: <9310132129.AA04634@itd.nrl.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 13 Oct 1993, Randall Atkinson wrote: > The proposal at the time of my note was that the port numbers used by > RTP would be _dynamic_ within a certain range (e.g. over 1024). > Other protocols might also exist in the range (e.g. from portmapper or > similar ilk). Ah, OK, thanks. I misunderstood that there would be a range that would include *only* video assigned by IANA and that no other services would use this range. Thanks Ran. Allen Robel Internet: allen@nwnet.net Network Engineer voice: (206)562-3000 NorthWestNet FAX: (206)562-4822 From rem-conf-request@es.net Thu Oct 14 16:44:25 1993 Received: from sled-f.gsfc.nasa.gov by osi-east.es.net via ESnet SMTP service id <01181-0@osi-east.es.net>; Thu, 14 Oct 1993 13:43:51 +0000 Received: by sled.gsfc.nasa.gov (4.1/1.35) id AA15669; Thu, 14 Oct 93 16:43:43 EDT From: rogers@sled.gsfc.nasa.gov (Scott W. Rogers) Message-Id: <9310142043.AA15669@sled.gsfc.nasa.gov> Subject: STS-58 Launch Rescheduled To: mbone@isi.edu, rem-conf@es.net Date: Thu, 14 Oct 1993 16:43:43 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 639 The Launch of NASA's Space Shuttle Columbia with mission STS-58 has been rescheduled for Friday 15-October-1993 at 10:53am EDT (1453 UTC). We (at GSFC) will resume multicasting it at least 2 hours before launch. I've changes the AUDIO to DVI4 at someones suggestion as it is supposed to send less packets per second through the routers. -- -------------------------------------------------------------------------- Scott W. Rogers +1-301-286-1377 Computer Networking Branch --- Code 933 ---- Greenbelt, MD 20771 NASA Goddard Space Flight Center FAX: 301-286-1777 From rem-conf-request@es.net Thu Oct 14 20:12:54 1993 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <04348-0@osi-east.es.net>; Thu, 14 Oct 1993 17:00:51 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA06014; Thu, 14 Oct 93 17:00:50 PDT Date: Thu, 14 Oct 93 17:00:50 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9310150000.AA06014@viipuri.nersc.gov> To: rem-conf@es.net Subject: FWD: HPCC conference This was mis-addressed to rem-conf-request... ----- Begin Included Message ----- >From rrs@cerc.wvu.edu Thu Oct 14 12:05:25 1993 From: rrs@cerc.wvu.edu (Robert Shank) Date: Thu, 14 Oct 93 15:05:09 EDT To: mbone@isi.edu, rem-conf-request@es.net Subject: HPCC conference Content-Length: 1826 Software Valley XII High Performance Computing and Communications On October 20 and 21, 1993 the annual Software Valley conference will be held in Huntington, WV. We will be multicasting the speakers and afternoon panel discussion across the MBone on October 21 between 9:00 am and 3:30 pm EDT. The agenda for Thursday, October 21, 1993 is: 9:00 - 9:10am Taped Overview from Wednesday Conference activities 9:10 - 9:55am Dr. Michael Nelson Office of Science & Technology Policy "Overview of the Federal Government HPCC" 10:00 - 10:25am Coffee Break 10:25 - 10:30am John Turner West Virginia University Hospitals TeleMedicine Project "MDTV Overview" 10:30 - 11:15am Prof. Gio Wiederhold ARPA/SISTO "HPCC from an ARPA and Industry Perspective" 11:15 - 12:00pm TBD 12:00 - 1:30pm Sen. Robert Byrd U.S. Senator from West Virginia Keynote Address 1:30 - 3:00pm Panel on Future Directions of HPCC 3:00 - 3:15pm Concluding Remarks In the afternoon, we will try to conduct a panel session over the MBone with the primary purpose of demonstrating the capability of long distance participation in panel discussions. Participants in the panel discussion will be: >From Huntington, WV Peter Higgins, Deputy Assistant Director Automation, CJIS >From Morgantown, WV Dr. Jack Callahan, Concurrent Engineering Research Center, WVU >From Palo Alto, CA Dr. Mark Weiser, Manager of the Computer Science Lab at Xerox PARC Dr. Ton Kitchens, Head of HPCC for the Dept. of Energy Thanks to Ron Frederic @ PARC for the help AT&T and C&P for communications Sun Microsystems for an extra IPX w/ VideoPix ----- End Included Message ----- From rem-conf-request@es.net Sat Oct 16 18:23:04 1993 Received: from horse.ee.lbl.gov by osi-east.es.net via ESnet SMTP service id <22263-0@osi-east.es.net>; Sat, 16 Oct 1993 15:17:09 +0000 Received: by horse.ee.lbl.gov for rem-conf@es.net (5.65/1.41) id AA25339; Sat, 16 Oct 93 15:17:07 -0700 From: mccanne@horse.ee.lbl.gov (Steven McCanne) Message-Id: <9310162217.AA25339@horse.ee.lbl.gov> To: rem-conf@es.net Subject: in_pcb.c fix for ultrix 4.3 Date: Sat, 16 Oct 93 15:17:07 PDT I've put Van's in_pcb.c fix into Ultrix 4.3 kernel. The file INPCB.ultrix.tar.Z can be retrieved via anonymous ftp to ftp.ee.lbl.gov. Source diffs and objects are both included. Recall that this fix remedies a bug in the 4.3bsd networking code that would not allow a socket destination to be bound to a multicast address. As a workaround, vat (and the other conferencing tools) revert to INADDR_ANY if the multicast bind fails, which means that conferences sharing the same port are intermixed (e.g., someone directing a unicast vat at you can appear in your Mbone Audio session without you knowing they are only unicasting). Steve From rem-conf-request@es.net Sun Oct 17 14:07:51 1993 Received: from nightshade.cs.odu.edu by osi-east.es.net via ESnet SMTP service id <26340-0@osi-east.es.net>; Sun, 17 Oct 1993 11:00:31 +0000 Received: by nightshade.cs.odu.edu (4.1/lanleaf2.4) id AA05742; Sun, 17 Oct 93 14:01:34 EDT Date: Sun, 17 Oct 1993 13:47:30 -0400 (EDT) From: -% urbane RuFneCk %- Subject: Problems with Vat and Wb. To: out-mbone@cs.odu.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello.. I'm having problems getting wb to work with any other wb. I have two multicast machines on the same ethernet (128.82.6.128). wb and vat work fine on each machine but don't seem to sense each other's presence. nv works perfectly, so i don't think its a kernel or protocol problem. i have sd v1.14 and have tried both wb.static/wb and vat.dyn through it; i've also tried launching them by themselves. Same result. The first time I launched wb it worked between the machines. The machines are Sun IPCs running 4.1.3. Thanks for any help! keith@cs.odu.edu From rem-conf-request@es.net Mon Oct 18 15:04:51 1993 Received: from bnl.gov by osi-east.es.net via ESnet SMTP service id <07587-0@osi-east.es.net>; Mon, 18 Oct 1993 11:49:22 +0000 Received: by bnl.gov (5.57/Ultrix3.0-C) id AA00614; Mon, 18 Oct 93 14:49:11 -0400 Received: by maeva.ccd.bnl.gov.ccd.bnl.gov (5.0/SMI-SVR4) id AA15439; Mon, 18 Oct 93 14:49:09 EDT Date: Mon, 18 Oct 93 14:49:09 EDT From: gc@maeva.ccd.bnl.gov (Graham Campbell) Message-Id: <9310181849.AA15439@maeva.ccd.bnl.gov.ccd.bnl.gov> To: rem-conf@es.net Subject: Whats happening? X-Sun-Charset: US-ASCII Content-Length: 314 My workstation is the local mbone router. I have noticed a strange pattern of CPU usage while the router code is running. Roughly every 75 sec. there is a 15 sec. burst of CPU activity that hits about 50% on the perfmeter. This pattern seems independent of mbone activity. Anybody know whats happening? Graham From rem-conf-request@es.net Mon Oct 18 17:12:32 1993 Received: from garb5.bellcore.com by osi-east.es.net via ESnet SMTP service id <10025-0@osi-east.es.net>; Mon, 18 Oct 1993 14:11:57 +0000 Received: by garb5.bellcore.com (5.61/1.34) id AA01022; Mon, 18 Oct 93 17:11:49 -0400 Date: Mon, 18 Oct 93 17:11:49 -0400 From: bianchi@bellcore.com (Michael H Bianchi) Message-Id: <9310182111.AA01022@garb5.bellcore.com> To: rem-conf@es.net Subject: Sparc10 audio box The Sparc 10 audio box has separate inputs for microphone level and line-level, and separate outputs at headphone-level and line-level. Is there a version of sd/vat that understands the ioctl protocol for switching between these various inputs? Using the line-level input and output would make sense for mbone telecasts. Mike Bianchi (201) 829-5055 bianchi@bellcore.com From rem-conf-request@es.net Mon Oct 18 19:21:25 1993 Received: from Sun.COM by osi-east.es.net via ESnet SMTP service id <14137-0@osi-east.es.net>; Mon, 18 Oct 1993 16:08:10 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA23011; Mon, 18 Oct 93 16:08:08 PDT Received: from amber.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA14262; Mon, 18 Oct 93 16:07:56 PDT Received: by amber.Eng.Sun.COM (5.0/SMI-SVR4) id AA09082; Mon, 18 Oct 93 16:07:45 PDT Date: Mon, 18 Oct 93 16:07:45 PDT From: Don.Hoffman@Eng.Sun.COM (Don Hoffman) Message-Id: <9310182307.AA09082@amber.Eng.Sun.COM> To: rem-conf@es.net, bianchi@bellcore.com Subject: Re: Sparc10 audio box X-Sun-Charset: US-ASCII Content-Length: 1037 If you are running vat under Solaris 2.2 or 2.3, then you can start up "audiocontrol" at the same time. Use it to redirect the audio input or output to the connector/speaker of your choice (over-riding the vat settings). There might have been a similar program on the SS10 version of 4.1.3, but I don't have a version around to check for sure. Don ----- Begin Included Message ----- >From rem-conf-request@es.net Mon Oct 18 15:51:49 1993 Date: Mon, 18 Oct 93 17:11:49 -0400 From: bianchi@bellcore.com (Michael H Bianchi) To: rem-conf@es.net Subject: Sparc10 audio box Content-Length: 393 X-Lines: 8 The Sparc 10 audio box has separate inputs for microphone level and line-level, and separate outputs at headphone-level and line-level. Is there a version of sd/vat that understands the ioctl protocol for switching between these various inputs? Using the line-level input and output would make sense for mbone telecasts. Mike Bianchi (201) 829-5055 bianchi@bellcore.com ----- End Included Message ----- From rem-conf-request@es.net Mon Oct 18 19:55:50 1993 Received: from rx7.ee.lbl.gov by osi-east.es.net via ESnet SMTP service id <14460-0@osi-east.es.net>; Mon, 18 Oct 1993 16:44:45 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA00964; Mon, 18 Oct 93 16:45:16 -0700 Message-Id: <9310182345.AA00964@rx7.ee.lbl.gov> To: bianchi@bellcore.com (Michael H Bianchi) Cc: rem-conf@es.net Subject: Re: Sparc10 audio box In-Reply-To: Your message of Mon, 18 Oct 93 17:11:49 EDT. Date: Mon, 18 Oct 93 16:45:16 PDT From: Van Jacobson There'll be a new version of vat (2.17) out in the next day or so that knows about all the input & outputs on an SS-10 & can switch between them. - Van From rem-conf-request@es.net Mon Oct 18 19:58:03 1993 Received: from talisman.kaleida.com by osi-east.es.net via ESnet SMTP service id <14466-0@osi-east.es.net>; Mon, 18 Oct 1993 16:44:53 +0000 Received: from [130.43.11.117] (arodriguez.kaleida.com) by kaleida.com (4.1/Spike-2.1-(Kaleida)) id AA09486; Mon, 18 Oct 93 16:43:53 PDT Date: Mon, 18 Oct 93 16:43:53 PDT Message-Id: <9310182343.AA09486@kaleida.com> X-Sender: aar@talisman.kaleida.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: aar@kaleida.com (Arturo A. Rodriguez) Subject: Final Program - High-Speed Networking and Multimedia Computing High-Speed Networking and Multimedia Computing Part of IS&T/SPIE Symposium on Electronic Imaging: Science & Technology San Jose Convention Center, San Jose, California, February 6-10, 1994 In Cooperation with the IEEE Computer Society Task Force on Multimedia Computing Conference Chairs: Arturo A. Rodriguez, Kaleida Labs Mon-Song Chen, IBM T. J. Watson Research Center Jacek Maitan, Univ. of North Carolina at Charlotte Program Committee: Robert Boorstyn, Polytechnic University Jerome R. Cox, Jr., Washington University Edward A. Fox, Virginia Tech Arif Ghafoor, Purdue University Gita Gopal, Bellcore Madan Gopal, IBM T. J. Watson Research Center Ping-Kang Hsiung, Entertainment Research & Applications Dilip Kandlur, IBM T. J. Watson Research Center Shay Kutten, IBM T. J. Watson Research Center Michael Lesk, Bellcore Ken Morse, Kaleida Labs Seong Ki Mun, Georgetown University P. Venkat Rangan, University of California, San Diego Lawrence A. Rowe, University of California, Berkeley Gerri Sinclair, Simon Fraser University Anujan M. Varma, University of California, Santa Cruz Steven B. Weinstein, Bellcore WEDNESDAY 9 FEBRUARY User Interfaces and Multimedia Software Architectures Session Chair: Edward A. Fox, Virginia Tech 8:05 Human interface to large multimedia databases, B. Davis, MIT Media Labs, L Marks, D Collins, R Mack, & P Malkin, IBM Watson Research 8:30 Interactive video processing: software architecture issues, Simon J. Gibbs, Univ. of Geneva (Switzerland) 8:55 Digital video architecture for OS/2 2.1, John E. Parsons, IBM Corp. 9:20 Creation and presentation of continuous multimedia streams on PC, S. Jordanoski and Danco Davcev, St Kiril & Metodij Univ. (Macedonia) 9:45 COFFEE Multimedia Computing and Applications Session Chair: P. Venkat Rangan, Univ. of California, San Diego 10:10 Fast software dithering of 24 to 8 or 1 bit video, J. Kay, T. Nguyen, and J. Pasquale, Univ. of California/San Diego 10:35 Software-only video decompression into arbitrary shapes Roger Wilson, Acorn Computers (UK) 11:00 Digital video delivery for a digital library in computer science, Edward A. Fox, Virginia Tech 11:25 Construction of a multimedia application on public network, J. Liu, C-H Wang, Y-M Tseng, S-L Hsiao and F-Y Hung Ministry of Transportation and Communications (Taiwan) 11:50 Dial-up remote access image database, C-D Ho, S-M Lee, P-K Liao, M-H Tsai, W-S Shiehm h-R Chang and R-H Ju Ministry of Transportation and Communications (Taiwan) 12:15-2:00 LUNCH Multimedia Conferencing Session Chair: Mon-Song Chen, IBM T. J. Watson Research Center 2:00 Statistical Real-Time Video Channels over a Multi-access Network K G Shin and C-C Chou, Univ. of Michigan 2:25 An active multimedia system for delayed conferencing, T. Y. Hou, A Hsu, M Chiu, Siemens Research, S.K. Chang, H U Chang, Univ. of Pittsburgh 2:50 Personal telepresence--an interactive multimedia workstation, M. Pihlman and R. Farrell, Lawrence Livermore Lab D, Sauerhaft, Compression Labs, Inc. 3:15 Network support for a multimedia conference scheduling service, Yee-Hsiang Chang, Hewlett-Packard Labs 3:40 COFFEE II Transmission Methods and Techniques Session Chair: Lawrence A. Rowe, UC Berkeley 4:05 Schemes for efficient transmission of encoded video streams on high-speed networks, S. Ramanathan, H M Vin and P Venkat Rangan, UC/San Diego 4:30 MPEG video in software: representation, transmission and playback, L. A. Rowe, K. Patel, B. C. Smith, K. Liu, UC/Berkeley 4:55 Error concealment strategy for picture-header loss in MPEG compressed video, Huifang Sun and Joel Zdepski, David Sarnoff Research Ctr. 5:20 Rate control for VBR MPEG video on local area networks, D Reininger and W. Kwok, David Sarnoff Res., and A. Guha, MIT THURSDAY 10 FEBRUARY Multimedia Servers and Media Scheduling Session Chair: Dilip D. Kandlur, IBM Watson Research Ctr 8:05 Design of a Multimedia Storage Server D. Kandlur, Mon-Song Chen, & Zon-Yin Shae, IBM Watson Research 8:30 Multimedia server for on-demand services, H. Fujii, A. Ishikawa, N. Kotani, N. Sakurai NTT Network Information Systems Lab. (Japan) 8:55 GRAMS--a multimedia service system, Joseph Hui, D Reinninger, J Zhang, Rutgers Univ. 9:20 Storage subsystem in a large multimedia server for high-speed network environment, C-S Shih, J. K Dey, M Kumar, IBM TJ Watson Research Ctr. 9:45 Disk scheduling for multimedia data streams, S Daigle (Bellcore) and J. K. Strosnider (Carnegie Mellon U.) 10:10-10:40 COFFEE Perceptual Issues and Medical Video Transmission Session Chair: Jerome R. Cox Jr., Washington University 10:40 Distributed multimedia: user perception and dynamic QoS, R.T. Apteker, J. Fisher, V. S. Kisimov and H Neishlos, Univ. of the Witwatersrand (South Africa) 11:05 Role of standard compressed video teleconference codecs in the transmission of medical image data, M A. Wondrow, B Gilbert, B. K. Khandheria, M P Mitchell, and P J Wegwerth, Mayo Foundation 11:30 Considerations in the transmission and storage of JPEG-encoded medical video, N. R. Gohel, G. J Blaine, J R Cox Jr, and D. R. Fuhrmann Washington University 11:55-1:30 LUNCH Transport Systems and Protocols Session Chair: Jacek Maitan, University of North Carolina/Charlotte 1:30 The BERKOM multimedia transport system, S Boecking, Siemens Muenchen (FRG), S Damaskos, GMD Fokus (FRG), L Delgrossi IBM ENC Heidelberg (FRG), A Fartmann SNI (FRG), R Hammeschmidt DeTeBerkom (FRG), G Hoelzing, DEC CEC (FRG), I Milouscheva Technische Univ. Berlin (FRG), J Sandvoss, IBM ENC Heidelberg (FRG 1:55 Connection oriented protocols over ATM: a case study, S. Damaskos and A. Gavras, German National Research Corp. for Mathematics and Data Processing (FRG) 2:20 Analysis of 100Base-VG demand priority protocol: effects on real-time communications, J. Kadambi, AT&T Bell Labs, and S. Barilovits, MultiMedia Lans, Inc. 2:45 Lossless digital image browsing in high speed networks, C. Parris and H Zhang, Univ. of California/Berkeley 3:10-3:40 COFFEE Multimedia Data Manipulation and Hardware Architectures Session Chair: Ken Morse, Kaleida Labs 3:40 Trends in hardware acceleration for digital video on personal computers K. Morse and Arturo A. Rodriguez, Kaleida Labs 4:05 Storage, retrieval, and edit of digital video using MJPEG, S.I. Sudharsanan (DEC), and D. H. Lee, IBM Watson Research, 4:30 Digital video on personal systems - implementation and performance, Limin Hu, IBM Almaden Research Ctr. 4:55 Low-cost multi-window display memory for full-motion video signals, Alfons A.J. de Lange, Philips Research Labs. (Netherlands) 5:20 Introducing video communication and presentation to desktop computers, M. Jager and U Osterfeld, Fraunhofer Institute for Computer Graphic Poster Session and Demonstrations (Tuesday 5:30 to 7:00 PM) Demonstrations by various authors will accompany the Poster Session. ScriptX Technology (Presentation only) John B. Wainwright, Kaleida Labs Semidynamic and dynamic transmission algorithms for multiplexing voice with data, Y. Rozenbaum, P. Papantoni-Kasakos, D. Kazakos, Univ. of Virginia Multi-media chatting system on LAN, C-S Lung, H-C Huang, C-C Wang, C-L Lee, S-M Lee Ministry of Transportation and Communications (Taiwan) Fault-tolerant layered approach to fiber optic networks, H. Abu-Amara, S. Dolev, A. Kanevsky, J L Welch, Texas A&M Univ. Bilevel document archiving system, using JBIG, A. Bakalidis, A. Tsompanopoulus, and C. Chamzas, Democritus Univ. of Thrace (Greece) Displaying digital video over Ethernet TCP-IP, Paul Jackson and John Foster, Prairie View A&M Univ. Hyperspace storage compression for multimedia systems, Klaus Holtz, Omni Dimensional Networks, and A. Lettieri, Applied Autosophy Different approaches to implement application software using images, C. Metaxaki-Kossionides, Univ. of Athens (Greece) For more information, please contact: Jane Lybecker, SPIE, P O Box 10, Bellingham, WA 98227-0010 phone: (206) 676-3290, e-mail: janel@mom.spie.org From rem-conf-request@es.net Tue Oct 19 09:12:10 1993 Received: from talisman.kaleida.com by osi-east.es.net via ESnet SMTP service id <14465-0@osi-east.es.net>; Mon, 18 Oct 1993 16:44:53 +0000 Received: from [130.43.11.117] (arodriguez.kaleida.com) by kaleida.com (4.1/Spike-2.1-(Kaleida)) id AA09473; Mon, 18 Oct 93 16:43:34 PDT Date: Mon, 18 Oct 93 16:43:34 PDT Message-Id: <9310182343.AA09473@kaleida.com> X-Sender: aar@talisman.kaleida.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: aar@kaleida.com (Arturo A. Rodriguez) Subject: Final Program - Digital Video Compression on Personal Computers DIGITAL VIDEO COMPRESSION ON PERSONAL COMPUTERS: ALGORITHMS AND TECHNOLOGIES Part of IS&T/SPIE Symposium on Electronic Imaging: Science & Technology San Jose Convention Center, San Jose, California, February 6-10, 1994 In Cooperation with the IEEE Computer Society Task Force on Multimedia Computing Conference Chair: Arturo A. Rodriguez, Kaleida Labs Program Committee: Walter Bender, MIT Media Lab Alan C. Bovik, University of Texas Jerome R. Cox, Jr., Washington University Edward J. Delp, Purdue University Paul Farrelle, Optivision Edward A. Fox, Virginia Tech Ehud D. Karnin, IBM Haifa Scientific Center Ken Morse, Kaleida Labs James O. Normile, Apple Computer P. Venkat Rangan, University of California, San Diego K. R. Rao, University of Texas at Arlington Lawrence A. Rowe, University of California, Berkeley Arthur J. Stein, IBM Watson Research Center Eric Viscito, IBM Watson Research Center MONDAY 7 FEBRUARY Hardware Implementations Session Chair: Ken Morse, Kaleida Labs 8:30 Design of a Motion JPEG Adapter Card D.H. Lee, IBM Watson Research and S. Sudharsanan, DEC 8:55 JPEG image compression hardware implementation with extensions for fixed-rate and compressed image editing applications, M. P. Boliek and D. W. Bednash, RICOH California Research Ctr. T. Ryu and Y. Sato, Ricoh Co., Ltd (Japan) 9:20 ASIC implementation of recursive scaled discrete cosine transform algorithm, B N. On and S Narasimhan, National Univ. of Singapore 9:45 Real-time MPEG Video Codec on a Single-chip Multiprocessor W. Lee and Yongmin Kim, Univ. of Washington 10:10-10:40 COFFEE Scene Change Detection and Video Testing Session Chair: Arthur J. Stein, IBM Watson Research 10:40 Video scene decomposition with the motion picture parser, T.D.C. Little and D Venkatash, Boston Univ. 11:05 Method for extracting camera operations to describe sub-scenes in video sequences, J. Maeda, IBM Tokyo Research Lab 11:30 Computer-based testing of digital video quality, C.P. Cressy and G. W. Beakley, StellaCom, Inc. 11:55-1:30 LUNCH Video Coding Methods and Techniques I Session Chair: K. R. Rao, Univ. of Texas/Arlington 1:30 Modulated lapped transforms in image coding, R. L. de Queiroz and K. R. Rao, Univ. of Texas/Arlington 1:55 Hybrid DCT/quadtree-segmentation coding of video sequences, Sam Liu, Hewlet-Packard Labs and F-M Wang, C-Cube 2:20 Rate and resolution scalable 3-D subband coding of video, D. Taubman and A. Zakhor, Univ. of California/Berkeley 2:45 Applying mid-level vision techniques for video data compression and manipulation, J. Y. A. Wang and E. H. Adelson, MIT Media Lab 3:10-3:40 COFFEE Video Coding for Software-only Playback Session Chair: Arturo A. Rodriguez, Kaleida Labs 3:40 The feasibility of video codec algorithms for software-only playback, A. A. Rodriguez and K. Morse, Kaleida Labs 4:05 High-performance video codec for CD-ROM based video playback, K Wang, J. Normile & H J Wu, Apple Computer 4:30 Computationally fast wavelet-based video coding scheme, A Sengupta, M. Hilton, and B. Jawerth, Univ. of South Carolina 4:55 Software codec for personal computers based on the discrete cosine transform, C Pitts, J M Beaumont, N A Emms, & D J Myers, BT Labs (UK) 5:20 Using 4x4 DCTs and moving 4x4 blocks for software-only video decompression Roger Wilson, Acorn Computers Ltd. (UK) TUESDAY 8 FEBRUARY Video Coding Methods and Techniques II Session Chair: Edward J. Delp, Purdue University 8:05 Motion compensated visual pattern image sequence coding, A.C. Bovik and B. Barnett, Univ. of Texas/Austin 8:30 HDCC--a software based compression algorithm for video conferencing, H Moreton, Silicon Graphics Computer Systems 8:55 Statistical inverse discrete cosine transforms for image compression, Andy C. Hung and Teresa H.-Y Meng, Stanford Univ. 9:20 Video Coding by DCT Coefficient Compenstation H Yamaguchi, Texas Instruments Inc., Tsukuba R&D Ctr. (Japan) 9:45 COFFEE I MPEG Implementations Session Chair: Eric Viscito, IBM T. J. Watson Research 10:10 Fast motion estimation algorithm for an MPEG video coder, E Chan, R Ghandi, & S Panchanathan, Univ. of Ottawa (Canada) 10:35 Parallel Implementation of MPEG-II Video Encoding Using Socket Programming in LAN, Yanbin Yu and D. Anastassiou, Columbia University 11:00 MPEG on the PC: software only and hardware accelerated implementations, T. P. Chen and C. Eddy, Xing Technology Corp. 11:25 High-performance cross-platform MPEG CODEC, H. Bheda and P. Srinivasan, Mediamatics Inc. 11:50 ISO/IEC software implementation of MPEG-1 video, Chad Fogg, Cascade Design Automation 12:15-2:00 LUNCH MPEG Standards Session Chair: Arturo A. Rodriguez, Kaleida Labs 2:00 Invited Speaker: Didier J. LeGall,C-Cube Overview of MPEG-1 and MPEG-2 Video, 2:50 Invited Speaker: Davis Y. Pan, DEC Overview of the MPEG/audio compression algorithm, 3:15 Invited Speaker: A. G. MaCinnis, Kaleida Labs, Inc MPEG-2 Systems 3:40 COFFEE II Low Bit Rate Coding Session Chair: James O. Normile, Apple Computer 4:05 Status of ITU and ISO/MPEG 4 Coding Standards at Very Low Bit Rates, R Schaphorst, Delta Information Sys., & C Reader, Reader Inc. 4:30 Optimized hybrid transfrom coding for very low bitrate: videotelephony communication on PC G. Eude and J C Scmitt, CNET (France) 4:55 Transform Coding for Low Bitrate Applications, D Ponceleon, K Wang, H-J Wu, J Normile, Apple Computer 5:20 Video coding with wavelet transform on the very low bit rate communication channel, S-W Kim and H-K Lee, Korea Advanced Institute of Science and Tech. Poster Session and Demonstrations (Tuesday 5:30 to 7:00 PM) Demonstrations by various authors will accompany the Poster Presentations. Parallel butterfly algorithm and VLSI architecture for image compression, T. Acharya and A. Mukherjee, Univ. of Central Florida Motion estimation optimization in a MPEG 1 like video coding scheme for low bitrate applications, M.l Roser and P. Villegas, Telefonica I+D (Spain) Graphic primitive based software decodable video, R. Gonzalez and A. Ginige, Univ. of Technology (Australia) Video encoding using global block matching, G. K. Arakaki, Recruit Co., Ltd. (Japan) For more information, please contact: Jane Lybecker, SPIE, P O Box 10, Bellingham, WA 98227-0010 phone: (206) 676-3290, e-mail: janel@mom.spie.org From rem-conf-request@es.net Tue Oct 19 13:00:21 1993 Received: from sled.gsfc.nasa.gov by osi-east.es.net via ESnet SMTP service id <13766-0@osi-east.es.net>; Wed, 13 Oct 1993 08:25:07 +0000 Received: by sled.gsfc.nasa.gov (4.1/1.35) id AA08716; Wed, 13 Oct 93 11:24:55 EDT From: rogers@sled.gsfc.nasa.gov (Scott W. Rogers) Message-Id: <9310131524.AA08716@sled.gsfc.nasa.gov> Subject: Re: NASA Select Broadcast To: kevin@cc.gatech.edu (Kevin C. Almeroth) Date: Wed, 13 Oct 1993 11:24:54 -0400 (EDT) Cc: rem-conf@es.net, mbone@isi.edu In-Reply-To: <199310131408.AA00347@alps.cc.gatech.edu> from "Kevin C. Almeroth" at Oct 13, 93 10:08:05 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 29601 > From kevin@cc.gatech.edu Wed Oct 13 10:08:18 1993 > Date: Wed, 13 Oct 1993 10:08:05 -0400 > From: "Kevin C. Almeroth" > Message-Id: <199310131408.AA00347@alps.cc.gatech.edu> > To: rogers@gocart.gsfc.nasa.gov > Subject: NASA Select Broadcast > Cc: kevin@cc.gatech.edu > Could you please provide some information on how you are sending > the NASA Select broadcast? For example, where are you getting > the video and audio sources. > You might even want to send this to the mailing list. > Thanks > Kevin Almeroth (kevin@cc.gatech.edu) | Telecommunications Systems Group > College of Computing | Georgia Institute of Technology OK, here it is, there is nothing magic about it... I work at NASA'S Goddard Space Flight Center (GSFC). The TeleCommunications branch provides a form of cable TV for the center. Channel 12 is NASA select. I had a cable drop installed in my office and I brought in my old VCR. The VCR is connected to the cable and to a SUN SPARCstation IPC with a VideoPix card. The IPC is running SunOS 4.1.3 (Solaris 1.1) with a multicasting kernal. The Mono output from the VCR is fed through a reverse Y adapter into a MacIntosh Stero RCA to Mini-plug and into the IPC's audio input. The video outfput from the VCR goes into the VideoPix card. The software in NV (3.2) and VAT (v2.14beta) , + + + + + + + + + + Several (US) cable companies carry NASA Select. C-SPAN usually carries NASA Select during launches. NASA Select is also available (free) via sattelite. Many Universities etc. use local equipment to receive the signal and (legally) rebroadcast it locally through the campus cable TV. This is basically what GSFC is doing. Below is a blurb put out by NASA through it's public affairs office (PAO). It describes a little bit about the sattelite transmission and includes the NASA Select planned coverage during the next two weeks for the mission (STS-58). + + + + + + + + + + If anyone objects to the transmissions, please let me know. I've been trying to turn it off during periods of inactivity to save bandwith and turning it back on when there is a mission briefing, status update, or show. Scott W. Rogers +1 301-286-1377 / Fax: +1 301-286-1777 + + + + + + + + + + Subj: STS-58 TV SKED *********************************************************************** NASA SELECT TV SCHEDULE STS-58/SLS-2 10/12/93 *********************************************************************** NASA Select programming can be accessed through GE Satcom F2R, transponder 13. The frequency is 3960 MHz with an orbital position of 72 degrees West Longitude. This is a full transponder service and will be operational 24 hours a day. Two hour edited programs of each flight day will be replayed for Hawaii and Alaska on Galaxy 6, transponder 18, channel 18. The orbital position is 99 degrees West Longitude, with a frequency of 4060 MHz. Audio is 6.2 and 6.8 MHz. The programs will begin on launch day and continue through landing, airing at 11pm Central Time. This NASA Select television schedule of mission coverage is available on Comstore, the mission TV schedule computer bulletin board service. Call 713-483-5817, and follow the prompts to access this service. ------------------------ Tuesday, October 12 -------------------------- L -2 Days SUBJECT SITE CDT ------- ---- --- COUNTDOWN STATUS BRIEFING KSC 08:00 AM ----------------------- Wednesday, October 13 ------------------------- L -1 Day COUNTDOWN STATUS BRIEFING KSC 07:00 AM SCIENCE OVERVIEW KSC 08:30 AM PRE-LAUNCH PRESS CONFERENCE KSC 10:00 AM ----------------------- Thursday, October 14 -------------------------- FD 1 ORBIT SUBJECT SITE MET CDT ----- ------- ---- --- --- NASA SELECT MISSION KSC 05:00 AM COVERAGE BEGINS LAUNCH KSC 00/00:00 09:53 AM NASA SELECT ORIGINATION JSC 00/00:04 09:57 AM SWITCHED TO JSC MECO 00/00:08 10:01 AM 1 NASA SELECT ORIGINATION KSC 00/00:13 10:06 AM SWITCHED TO KSC 1 LAUNCH REPLAYS KSC 00/00:13 10:06 AM (APPROX. 5 MINUTES AFTER MECO) T=30:00 1 NASA SELECT ORIGINATION JSC 00/00:43 10:36 AM SWITCHED TO JSC 1 NASA SELECT ORIGINATION KSC 00/01:07 11:00 AM SWITCHED TO KSC 1 POST LAUNCH PRESS CONFERENCE KSC 00/01:07 11:00 AM 2 NASA SELECT ORIGINATION JSC 00/01:37 11:30 AM SWITCHED TO JSC 2 SPACELAB ACTIVATION 00/02:25 12:18 PM (not televised) 2 Ku BAND ANTENNA DEPLOY 00/02:30 12:23 PM (not televised) 3 SPACELAB ACTIVITIES TDRW/E 00/03:02 12:55 PM T=52:00 3 MISSION UPDATE JSC 00/03:07 01:00 PM 3 SPACELAB ACTIVITIES TDRW/E 00/04:00 01:53 PM T=51:00 4 SPACELAB ACTIVITIES TDRE 00/04:52 02:45 PM T=18:00 4 SPACELAB ACTIVITIES TDRW 00/05:38 03:31 PM T=22:00 5 NASA SELECT ORIGINATION KSC 00/06:07 04:00 PM SWITCHED TO KSC 5 ENGINEERING LAUNCH REPLAYS KSC 00/06:07 04:00 PM T=30:00 5 NASA SELECT ORIGINATION JSC 00/06:37 04:30 PM SWITCH TO JSC 6 SPACELAB ACTIVITIES TDRW 00/07:28 05:21 PM T=4:00 6 SPACELAB ACTIVITIES TDRE 00/07:42 05:35 PM T=18:00 7 FD1 HIGHLIGHTS JSC 00/10:07 08:00 PM 8 CREW SLEEP 00/11:00 08:53 PM 9 REPLAY OF FD1 HIGHLIGHTS JSC 00/12:07 10:00 PM ------------------------ Friday, October 15 --------------------------- FD 2 11 REPLAY OF FD1 HIGHLIGHTS JSC 00/15:07 01:00 AM 13 CREW WAKE UP 00/19:00 04:53 AM 17 SPACELAB ACTIVITIES TDRW/E 00/23:56 09:49 AM T=29:00 17 MISSION UPDATE JSC 00/23:37 09:30 AM 17 SPACELAB ACTIVITIES TDRW/E 01/00:53 10:46 AM T=52:00 18 SPACELAB ACTIVITIES TDRE 01/01:46 11:39 AM T=35:00 18 SPACELAB ACTIVITIES TDRW 01/02:28 12:21 PM T=12:00 19 SPACELAB ACTIVITIES TDRW 01/02:59 12:52 PM T=4:00 19 SPACELAB ACTIVITIES TDRE 01/03:51 01:44 PM T=6:00 19 SPACELAB ACTIVITIES TDRW 01/04:03 01:56 PM T=22:00 20 MISSION STATUS BRIEFING JSC 01/04:37 02:30 PM MSFC 20 SPACELAB ACTIVITIES TDRE 01/05:01 02:54 PM T=29:00 21 VIDEO UPDATE JSC 01/06:07 04:00 PM 22 SPACELAB ACTIVITIES TDRW 01/07:32 05:25 PM T=10:00 22 SPACELAB ACTIVITIES TDRE 01/07:54 05:47 PM T=34:00 23 FD2 HIGHLIGHTS JSC 01/10:07 08:00 PM 24 CREW SLEEP 01/11:00 08:53 PM 25 REPLAY OF FD2 HIGHLIGHTS JSC 01/12:07 10:00 PM ----------------------- Saturday, October 16 -------------------------- FD 3 26 REPLAY OF FD2 JSC 01/14:07 12:00 AM MISSION STATUS BRIEFING 27 REPLAY OF FD2 HIGHLIGHTS JSC 01/16:07 02:00 AM 29 CREW WAKE UP 01/19:00 04:53 AM 32 MISSION UPDATE JSC 01/23:37 09:30 AM 33 SPACELAB ACTIVITIES TDRW/E 02/01:09 11:02 AM T=31:00 34 SPACELAB ACTIVITIES TDRE 02/01:43 11:36 AM T=17:00 35 SPACELAB ACTIVITIES TDRE 02/03:39 01:32 PM T=21:00 35 SPACELAB ACTIVITIES TDRW/E 02/04:06 01:59 PM T=81:00 36 MISSION STATUS BRIEFING JSC 02/04:37 02:30 PM MSFC 37 VIDEO UPDATE JSC 02/06:07 04:00 PM 37 SPACELAB ACTIVITIES TDRE 02/06:37 04:30 PM T=30:00 38 SPACELAB ACTIVITIES TDRW 02/07:39 05:32 PM T=23:00 39 FD3 HIGHLIGHTS JSC 02/10:07 08:00 PM 40 CREW SLEEP 02/11:00 08:53 PM 41 REPLAY OF FD3 HIGHLIGHTS JSC 02/12:07 10:00 PM ----------------------- Sunday, October 17 ---------------------------- FD 4 42 REPLAY OF FD3 JSC 02/14:07 12:00 AM MISSION STATUS BRIEFING 43 REPLAY OF FD3 HIGHLIGHTS JSC 02/16:07 02:00 AM 45 CREW WAKE UP 02/19:00 04:53 AM 48 SPACELAB ACTIVITIES TDRE 02/23:01 08:54 AM T=8:00 48 SPACELAB ACTIVITIES TDRW/E 02/23:23 09:16 AM T=52:00 48 MISSION UPDATE JSC 02/23:37 09:30 AM 49 SPACELAB ACTIVITIES TDRE 03/00:16 10:09 AM T=35:00 49 SPACELAB ACTIVITIES TDRW 03/00:58 10:51 AM T=37:00 50 SPACELAB ACTIVITIES TDRW/E 03/01:37 11:30 AM T=6:00 52 SPACELAB ACTIVITIES TDRW/E 03/04:32 02:25 PM T=43:00 52 MISSION STATUS BRIEFING JSC 03/04:37 02:30 PM MSFC 53 VIDEO UPDATE JSC 03/06:07 04:00 PM 53 SPACELAB ACTIVITIES TDRE 03/06:21 04:14 PM T=51:00 54 SPACELAB ACTIVITIES TDRW 03/07:43 05:36 PM T=7:00 55 FD4 HIGHLIGHTS JSC 03/10:07 08:00 PM 56 CREW SLEEP 03/11:00 08:53 PM 57 REPLAY OF FD4 HIGHLIGHTS JSC 03/12:07 10:00 PM ------------------------ Monday, October 18 --------------------------- FD 5 58 REPLAY OF FD4 JSC 03/14:07 12:00 AM MISSION STATUS BRIEFING 59 REPLAY OF FD4 HIGHLIGHTS JSC 03/16:07 02:00 AM 61 CREW WAKE UP 03/19:00 04:53 AM 64 MISSION UPDATE JSC 03/23:37 09:30 AM 67 SPACELAB ACTIVITIES TDRW 04/03:10 01:03 PM T=16:00 67 SPACELAB ACTIVITIES TDRE 04/03:27 01:20 PM T=3:00 67 SPACELAB ACTIVITIES TDRE 04/03:40 01:33 PM T=20:00 67 SPACELAB ACTIVITIES TDRW 04/04:10 02:03 PM T=15:00 68 SPACELAB ACTIVITIES TDRW 04/04:27 02:20 PM T=3:00 68 MISSION STATUS BRIEFING JSC 04/04:37 02:30 PM MSFC 68 SPACELAB ACTIVITIES TDRE 04/04:55 02:48 PM T=45:00 68 SPACELAB ACTIVITIES TDRW 04/05:52 03:45 PM T=23:00 69 VIDEO UPDATE JSC 04/06:07 04:00 PM 71 FD5 HIGHLIGHTS JSC 04/10:07 08:00 PM 71 CREW SLEEP 04/10:15 08:08 PM 73 REPLAY OF FD5 HIGHLIGHTS JSC 04/12:07 10:00 PM ----------------------- Tuesday, October 19 --------------------------- FD 6 74 REPLAY OF FD5 JSC 04/14:07 12:00 AM MISSION STATUS BRIEFING 75 REPLAY OF FD5 HIGHLIGHTS JSC 04/16:07 02:00 AM 77 CREW WAKE UP 04/18:15 04:08 AM 80 MISSION UPDATE JSC 04/23:37 09:30 AM 81 SPACELAB ACTIVITIES TDRE 05/00:30 10:23 AM T=26:00 81 SPACELAB ACTIVITIES TDRW 05/01:02 10:55 AM T=50:00 82 SPACELAB ACTIVITIES TDRE 05/01:54 11:47 AM T=16:00 82 SPACELAB ACTIVITIES TDRE 05/02:40 12:33 PM T=13:00 82 P/TV05 MIDDECK ACTIVITIES TDRW 05/02:55 12:48 PM T=15:00 83 SPACELAB ACTIVITIES TDRW/E 05/03:10 01:03 PM T=56:00 83 SPACELAB ACTIVITIES TDRW 05/04:13 02:06 PM T=12:00 84 SPACELAB ACTIVITIES TDRW 05/04:30 02:23 PM T=10:00 84 MISSION STATUS BRIEFING JSC 05/04:37 02:30 PM MSFC 85 VIDEO UPDATE JSC 05/06:07 04:00 PM 87 FD6 HIGHLIGHTS JSC 05/10:07 08:00 PM 87 CREW SLEEP 05/10:15 08:08 PM 89 REPLAY OF FD6 HIGHLIGHTS JSC 05/12:07 10:00 PM ---------------------- Wednesday, October 20 -------------------------- FD 7 90 REPLAY OF FD6 JSC 05/14:07 12:00 AM MISSION STATUS BRIEFING 91 REPLAY OF FD6 HIGHLIGHTS JSC 05/16:07 02:00 AM 93 CREW WAKE UP 05/18:15 04:08 AM 95 SPACELAB ACTIVITIES TDRW 05/22:21 08:14 AM T=11:00 96 SPACELAB ACTIVITIES TDRE 05/23:11 09:04 AM T=11:00 96 SPACELAB ACTIVITIES TDRW 05/23:33 09:26 AM T=5:00 96 MISSION UPDATE JSC 05/23:37 09:30 AM 98 SPACELAB ACTIVITIES TDRW/E 06/02:39 12:32 PM T=86:00 100 SPACELAB ACTIVITIES TDRW 06/04:36 02:29 PM T=18:00 100 MISSION STATUS BRIEFING JSC 06/04:37 02:30 PM MSFC 100 SPACELAB ACTIVITIES TDRE 06/05:14 03:07 PM T=29:00 101 VIDEO UPDATE JSC 06/06:07 04:00 PM 101 SPACELAB ACTIVITIES TDRW/E 06/06:26 04:19 PM T=20:00 103 SPACELAB ACTIVITIES TDRW/E 06/09:44 07:37 PM T=45:00 103 FD7 HIGHLIGHTS JSC 06/10:07 08:00 PM 103 CREW SLEEP 06/10:15 08:08 PM 105 REPLAY OF FD7 HIGHLIGHTS JSC 06/12:07 10:00 PM ----------------------- Thursday, October 21 -------------------------- FD 8 106 REPLAY OF FD7 JSC 06/14:07 12:00 AM MISSION STATUS BRIEFING 107 REPLAY OF FD7 HIGHLIGHTS JSC 06/16:07 02:00 AM 109 CREW WAKE UP 06/18:15 04:08 AM 111 SPACELAB ACTIVITIES TDRE 06/21:30 07:23 AM T=12:00 112 SPACELAB ACTIVITIES TDRE 06/22:45 08:38 AM T=39:00 112 SPACELAB ACTIVITIES TDRW 06/23:31 09:24 AM T=20:00 112 MISSION UPDATE JSC 06/23:37 09:30 AM 112 SPACELAB ACTIVITIES TDRW/E 06/23:55 09:48 AM T=26:00 113 SPACELAB ACTIVITIES TDRE 07/00:26 10:19 AM T=12:00 114 SPACELAB ACTIVITIES TDRW 07/01:34 11:27 AM T=13:00 115 SPACELAB ACTIVITIES TDRW/E 07/03:06 12:59 PM T=26:00 115 SPACELAB ACTIVITIES TDRE 07/03:35 01:28 PM T=35:00 116 MISSION STATUS BRIEFING JSC 07/04:37 02:30 PM MSFC 117 VIDEO UPDATE JSC 07/06:07 04:00 PM 117 SPACELAB ACTIVITIES TDRW/E 07/06:14 04:07 PM T=33:00 119 SPACELAB ACTIVITIES TDRE 07/10:02 07:55 PM T=5:00 119 FD8 HIGHLIGHTS JSC 07/10:07 08:00 PM 120 CREW SLEEP 07/10:15 08:08 PM 121 REPLAY OF FD8 HIGHLIGHTS JSC 07/12:07 10:00 PM ------------------------ Friday, October 22 --------------------------- FD 9 122 REPLAY OF FD8 JSC 07/14:07 12:00 AM MISSION STATUS BRIEFING 123 REPLAY OF FD8 HIGHLIGHTS JSC 07/16:07 02:00 AM 125 CREW WAKE UP 07/18:15 04:08 AM 128 MISSION UPDATE JSC 07/23:37 09:30 AM 129 SPACELAB ACTIVITIES TDRW/E 08/00:07 10:00 AM T=16:00 131 SPACELAB ACTIVITIES TDRW 08/02:59 12:52 PM T=9:00 131 SPACELAB ACTIVITIES TDRW 08/03:10 01:03 PM T=5:00 131 P/TV06 FLIGHT DECK ACTIVITIES TDRE 08/03:15 01:08 PM T=10:00 131 SPACELAB ACTIVITIES TDRE 08/03:25 01:18 PM T=46:00 132 MISSION STATUS BRIEFING JSC 08/04:37 02:30 PM MSFC 132 SPACELAB ACTIVITIES TDRE 08/05:09 03:02 PM T=9:00 133 VIDEO UPDATE JSC 08/06:07 04:00 PM 135 FD9 HIGHLIGHTS JSC 08/10:07 08:00 PM 135 CREW SLEEP 08/10:15 08:08 PM 137 REPLAY OF FD9 HIGHLIGHTS JSC 08/12:07 10:00 PM ----------------------- Saturday, October 23 -------------------------- FD 10 138 REPLAY OF FD9 JSC 08/14:07 12:00 AM MISSION STATUS BRIEFING 139 REPLAY OF FD9 HIGHLIGHTS JSC 08/16:07 02:00 AM 141 CREW WAKE UP 08/18:15 04:08 AM 143 CREW PRESS CONFERENCE TDRE 08/21:15 07:08 AM JSC/KSC/MSFC 144 SPACELAB ACTIVITIES TDRW/E 08/22:38 08:31 AM T=12:00 144 SPACELAB ACTIVITIES TDRE 08/22:52 08:45 AM T=28:00 144 MISSION UPDATE JSC 08/23:37 09:30 AM 144 SPACELAB ACTIVITIES TDRW/E 08/23:48 09:41 AM T=22:00 145 P/TV05 MIDDECK ACTIVITIES TDRE 09/00:10 10:03 AM T=20:00 147 SPACELAB ACTIVITIES TDRW 09/03:04 12:57 PM T=9:00 147 SPACELAB ACTIVITIES TDRE 09/03:52 01:45 PM T=20:00 148 MISSION STATUS BRIEFING JSC 09/04:37 02:30 PM MSFC 148 SPACELAB ACTIVITIES TDRW/E 09/04:43 02:36 PM T=24:00 149 VIDEO UPDATE JSC 09/06:07 04:00 PM 151 FD10 HIGHLIGHTS JSC 09/10:07 08:00 PM 151 CREW SLEEP 09/10:15 08:08 PM 153 REPLAY OF FD10 HIGHLIGHTS JSC 09/12:07 10:00 PM ------------------------ Sunday, October 24 --------------------------- FD 11 154 REPLAY OF FD10 JSC 09/14:07 12:00 AM MISSION STATUS BRIEFING 155 REPLAY OF FD10 HIGHLIGHTS JSC 09/16:07 02:00 AM 157 CREW WAKE UP 09/18:15 04:08 AM 160 MISSION UPDATE JSC 09/23:37 09:30 AM 162 SPACELAB ACTIVITIES TDRE 10/02:11 12:04 PM T=20:00 163 SPACELAB ACTIVITIES TDRW/E 10/03:11 01:04 PM T=20:00 163 SPACELAB ACTIVITIES TDRE 10/04:00 01:53 PM T=14:00 164 MISSION STATUS BRIEFING JSC 10/04:37 02:30 PM MSFC 164 SPACELAB ACTIVITIES TDRW 10/04:42 02:35 PM T=26:00 164 SPACELAB ACTIVITIES TDRE 10/05:20 03:13 PM T=30:00 165 VIDEO UPDATE JSC 10/06:07 04:00 PM 167 CREW SLEEP 10/09:30 07:23 PM 167 FD11 HIGHLIGHTS JSC 10/10:07 08:00 PM 169 REPLAY OF FD11 HIGHLIGHTS JSC 10/12:07 10:00 PM ------------------------ Monday, October 25 --------------------------- FD 12 170 REPLAY OF FD11 JSC 10/14:07 12:00 AM MISSION STATUS BRIEFING 171 REPLAY OF FD11 HIGHLIGHTS JSC 10/16:07 02:00 AM 172 CREW WAKE UP 10/17:30 03:23 AM 175 SPACELAB ACTIVITIES TDRW/E 10/22:01 07:54 AM T=74:00 176 SPACELAB ACTIVITIES TDRE 10/23:20 09:13 AM T=9:00 176 SPACELAB ACTIVITIES TDRW 10/23:35 09:28 AM T=14:00 176 MISSION UPDATE JSC 10/23:37 09:30 AM 177 SPACELAB ACTIVITIES TDRW/E 11/00:04 09:57 AM T=46:00 178 SPACELAB ACTIVITIES TDRW 11/01:30 11:23 AM T=7:00 178 SPACELAB ACTIVITIES TDRE 11/01:58 11:51 AM T=41:00 179 SPACELAB ACTIVITIES TDRW/E 11/03:06 12:59 PM T=34:00 180 MISSION STATUS BRIEFING JSC 11/04:37 02:30 PM MSFC 180 SPACELAB ACTIVITIES TDRW/E 11/04:43 02:36 PM T=65:00 181 SPACELAB ACTIVITIES TDRW 11/06:03 03:56 PM T=3:00 181 VIDEO UPDATE JSC 11/06:07 04:00 PM 181 SPACELAB ACTIVITIES TDRW 11/06:22 04:15 PM T=9:00 182 SPACELAB ACTIVITIES TDRW/E 11/08:16 06:09 PM T=12:00 183 CREW SLEEP 11/09:30 07:23 PM 183 FD12 HIGHLIGHTS JSC 11/10:07 08:00 PM 185 REPLAY OF FD12 HIGHLIGHTS JSC 11/12:07 10:00 PM ----------------------- Tuesday, October 26 --------------------------- FD 13 186 REPLAY OF FD12 JSC 11/14:07 12:00 AM MISSION STATUS BRIEFING 187 REPLAY OF FD12 HIGHLIGHTS JSC 11/16:07 02:00 AM 188 CREW WAKE UP 11/17:30 03:23 AM 191 SPACELAB ACTIVITIES TDRW 11/22:04 07:57 AM T=16:00 191 P/TV06 FLIGHT DECK ACTIVITIES TDRW 11/22:20 08:13 AM T=10:00 192 SPACELAB ACTIVITIES TDRW/E 11/22:30 08:23 AM T=22:00 192 MISSION UPDATE JSC 11/23:37 09:30 AM 195 SPACELAB ACTIVITIES TDRW 12/03:19 01:12 PM T=4:00 196 MISSION STATUS BRIEFING JSC 12/04:37 02:30 PM MSFC 197 VIDEO UPDATE JSC 12/06:07 04:00 PM 199 CREW SLEEP 12/09:30 07:23 PM 199 FD13 HIGHLIGHTS JSC 12/10:07 08:00 PM 201 REPLAY OF FD13 HIGHLIGHTS JSC 12/12:07 10:00 PM ----------------------- Wednesday, October 27 ------------------------- FD 14 202 REPLAY OF FD13 JSC 12/14:07 12:00 AM MISSION STATUS BRIEFING 203 REPLAY OF FD13 HIGHLIGHTS JSC 12/16:07 02:00 AM 204 CREW WAKE UP 12/17:30 03:23 AM 206 SPACELAB ACTIVITIES TDRW/E 12/20:45 06:38 AM T=30:00 207 P/TV06 FLIGHT DECK ACTIVITIES TDRE 12/21:15 07:08 AM T=10:00 207 SPACELAB ACTIVITIES TDRE 12/21:25 07:18 AM T=30:00 207 SPACELAB ACTIVITIES TDRW/E 12/22:01 07:54 AM T=89:00 208 MISSION UPDATE JSC 12/23:37 09:30 AM 208 SPACELAB ACTIVITIES TDRW/E 12/23:41 09:34 AM T=64:00 210 SPACELAB ACTIVITIES TDRE 13/01:55 11:48 AM T=24:00 211 SPACELAB ACTIVITIES TDRE 13/03:30 01:23 PM T=46:00 212 MISSION STATUS BRIEFING JSC 13/04:37 02:30 PM MSFC 212 SPACELAB ACTIVITIES TDRW/E 13/04:44 02:37 PM T=16:00 212 SPACELAB DEACTIVATION 13/05:30 03:23 PM (not televised) 213 VIDEO UPDATE JSC 13/06:07 04:00 PM 215 CREW SLEEP 13/09:25 07:18 PM 215 FD14 HIGHLIGHTS JSC 13/10:07 08:00 PM 217 REPLAY OF FD14 HIGHLIGHTS JSC 13/12:07 10:00 PM ---------------------- Thursday, October 28 --------------------------- FD 15 218 REPLAY OF FD14 JSC 13/14:07 12:00 AM MISSION STATUS BRIEFING 219 REPLAY OF FD14 HIGHLIGHTS JSC 13/16:07 02:00 AM 220 CREW WAKE UP 13/16:25 02:18 AM 220 SPACELAB DEACTIVATION 13/18:05 03:58 AM (not televised) 222 Ku BAND ANTENNA STOW 13/19:25 05:18 AM (not televised) 224 DE-ORBIT BURN 13/23:29 09:22 AM (not televised) 225 EDWARDS LANDING DFRF 14/00:29 10:22 AM LANDING REPLAYS DFRF TBD POST LANDING PRESS CONFERENCE DFRF TBD *********************************************************************** DEFINITION OF TERMS *********************************************************************** CDT: Central Daytight Time (-0500 UTC) DFRF: Dryden Flight Research Facility, California FD: Flight Day JSC: Johnson Space Center KSC: Kennedy Space Center MECO: Main engine cut-off MET: Mission Elapsed Time. The time which begins at the moment of launch and is read: days/hours:minutes. Launch=00/00:00 P/TV: Photographic/Television activity SLS: Spacelab Life Sciences; STS-58 primary payload STS: Space Transportation System T=: Time equivalent; Used for duration of event. TBD: To be determined. TDRE,W: Tracking and Data Relay Satellite, East and West longitudes. VTR: Videotape recorder. -- -------------------------------------------------------------------------- Scott W. Rogers +1-301-286-1377 Computer Networking Branch --- Code 933 ---- Greenbelt, MD 20771 NASA Goddard Space Flight Center FAX: 301-286-1777 From rem-conf-request@es.net Tue Oct 19 18:30:26 1993 Received: from lhc.nlm.nih.gov by osi-east.es.net via ESnet SMTP service id <16758-0@osi-east.es.net>; Tue, 19 Oct 1993 15:23:31 +0000 Received: from billings.nlm.nih.gov by nlm.nih.gov (4.1/SMI-4.0) id AA26335; Tue, 19 Oct 93 18:23:25 EDT Received: by billings.nlm.nih.gov (4.1/SMI-4.1) id AA02381; Tue, 19 Oct 93 18:18:07 EDT Date: Tue, 19 Oct 93 18:18:07 EDT From: rodgers@nlm.nih.gov (R. P. Channing ["Rick"] Rodgers) Message-Id: <9310192218.AA02381@billings.nlm.nih.gov> To: mbone@isi.edu, rem-conf@es.net Subject: Would like to do audio/video multicast of SIGNIDR on 12 Nov. 93 Cc: casner@isi.edu Dear Colleagues, We would very much like to use MBONE to broadcast audio and video from the SIGNIDR III meeting which is to be held at the Lister Hill Center of the National Library of Medicine on Friday 12 November 1993, from 0900-1730 EST. Appended is the currently planned itinerary. There has apparently been some delay in adding me to the mbone list, so please get back in touch with me or my colleague Jules Aronson (aronson@nlm.nih.gov) by direct email if there are any problems/issues/questions (I will be unavailable 21-31 Oct.). Looking forward to being on the list... Cheerio, Rick Rodgers -------------------------------------------------------------------------------- ITINERARY FOR SIGWAIS/SIGNIDR III AT THE NLM (12 November 1993; Subject to Change) 9:00-9:30 R. P. C. Rodgers (Lister Hill Center, NLM) What this Meeting is About: An Introduction, Outline, and Acknowledgments 9:30-9:40 Questions and Discussion 9:40-10:10 Jim Fullton (CNIDR) A Network Distributed Image Database 10:10-10:20 Questions and Discussion 10:20-10:40 MORNING BREAK 10:40-11:10 Dan Masys (Lister Hill Center, NLM) Visualizing the Virtual Library: Technology Development in Progress at the National Library of Medicine 11:10-11:20 Questions and Discussion 11:20-11:50 Hardin/Andreesen (NCSA) NCSA Mosaic, Past, Present and Future 11:50-12:00 Questions and Discussion 12:00-13:30 LUNCH BREAK 13:30-14:00 D. A. B. Lindberg (NLM, HPCC) The Federal High Performance Computing and Communications (HPCC) Program 14:00-14:10 Questions and Discussion 14:10-14:40 Paul Jones (Univ. of North Carolina, Chapel Hill) Publishing Information Using Multiple Information Servers (Gopher, WAIS, World Wide Web) 14:40-14:50 Questions and Discussion 14:50-15:20 Eliot Christian (USGS) The Government Information Locator Service (GILS) 15:20-15:30 Questions and Discussion 15:30-15:40 AFTERNOON BREAK 15:40-16:10 Archie Warnock (NASA) Integrating Information Services for NASA 16:10-16:20 Questions and Discussion 16:20-16:50 Pushpendra Mohta (CERFnet) So How Do I Get Onto the Internet? 16:50-17:00 Questions and Discussion, Wrap-up -------------------------------------------------------------------------------- From rem-conf-request@es.net Tue Oct 19 19:27:56 1993 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <17750-0@osi-east.es.net>; Tue, 19 Oct 1993 16:27:12 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA08840; Tue, 19 Oct 93 16:27:11 PDT Date: Tue, 19 Oct 93 16:27:11 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9310192327.AA08840@viipuri.nersc.gov> To: rem-conf@es.net Subject: IP encapsulate routing for mrouted on ----- Begin Included Message ----- >From frank@manua.gsfc.nasa.gov Tue Oct 19 07:48:47 1993 Date: Tue, 19 Oct 93 10:49:07 -0400 From: frank@manua.gsfc.nasa.gov (Frank Chen) To: rem-conf-request@es.net ^^^^^^^^ Subject: IP encapsulate routing for mrouted on Content-Length: 1969 I recently got an Indy running IRIX 5.1.1. I am thinking to use this box to run mrouted for our Rib. Is this powerful enough? I only got 32MB RAM. I believe that the mrouted for IRIX 5.1.1 does not support IP encapsulate routing, right? Where can I get the patches? I was told that the patches in ftp.sgi.com are for IRIX 4.0.5. Also, is there any problem running wb 1.13(93/08/10), vat 1.12(93/07/06), ivs 3.2, sd 1.14, and nv 3.2? I can run '3rd MICE seminar' this morning on SGI Indigo running 4.0.5F. But when I ran it in Indy, The console just freeze when the whiteboard window is coming up(vat already up and I can hear the sound for a few seconds and a 'ps' shows 'ivs','wb', 'vat' are already started). I still can ping to Indy from another machine and login to Indy to run 'top' and found out that Xsgi is using 85% of CPU. However, this telnet session also freeze after several minutes and a 11 minutes ping after that shows 97% packets loss. Started another ping for about 7 minutes shows 100% packet loss. Anyone know which is at fault? Actually, whiteboard did not work fine on Indigo. It came up and I can see some pages. However, my terminal printout lots of messages complaint about postscript command. Thanks! -Frank Chen =============================================================================== | Chih-Hung Chen (Frank) | email: frank@manua.gsfc.nasa.gov| | General Sciences Corp.(SAIC) | fax : (301) 286-3221 | | Software Development - SeaWiFS Data System| voice: (301) 286-9531 | | System/Network SeaWiFS Project | | | NASA/Goddard Space Flight Center | | | Code 970.2 | | | Greenbelt, Maryland 20771 | | =============================================================================== ----- End Included Message ----- From rem-conf-request@es.net Tue Oct 19 21:08:31 1993 Received: from SGI.COM by osi-east.es.net via ESnet SMTP service id <22372-0@osi-east.es.net>; Tue, 19 Oct 1993 18:07:49 +0000 Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for rem-conf@es.net id AA22574; Tue, 19 Oct 93 18:07:42 -0700 Received: from xingping.esd.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgi.sgi.com:frank@manua.gsfc.nasa.gov id AA28024; Tue, 19 Oct 93 18:07:37 -0700 Received: by xingping.esd.sgi.com (930416.SGI/911001.SGI) for @relay.sgi.com:rem-conf@es.net id AA13853; Tue, 19 Oct 93 18:07:32 -0700 Date: Tue, 19 Oct 93 18:07:32 -0700 From: arc@xingping.esd.sgi.com (Andrew Cherenson) Message-Id: <9310200107.AA13853@xingping.esd.sgi.com> To: frank@manua.gsfc.nasa.gov, rem-conf@es.net Subject: Re: Indy/MBONE questions >From: frank@manua.gsfc.nasa.gov (Frank Chen) > I believe that the mrouted for IRIX 5.1.1 does not support IP encapsulate > routing, right? Nope, the mrouted that ships with Indy is the encapsulating version. > Where can I get the patches? I was told that the patches > in ftp.sgi.com are for IRIX 4.0.5. You do not need any patches for IRIX 5.1. > Also, is there any problem running wb 1.13(93/08/10), vat 1.12(93/07/06), > ivs 3.2, sd 1.14, and nv 3.2? I can run '3rd MICE seminar' this morning on > SGI Indigo running 4.0.5F. But when I ran it in Indy, The console just > freeze when the whiteboard window is coming up There's a bug in the 5.1 X server that's tickled by the current wb binary. As a workaround, before starting wb sessions, start "xpsview" and quit it once the window menus appear. ftp.sgi.com:/sgi/ipmcast/README.tools contains more information about MBONE tools on Indy. > Actually, whiteboard did not work fine > on Indigo. It came up and I can see some pages. However, my terminal > printout lots of messages complaint about postscript command. You probably need to install the Display PostScript software (dps_eoe). From rem-conf-request@es.net Wed Oct 20 11:43:34 1993 Received: from ncar.ucar.edu by osi-east.es.net via ESnet SMTP service id <26941-0@osi-east.es.net>; Wed, 20 Oct 1993 08:29:30 +0000 Received: from hao.ucar.edu by ncar.ucar.EDU (5.65/ NCAR Central Post Office 03/11/93) id AA19555; Wed, 20 Oct 93 09:29:26 MDT Received: from ozzel.hao.ucar.edu.hao by hao (4.1/SMI-4.1) id AA26095; Wed, 20 Oct 93 09:29:25 MDT Received: by ozzel.hao.ucar.edu.hao (4.1/SMI-4.1) id AA12259; Wed, 20 Oct 93 09:29:24 MDT Date: Wed, 20 Oct 93 09:29:24 MDT From: sitongia@ozzel.hao.ucar.edu (Leonard Sitongia) Message-Id: <9310201529.AA12259@ozzel.hao.ucar.edu.hao> To: rem-conf@es.net Subject: multicast of HPCC conference Would the list maintainer mail me the agenda for this multicast, please? Thanks, --Leonard E. Sitongia HAO Unix System Manager sitongia@ncar.ucar.edu voice: (303)497-1509 fax: (303)497-1589 High Altitude Observatory P.O. Box 3000 Boulder CO 80307 From rem-conf-request@es.net Wed Oct 20 12:48:47 1993 Received: from sics.se by osi-east.es.net via ESnet SMTP service id <27806-0@osi-east.es.net>; Wed, 20 Oct 1993 09:35:11 +0000 Received: from bugs.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA05270; Wed, 20 Oct 93 17:35:03 +0100 Message-Id: <9310201635.AA05270@sics.se> To: rem-conf@es.net Subject: Sun announces new multimedia products Date: Wed, 20 Oct 1993 17:35:01 +0100 From: Anders Klemets I apologize if you have already seen this announcement. Anders -------- From: flash@Sun.COM Newsgroups: cs.sun-users Subject: SunFlash: 58.19 SMCC Imaging and Multimedia Workstations Date: 20 Oct 1993 03:32:47 -0400 Organization: Columbia University Department of Computer Science NNTP-Posting-Host: cs.columbia.edu sunflash-Distributed to mailing list NY/columbia.edu/cs.columbia.edu sunflash-Send requests, problems to owner-sunflash@cs.columbia.edu ---------------------------------------------------------------------------- The Florida SunFlash SMCC Announces New Imaging and Multimedia Workstations SunFLASH Vol 58 #19 October 1993 ---------------------------------------------------------------------------- 58.19 SMCC Announces New Imaging and Multimedia Workstations - SPARCstation 10SX - SPARCstation 10M - SPARCclassic M - "multimedia bundle" New workstations bringing fully configured, high-end image processing and multimedia capabilities down to a new low price range. These new systems feature revolutionary imaging capabilities and the industry's lowest-cost real-time video capture/compression technology, both developed by SMCC. The multimedia package includes the SunVideo capture/compression card, video camera and multimedia CD-ROM disc. ---------------------------------------------------------------------------- Contact: Sun Microsystems Computer Corporation Robert Manetta (415) 336-0979 SMCC UNVEILS INDUSTRY-LEADING IMAGING AND MULTIMEDIA WORKSTATIONS Eastman Kodak, Adobe Support New Systems MOUNTAIN VIEW, Calif. -- October 19, 1993 -- Sun Microsystems Computer Corp. (SMCC) today introduced new workstations bringing fully configured, high-end image processing and multimedia capabilities down to a new low price range. These new systems feature revolutionary imaging capabilities and the industry's lowest-cost real-time video capture/compression technology, both developed by SMCC. Eastman Kodak Company and Adobe Systems, Inc., industry leaders in color and imaging technology, are showing their support for the new workstations with major sales and product integration programs. The new Sun(R) workstations include: - SPARCstation(TM) 10SX -- providing industry-leading image processing performance, full 24-bit color, 3-D graphics and hardware-accelerated video playback. - SPARCstation 10M -- offering all of the capabilities of the SPARCstation 10SX, plus real-time video capture/compression and a video camera. - SPARCclassic(TM) M -- at $4,995, the industry's most inexpensive, fully configured multimedia workstation. It includes a camera, real-time video capture/compression card -- enabling multimedia conferencing over standard networks -- and a storage disk. These workstations give new visual computing capabilities to users in a variety of application areas, including color pre-press, medical imaging, satellite imaging, geographic information systems, oil and gas exploration, low-end MCAD, animation, multimedia authoring and video conferencing. SPARCstation 10SX In the area of imaging, the SPARCstation 10SX delivers unmatched performance and capabilities among workstation platforms. "Imaging" means the ability to manipulate and process such images as digitized photographs, X rays and satellite data. This new system fills a huge gap between high-end personal computer-class systems --- which are severely hampered by slow performance -- and costly proprietary imaging systems costing upward of $60,000. Priced within range of a Macintosh imaging system, the SPARCstation 10SX delivers a level of performance better than many proprietary imaging systems. The SPARCstation 10SX is the first system in its class with a graphics and imaging ASIC integrated right into its memory subsystem that can manipulate images as large as 300 megabytes in almost real time. Common imaging functions -- panning, zooming and rotating -- as well as advanced special effects -- sharpening, blurring and edge detection -- are carried out extremely quickly due to the speed of the SX chip. In addition, SX is the only imaging accelerator that doesn't force data to pass over a relatively low-speed bus. The SPARCstation 10SX is a versatile workstation that, in addition to superior imaging, provides full 24-bit, Gouraud-shaded, Z-buffered graphics for interactive 3-D. It also provides fast decompressed video playback in hardware. All of these capabilities are carried out by the revolutionary ASIC. The SPARCstation 10SX, which is available immediately, has introductory pricing beginning at $15,495. The price includes a 535 megabyte hard disk, 32 megabytes of memory and a 16-inch color monitor. Multimedia Demands Compressed Video SMCC also introduced two workstations providing new levels of video conferencing and multimedia authoring functionality. They feature video capture and compression at 30 frames per second, making possible high-quality, full-frame video conferencing over a network. These systems are the SPARCstation 10M and the SPARCclassic M computers. "Without compression, video is useless because the images can't be sent and received without using up all of a network's bandwidth," said Jay Puri, vice president of product marketing at SMCC. "Other vendors' systems don't adequately address the issue of video compression at a low cost." SMCC's video conferencing workstations come equipped with the new SunVideo(TM) capture/compression SBus card, the first real-time video card that supports multiple video compression standards such as MPEG, JPEG and CELL, SMCC's internally developed algorithm. The multimedia workstations also include a video camera and a CD-ROM disc containing licensable video and multimedia programs. In addition, users can take advantage of Solaris LIVE!, an extensive array of multimedia technologies that support workgroup collaboration, video conferencing and more. Solaris LIVE! is part of the Solaris 2.3 operating environment. "We're especially proud of the SPARCclassic M because it offers video capabilities and price/performance that no other vendor -- in either the PC or workstation space -- can match," said Puri. "To come close to the SPARCclassic M configuration in terms of disk, video compression and other features, you'd have to pay at least 50 percent more." The SPARCstation 10M has introductory prices starting at $17,095, and the SPARCclassic M costs $4,995 for quantities of 12 or more. Both will be available beginning December 15. Nearly One Million Multimedia-Capable Workstations Also available is a "multimedia bundle" that can be used to equip any of the existing installed base of SPARCstation systems for multimedia. Among workstation vendors, only SMCC allows customers to protect their investments and retrofit existing systems for multimedia. Other vendors compel customers to purchase entire new systems to obtain these capabilities. Priced at $1,895, the multimedia package includes the SunVideo capture/compression card, video camera and multimedia CD-ROM disc. The SunVideo card can also be purchased alone for $1,495. Sun Microsystems Computer Corporation (SMCC), the world's leading supplier of open client-server computing solutions, is an operating company of Sun Microsystems, Inc. Sun is the exclusive computer supplier to World Cup Soccer 1994. SMCC has its headquarters in Mountain View, Calif. # # # Sun, the Sun logo, Sun Microsystems, XIL, Solaris and SunVideo are trademarks or registered trademarks of Sun Microsystems, Inc. All SPARC trademarks, including the SCD Compliant logo, are trademarks or registered trademarks of SPARC International, Inc. SPARCstation and SPARCclassic are licensed exclusively to Sun Microsystems, Inc. Products bearing SPARC trademarks are based on an architecture developed by Sun Microsystems, Inc. All other products are referred to herein by the trademarks as designated by the companies who market those products. For reader inquiries, telephone 1-800-821-4643. ********************************************************************** For information about SunFlash send mail to info-sunflash@Sun.COM. Subscription requests should be sent to sunflash-request@Sun.COM. Archives are on draco.nova.edu, ftp.uu.net, sunsite.unc.edu, src.doc.ic.ac.uk and ftp.adelaide.edu.au All prices, availability, and other statements relating to Sun or third party products are valid in the U.S. only. Please contact your local Sales Representative for details of pricing and product availability in your region. Descriptions of, or references to products or publications within SunFlash does not imply an endorsement of that product or publication by Sun Microsystems. Send brief articles (e.g. third party announcements) and include contact information (non-800#, fax #, email, etc) to: John McLaughlin, SunFlash editor, flash@Sun.COM. +1 305 351 4909 ====================================================================== From: flash@Sun.COM Newsgroups: cs.sun-users Subject: SunFlash: 58.20 Kodak, Adobe Support SPARCstation 10SX Date: 20 Oct 1993 03:32:50 -0400 Organization: Columbia University Department of Computer Science NNTP-Posting-Host: cs.columbia.edu sunflash-Distributed to mailing list NY/columbia.edu/cs.columbia.edu sunflash-Send requests, problems to owner-sunflash@cs.columbia.edu ---------------------------------------------------------------------------- The Florida SunFlash Kodak, Adobe Support SPARCstation 10SX SunFLASH Vol 58 #20 October 1993 ---------------------------------------------------------------------------- 58.20 Kodak, Adobe Support SPARCstation 10SX Kodak will incorporate the SPARCstation 10SX system in several imaging products that produce Photo CD discs. SMCC announced today that the SPARCstation 10SX system will come with a coupon redeemable for a complimentary copy of Adobe Photoshop, the industry-leading image processing application from Adobe. ---------------------------------------------------------------------------- Contact: Sun Microsystems Computer Corporation Robert Manetta (415) 336-0979 Complimentary Copy of Adobe Photoshop Offered With New System MOUNTAIN VIEW, Calif. -- October 19, 1993 -- Eastman Kodak Company and Adobe Systems Incorporated today demonstrated their support for the new Sun(R) SPARCstation(TM) 10SX system through resale, bundling and licensing agreements with Sun Microsystems Computer Corporation (SMCC). The two industry leaders are among a host of vendors whose applications will run on the SPARCstation 10SX system and two new multimedia Sun workstations introduced today. Eastman Kodak Company will incorporate the SPARCstation 10SX system in several imaging products that produce Photo CD discs. These products, to be introduced by Kodak over the next year, use compact optical discs to store, enhance and display everything from family snapshots to high-resolution satellite images. Kodak chose the Sun workstation for the new Photo CD products because of its unmatched imaging performance at an affordable price. "There is currently no workstation on the market that comes close to it," said Fred Geyer, vice president and general manager of Kodak's imaging division. The SPARCstation 10SX costs less than $16,000 but delivers the imaging performance of a proprietary imaging workstations costing $60,000 or more. As part of the new Kodak products, the SPARCstation 10SX will perform all image editing and manipulation functions on Photo CD images, including cropping, sharpening and altering color, color density and contrast. Photo CD On Solaris(R) Kodak and SunSoft announced that Photo CD display and editing capabilities will be available on the next release of the Solaris(R) operating environment. This enables all Solaris system users and independent software vendors to display and enhance Kodak Photo CD images. SunSoft will also make a patch for Photo CD available with its recently announced Solaris 2.3 software environment, beginning next month. This is not the first time Kodak and SMCC have collaborated. Since Kodak began marketing Photo CD imaging workstations in 1992, the SPARCstation 2 system has been the base platform. In addition, Kodak engineers were consulted for the initial design specifications of the SPARCstation 10SX system. This past March, Kodak and SunSoft announced that Kodak's KCMS color management system and precision color transforms -- which give workstation users extremely realistic color display and output capabilities -- would be incorporated into the Solaris environment. Complimentary Copy of Adobe Photoshop(TM) Separately, SMCC announced today that the SPARCstation 10SX system will come with a coupon redeemable for a complimentary copy of Adobe Photoshop, the industry-leading image processing application from Adobe. Until now, Adobe Photoshop had only been available on personal computers and Macintoshes. "We are excited about this special offer to provide Adobe Photoshop with the SPARCstation 10SX," said Steve MacDonald, senior vice president and general manager, Systems Products Division at Adobe Systems. "Combining the features and flexibility of Adobe Photoshop software with the power and performance of the new SPARCstation 10SX will provide a significant boost in end user productivity. We will continue to work with Sun to provide solutions that strengthen and broaden each company's market position." Adobe Photoshop software is used to manipulate scanned or computer-generated continuous tone, bitmap, grayscale or color images. Creative professionals may edit and reposition any image or portion of an image, and import and export image files with other graphics programs including those that support Encapsulated PostScript and Adobe Illustrator(R) file formats. The program provides a variety of special effects filters and 16-million-color paint capability and performs a variety of professional functions such as color editing and separations. The coupon for the complimentary copy of Adobe Photoshop software will be included with every SPARCstation 10SX sold through March, 1994. Customers can obtain the application by mailing the coupon back to Adobe. Photoshop is expected to be used in a wide range of applications on SPARCstation systems, including pre-press, industrial design, geographic information systems and creating/enhancing digital film, video and animation. "SMCC has targeted the networked publishing and color imaging markets and relationships with industry leaders like Kodak and Adobe are a key part of our strategy to be the leader in these markets." said Jay Puri, SMCC's vice president of product marketing. Kodak and Adobe are among many third-party vendors whose applications will soon take advantage of the many features of the SPARCstation 10SX. Among these application vendors are AVS (scientific visualization), CEMAX (medical), ERDAS (GIS), KHORAL Research (imaging application development), Apunix (image processing), TimeArts (pre-press, animation), International Imaging Systems (GIS), Landmark Graphics (oil and gas) and Marquette Electronics (medical). SMCC's new multimedia workstations -- the SPARCstation 10M and SPARCclassic(TM) M -- enjoy broad third-party support as well. Among the vendors with applications running on the new workstations are AimTech (multimedia authoring), Apunix (image editing), InSoft (video conferencing, TV-in-a-window), Paradise Software (video on demand), RAD Technologies (video editing) and SunSolutions (desktop video conferencing solution including video, audio, shared applications and shared whiteboard). Sun Microsystems Computer Corporation (SMCC), the world's leading supplier of open client-server computing solutions, is an operating company of Sun Microsystems, Inc. Sun is the exclusive computer supplier to World Cup Soccer 1994. SMCC has its headquarters in Mountain View, Calif. # # # Sun, the Sun logo, Sun Microsystems, Sun Microsystems Computer Corporation, the Sun Microsystems Computer Corporation logo, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. All SPARC trademarks, including the SCD Compliant logo, are trademarks or registered trademarks of SPARC International, Inc. SPARCstation and SPARCclassic are licensed exclusively to Sun Microsystems, Inc. Products bearing SPARC trademarks are based on an architecture developed by Sun Microsystems, Inc. Adobe Illustrator and Adobe Photoshop are trademarks of Adobe Systems Incorporated, which may be registered in certain jurisdictions. All other products are referred to herein by the trademarks as designated by the companies who market those products. For reader inquiries, telephone 1-800-821-4643. ********************************************************************** For information about SunFlash send mail to info-sunflash@Sun.COM. Subscription requests should be sent to sunflash-request@Sun.COM. Archives are on draco.nova.edu, ftp.uu.net, sunsite.unc.edu, src.doc.ic.ac.uk and ftp.adelaide.edu.au All prices, availability, and other statements relating to Sun or third party products are valid in the U.S. only. Please contact your local Sales Representative for details of pricing and product availability in your region. Descriptions of, or references to products or publications within SunFlash does not imply an endorsement of that product or publication by Sun Microsystems. Send brief articles (e.g. third party announcements) and include contact information (non-800#, fax #, email, etc) to: John McLaughlin, SunFlash editor, flash@Sun.COM. +1 305 351 4909 From rem-conf-request@es.net Wed Oct 20 13:57:33 1993 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <29117-0@osi-east.es.net>; Wed, 20 Oct 1993 10:48:57 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA09389; Wed, 20 Oct 93 10:48:56 PDT Date: Wed, 20 Oct 93 10:48:56 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9310201748.AA09389@viipuri.nersc.gov> To: rem-conf@es.net Subject: Re: Sun announces new multimedia products Anyone from Sun care to clarify the following? Also available is a "multimedia bundle" that can be used to equip any of the existing installed base of SPARCstation systems for multimedia. Among workstation vendors, only SMCC allows customers to protect their investments and retrofit existing systems for multimedia. Other vendors compel customers to purchase entire new systems to obtain these capabilities. Priced at $1,895, the multimedia package includes the SunVideo capture/compression card, video camera and multimedia CD-ROM disc. The SunVideo card can also be purchased alone for $1,495. Does this include support for the SunVideo card IN SunOS 4.1.x? Or does the bundle include an upgrade to Solaris2.3? What are the specs on the camera? What software is on the "multimedia CD-ROM"? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ari Ollikainen ari@es.net National Energy Research Supercomputer Center ESnet (Energy Sciences Network) Lawrence Livermore National Laboratory 510-423-5962 FAX:510-423-8744 P.O. BOX 5509, MS L-561, Livermore, CA 94550 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Wed Oct 20 15:31:45 1993 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <03937-0@osi-east.es.net>; Wed, 20 Oct 1993 12:22:27 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA09508; Wed, 20 Oct 93 12:22:19 PDT Date: Wed, 20 Oct 93 12:22:19 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9310201922.AA09508@viipuri.nersc.gov> To: markus@octavia.anu.edu.au Subject: Re: add Cc: rem-conf@es.net > > I've now gotten myself subscribed to the Australian end of rem-conf, Thanks. > Do you happen to archive old articles on rem-conf somewhere ? The Australian > person didn't know of any archive.. > > Thanks for your help. > > Cheers, > Markus > > Markus Buchhorn, Parallel Computing Research Facility > email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU > Australian National University, Canberra, 0200 , Australia. > [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] > Since this is of general interest, I'm copying the answer to the list. The archive is on nic.es.net in pub/mailing-lists/mail-archive/rem-conf and is automatically kept current: ftp> cd pub/mailing-lists/mail-archive/rem-conf 250 CWD command successful. ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 2591 -rw-r--r-- 1 0 37 117 Jul 19 16:31 .IndexLink -rwxr-xr-x 1 0 22 1237 Oct 19 14:44 .cache -rw-r--r-- 1 7377 22 308028 Aug 27 22:15 rem-conf-1992-11 -rw-r--r-- 1 7377 22 260433 Aug 27 22:14 rem-conf-1992-12 -rw-r--r-- 1 7377 22 96338 Aug 27 22:14 rem-conf-1993-01 -rw-r--r-- 1 7377 22 125222 Aug 27 22:14 rem-conf-1993-02 -rw-r--r-- 1 7377 22 240714 Aug 27 22:14 rem-conf-1993-03 -rw-r--r-- 1 7377 22 117390 Aug 27 22:14 rem-conf-1993-04 -rw-r--r-- 1 7377 22 78700 Aug 27 22:14 rem-conf-1993-05 -rw-rw-r-- 1 210 22 198875 Aug 27 22:47 rem-conf-1993-06 -rw-r--r-- 1 210 22 311141 Jul 30 19:22 rem-conf-1993-07 -rw-r--r-- 1 210 22 204103 Aug 31 13:31 rem-conf-1993-08 -rw-r--r-- 1 210 22 394008 Sep 30 18:15 rem-conf-1993-09 -rw-r--r-- 1 210 22 193829 Oct 20 10:57 rem-conf-1993-10 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ari Ollikainen ari@es.net National Energy Research Supercomputer Center ESnet (Energy Sciences Network) Lawrence Livermore National Laboratory 510-423-5962 FAX:510-423-8744 P.O. BOX 5509, MS L-561, Livermore, CA 94550 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Wed Oct 20 19:36:35 1993 Received: from brolga.cc.uq.oz.au by osi-east.es.net via ESnet SMTP service id <11237-0@osi-east.es.net>; Wed, 20 Oct 1993 16:35:53 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Thu, 21 Oct 1993 09:35:42 +1000 To: rem-conf@es.net Subject: RE: Sun announces new multimedia products cc: flash@Sun.COM Date: Thu, 21 Oct 1993 09:35:38 +1000 From: David Vu > Also available is a "multimedia bundle" that can be used to equip any > of the existing installed base of SPARCstation systems for multimedia. > Among workstation vendors, only SMCC allows customers to protect their > investments and retrofit existing systems for multimedia. Other vendors > compel customers to purchase entire new systems to obtain these > capabilities. Priced at $1,895, the multimedia package includes the > SunVideo capture/compression card, video camera and multimedia CD-ROM > disc. The SunVideo card can also be purchased alone for $1,495. > > Sun Microsystems Computer Corporation (SMCC), the world's leading > supplier of open client-server computing solutions, is an operating > company of Sun Microsystems, Inc. Sun is the exclusive computer > supplier to World Cup Soccer 1994. SMCC has its headquarters in > Mountain View, Calif. Anyone from Sun or SMCC know whether there are any plans to release the PC or MAC version of this SunVideo multimedia package? David Vu | Prentice Centre Internet: D.Vu@cc.uq.oz.au | The University of Queensland Phone: +61 7 365 3941 | Brisbane Q 4072 FAX: +61 7 365 4477 | Australia From rem-conf-request@es.net Wed Oct 20 22:19:34 1993 Received: from spool.UU.NET by osi-east.es.net via ESnet SMTP service id <12270-0@osi-east.es.net>; Wed, 20 Oct 1993 19:12:52 +0000 Received: from joyce.cs.su.OZ.AU by spool.UU.NET with MHSnet (5.61/UUNET-uucp-primary) id AA10113; Wed, 20 Oct 93 22:12:42 -0400 Message-Id: <9310210212.AA10113@spool.UU.NET> Date: Thu, 21 Oct 1993 11:55:45 +1000 From: gregr@joyce.cs.su.OZ.AU (Greg Ryan) Subject: multicasting with Solaris 1.1C and 2.3? To: rem-conf@es.net Reply-To: gregr@cs.su.oz.au Cc: roy@uunet.UU.NET Our connection to the MBONE has been via a Sparcstation running SunOS 4.1.2, but now with more recent Sun machines installed and on the horizon for the department, we've been wondering what effect the newer versions of Solaris will have on our ability to run multicasting software on these machines. Solaris 1.1C (aka SunOS 4.1.3C) has just been made available to us and Solaris 4.3 is just around the corner, so we're trying to decide whether to down or upgrade our machines. So my questions for the group are: 1) Is anybody running a multicast kernel successfully on Solaris 1.1C (SunOS 4.1.3C)? If so, as 4.1.3C comes with no 4.1.3 patches built in, which 4.1.3 patches, if any, (besides the multicast ones) were required for the multicast kernel and mrouted to work on 4.1.3C? 2) How far will the upcoming Solaris 2.3 release, supporting both dynamic and static 4.1.x binaries, go to solving the problems of running the audio/visual tools on Solaris? 3) Will Solaris 2.3 support a multicasting kernel and mrouted? Sorry about the Sun specific nature of this mail, but this mailing list probably has the expertise to answer my questions. Greg Ryan gregr@cs.su.oz.au From rem-conf-request@es.net Thu Oct 21 01:02:22 1993 Received: from tadpole.Tadpole.COM by osi-east.es.net via ESnet SMTP service id <13152-0@osi-east.es.net>; Wed, 20 Oct 1993 22:01:44 +0000 Received: from ribit.tadpole.com by tadpole.Tadpole.COM (4.1/SMI-4.1) id AA08662; Thu, 21 Oct 93 00:01:26 CDT Date: Thu, 21 Oct 93 00:01:26 CDT From: jim@Tadpole.COM (Jim Thompson) Message-Id: <9310210501.AA08662@tadpole.Tadpole.COM> To: gregr@cs.su.oz.au, rem-conf@es.net Subject: Re: multicasting with Solaris 1.1C and 2.3? Cc: roy@uunet.UU.NET > Solaris 1.1C (aka SunOS 4.1.3C) has just been made available to us and > Solaris 4.3 is just around the corner, so we're trying to decide whether ^-- 2 ? > to down or upgrade our machines. > 1) Is anybody running a multicast kernel successfully on Solaris 1.1C > (SunOS 4.1.3C)? If so, as 4.1.3C comes with no 4.1.3 patches built in, > which 4.1.3 patches, if any, (besides the multicast ones) were required > for the multicast kernel and mrouted to work on 4.1.3C? This same question was asked on the mbone list earlier today. 4.1.3C supports machines based on Tsunami (er, microsparc) only. Given that Sun *supposedly* made minimal changes, I wouldn't expect that it would be very far off to expect that the binary distributions for sun4m machines running 4.1.3 would work out of the box. The big difference in porting to microsparc is that all writes go via the data cache. This means that any self-modifing code needs to insert an 'iflush' instruction in order for the CPU to see the modification. This is typically only needed in trap handlers and ld.so. ;-) > 2) How far will the upcoming Solaris 2.3 release, supporting both dynamic > and static 4.1.x binaries, go to solving the problems of running the > audio/visual tools on Solaris? I run vat, nv, sd, and wb (dynamic versions) on 2.3 (EA) everyday. > 3) Will Solaris 2.3 support a multicasting kernel and mrouted? If you're referring to being able to use a 2.3 machine as a multicast router, not without some work. :-) If you just want to use it as and 'end-point' it will do that out of the box. Tadpole makes single-board computers based on microsparc. I've got a couple of these around. If it turns into an issue to get the multicast router code working on microsparc, I'll be glad to hack it in at some point. It only took about 2 hours to do the same thing for sparcbook (1 and 2), and most of that was figuring out how to get the ethernet interface on the machine to deal with multicast packets. Jim From rem-conf-request@es.net Thu Oct 21 05:42:21 1993 Received: from mvs.oac.ucla.edu by osi-east.es.net via ESnet SMTP service id <14235-0@osi-east.es.net>; Thu, 21 Oct 1993 02:41:44 +0000 Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 4137; Thu, 21 Oct 93 02:42:18 PST Date: Thu, 21 Oct 93 02:41 PDT To: jim@TADPOLE.COM (Jim Thompson) From: Denis DeLaRoca (310) 825-4580 Subject: Re: Re: multicasting with Solaris 1.1C and 2.3? Cc: rem-conf@ES.NET > 4.1.3C supports machines based on Tsunami (er, microsparc) only. > Given that Sun *supposedly* made minimal changes, I wouldn't expect > that it would be very far off to expect that the binary distributions > for sun4m machines running 4.1.3 would work out of the box. I built an mcasting kernel successfully but I can't build mrouted due to unresolved references to _dlopen, _dlclose and _dlsym (but the distribution mrouted binary seems to come up ok). Maybe you could resolve the reported problem with dbri_mmcodec.o being different for 4.1.3. :-) -- Denis From rem-conf-request@es.net Thu Oct 21 08:09:19 1993 Received: from nsipo.arc.nasa.gov by osi-east.es.net via ESnet SMTP service id <14784-0@osi-east.es.net>; Thu, 21 Oct 1993 04:53:55 +0000 Received: from lupine.nsi.nasa.gov by nsipo.arc.nasa.gov (4.1/1.5) id AA03493; Thu, 21 Oct 93 04:53:52 PDT Received: by lupine.nsi.nasa.gov (5.65/SunOS-4.1.3) id AA16875; Thu, 21 Oct 93 07:52:25 -0400 From: Mike Newell Message-Id: <9310211152.AA16875@lupine.nsi.nasa.gov> Subject: Re: Re: multicasting with Solaris 1.1C and 2.3? To: CSP1DWD@MVS.OAC.UCLA.EDU (Denis DeLaRoca) Date: Thu, 21 Oct 93 7:52:24 EDT Cc: jim@TADPOLE.COM, rem-conf@es.net In-Reply-To: ; from "Denis DeLaRoca" at Oct 21, 93 2:41 am X-Mailer: ELM [version 2.3 PL11] > > > 4.1.3C supports machines based on Tsunami (er, microsparc) only. > > Given that Sun *supposedly* made minimal changes, I wouldn't expect > > that it would be very far off to expect that the binary distributions > > for sun4m machines running 4.1.3 would work out of the box. > > I built an mcasting kernel successfully but I can't build mrouted > due to unresolved references to _dlopen, _dlclose and _dlsym (but > the distribution mrouted binary seems to come up ok). > > Maybe you could resolve the reported problem with dbri_mmcodec.o > being different for 4.1.3. :-) > I had this problem quite a while ago due to an improperly built libc.so. For the short term you can try the -Bstatic flag on your cc command; that builds the image without dynamic linking. Also, check your libc.so. There's instructions in a sub-directory of the /usr/lib/shlib.etc directory. What the instructions DON'T mention is that two or three of the lines in the "lorder-sparc" file lose the ".o" extension. This caused the dynamic link problem on my machine. Make sure all the file names in lorder-sparc have the .o on them, and rebuild. At least, that works for SunOS 4.1.3... Mike Newell NASA Advanced Network Applications From rem-conf-request@es.net Thu Oct 21 11:30:03 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <14218-0@osi-east.es.net>; Thu, 21 Oct 1993 02:37:33 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 21 Oct 1993 10:37:12 +0100 To: Van Jacobson cc: rem-conf@es.net, mbone@isi.edu Subject: we made doonesbury!!! Date: Thu, 21 Oct 93 10:37:08 +0100 From: Jon Crowcroft todays Guradian (national UK quality newspaper), doonesbury, features audio/video and a reference to watching the shuttle launch (delay) - where does this guy get his copy!!! garry trudeau has to be the most plugged in person - he was way more up to date than the computer section of the same paper:-) jon p.s. is he on e-mail we should congratulate him.. From rem-conf-request@es.net Thu Oct 21 12:32:41 1993 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <17235-0@osi-east.es.net>; Thu, 21 Oct 1993 09:32:08 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA10330; Thu, 21 Oct 93 09:32:06 PDT Date: Thu, 21 Oct 93 09:32:06 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9310211632.AA10330@viipuri.nersc.gov> To: rem-conf@es.net Subject: Mulimedia SGI solution ! Forwarded mail: ----- Begin Included Message ----- >From travere@indigo1.cyceron.fr Thu Oct 21 00:51:56 1993 Date: Thu, 21 Oct 93 08:51:28 +0100 From: travere@indigo1.cyceron.fr (Jael.Travere@Cyceron.Fr) To: rem-conf-request@es.net ^^^^^^^ Subject: Mulimedia SGI solution ! Content-Length: 749 A very powerful "multimedia bundle" is also available with the new Indy SGI workstation ! including the station, the Indycam (colour camera) and the full package (Whiteboard etc etc ..). It is not a marketing information !! i've tested this solution and it is very efficient with the power of a SGI machine (GL, Explorer , Distributed Workspace, and of course IRIX 5.1) Jael.Travere@Cyceron.Fr ___________________________________________________________ J.M Travere, Ph. D Cyceron PET Research Center CEA/DSV/DPTE Bd Becquerel - BP 5027 Comp. Sc. Manager 14021 - Caen - CEDEX France Std : (+33) 31 47 02 00 Tel : (+33) 31 47 02 14 Fax : (+33) 31 47 02 22 ___________________________________________________________ ----- End Included Message ----- From rem-conf-request@es.net Thu Oct 21 14:21:51 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <18417-0@osi-east.es.net>; Thu, 21 Oct 1993 11:09:46 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Thu, 21 Oct 1993 11:09:40 -0700 Posted-Date: Thu 21 Oct 93 11:08:49 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 21 Oct 93 11:08:50 PDT Date: Thu 21 Oct 93 11:08:49 PDT From: Stephen Casner Subject: Re: we made doonesbury!!! To: J.Crowcroft@cs.ucl.ac.uk Cc: rem-conf@es.net, MBONE@ISI.EDU Message-Id: <751226929.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199310210937.AA21747@venera.isi.edu> Mail-System-Version: Jon, I am also impressed by Trudeau's quick response, but I think this one is not quite as impressive as it might seem at first glance to us. On my first reading, I interpreted the strip the same way you did, but then I decided that he was not talking about watching a delayed replay of the shuttle launch. The shuttle launch was delayed by a problem with one of the computers, and I think he meant that the characters would watch the delay itself by hacking into the computer, in the same way that they were watching the recording level meters in the studio computer. Still, if he really was referring to the most recent shuttle launch, that's a one-week lag which is very short compared to typical comic strip production. -- Steve ------- From rem-conf-request@es.net Thu Oct 21 15:47:37 1993 Received: from mothra.nts.uci.edu by osi-east.es.net via ESnet SMTP service id <19637-0@osi-east.es.net>; Thu, 21 Oct 1993 12:32:21 +0000 Received: by mothra.nts.uci.edu id AA29599 (5.65c/IDA-1.4.4 for rem-conf@es.net); Thu, 21 Oct 1993 12:32:16 -0700 Received: from [128.200.132.104] (godzilla.nts.uci.edu) by mothra.nts.uci.edu with SMTP id AA29557 (5.65c/IDA-1.4.4 for rem-conf@es.net); Thu, 21 Oct 1993 12:31:42 -0700 Message-Id: <199310211931.AA29557@mothra.nts.uci.edu> Date: Thu, 21 Oct 1993 12:32:03 -0700 To: Jon Crowcroft , Van Jacobson From: David Walker X-Sender: dhwalker@mothra.nts.uci.edu Subject: Re: we made doonesbury!!! Cc: rem-conf@es.net, mbone@isi.edu Uh oh! Now they *can* tell you're a dog. :-) David At 10:37 AM 10/21/93 +0100, Jon Crowcroft wrote: >todays Guradian (national UK quality newspaper), doonesbury, features >audio/video and a reference to watching the shuttle launch (delay) - > >where does this guy get his copy!!! > >garry trudeau has to be the most plugged in person - he was way more >up to date than the computer section of the same paper:-) > >jon >p.s. is he on e-mail we should congratulate him.. From rem-conf-request@es.net Thu Oct 21 17:54:58 1993 Received: from ibm.cl.msu.edu by osi-east.es.net via ESnet SMTP service id <21393-0@osi-east.es.net>; Thu, 21 Oct 1993 14:41:58 +0000 Received: from MSU.BITNET by msu.edu (IBM VM SMTP V2R2) with BSMTP id 6425; Thu, 21 Oct 93 17:42:05 EDT Received: by MSU (Mailer R2.08 PTF008) id 4074; Thu, 21 Oct 93 17:42:05 EDT Date: Thu, 21 Oct 93 17:41 EDT To: rem-conf@es.net X-Originally-To: rem-conf@es.net, mbone@isi.equ From: "Richard_R.Moore" Subject: doonesbury > Date: Thu 21 Oct 93 11:08:49 PDT > From: Stephen Casner > Subject: Re: we made doonesbury!!! > To: J.Crowcroft@cs.ucl.ac.uk > Cc: rem-conf@es.net, MBONE@ISI.EDU > Message-Id: <751226929.0.CASNER@XFR.ISI.EDU> > In-Reply-To: <199310210937.AA21747@venera.isi.edu> > Mail-System-Version: > Sender: video-request@cic.net > Errors-To: owner-video@cic.net > Precedence: bulk > > Jon, > I am also impressed by Trudeau's quick response, but I think > this one is not quite as impressive as it might seem at first glance 2 to us. On my first reading, I interpreted the strip the same way you > did, but then I decided that he was not talking about watching a > delayed replay of the shuttle launch. The shuttle launch was delayed > by a problem with one of the computers, and I think he meant that the > characters would watch the delay itself by hacking into the computer, > in the same way that they were watching the recording level meters in > the studio computer. Still, if he really was referring to the most > recent shuttle launch, that's a one-week lag which is very short > compared to typical comic strip production. > -- Steve > ------- It is interesting how different people can read the same stri and have much different intepretations. I read it as this hacker was GOING TO CAUSE the delay by messing with the shuttle's computer (otherwise, how would he know it was going to be delayed because of a computer problem?) From rem-conf-request@es.net Thu Oct 21 17:59:48 1993 Received: from ietf.cnri.reston.va.us by osi-east.es.net via ESnet SMTP service id <21592-0@osi-east.es.net>; Thu, 21 Oct 1993 14:59:07 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21469; 21 Oct 93 16:54 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-avt-rtp-04.txt, .ps Date: Thu, 21 Oct 93 16:54:46 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9310211654.aa21469@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP: A Transport Protocol for Real-Time Applications Author(s) : H. Schulzrinne, S. Casner Filename : draft-ietf-avt-rtp-04.txt, .ps Pages : 41 This memorandum describes the real-time transport protocol, RTP. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of-service for real-time services. The data transport isaugmented by a control protocol (RTCP) designed to provide minimal control and identification functionality particularly in multicast networks. Within multicast associations, sites can also direct control messages to individual sites. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and bridges. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-avt-rtp-04.txt". Or "get draft-ietf-avt-rtp-04.ps". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE draft-ietf-avt-rtp-04.txt". Or "FILE draft-ietf-avt-rtp-04.ps". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19931021111604.I-D@CNRI.Reston.VA.US> FILE draft-ietf-avt-rtp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19931021111604.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Oct 21 18:09:54 1993 Received: from ietf.cnri.reston.va.us by osi-east.es.net via ESnet SMTP service id <21592-1@osi-east.es.net>; Thu, 21 Oct 1993 14:59:09 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21493; 21 Oct 93 16:54 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-avt-issues-01.txt, .ps Date: Thu, 21 Oct 93 16:54:55 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9310211654.aa21493@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Issues in Designing a Transport Protocol for Audio and Video Conferences and other Multiparticipant Real-Time Applications Author(s) : H. Schulzrinne Filename : draft-ietf-avt-issues-01.txt, .ps Pages : 64 This memorandum is a companion document to the current version of the RTP protocol specification draft-ietf-avt-rtp-*.{txt,ps}. It discusses aspects of transporting real-time services (such as voice or video) over the Internet. It compares and evaluates design alternatives for a real-time transport protocol, providing rationales for the design decisions made for RTP. Also covered are issues of port assignment and multicast address allocation. A comprehensive glossary of terms related to multimedia conferencing is provided. This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the author(s). Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-avt-issues-01.txt". Or "get draft-ietf-avt-issues-01.ps". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE draft-ietf-avt-issues-01.txt". Or "FILE draft-ietf-avt-issues-01.ps". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19931021112204.I-D@CNRI.Reston.VA.US> FILE draft-ietf-avt-issues-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-issues-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19931021112204.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Thu Oct 21 18:18:46 1993 Received: from ietf.cnri.reston.va.us by osi-east.es.net via ESnet SMTP service id <21736-0@osi-east.es.net>; Thu, 21 Oct 1993 15:10:43 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21522; 21 Oct 93 16:55 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-avt-profile-03.txt Date: Thu, 21 Oct 93 16:55:09 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9310211655.aa21522@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Sample Profile for the Use of RTP for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne Filename : draft-ietf-avt-profile-03.txt Pages : 10 This note describes a profile for the use of the real-time transport protocol (RTP) and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from format index to encodings. The document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. However, the definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-avt-profile-03.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE draft-ietf-avt-profile-03.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19931021113133.I-D@CNRI.Reston.VA.US> FILE draft-ietf-avt-profile-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19931021113133.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Fri Oct 22 01:13:51 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <25434-0@osi-east.es.net>; Thu, 21 Oct 1993 22:11:06 +0000 Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Thu, 21 Oct 1993 22:11:03 -0700 Date: Thu, 21 Oct 1993 22:10:58 -0700 From: schooler@ISI.EDU Posted-Date: Thu, 21 Oct 1993 22:10:58 -0700 Message-Id: <199310220510.AA16292@elm.isi.edu> Received: by elm.isi.edu (5.65c/4.0.3-4) id ; Thu, 21 Oct 1993 22:10:58 -0700 To: rem-conf@es.net Subject: a new Mbone tool Cc: casner@ISI.EDU, schooler@ISI.EDU, touch@ISI.EDU As some of you may know, we have been working on a session orchestration tool that allows a user to explicitly invite others to participate in a conference, and alerts them to accept or decline. For largely historical reasons (that this program evolved over time from a similar tool by the same name), it is called mmcc, the multimedia conference control program. Mmcc is an X-based tool that provides both point-to-point and multipoint teleconferences. It automatically spawns underlying audio, video and groupware programs among members of a session, then tears them down at session completion. Currently, mmcc brings up vat by default, and offers the option to start nv and wb, but in the future we'd like to support other MBone tools as well. Mmcc will distribute a session key for confidential sessions. In this preliminary version, the key is sent in the clear, so it is not secure, but eventually we expect to use Kerberos or certificates for secure key distribution. Mmcc aims to supplement the large open-style sessions supported by the existing version of sd. It complements the hailing-channel approach of public sessions with a more private session style for smaller conferences. Thus, session advertisement is internal to the group of participating conferees. If you have a previous version of mmcc PLEASE THROW IT AWAY. We have a new IANA-sanctioned port number, so old and new versions of mmcc cannot communicate. We have only released a Sparc version of the software, but are interested in finding other platforms on which we can test the program. I've appended the latest README file for documentation, with pointers to more detailed information. E. Eve M. Schooler USC/Information Sciences Institute Voice: 310-822-1511, x114 4676 Admiralty Way FAX: 310-823-6714 Marina del Rey, CA 90292 E-mail: schooler@isi.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MMCC RELEASE SOFTWARE --------------------- The mmcc release software is available via anonymous FTP from ftp.isi.edu:confctrl/mmcc.tar.Z, and includes the files: mmcc Sparc binary of the program mmcc.static Sparc binary, with statically bound libraries mmcc.1 Manual page .mmccrc Sample user configuration file .mmcc.au Sample audio file sounds A directory of sample audio files README This file CHANGES Log of incremental changes COPYRIGHT Copyright notice HOW TO USE MMCC --------------- To start up mmcc, type mmcc & Mmcc must be running on a remote user's workstation in order to rendezvous with that user. The mmcc window may be closed to place it out of view when it is not in use. Any incoming requests will automatically re-open the window. CAUTION ------- Please note that the Internet does not have sufficient capacity to act as a replacement for the telephone network, so mmcc and the underlying media tools should be used judiciously. The audio and video traffic will not slow down the way TCP traffic will, so if multiple calls are placed simultaneously over the same link, severe congestion could result. In particular, please limit the use of multicast (sessions with more than two parties) with "World" scope on the Multicast Backbone (MBONE) during major events as advertised in sd and on the rem-conf@es.net mailing list. Two party unicast calls will have less impact, but still could overload links that are used in the MBONE. For more information regarding the MBONE, see the frequently asked questions file ftp.isi.edu:mbone/faq.txt. USER CONFIGURATION FILE ----------------------- Mmcc may be configured to start up with a database of remote user aliases and addresses. By default mmcc looks for the file ".mmccrc" in your home directory. The -f option may be used to specify a different user configuration file (see the man page for further details). Each line in the config file includes an alias for a user, the user's login id, and the user's workstation host name or host address. The port field is optional, and by default has a value of 5050; a port may be specified as a decimal or hexidecimal value (e.g., 0x13BA). Create your own "~/.mmccrc" file, as you begin to acquire remote users' addresses. CREATING A NEW SESSION ---------------------- Use the left mouse button to click on "Connect" in the main mmcc window; this will cause the creation of a "Connect" panel. With the "Connect" panel open, first click, then type a session name in the "Session Alias" field. If this field is left blank, the name of the session is automatically generated and is based on the session initiator's alias. Specify a session encryption key by clicking, then typing in the "Key" field. Under the "Participants" list, use the left mouse button to click on the aliases of any remote users who should be included in the session. Repeated clicking on the same user's name toggles the selection. To include a user not in your user configuration file, click left, then type in the "Add" field at the bottom of the "Participants" list; the fields correspond to the fields of the user configuration file. Only the "user" and "addr" fields are required. If unspecified, "alias" defaults to "user@addr", or "user@addr:port" if the "port" field is non-standard. When unspecified, "port" defaults to mmcc's default port. When the entry is complete, simply hit to enter it in the participant list and select it. There currently is no automated way to save new participant entries in the user configuration file, but we would like to add this in the near future. Under the "Media" list, select the media to include. Currently, the choices "Audio", "Video", and "Groupware" map to the programs vat, nv, and wb. Each media has its own QoS (quality of service) setting, as well as a Scope (ttl). The QoS choice is experimental and is presently only in service for audio; "High", "Medium", and "Low" map to audio encodings pcm, idvi, gsm. Using the left mouse button, click on the "CREATE" button to initiate the session, or on "Cancel" to cancel the request. ACCEPTING AN INVITATION ----------------------- When a remote user requests your participation in a conference, your mmcc window will open itself and pop to the front of your screen. By default, it double beeps to get your attention. However, you may configure mmcc to play a sound file to get your attention instead, by placing a sound file called ".mmcc.au" in your home directory, or by passing mmcc the -play option on the command line (see the man page for further details). SESSION STATUS -------------- Session status may be observed by clicking on the "View Status" button on the main mmcc panel. Status includes the list of session participants, as well as the details associated with the session; the session alias, session key, media included, ttl's, and qos choices. DISCONNECTING A SESSION ----------------------- Use the "Disconnect" button on the main mmcc panel to leave an on-going session. The conference is terminated when fewer than two sites are left in a session. EXITING MMCC ------------ Type "q", "Q" or "^C" anywhere in the main mmcc panel to quit out of the program. Alternatively, those of you running OpenWindows may use the "Quit" option in the frame menu to exit. If the Connect panel is open, it will have to be closed before the program will exit. CAVEATS ------- There may be GUI strangeness due to X differences. We are particularly interested in resolving these. Please let us know what you find. During a multiparty session, mmcc spawns programs that rely on the presence of an IP multicast kernel, and if communicating with remote users the presence of the MBONE. For now, the default ttl value passed to these programs is 2, or the "Local" scope setting. The Video and Groupware settings "Same", are relative to Audio scope. Be aware that a ttl value of 127 constitutes an Internet-wide call, and that there are certain combinations of media and ttl that mmcc considers valid but anti-social. Mmcc produces a pop-up warning message that must be answered before the session will be initiated. Situations may arise where the selected ttl proves to be too small for all media to reach all participants. However, these are not issues for two-party sessions, where unicast is used instead. The search path in your shell environment must include vat, nv and wb. Similarly, if you use the option to play a sound file when someone calls you, then your search path must also include the play program. If the audio device is locked by another audio-related program, mmcc will be unable to play the designated sound file, but will double beep instead. In either case, a "REPLY REQUESTED" pop-up will appear. The "View Status" on the main panel creates a snapshot of the status of the selected session, and dumps it to the screen. The screen dump therefore does not reflect subsequent changes in state, user list, etc. It also remains until the panel is closed (Hide Status), even if the corresponding session is closed. For a more complete listing of Caveats, see the man page. PROMISES, PROMISES ------------------ In the near term, we expect mmcc to support all the items in the GUI for which there is a button but no underlying support (!), Modify scenarios (invites, joins, add media, change parameters), more dynamic user configuration files, group aliases, additional underlying media programs (pvp, ivs, nevot, etc.), user-tailored Tk/Tcl extensions, better timeout configurability, among other improvements. Finally, command line options will be offered as Xresource variables. Be forewarned that the GUI and distributed peer-to-peer protocol are likely to change between alpha releases. The mmcc binary is currently only available for Sun SPARCs. COMMENTS -------- This should be enough information to get you started. Please forward any bugs, comments, suggestions you may have to Eve Schooler or Joe Touch . They are most welcome and appreciated. THANKS for being part of this alpha release. From rem-conf-request@es.net Fri Oct 22 02:11:54 1993 Received: from ressu.cc.tut.fi by osi-east.es.net via ESnet SMTP service id <25683-0@osi-east.es.net>; Thu, 21 Oct 1993 23:05:36 +0000 Received: by ressu.cc.tut.fi id AA15718 (5.65b/IDA-1.4.3 for rem-conf@es.net); Fri, 22 Oct 93 08:05:28 +0200 Date: Fri, 22 Oct 93 08:05:28 +0200 From: Mika Uusitalo Message-Id: <9310220605.AA15718@ressu.cc.tut.fi> To: rem-conf@es.net Subject: subscribe please subscribe me to this mailing list mika uusitalo tampere univ. of tech. finland From rem-conf-request@es.net Fri Oct 22 02:27:12 1993 Received: from dmssyd.syd.dms.CSIRO.AU by osi-east.es.net via ESnet SMTP service id <25781-0@osi-east.es.net>; Thu, 21 Oct 1993 23:20:57 +0000 Received: from drugs.syd.dms.CSIRO.AU by dmssyd.syd.dms.CSIRO.AU (4.1/5.17) id AA03598; Fri, 22 Oct 93 16:20:25 EST (from marka@syd.dms.csiro.au (Mark Andrews)) Message-Id: <9310220620.AA03598@dmssyd.syd.dms.CSIRO.AU> To: schooler@isi.edu Cc: rem-conf@es.net, casner@isi.edu, touch@isi.edu Subject: Re: a new Mbone tool In-Reply-To: Your message of "Thu, 21 Oct 1993 22:10:58 MST." <199310220510.AA16292@elm.isi.edu> Date: Fri, 22 Oct 1993 16:20:21 +1000 From: Mark Andrews It looks interesting from the description. Pity that there are hard coded paths in it. Mark. % mmcc couldn't open "/local/tcl-7.0b2/lib/tk/tclIndex": No such file or directory % -- Mark Andrews, CSIRO Div Maths & Stats Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au UUCP: ....!uunet!syd.dms.csiro.au!marka From rem-conf-request@es.net Fri Oct 22 05:10:11 1993 Received: from brolga.cc.uq.oz.au by osi-east.es.net via ESnet SMTP service id <25942-0@osi-east.es.net>; Thu, 21 Oct 1993 23:48:09 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Fri, 22 Oct 1993 16:47:37 +1000 To: Mark Andrews cc: schooler@isi.edu, rem-conf@es.net, casner@isi.edu, touch@isi.edu Subject: Re: a new Mbone tool In-reply-to: Your message of "Fri, 22 Oct 1993 16:20:21 +1000." <9310220620.AA03598@dmssyd.syd.dms.CSIRO.AU> Date: Fri, 22 Oct 1993 16:47:33 +1000 Message-ID: <2353.751272453@brolga.cc.uq.oz.au> From: George Michaelson It looks interesting from the description. Pity that there are hard coded paths in it. Mark. % mmcc couldn't open "/local/tcl-7.0b2/lib/tk/tclIndex": No such file or directory % One symlink solved this for me. it looks lovely! -George From rem-conf-request@es.net Fri Oct 22 10:20:12 1993 Received: from CNRI.Reston.VA.US by osi-east.es.net via ESnet SMTP service id <28670-0@osi-east.es.net>; Fri, 22 Oct 1993 07:19:27 +0000 Received: from CNRI.Reston.VA.US by CNRI.Reston.VA.US id aa11505; 22 Oct 93 10:18 EDT To: mbone@isi.edu, rem-conf@es.net cc: John Garret <0004716758@mcimail.com>, John Stewart , Claudio Topolcic Subject: Planned video conference Date: Fri, 22 Oct 93 10:18:21 -0400 From: Claudio Topolcic Message-ID: <9310221018.aa11505@CNRI.Reston.VA.US> Folks, Hi! We are planning to use Internet video and audio to connect someone into a meeting we are having at CNRI. We plan to do this by establishing full duplex point to point VAT and NV connections between Berkeley and CNRI (in the Washington DC area). We will be using default settings for both. We will set these connections up sometime during the evening of Monday 25 October and during the (East coast) work day on Tuesday 26 October. However, it is unlikely that they will be up for that entire time period, and will not be left up overnight. Although this meeting will not be on the MBONE, we thought that some of you might want to know that this is going on. Please let me know if you feel this activity will cause excessive problems. My address and phone number are below. I would also like to take this opportunity to thank all the people who have made Internet video and audio a reality. This is a really useful capability. Claudio Topolcic Corporation for National Research Initiatives 703-620-8990 or 703-758-5916 topolcic@cnri.reston.va.us From rem-conf-request@es.net Fri Oct 22 10:41:14 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <28800-0@osi-east.es.net>; Fri, 22 Oct 1993 07:28:06 +0000 Received: from jaguar.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 22 Oct 1993 15:27:26 +0100 To: rem-conf@es.net, mice-seminars@cs.ucl.ac.uk Subject: mice international seminar Date: Fri, 22 Oct 93 15:27:25 +0100 From: Stuart Clayman As part of its International Seminar Series on Multimedia, Comms & Nets, Distributed Systems and CSCW, the MICE project proudly presents The First ISODE Research Seminar on Monday, October 25th at 14:00 GMT / 15:00 CET. During the seminar the following addresses will be used: Audio: vat on 224.5.17.12 port default Video: ivs on 224.5.17.12 port default Whiteboard: wb on 224.5.17.12 port 32416 Some of the slides are large so use the -P 100000 option to wb The slides for the talk can be collected by anonymous ftp from cs.ucl.ac.uk:/cs/ftp/ftp/mice/seminars/lavender Speaker: Dr. Greg Lavender Microelectronics and Computer Technology Corporation (MCC) Title: OOSI - an objectified Upper layer OSI protocol stack Abstract: The purpose of this talk is to bring to the attention of the ISODE Consortium community information on emerging research on upper layer protocol design and implementation that has potential benefit to users and implementors of ISODE-based technology. I will describe an ``objectified'' upper layer OSI protocol stack, called OOSI (pronounced "ooo-zi"), that is a complete re-design and ongoing implementation in C++ of the core ISODE protocol stack. The design and implementation of OOSI was undertaken primarily to support concurrent C++ applications that require a fully asynchronous, multi-threaded, peer-to-peer communication framework. OOSI is unique in it's approach to the protocol layering problem. Class templates are used to construct ``Polymorphic Service Access Points'' that allow a SAP to be parameterized with the (minimal) set of functional units required for a particular association. The relationship between the presentation, session and transport switch layers is defined by an inheritance-based structure resulting in the ability to restrict, or even eliminate, session functionality. The result is the ability to construct applications using ``simple'' OSI stack configurations (e.g., kernel presentation services directly over transport). Asynchronous service requests are supported in OOSI by the implementation of ``Polymorphic Futures,'' which represent the future result value of an asynchronously invoked service primitive. Type conversion is used to effect a synchronized rendezvous with a client thread waiting on an eventual service indication event. Concurrency is provided by a POSIX threads class that maps onto either Solaris threads or OSF/1 pthreads. I will also describe a set of object-oriented abstractions that allow direct programming with ASN.1 types in C++. The design and implementation supports the flexible use of different encoding rules through type parameterization of a P-SAP. The advantage is that a variety of encoding forms can be used, such as PER, Huitema's fast encodings, and even XDR for the appropriate subset of ASN.1 types. The ASN.1/C++ components (including a translator) can be used indepently from the rest of OOSI and are ideally suited for applications written in C++ that depend on ASN.1 specified protocols directly over a transport service (e.g., RDA, SNMP, and the WAIS version of Z39.50). Performance data will be provided that demonstrates that this work is suitable for serious application development. In particular, the presentation services improve dramatically on ISODE. The potential for realizing presentation pipelining, as advocated by David Clark, will also be discussed in the context of the OOSI framework. From rem-conf-request@es.net Fri Oct 22 12:14:28 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <29796-0@osi-east.es.net>; Fri, 22 Oct 1993 09:03:59 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 22 Oct 1993 17:03:51 +0100 To: rem-conf@es.net Subject: mbone jam? Date: Fri, 22 Oct 93 17:03:47 +0100 From: Jon Crowcroft we have radio free vat (of dubious legaility or use:-) anyone want to try for the mbone live music? should we book an sd session (mor ethan one for different tastes?)? jon From rem-conf-request@es.net Fri Oct 22 14:45:04 1993 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <02916-0@osi-east.es.net>; Fri, 22 Oct 1993 11:35:25 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA11567; Fri, 22 Oct 93 11:35:23 PDT Date: Fri, 22 Oct 93 11:35:23 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9310221835.AA11567@viipuri.nersc.gov> To: mbone@isi.edu, ccoprmm@oit.gatech.edu Subject: Re: Does anyone know if Sun's new video board and xil libraries will work? Cc: rem-conf@es.net > Sun is supposed to be comming out with a new videoboard soon that > comes with a set of "xil" video libraries. Does anyone know if these > libraries and the card will work with nv? If not, any idea how hard it might > be to add it? > > I suppose the question might be rephrased as: Will nv work with the SunVideo card AND XIL? Here's some information on SunVideo that I got from our friendly Sun salesrep: -----------------------------cut here------------------------------------- WORLDWIDE PRODUCT ANNOUNCEMENT INFORMATION New Video and Multimedia Products SECTION I PRODUCT HIGHLIGHTS ------------------ *********************************************************************** * * * 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 III U.S. PRICING AND ORDERING INFORMATION ------------------------------------- THE FOLLOWING APPEARS IN BOTH THE END USER AND RESELLER PRICE LIST 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 X487A-UK $1895 A N/C X487A-EU $1895 A N/C UK denotes 220V, 50 Hz, UK power cord and transformer EU denotes 220V, 50 Hz, European power cord and transformer THE FOLLOWING APPEAR IN THE END USER PRICE LIST Order Net Discount SunSpectrum Description Number Price Category Silver Price ------------------------------------------------------------------------------- Multimedia Desktops =================== SPARCclassic M -------------- 15-inch Color Monitor, 16-Mbyte Memory, 207-Mbyte-Internal SCSI Disk Quantity 1 Pricing 4/15DC-16-P91 $5,295 N/A $50 4/15DC-16-P91U $5,295 N/A $50 4/15DC-16-P91E $5,295 N/A $50 Quantity 12 Pricing 4/15DC-16-P91-12 $59,940 N/A $595 4/15DC-16-P91U-12 $59,940 N/A $595 4/15DC-16-P91E-12 $59,940 N/A $595 U denotes 220V, 50 Hz, UK power cord and transformer E denotes 220V, 50 Hz, European power cord and transformer THE FOLLOWING APPEARS IN THE RESELLER PRICE LIST Order Net Discount SunSpectrum Description Number Price Category Silver Price ------------------------------------------------------------------------------- Multimedia Desktops =================== SPARCclassic M -------------- 15-inch Color Monitor, 16-Mbyte Memory, 207-Mbyte-Internal SCSI Disk 4/15DC-16-P91-05 $4,196 N/A $50 4/15DC-16-P91U-05 $4,196 N/A $50 4/15DC-16-P91E-05 $4,196 N/A $50 U denotes 220V, 50 Hz, UK power cord and transformer E denotes 220V, 50 Hz, European power cord and transformer THE FOLLOWING APPEAR IN BOTH THE END USER AND RESELLER PRICE LIST Order List Discount SunSpectrum Description Number Price Category Silver Price ------------------------------------------------------------------------------- SPARCstation 10 M ----------------- 16-inch Color Monitor, 4 Mbyte Vsimm, 32-Mbyte, 535-Mbyte-Internal SCSI Disk S10BESX-40-32-P92 $17,095 A $168 S10BESX-40-32-P92U $17,095 A $168 S10BESX-40-32-P92E $17,095 A $168 U denotes 220V, 50 Hz, UK power cord and transformer E denotes 220V, 50 Hz, European power cord and transformer (c) 1993 Sun Microsystems, Inc. Sun, Sun Microsystems, the Sun logo, Sun Microsystems Computer Corporation, SunVideo, Solaris LIVE, IPX, LX, CDware, XIL, and TurboGXplus are trademarks or registered trademarks of Sun Microsystems, Inc. All SPARC trademarks, including the SCD Compliant Logo, are trademarks or registered trademarks of SPARC International, Inc. SPARCclassic, SPARCstation, SPARCserver, and SPARCcenter are licensed exclusively to Sun Microsystems, Inc. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. Hewlett-Packard is a registered trademark of Hewlett-Packard Company. IBM is a registered trademark of International Busniess Machines Corporation. All other product or service names mentioned herein are trademarks of their respective owners. From rem-conf-request@es.net Fri Oct 22 15:24:45 1993 Received: from SKIGO.GRAPHICS.CORNELL.EDU by osi-east.es.net via ESnet SMTP service id <03422-0@osi-east.es.net>; Fri, 22 Oct 1993 12:15:24 +0000 Received: by skigo.graphics.cornell.edu (5.65/DEC-Ultrix/4.3) id AA21735; Fri, 22 Oct 1993 15:14:25 -0400 Message-Id: <9310221914.AA21735@skigo.graphics.cornell.edu> To: mccanne@horse.ee.lbl.gov (Steven McCanne) Cc: rem-conf@es.net, muse@uunet.uu.net, mkc@graphics.cornell.edu Subject: Re: in_pcb.c fix for ultrix 4.3 In-Reply-To: Your message of "Sat, 16 Oct 93 15:17:07 PDT." <9310162217.AA25339@horse.ee.lbl.gov> Date: Fri, 22 Oct 93 15:14:24 -0400 From: Mitch Collinsworth X-Mts: smtp >I've put Van's in_pcb.c fix into Ultrix 4.3 kernel. The file >INPCB.ultrix.tar.Z can be retrieved via anonymous ftp to >ftp.ee.lbl.gov. Source diffs and objects are both included. Could you give a little more info on how to apply this? I have the typical Ultrix binary distribution, so I replaced the existing .o files with the 3 new ones in the tar file and rebuilt the kernel. Previously I had applied the ipmulticast stuff from gregorio:vmtp-ip/ipmulticast-ultrix4.2a-binary.tar and that was working fine. After applying the in_pcb fix I got a kernel that boots ok, but somehow disables NIS. ypbind starts ok, but yp applications give errors stating they can't communicate with ypbind. >Recall that this fix remedies a bug in the 4.3bsd networking >code that would not allow a socket destination to be bound to >a multicast address. As a workaround, vat (and the other conferencing >tools) revert to INADDR_ANY if the multicast bind fails, which >means that conferences sharing the same port are intermixed >(e.g., someone directing a unicast vat at you can appear in your >Mbone Audio session without you knowing they are only unicasting). > >Steve This sounds like the problem uunet's muse code is having on Ultrix. Muse guys, check out this workaround! -Mitch From rem-conf-request@es.net Fri Oct 22 15:55:02 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <03771-0@osi-east.es.net>; Fri, 22 Oct 1993 12:45:19 +0000 Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Fri, 22 Oct 1993 12:45:06 -0700 Date: Fri, 22 Oct 1993 12:44:55 -0700 From: schooler@ISI.EDU Posted-Date: Fri, 22 Oct 1993 12:44:55 -0700 Message-Id: <199310221944.AA17110@elm.isi.edu> Received: by elm.isi.edu (5.65c/4.0.3-4) id ; Fri, 22 Oct 1993 12:44:55 -0700 To: marka@syd.dms.csiro.au, G.Michaelson@cc.uq.oz.au Subject: Re: a new Mbone tool Cc: schooler@ISI.EDU, rem-conf@es.net, casner@ISI.EDU, touch@ISI.EDU This has been fixed. A new tar file can be grabbed from ftp.isi.edu:confctrl/mmcc.tar.Z. Thanks for the feedback, E. >From rem-conf-request@es.net Fri Oct 22 02:12:31 1993 >To: Mark Andrews >Cc: schooler@ISI.EDU, rem-conf@es.net, casner@ISI.EDU, touch@ISI.EDU >Subject: Re: a new Mbone tool >Date: Fri, 22 Oct 1993 16:47:33 +1000 >From: George Michaelson > > It looks interesting from the description. Pity that there are hard > coded paths in it. > > Mark. > > % mmcc > couldn't open "/local/tcl-7.0b2/lib/tk/tclIndex": No such file or directory > % > >One symlink solved this for me. it looks lovely! > >-George > From rem-conf-request@es.net Fri Oct 22 16:25:37 1993 Received: from elxr-fddi.jpl.nasa.gov by osi-east.es.net via ESnet SMTP service id <04297-0@osi-east.es.net>; Fri, 22 Oct 1993 13:21:00 +0000 Received: from localhost.jpl.nasa.gov by elxr.jpl.Nasa.Gov (4.1/SMI-4.1+DXRm2.2) id AA10661; Fri, 22 Oct 93 13:20:21 PDT Message-Id: <9310222020.AA10661@elxr.jpl.Nasa.Gov> To: Jon Crowcroft Cc: vat-radio@elxr.Jpl.Nasa.Gov, rem-conf@es.net Subject: Re: mbone jam? Date: Fri, 22 Oct 1993 13:20:13 -0700 From: Dave Hayes In message <9310221653.AA07041@elxr.jpl.Nasa.Gov>you write: >we have radio free vat (of dubious legaility or use:-) >anyone want to try for the mbone live music? A 19.2k serial PPP connection will not do justice to the jams that go on in my living room. If someone will give me a high speed connection, though... From rem-conf-request@es.net Fri Oct 22 21:08:17 1993 Received: from horse.ee.lbl.gov by osi-east.es.net via ESnet SMTP service id <08472-0@osi-east.es.net>; Fri, 22 Oct 1993 18:01:28 +0000 Received: by horse.ee.lbl.gov for rem-conf@es.net (5.65/1.41) id AA11570; Fri, 22 Oct 93 18:01:24 -0700 From: mccanne@horse.ee.lbl.gov (Steven McCanne) Message-Id: <9310230101.AA11570@horse.ee.lbl.gov> To: rem-conf@es.net, muse@uunet.uu.net Subject: Re: in_pcb.c fix for ultrix 4.3 In-Reply-To: Mitch's message of Fri, 22 Oct 93 15:14:24 -0400. <9310221914.AA21735@skigo.graphics.cornell.edu> Date: Fri, 22 Oct 93 18:01:24 PDT > After applying the in_pcb fix I got a kernel that boots ok, but > somehow disables NIS. ypbind starts ok, but yp applications give errors > stating they can't communicate with ypbind. Unfortunately, the yp library uses a broken test to see if the ypbind process is alive: it tries to bind to the yp port, and if it succeeds, assumes ypbind is dead. E.g., the library relies on the old broken in_pcb implementation. Van had a workaround for this problem in our SunOS kernel, so I've retrofitted it into the Ultrix patches, and put a new INPCB.ultrix.tar.Z on ftp.ee.lbl.gov. Mitch has verified that this fixes his NIS problems. (Thanks, Mitch!) Steve From rem-conf-request@es.net Sat Oct 23 16:18:51 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <12974-0@osi-east.es.net>; Sat, 23 Oct 1993 13:18:13 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Sat, 23 Oct 1993 13:18:09 -0700 Posted-Date: Sat 23 Oct 93 13:17:26 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sat, 23 Oct 93 13:17:27 PDT Date: Sat 23 Oct 93 13:17:26 PDT From: Stephen Casner Subject: New RTP drafts; Agenda for AVT WG To: rem-conf@es.net Message-Id: <751407446.0.CASNER@XFR.ISI.EDU> Mail-System-Version: To the IETF Audio/Video Transport WG and other interested parties: You may have noticed that a new set of drafts for the Real-Time Transport Protocol (RTP) has been issued to the Internet-Drafts repositories. These are the versions for which the official IETF Last Call has been requested, with the following status: draft-ietf-avt-rtp-04.txt, .ps Proposed Standard draft-ietf-avt-profile-03.txt Prototype draft-ietf-avt-issues-01.txt Informational In case you've been wondering what's happened since the completion of the working group last call four weeks ago, we did receive some helpful comments from Andrew Cherenson about points that were unclear in the text. I've been working with Henning to make the spec more clear and explicit; there were a number of edits, but only one functional change, described next. There was a problem, which Andrew and Bill Fenner identified, that the mechanism proposed for allocation of experimental options was insufficient to avoid conflicts among multiple profiles, formats, and application experiments. There would be a similar problem for the items within the SDES option. Based on a suggestions by Andrew and Bill, and after some discussions with these folks, the previous experimental option type range from 64-127 has been segmented as follows: 64-95 profile specific options, defined in profile spec 96-126 format specific options, defined in profile or format spec 127 application specific, distinguished by 32-bit "name"; not officially registered This allows specifications for new profiles and formats to define options without the danger of conflicting with existing registrations. After those specs are complete, additional options can be defined separately and registered with IANA in the Assigned Numbers RFC. See the RTP draft for details. For those of you who may have been waiting for the last round to make comments, this is it! Please review the drafts. There are a couple of formatting errors in the "Issues" draft, and in the RTP spec, the first occurrence of "1970" on page 35 should be "1900". These problems will be fixed along with pagination and any comments that you, other IETF members, or the RFC editor may have during the RFC editing process. Houston IETF Meeting Since the RTP spec is now in the final stages, and the open issues of which I was aware have been resolved, it should not be necessary to have a detailed discussion of the protocol as we have at past meetings. I have only requested a single session this time, in the second afternoon slot on Tuesday, following the MMUSIC WG. I expect this meeting to have a lot of the flavor of the "implementers session" we've had in the last slot at previous meetings. I'd like to get brief reports from implementors again on the progress that's been made and any difficulties found. With the main protocol spec becoming more stable, the focus may fall next to the audio/video profile specification or to new profile specifications. What WG efforts are required in that area? Finally, Don Hoffman has told me that one of the attendees of his IMA Network Focus Group will be able to give a short report of that group's recent meeting so that we can discuss interaction between that group and the IETF AVT and MMUSIC activities. -- Steve Casner Audio/Video Transport WG A G E N D A Tuesday, November 2, 4:00-6:00 - Statement of status of RTP (in "Last Call", I hope), and opportunity for comments to be made on the spec, but no lengthy rehashing of old issues! - Brief presentations on what's been learned from implementations of RTP -- what has been learned that we may need to address in the audio/video profile? - Encoding specifications: Impact of RTP changes on the H.261 spec; getting a JPEG spec defined, others? - In March we had a good discussion about an API for software decoders -- how has the picture changed in 8 months? - Report from the IMA Network Focus Group meeting on interaction with IETF, and specifically how RTP might fit in. - Assess what further WG efforts are needed ------- From rem-conf-request@es.net Sun Oct 24 14:40:54 1993 Received: from galaxy.net.Hawaii.Edu by osi-east.es.net via ESnet SMTP service id <21607-0@osi-east.es.net>; Sun, 24 Oct 1993 11:34:44 +0000 Received: from galaxy.net.Hawaii.Edu ([132.160.3.23]) by galaxy.net.Hawaii.Edu with SMTP id <119655>; Sun, 24 Oct 1993 08:34:21 -1000 Date: Sun, 24 Oct 1993 08:30:10 -1000 From: Winston KC Dang Subject: SEC database being multicasted???? To: rem-conf@es.net In-Reply-To: <9310111024.AA15234@rx7.ee.lbl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the Monday October 25 edition of Investor's Daily, there was a small front page brief saying: The Internet Multicasting Service plans to provide access to the Securities and Exchange Commission's Edgar Database. Does anyone know anything about this? Winston From rem-conf-request@es.net Sun Oct 24 23:40:14 1993 Received: from LNS62.LNS.CORNELL.EDU by osi-east.es.net via ESnet SMTP service id <22335-0@osi-east.es.net>; Sun, 24 Oct 1993 16:47:42 +0000 Received: from LNS62.LNS.CORNELL.EDU by LNS62.LNS.CORNELL.EDU (PMDF V4.2-13 #3448) id <01H4HVRSS1G095MVSE@LNS62.LNS.CORNELL.EDU>; Sun, 24 Oct 1993 15:59:14 EST Date: Sun, 24 Oct 1993 15:59:14 -0500 (EST) From: "Selden E. Ball, Jr." Subject: Re: SEC database being multicasted???? To: wkd@Hawaii.Edu, rem-conf@es.net Message-id: <01H4HVRSTWYQ95MVSE@LNS62.LNS.CORNELL.EDU> X-VMS-To: IN%"wkd@Hawaii.Edu",IN%"rem-conf@es.net" X-VMS-Cc: SEB MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Winston KC Dang recently asked for more infomation about The Internet Multicasting Service making available the SEC's EDGAR database. I am appending an edited version of the article posted recently to the com-priv mailing list. The complete article is available from the source described in the article. I have no relationship to GNN. Selden seb@lns61.tn.cornell.edu ======================== > SEC EDGAR DATABASE TO BE MADE FREELY AVAILABLE > ON INTERNET COMPUTER NETWORK > > (The full text of this release > can be obtained from GNN. For > information on subscribing to > GNN see the end of this release.) > >Thursday, October 21, 1993 >8:00 p.m. (eastern) > >SEBASTOPOL, CA -- The Global Network Navigator, an Internet-based >online resource center, reported this afternoon that the Internet >Multicasting Service, in conjunction with the New York University >Stern School of Business, will be participating in a project to provide >access on the Internet to the Securities and Exchange Commission's >(SEC) EDGAR database. This project is sponsored by the National >Science Foundation. Today's announcement means that the key public >disclosure information contained in EDGAR will, for the first time, >become available to the general public over the global Internet >computer network. > > THE EDGAR DATABASE > > EDGAR is an on-line filing system mandated by the SEC for >America's largest corporations. [...] > HOW TO ACCESS GNN NEWS > >GNN is available for free on a subscription basis. However, you can >access GNN News immediately and subscribe later. If you have a WWW >browser such as Xmosaic, use the following URL to access the GNN News >front page: > > http://nearnet.gnn.com/news/home/news.html > > HOW TO SUBSCRIBE TO GNN > > The Global Network Navigator is available over the Internet >as a free subscription service during its initial launch. To subscribe >to GNN, send email to info@gnn.com. A subscription form and instructions >will automatically be sent back to you. If you have any questions or >comments about GNN, send email to forum@gnn.com and tell us your >thoughts. For information about becoming a GNN sponsor, please send >email to adv@gnn.com. From rem-conf-request@es.net Mon Oct 25 02:17:53 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <23754-0@osi-east.es.net>; Sun, 24 Oct 1993 23:10:47 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Sun, 24 Oct 1993 23:10:41 -0700 Posted-Date: Sun 24 Oct 93 23:09:58 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sun, 24 Oct 93 23:09:59 PDT Date: Sun 24 Oct 93 23:09:58 PDT From: Stephen Casner Subject: Call for Papers: Packet Video To: rem-conf@es.net Message-Id: <751529398.0.CASNER@XFR.ISI.EDU> Mail-System-Version: I would particularly like to encourage those of you working on video over the Internet to notice that area of interest in the following CFP, and to invite your participation. -- Steve Casner ************************************************************************ FIRST CALL FOR PAPERS Sixth International Workshop on PACKET VIDEO September 26-27, 1994 Portland, Oregon, USA The Sixth International Workshop on Packet Video (PV) will be held from September 26 to 27 in Portland, Oregon. It will follow the Picture Coding Symposium (PCS) to be held in Sacramento, California from September 21-23. The objective of the Workshop is to provide a forum for discussion of new and recent results or ideas on video services for packet switched networks, including the applicability of evolving MPEG2 / H.26x video coding standards for such services. In order to preserve its characteristic as a workshop, active participation of the attendees in the meeting is encouraged. Authors are invited to submit a Planning Questionnaire (printed on the reverse side of this Call for Papers) and later on an abstract of 500 words with a Work Description Cover Sheet (to be mailed after receipt of Planning Questionnaire) on recent advances in the field of packet video. Final contributions in the form of a four page extended summary and a 20 minute oral presentation or a poster presentation (based on the Steering Committee Decision) will be required for accepted abstracts. Areas of interest include, but are not limited to: --Video coding for ATM and other packet networks --Video over Internet --Multiplexing and switching of variable bit rate video --Compensation of packet loss and jitter --Privacy and security aspects of packet video --Variable rate video transport with or without priority --Network architecture for real-time video transport --Performance modeling and evaluation --Protocols for packet video --Inter-media synchronization in ATM and Internet networks --New visual services over ATM networks (LAN, MAN, B-ISDN) --Human factors in packet video --Rate control for VBR encoders --Memory architecture for multimedia terminals In submitting a paper, please take into account the following summary of deadlines: November 30, 1993 Planning Questionnaire submission April 15, 1994 Abstract and Work Description Cover Sheet submission (5 copies) May 31, 1994 Notification of acceptance mailed July 15, 1994 Camera ready copy (extended summary) submission General Chairperson: A.Tabatabai, Tektronix, USA Technical Chairperson: A.Reibman, AT&T Bell Laboratories, USA Steering Committee Members: M. Biggar -Telecom Australia -AUS S. Casner -USC/Info. Sciences Inst. -USA L. Chiariglione -CSELT -I J. Y. Cochennec -CNET -F H. Gharavi -Loughborough Univ. -UK J. Guichard -CNET -F G. Morrison -BT Laboratories -UK D. Pearson -Essex University -UK D. Raychaudhuri -NEC -USA R. Shaefer -Heinrich-Hertz Institute -D H. Tominaga -Waseda University -J M. Vetterli -U.C. Berkeley -USA M. Wada -KDD -J L. Zhang -Xerox -USA Planning Questionnaire Sixth International Workshop on PACKET VIDEO September 26-27, 1994 Portland, Oregon, USA If you plan to attend the International Workshop on Packet Video, please complete and return this form immediately to either: Ali Tabatabai General Chairperson Packet Video '94 Steering Committee Tektronix, Inc. P.O. Box 500, Mail Stop 50-370 Beaverton, OR 97077 USA Telephone: (503) 627-1121 Fax: (503) 627-5502 Email: ajt@sail.labs.tek.com Amy Reibman Technical Chairperson Packet Video '94 Steering Committee AT&T Bell Laboratories Room 4E-520 101 Crawford's Corner Rd. Holmdel, NJ 07733-3030 USA Telephone: (908) 949-3470 FAX: (908) 949-3697 Email: reibman@research.att.com in order to receive further information. Name: ____________________________________________________ Title Family Name First Name Affiliation: _____________________________________________ Address: _________________________________________________ _________________________________________________ Country: _________________________________________________ Phone:_____________ Fax:_____________ E-Mail:______________ Please check: I intend to present a paper: __Definitely __Probably I intend to participate only: __Definitely __Probably [end] ------- From rem-conf-request@es.net Mon Oct 25 11:21:00 1993 Received: from munin.fnal.gov by osi-east.es.net via ESnet SMTP service id <26476-0@osi-east.es.net>; Mon, 25 Oct 1993 08:08:41 +0000 Received: from LOCALHOST.fnal.gov by munin.fnal.gov with SMTP id AA17557 (5.65c+/IDA-1.4.4 for rem-conf@es.net); Mon, 25 Oct 1993 10:09:06 -0500 Message-Id: <199310251509.AA17557@munin.fnal.gov> To: rem-conf@es.net Subject: NV for SGI Indy? Date: Mon, 25 Oct 93 10:09:05 -0500 From: Matt Crawford Do some versions of vat and nv support the SGI Indy? _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From rem-conf-request@es.net Mon Oct 25 15:39:14 1993 Received: from zephyr.isi.edu by osi-east.es.net via ESnet SMTP service id <03046-0@osi-east.es.net>; Mon, 25 Oct 1993 12:30:29 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Mon, 25 Oct 1993 12:30:26 -0700 Date: Mon, 25 Oct 1993 12:30:26 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199310251930.AA21006@zephyr.isi.edu> To: rem-conf@es.net, end2end-interest@ISI.EDU Subject: Draft papers of interest to these lists At the Houston IETF meeting, there will be two BOFs concerned with extending the Internet architecture to provide resource reservation, to better support packet voice and video among other things. BOF announcements are appended. In preparation for these BOFs, we have prepared three Internet Drafts: an overview of the architecture, a description of a proposed service model, and an initial specification for a setup protocol RSVP. These drafts have been submitted to CNRI, in hopes they will be in place before the Houston meeting. In any case, the papers are available for anonymous FTP from host ftp.isi.edu, in directory pub/braden/isip/, with file names: overview.ps, .txt service-model.ps, .txt rsvpspec.ps, .txt Bob Braden _______________________________________________________________ BOF: "Real-time Packet Forwarding and Admission Control" [realtime] Schedule: Wednesday November 3, 1930 - 2200 Chair: Bob Braden, USC Information Sciences Institute Speakers: Scott Shenker, Xerox Palo Alto Research Center Dave Clark, MIT Laboratory for Computer Science Summary: The demand for multimedia communication and the success of IETF audio/videocasts are creating an urgent requirement for resource reservation in the Internet, to support 'real-time' applications. To implement resource reservation, we must define an appropriate service model which all routers will satisfy. We must come to an agreement on how to ensure that a heterogeneous set of routers will support the model, regardless of what mechanisms they use. This BOF will present a proposal for a new Internet service model, and discuss how the IETF should go about standardizing it. Scott Shenker and Dave Clark will be the speakers. They plan to address the following topics: A: Why we need a new service model B: A Proposal for a new Integrated Service Model C: How to standardize a service model The BOF will then have open discussion of these topics, intended to lead to the creation of a working group to carry this work forward towards standardization. Two Internet Drafts have been submitted as background for this BOF. "Integrated Services in the Internet Architecture: an Overview", Bob Braden, Dave Clark, and Scott Shenker, draft-braden-realtime-outline.00.ps draft-braden-realtime-outline.00.txt "A Service Model for an Integrated Services Internet", Scott Shenker, Dave Clark, and Lixia Zhang, draft-shenker-realtime-model-00.ps draft-shenker-realtime-model-00.txt BOF: "RSVP -- Resource Reservation Setup Protocol for the Internet" Schedule: Wednesday November 3, 1330 - 1530 Speaker: Bob Braden, USC Information Sciences Institute Summary: If the Internet is to support resource reservation, a reservation setup protocol is required. Work in the End-to-End Research Group of the IRTF has led to the development of a resource reservation setup protocol called RSVP. RSVP is a connectionless ('soft state') protocol that provides receiver-initiated setup for multicast or unicast data flows, with good scaling and robustness properties. This BOF will give an overview of RSVP and propose the formation of a Working Group to further engineer and standardize it. An Internet Draft has been submitted containing a preliminary specification of RSVP: "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", Lixia Zhang, Bob Braden, Deborah Estrin, Shai Herzog, and Sugih Jamin: draft-braden-rsvp-00.ps draft-braden-rsvp-00.txt The basic concepts of RSVP are described in: "RSVP: A New Resource ReSerVation Protocol", Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker, and Daniel Zappala, IEEE Network, September 1993. From rem-conf-request@es.net Mon Oct 25 20:07:36 1993 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <09818-0@osi-east.es.net>; Mon, 25 Oct 1993 16:53:34 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA13537; Mon, 25 Oct 93 16:53:30 PDT Date: Mon, 25 Oct 93 16:53:30 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9310252353.AA13537@viipuri.nersc.gov> To: rem-conf@es.net Subject: ShowMe 2.0: Desktop Video Conferencing Product Cc: dvtf@es.net, rcwg@nic.hep.net, DTSUG@sws1.ctd.ornl.gov On the heels of the SunVideo announcememnt comes a software package that uses it to good advantage. Note that ShowMe 2.0 is "bundled" with the previously announced SunVideo multimedia bundle... ----- Begin Included Message ----- SUNSOLUTIONS UNVEILS INDUSTRY'S FIRST COMPLETE DESKTOP VIDEO CONFERENCING PRODUCT FOR WORKSTATIONS ShowMe 2.0 Offers Video, Audio, Application Sharing and Enhanced Whiteboard Capabilities SunSolutions Announces It Will Support Multiple Platforms MOUNTAIN VIEW, Calif. -- October 25, 1993 -- SunSolutions, the video conferencing and collaboration business of Sun Microsystems, Inc., today introduced ShowMe(TM) 2.0, the industry's first complete, easy-to-use desktop video conferencing solution that enables workstation users to collaborate interactively, in real time, with a full range of video, audio and screen sharing tools. ShowMe 2.0 broadly expands the capabilities of ShowMe 1.1, adding video, audio, application sharing and enhanced whiteboard features to the shared whiteboard facility of the previous version. Users can display, discuss, edit or annotate documents and images, display or send video, and share applications through a graphical user interface that is simple and intuitive. With video, users may see conference participants' gestures and expressions from their desktops just as they would in person. ShowMe 2.0 will ship in December 1993 running on SPARC(R) systems in the SunSoft Solaris(R) operating environment. Versions of ShowMe for Hewlett-Packard and IBM workstations, and for Intel platforms running on Microsoft(R) Windows and Solaris X86 will ship in 1994. "This is breakthrough technology for management," said Michele Parry, general manager of SunSolutions. "With ShowMe, businesses can push through the barriers of traditional communication and exchange information immediately and effectively. Now anything users can communicate in a meeting they can communicate right from the desktop, where they have easy access to their electronic files. The bottom line is that with desktop video conferencing, businesses can get their products and services to market faster, with higher quality results, at a lower cost." ShowMe 2.0 consists of ShowMe Video(TM), ShowMe Audio(TM), ShowMe SharedApp(TM) and ShowMe Whiteboard(TM). The capabilities work together, so customers can take advantage of any or all of them at the same time. ShowMe is based on the Motif(R) graphical user interface and operates on SPARC workstations over TCP/IP networks. ShowMe Video and ShowMe Audio ShowMe Video and ShowMe Audio enable users to hold face-to-face meetings from their desktops, allowing them to collaborate without the need for costly and time-consuming travel. A ShowMe video camera mounted on each user's workstation provides a live, full-color image of each participant, with audio input through SunMicrophone(TM) and output through the workstation's speakers. Users can modify the size of the video window and adjust the sound level through a graphical, easy-to-use menu. Automatic bandwidth allocation lets users adjust the transmission rate to optimize network usage. ShowMe Video also includes a one-way conference feature that supports multicast and allows participants to receive video without a SunVideo(TM) capture/compression SBus card. With video and audio functionality, ShowMe provides a rich communication environment. Users can take advantage of the video capabilities to display objects, such as product prototype models, or documents that are not resident on the system, such as newspaper headlines. In addition, conference participants may view pre-recorded video. ShowMe SharedApp The ShowMe SharedApp software enables multiple users to interact with a live application simultaneously in real time, with participants seeing the same view on their workstation screens. Remote users need not have the application loaded on their workstations in order to participate in the on-line meeting. SPARC systems running Solaris operating environment applications based on the X Window System Version 11 standards work with ShowMe SharedApp. In addition, Microsoft Windows applications supported by SunSelect's Wabi(TM) software are shareable. The ability to share applications increases user productivity in collaborative tasks. For example, an instructor can use ShowMe SharedApp to demonstrate an application remotely to new users, then pass the cursor control and guide students as they practice. With ShowMe SharedApp, a user can demonstrate a problem to customer support personnel and see a solution demonstrated in turn. In another example, engineers can collaborate on a computer-aided design. ShowMe Whiteboard SunSolutions' whiteboard software provides a shared "desktop conference board" that makes it easy for users to simultaneously view and annotate drawings, spreadsheets and other documents. Each user has a separate, personalized on-screen marker that is visible to all participants and can be used to express ideas visually by pointing, gesturing and making annotations as one would in a face-to-face meeting. ShowMe Whiteboard offers a number of enhancements to the shared whiteboard capabilities of ShowMe 1.1. The whiteboard now supports 24-bit images, making it possible to display high-quality graphics; multiple ShowMe Whiteboard sessions can now run on a single SPARC CPU, providing X-terminal support; and the product is based on the Motif graphical user interface for ease of use. With ShowMe Whiteboard, desktop conferencing participants can receive instant feedback and complete projects faster. Workgroups can collaborate in real time to create diagrams, list future action items, edit manuscripts, comment on presentation slides and discuss drawings. Pricing and Availability The ShowMe 2.0 product will be available at the end of 1993 through SunSolutions resellers. The U.S. suggested list price for ShowMe 2.0 is $3,270 for a single right-to-use license, and $8,430 for a three-user RTU license. A video camera and a SunVideo card are included with each license, along with CD media and documentation. An audiographics configuration, which includes ShowMe SharedApp, ShowMe Whiteboard and ShowMe Audio, is available for a U.S. suggested list price of $899 for a single RTU license, $1,650 for a three-user RTU license, $3,750 for a 10-user RTU license, and $26,200 for a 100-user RTU license. About SunSolutions SunSolutions, a business of Sun Microsystems, Inc., is dedicated to designing, developing and marketing video conferencing and collaboration products. The business is headquartered in Mountain View, Calif., USA with a European office in Bagshot, U.K. # # # # Sun Microsystems, Sun, the Sun logo, SunSolutions, the SunSolutions logo, SunSelect, the SunSelect logo, Sun Microsystems Computer Corporation, the Sun Microsystems Computer Corporation logo, SunExpress, the SunExpress logo, ShowMe, ShowMe Whiteboard, ShowMe Video, ShowMe Audio, ShowMe SharedApp, Solaris, SunMicrophone, SunVideo and Wabi are trademarks or registered trademarks of Sun Microsystems, Inc. All SPARC trademarks are trademarks or registered trademarks of SPARC International, Inc. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. Microsoft is a registered trademark of Microsoft Corporation. Motif is a registered trademark of Hewlett Packard Corporation. All other products or services mentioned herein are trademarks of their respective owners. ----- End Included Message ----- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ari Ollikainen ari@es.net National Energy Research Supercomputer Center ESnet (Energy Sciences Network) Lawrence Livermore National Laboratory 510-423-5962 FAX:510-423-8744 P.O. BOX 5509, MS L-561, Livermore, CA 94550 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Tue Oct 26 01:39:16 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <16807-0@osi-east.es.net>; Mon, 25 Oct 1993 22:32:35 +0000 Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Mon, 25 Oct 1993 22:32:33 -0700 Date: Mon, 25 Oct 1993 22:32:27 -0700 From: schooler@ISI.EDU Posted-Date: Mon, 25 Oct 1993 22:32:27 -0700 Message-Id: <199310260532.AA03890@elm.isi.edu> Received: by elm.isi.edu (5.65c/4.0.3-4) id ; Mon, 25 Oct 1993 22:32:27 -0700 To: rem-conf@es.net Subject: Bootstrapping mmcc Cc: casner@ISI.EDU, schooler@ISI.EDU, touch@ISI.EDU I've had a few requests about bootstrapping the recently-released mmcc tool -- basically, how can a user find other users' addresses. Several folks have suggested using the user@hostname entry in the MBone Audio window, however these values are overwritten if the user supplies his or her own alias. Soooo, if you are willing to make your user@hostname address known to the rest of the world, please send a PRIVATE e-mail message to that has a Subject line "Add to .mmccrc". The message should be in .mmccrc format. For example: "Daffy Duck" dduck toons.animation.disney.com The fields represent your user alias, your login id, and the host name or address at which you will run mmcc; optionally a fourth field may be given that specifies a port at which the program should listen (if it is a non-standard port). I will create a PUBLIC .mmccrc file ftp.isi.edu:confctrl/.mmccrc to store these entries. An e-mail message to me with the Subject line "Delete from .mmccrc" will remove you from the file. Of course, the more interesting way of doing dynamic user registration is through multicast addressing, but that didn't make it into this release.... Thanks, Eve Eve M. Schooler USC/Information Sciences Institute Voice: 310-822-1511, x114 4676 Admiralty Way FAX: 310-823-6714 Marina del Rey, CA 90292 E-mail: schooler@isi.edu From rem-conf-request@es.net Tue Oct 26 17:04:17 1993 Received: from sled-f.gsfc.nasa.gov by osi-east.es.net via ESnet SMTP service id <28902-0@osi-east.es.net>; Tue, 26 Oct 1993 13:45:59 +0000 Received: by sled.gsfc.nasa.gov (4.1/1.35) id AA00353; Tue, 26 Oct 93 16:45:56 EDT From: rogers@sled.gsfc.nasa.gov (Scott W. Rogers) Message-Id: <9310262045.AA00353@sled.gsfc.nasa.gov> Subject: NASA Select won't be sent during the IETF. To: rem-conf@es.net, mbone@isi.edu Date: Tue, 26 Oct 1993 16:45:56 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 684 I will be stopping the NASA Select feed over the MBONE during the IETF Multicast whether the Shuttle is still in orbit or not. Please everyone, do not start it back up, they will need the bandwidth and NASA doesn't need to be know for hogging the network. If a scheduled or delayed landing occurs during a break in the IETF I will try to transmit it, otherwise I defer to the IETF. -- -------------------------------------------------------------------------- Scott W. Rogers +1-301-286-1377 Computer Networking Branch --- Code 933 ---- Greenbelt, MD 20771 NASA Goddard Space Flight Center FAX: 301-286-1777 From rem-conf-request@es.net Tue Oct 26 17:56:05 1993 Received: from bridge2.NSD.3Com.COM by osi-east.es.net via ESnet SMTP service id <00261-0@osi-east.es.net>; Tue, 26 Oct 1993 14:47:57 +0000 Received: from himalayan.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA29750 (5.65c/IDA-1.4.4nsd for ); Tue, 26 Oct 1993 14:47:56 -0700 Received: by himalayan.NSD.3Com.COM id AA01114 (5.65c/IDA-1.4.4-910725 for rem-conf@es.net); Tue, 26 Oct 1993 14:47:50 -0700 From: Pyda Srisuresh Message-Id: <199310262147.AA01114@himalayan.NSD.3Com.COM> Subject: Voice data compression To: rem-conf@es.net Date: Tue, 26 Oct 93 14:47:49 PDT Cc: suresh@NSD.3Com.COM (Pyda Srisuresh) X-Mailer: ELM [version 2.3 PL11] Sorry, I forgot to mention my e-maill address. It is: suresh@3com.com Thanks. - suresh (suresh@3com.com) ---------------------------------------------------------------------------- Hi, I would appreciate if someone would let me know the following information. 1. How much memory space would I need to store an hour of voice message? I will need to store a day's worth of voice in memory at a time. Can you suggest some equipment that is cost effective and converts voice to digital data? What kind of computing environments (i.e., PC, SUN, mainframe etc..) do these equipments run on? 2. Are there any data compression techniques that are available in hardware or software to transmit the digital data on 64Kbps serial line? I would appreciate compression techniques for data storage as well as for data transfer. Thanks. - suresh (suresh@3com.com) From rem-conf-request@es.net Tue Oct 26 18:14:55 1993 Received: from bridge2.NSD.3Com.COM by osi-east.es.net via ESnet SMTP service id <00200-0@osi-east.es.net>; Tue, 26 Oct 1993 14:44:52 +0000 Received: from himalayan.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA29691 (5.65c/IDA-1.4.4nsd for ); Tue, 26 Oct 1993 14:44:46 -0700 Received: by himalayan.NSD.3Com.COM id AA01102 (5.65c/IDA-1.4.4-910725 for rem-conf@es.net); Tue, 26 Oct 1993 14:44:45 -0700 From: Pyda Srisuresh Message-Id: <199310262144.AA01102@himalayan.NSD.3Com.COM> Subject: Voice data compression To: rem-conf@es.net Date: Tue, 26 Oct 93 14:44:38 PDT Cc: suresh@NSD.3Com.COM (Pyda Srisuresh) X-Mailer: ELM [version 2.3 PL11] Hi, I would appreciate if someone would let me know the following information. 1. How much memory space would I need to store an hour of voice message? I will need to store a day's worth of voice in memory at a time. Can you suggest some equipment that is cost effective and converts voice to digital data? What kind of computing environments (i.e., PC, SUN, mainframe etc..) do these equipments run on? 2. Are there any data compression techniques that are available in hardware or software to transmit the digital data on 64Kbps serial line? I would appreciate compression techniques for data storage as well as for data transfer. Thanks. - suresh From rem-conf-request@es.net Wed Oct 27 00:30:04 1993 Received: from cambium.uoregon.edu by osi-east.es.net via ESnet SMTP service id <28871-0@osi-east.es.net>; Tue, 26 Oct 1993 13:43:55 +0000 Received: from localhost (meyer@localhost) by cambium.uoregon.edu (8.6.3/8.6) id NAA00042; Tue, 26 Oct 1993 13:41:55 -0700 Date: Tue, 26 Oct 1993 13:41:55 -0700 From: "David M. Meyer 503/346-1747" Message-Id: <199310262041.NAA00042@cambium.uoregon.edu> To: mbone@isi.edu, rem-conf@es.net Subject: Solaris 2.2 as a mrouter [was Re: Solaris, and How Multiple MBone recipients on same LAN] Steve has asked me to post an update to our information regarding running MBONE applications on Solaris 2.x. For Solaris 2.2, the applications (e.g., nv, vat, etc) run fine on the "out of the box" kernel (and in particular, the /kernel/drv/ip module). However, if you want to use your Solaris 2.2 machine to run mrouted, you need Erik Nordmark's /kernel/drv/ip, which can be found on ftp.uoregon.edu in pub/Solaris2.x/MBONE/binaries (the file is called ip; there is a startup file, S69mrouted, there as well). The patch was neccessary to allow non-srcrt tunnels. Erik says that his modifications made Solaris 2.3, so you will be able to use the distributed 2.3 /kernel/drv/ip. Finally, I believe that this might be available on playground.sun.com (although I can't find it right now...). playground.sun.com also has Solaris 2.x versions of the vidiopix libraries (so, you can build a native nv). There are also Solaris native versions of various MBONE applications on ftp.uoregon.edu:pub/Solaris2.x/binaries, including mrouted, ivs, and nv (ivs and nv are linked against X11R5; there is an openwindows version of nv in nv.openwindows). Please let me know if you have any questions about this stuff. Thanks, Dave David M. Meyer Voice: 503/346-1747 Senior Network Engineer Pager: 503/342-9458 Office of University Computing FAX: 503/346-4397 Computing Center Internet: meyer@ns.uoregon.edu University of Oregon 1225 Kincaid Eugene, OR 97403 From rem-conf-request@es.net Wed Oct 27 04:13:50 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <05027-0@osi-east.es.net>; Wed, 27 Oct 1993 01:05:28 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 27 Oct 1993 08:03:34 +0000 To: Pyda Srisure cc: rem-conf@es.net Subject: Re: Voice data compression In-reply-to: Your message of "Tue, 26 Oct 93 14:44:38 PDT." <199310262144.AA01102@himalayan.NSD.3Com.COM> Date: Wed, 27 Oct 93 08:03:27 +0000 From: Jon Crowcroft > 1. How much memory space would I need to store an hour of voice message? > I will need to store a day's worth of voice in memory at a time. > Can you suggest some equipment that is cost effective and converts voice > to digital data? What kind of computing environments (i.e., PC, SUN, > mainframe etc..) do these equipments run on? Sun, PCM coded at 64kbps => 8 * 60 * 60 kbytes per hour or 29Mbytes per hour... any trvial compression more than halves this. heavy (LPC 4?), divides by around 4-5, so... > > 2. Are there any data compression techniques that are available in > hardware or software to transmit the digital data on 64Kbps serial > line? I would appreciate compression techniques for data storage > as well as for data transfer. see the vat-record programs.... jon p.s. that will be 3 dollars and 4 cents please... From rem-conf-request@es.net Wed Oct 27 14:34:37 1993 Received: from zephyr.isi.edu by osi-east.es.net via ESnet SMTP service id <10376-0@osi-east.es.net>; Wed, 27 Oct 1993 11:26:40 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Wed, 27 Oct 1993 11:26:32 -0700 Date: Wed, 27 Oct 1993 11:26:32 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199310271826.AA07211@zephyr.isi.edu> To: rem-conf@es.net, end2end-interest@ISI.EDU Subject: Corrected service model draft Cc: shenker@parc.xerox.com, braden@ISI.EDU When I was little, they told me, "Haste makes waste". I guess I never got the message... The file service-model.ps as originally posted here for anonymous FTP, and as distributed in the Internet-Draft repositories today. was lacking three figures and it had a couple of mysteriously truncated lines. The correct version was installed yesterday (Tuesday) morning on host ftp.isi.edu under pub/braden/isip/service-model.ps. It's not clear you really NEED the pictures, but in case you want them, you get get the revised version. Sorry for the screwup;it was a Sunday-afternoon mis-communication between Scott Shenker and myself. Bob Braden From rem-conf-request@es.net Wed Oct 27 18:26:35 1993 Received: from ucsd.edu by osi-east.es.net via ESnet SMTP service id <13738-0@osi-east.es.net>; Wed, 27 Oct 1993 15:19:56 +0000 Received: from deadone by ucsd.edu; id PAA22216 sendmail 8.6.3/UCSD-2.2-sun via SMTP Wed, 27 Oct 1993 15:19:52 -0700 Received: by deadone (5.0/UCSDPSEUDO.4) id AA04738 for larry.wake@west.sun.com; Wed, 27 Oct 93 15:19:49 PDT Date: Wed, 27 Oct 93 15:19:49 PDT From: hidley@de.UCSD.EDU (greg hidley) Message-Id: <9310272219.AA04738@deadone> To: mbone@isi.edu, rem-conf@es.net Subject: Difficulties tunneling into Solaris 2.2 ... Cc: hidley@de.UCSD.EDU, larry.wake@west.sun.com X-Sun-Charset: US-ASCII content-length: 2391 I am trying to get a tunnel into my Sun SS2 ("deadone.ucsd.edu") running Solaris 2.2 but am having some trouble getting things setup. If any of you have gotten past this on a 2.2 machine I would appreciate any pointers you could give me. I am running the generic Sun kernel with Version 2.0 of mrouted and the following mrouted.conf lines: phyint 132.239.18.8 tunnel 132.239.18.8 132.239.1.4 metric 5 threshold 8 132.239.18.8 is my machine. I am being fed by another Sun running 4.1.x. The link to the other Sun is over ethernet and fiber ... deadone# traceroute 132.239.1.4 traceroute to 132.239.1.4 (132.239.1.4), 30 hops max, 40 byte packets 1 ebu1-bb-gw.ucsd.edu (132.239.8.62) 71 ms 39 ms 55 ms 2 muir-gw-fddi.ucsd.edu (132.239.254.238) 162 ms 13 ms 14 ms 3 nothing.ucsd.edu (132.239.1.4) 15 ms 3 ms 3 ms deadone# /etc/mrouted -d debug level 2 mrouted version 2.0 installing le0 (132.239.18.8 on subnet 132.239) as vif #0 warning - unnecessary tunnel remote address 132.239.1.4 in /etc/mrouted.conf, can't forward: only one enabled vif deadone# netstat -M Virtual Interface Table Vif Threshold Local-Address Remote-Address Groups Multicast Routing Table Origin-Subnet In-Vif Out-Vifs deadone# ifconfig le0 le0: flags=863 mtu 1500 inet 132.239.18.8 netmask ffff0000 broadcast 132.239.255.255 ether 8:0:20:f:f:1a deadone# netstat -r Routing Table: Destination Gateway Flags Ref Use Interface -------------------- -------------------- ----- ----- ------ --------- localhost localhost UH 0 1604 lo0 132.239.0.0 deadone.ucsd.edu U 3 1456 le0 224.0.0.0 deadone.ucsd.edu U 3 0 le0 default ebu1-bb-gw.ucsd.edu UG 0 80 The error message seems to imply that I might need an addition vif configured but I am not sure how to do that. "sd" is not showing the reception of any communications yet my feeder assures me audio and video is going out over the tunnel. Thanks again for any assistance. greg Greg Hidley Director Engineering Computing School of Engineering, MC-0403 University of California, San Diego La Jolla, CA. 92093 (619) 534-5775 Bitnet: hidley@ucsd Internet: hidley@ucsd.edu UUCP: ucsd!hidley From rem-conf-request@es.net Wed Oct 27 18:50:41 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <14750-0@osi-east.es.net>; Wed, 27 Oct 1993 15:44:01 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Wed, 27 Oct 1993 15:43:57 -0700 Posted-Date: Wed 27 Oct 93 15:43:06 PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 27 Oct 93 15:43:07 PDT Date: Wed 27 Oct 93 15:43:06 PDT From: Stephen Casner Subject: Re: Difficulties tunneling into Solaris 2.2 ... To: hidley@de.ucsd.edu, MBONE@ISI.EDU, rem-conf@es.net Cc: larry.wake@west.sun.com Message-Id: <751761786.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9310272219.AA04738@deadone> Mail-System-Version: The problem is that you are trying to forward between two subnets of 132.239, but you have not configured your interface to be subnetted (your mask is ffff0000): le0: flags=863 mtu 1500 inet 132.239.18.8 netmask ffff0000 broadcast 132.239.255.255 ether 8:0:20:f:f:1a Therefore, mrouted thinks both the addresses you gave it in the tunnel command are on the same network, so there's no need for the tunnel. Also, did you put in the patch to Solaris 2.2 to allow encapsulated tunnels, as mentioned in David Meyer's message to the mbone and rem-conf lists yesterday? -- Steve ------- From rem-conf-request@es.net Wed Oct 27 19:59:02 1993 Received: from santiam.CS.ORST.EDU by osi-east.es.net via ESnet SMTP service id <15762-0@osi-east.es.net>; Wed, 27 Oct 1993 16:49:50 +0000 Received: from trillium.CS.ORST.EDU by santiam.CS.ORST.EDU (1.37.109.4/1.15) id AA23434; Wed, 27 Oct 93 16:43:48 -0700 Message-Id: <9310272343.AA23434@santiam.CS.ORST.EDU> To: rem-conf@es.net, mbone@isi.edu Subject: Super Computing 93 Conference on MBONE Reply-To: sechrest@cs.orst.edu Date: Wed, 27 Oct 1993 16:50:18 -0700 From: (John Sechrest) sechrest We have been discussing putting parts of the Super Computer 93 conference out on to the MBONE for the dates of 11/16 at 8:30 am PST to 11/18 at 4:00. We are currently working out the schedule of what we would broadcast. Does anyone see problems with this broadcast? ------- John Sechrest . Internet: sechrest@cs.orst.edu Technical Director . UUCP: hplabs!hp-pcd!orstcs!sechrest Computer Science Dept . Oregon State University . Corvallis,Oregon 97331 . (503) 737-3273 . From rem-conf-request@es.net Wed Oct 27 21:19:35 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <17264-0@osi-east.es.net>; Wed, 27 Oct 1993 18:11:31 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12269>; Wed, 27 Oct 1993 18:11:07 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 27 Oct 1993 18:11:02 -0700 To: rem-conf@es.net, mbone@isi.edu Subject: Xerox PARC Forum, Thu, Oct 28 -- Mark Weiser, "Ubiquitous Computing" Date: Wed, 27 Oct 1993 18:10:54 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Oct27.181102pdt.12171@skylark.parc.xerox.com> The following seminar will be 'cast on the MBone, using the same TTL scope as IETF Channel 2. It is advertised in 'sd' with the following parameters: Xerox PARC Forum - Audio pcm 224.2.248.152, port 53826, id 12617, ttl 159 Xerox PARC Forum - Video nv 224.2.248.152, port 49991, id 65362, ttl 95 (Note that these parameters are different than previous PARC Forum 'casts.) Thursday, October 28, 1993 4:00 P.M. Pacific Daylight Time (2300 GMT) PARC Auditorium "Ubiquitous Computing" Mark Weiser, Manager, Xerox PARC Computer Science Laboratory Inspired by the social scientists, philosophers, and anthropologists at PARC, we have been trying to take a radical look at what computing and networking ought to be like. We believe that people live through their practices and tacit knowledge so that the most powerful things are those that are effectively invisible in use. This is a challenge that affects all of computer science. Our preliminary approach: Activate the world. Provide hundreds of wireless computing devices per person per office, of all scales (from 1" displays to wall sized). This has required new work in operating systems, user interfaces, networks, wireless, displays, and many other areas. We call our work "ubiquitous computing". This is different from PDAs, dynabooks, or information at your fingertips. It is invisible, everywhere computing that does not live on a personal device of any sort, but is in the woodwork everywhere. In this talk I'll describe what is wrong with existing approaches to computing, why ubiquitous computing is inevitable, and some of the things we have learned from our research. Host: Kathy Jarvis/PARC Information Center ------------------------ From rem-conf-request@es.net Wed Oct 27 21:32:18 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <17390-0@osi-east.es.net>; Wed, 27 Oct 1993 18:24:40 +0000 Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Wed, 27 Oct 1993 18:24:26 -0700 Date: Wed, 27 Oct 1993 18:24:20 -0700 From: schooler@ISI.EDU Posted-Date: Wed, 27 Oct 1993 18:24:20 -0700 Message-Id: <199310280124.AA06212@elm.isi.edu> Received: by elm.isi.edu (5.65c/4.0.3-4) id ; Wed, 27 Oct 1993 18:24:20 -0700 To: rem-conf@es.net Subject: Re: new MBone tool Cc: schooler@ISI.EDU, casner@ISI.EDU, touch@ISI.EDU There's a new incremental release of mmcc, and a new tar file ftp.isi.edu:confctrl/mmcc.tar.Z (always a symbolic link to the latest tarfile). Excerpts from the CHANGES file: v.51alpha - Wed Oct 27 1993 - fixed bug with "Same" scope being set to ttl of 0 for Groupware - changed libraries included in dynamic and static versions - more complete alias and addr info included in REPLY REQUEST pop-up - established ftp.isi.edu:confctrl/.mmccrc - updated documentation re unicast vs multicast addressing E. From rem-conf-request@es.net Wed Oct 27 23:54:51 1993 Received: from 129.10.10.50 by osi-east.es.net via ESnet SMTP service id <18527-0@osi-east.es.net>; Wed, 27 Oct 1993 20:47:13 +0000 Received: from orodruin.ccs.neu.edu by amber.ccs.neu.edu (4.1/SMI-4.1) id AA29674; Wed, 27 Oct 93 23:46:21 EDT Received: from localhost.ccs.neu.edu by orodruin.ccs.neu.edu (4.1/SMI-4.1) id AA13009; Wed, 27 Oct 93 23:46:20 EDT Message-Id: <9310280346.AA13009@orodruin.ccs.neu.edu> To: sechrest@cs.orst.edu Cc: rem-conf@es.net, mbone@isi.edu Subject: Re: Super Computing 93 Conference on MBONE In-Reply-To: Your message of "Wed, 27 Oct 93 16:50:18 PDT." <9310272343.AA23434@santiam.CS.ORST.EDU> X-Face: *'zZ/"yTt9-uu_!FVf9w02sU9"h^d<3'$v#E"nI\{|he"A%JggYOD5h#j(-~[9WssZNwoJE bpkSH'PF';RxPQ"H:6LW5$OZU1!oEq>vZ'TqM:T!kLA@4CqSgZ'#9Tw.Gx7ONs)9D(R" Date: Wed, 27 Oct 93 23:46:19 -0400 From: Ivan R Judson We have also been working on doing this at Argonne, the idea being we are useing wireless ethernet to be mobile throughout the conference. I am more than willing to schedule times that aren't going to conflict with you. Does this seem reasonable? ............................................................................... Ivan R. Judson | ivan@ccs.neu.edu Northeastern University | judson@mcs.anl.gov Experimental Systems Group | ivan@scout.lcs.mit.edu From rem-conf-request@es.net Thu Oct 28 03:48:14 1993 Received: from jarrah.itd.adelaide.edu.au by osi-east.es.net via ESnet SMTP service id <20271-0@osi-east.es.net>; Thu, 28 Oct 1993 00:38:06 +0000 Received: by jarrah.itd.adelaide.edu.au with SMTP (5.61+IDA+MU/UA-5.28) id AA23876; Thu, 28 Oct 1993 17:07:28 +0930 Message-Id: <9310280737.AA23876@jarrah.itd.adelaide.edu.au> To: schooler@ISI.EDU Cc: rem-conf@es.net, casner@ISI.EDU, touch@ISI.EDU Subject: Re: new MBone tool In-Reply-To: Your message of "Wed, 27 Oct 1993 18:24:20 MST." <199310280124.AA06212@elm.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 28 Oct 1993 17:07:27 +0930 From: Mark Prior There's a new incremental release of mmcc, and a new tar file ftp.isi.edu:confctrl/mmcc.tar.Z (always a symbolic link to the latest tarfile). Excerpts from the CHANGES file: Just to let you know (and the people on rem-conf in Australia), I am mirroring the mmcc kits on ftp.adelaide.edu.au in the pub/av/mmcc directory. I am trying to collect all the useful stuff in one place :-) Mark. From rem-conf-request@es.net Thu Oct 28 13:27:58 1993 Received: from nervm.nerdc.ufl.edu by osi-east.es.net via ESnet SMTP service id <25181-0@osi-east.es.net>; Thu, 28 Oct 1993 10:27:21 +0000 Received: from charon.cba.ufl.edu by nervm.nerdc.ufl.edu (IBM VM SMTP V2R2) with TCP; Thu, 28 Oct 93 13:27:38 EDT Received: From CHIP/WORKQUEUE by charon.cba.ufl.edu via Charon 3.4 with IPX id 100.931028132619.384; 28 Oct 93 13:26:32 -0500 Message-ID: To: rem-conf@es.net From: "RICHARD H. HUGHES" Date: Thu, 28 Oct 1993 13:26:10 EST Subject: Unsubscribe X-pmrqc: 1 Return-receipt-to: "RICHARD H. HUGHES" Priority: normal X-mailer: WinPMail v1.0 (R2) From rem-conf-request@es.net Thu Oct 28 13:48:42 1993 Received: from han.hana.nm.kr by osi-east.es.net via ESnet SMTP service id <25475-0@osi-east.es.net>; Thu, 28 Oct 1993 10:38:47 +0000 Received: from mani.kaist.ac.kr ([192.104.15.2]) by han.hana.nm.kr (4.1/KUM-0.1) id AA07835; Fri, 29 Oct 93 02:38:58 KST Received: by mani.kaist.ac.kr (4.1/SMI-4.1) id AA21422; Fri, 29 Oct 93 02:41:38 KST From: krkang@mani.kaist.ac.kr (Kyungran Kang) Message-Id: <9310281741.AA21422@mani.kaist.ac.kr> Errors-To: Postmaster@mani.kaist.ac.kr Subject: Re: Xerox PARC Forum, Thu, Oct 28 -- Mark Weiser, "Ubiquitous Computing" To: deering@parc.xerox.com (Steve Deering) Date: Fri, 29 Oct 93 2:41:37 KST Cc: rem-conf@es.net In-Reply-To: <93Oct27.181102pdt.12171@skylark.parc.xerox.com>; from "Steve Deering" at Oct 27, 93 6:10 pm X-Mailer: ELM [version 2.3 PL11] Dear sir. I can't see the ad in my sd. ;( My host is in Korea. Hosts in Korea receive IP multicast packets from 192.52.195.241(mbone.nsi.nasa.gov). I'd like to listen the Forum. Please help me reach the Forum. Thanks in advance. (Steve Deering) writes: > > The following seminar will be 'cast on the MBone, using the same TTL scope > as IETF Channel 2. It is advertised in 'sd' with the following parameters: > > Xerox PARC Forum - Audio pcm 224.2.248.152, port 53826, id 12617, ttl 159 > Xerox PARC Forum - Video nv 224.2.248.152, port 49991, id 65362, ttl 95 > > (Note that these parameters are different than previous PARC Forum 'casts.) +----------------------------------------------------+ | Kang, Kyungran : krkang@cosmos.kaist.ac.kr | | | | Tel. : +82-42-869-3554 Fax. : +82-2-869-8700 | | | | System Architecture Lab. | | Computer Science Department, KAIST, KOREA | +----------------------------------------------------+ From rem-conf-request@es.net Thu Oct 28 15:34:51 1993 Received: from sun2.nsfnet-relay.ac.uk by osi-east.es.net via ESnet SMTP service id <02320-0@osi-east.es.net>; Thu, 28 Oct 1993 12:25:57 +0000 Via: uk.ac.birmingham.computer-science; Thu, 28 Oct 1993 18:50:00 +0000 Received: from pooh.cs.bham.ac.uk by percy.cs.bham.ac.uk with SMTP (PP) id <16656-0@percy.cs.bham.ac.uk>; Thu, 28 Oct 1993 18:49:36 +0000 Received: by pooh.cs.bham.ac.uk (4.1/client/1.2) id AA13624; Thu, 28 Oct 93 18:49:37 GMT Date: Thu, 28 Oct 93 18:49:37 GMT From: M.A.Swaby-SE0@computer-science.birmingham.ac.uk Message-Id: <13624.9310281849@pooh.cs.bham.ac.uk> To: rem-conf@es.net Subject: Suggestions wanted for project Hi, I'm Mike Swaby, a software engineering student at The University of Birmingham, UK. I've been looking at multimedia conferencing systems with a view to carrying out a software project. I can't use tools such as sd,vat and ivs etc. because our Sun workstations run SunOS 4.1.3 without IP Multicast extensions and I can't persuade my sysadmin to install them. Are there any versions of the standard tools available that do not require multicast kernal extensions ? Also, I would be very interested to hear from anybody who could suggest an original multimedia conferencing related project that would take me around 4-6 months to complete. I would of course be happy to make available the results of any work that I carry out. Thanks, Mike. --------------------------------------------------------------------------- | Mike Swaby | | | School of Computer Science | "and the Sultans played creole..." | | University of Birmingham | --Dire Straits | | UK | | --------------------------------------------------------------------------- From rem-conf-request@es.net Thu Oct 28 16:44:23 1993 Received: from gumby.dsd.TRW.COM by osi-east.es.net via ESnet SMTP service id <03663-0@osi-east.es.net>; Thu, 28 Oct 1993 13:34:27 +0000 Received: from localhost.sp.TRW.COM by gumby.dsd.TRW.COM (4.1/SMI-4.1) id AA29916; Thu, 28 Oct 93 13:34:25 PDT Message-Id: <9310282034.AA29916@gumby.dsd.TRW.COM> To: rem-conf@es.net Subject: IP Multicasting w/ DNI (?) Date: Thu, 28 Oct 93 13:34:24 -0700 From: Dan Molinelli hi, i installed IP Multicasting on one of SS10s. we have Sunlink DNI running on it also (DECnet Phase IV). we noticed that with the multicast kernel we can no longer see DECnet multicasts. looks like the kernel ONLY recognizes IP Multicasts!?!? is this true? someone else has this problem? thanks dan Daniel Molinelli (310) 812-2161 TRW Space and Electronics Group, Communications Services moline@gumby.dsd.TRW.COM (Internet) From rem-conf-request@es.net Thu Oct 28 17:42:35 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <04543-0@osi-east.es.net>; Thu, 28 Oct 1993 14:31:54 +0000 Received: from Dove.Parc.Xerox.xns by alpha.xerox.com via XNS id <11699>; Thu, 28 Oct 1993 14:31:33 PDT X-NS-Transport-ID: 0000AA0066996F28307D Date: Thu, 28 Oct 1993 14:30:46 PDT Sender: Daniel_C._Swinehart.PARC@xerox.com From: Dan_Swinehart.PARC@xerox.com Subject: Re: Suggestions wanted for project In-Reply-to: "M.A.Swaby-SE0%computer-science.birmingha:uk's message of Thu, 28 Oct 1993 11:49:37 PDT" To: M.A.Swaby-SE0@computer-science.birmingha.uk cc: rem-conf@es.net Message-Id: <93Oct28.143133pdt.11699@alpha.xerox.com> Send us the E-Mail addresses of your system administrator and of the chairman of your department and we'll all encourage them to get on the stick and move with the times. It doesn't make any sense to pursue a project in the area you've mentioned without beginning with tools as close to the state of the art as you can achieve. I wouldn't have any advice for you that didn't first suggest dealing successfully with this problem, since clearly multicast is one of the basic building blocks of any IP-based approach to these applications. I think by now we can be confident that these extensions are reasonable. Universities are supposed to be part of the solution, not part of the problem. I'd treat this is a high-order component of my problem, if I were you. Seriously, I'm willing to send the appropriately polite shame-on-you message if you'd like. But I'd think the best path to your system administrator is through your faculty. If they don't see the necessity, or haven't got the clout to get past the bureaucrats, then perhaps you have bigger problems to deal with. regards, Dan Swinehart Principal Scientist Computer Science Laboratory Xerox Palo Alto Research Center P.S. You could do multicast experiments on a single Ethernet segment without any multicast routers or tunnel routers in your environment. Presumably the tools would work in such a local environment without needing the multicast extensions. But maybe they count on being able to call on the new sysem routines provided by these extensions? I'm not an expert at this level. From rem-conf-request@es.net Thu Oct 28 18:38:40 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <04619-0@osi-east.es.net>; Thu, 28 Oct 1993 14:36:24 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11699>; Thu, 28 Oct 1993 14:35:36 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 28 Oct 1993 14:35:28 -0700 To: krkang@mani.kaist.ac.kr (Kyungran Kang) Cc: rem-conf@es.net Subject: Re: Xerox PARC Forum, Thu, Oct 28 -- Mark Weiser, "Ubiquitous Computing" In-reply-to: Your message of "Thu, 28 Oct 93 10:41:37 PDT." <9310281741.AA21422@mani.kaist.ac.kr> Date: Thu, 28 Oct 1993 14:35:15 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Oct28.143528pdt.12171@skylark.parc.xerox.com> > I can't see the ad in my sd. ;( > > My host is in Korea. Hosts in Korea receive IP multicast packets from > 192.52.195.241(mbone.nsi.nasa.gov). > > I'd like to listen the Forum. Please help me reach the Forum. Kyungran, The sd advertisements were using the same TTLs as normally used for IETF Channel 2 transmissions. Perhaps there is a threshold between here and there that is preventing those ads from getting through. I have now increased the TTLs to the IETF Channel 1 values (191 for the audio and 127 for the video). If you still don't see them, I can't help you. Steve From rem-conf-request@es.net Thu Oct 28 18:47:49 1993 Received: from gumby.dsd.TRW.COM by osi-east.es.net via ESnet SMTP service id <05815-0@osi-east.es.net>; Thu, 28 Oct 1993 15:37:55 +0000 Received: from localhost.sp.TRW.COM by gumby.dsd.TRW.COM (4.1/SMI-4.1) id AA03385; Thu, 28 Oct 93 15:37:52 PDT Message-Id: <9310282237.AA03385@gumby.dsd.TRW.COM> To: rem-conf@es.net Subject: MBONE and DNI (?) Date: Thu, 28 Oct 93 15:37:51 -0700 From: Dan Molinelli hi, well we got Sunlink DNI working with the MBONE IP Multicast kernel. we had to use mtest and manually bring up DECnet multicasting. questions: If this is the correct way to do this. Is there ANY documenation for the MBONE stuff? What in the kernel has changed. Are other people running CAP, DNI or OSI on their Suns with MBONE? Daniel Molinelli (310) 812-2161 TRW Space and Electronics Group, Communications Services moline@gumby.dsd.TRW.COM (Internet) From rem-conf-request@es.net Thu Oct 28 19:46:53 1993 Received: from anu.anu.edu.au by osi-east.es.net via ESnet SMTP service id <06719-0@osi-east.es.net>; Thu, 28 Oct 1993 16:37:38 +0000 Received: from octavia. (octavia.anu.edu.au) by anu.anu.edu.au (4.1/SMI-4.1) id AA01913; Fri, 29 Oct 93 09:36:45 EST Received: by octavia. (4.1/SMI-4.1) id AA08589; Fri, 29 Oct 93 09:37:16 EST Date: Fri, 29 Oct 93 09:37:16 EST From: markus@octavia.anu.edu.au (Markus Buchhorn) Message-Id: <9310282337.AA08589@octavia.> To: krkang@mani.kaist.ac.kr Subject: Re: Xerox PARC Forum, Thu, Oct 28 -- Mark Weiser, "Ubiquitous Computing" Cc: rem-conf@es.net > I can't see the ad in my sd. ;( > I'd like to listen the Forum. Please help me reach the Forum. SD is not the only way to pick up a multicast session - basically it is only a phonebook where sessions are advertised, but if you already know the "phone number", you can dial in directly. > > Xerox PARC Forum - Audio pcm 224.2.248.152, port 53826, id 12617, ttl 159 > > Xerox PARC Forum - Video nv 224.2.248.152, port 49991, id 65362, ttl 95 So, if you have vat and nv installed, and are receiving packets, you can do: % nv & which brings up the basic window. Then type in the numbers into the appropriate slots. (click on the numbers and delete the existing entries - hit return when each one is done.) For the audio % vat '224.2.248.152/53826/12617' & brings up the session. This is how I got it right now - My SD didn't show the session either (even though it was there yesterday...) Cheers, Markus Markus Buchhorn, Parallel Computing Research Facility email = markus@octavia.anu.edu.au snail = CISR, I Block, OAA, ANU Australian National University, Canberra, 0200 , Australia. [International = +61 6, Australia = 06] [Phone = 2492930, Fax = 2490747] From rem-conf-request@es.net Thu Oct 28 20:27:53 1993 Received: from zephyr.isi.edu by osi-east.es.net via ESnet SMTP service id <07175-0@osi-east.es.net>; Thu, 28 Oct 1993 17:17:04 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Thu, 28 Oct 1993 17:16:50 -0700 Date: Thu, 28 Oct 1993 17:16:50 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199310290016.AA05799@zephyr.isi.edu> To: deering@parc.xerox.com Subject: What's missing from the PARC Forum multicasts Cc: rem-conf@es.net Steve, It just came to me what the PARC Forum needs. It needs THEME MUSIC, to play before and after. Just turning the broadcast on and off abruptly simply isn't very professional... Bob Braden From rem-conf-request@es.net Thu Oct 28 21:24:54 1993 Received: from alpha.Xerox.COM by osi-east.es.net via ESnet SMTP service id <07599-0@osi-east.es.net>; Thu, 28 Oct 1993 18:12:18 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11692>; Thu, 28 Oct 1993 18:11:52 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 28 Oct 1993 18:11:45 -0700 To: braden@isi.edu (Bob Braden) Cc: rem-conf@es.net, deering@parc.xerox.com Subject: Re: What's missing from the PARC Forum multicasts In-reply-to: Your message of "Thu, 28 Oct 93 17:16:50 PDT." <199310290016.AA05799@zephyr.isi.edu> Date: Thu, 28 Oct 1993 18:11:31 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Oct28.181145pdt.12171@skylark.parc.xerox.com> > It just came to me what the PARC Forum needs. It needs THEME MUSIC, > to play before and after. Just turning the broadcast on and off > abruptly simply isn't very professional... Yes, I've been trying to get the A/V services folks to improve the format, like leaving the camera on before and after the talk so Internauts can watch the audience arrive and depart, maybe rolling some credits at the end, etc. It's a change for them -- their official task is to produce a videotape for internal Xerox distribution, and they like to start and end the tape with a short length of recorded silence. Thay also like to go home as soon as the talk is finished. Anyway, we'll work on it. Steve From rem-conf-request@es.net Fri Oct 29 04:54:49 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <10198-0@osi-east.es.net>; Fri, 29 Oct 1993 01:45:46 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 29 Oct 1993 08:45:32 +0000 To: Dan_Swinehart.PARC@xerox.com cc: M.A.Swaby-SE0@computer-science.birmingham.ac.uk, rem-conf@es.net Subject: Re: Suggestions wanted for project In-reply-to: Your message of "Thu, 28 Oct 93 14:30:46 PDT." <93Oct28.143133pdt.11699@alpha.xerox.com> Date: Fri, 29 Oct 93 08:45:32 +0000 From: Jon Crowcroft >you'd like. But I'd think the best path to your system administrator is >through your faculty. If they don't see the necessity, or haven't got the >clout to get past the bureaucrats, then perhaps you have bigger problems to >deal with. agree - basically, if your sys admin can't do this (and it is an hours work max) then what are they doing? >P.S. You could do multicast experiments on a single Ethernet segment without >any multicast routers or tunnel routers in your environment. Presumably the >tools would work in such a local environment without needing the multicast >extensions. But maybe they count on being able to call on the new sysem >routines provided by these extensions? I'm not an expert at this level. unixes need changes to join groups and receive ip multicast to those groups even just on the LAN. (for a start you have to recognize class D addresses, then you have to reognize which ones you have group members for, then you need a mapping from ip class D addr to ether addr -= thats all before you even consider routing off the lan...) by the way, UK-wide mbone support is going to be in place as a service soonish - it is funded as part of superjanet work... jon From rem-conf-request@es.net Fri Oct 29 05:04:49 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <10223-0@osi-east.es.net>; Fri, 29 Oct 1993 01:53:58 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 29 Oct 1993 08:53:45 +0000 To: Steve Deering cc: braden@isi.edu (Bob Braden), rem-conf@es.net Subject: Re: What's missing from the PARC Forum multicasts In-reply-to: Your message of "Thu, 28 Oct 93 18:11:31 PDT." <93Oct28.181145pdt.12171@skylark.parc.xerox.com> Date: Fri, 29 Oct 93 08:53:44 +0000 From: Jon Crowcroft >> It just came to me what the PARC Forum needs. It needs THEME MUSIC, >> to play before and after. Just turning the broadcast on and off >> abruptly simply isn't very professional... Steve if you had a good classical radio station you could just switch the audio input to that - if not, we can dd this for you - we could provide a feed of good ole fasioned bbc stuff, and you could just cross us out during the talk. jon From rem-conf-request@es.net Fri Oct 29 09:19:58 1993 Received: from piraya.electrum.kth.se by osi-east.es.net via ESnet SMTP service id <11504-0@osi-east.es.net>; Fri, 29 Oct 1993 06:05:26 +0000 Received: from ulfs-mac.electrum.kth.se by piraya.electrum.kth.se (5.61-bind 1.4+ida/4.0) id AA07419; Fri, 29 Oct 93 14:05:02 +0100 Message-Id: <9310291305.AA07419@piraya.electrum.kth.se> X-Sender: bilting@mail.it.kth.se Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Sep 1989 14:05:09 +0000 To: mice-seminars@cs.ucl.ac.uk, rem-conf@es.net From: bilting@it.kth.se (Ulf Bilting) Subject: MICE seminar Nov 1 This is to announce the MICE seminar Nov 1 1993 from KTH/SICS in Stockholm Time: 15.00 CET (= 14.00 GMT) Lars Thylen (KTH/Photonics) Optical networks and transmission in broadband communications The usual multicast addresses will be used: vat 224.5.17.12 (default port) ivs 224.5.17.12 (default port) wb 224.5.17.12 (port 32416) From rem-conf-request@es.net Fri Oct 29 11:34:00 1993 Received: from cambium.uoregon.edu by osi-east.es.net via ESnet SMTP service id <12364-0@osi-east.es.net>; Fri, 29 Oct 1993 08:16:31 +0000 Received: from localhost (meyer@localhost) by cambium.uoregon.edu (8.6.3/8.6) id IAA07596; Fri, 29 Oct 1993 08:14:30 -0700 Date: Fri, 29 Oct 1993 08:14:30 -0700 From: "David M. Meyer 503/346-1747" Message-Id: <199310291514.IAA07596@cambium.uoregon.edu> To: rem-conf@es.net, mbone@isi.edu Subject: /kernel/drv/ip location correction (Solaris 2.x as an mrouter) It was brought to my attention that I erronously said that you could find Erik's ip module in ftp.uoregon.edu in pub/Solaris2.x/MBONE/binaries That should be ftp.uoregon.edu in pub/Solaris2.x/src/MBONE/binaries (the file is called ip). Sorry for any inconvenience. Dave David M. Meyer Voice: 503/346-1747 Senior Network Engineer Pager: 503/342-9458 Office of University Computing FAX: 503/346-4397 Computing Center Internet: meyer@ns.uoregon.edu University of Oregon 1225 Kincaid Eugene, OR 97403 From rem-conf-request@es.net Fri Oct 29 12:16:29 1993 Received: from zephyr.isi.edu by osi-east.es.net via ESnet SMTP service id <12506-0@osi-east.es.net>; Fri, 29 Oct 1993 08:29:29 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Fri, 29 Oct 1993 08:29:07 -0700 Date: Fri, 29 Oct 1993 08:29:07 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199310291529.AA13593@zephyr.isi.edu> To: deering@parc.xerox.com, J.Crowcroft@cs.ucl.ac.uk Subject: Re: What's missing from the PARC Forum multicasts Cc: braden@ISI.EDU, rem-conf@es.net *> From J.Crowcroft@cs.ucl.ac.uk Fri Oct 29 01:53:57 1993 *> To: Steve Deering *> Cc: braden@ISI.EDU (Bob Braden), rem-conf@es.net *> Subject: Re: What's missing from the PARC Forum multicasts *> In-Reply-To: Your message of "Thu, 28 Oct 93 18:11:31 PDT." <93Oct28.181145pdt.12171@skylark.parc.xerox.com> *> Date: Fri, 29 Oct 93 08:53:44 +0000 *> From: Jon Crowcroft *> Content-Length: 435 *> X-Lines: 15 *> *> *> *> >> It just came to me what the PARC Forum needs. It needs THEME MUSIC, *> >> to play before and after. Just turning the broadcast on and off *> >> abruptly simply isn't very professional... *> *> Steve *> *> if you had a good classical radio station you could just switch the *> audio input to that - if not, we can dd this for you - we could *> provide a feed of good ole fasioned bbc stuff, and you could just *> cross us out during the talk. *> *> jon *> *> No, No, you aren't taking this seriously enough. PARC needs its OWN theme, something hummable, so that whenever people hear it, they instantly associate it with PARC Forum. Like the William Tell Overture and the Lone Ranger, for example. Bob From rem-conf-request@es.net Fri Oct 29 14:11:40 1993 Received: from gumby.dsd.TRW.COM by osi-east.es.net via ESnet SMTP service id <14896-0@osi-east.es.net>; Fri, 29 Oct 1993 11:01:30 +0000 Received: from localhost.sp.TRW.COM by gumby.dsd.TRW.COM (4.1/SMI-4.1) id AA27273; Fri, 29 Oct 93 11:01:28 PDT Message-Id: <9310291801.AA27273@gumby.dsd.TRW.COM> To: rem-conf@es.net Subject: perl script for DNI & IP Multicast Date: Fri, 29 Oct 93 11:01:27 -0700 From: Dan Molinelli here's the perl script needed to enable DECnet when in use with an IP Multicast kernel via Sunlink DNI. later dan ===== #!/usr/local/bin/perl # # mbone_install_mcasts # # This script will install the multicast address needed for # DECNET if the MBONE Multicast kernel is running. # We check to see if the flag 0x800 is set (via ifconfig), and # if so we run mtest to add the multicast address. # If this gets executed more than once, the multicast will be added # more than once, and more than 1 delete command will be necessary # to delete it. # # You can see if the multicast address is already set by running # etherfind in the non-promiscious mode, and see if any multicasts # are getting through: # etherfind -p decnet # If withing 15 seconds you do not see output like the following: # 106 DEC Routing 44.1023 -> multicast # 106 DEC Routing 18.1023 -> multicast # 106 DEC Routing 7.1023 -> multicast # then you need to set the multicast. # NOTE: I'm only setting the DEC Routing (level 2) multicast. # By default, DNI sets both this one and the level 1 multicast. # I don't think the level 1's are necessary, since we cannot # act as a router. DNI works fine with just the level 2's. # # I also assume, something like this will be needed if you want # to run Appletalk phase 2 (CAP) on this machine. # # jsb - 10/28/93 # $interface="le0"; $IFF_MULTICAST=0x800; $MCAST_DEC_ROUTE_1="ab.00.00.03.00.00"; # End node Hello $MCAST_DEC_ROUTE_2="ab.00.00.04.00.00"; # Router Hello $PROG_MTEST="/usr/local/etc/mtest"; # First run ifconfig and extract the "flags=" value, which is in hex. open(IFCONFIG, "ifconfig $interface|") || die "Cannot run ifconfig: $!\n"; while(){ if(/flags/o) { # The flags appear between a "=" and a "<" character ($xx, $flagshex) = split(/[=<]/, $_); $flags = hex($flagshex); # flags is in HEX } } close IFCONFIG; # # Now, a simple AND will tell me if the Multicast Bit is set # This means we are running the MULTICAST Kernel $tmpfile = "/tmp/mtest.input"; if($flags & $IFF_MULTICAST) { print "IFF_MULTICAST IS SET\n"; print "Must be running the IP Multicast Kernel\n"; open(TMPFILE, ">$tmpfile") || die "Cannot write to $tmpfile: $!\n"; print TMPFILE "a $interface $MCAST_DEC_ROUTE_2\n"; print TMPFILE "q\n"; close TMPFILE; print "Adding multicast: $MCAST_DEC_ROUTE_2\n"; system("$PROG_MTEST < $tmpfile"); } else{ print "IFF_MULTICAST IS NOT SET\n"; } ------- End of Forwarded Message From rem-conf-request@es.net Fri Oct 29 22:46:57 1993 Received: from rx7.ee.lbl.gov by osi-east.es.net via ESnet SMTP service id <22671-0@osi-east.es.net>; Fri, 29 Oct 1993 19:38:33 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA13731; Fri, 29 Oct 93 19:39:12 -0700 Message-Id: <9310300239.AA13731@rx7.ee.lbl.gov> To: mbone@isi.edu, rem-conf@es.net Subject: HP versions of vat, wb & sd available Date: Fri, 29 Oct 93 19:39:11 PDT From: Van Jacobson Versions of vat, wb & sd for HP-7xx (`snake') workstations running hpux are now available for anonymous ftp from ftp.ee.lbl.gov in files hp-sd.tar.Z, hp-vat.tar.Z & hp-wb.tar.Z. There is also an hpux binary for ghostscript (the postscript renderer used by wb) available as hp-gs.tar.Z. Note that to run vat you need a model of snake that has built-in audio hardware, e.g., a 735 but not a 720 or 730. Also note that hpux multicast support is *not* available from ftp.ee.lbl.gov (since we had nothing to do with porting multicast to hpux) be we suspect that other parties will be making it publically available in the near future. We'd like to thank Steve Pink (on sabattical at HP Labs, Bristol) for pushing to make this port happen, Mark Laubach at HP Labs, Palo Alto, for loaning us a 735 & promptly answering all our questions about the HP audio hardware & software and Geir Pedersen at Univ. of Oslo for supplying us with a multicast-capable hpux kernel. - Van Jacobson & Steve McCanne From rem-conf-request@es.net Sat Oct 30 02:52:01 1993 Received: from genesis.iti.gov.sg by osi-east.es.net via ESnet SMTP service id <23450-0@osi-east.es.net>; Fri, 29 Oct 1993 23:44:19 +0000 Received: from sol.iti.gov.sg by iti.gov.sg (4.1/SMI-4.1) id AA05879; Sat, 30 Oct 93 14:45:46 SST From: sree@iti.gov.sg (Sreedharan Bhaskaran \(ATM\)) Message-Id: <9310300645.AA05879@iti.gov.sg> Subject: Subscribe To: rem-conf@es.net Date: Sat, 30 Oct 93 14:45:52 WST X-Mailer: ELM [version 2.3 PL11] Hello, Can you please put me and my colleague on this mailing list. Our email addresses are : sree@iti.gov.sg ypc@iti.gov.sg Sree -------------------------------------------------------------------------- Sreedharan Bhaskaran | Tel: (65)-772-0409 Multimedia Communications | Fax: (65)-777-3043 Information Technology Institute | National Computer Board | email: sree@iti.gov.sg 71 Science Park Drive | NCB Building | Singapore 0511 | Republic Of Singapore | -------------------------------------------------------------------------- From rem-conf-request@es.net Sat Oct 30 16:05:44 1993 Received: from cambium.uoregon.edu by osi-east.es.net via ESnet SMTP service id <03456-0@osi-east.es.net>; Sat, 30 Oct 1993 13:05:02 +0000 Received: from localhost (root@localhost) by cambium.uoregon.edu (8.6.3/8.6) id NAA02260; Sat, 30 Oct 1993 13:02:58 -0700 Date: Sat, 30 Oct 1993 13:02:58 -0700 From: "David M. Meyer 503/346-1747" Message-Id: <199310302002.NAA02260@cambium.uoregon.edu> To: rem-conf@es.net, mbone@isi.edu cc: nero-coord@cs.orst.edu, jqj@phloem.uoregon.edu, dsmith@phloem.uoregon.edu, jad@phloem.uoregon.edu, grzybowski_carl@oslmac.osl.or.gov Subject: As promised (Solaris 2.x/SVR4 patch for mrmap) Included below is a (again minor) patch that makes mrmap compile and run on Solaris 2.x (or SVR4) systems. The patch is wrapped up in a shar archive with the dvmrp.h from the mrouted distribution (in the event you don't have it). Again, you can get the Solaris 2.x binary from ftp.uoregon.edu:pub/Solaris2.x/bin. Please let me know if you have any problems with the patch and, as usual, many thanks to Van and crew. Dave David M. Meyer Voice: 503/346-1747 Senior Network Engineer Pager: 503/342-9458 Office of University Computing FAX: 503/346-4397 Computing Center Internet: meyer@ns.uoregon.edu University of Oregon 1225 Kincaid Eugene, OR 97403 ---------------------------------- #!/bin/sh # This is a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 10/30/1993 19:59 UTC by meyer@ns.uoregon.edu # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 5818 -r--r--r-- dvmrp.h # 1901 -rw-r--r-- patch01 # # ============= dvmrp.h ============== if test -f 'dvmrp.h' -a X"$1" != X"-c"; then echo 'x - skipping dvmrp.h (File already exists)' else echo 'x - extracting dvmrp.h (Text)' sed 's/^X//' << 'SHAR_EOF' > 'dvmrp.h' && /* X * The mrouted program is covered by the license in the accompanying file X * named "LICENSE". Use of the mrouted program represents acceptance of X * the terms and conditions listed in that file. X * X * The mrouted program is COPYRIGHT 1989 by The Board of Trustees of X * Leland Stanford Junior University. X * X * X * $Revision: 1.2 $ X */ X /* X * A DVMRP message consists of an IP header + an IGMP header + (for some types) X * zero or more bytes of data. X * X * For REPORT messages, the data is route information; the route information X * consists of one or more lists of the following form: X * X * (mask, (origin, metric), (origin, metric), ...) X * X * where: X * X * "mask" is the subnet mask for all the origins in the list. X * It is always THREE bytes long, containing the low-order X * three bytes of the mask (the high-order byte is always X * 0xff and therefore need not be transmitted). X * X * "origin" is the number of a subnet from which multicast datagrams X * may originate. It is from one to four bytes long, X * depending on the value of "mask": X * if all bytes of the mask are zero X * the subnet number is one byte long X * else if the low-order two bytes of the mask are zero X * the subnet number is two bytes long X * else if the lowest-order byte of the mask is zero X * the subnet number is three bytes long, X * else X * the subnet number is four bytes long. X * X * "metric" is a one-byte value consisting of two subfields: X * - the high-order bit is a flag which, when set, indicates X * the last (origin, metric) pair of a list. X * - the low-order seven bits contain the routing metric for X * the corresponding origin, relative to the sender of the X * DVMRP report. The metric may have the value of UNREACHABLE X * added to it as a "split horizon" indication (so called X * "poisoned reverse"). X * X * Within a list, the origin subnet numbers must be in ascending order, and X * the lists themselves are in order of increasing mask value. A message may X * not exceed 576 bytes, the default maximum IP reassembly size, including X * the IP and IGMP headers; the route information may be split across more X * than one message if necessary, by terminating a list in one message and X * starting a new list in the next message (repeating the same mask value, X * if necessary). X * X * For NEIGHBORS messages, the data is neighboring-router information X * consisting of one or more lists of the following form: X * X * (local-addr, metric, threshold, ncount, neighbor, neighbor, ...) X * X * where: X * X * "local-addr" is the sending router's address as seen by the neighbors X * in this list; it is always four bytes long. X * "metric" is a one-byte unsigned value, the TTL `cost' of forwarding X * packets to any of the neighbors on this list. X * "threshold" is a one-byte unsigned value, a lower bound on the TTL a X * packet must have to be forwarded to any of the neighbors on X * this list. X * "ncount" is the number of neighbors in this list. X * "neighbor" is the address of a neighboring router, four bytes long. X * X * As with REPORT messages, NEIGHBORS messages should not exceed 576 bytes, X * including the IP and IGMP headers; split longer messages by terminating the X * list in one and continuing in another, repeating the local-addr, etc., if X * necessary. X * X * For NEIGHBORS2 messages, the data is identical to NEIGHBORS except X * there is a flags byte before the neighbor count: X * X * (local-addr, metric, threshold, flags, ncount, neighbor, neighbor, ...) X */ X /* X * DVMRP message types (carried in the "code" field of an IGMP header) X */ #define DVMRP_PROBE 1 /* for finding neighbors */ #define DVMRP_REPORT 2 /* for reporting some or all routes */ #define DVMRP_ASK_NEIGHBORS 3 /* sent by mapper, asking for a list */ X /* of this router's neighbors. */ #define DVMRP_NEIGHBORS 4 /* response to such a request */ #define DVMRP_ASK_NEIGHBORS2 5 /* as above, want new format reply */ #define DVMRP_NEIGHBORS2 6 X /* X * 'flags' byte values in DVMRP_NEIGHBORS2 reply. X */ #define DVMRP_NF_TUNNEL 0x01 /* neighbors reached via tunnel */ #define DVMRP_NF_SRCRT 0x02 /* tunnel uses IP source routing */ #define DVMRP_NF_DOWN 0x10 /* kernel state of interface */ #define DVMRP_NF_DISABLED 0x20 /* administratively disabled */ #define DVMRP_NF_QUERIER 0x40 /* I am the subnet's querier */ X /* X * Limit on length of route data X */ #define MAX_IP_PACKET_LEN 576 #define MIN_IP_HEADER_LEN 20 #define MAX_IP_HEADER_LEN 60 #define MAX_DVMRP_DATA_LEN \ X ( MAX_IP_PACKET_LEN - MAX_IP_HEADER_LEN - IGMP_MINLEN ) X /* X * Various protocol constants (all times in seconds) X */ X /* address for multicast DVMRP msgs */ #define INADDR_DVMRP_GROUP (u_long)0xe0000004 /* 224.0.0.4 */ X #define ROUTE_MAX_REPORT_DELAY 5 /* max delay for reporting changes */ X /* (This is the timer interrupt */ X /* interval; all times must be */ X /* multiples of this value.) */ X #define ROUTE_REPORT_INTERVAL 60 /* periodic route report interval */ #define ROUTE_SWITCH_TIME 140 /* time to switch to equivalent gw */ #define ROUTE_EXPIRE_TIME 200 /* time to mark route invalid */ #define ROUTE_DISCARD_TIME 340 /* time to garbage collect route */ X #define LEAF_CONFIRMATION_TIME 200 /* time to consider subnet a leaf */ X #define NEIGHBOR_PROBE_INTERVAL 190 /* periodic neighbor probe interval */ #define NEIGHBOR_EXPIRE_TIME 140 /* time to consider neighbor gone */ X #define GROUP_QUERY_INTERVAL 125 /* periodic group query interval */ #define GROUP_EXPIRE_TIME 270 /* time to consider group gone */ X #define UNREACHABLE 32 /* "infinity" metric, must be <= 64 */ #define DEFAULT_METRIC 1 /* default subnet/tunnel metric */ #define DEFAULT_THRESHOLD 1 /* default subnet/tunnel threshold */ SHAR_EOF chmod 0444 dvmrp.h || echo 'restore of dvmrp.h failed' Wc_c="`wc -c < 'dvmrp.h'`" test 5818 -eq "$Wc_c" || echo 'dvmrp.h: original size 5818, current size' "$Wc_c" fi # ============= patch01 ============== if test -f 'patch01' -a X"$1" != X"-c"; then echo 'x - skipping patch01 (File already exists)' else echo 'x - extracting patch01 (Text)' sed 's/^X//' << 'SHAR_EOF' > 'patch01' && *** Makefile.orig Sat Oct 30 12:30:54 1993 --- Makefile Sat Oct 30 12:40:30 1993 *************** *** 2,13 **** X OPT= -O X CFLAGS= -I/usr/src/local/sbin/mrouted ${OPT} X SRCS = mrmap.c ! X all: mrmap X X mrmap: mrmap.o X rm -f $@ ; \ ! ${CC} -o $@ ${CFLAGS} mrmap.o X X clean: FRC X rm -f *.o core core.mrmap tags TAGS --- 2,16 ---- X OPT= -O X CFLAGS= -I/usr/src/local/sbin/mrouted ${OPT} X SRCS = mrmap.c ! # ! # -lnsl -lsocket for SVR4 ! # ! LIBS = -lnsl -lsocket X all: mrmap X X mrmap: mrmap.o X rm -f $@ ; \ ! ${CC} -o $@ ${CFLAGS} mrmap.o ${LIBS} X X clean: FRC X rm -f *.o core core.mrmap tags TAGS *** mrmap.c.orig Sat Oct 30 12:32:02 1993 --- mrmap.c Sat Oct 30 12:46:22 1993 *************** *** 144,150 **** X X if (addr == 0) X return ("local"); ! e = gethostbyaddr(&addr, sizeof(addr), AF_INET); X return e ? e->h_name : 0; X } X --- 144,150 ---- X X if (addr == 0) X return ("local"); ! e = gethostbyaddr((char *) &addr, sizeof(addr), AF_INET); X return e ? e->h_name : 0; X } X *************** *** 223,229 **** --- 223,233 ---- X igmp->igmp_cksum = 0; X igmp->igmp_cksum = inet_cksum((u_short *)igmp, sizeof(struct igmp)); X + #ifdef __STDC__ + memset(sdst, (char)0, sizeof(sdst)); + #else X bzero(sdst, sizeof(sdst)); + #endif X sdst.sin_family = AF_INET; X sdst.sin_addr.s_addr = dst; X if (sendto(igmp_socket, buf, ip->ip_len, 0, *************** *** 374,381 **** X u_long target_addr = 0; X int sockbuf = 24*1024; X ! setlinebuf(stderr); X setlinebuf(stdout); X X if (geteuid() != 0) { X fprintf(stderr, "must be root\n"); --- 378,390 ---- X u_long target_addr = 0; X int sockbuf = 24*1024; X ! #ifdef __STDC__ ! setvbuf(stderr, NULL, _IOLBF, 0); ! setvbuf(stdout, NULL, _IOLBF, 0); ! #else X setlinebuf(stdout); + setlinebuf(stderr); + #endif /* __STDC__ */ X X if (geteuid() != 0) { X fprintf(stderr, "must be root\n"); SHAR_EOF chmod 0644 patch01 || echo 'restore of patch01 failed' Wc_c="`wc -c < 'patch01'`" test 1901 -eq "$Wc_c" || echo 'patch01: original size 1901, current size' "$Wc_c" fi exit 0 From rem-conf-request@es.net Sat Oct 30 16:08:28 1993 Received: from cambium.uoregon.edu by osi-east.es.net via ESnet SMTP service id <03448-0@osi-east.es.net>; Sat, 30 Oct 1993 13:00:09 +0000 Received: from localhost (root@localhost) by cambium.uoregon.edu (8.6.3/8.6) id MAA02243; Sat, 30 Oct 1993 12:58:01 -0700 Date: Sat, 30 Oct 1993 12:58:01 -0700 From: "David M. Meyer 503/346-1747" Message-Id: <199310301958.MAA02243@cambium.uoregon.edu> To: rem-conf@es.net, mbone@isi.edu cc: nero-coord@cs.orst.edu, jqj@phloem.uoregon.edu, dsmith@phloem.uoregon.edu, jad@phloem.uoregon.edu, grzybowski_carl@oslmac.osl.or.gov Subject: Solaris 2.x patch for mrdebug Included below is a (minor) patch that makes mrdebug compile and run on Solaris 2.x (or SVR4) systems. I'll post a mrmap in a seprate message. You can get the Solaris 2.x binary from ftp.uoregon.edu:pub/Solaris2.x/bin. Please let me know if you have any problems with the patch and thanks to Van and crew (Deborah Agarwal, et al) for providing these great tools. Dave David M. Meyer Voice: 503/346-1747 Senior Network Engineer Pager: 503/342-9458 Office of University Computing FAX: 503/346-4397 Computing Center Internet: meyer@ns.uoregon.edu University of Oregon 1225 Kincaid Eugene, OR 97403 ---------------------------------- *** Makefile.orig Fri Oct 29 15:29:31 1993 --- Makefile Fri Oct 29 15:30:05 1993 *************** *** 10,17 **** OBJFILS = $(SRCFILS:.c=.o) ! CFLAGS = -O ! LDFLAGS = tar: mrdebug.tar.Z --- 10,17 ---- OBJFILS = $(SRCFILS:.c=.o) ! CFLAGS = -O -DSVR4 ! LDFLAGS = -lnsl -lsocket tar: mrdebug.tar.Z *** mrdebug.c.orig Fri Oct 29 15:29:02 1993 --- mrdebug.c Fri Oct 29 15:47:45 1993 *************** *** 20,26 **** --- 20,33 ---- #include #include #include + #ifdef SVR4 + #include + #ifndef EX_USAGE + #define EX_USAGE EX_SUCCESS + #endif /* EX_USAGE */ + #else #include + #endif /* SVR4 */ #include "types.h" #include "mrhash.h" *************** *** 30,38 **** --- 37,47 ---- #include "user_proto.h" /********EXTERNAL REFERENCES *************/ + #ifndef __STDC__ extern int getopt(int, char**, const char*); extern char *optarg; extern int optind; + #endif /********GLOBALS **********/ Network mbone; *************** *** 280,288 **** cur_path_stack.number = 0; cur_path_stack.first = NULL; if( mbone.adj_list[destination].type & SUBNET ) ! push_path_elem( &cur_path_stack, dest_name, ! mbone.adj_list[destination].dist_vects.distance, ! 0, FALSE, FALSE, TRUE ); if( verbose ) fprintf( output, "Output key: interface, tree level/metric to here/ttl to reach\n\n"); print_path( output, &mbone, indent, src_name, dest_name, --- 289,298 ---- cur_path_stack.number = 0; cur_path_stack.first = NULL; if( mbone.adj_list[destination].type & SUBNET ) ! push_path_elem( &cur_path_stack, ! dest_name, ! mbone.adj_list[destination].dist_vects.distance, ! 0, FALSE, FALSE, TRUE,0 ); if( verbose ) fprintf( output, "Output key: interface, tree level/metric to here/ttl to reach\n\n"); print_path( output, &mbone, indent, src_name, dest_name, *** mrhash.c.orig Fri Oct 29 15:48:15 1993 --- mrhash.c Fri Oct 29 16:16:39 1993 *************** *** 32,38 **** #include #include ! #include #include "types.h" #include "mrhash.h" --- 32,42 ---- #include #include ! #ifdef SVR4 ! #include ! #else ! #include ! #endif /* SVR4 */ #include "types.h" #include "mrhash.h" *************** *** 77,83 **** --- 81,91 ---- if ( ( newtbl_p = (HENTRY_t *)calloc(slots, sizeof(HENTRY_t)) ) == NULL ) { printf("create_htable: Malloc returned NULL\n"); + #ifdef SVR4 + Sys_exit( EX_NOSPACE ); + #else Sys_exit( EX_OSERR ); + #endif } table_p->htbl_p = (HENTRY_t **) newtbl_p; *************** *** 149,155 **** --- 157,167 ---- if ( ( entry_p = lookup_htable( table_p, key_p ) ) == NULL ) { printf("ERROR: delete_htable: Did not find entry\n"); + #ifdef SVR4 + Sys_exit( EX_FAILURE ); + #else Sys_exit( EX_SOFTWARE ); + #endif } /* ** Remove entry from the table. *************** *** 170,176 **** --- 182,192 ---- if ( table_p->entries < 0 ) { printf("delete_htable: ERROR!! hash table entries < 0 \n"); + #ifdef SVR4 + Sys_exit( EX_FAILURE ); + #else Sys_exit( EX_SOFTWARE ); + #endif } } *************** *** 197,203 **** --- 213,223 ---- if ( ( nentry_p = (HENTRY_t *) malloc( sizeof( HENTRY_t ) ) ) == NULL ) { printf("insert_htable: malloc returned NULL\n"); + #ifdef SVR4 + Sys_exit( EX_NOSPACE ); + #else Sys_exit( EX_OSERR ); + #endif } nentry_p->hidx = hidx; /* Slot number in table */ strcpy( nentry_p->key_p, key_p ); /* IP name */ *************** *** 234,240 **** --- 254,264 ---- if ( ( entry_p = lookup_htable( table_p, key_p ) ) == NULL ) { printf("ERROR: update_htable: Did not find entry\n"); + #ifdef SVR4 + Sys_exit( EX_FAILURE ); + #else Sys_exit( EX_SOFTWARE ); + #endif } /* ** Update entry *** user.c.orig Fri Oct 29 16:16:52 1993 --- user.c Fri Oct 29 16:17:10 1993 *************** *** 1,8 **** #include #include #include ! #include "types.h" #include "mrhash.h" #include "data_struct_proto.h" --- 1,11 ---- #include #include + #ifdef SVR4 + #include + #else #include ! #endif #include "types.h" #include "mrhash.h" #include "data_struct_proto.h" From rem-conf-request@es.net Sun Oct 31 10:06:53 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net via ESnet SMTP service id <06656-0@osi-east.es.net>; Sun, 31 Oct 1993 06:59:25 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 31 Oct 1993 14:59:10 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: bilting@it.kth.se (Ulf Bilting) cc: mice-seminars@cs.ucl.ac.uk, rem-conf@es.net Subject: Re: MICE seminar Nov 1 In-reply-to: Your message of "Fri, 22 Sep 89 14:05:09 -0100." <9310291305.AA07419@piraya.electrum.kth.se> Date: Sun, 31 Oct 93 14:59:09 +0000 Sender: M.Handley@cs.ucl.ac.uk >This is to announce the MICE seminar Nov 1 1993 from KTH/SICS in Stockholm >Time: 15.00 CET (= 14.00 GMT) > >Lars Thylen (KTH/Photonics) >Optical networks and transmission >in broadband communications Assuming I've converted the timezones correctly, I believe the start of the IETF plenary is 15:00 GMT. We should be careful to avoid overrunning and clashing with the plenary. Similarly if the good folks multicasting the IETF could please keep the data rate on their test traffic low for that hour, we'd be very grateful. Mark From rem-conf-request@es.net Sun Oct 31 22:19:05 1993 Received: from venera.isi.edu by osi-east.es.net via ESnet SMTP service id <08968-0@osi-east.es.net>; Sun, 31 Oct 1993 19:10:28 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Sun, 31 Oct 1993 19:10:24 -0800 Posted-Date: Sun 31 Oct 93 19:09:40 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sun, 31 Oct 93 19:09:41 PST Date: Sun 31 Oct 93 19:09:40 PST From: Stephen Casner Subject: IETF Multicast tape replay extended To: rem-conf@es.net Message-Id: <752123380.0.CASNER@XFR.ISI.EDU> Mail-System-Version: The announcement of the multicast schedule said that the tape replay would be only one channel, and only part of the day's program. Now two VCRs have been obtained, and I have provided some T-200 tapes, so the replay will be on both channels and will cover the full day's program. The replay will still begin about one half hour after the end of the last session. Megan will be sending an updated multicast schedule to show this change. -- Steve ------- From rem-conf-request@es.net Sun Oct 31 23:10:03 1993 Received: from cambium.uoregon.edu by osi-east.es.net via ESnet SMTP service id <09104-0@osi-east.es.net>; Sun, 31 Oct 1993 20:01:54 +0000 Received: from localhost (meyer@localhost) by cambium.uoregon.edu (8.6.4/8.6) id TAA11111; Sun, 31 Oct 1993 19:59:39 -0800 Date: Sun, 31 Oct 1993 19:59:39 -0800 From: "David M. Meyer 503/346-1747" Message-Id: <199311010359.TAA11111@cambium.uoregon.edu> To: rem-conf@es.net, mbone@isi.edu Subject: patches for Solaris 2.2 "native" ivs, et al. I recently noticed that the Solaris 2.2 ivs patches distributed by INRIA depend on the compatibility libraries. Here are some patches that remove those dependencies. You need to apply the from INRIA patches first (you can find these on zenon.inria.fr in /rodeo/ivs/ivs3.2-solaris2.2.tar.Z). I note that the original patches used SOLARIS as the preprocessor symbol to identify what is in reality SVR4, Std C, or POSIX code. I've continued with this, although these symbols (SVR4 , __STDC__) and/or possibly some feature testing, would be more appropriate. Again, you can find the whole thing in ftp.uoregon.edu: /usr/local/src/MBONE/Applications/ivs/ivs3.2-src.solaris.tar.gz Good luck, and please let me know if you have problems with these patches. Dave David M. Meyer Voice: 503/346-1747 Senior Network Engineer Pager: 503/342-9458 Office of University Computing FAX: 503/346-4397 Computing Center Internet: meyer@ns.uoregon.edu University of Oregon 1225 Kincaid Eugene, OR 97403 --------------------------- *** ./src/soundsparc.c Sun Oct 31 14:17:49 1993 --- ./src/soundsparc.c.orig Sun Oct 31 13:57:37 1993 *************** *** 15,22 **** #ifdef SPARCSTATION #ifdef SOLARIS - #define irint rint /* ok, imperfect */ #include #else #include --- 15,22 ---- #ifdef SPARCSTATION + #ifdef SOLARIS #include #else #include *************** *** 62,94 **** /* Forward functions */ - - #ifdef SOLARIS - /* - * imperfect usleep emulation -- - * - * Probably should use the POSIX interface when we get Solaris - * 2.3 (see nanosleep(3R) on Solaris 2.3 [libposix4.a]). - * - * - * David M. Meyer 503/346-1747 - * meyer@cambium.uoregon.edu - * Sun Oct 31 14:09:57 1993 - * - * $Header: $ - * - */ - - void usleep(usecs) - unsigned int usecs; - { - struct timeval tval; - - tval.tv_sec = usecs/1000000; - tval.tv_usec = usecs%1000000; - select(0,NULL,NULL,NULL,&tval); - } - #endif /* Convert local gain into device parameters */ --- 62,67 ---- *** ./src/protocol.h Sun Oct 31 14:19:45 1993 --- ./src/protocol.h.orig Sun Oct 31 14:19:21 1993 *************** *** 202,210 **** u_short sec; /* 16-bits seconds */ u_short usec; /* 16 bits microseconds (<< 4) */ } TIMESTAMP; - - #ifdef SOLARIS - #define index(s,c) strchr((s),(c)) - #define bcopy(src,dest,len) (memmove((dest), (src), (len))) - #define bzero(dest,len) (memset((dest), (char)0, (len))) - #endif --- 202,204 ---- *** ./sun4OS4/Makefile Sun Oct 31 14:44:53 1993 --- ./sun4OS4/Makefile.orig Sun Oct 31 14:30:44 1993 *************** *** 3,15 **** # #--------------- X LIBRARY -------------------- ! # X11_LIBDIR=/usr/openwin/lib ! # X11_INCLUDE=/usr/openwin/include ! # XLIBRARY=$(X11_LIBDIR)/libXaw.a $(X11_LIBDIR)/libXmu.a \ ! # $(X11_LIBDIR)/libXt.a $(X11_LIBDIR)/libXext.a \ ! # $(X11_LIBDIR)/libX11.a -lsocket -lnsl /usr/ucblib/libucb.a -ldl ! ! XLIBRARY=-lXaw -lXmu -lXt -lXext -lX11 SHARE=-DMITSHM --- 3,13 ---- # #--------------- X LIBRARY -------------------- ! X11_LIBDIR=/usr/openwin/lib ! X11_INCLUDE=/usr/openwin/include ! XLIBRARY=$(X11_LIBDIR)/libXaw.a $(X11_LIBDIR)/libXmu.a \ ! $(X11_LIBDIR)/libXt.a $(X11_LIBDIR)/libXext.a \ ! $(X11_LIBDIR)/libX11.a -lsocket -lnsl /usr/ucblib/libucb.a -ldl SHARE=-DMITSHM *************** *** 70,76 **** CPU=-DSPARCSTATION ! AXL= VOLA=-fvolatile OPT1=-traditional OPT=-O --- 68,74 ---- CPU=-DSPARCSTATION ! AXL=-L/net/lib/gnu/gcc-2.4.3.1/lib/gcc-lib/sparc-sun-sunos4.1/2.4.3/ VOLA=-fvolatile OPT1=-traditional OPT=-O *************** *** 84,91 **** # #-- gcc ver 2.4.3 CC=gcc ! # CFLAGS= $(GCC_OPT) -I$(X11_INCLUDE) -DSOLARIS ! CFLAGS= $(GCC_OPT) -DSOLARIS #-- #CC=cc #CFLAGS= $(CC_OPT) --- 82,88 ---- # #-- gcc ver 2.4.3 CC=gcc ! CFLAGS= $(GCC_OPT) -I$(X11_INCLUDE) -DSOLARIS #-- #CC=cc #CFLAGS= $(CC_OPT) *** ./Makefile.common Sun Oct 31 15:09:28 1993 --- ./Makefile.common.orig Sun Oct 31 14:09:43 1993 *************** *** 1,10 **** #----------------- Common IVS Makefile ---------------------- - # - # Use LDFLAGS = -lnsl -lsocket for SVR4 (e.g. Solaris 2.x) - # - - LDFLAGS = -lnsl -lsocket SOURCES=../src/ HEADERS=$(SOURCES)adpcm.h $(SOURCES)ffct.h $(SOURCES)huffman.h \ --- 1,5 ---- *************** *** 110,116 **** -c $(SOURCES)display.c protocol.o: $(SOURCES)protocol.h $(SOURCES)protocol.c ! $(CC) $(PFLAGS) -DSOLARIS \ $(CCDEFS) \ $(CCMULTICASTINCL) \ -c $(SOURCES)protocol.c --- 105,111 ---- -c $(SOURCES)display.c protocol.o: $(SOURCES)protocol.h $(SOURCES)protocol.c ! $(CC) $(PFLAGS) \ $(CCDEFS) \ $(CCMULTICASTINCL) \ -c $(SOURCES)protocol.c *************** *** 131,137 **** $(OBJ_VIDEO) \ ivs.o \ $(LIB_VIDEO) \ ! $(XLIBRARY) $(LIB_AUDIO) -lm -o $@ $(LDFLAGS) decode_h261: $(HEADERS) $(OBJ_IVS_FILE) $(OBJ_DCT) $(SOURCES)decode_h261.c $(CC) $(CFLAGS) \ --- 126,132 ---- $(OBJ_VIDEO) \ ivs.o \ $(LIB_VIDEO) \ ! -L$(X11_LIBDIR) $(XLIBRARY) $(LIB_AUDIO) -lm -o $@ decode_h261: $(HEADERS) $(OBJ_IVS_FILE) $(OBJ_DCT) $(SOURCES)decode_h261.c $(CC) $(CFLAGS) \ *************** *** 139,145 **** $(OBJ_IVS_FILE) \ $(OBJ_DCT) \ $(SOURCES)decode_h261.c \ ! $(XLIBRARY) $(LIB_AUDIO) -lm -o $@ $(LDFLAGS) ivs_record: $(SOURCES)h261.h $(SOURCES)protocol.h \ --- 134,140 ---- $(OBJ_IVS_FILE) \ $(OBJ_DCT) \ $(SOURCES)decode_h261.c \ ! -L$(X11_LIBDIR) $(XLIBRARY) $(LIB_AUDIO) -lm -o $@ ivs_record: $(SOURCES)h261.h $(SOURCES)protocol.h \ *************** *** 149,155 **** $(CCINCL) \ $(PFLAGS) \ protocol.o display.o athena.o $(SOURCES)ivs_record.c \ ! $(XLIBRARY) -lm -o $@ $(LDFLAGS) h261_record: $(SOURCES)h261.h $(SOURCES)protocol.h $(SOURCES)quantizer.h \ protocol.o display.o athena.o $(SOURCES)h261_record.c --- 144,150 ---- $(CCINCL) \ $(PFLAGS) \ protocol.o display.o athena.o $(SOURCES)ivs_record.c \ ! -L$(X11_LIBDIR) $(XLIBRARY) -lm -o $@ h261_record: $(SOURCES)h261.h $(SOURCES)protocol.h $(SOURCES)quantizer.h \ protocol.o display.o athena.o $(SOURCES)h261_record.c *************** *** 158,164 **** $(CCINCL) \ $(PFLAGS) \ protocol.o display.o athena.o $(SOURCES)h261_record.c \ ! -lXaw -lXmu -lXt -lXext -lX11 -lm -o $@ $(LDFLAGS) ivs_replay: $(SOURCES)h261.h $(SOURCES)protocol.h \ $(OBJ) ifct.o video_decoder.o $(SOURCES)ivs_replay.c --- 153,159 ---- $(CCINCL) \ $(PFLAGS) \ protocol.o display.o athena.o $(SOURCES)h261_record.c \ ! -L$(X11_LIBDIR) -lXaw -lXmu -lXt -lXext -lX11 -lm -o $@ ivs_replay: $(SOURCES)h261.h $(SOURCES)protocol.h \ $(OBJ) ifct.o video_decoder.o $(SOURCES)ivs_replay.c *************** *** 167,186 **** $(CCINCL) \ $(PFLAGS) \ $(OBJ) ifct.o video_decoder.o $(SOURCES)ivs_replay.c \ ! $(XLIBRARY) $(LIB_AUDIO) -lm -o $@ $(LDFLAGS) ivsd: $(SOURCES)ivsd.c protocol.o $(CC) $(CFLAGS) \ $(CCDEFS) \ $(CCINCL) \ ! $(PFLAGS) \ ! protocol.o $(SOURCES)ivsd.c $(XLIBRARY) -lm -o $@ $(LDFLAGS) rate: $(SOURCES)rate.c protocol.o $(CC) $(CFLAGS) \ $(CCDEFS) \ $(PFLAGS) \ ! protocol.o $(SOURCES)rate.c -lm -o $@ $(LDFLAGS) clean: rm -f *.o core *~ --- 162,181 ---- $(CCINCL) \ $(PFLAGS) \ $(OBJ) ifct.o video_decoder.o $(SOURCES)ivs_replay.c \ ! -L$(X11_LIBDIR) $(XLIBRARY) $(LIB_AUDIO) -lm -o $@ ivsd: $(SOURCES)ivsd.c protocol.o $(CC) $(CFLAGS) \ $(CCDEFS) \ $(CCINCL) \ ! $(PFLAGS) -L$(X11_LIBDIR) \ ! protocol.o $(SOURCES)ivsd.c $(XLIBRARY) -lm -o $@ rate: $(SOURCES)rate.c protocol.o $(CC) $(CFLAGS) \ $(CCDEFS) \ $(PFLAGS) \ ! protocol.o $(SOURCES)rate.c -lm -o $@ clean: rm -f *.o core *~