From rem-conf-request@es.net Tue Nov 01 06:37:27 1994 Received: from swan.cl.cam.ac.uk by osi-west.es.net via ESnet SMTP service id <25587-0@osi-west.es.net>; Tue, 1 Nov 1994 03:36:58 +0000 Received: from swan.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Tue, 1 Nov 1994 10:40:38 +0000 To: rem-conf@es.net, mbone@ISI.EDU cc: Piete.Brooks@cl.cam.ac.uk Reply-to: Piete.Brooks@cl.cam.ac.uk Subject: Mbone transmission 94/11/2 16:15-17:15 UTC (cl.cam.ac.uk Seminar) Date: Tue, 01 Nov 1994 10:25:07 +0000 From: Piete Brooks Message-ID: <"swan.cl.cam.:081900:941101102527"@cl.cam.ac.uk> We are planning to transmit this week's seminar only within JIPS (ac.uk), unless anyone outside JIPS would like it. If you would, email me the name of your nearest MBone router (if you know it), and I'll set teh TTL accordingly. Please also say if you want video (of the speaker - slides available separately) NAME: John Harrison, University of Cambridge, Computer Laboratory DATE: Wednesday 2nd November 1994 at 4.15pm (16:15 UTC) PLACE: Babbage Lecture Theatre TITLE: Theorem Provers & Computer Algebra Systems Computer theorem provers and computer algebra systems are both aids to symbolic computation. Nevertheless they have quite different design philosophies and are invariably used by different kinds of people. In this talk we draw some contrasts, particularly as regards correctness and ease of use, and suggest ways in which the strengths of both kinds of system can be combined. This seminar will be multicast (audio and video) on the mbone as part of our multimedia test programme. Further information is available at http://www.cl.cam.ac.uk/mbone/#cl. From rem-conf-request@es.net Tue Nov 01 07:02:27 1994 Received: from exxilon.xx.rmit.EDU.AU by osi-west.es.net via ESnet SMTP service id <25791-0@osi-west.es.net>; Tue, 1 Nov 1994 04:02:03 +0000 Received: (richard@localhost) by exxilon.xx.rmit.EDU.AU (8.6.9/8.6.4/ram5) id WAA28304; Tue, 1 Nov 1994 22:59:30 +1100 From: "Richard A. Muirden" Message-Id: <199411011159.WAA28304@exxilon.xx.rmit.EDU.AU> Subject: 7 hour mbone event scheduled To: rem-conf@es.net, mbone@isi.edu Date: Tue, 1 Nov 1994 22:59:30 +1100 (EDT) Cc: epic@rmit.edu.au, gak@rmit.edu.au, richard@exxilon.xx.rmit.EDU.AU (Richard A. Muirden) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3876 Greetings, We wish to schedule the following event for Sunday 27 November 1994 on the mbone. The event will contain Video (nv) at ttil 191 with normal bandwidth and audio (vat) for the 7 hours coverage. A whiteboard session will also be used for feedback, etc. The entry has allready been booked in the Mbone Agenda WWW service. The session will be advertised in 'sd' from approx. 1 week before the event, as per normal practice. see below for more details on the event: regards, richard ---- ......................begin.....transmission................ RMITV PRESENTS E.P.I.C. omnicast E.P.I.C. is an event that will be beamed live across the airwaves from the studios at RMITV on the 27th November 7pm- 2am EST. It will be based around a 7 hour marathon transmission on Melbourne's dynamic community television station, "MCT-31" on the UHF dial. E.P.I.C. is an acronym for the fusion of 'Experimenta' festival , RMITV shows 'PO', 'Inventing The Image' and 'Cyberthon'. 'Experimenta' presented by M.I.M.A. is a biennial event on >from 17-27th November which brings together local, interstate and international artists and speakers to present surveys of film, video, installation and performance art. 'PO' is an interview based documentary which follows the course of local artists and 'Inventing The Image' exposes an Australian selection of the cinema component from the 'Experimenta' selection. 'Cyberthon IV: symmetry in psyburbia', is an annual LIVE-TIME fusion of locally computer generated animation and live electronic music. As part of the 'Experimenta' platform, E.P.I.C. will be exploring its own boundaries; the power of integrated mass communications. E.P.I.C. has united a group of experimental media and visual artists as well as a collective of musicians who will create the form and framework of the show. Apart from television, E.P.I.C. will incorporate press, radio simulcast on RRR and PBS, live music from the Esplanade Hotel, BBS access and Global Internet simulcast. E.P.I.C. is a demonstration of what can be achieved when access media works together. Interact with us on the eve of the E.P.I.C. event, fax us with images, up/download text and graphics. For info on tuning your T.V + VCR to UHF-31 contact MCTC on +61-3-650-5610 or Mr. Antenna, as advertised. E.P.I.C. members invite all households, cafes, band venues, hotels, restaurants and nightclubs to tune there frequencies to MCT-31 on 27th November 1994 AD. For further details on show, artists and for interviews contact: Melissa McArdle (publicity) ph: +61-3-349-2290 @ RMITV STUDIO's NOW - MCT-31 INFO 0055 39931 ON EVE - PH: +61-3-660-3316 ON EVE - FAX: +61-3-660-7305 NOW - EMAIL: epic@rmit.edu.au EPIC PROGRAM @PM - EST 7.00-7.30 Intro (PG) 7.30-9.00 PO + I.T.I + Experimenta (PG) 9.00-11.00 I.T.I + Esplanade Hotel + PBS (M) 11.00-2.00 Cyberthon IV + RRR Tranzmission (M) (also on MBONE and CU-See Me - details TBA) Tune 2 MCT-31, RRR, PBS, BBS, ESPY + MIMA 4 .info To receive a copy of the E.P.I.C. flyer, send an email message to us with the subject line (not the message body) containing one of 'epic.gif', 'epic.jpg', or 'epic.iff'. Image and Layout of Flyer by Artvaak Design & Imagec Image Processing. ....................end....transmission..................... -- Richard A. Muirden, Sys. Admin |Fan of Shostakovich, "Star Trek" and the Boeing Email: richard@rmit.EDU.AU |777 (launch: May 15, 1995 - United Airlines). Phone: (+61 3) 660 3814 |I created alt.fan.shostakovich! Fly: UA,QF,WN http://www.rmit.edu.au/richard |Can *YOU* beat my 95 Shost CD's? :-) ** I used to run a hot dog stand on the information superhighway before the ** McCorporations took over From rem-conf-request@es.net Tue Nov 01 18:18:41 1994 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by osi-west.es.net via ESnet SMTP service id <01625-0@osi-west.es.net>; Tue, 1 Nov 1994 14:40:14 +0000 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU [132.236.199.54]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id RAA26233; Tue, 1 Nov 1994 17:40:09 -0500 X-Sender: rc19@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Nov 1994 18:39:49 -0500 To: rem-conf@es.net From: R.Cogger@cornell.edu (Richard Cogger) Subject: Prince Charles and Global Schoolhouse Cc: John Lynn , Yvonne Marie Andres Folks, On Thursday, Nov. 3rd, at 11:30AM PST, the UK's Prince Charles will be meeting some of the kids from the Global Schoolhouse in LA. Remotely, by CU-SeeMe, kids from Arlington, VA, kids from London, and John Morgridge, Cisco CEO, will be conferencing. The audio will be available via phone bridge. If it works, the London site will be using nv to send and receive video with nv's CU-SeeMe encoder/decoder and a new version of the reflector to translate headers. A number of reflectors around and about will permit some CU-SeeMe users to receive the video. If the mbone community wants us to, we can relay this conference to the mbone for nv reception. We can also patch the audio into VAT. I havn't been keeping up with mbone schedules, so my questions are: Would approx. 3-400Kbps of video and an audio stream be a problem? Do folks want to have this sent on the mbone? Thanks for advice, -Dick From rem-conf-request@es.net Tue Nov 01 18:30:23 1994 Received: from cscgpo.anu.edu.au by osi-west.es.net via ESnet SMTP service id <02696-0@osi-west.es.net>; Tue, 1 Nov 1994 15:29:49 +0000 Received: from octavia.anu.edu.au (octavia.anu.edu.au [150.203.5.35]) by cscgpo.anu.edu.au (8.6.9/8.6.9) with SMTP id KAA22224 for ; Wed, 2 Nov 1994 10:29:19 +1100 Received: by octavia.anu.edu.au (4.1/SMI-4.1) id AA17482; Wed, 2 Nov 94 10:28:16 EST Date: Wed, 2 Nov 94 10:28:16 EST From: markus@octavia.anu.edu.au (Markus Buchhorn) Message-Id: <9411012328.AA17482@octavia.anu.edu.au> To: jed@llnl.gov Subject: MBone Session Agenda page and timezones Cc: calegari@imicilea.cilea.it, mbone@isi.edu, rem-conf@es.net [Hope you don't mind that I cc'ed the lists - see below] >From Jed: > What is actually needed is the ability to: > > 1. Enter a date and local time (with its time zone) and have > returned an equivalent GMT date and time, and > 2. Enter a GMT date and time and a local time zone and have > returned an equivalent local date and time. > > I mentioned this problem once in the mbone list and eventuly > Markus Buchhorn picked up the challange of being the time > hero of our time. However, I believe his latest effort (I think > included below) still falls short. Oh - I see, butter them up and then take the shine off. I know your types and we call them nasty things round here... :-) > Also it isn't a Web page (which would be very convenient). People assure me that it is quite easy to write a home page that is in fact in a script/program - all it needs to do is echo 'text/html' (?) as it's first response to an http request and then echo your html text. The CGI scripts provided with Mosaic have a few examples. Now - I haven't done this yet, but it shouldn't be too hard. I'm sure there are many WWW gurus out there...._hint_.... > The most > interesting part of the problem to me is how to keep up-to-date > on when the different time zones go to/from "daylight savings time". Not interesting - a pain. There is no 'standard' for naming timezones, and there's even disagreement within some time zones ! (do you use DS or D for daylight savings, or S (summertime) which conflicts with S (standard). Thus Australia's east coast has AEST or just EST, which becomes EDT, AEDT, EDST, or, help us, AEDST. Descriptive, though. :-) I'd hate to tabulate them all, and when they change to/from DS, which can vary year to year, state to state... However, local sites have a vested interest in getting their own timezones right. _We_ shouldn't care about _their_ codes or conversions. Now a Web page for MBONE events should only use one timezone for obvious reasons, and the easiest one to convert to is GMT (UTC for the purists). Hence the gmtoff.pl script. Everybody has an interest in advertising the right time, so the advertiser should make sure they convert correctly to 'the standard' (at least, the easiest standard :-) ). [...] So - let me present gmtoff.pl version 1.2. No args (as before) prints the current offset to GMT. -l or -g converts the time argument to local or GMT respectively. The time arg has to be in quotes to get treated as a single argument. e.g: (we've just started DS) markus@octavia% gmtoff Localtime is 11.0 hours ahead of GMT markus@octavia% gmtoff -g '9:00:00 3 11 94' The input local time/date converts to: 02 Nov 94 at 22:00:00 GMT markus@octavia% gmtoff -l '9:00:00 3 11 94' The input GMT time/date converts to: 03 Nov 94 at 20:00:00 localtime Hope you find it useful. I'll leave the Mosaic stuff to others - I'm still working on several basic home pages, before we get into services... :-). I also have a man page kindly written by Rick Rodgers that I'll update eventually (unless you'd like to, Rick ? :-) ). As before, please test locally and let me know if it croaks. I don't have worldwide accounts to test it out myself :-). 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] -------------snip----snip----snip------------------------------------------ #!/usr/new/bin/perl # Modify above line to point to your local perl location... # # Markus.Buchhorn@anu.edu.au, 5th October 1994 # v1.1 Fixed bug in no arg case, Added rounding of output, Changed output # of converted date to printf. 6 Oct 94. # v1.11 Removed rounding and used printf instead. Beware int()'s of negatives # v1.2 Changed to use -l 'time' or -g 'time' to convert gmt2local or # local2gmt respectively. 2 Nov 94. # # Uses Perl interface to time() system calls. # No args = display offset of GMT from localtime # -l 'time' = display localtime version of input GMT # -g 'time' = display GMT version of input localtime # The input date is required to be in the form hh:mm:ss DD MM YY, and # needs to be in quotes (treated as a single arg). require "timelocal.pl"; require "getopts.pl"; &Getopts('l:g:'); if ($opt_g||$opt_l) { if ($opt_g) { @tstamp = split(' ',$opt_g); } else { @tstamp = split(' ',$opt_l); } @qtime = split(/:/,$tstamp[0]); if ($#qtime != 2) {die "Usage: $0 hh:mm:ss DD MM YY\n";} $qarray[0] = $qtime[2]; $qarray[1] = $qtime[1]; $qarray[2] = $qtime[0]; $qarray[3] = $tstamp[1]; $qarray[4] = $tstamp[2]-1; $qarray[5] = $tstamp[3]; if ($tstamp[3] > 100) {$qarray[5] -= 1900;} if($opt_g) { $qltime = &timelocal(@qarray); ($qsec,$qmin,$qhr,$qmday,$qmon,$qyear,$qwday,$qyday,$qisdst) = gmtime($qltime); $qmon = (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec)[$qmon]; printf STDOUT ("The input local time/date converts to: %02d %s %02d at %02d:%02d:%02d GMT\n", $qmday, $qmon, $qyear, $qhr, $qmin, $qsec); exit; } else { $qgtime = &timegm(@qarray); ($qsec,$qmin,$qhr,$qmday,$qmon,$qyear,$qwday,$qyday,$qisdst) = localtime($qgtime); $qmon = (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec)[$qmon]; printf STDOUT ("The input GMT time/date converts to: %02d %s %02d at %02d:%02d:%02d localtime\n", $qmday, $qmon, $qyear, $qhr, $qmin, $qsec); exit; } } # ------------------------------------------------------ # If we get here then we want just the offset ($gsec,$gmin,$ghr,$gmday,$gmon,$gyear,$gwday,$gyday,$gisdst) = gmtime(time); ($sec,$min,$hr,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); $GMT = $gyday + ((($ghr*3600)+($gmin*60))/86400); $LT = $yday + ((($hr*3600) +($min*60))/86400); $OFFSET = ($LT - $GMT)*24; if ($OFFSET >= 0) { printf STDOUT ("Localtime is %3.1f hours ahead of GMT\n",$OFFSET); } else { $OFFSET = -$OFFSET; printf STDOUT ("Localtime is %3.1f hours behind GMT\n",$OFFSET); } exit; From rem-conf-request@es.net Tue Nov 01 22:01:32 1994 Received: from harry.lloyd.com by osi-west.es.net via ESnet SMTP service id <04971-0@osi-west.es.net>; Tue, 1 Nov 1994 19:00:58 +0000 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #5) id m0r2VwL-0005b0C; Tue, 1 Nov 94 19:00 PST Message-Id: X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Nov 1994 19:00:46 -0800 To: R.Cogger@cornell.edu (Richard Cogger), rem-conf@es.net From: brian@lloyd.com (Brian Lloyd) Subject: Re: Prince Charles and Global Schoolhouse Cc: John Lynn , Yvonne Marie Andres At 18:39 11/1/94 -0500, Richard Cogger wrote: >Folks, > On Thursday, Nov. 3rd, at 11:30AM PST, the UK's Prince Charles will >be meeting some of the kids from the Global Schoolhouse in LA. Remotely, >by CU-SeeMe, kids from Arlington, VA, kids from London, and John Morgridge, >Cisco CEO, will be conferencing. The audio will be available via phone >bridge. >If it works, the London site will be using nv to send and receive video >with nv's CU-SeeMe encoder/decoder and a new version of the reflector to >translate headers. A number of reflectors around and about will permit >some CU-SeeMe users to receive the video. > If the mbone community wants us to, we can relay this conference to >the mbone for nv reception. We can also patch the audio into VAT. I >havn't been keeping up with mbone schedules, so my questions are: > >Would approx. 3-400Kbps of video and an audio stream be a problem? Surely you jest! >Do folks want to have this sent on the mbone? > >Thanks for advice, -Dick Gee, I am sure this will advance education world-wide. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From rem-conf-request@es.net Tue Nov 01 23:08:23 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <05398-0@osi-west.es.net>; Tue, 1 Nov 1994 20:07:55 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Tue, 1 Nov 1994 20:07:50 -0800 Posted-Date: Tue 1 Nov 94 20:06:42 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 1 Nov 94 20:06:43 PST Date: Tue 1 Nov 94 20:06:42 PST From: Stephen Casner Subject: Re: MBONE setup questions To: rsn@spl42.spl.loral.com, rem-conf@es.net Message-Id: <783749202.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9410281642.AA00769@spl42.spl.loral.com> Mail-System-Version: > I am having problems launching 'wb' from 'sd'. I get an error > which remarks that the perameters are incorrect for 'wb'. The 'vat' > launchs correctly. Any ideas? You need a .sd.tcl file that fixes the calling parameters to wb for changes made since sd was produced. See the wb documentation for details. > Is is possible to design 'sd' such that I need only provide an address > to what is now a remote tunnel site rather than the setup of 'mrouted'. > I frame this question from the prospective of a end-site/user/LISTENER > to allow a faster configuration of 'sd' to public broadcasts. Obviously > to transmit, 'mrouted' is required, but for the VAST net community, > listening will be the extent of there use. No. An mrouted tunnel (or some method of multicast routing) is required to get the multicast packets to you just as much as it is required for you to be able to transmit multicast packets to the MBone. > Media on Demand is an example which does not need 'mrouted' A media stream could be sent to you individually on demand as a unicast stream. However, to tune in to "public broadcasts" which are sent via multicast for bandwidth efficiency to many places at once, you must get multicast routing. Eventually everyone should have it. -- Steve ------- From rem-conf-request@es.net Wed Nov 02 13:30:41 1994 Received: from icm1.icp.net by osi-west.es.net via ESnet SMTP service id <07806-0@osi-west.es.net>; Wed, 2 Nov 1994 01:27:44 +0000 Received: from stpb.soft.net ([164.164.4.5]) by icm1.icp.net (8.6.9/8.6.9) with SMTP id EAA28620 for ; Wed, 2 Nov 1994 04:26:36 -0500 Received: from uranium.bfl.soft.net (bfl.soft.net) by stpb.soft.net (4.1/SMI-4.1) id AA11202; Wed, 2 Nov 94 14:55:08+0530 X-Organisation: Software Technology Park, Bangalore Received: by uranium.bfl.soft.net (BOSX 3.2/UCB 5.64/4.03) id AA13728; Wed, 2 Nov 1994 14:55:01 GMT Date: Wed, 2 Nov 1994 14:55:01 GMT From: arun@uranium.bfl.soft.net (ARUN PRASAD) Message-Id: <9411021455.AA13728@uranium.bfl.soft.net> To: rem-conf@es.net Subject: Req for Info Hi, I wish to join the news group on "VIDEO CONFERENCING" Please put me on the mailing list. ARUN PASASD PROJECT LEADER BFL SOFTWARE LIMITED 45/3 RESIDENCY ROAD BANGALORE 560 025 INDIA From rem-conf-request@es.net Wed Nov 02 13:33:32 1994 Received: from amway.ch.apollo.hp.com by osi-west.es.net via ESnet SMTP service id <11718-0@osi-west.es.net>; Wed, 2 Nov 1994 10:16:35 +0000 Original-Received: from alexx.ch.apollo.hp.com by amway.ch.apollo.hp.com id Wed, 2 Nov 1994 13:16:32 -0500 PP-warning: Illegal Received field on preceding line Received: by alexx.ch.apollo.hp.com id ; Wed, 2 Nov 1994 13:16:31 -0500 From: root@alexx.ch.apollo.hp.com Subject: MBone Session Agenda page and timezones (fwd) To: jed@llnl.gov Date: Wed, 2 Nov 94 13:16:31 EST Cc: calegari@imicilea.cilea.it, mbone@isi.edu, rem-conf@es.net Mailer: Elm [revision: 70.85] [Hope you don't mind that I cc'ed the lists - see below] >From Jed: > What is actually needed is the ability to: > > 1. Enter a date and local time (with its time zone) and have > returned an equivalent GMT date and time, and > 2. Enter a GMT date and time and a local time zone and have > returned an equivalent local date and time. > > I mentioned this problem once in the mbone list and eventuly > Markus Buchhorn picked up the challange of being the time > hero of our time. However, I believe his latest effort (I think > included below) still falls short. Oh - I see, butter them up and then take the shine off. I know your types and we call them nasty things round here... :-) > Also it isn't a Web page (which would be very convenient). People assure me that it is quite easy to write a home page that is in fact in a script/program - all it needs to do is echo 'text/html' (?) as it's first response to an http request and then echo your html text. The CGI scripts provided with Mosaic have a few examples. Now - I haven't done this yet, but it shouldn't be too hard. I'm sure there are many WWW gurus out there...._hint_.... > The most > interesting part of the problem to me is how to keep up-to-date > on when the different time zones go to/from "daylight savings time". Not interesting - a pain. There is no 'standard' for naming timezones, and there's even disagreement within some time zones ! (do you use DS or D for daylight savings, or S (summertime) which conflicts with S (standard). Thus Australia's east coast has AEST or just EST, which becomes EDT, AEDT, EDST, or, help us, AEDST. Descriptive, though. :-) I'd hate to tabulate them all, and when they change to/from DS, which can vary year to year, state to state... However, local sites have a vested interest in getting their own timezones right. _We_ shouldn't care about _their_ codes or conversions. Now a Web page for MBONE events should only use one timezone for obvious reasons, and the easiest one to convert to is GMT (UTC for the purists). Hence the gmtoff.pl script. Everybody has an interest in advertising the right time, so the advertiser should make sure they convert correctly to 'the standard' (at least, the easiest standard :-) ). [...] So - let me present gmtoff.pl version 1.2. No args (as before) prints the current offset to GMT. -l or -g converts the time argument to local or GMT respectively. The time arg has to be in quotes to get treated as a single argument. e.g: (we've just started DS) markus@octavia% gmtoff Localtime is 11.0 hours ahead of GMT markus@octavia% gmtoff -g '9:00:00 3 11 94' The input local time/date converts to: 02 Nov 94 at 22:00:00 GMT markus@octavia% gmtoff -l '9:00:00 3 11 94' The input GMT time/date converts to: 03 Nov 94 at 20:00:00 localtime Hope you find it useful. I'll leave the Mosaic stuff to others - I'm still working on several basic home pages, before we get into services... :-). I also have a man page kindly written by Rick Rodgers that I'll update eventually (unless you'd like to, Rick ? :-) ). As before, please test locally and let me know if it croaks. I don't have worldwide accounts to test it out myself :-). 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] -------------snip----snip----snip------------------------------------------ #!/usr/new/bin/perl # Modify above line to point to your local perl location... # # Markus.Buchhorn@anu.edu.au, 5th October 1994 # v1.1 Fixed bug in no arg case, Added rounding of output, Changed output # of converted date to printf. 6 Oct 94. # v1.11 Removed rounding and used printf instead. Beware int()'s of negatives # v1.2 Changed to use -l 'time' or -g 'time' to convert gmt2local or # local2gmt respectively. 2 Nov 94. # # Uses Perl interface to time() system calls. # No args = display offset of GMT from localtime # -l 'time' = display localtime version of input GMT # -g 'time' = display GMT version of input localtime # The input date is required to be in the form hh:mm:ss DD MM YY, and # needs to be in quotes (treated as a single arg). require "timelocal.pl"; require "getopts.pl"; &Getopts('l:g:'); if ($opt_g||$opt_l) { if ($opt_g) { @tstamp = split(' ',$opt_g); } else { @tstamp = split(' ',$opt_l); } @qtime = split(/:/,$tstamp[0]); if ($#qtime != 2) {die "Usage: $0 hh:mm:ss DD MM YY\n";} $qarray[0] = $qtime[2]; $qarray[1] = $qtime[1]; $qarray[2] = $qtime[0]; $qarray[3] = $tstamp[1]; $qarray[4] = $tstamp[2]-1; $qarray[5] = $tstamp[3]; if ($tstamp[3] > 100) {$qarray[5] -= 1900;} if($opt_g) { $qltime = &timelocal(@qarray); ($qsec,$qmin,$qhr,$qmday,$qmon,$qyear,$qwday,$qyday,$qisdst) = gmtime($qltime); $qmon = (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec)[$qmon]; printf STDOUT ("The input local time/date converts to: %02d %s %02d at %02d:%02d:%02d GMT\n", $qmday, $qmon, $qyear, $qhr, $qmin, $qsec); exit; } else { $qgtime = &timegm(@qarray); ($qsec,$qmin,$qhr,$qmday,$qmon,$qyear,$qwday,$qyday,$qisdst) = localtime($qgtime); $qmon = (Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec)[$qmon]; printf STDOUT ("The input GMT time/date converts to: %02d %s %02d at %02d:%02d:%02d localtime\n", $qmday, $qmon, $qyear, $qhr, $qmin, $qsec); exit; } } # ------------------------------------------------------ # If we get here then we want just the offset ($gsec,$gmin,$ghr,$gmday,$gmon,$gyear,$gwday,$gyday,$gisdst) = gmtime(time); ($sec,$min,$hr,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time); $GMT = $gyday + ((($ghr*3600)+($gmin*60))/86400); $LT = $yday + ((($hr*3600) +($min*60))/86400); $OFFSET = ($LT - $GMT)*24; if ($OFFSET >= 0) { printf STDOUT ("Localtime is %3.1f hours ahead of GMT\n",$OFFSET); } else { $OFFSET = -$OFFSET; printf STDOUT ("Localtime is %3.1f hours behind GMT\n",$OFFSET); } exit; From rem-conf-request@es.net Wed Nov 02 13:38:17 1994 Received: from monge.brunel.ac.uk by osi-west.es.net via ESnet SMTP service id <09699-0@osi-west.es.net>; Wed, 2 Nov 1994 06:08:31 +0000 Received: from babbage.brunel.ac.uk by monge.brunel.ac.uk with SMTP (PP) id <04303-0@monge.brunel.ac.uk>; Wed, 2 Nov 1994 14:07:55 +0000 From: Andrew Findlay Message-Id: <1126.9411021407@babbage.brunel.ac.uk> Subject: Re: Prince Charles and Global Schoolhouse To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Wed, 2 Nov 1994 14:07:52 +0000 (GMT) Cc: J.Crowcroft@cs.ucl.ac.uk, brian@lloyd.com, R.Cogger@cornell.edu, jal7@cornell.edu, andresyv@nic.cerf.net, rem-conf@es.net In-Reply-To: <4363.783778993@cs.ucl.ac.uk> from "Mark Handley" at Nov 2, 94 12:23:13 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 713 >But we won't have the new link up by tomorrow :-( Internationally, >much of the Mbone doesn't handle 512Kbps very well, so I would suggest >you go for only 200Kbps of video if you don't want bad loss to >the UK. Also remember that becasue the conference is being conducted with CuSee-Me protocols, the whole lot will *also* be coming unicast to Brunel as we are one of the participating sites. Andrew ---------------------------------------------------------------------------- | From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK | | Andrew.Findlay@brunel.ac.uk +44 1895 203066 or +44 1895 274000 x2512 | ---------------------------------------------------------------------------- From rem-conf-request@es.net Wed Nov 02 13:39:28 1994 Received: from amway.ch.apollo.hp.com by osi-west.es.net via ESnet SMTP service id <12866-0@osi-west.es.net>; Wed, 2 Nov 1994 10:38:33 +0000 Original-Received: from alexx.ch.apollo.hp.com by amway.ch.apollo.hp.com id Wed, 2 Nov 1994 13:38:30 -0500 PP-warning: Illegal Received field on preceding line Received: by alexx.ch.apollo.hp.com id ; Wed, 2 Nov 1994 13:38:29 -0500 From: root@alexx.ch.apollo.hp.com Subject: Re: MBONE setup questions (fwd) To: rsn@spl42.spl.loral.com, rem-conf@es.net Date: Wed, 2 Nov 94 13:38:29 EST Mailer: Elm [revision: 70.85] > I am having problems launching 'wb' from 'sd'. I get an error > which remarks that the perameters are incorrect for 'wb'. The 'vat' > launchs correctly. Any ideas? You need a .sd.tcl file that fixes the calling parameters to wb for changes made since sd was produced. See the wb documentation for details. > Is is possible to design 'sd' such that I need only provide an address > to what is now a remote tunnel site rather than the setup of 'mrouted'. > I frame this question from the prospective of a end-site/user/LISTENER > to allow a faster configuration of 'sd' to public broadcasts. Obviously > to transmit, 'mrouted' is required, but for the VAST net community, > listening will be the extent of there use. No. An mrouted tunnel (or some method of multicast routing) is required to get the multicast packets to you just as much as it is required for you to be able to transmit multicast packets to the MBone. > Media on Demand is an example which does not need 'mrouted' A media stream could be sent to you individually on demand as a unicast stream. However, to tune in to "public broadcasts" which are sent via multicast for bandwidth efficiency to many places at once, you must get multicast routing. Eventually everyone should have it. -- Steve ------- From rem-conf-request@es.net Wed Nov 02 13:45:14 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <05821-0@osi-west.es.net>; Tue, 1 Nov 1994 21:14:39 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14489(8)>; Tue, 1 Nov 1994 21:14:23 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12172>; Tue, 1 Nov 1994 21:14:14 -0800 To: rem-conf@es.net Cc: deering@parc.xerox.com Subject: Rolling Stones mbone-cast Date: Tue, 1 Nov 1994 21:14:03 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Nov1.211414pst.12172@skylark.parc.xerox.com> According to taday's San Jose Mercury News: On Nov. 18, the Stones will "multicast" a 20-minute teaser from their concert in Dallas over Mbone, a way to send video over the Internet. The concert snippet will be rebroadcast every 20 minutes. So, have the Stones sent a message to rem-conf checking for conflicts yet? The Stones web site (http://www.stones.com, of course) has been claiming for a while that: This fall, a selected date of the Rolling Stones Voodoo Lounge Tour will be transmitted live over the MBONE. You can see Mick and Keith and the boys whooping it up in stadiums across the country without ever leaving the radioactive glow of your workstation. but the Murky News article is the first report I've seen of a specific date. I'm disappointed to see that it will just be a 20-minute "teaser" -- basically just a commercial -- but I'm also bummed that I have to be away at a meeting all that day. I hope someone records it (if it actually happens -- these sorts of events often fizzle for any number of technical reasons, sad to say.) Does anybody know more about this? Like, who is providing the MBone tunnel to the Dallas stadium? I see that Sun is co-sponsoring the web page, but are they also involved in the planned mbone-cast? Steve p.s. We'll know that the Mbone has gone mainstream when the papers no longer put "multicast" in quotation marks. :-) From rem-conf-request@es.net Wed Nov 02 13:45:20 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <07596-0@osi-west.es.net>; Wed, 2 Nov 1994 01:10:27 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Nov 1994 09:10:12 +0000 To: Steve Deering cc: rem-conf@es.net Subject: Re: Rolling Stones mbone-cast In-reply-to: Your message of "Tue, 01 Nov 94 21:14:03 PST." <94Nov1.211414pst.12172@skylark.parc.xerox.com> Date: Wed, 02 Nov 94 09:10:09 +0000 Message-ID: <718.783767409@cs.ucl.ac.uk> From: Jon Crowcroft >p.s. We'll know that the Mbone has gone mainstream when the papers no > longer put "multicast" in quotation marks. :-) we'll know that the "mbone" has gone mainstream when the kids 'cast some contemporary music:-) jon From rem-conf-request@es.net Wed Nov 02 13:45:25 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <09066-0@osi-west.es.net>; Wed, 2 Nov 1994 04:25:06 +0000 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Nov 1994 12:23:52 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Jon Crowcroft cc: brian@lloyd.com (Brian Lloyd), R.Cogger@cornell.edu (Richard Cogger), John Lynn , Yvonne Marie Andres , rem-conf@es.net Subject: Re: Prince Charles and Global Schoolhouse In-reply-to: Your message of "Wed, 02 Nov 94 09:16:28 GMT." <813.783767788@cs.ucl.ac.uk> Date: Wed, 02 Nov 94 12:23:13 +0000 Message-ID: <4363.783778993@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk > >>translate headers. A number of reflectors around and about will permit > >>some CU-SeeMe users to receive the video. > > >>Would approx. 3-400Kbps of video and an audio stream be a problem? > > >Surely you jest! >the mbone can sustain around 512kbps (says steve casner, and certainly >in the UK, we can handle ~10Mbps internally...and we are >re-engineering the international feeds to be able to sustain >764kbps mbone frm the US without disturbing " so called " normal unicast >services...) - remember, if you run pruning mrouted, you don't get >what you don't want - if you don't run pruning mrouted, you deserve >everything you get:-) But we won't have the new link up by tomorrow :-( Internationally, much of the Mbone doesn't handle 512Kbps very well, so I would suggest you go for only 200Kbps of video if you don't want bad loss to the UK. Also saying we have 10Mbps in the UK is a bit optimistic - Although SuperJanet would probably cope, the NOC transit nets and mrouted suns would turn belly up way before that level. Mark From rem-conf-request@es.net Wed Nov 02 13:45:30 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <07637-0@osi-west.es.net>; Wed, 2 Nov 1994 01:16:23 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Nov 1994 09:15:49 +0000 To: brian@lloyd.com (Brian Lloyd) cc: R.Cogger@cornell.edu (Richard Cogger), John Lynn , Yvonne Marie Andres , rem-conf@es.net Subject: Re: Prince Charles and Global Schoolhouse In-reply-to: Your message of "Tue, 01 Nov 94 19:00:46 PST." Date: Wed, 02 Nov 94 09:15:47 +0000 Message-ID: <810.783767747@cs.ucl.ac.uk> From: Jon Crowcroft >>translate headers. A number of reflectors around and about will permit >>some CU-SeeMe users to receive the video. >>Would approx. 3-400Kbps of video and an audio stream be a problem? >Surely you jest! the mbone can sustain around 512kbps (says steve casner, and certainly in the UK, we can handle ~10Mbps internally...and we are re-engineering the international feeds to be able to sustain 764kbps mbone frm the US without disturbing " so called " normal unicast services...) >>Do folks want to have this sent on the mbone? >>Thanks for advice, -Dick yes please. >Gee, I am sure this will advance education world-wide. firmly into cheek> last time around, we were privalaged to run the uk end of the gobal schoolhouse - the value for the children involved was immense, even though it was juts a demo....the effect was proably severla times greater than the _most_ succesful net-nerd typical mbone use for people like me... jon From rem-conf-request@es.net Wed Nov 02 13:45:34 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <07650-0@osi-west.es.net>; Wed, 2 Nov 1994 01:17:27 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 2 Nov 1994 09:16:29 +0000 To: brian@lloyd.com (Brian Lloyd) cc: R.Cogger@cornell.edu (Richard Cogger), John Lynn , Yvonne Marie Andres , rem-conf@es.net Subject: Re: Prince Charles and Global Schoolhouse In-reply-to: Your message of "Tue, 01 Nov 94 19:00:46 PST." Date: Wed, 02 Nov 94 09:16:28 +0000 Message-ID: <813.783767788@cs.ucl.ac.uk> From: Jon Crowcroft >>translate headers. A number of reflectors around and about will permit >>some CU-SeeMe users to receive the video. >>Would approx. 3-400Kbps of video and an audio stream be a problem? >Surely you jest! the mbone can sustain around 512kbps (says steve casner, and certainly in the UK, we can handle ~10Mbps internally...and we are re-engineering the international feeds to be able to sustain 764kbps mbone frm the US without disturbing " so called " normal unicast services...) - remember, if you run pruning mrouted, you don't get what you don't want - if you don't run pruning mrouted, you deserve everything you get:-) >>Do folks want to have this sent on the mbone? >>Thanks for advice, -Dick yes please. >Gee, I am sure this will advance education world-wide. firmly into cheek> last time around, we were privalaged to run the uk end of the gobal schoolhouse - the value for the children involved was immense, even though it was juts a demo....the effect was proably severla times greater than the _most_ succesful net-nerd typical mbone use for people like me... jon From rem-conf-request@es.net Wed Nov 02 13:45:38 1994 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <07828-0@osi-west.es.net>; Wed, 2 Nov 1994 01:36:21 +0000 Via: uk.ac.edinburgh.festival; Wed, 2 Nov 1994 09:34:59 +0000 Received: from cancer.ucs.ed.ac.uk by festival.ed.ac.uk id aa16205; 2 Nov 94 9:34 GMT Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Wed, 2 Nov 94 09:34:45 GMT Date: Wed, 2 Nov 1994 09:34:44 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.edinburgh.ac.uk To: Perry Wagle Cc: mbone@isi.edu, rem-conf@es.net, reini@cosy.sbg.ac.at Subject: Re: sparc 5 audio In-Reply-To: <199411011855.AA02682@venera.isi.edu> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 1 Nov 1994, Perry Wagle wrote: > We just got a Sparc 5 which we are running SunOS 4.1.3_U1 on. The audio > is terrible. I thought I saw patches for this or something like it fly > past on this list, but I somehow failed to save them. Could someone > email me the patches if they exist? > > If there is a archive that I should have looked it, email me that, and I > will post that information, once, to this list. [Sorry for the cross-post on rem-conf but people have been complaining about this for some time and would like to publicise the news as widely as possible.] Sun have just released new patches for the SPARC 5. I do not think that they have fixed all the problems yet but I have been through an extensive testing process with Sun and believe that the DMA hangs and kernel panics have now been fixed. The patches you should install are 101508-07 and 102161-01. In order to get tolerable audio without too many dropouts, after applying the patches I needed to set the audio buffer size to 1200. To do this you need to do: adb -k -w /vmunix /dev/mem audio_4231_bsize/W 0t1200 audio_4231_bsize?W 0t1200 $q You will still notice a slight clicking sound throughout the audio playback but it is certainly livable with. I am still negotiating with Sun to get this fixed so hopefully there will be a further version of the patch. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Wed Nov 02 13:45:43 1994 Received: from lupine.nsi.nasa.gov by osi-west.es.net via ESnet SMTP service id <09729-0@osi-west.es.net>; Wed, 2 Nov 1994 06:16:05 +0000 Received: (from mnewell@localhost) by lupine.nsi.nasa.gov (8.6.9/8.6.9) id JAA06149; Wed, 2 Nov 1994 09:14:45 -0500 Date: Wed, 2 Nov 1994 09:14:41 -0500 (EST) From: "Michael C. Newell" To: "Richard A. Muirden" cc: rem-conf@es.net, mbone@ISI.EDU, epic@rmit.edu.au, gak@rmit.edu.au, "Richard A. Muirden" Subject: Re: 7 hour mbone event scheduled In-Reply-To: <199411011159.WAA28304@exxilon.xx.rmit.EDU.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Oh God - ARTISTS on the Net!!! ;{( Mike On Tue, 1 Nov 1994, Richard A. Muirden wrote: > Date: Tue, 1 Nov 1994 22:59:30 +1100 (EDT) > From: Richard A. Muirden > To: rem-conf@es.net, mbone@ISI.EDU > Cc: epic@rmit.edu.au, gak@rmit.edu.au, > "Richard A. Muirden" > Subject: 7 hour mbone event scheduled > > Greetings, > > We wish to schedule the following event for Sunday 27 November 1994 on > the mbone. > > The event will contain Video (nv) at ttil 191 with normal bandwidth and > audio (vat) for the 7 hours coverage. > > A whiteboard session will also be used for feedback, etc. > > The entry has allready been booked in the Mbone Agenda WWW service. > > The session will be advertised in 'sd' from approx. 1 week before > the event, as per normal practice. > > see below for more details on the event: > > regards, > richard > ---- > > ......................begin.....transmission................ > > > > RMITV PRESENTS E.P.I.C. omnicast > > E.P.I.C. is an event that will be beamed live across the > airwaves from the studios at RMITV on the 27th November 7pm- > 2am EST. It will be based around a 7 hour marathon > transmission on Melbourne's dynamic community television > station, "MCT-31" on the UHF dial. > > E.P.I.C. is an acronym for the fusion of 'Experimenta' > festival , RMITV shows 'PO', 'Inventing The Image' and > 'Cyberthon'. > > 'Experimenta' presented by M.I.M.A. is a biennial event on > from 17-27th November which brings together local, > interstate and international artists and speakers to present > surveys of film, video, installation and performance art. > 'PO' is an interview based documentary which follows the > course of local artists and 'Inventing The Image' exposes an > Australian selection of the cinema component from the > 'Experimenta' selection. 'Cyberthon IV: symmetry in > psyburbia', is an annual LIVE-TIME fusion of locally > computer generated animation and live electronic music. > > As part of the 'Experimenta' platform, E.P.I.C. will be > exploring its own boundaries; the power of integrated mass > communications. E.P.I.C. has united a group of experimental > media and visual artists as well as a collective of > musicians who will create the form and framework of the > show. Apart from television, E.P.I.C. will incorporate > press, radio simulcast on RRR and PBS, live music from the > Esplanade Hotel, BBS access and Global Internet simulcast. > E.P.I.C. is a demonstration of what can be achieved when > access media works together. > > Interact with us on the eve of the E.P.I.C. event, fax us > with images, up/download text and graphics. > > For info on tuning your T.V + VCR to UHF-31 contact MCTC on > +61-3-650-5610 or Mr. Antenna, as advertised. > > E.P.I.C. members invite all households, cafes, band venues, > hotels, restaurants and nightclubs to tune there frequencies > to MCT-31 on 27th November 1994 AD. > > For further details on show, artists and for interviews > contact: Melissa McArdle (publicity) ph: +61-3-349-2290 > > @ RMITV STUDIO's > NOW - MCT-31 INFO 0055 39931 > ON EVE - PH: +61-3-660-3316 > ON EVE - FAX: +61-3-660-7305 > NOW - EMAIL: epic@rmit.edu.au > > EPIC PROGRAM @PM - EST > 7.00-7.30 Intro (PG) > 7.30-9.00 PO + I.T.I + Experimenta (PG) > 9.00-11.00 I.T.I + Esplanade Hotel + PBS (M) > 11.00-2.00 Cyberthon IV + RRR Tranzmission (M) > (also on MBONE and CU-See Me - details TBA) > Tune 2 MCT-31, RRR, PBS, BBS, ESPY + MIMA 4 .info > > > To receive a copy of the E.P.I.C. flyer, send an email > message to us with the subject line (not the message body) > containing one of 'epic.gif', 'epic.jpg', or 'epic.iff'. > Image and Layout of Flyer by Artvaak Design & Imagec Image > Processing. > > > ....................end....transmission..................... > > -- > Richard A. Muirden, Sys. Admin |Fan of Shostakovich, "Star Trek" and the Boeing > Email: richard@rmit.EDU.AU |777 (launch: May 15, 1995 - United Airlines). > Phone: (+61 3) 660 3814 |I created alt.fan.shostakovich! Fly: UA,QF,WN > http://www.rmit.edu.au/richard |Can *YOU* beat my 95 Shost CD's? :-) > ** I used to run a hot dog stand on the information superhighway before the ** > McCorporations took over > Thanks, Mike +--------------------------------------+------------------------------------+ |Mike Newell | The opinions expressed herein are | |NASA Science Internet Network Systems | my own, and do not necessarily | |Sterling Software, Inc. | reflect those of the NSI program, | |MNewell@nsipo.nasa.gov | Sterling Software, NASA, or anyone | |+1-202-434-8954 | else. | +--------------------------------------+------------------------------------+ From rem-conf-request@es.net Wed Nov 02 13:45:48 1994 Received: from harry.lloyd.com by osi-west.es.net via ESnet SMTP service id <10984-0@osi-west.es.net>; Wed, 2 Nov 1994 09:01:27 +0000 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #5) id m0r2j3Q-0005b1C; Wed, 2 Nov 94 09:00 PST Message-Id: X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Nov 1994 09:00:58 -0800 To: Jon Crowcroft , brian@lloyd.com (Brian Lloyd) From: brian@lloyd.com (Brian Lloyd) Subject: Re: Prince Charles and Global Schoolhouse Cc: R.Cogger@cornell.edu (Richard Cogger), John Lynn , Yvonne Marie Andres , rem-conf@es.net Brian Lloyd said: > >Gee, I am sure this will advance education world-wide. >firmly into cheek> > At 9:15 11/2/94 +0000, Jon Crowcroft wrote: >last time around, we were privalaged to run the uk end of the gobal >schoolhouse - the value for the children involved was immense, even >though it was juts a demo....the effect was proably severla times >greater than the _most_ succesful net-nerd typical mbone use for >people like me... Hmmm ... it would be interesting to see how you quantify "immense." I hope you will forgive me for remaining skeptical. There seems to be a strong propensity toward "exciting" high-visibility uses of the Internet, especially teleconferencing technology. You know, the kind of thing that attracts the broadcast media and has high-level officials patting each other on the back in self congratulations for how education in is being well served. Frankly this type of use does not strike me as truely advancing education in a long-lasting, meaningful way. Yes it does raise the visibility of the technology as a potentially useful tool but, IMHO, it does not bring the tool closer to the schoolhouse in a meaningful way. I would *really* like to see an example of how two "ordinary" teachers in "ordinary" schools have found a use for this same technology in the course of their "ordinary" curriculum. Cross disciplinary and cross grade-level use, e.g. a high-school chemistry class working with a college biology class on a local/regional ecology project using multiple Internet tools, would excite me much more. And please do not misconstrue this to imply that this technology is only applicable to technical subjects. Certainly On the other hand, I guess I just don't grasp the larger picture. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From rem-conf-request@es.net Wed Nov 02 13:45:53 1994 Received: from nic.cerf.net by osi-west.es.net via ESnet SMTP service id <11261-0@osi-west.es.net>; Wed, 2 Nov 1994 09:41:09 +0000 Received: (from andresyv@localhost) by nic.cerf.net (8.6.8/8.6.9) id JAA00607; Wed, 2 Nov 1994 09:40:58 -0800 Date: Wed, 2 Nov 1994 09:40:57 -0800 (PST) From: Yvonne Marie Andres Subject: Re: Prince Charles and Global Schoolhouse To: Brian Lloyd cc: Jon Crowcroft , Richard Cogger , John Lynn , rem-conf@es.net In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Brian, I don't have time to answer your question in depth as I'm too busy designing and implementing a number of projects (in addition to the UKLA event). However, I will send you a background file on Global SchoolNet Foundation. For every **highly visible media event** we conduct, we have hundreds of teacher-to-teacher, student-to-student activities via email. By June 1994 we will have a report citing such examples. Sincerely, Yvonne <<*>><<*>><<*>><<*>><<*>><<*>><<*>><<*>> Yvonne Marie Andres, Global Schoolhouse/Global SchoolNet Foundation 7040 Avenida Encinas 104-281, Carlsbad, CA 92009 Voice (619) 931-5934 FAX (619) 931-5934 email: andresyv@cerf.net <<*>><<*>><<*>><<*>><<*>><<*>><<*>><<*>> On Wed, 2 Nov 1994, Brian Lloyd wrote: > I would *really* like to see an example of how two "ordinary" teachers in > "ordinary" schools have found a use for this same technology in the course > of their "ordinary" curriculum. Cross disciplinary and cross grade-level > use, e.g. a high-school chemistry class working with a college biology > class on a local/regional ecology project using multiple Internet tools, > would excite me much more. And please do not misconstrue this to imply > that this technology is only applicable to technical subjects. > > On the other hand, I guess I just don't grasp the larger picture. Global SchoolNet Fondation "Cutting Edge Technology for Grass Roots Educators" and the FrEdMail (Free Educational Electronic Mail) Network "Linking Students and Educators Around the Globe" Al Rogers, Executive Director PO Box 243, Bonita, CA 91908 619-475-4852 arogers@bonita.cerf.fred.org Yvonne Marie Andres, President 619-433-3413 or 619-931-5934 andresyv@cerf.net Since 1985 the FrEdMail has been a leader in the instructional applications of telecommunications. Today, the Global SchoolNet Foundation (GSN), a 501(c)(3) non-profit corporation, is a major contributor to the philosophy, design, culture and content of educational networking on the Internet. This short article describes our products and services. Global Learning Centers -------------------------------- The growing FrEdMail BBS Network ( aservice of te GSN) itself continues to fill an important ecological niche in the world of educational networking. Over 200 FrEdMail Global Learning Centers, operating on Apple IIe/IIgs and Macintosh LC computers, provide free Internet email access to thousands of teachers and their students across the U.S. Over 12 direct Internet gateways, which connect a FrEdMail BBS directly to a Unix Internet host, give users their own Internet email addresses. Because the BBS software can be operated by computer novices, many of our system operators are classroom teachers with no special technical training. FrEdMail helps bring the information age directly to schools and students who otherwise would wait years for the infrastructure to reach them. With a simple and low-cost FrEdMail Global Curriculum Center, they can immediately begin enjoying the benefits of global links to educators around the world Global SCHLnet News ------------------ SCHLnet is "FrEdMail on the Internet." The exemplary FrEdMail projects and newsgroups, containing the finest collection of learning activities available anywhere, are now available to schools on the Internet via our SCHLnet subscription service. SCHLnet utilizes standard Usenet transport protocols and message format to create the first professionally managed distributed conferencing service aimed specifically at teachers and their students. SCHLnet answers many of the concerns of educators about content and access on the Internet. You may review SCHLnet by telnetting to acme.fred.org; login is guest, password fred18. On-line Collaborative Learning Projects & Services -------------------------------------------------- Since 1985 GSN/FrEdMail has been setting the standard for asynchronous collaborative learning projects. GSN/FrEdMail's Eratoshenes, Newsday, Geogame, Santa Letters, and other projects are network classics of well-organized activities. Our projects serve as models to teachers who wish to generate their own successful projects. In our role as "mentors" to the educational community, we: * conduct numerous model collaborative learning projects each semester, free of charge * publish model lesson plans for collaborative projects * assist teachers in designing and managing their own learning projects * provide global newsgroups and listservs for teachers to advertise and market their own projects To be placed on our project listserv, send a message to fred@acme.fred.org with the body of the message containing "SUB HILITES". (Note: do this ONLY if you are unable to access SCHLnet.) If you want our guidelines for developing your own project, include the line "SEND GUIDELINES" If you want to submit your own project for posting on our International lists, send your complete project description, formatted according to our guidelines mentioned in the previous paragraph, to call-ideas@acme.fred.org Workshops and On-line courses ----------------------------- The Global SchoolNet Foundation currently conducts two teacher workshops: * Hello Internet, conducted on-site or on-line, introduces your teachers to Internet resources useful to classroom learning applications. All current, up-to-date resources are covered. * Managing Global Learning Projects equips teachers with the skills and resources to plan, organize, and conduct their own collaborative on-line learning projects. Call us at 619-475-4852 for more information. TeleSensations, T'nT, Newsletter, Videos ---------------------------------------- Global SchoolNet also markets a variety of resources for teachers and school districts, including: * TeleSensations is the finest telecomputing resource guide available for teachers. It contains over 100 telecomputing activities that you can conduct with your students on-line, as well as a potpourri of helpful technical and procedural information, tips, and advice. This is a perfect textbook for teachers in training, and a must-have resource for every school. * T'nT Teachers 'n Telecommunications is a comprehensive syllabus for a 15-hour teacher training workshop, especially designed for district resource specialists, staff trainers, and others charged with training teachers in how to use telecomputing. * Videos: A variety of video tapes for teacher training * Newsletter, published quarterly, containing a variety of articles and information about K-12 networking practices. For More Information -------------------- For more information send a message to fred@acme.fred.org requesting information about: Global SchoolNet Foundation Global Schoolhouse Project FrEdMail BBS FrEdMail BBS/Internet Unix Gateway Software SCHLnet GSN collaborative learning projects Hilites (our projects listserv) Teacher training workshops TeleSensations T'nT Videos Newsletter ------------------------------------------------------------------- The goals of the Global SchoolNet Foundation are to: 1. Promote the development of effective reading, writings, and communication skills in students at all grade levels. 2. Promote the development of geographical, cultural, and socio-political understanding on a global scale. 3. Promote the articulation between all segments of the community (such as schools, universities, community health agencies, community service organizations, and others), and to bring those agencies into a closer working relationship with the schools. 4. Promote a better understanding of telecommunications technologies, and encourage and promote their responsible and effective use, in schools and classrooms across America. 5. Promote and foster the development of a low cost, community-based, distributed electronic data communications network owned by public agencies such as schools, libraries, cities, and other community service organizations, with the goal of providing all citizens equal and free or low- cost access to the basic tools of information access, retrieval, and transmission that are so important in our age of information. SCHLnet News Service =================== The Global Schoolnet (formerly FrEdMail) Foundation is announcing SCHLnet, a new networking service addressed to teachers and their students. If you are a teacher you may wish to bring this information to the attention of your network administrator. Al Rogers - Executive Director Yvonne Marie Andres - President Global Schoolnet Foundation PO Box 243, Bonita, CA 91908 619-475-4852 Linking Teachers and Students Around the World What is SCHLnet? ---------------- SCHLnet is a new distributed conferencing management service that meets the needs of K-12 educators and their students on the Internet. Because it is a distributed conference it effectively puts teachers in touch with one another throughout the United States, Canada, Europe, Latin America, Australia, the Orient, Russia, and many other countries... even where direct Internet access is not available. SCHLnet solves the problems of "noise control" on the internet. It moves your listserv and group mail topics out of your personal mail boxes into the SCHLnet conference area, organized by topic, and ready for browsing when you are ready. Your mailbox will once again be used only for personal correspondence. SCHLnet uses Usenet format newsgroups to create a "mini-usenet" aimed specifically at K-12 teachers and their students. SCHLnet creates an interactive flea-market of ideas, resources, opportunities, and information of specific relevance to teachers and their students, without the extraneous and sometimes offensive distractions (from the perspective of K-12 educators, children, parents, and local school boards) posed by Usenet netnews. How does it work? ----------------- SCHLnet news is delivered directly to your local network using the USENET message interchange format, and available via the Internet, UUCP, Global Schoolnet Foundation, and other delivery protocols. Network types include School BBS, district BBS, school LAN's, district wide area networks, and regional or statewide networks. (Individuals may also subscribe to the CALLS hierarchy directly... see below). The Usenet delivery protocols are supported by a variety of packages for Unix and other systems. If you're already on USENET, you're ready to receive SCHLnet with no extra effort. If you're not on USENET, many public domain newsreading programs are available, usually for free. SCHLnet is a service of the Global Schoolnet Foundation, a pioneer and leader in networking services for educators for the past decade. The Global Schoolnet Foundation monitors all newsgroups, and actively moderates many of them. This service ensures that your teachers and students will find a professional networking venue appropriate to your local community standards. What Content is available on SCHLnet? ------------------------------------- SCHLnet newsgroups are discussion and information forums for various topics of interest to educators. These newsgroups are delivered to schools and networks around the world, thereby creating an international distributed conferencing system. Current subject categories include a range of topics. New topics will be added as demand dictates. Current categories include: CALLS - Calls for collaboration, collaborative project announcements, requests for project partners and sister schools, and keypal requests. (This is our "special" newsgroup and is discussed below.) NEWS - News and information on a variety of topics, including America 2000 Daily Report Card, CNN Newsroom Daily Lesson Plans, and other publications and announcements to educators. SIG - Special Interest Groups and discussion forums on a variety of general interest issues. CURR - Curriculum Interest Groups, similar to SIGS but specific to curricular themes. PROJ - Current and Recent Classroom Projects. Ongoing network- wide projects will be conducted in this area, so that all participants may "peek" at the progress of a project and new participants may choose to join. PUB - Publications of various sorts, INCLUDING the electronic publishing of the best of student work. Teachers supervise the selection and posting of only the BEST of student work. Other electronic publications from around the Internet will also be posted here. STU - Various student topics/exchanges. This is the place for students to correspond with one another. Moderators encourage appropriate and timely discussions on a variety of topics. What is the CALLS newsgroup? ---------------------------- A particular area of focus is the newsgroup hierarchy "CALLS" which is dedicated to "CALLS for collaboration." Here teachers themselves post their own announcements for project-based learning activities. CALLS meets the needs of busy teachers who are looking for relevant learning projects for their students and who want a reliable forum for soliciting collaborators for their own projects. It meets these needs: o) Novice teachers coming on-line need a rich collection of varied, simple, and useful curriculum-focused activities, gathered together in one place for easy access. o) Teachers need examples of successful project planning, implementation, and evaluation if they are to take the initiative to organize and implement their own project ideas. o) Teachers and budding project coordinators need help in project development. Many excellent project ideas languish for lack of skill in "bringing them to market." Teachers need help in refining their ideas, developing a marketable project announcement, and obtaining collaborators from the widest possible pool of potential participants. o) Busy networks need some form of "noise control." Announcements for exemplary projects must often contend with an ocean of messages asking for pen pals, sister schools, and messages of the "Kilroy was here" genre. Most teachers don't have the time to wade through a large volume of extraneous mail looking for "gems." SCHLnet CALLS topics will contain only project-based collaborative learning activities. o) CALLS projects will engage students in collaboration with other classes in their learning experiences. Students will measure, collect, evaluate, write, read, publish, simulate, hypothesize, compare, debate, examine, investigate, report, and summarize their learning experiences. Much of this will take place via the network as they collect, organize, share, and report. What does the Global Schoolnet Foundation do with CALLS? ------------------------------------------------ As the primary moderator of CALLS, the Global Schoolnet Foundation will: o) Publish a calendar and curriculum matrix for projects appearing on CALLS each semester or each quarter. o) Screen and post project ideas which meet the established project criteria o) Work with teachers who have worthy project ideas to develop credible project announcements for posting on CALLS. How can teachers use CALLS? --------------------------- o) Read CALL to find credible, worthwhile classroom-based, collaborative learning activities. Since it is moderated, only well-organized and useful projects will be announced here. You will not have to wade through oceans of trivia to find good projects. o) Post your project on CALL to solicit participation from the widest and most interesting audience possible. The Global Schoolnet Foundation will post your project announcement on the appropriate CALL newsgroup. If your idea is missing some elements crucial to success we will work with you to develop a well-structured call for collaboration which will assist in developing a successful project. What does it cost? And, Why? Usenet is free! -------------------------------------------- Yes, Usenet is free to the user. It is also completely unmoderated. Therefore, many topics are not appropriate to the K-12 environment. SCHLnet newsfeeds, on the other hand, deliver monitored, professional forums for K-12 educators and students which meet the standards of your local community. SCHLnet fees cover the costs of managing this service. Fees are moderate and in keeping with the philosophy of the Global Schoolnet Foundation, a non-profit corporation which for eight years has provided free and low-cost telecommunications to thousands of classrooms. Fees for SCHLnet newsfeeds and services are based on the size of your network and the number of educators and adult users with access to SCHLnet. Network types include School BBS, district BBS, school LAN's, district wide area networks, and regional or statewide networks. Contact fred@acme.fred.org for current fees. How do I subscribe? -------------------- If you are a network administrator, request an electronic order form and the full sheet of terms, conditions, and fees from fred@acme.fred.org. You can also write to us at: Global Schoolnet Foundation PO Box 243 Bonita, CA 91908-0243 619-475-4852 What if my site can't join but users want to subscribe? ------------------------------------------------------- If your sysadmin is not willing to put the "schl.net" newsgroups on your network we will be glad to send you selected SCHLnet newsgroups via your normal Internet email address and bill you individually. You will probably want to receive all of the CALL newsgroups, plus selected other newsgroups that especially pertain to your needs. How do I get a news feed? ------------------------- If you already have an Internet address, then we can send the newsfeeds to your network. If you don't, you can get UUCP feeds directly from UUNET or PSI. Write to postmaster@uunet.uu.net for details on how to become a customer of theirs. They provide cheap communications, but do charge a $35/month administrative fee on top of their telecom charges. After that, they can feed you anywhere in the USA for as little as $5/hour. PSI charges a flat fee of $75/month for leaf-site access to E-mail and news, with local access in selected areas. Mail info@psi.com or phone 800-82psi82. You can also get a feed from one of our existing customers in your area. Our net is growing. Contact us to see if we have a feed site in an area that you can call. If there is no feed point suitable for you, we will keep you on file and inform you when one shows up. Can I see what it looks like? ----------------------------- We'll be glad to give you a free one-month trial of SCHLnet with no obligation. If you already connect to UUNET or the Internet and you can receive Usenet newsfeeds we can set a trial up for you almost immediately, with no effort on your part. If you're not satisfied with the products at the end of the trial, send back the invoice (even by e-mail) and you will be charged nothing. What about feeding other sites? ------------------------------- USENET works by having one site in an area feed other sites. SCHLnet can work that way too. If you apply for permission, and you have the capacity to do it reliably, we will let you feed other sites. In fact, we'll pay you to do this by reducing your subscription fees by 10% of the fees we charge the sites you feed directly. You can either register with us to feed sites, or you can go out and find possible subscribers amongst the sites you already know. If you do that, we'll discount your price even further. Feed 7-10 similar sized sites in this manner and your subscription will be free. What are the terms and conditions? ---------------------------------- SCHLnet products are offered under special terms. If you wish to subscribe, we'll send you the full sheet of terms and conditions. In general, the terms state that: - You must not interfere with the operation of the SCHLnet network (no forged control messages etc.) - You must respect copyright, and not allow unauthorized access. - SCHLnet's audience includes young children. Consequently, we prohibit profane, discourteous, abusive, racist, sexist, obscene, and sexually explicit language. You must assist the Global Schoolnet Foundation in enforcing these standards among your users. - You must pay your subscription fees on time. - Customers may not re-sell or re-publish SCHLnet news feeds (Some limited use on fee paying BBSs is allowed.) - Articles must be kept intact. - SCHLnet is not responsible for information provided by outside information providers. Most news feeds are offered on an as-is basis. - Customers are responsible for the cost of communication from a SCHLnet feedpoint to their computer. What if I don't have a Unix system? ----------------------------------- There are software packages available that handle USENET format news for many different operating systems. There are even a couple of free/shareware packages for the IBM-PC. One which we recommend is called Waffle which can be downloaded as shareware from Compuserve and other information services. The simplest and least expensive approach to receiving and distributing SCHLnet to your teachers is through the Global Schoolnet Network which uses readily available Apple IIe and IIgs computers. We can send you additional information about the Global Schoolnet Network. For additional information, contact: arogers@bonita.cerf.fred.org From rem-conf-request@es.net Wed Nov 02 14:49:46 1994 Received: from hp.com by osi-west.es.net via ESnet SMTP service id <13823-0@osi-west.es.net>; Wed, 2 Nov 1994 11:48:20 +0000 Received: from ch-hub.ch.apollo.hp.com by hp.com with SMTP (1.37.109.12/15.5+ECS 3.3) id AA255375637; Wed, 2 Nov 1994 11:47:18 -0800 Message-Id: <199411021947.AA255375637@hp.com> Received: by ch-hub.ch.apollo.hp.com for rem-conf@es.net id AA19245; Wed, 2 Nov 1994 14:46:02 -0500 From: root014@apollo.hp.com (NONP - root) Subject: Req for Info (fwd) To: rem-conf@es.net Date: Wed, 2 Nov 94 14:46:02 EST Mailer: Elm [revision: 70.85] Hi, I wish to join the news group on "VIDEO CONFERENCING" Please put me on the mailing list. ARUN PASASD PROJECT LEADER BFL SOFTWARE LIMITED 45/3 RESIDENCY ROAD BANGALORE 560 025 INDIA From rem-conf-request@es.net Wed Nov 02 14:55:33 1994 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <13872-0@osi-west.es.net>; Wed, 2 Nov 1994 11:54:44 +0000 Via: uk.ac.edinburgh.festival; Wed, 2 Nov 1994 17:13:53 +0000 Received: from cancer.ucs.ed.ac.uk by festival.ed.ac.uk id aa15512; 2 Nov 94 17:13 GMT Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Wed, 2 Nov 94 17:13:42 GMT Date: Wed, 2 Nov 1994 17:11:05 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.edinburgh.ac.uk To: Brian Lloyd Cc: Jon Crowcroft , Brian Lloyd , Richard Cogger , John Lynn , Yvonne Marie Andres , rem-conf@es.net Subject: Re: Prince Charles and Global Schoolhouse In-Reply-To: Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 2 Nov 1994, Brian Lloyd wrote: > I hope you will forgive me for remaining skeptical. There seems to be a > strong propensity toward "exciting" high-visibility uses of the Internet, > especially teleconferencing technology. You know, the kind of thing that > attracts the broadcast media and has high-level officials patting each > other on the back in self congratulations for how education in > is being well served. Frankly this > type of use does not strike me as truely advancing education in a > long-lasting, meaningful way. Yes it does raise the visibility of the > technology as a potentially useful tool but, IMHO, it does not bring the > tool closer to the schoolhouse in a meaningful way. > > I would *really* like to see an example of how two "ordinary" teachers in > "ordinary" schools have found a use for this same technology in the course > of their "ordinary" curriculum. Cross disciplinary and cross grade-level > use, e.g. a high-school chemistry class working with a college biology > class on a local/regional ecology project using multiple Internet tools, > would excite me much more. And please do not misconstrue this to imply > that this technology is only applicable to technical subjects. Certainly > > On the other hand, I guess I just don't grasp the larger picture. You are not likely to see the latter unless schools get the funding to provide themselves with equipment and high-speed network connections. You are not likely to get this until the former has happened, to convince those who hold the purse-strings (those who appear in front of the cameras and campaign for votes) to invest. So I think on balance that such projects are worthwhile. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Wed Nov 02 15:15:24 1994 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by osi-east.es.net via ESnet SMTP service id <11024-0@osi-east.es.net>; Wed, 2 Nov 1994 12:15:00 +0000 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU [132.236.199.54]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id PAA02374; Wed, 2 Nov 1994 15:13:42 -0500 X-Sender: rc19@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Nov 1994 16:13:20 -0500 To: rem-conf@es.net, cu-seeme-announce-l@cornell.edu From: R.Cogger@cornell.edu (Richard Cogger) Subject: nv - CU-SeeMe interoperation Folks, We will be using an unreleased version of the reflector code tomorrow, for the Prince Charles event, which is able to translate (and generally fudge up) headers between nv/vat and CU-SeeMe. The good news is that it's working. Running nv and vat, you can connect to a CU-SeeMe reflector (running the new code) via unicast, and send and receive audio and video. Now for the bad news: we're not going to be able to generally release this reflector code soon because: First issue: We're worried about releasing something that will allow folks to unknowingly invoke link-melting bitblasts across the Internet. The problem is that nv, designed for a primarily multicast environment, does not provide any information the reflector could use to know which video streams a participant is actually viewing (has a window open for). So the reflector just sends them all. (Or it could send none of them, but what would be the point? Perhaps we should limit to at-most-n, but they would be sort of randomly chosen and the nv user would have no control.) Even in a multicast environment, one could argue that streams ought not be sent where no one is watching, but the odds are that someone probably is and only one copy goes (+- the effects of tunnel topology vs. real). With the CU-SeeMe unicast environment, it would be intolerable for a busy reflector to just send a copy of everything to each nv. CU-SeeMe streams are sent by the reflector only after a client indicates, stream by stream that it wants to receive them. (In current implementation, the client, by default, asks for the first 7 streams it hears about, but we're going to change that.) We're exploring with Ron Frederick how we might best be able to add somehow a means for a unix system to send the info the reflector needs to be able to prune (or not unprune) unwanted streams. Unfortunately, none of the CU-SeeMe team knows UI programming for X. If anyone wants to help... Second issue: nv sending via reflector to CU-SeeMe only works if nv uses its CU-SeeMe encoder. So you can't in general use this new version to watch an mbone conference with a Mac or PC. We plan to move nv's set of decoders and the CU-SeeMe encoder into the reflector for general transcoding, but that's proving a little tougher in practice than it sounds just to say it. But there's no real obstacle to getting this done beyond the time to do it. Cheers, -Dick From rem-conf-request@es.net Wed Nov 02 15:26:36 1994 Received: from hp.com by osi-east.es.net via ESnet SMTP service id <11623-0@osi-east.es.net>; Wed, 2 Nov 1994 12:26:18 +0000 Received: from ch-hub.ch.apollo.hp.com by hp.com with SMTP (1.37.109.12/15.5+ECS 3.3) id AA236105075; Wed, 2 Nov 1994 11:37:56 -0800 Message-Id: <199411021937.AA236105075@hp.com> Received: by ch-hub.ch.apollo.hp.com for rem-conf@es.net id AA18953; Wed, 2 Nov 1994 14:36:37 -0500 From: root014@apollo.hp.com (NONP - root) Subject: Re: Prince Charles and Global Schoolhouse (fwd) To: rem-conf@es.net Date: Wed, 2 Nov 94 14:36:37 EST Mailer: Elm [revision: 70.85] >>translate headers. A number of reflectors around and about will permit >>some CU-SeeMe users to receive the video. >>Would approx. 3-400Kbps of video and an audio stream be a problem? >Surely you jest! the mbone can sustain around 512kbps (says steve casner, and certainly in the UK, we can handle ~10Mbps internally...and we are re-engineering the international feeds to be able to sustain 764kbps mbone frm the US without disturbing " so called " normal unicast services...) - remember, if you run pruning mrouted, you don't get what you don't want - if you don't run pruning mrouted, you deserve everything you get:-) >>Do folks want to have this sent on the mbone? >>Thanks for advice, -Dick yes please. >Gee, I am sure this will advance education world-wide. firmly into cheek> last time around, we were privalaged to run the uk end of the gobal schoolhouse - the value for the children involved was immense, even though it was juts a demo....the effect was proably severla times greater than the _most_ succesful net-nerd typical mbone use for people like me... jon From rem-conf-request@es.net Wed Nov 02 16:54:06 1994 Received: from hp.com by osi-west.es.net via ESnet SMTP service id <13900-0@osi-west.es.net>; Wed, 2 Nov 1994 11:55:56 +0000 Received: from ch-hub.ch.apollo.hp.com by hp.com with SMTP (1.37.109.12/15.5+ECS 3.3) id AA269746151; Wed, 2 Nov 1994 11:55:51 -0800 Message-Id: <199411021955.AA269746151@hp.com> Received: by ch-hub.ch.apollo.hp.com for rem-conf@es.net id AA19497; Wed, 2 Nov 1994 14:54:38 -0500 From: root014@apollo.hp.com (NONP - root) Subject: Rolling Stones mbone-cast (fwd) To: rem-conf@es.net Date: Wed, 2 Nov 94 14:54:38 EST Mailer: Elm [revision: 70.85] According to taday's San Jose Mercury News: On Nov. 18, the Stones will "multicast" a 20-minute teaser from their concert in Dallas over Mbone, a way to send video over the Internet. The concert snippet will be rebroadcast every 20 minutes. So, have the Stones sent a message to rem-conf checking for conflicts yet? The Stones web site (http://www.stones.com, of course) has been claiming for a while that: This fall, a selected date of the Rolling Stones Voodoo Lounge Tour will be transmitted live over the MBONE. You can see Mick and Keith and the boys whooping it up in stadiums across the country without ever leaving the radioactive glow of your workstation. but the Murky News article is the first report I've seen of a specific date. I'm disappointed to see that it will just be a 20-minute "teaser" -- basically just a commercial -- but I'm also bummed that I have to be away at a meeting all that day. I hope someone records it (if it actually happens -- these sorts of events often fizzle for any number of technical reasons, sad to say.) Does anybody know more about this? Like, who is providing the MBone tunnel to the Dallas stadium? I see that Sun is co-sponsoring the web page, but are they also involved in the planned mbone-cast? Steve p.s. We'll know that the Mbone has gone mainstream when the papers no longer put "multicast" in quotation marks. :-) From rem-conf-request@es.net Wed Nov 02 16:54:12 1994 Received: from hp.com by osi-west.es.net via ESnet SMTP service id <13904-0@osi-west.es.net>; Wed, 2 Nov 1994 11:56:35 +0000 Received: from ch-hub.ch.apollo.hp.com by hp.com with SMTP (1.37.109.12/15.5+ECS 3.3) id AA270916185; Wed, 2 Nov 1994 11:56:25 -0800 Message-Id: <199411021956.AA270916185@hp.com> Received: by ch-hub.ch.apollo.hp.com for rem-conf@es.net id AA19514; Wed, 2 Nov 1994 14:55:09 -0500 From: root014@apollo.hp.com (NONP - root) Subject: Re: MBONE setup questions (fwd) To: rsn@spl42.spl.loral.com, rem-conf@es.net Date: Wed, 2 Nov 94 14:55:09 EST Mailer: Elm [revision: 70.85] > I am having problems launching 'wb' from 'sd'. I get an error > which remarks that the perameters are incorrect for 'wb'. The 'vat' > launchs correctly. Any ideas? You need a .sd.tcl file that fixes the calling parameters to wb for changes made since sd was produced. See the wb documentation for details. > Is is possible to design 'sd' such that I need only provide an address > to what is now a remote tunnel site rather than the setup of 'mrouted'. > I frame this question from the prospective of a end-site/user/LISTENER > to allow a faster configuration of 'sd' to public broadcasts. Obviously > to transmit, 'mrouted' is required, but for the VAST net community, > listening will be the extent of there use. No. An mrouted tunnel (or some method of multicast routing) is required to get the multicast packets to you just as much as it is required for you to be able to transmit multicast packets to the MBone. > Media on Demand is an example which does not need 'mrouted' A media stream could be sent to you individually on demand as a unicast stream. However, to tune in to "public broadcasts" which are sent via multicast for bandwidth efficiency to many places at once, you must get multicast routing. Eventually everyone should have it. -- Steve ------- From rem-conf-request@es.net Wed Nov 02 16:55:01 1994 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by osi-west.es.net via ESnet SMTP service id <01865-0@osi-west.es.net>; Wed, 2 Nov 1994 13:53:46 +0000 Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id QAA16029; Wed, 2 Nov 1994 16:53:36 -0500 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Nov 1994 16:53:41 -0400 To: brian@lloyd.com (Brian Lloyd) From: Scott Brim Subject: Re: Prince Charles and Global Schoolhouse Cc: R.Cogger@cornell.edu (Richard Cogger), rem-conf@es.net, John Lynn , Yvonne Marie Andres At 22:00 11/01/94, Brian Lloyd wrote: >>Would approx. 3-400Kbps of video and an audio stream be a problem? > >Surely you jest! Brian, this is for a number of windows. As far as I can tell CU-SeeMe takes less than 10Kb per frame per second, with a lot of variance, of course. This seems to be significantly better than nv. Let's not talk about multicast vs. unicast -- that will be taken care of when possible, and there is hardly any multicast capability in the Internet today anyway. Tomorrow's conference will be handled by a "reflector net", which are engineered essentially like the mbone (but since they are built for ad hoc specific cases, they are sometimes engineered better). Someday they'll be built dynamically. ...Scott From rem-conf-request@es.net Wed Nov 02 18:43:01 1994 Received: from brolga.cc.uq.oz.au by osi-west.es.net via ESnet SMTP service id <03512-0@osi-west.es.net>; Wed, 2 Nov 1994 15:40:43 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Thu, 3 Nov 1994 09:40:04 +1000 To: Scott Brim cc: brian@lloyd.com (Brian Lloyd), R.Cogger@cornell.edu (Richard Cogger), rem-conf@es.net, John Lynn , Yvonne Marie Andres Subject: Re: Prince Charles and Global Schoolhouse In-reply-to: Your message of "Wed, 02 Nov 1994 16:53:41 -0400." X-Mailer: exmh version 1.5phi 9/15/94 Date: Thu, 03 Nov 1994 09:39:59 +1000 Message-ID: <9252.783819599@brolga.cc.uq.oz.au> From: George Michaelson Perhaps I misunderstand how this works in practice. I beg the CuSeeME users to run some live stats capture using tcpdump or similar methods and tell us what in practice was the used bandwidth at key points in the dispersed network. I understand this to be what has happened to predicate Steve Casners estimates of bandwidth implications for a multicast session. (quite aside for stats in sender/recipient GUI windows) As for content, I sit on the fence. I think if we had Charles jamming with the Stones it would probably be a bigger crowd-puller. We'll know multicast has become mainstream when Elvis broadcasts from mars on it... From rem-conf-request@es.net Wed Nov 02 19:06:23 1994 Received: from csam.my by osi-west.es.net via ESnet SMTP service id <03715-0@osi-west.es.net>; Wed, 2 Nov 1994 16:05:08 +0000 Received: by csam.MY (4.1/SMI-4.1) id AA18320; Thu, 3 Nov 94 08:10:18 MYT Date: Thu, 3 Nov 94 08:10:18 MYT From: fhlee@csam.MY (Lee Fook Heng) Message-Id: <9411030010.AA18320@csam.MY> To: rem-conf@es.net Subject: [Q]: Hoe to get connected to MBONE?? Hi, I am interested in connecting to MBONE. I am in Malaysia and my company is connected to a central router which then connects via satelite to NFSNET. Does anyone knows what is the nearest mrouter I to me and how can I get connected to MBONE. Thanks. -- Lee, Fook Heng System Engineer CSA Malaysia Tel : +603-7587878 (ext. 320) Fax : +603-7587382 email: fhlee@csam.my From rem-conf-request@es.net Wed Nov 02 19:11:52 1994 Received: from hp.com by osi-west.es.net via ESnet SMTP service id <03745-0@osi-west.es.net>; Wed, 2 Nov 1994 16:09:23 +0000 Received: from ch-hub.ch.apollo.hp.com by hp.com with SMTP (1.37.109.12/15.5+ECS 3.3) id AA274236280; Wed, 2 Nov 1994 11:58:00 -0800 Message-Id: <199411021958.AA274236280@hp.com> Received: by ch-hub.ch.apollo.hp.com for rem-conf@es.net id AA19590; Wed, 2 Nov 1994 14:56:44 -0500 From: root014@apollo.hp.com (NONP - root) Subject: Re: Prince Charles and Global Schoolhouse (fwd) To: R.Cogger@cornell.edu (Richard Cogger), rem-conf@es.net Date: Wed, 2 Nov 94 14:56:44 EST Mailer: Elm [revision: 70.85] At 18:39 11/1/94 -0500, Richard Cogger wrote: >Folks, > On Thursday, Nov. 3rd, at 11:30AM PST, the UK's Prince Charles will >be meeting some of the kids from the Global Schoolhouse in LA. Remotely, >by CU-SeeMe, kids from Arlington, VA, kids from London, and John Morgridge, >Cisco CEO, will be conferencing. The audio will be available via phone >bridge. >If it works, the London site will be using nv to send and receive video >with nv's CU-SeeMe encoder/decoder and a new version of the reflector to >translate headers. A number of reflectors around and about will permit >some CU-SeeMe users to receive the video. > If the mbone community wants us to, we can relay this conference to >the mbone for nv reception. We can also patch the audio into VAT. I >havn't been keeping up with mbone schedules, so my questions are: > >Would approx. 3-400Kbps of video and an audio stream be a problem? Surely you jest! >Do folks want to have this sent on the mbone? > >Thanks for advice, -Dick Gee, I am sure this will advance education world-wide. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From rem-conf-request@es.net Wed Nov 02 19:21:20 1994 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by osi-west.es.net via ESnet SMTP service id <03821-0@osi-west.es.net>; Wed, 2 Nov 1994 16:19:38 +0000 Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id TAA02811; Wed, 2 Nov 1994 19:19:20 -0500 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Nov 1994 19:19:25 -0400 To: George Michaelson From: Scott Brim Subject: Re: Prince Charles and Global Schoolhouse Cc: rem-conf@es.net, John Lynn , Yvonne Marie Andres If the mbone load looks bad and few people are watching I can take Prince Charles off. I'll be running the gateway (it was supposed to be easy!). It looks like the Space Shuttle, STS 66, starts tomorrow morning, by the way. From rem-conf-request@es.net Wed Nov 02 19:24:57 1994 Received: from harry.lloyd.com by osi-west.es.net via ESnet SMTP service id <03879-0@osi-west.es.net>; Wed, 2 Nov 1994 16:23:27 +0000 Received: from [158.222.1.3] by lloyd.com with smtp (Smail3.1.28.1 #5) id m0r2pwU-0005b2C; Wed, 2 Nov 94 16:22 PST Message-Id: X-Sender: brian@harry.lloyd.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Nov 1994 16:22:16 -0800 To: Graeme.Wood@ucs.edinburgh.ac.uk From: brian@lloyd.com (Brian Lloyd) Subject: Re: Prince Charles and Global Schoolhouse Cc: Jon Crowcroft , Brian Lloyd , Richard Cogger , John Lynn , Yvonne Marie Andres , rem-conf@es.net At 17:11 11/2/94 +0000, Graeme Wood wrote: >> I would *really* like to see an example of how two "ordinary" teachers in >> "ordinary" schools have found a use for this same technology in the course >> of their "ordinary" curriculum. Cross disciplinary and cross grade-level >> ... > >You are not likely to see the latter unless schools get the funding to >provide themselves with equipment and high-speed network connections. >You are not likely to get this until the former has happened, to convince >those who hold the purse-strings (those who appear in front of the >cameras and campaign for votes) to invest. So I think on balance that >such projects are worthwhile. This belongs on a forum other than rem-conf (sorry folks) but it is interesting to note that K12 educational use of the Internet is growing rather handily. We (Lloyd Internetworking) make our living connecting schools, districts, and county offices of education in California, USA, to the Internet. We are "in the trenches" so to speak and experience the growth first-hand. Brian Lloyd, President Lloyd Internetworking brian@lloyd.com 3031 Alhambra Drive (916) 676-1147 - voice Suite 102 (916) 676-3442 - fax Cameron Park, CA 95682 From rem-conf-request@es.net Thu Nov 03 04:24:25 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <06569-0@osi-west.es.net>; Thu, 3 Nov 1994 01:22:42 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Nov 1994 09:22:26 +0000 To: R.Cogger@cornell.edu (Richard Cogger) cc: rem-conf@es.net, cu-seeme-announce-l@cornell.edu Subject: Re: nv - CU-SeeMe interoperation In-reply-to: Your message of "Wed, 02 Nov 94 16:13:20 EST." Date: Thu, 03 Nov 94 09:22:23 +0000 Message-ID: <1126.783854543@cs.ucl.ac.uk> From: Jon Crowcroft > Now for the bad news: we're not going to be able to generally >release this reflector code soon because: > First issue: We're worried about releasing something that will >allow folks to unknowingly invoke link-melting bitblasts across the >Internet. The problem is that nv, designed for a primarily multicast >environment, does not provide any information the reflector could use to >know which video streams a participant is actually viewing (has a window >open for). So the reflector just sends them all. (Or it could send none >of them, but what would be the point? Perhaps we should limit to at-most-n, >but they would be sort of randomly chosen and the nv user would have no >control.) Even in a multicast environment, one could argue that streams >ought not be sent where no one is watching, but the odds are that someone >probably is and only one copy goes (+- the effects of tunnel topology vs. >real). With the CU-SeeMe unicast environment, it would be intolerable for >a busy reflector to just send a copy of everything to each nv. CU-SeeMe >streams are sent by the reflector only after a client indicates, stream by >stream that it wants to receive them. (In current implementation, the >client, by default, asks for the first 7 streams it hears about, but we're >going to change that.) this could be a job for CCCP! but... the problem you have is that recipient interest maps to mcast prunes in the mbone environment, while in a unicast sender based system like yours (and the uni bitfield codec based stuff) you explicity se things up.... now, iff everyone runs pruining code (actually PIM, but...) i don't see your problem, but until they do, i heartily agtree - you would envisage 100s of small, sparse unicast/reflector based school conferences, and everyone of these would traverse every link in the mbone where there wasn't a pruner (or in fact where there was until the prune relaibley got back....) > We're exploring with Ron Frederick how we might best be able to add >somehow a means for a unix system to send the info the reflector needs to >be able to prune (or not unprune) unwanted streams. Unfortunately, none of >the CU-SeeMe team knows UI programming for X. If anyone wants to help... i guess you need 'negative eyeball' detection the way that vat does silence detection... > Second issue: nv sending via reflector to CU-SeeMe only works if nv >uses its CU-SeeMe encoder. So you can't in general use this new version to >watch an mbone conference with a Mac or PC. We plan to move nv's set of >decoders and the CU-SeeMe encoder into the reflector for general >transcoding, but that's proving a little tougher in practice than it sounds >just to say it. But there's no real obstacle to getting this done beyond >the time to do it. so what is the most fruitful architectural approach: to consider the world as made up of MCU/reflector style confeences, and build an mbone tool so mbone people can explicitly join/leave, or to consider the mbone as the base case model, and engineer it right (PIM) so we can stand the prune etc traffic from implict joins? [good test case....looks like reflectors as members of mbone conferences will be classic sparse mode...] this, approximately, is the topic of mark handley's thesis work.... jon From rem-conf-request@es.net Thu Nov 03 11:22:15 1994 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by osi-west.es.net via ESnet SMTP service id <09148-0@osi-west.es.net>; Thu, 3 Nov 1994 08:21:52 +0000 Received: from [132.236.199.54] (PHANTOM.CIT.CORNELL.EDU [132.236.199.54]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id LAA13192; Thu, 3 Nov 1994 11:21:42 -0500 X-Sender: rc19@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 3 Nov 1994 12:21:26 -0500 To: rem-conf@es.net, cu-seeme-announce-l@cornell.edu From: R.Cogger@cornell.edu (Richard Cogger) Subject: Re: nv - CU-SeeMe interoperation At 4:22 AM 11/3/94, Jon Crowcroft wrote: > > > First issue: We're worried about releasing something that will > >allow folks to unknowingly invoke link-melting bitblasts across the > >Internet. The problem is that nv, designed for a primarily multicast > >environment, does not provide any information the reflector could use to > >know which video streams a participant is actually viewing (has a window > >open for). So the reflector just sends them all. (Or it could send none > >but... >the problem you have is that recipient interest maps to mcast prunes >in the mbone environment, while in a unicast sender based system like >yours (and the uni bitfield codec based stuff) you explicity se things >up.... Ummm... As I understand it, the current state of the art is that mbone conference participants all send to the same mcast group-address and that (some) mbone routers prune everything for such a group when there are no downstream receivers joined. I'm told that a future version of mcast strategy intends source-specific pruning, but nowhere is it implemented today. It would of course be possible for each sender to use a different group-address for AV streams and everyone use a common group for control. And then, each sender could use a *set* of group-addresses to send the various layers... > >now, iff everyone runs pruining code (actually PIM, but...) i don't >see your problem, but until they do, i heartily agtree - you would >envisage 100s of small, sparse unicast/reflector based school >conferences, and everyone of these would traverse every link in the >mbone where there wasn't a pruner (or in fact where there was until >the prune relaibley got back....) Does PIM include source-specific pruning? > > > We're exploring with Ron Frederick how we might best be able to add > >somehow a means for a unix system to send the info the reflector needs to > >be able to prune (or not unprune) unwanted streams. Unfortunately, none of > >the CU-SeeMe team knows UI programming for X. If anyone wants to help... > >i guess you need 'negative eyeball' detection the way that vat does silence >detection... Yes, that would be good. Failing availability of that technology, we can consider not showing a window as a fair clue. > > > Second issue: nv sending via reflector to CU-SeeMe only works if nv > >uses its CU-SeeMe encoder. So you can't in general use this new version to > >watch an mbone conference with a Mac or PC. We plan to move nv's set of > >decoders and the CU-SeeMe encoder into the reflector for general > >transcoding, but that's proving a little tougher in practice than it sounds > >just to say it. But there's no real obstacle to getting this done beyond > >the time to do it. > >so what is the most fruitful architectural approach: to consider the >world as made up of MCU/reflector style confeences, and build an >mbone tool so mbone people can explicitly join/leave, or to consider >the mbone as the base case model, and engineer it right (PIM) so we can >stand the prune etc traffic from implict joins? [good test >case....looks like reflectors as members of mbone conferences will be >classic sparse mode...] I would say: short term the former, longer term, the latter and also plan on continuing need/use of hybrid setups. > >this, approximately, is the topic of mark handley's thesis work.... Look forward to it. Cheers, -Dick From rem-conf-request@es.net Thu Nov 03 13:41:55 1994 Received: from feta.cisco.com by osi-west.es.net via ESnet SMTP service id <11082-0@osi-west.es.net>; Thu, 3 Nov 1994 10:41:17 +0000 Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA14741; Thu, 3 Nov 1994 10:40:58 -0800 Date: Thu, 3 Nov 1994 10:40:58 -0800 From: Dino Farinacci Message-Id: <199411031840.KAA14741@feta.cisco.com> To: R.Cogger@cornell.edu Cc: rem-conf@es.net, cu-seeme-announce-l@cornell.edu In-Reply-To: Richard Cogger's message of Thu, 3 Nov 1994 12:21:26 -0500 Subject: nv - CU-SeeMe interoperation >> Does PIM include source-specific pruning? Yes. But said another way it does source specific joining. The default mode for sparse-mode PIM is the inverse of DVMRP. It assumes no one wants the data until there are explicit joins received. Pruning is now a function of receivers going away. Dino From rem-conf-request@es.net Thu Nov 03 15:32:06 1994 Received: from unbc.edu by osi-west.es.net via ESnet SMTP service id <12205-0@osi-west.es.net>; Thu, 3 Nov 1994 12:31:32 +0000 Received: by unbc.edu id m0r38o4-0001hcC for rem-conf@es.net ; Thu, 3 Nov 94 12:30 PST From: Lyndon Nerenberg Message-Id: <9411031230.ZM3111@unbc.edu> Date: Thu, 3 Nov 1994 12:30:46 -0800 In-Reply-To: "Marc Ph. A. J. St.-Gil - UNIX/VAX Systems Manager" "Re: MBone Agenda: update." (Oct 26, 12:58pm) References: X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: "Marc Ph. A. J. St.-Gil - UNIX/VAX Systems Manager" , Matt Crawford Subject: Unambiguous Time Formats Cc: Antonio Calegari , rem-conf@es.net Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 On Oct 26, 12:58pm, Marc Ph. A. J. St.-Gil - UNIX/VAX Systems Manager wrote: > a) pick a "network date order" much like was done on big-endian vs. > little endian byte ordering (I vote for dd/mm/yy which is far more > logical than mm/dd/yy IMNSHO) But it's still ambiguous. Use this: YYYYMMDDHHMMSS.ssss as in 19941103132905 No possibility for confusion at all, and you can extend the precision as far as you want. --lyndon -- From rem-conf-request@es.net Thu Nov 03 16:44:44 1994 Received: from crdems.GE.COM by osi-west.es.net via ESnet SMTP service id <12871-0@osi-west.es.net>; Thu, 3 Nov 1994 13:44:03 +0000 Received: from grymoire.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA23015; Thu, 3 Nov 94 16:37:22 -0500 Received: by grymoire.crd.ge.com (5.0/GE-CRD Standard Sendmail Version S1.5)id AA25792; Thu, 3 Nov 1994 16:33:37 +0500 Date: Thu, 3 Nov 1994 16:33:37 +0500 From: barnett@grymoire.crd.ge.com (Bruce Barnett) Message-Id: <9411032133.AA25792@grymoire.crd.ge.com> To: rem-conf@es.net Subject: Personal Conferencing Specification Release 1.0 X-Sun-Charset: US-ASCII Content-Length: 470 In Network (Oct 31, page 53) there is mention if the Personal Conferencing Work Group Phone: (503) 696-6070. This work group is attempting to specify a standard communication mechanism for desktop conferencing. Perhaps some rem-conf people ought to look into this. I called up and got some more information. Them seem unfamiliar with the work done by members of this mailing list. I would provide more information, but the form has "confidential" all over it. From rem-conf-request@es.net Thu Nov 03 17:46:31 1994 Received: from 204.95.114.3 by osi-west.es.net via ESnet SMTP service id <13690-0@osi-west.es.net>; Thu, 3 Nov 1994 14:45:27 +0000 Received: by mmf.andersen.com (5.0/Andersen Consulting) id AA00542; Thu, 3 Nov 1994 16:39:28 +0600 Date: Thu, 3 Nov 1994 16:39:28 +0600 From: koduriv@mmf.andersen.com (Vijay L. Koduri) Message-Id: <9411032239.AA00542@mmf.andersen.com> To: rem-conf@es.net Subject: IVS on Solaris 2.3 X-Sun-Charset: US-ASCII content-length: 718 I have several SunSparc10s installed with Solaris 2.3. I would like to set up a multicast videoconferencing system based on IVS. I understand that IVS is currently the only system using RTP. Solaris comes preinstalled with IP multicast. So using IPmc and RTP, I would like to setup a multiparty videoconferencing system. What do I need to install in order to properly run IVS? I have obtained the IVS tar file for SunOS5 (Solaris) but do not have any rtp software yet. What rtp software do I need to get and what are some implementation issues? Are there any 'how tos' on implementation and usage? If anyone knows anything about this, please reply to koduriv@mmf.andersen.com Thanks in advance, Vijay Koduri From rem-conf-request@es.net Thu Nov 03 20:33:25 1994 Received: from relay1.Hawaii.Edu by osi-west.es.net via ESnet SMTP service id <15709-0@osi-west.es.net>; Thu, 3 Nov 1994 17:32:22 +0000 Received: from uhunix3.uhcc.Hawaii.Edu ([128.171.44.52]) by relay1.Hawaii.Edu with SMTP id <11589>; Thu, 3 Nov 1994 15:23:38 -1000 Received: by uhunix3.uhcc.Hawaii.Edu id <148506>; Thu, 3 Nov 1994 15:22:39 -1000 Subject: warning... From: Tim Newsham To: rem-conf@es.net Date: Thu, 3 Nov 1994 15:22:28 -1000 X-Mailer: ELM [version 2.3 PL11] Message-Id: <94Nov3.152239hst.148506@uhunix3.uhcc.Hawaii.Edu> I sent an unsubscribe message to the -request address but nothng has been done yet. This account will be gone in a day or two and messages will start bouncing to the list. Hopefully my subscription will be removed before then. Sorry for the off-topic post. Tim N. From rem-conf-request@es.net Thu Nov 03 21:47:50 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <16178-0@osi-west.es.net>; Thu, 3 Nov 1994 18:47:11 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14406(5)>; Thu, 3 Nov 1994 18:46:51 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16138>; Thu, 3 Nov 1994 18:46:44 -0800 To: koduriv@mmf.andersen.com (Vijay L. Koduri) cc: rem-conf@es.net Subject: Re: IVS on Solaris 2.3 In-reply-to: Your message of "Thu, 03 Nov 94 02:39:28 PST." <9411032239.AA00542@mmf.andersen.com> Date: Thu, 3 Nov 1994 18:46:41 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Nov3.184644pst.16138@ecco.parc.xerox.com> In message <9411032239.AA00542@mmf.andersen.com> you write: > I have several SunSparc10s installed with Solaris 2.3. I would like to > set up a multicast videoconferencing system based on IVS. I understand > that IVS is currently the only system using RTP. Solaris comes preinstalled > with IP multicast. So using IPmc and RTP, I would like to setup a multiparty > videoconferencing system. > It's not true that 'ivs' is the only package using RTP. My 'nv' video tool also uses RTP. Both 'ivs' and 'nv' are capable of multiparty conferencing using IP multicast. You don't need any special "RTP" package. It is built into both applications. Which video tool you prefer is largely a matter of personal taste. In general, 'ivs' is targetted more at lower bit rates, but uses more CPU. This is a good choice for long distance conferencing. When running in a local environment where you can spare the bandwidth, 'nv' will give you higher frame rates on the same hardware. If you'd like to pick up 'nv', you can get it from parcftp.xerox.com in the /pub/net-research directory. In particular, nvbin-3.3beta-sunos5.tar.Z is the one you need for Solaris 2.x. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Fri Nov 04 01:02:54 1994 Received: from nic.cerf.net by osi-west.es.net via ESnet SMTP service id <17064-0@osi-west.es.net>; Thu, 3 Nov 1994 22:02:30 +0000 Received: from calvin.vigra.com (vigra.com [134.24.6.112]) by nic.cerf.net (8.6.8/8.6.9) with SMTP id WAA13751; Thu, 3 Nov 1994 22:00:05 -0800 Received: from susie.vigra.com by calvin.vigra.com (4.1/Vigra-8.11-extern) id AA03895; Thu, 3 Nov 94 21:34:04 PST Received: by susie.vigra.com (4.1/Vigra-8.11-smtp) id AA05136; Thu, 3 Nov 94 21:34:04 PST Date: Thu, 3 Nov 94 21:34:04 PST From: Steve Haehnichen Message-Id: <9411040534.AA05136@susie.vigra.com> To: root014@apollo.hp.com (NONP - root) Cc: rem-conf@es.net In-Reply-To: root014@apollo.hp.com's message of Wed, 2 Nov 1994 19:55:09 GMT Subject: Re: MBONE setup questions (fwd) Reply-To: steve@vigra.com -=> On Wed, 2 Nov 1994 19:55:09 GMT, root014@apollo.hp.com (NONP - root) said: >> Media on Demand is an example which does not need 'mrouted' > A media stream could be sent to you individually on demand as a > unicast stream. However, to tune in to "public broadcasts" which > are sent via multicast for bandwidth efficiency to many places at > once, you must get multicast routing. Eventually everyone should > have it. This is something that I haven't been able to figure out from the FAQ and such. Does MBONE pay any attention to who's listening? If I "subscribe to the MBONE" by asking our service provider to route packets to our network, do we have any method of throttling the transmissions? The link would probably be a TCP tunnel through the routers between our provider and our local net that don't support multicasting. Once it's arrived at mrouted here, it's already consumed bandwidth in the bottleneck part of our network. I ask because we are currently connected at 56kbps, and I would be mighty unpopular around here if I repeatedly saturate that link with MBONE traffic when nobody is tuned in. If I could selectively request broadcasts at the service provider end, then it would be no problem. Is this possible without pestering them? Would killing the local mrouted stop the transmissions without causing a nuisance at their end? Thanks! -Steve -- Steve Haehnichen Vigra, Inc. San Diego, CA steve@vigra.com (619) 597-7080 x116 Fax: (619) 597-7094 From rem-conf-request@es.net Fri Nov 04 03:19:49 1994 Received: from jerry.inria.fr by osi-west.es.net via ESnet SMTP service id <17969-0@osi-west.es.net>; Fri, 4 Nov 1994 00:19:05 +0000 Received: by jerry.inria.fr (5.65c8/IDA-1.2.8) id AA27044; Fri, 4 Nov 1994 09:18:22 +0100 Message-Id: <199411040818.AA27044@jerry.inria.fr> To: koduriv@mmf.andersen.com (Vijay L. Koduri) Cc: rem-conf@es.net Subject: Re: IVS on Solaris 2.3 In-Reply-To: Your message of Thu, 03 Nov 1994 16:39:28 +0600. <9411032239.AA00542@mmf.andersen.com> Reply-To: Thierry.Turletti@sophia.inria.fr Date: Fri, 04 Nov 1994 09:18:20 +0100 From: Thierry Turletti > I have several SunSparc10s installed with Solaris 2.3. I would like to > set up a multicast videoconferencing system based on IVS. I understand > that IVS is currently the only system using RTP. Wrong, some audio/video conferencing tools are also based on RTP, e.g. nevot and nv. A survey of desktop videoconferencing products is available via the following URL: http://www2.ncsu.edu/eos/service/ece/project/succeed_info/dtvc_survey/products.html > What do I need to install in order to properly run IVS? I have obtained the > IVS tar file for SunOS5 (Solaris) but do not have any rtp software yet. What > rtp software do I need to get and what are some implementation issues? > Are there any 'how tos' on implementation and usage? There is no special RTP package required; it is already included in ivs. Just run it on your platform! You can consult the manual included in the ivs package or look at the following URL: http://zenon.inria.fr:8003/rodeo/personnel/Thierry.Turletti/ivs.html Thierry From rem-conf-request@es.net Fri Nov 04 03:55:15 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <18131-0@osi-west.es.net>; Fri, 4 Nov 1994 00:54:43 +0000 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 4 Nov 1994 08:54:23 +0000 To: R.Cogger@cornell.edu (Richard Cogger) cc: rem-conf@es.net Subject: Re: nv - CU-SeeMe interoperation In-reply-to: Your message of "Thu, 03 Nov 94 12:21:26 EST." Date: Fri, 04 Nov 94 08:54:20 +0000 Message-ID: <5634.783939260@cs.ucl.ac.uk> From: Jon Crowcroft >Does PIM include source-specific pruning? not yet - that is basically the issue for the model of reflector/mcu to mbone interworking, isn't it sounds like a job for the IETF IDMR WG.... problem of source spec pruning is the router state, but if we can control it as a per-grup cpnfig option, (probably associated with thew same state to contro lthe RP placement or something) then maybe its something that won't explode to badly... jon From rem-conf-request@es.net Fri Nov 04 04:38:59 1994 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net via ESnet SMTP service id <18402-0@osi-west.es.net>; Fri, 4 Nov 1994 01:38:25 +0000 Via: uk.ac.edinburgh.festival; Fri, 4 Nov 1994 09:32:28 +0000 Received: from cancer.ucs.ed.ac.uk by festival.ed.ac.uk id aa19926; 4 Nov 94 9:32 GMT Received: from scorpio.ucs.ed.ac.uk by ucs.ed.ac.uk; Fri, 4 Nov 94 09:32:19 GMT Date: Fri, 4 Nov 1994 09:32:17 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.edinburgh.ac.uk To: "Vijay L. Koduri" Cc: rem-conf@es.net Subject: Re: IVS on Solaris 2.3 In-Reply-To: <9411032239.AA00542@mmf.andersen.com> Message-Id: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-Url: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 3 Nov 1994, Vijay L. Koduri wrote: > I have several SunSparc10s installed with Solaris 2.3. I would like to > set up a multicast videoconferencing system based on IVS. I understand > that IVS is currently the only system using RTP. Solaris comes preinstalled with > IP multicast. So using IPmc and RTP, I would like to setup a multiparty > videoconferencing system. > > What do I need to install in order to properly run IVS? I have obtained the > IVS tar file for SunOS5 (Solaris) but do not have any rtp software yet. What > rtp software do I need to get and what are some implementation issues? > Are there any 'how tos' on implementation and usage? > > If anyone knows anything about this, please reply to koduriv@mmf.andersen.com You don't need any rtp software. ivs is rtp software. All you now need is a connection to the MBONE from your subnet and you are running. Of course you will need to make sure you have loaded the RTVC and XIL packages >from the Solaris 2.3 CD if you want to use the SunVideo card to send video. On usage the only caveat is don't send high-bandwidth video images with a large TTL. You will interfere with other traffic on the network if you do. In order to setup your conference you will probably want to install sd, the Session Directory program. You can fetch this from many good ftp sites but if you haven't got it you can get it from ftp://ftp.ucs.ed.ac.uk/pub/videoconference/sd/sun-sd.tar.Z. In order to get it to run you will need to make sure you have the OpenWindows Binary compatability libraries loaded from the Solaris CD and make sure that /usr/4lib is in LD_LIBRARY_PATH (if it is set at all) before /usr/openwin/lib. In order to get sd to recognize ivs you will need to installed a modified .sd.tcl file. You can get one from ftp://ftp.ucs.ed.ac.uk/pub/videoconference/sd/sd.tcl. I hope this will help. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Fri Nov 04 06:38:42 1994 Received: from imicilea.cilea.it by osi-west.es.net via ESnet SMTP service id <19234-0@osi-west.es.net>; Fri, 4 Nov 1994 03:37:37 +0000 Received: from [131.175.1.95] by IMICILEA.CILEA.IT (IBM VM SMTP V2R2) with TCP; Fri, 04 Nov 94 12:32:40 MET X-Sender: calegari@icil64 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 4 Nov 1994 13:37:28 +0200 To: rem-conf@es.net From: calegari@cilea.it (Antonio Calegari) Subject: Mbone Agenda - November 94 The MBone Agenda Nov 94 ------------------------------------------------------------------------ All times are given in GMT. ------------------------------------------------------------------------ 03-Nov 16:00 14-Nov 20:00 NASA Shuttle Broadcast - STS - 66 Contact: Alex Deacon - anaops@atlas.arc.nasa.gov NASA's STS-66 Broadcast. Launch time is estimated at 16:56 GMT. The mission is due to last 10 days 20 hours. ------------------------------------------------------------------------ 04-Nov 18:00 04-Nov 19:00 Mike Ruygrok operations Manager Contact: miker@lna.oz.au ------------------------------------------------------------------------ 18-Nov 03:00 18-Nov 06:00 BayLISA meeting: Jonny Goldman on gateways and proxies for H Contact: blw@baylisa.org or deleon@hpl.hp.com The broadcast will be from 7:30-10:00 PDT Nov 17, 1994 ------------------------------------------------------------------------ 27-Nov 08:00 27-Nov 15:00 Epic multimedia event Contact: richard@rmit.edu.au Television event ------------------------------------------------------------------------ ------------------------------------------------------------------------- Antonio Calegari CILEA - Segrate - Milan tel. : +39 (0)2 26995 257 Interuniversity Computing Centre email: calegari@icil64.cilea.it ITALY From rem-conf-request@es.net Fri Nov 04 09:04:02 1994 Received: from crdems.GE.COM by osi-west.es.net via ESnet SMTP service id <19876-0@osi-west.es.net>; Fri, 4 Nov 1994 06:03:29 +0000 Received: from grymoire.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA29155; Fri, 4 Nov 94 08:57:06 -0500 Received: by grymoire.crd.ge.com (5.0/GE-CRD Standard Sendmail Version S1.5)id AA10643; Fri, 4 Nov 1994 08:53:22 +0500 Date: Fri, 4 Nov 1994 08:53:22 +0500 From: barnett@grymoire.crd.ge.com (Bruce Barnett) Message-Id: <9411041353.AA10643@grymoire.crd.ge.com> To: koduriv@mmf.andersen.com, Thierry.Turletti@sophia.inria.fr Subject: Re: IVS on Solaris 2.3 Cc: rem-conf@es.net, simon.gibbs@gmd.de X-Sun-Charset: US-ASCII Content-Length: 325 > A survey of desktop videoconferencing products is available > via the following URL: > http://www2.ncsu.edu/eos/service/ece/project/succeed_info/dtvc_survey/products.html You may also want to check Simon Gibbs's Index to MultiMedia Information Sources: http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/MetaIndex.html From rem-conf-request@es.net Fri Nov 04 11:11:29 1994 Received: from imicilea.cilea.it by osi-west.es.net via ESnet SMTP service id <20698-0@osi-west.es.net>; Fri, 4 Nov 1994 08:10:59 +0000 Received: from [131.175.1.95] by IMICILEA.CILEA.IT (IBM VM SMTP V2R2) with TCP; Fri, 04 Nov 94 17:06:05 MET X-Sender: calegari@imicilea Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 4 Nov 1994 18:10:53 +0200 To: azhao@cc.gatech.edu (Q. Alex Zhao) From: calegari@cilea.it (Antonio Calegari) Subject: RE: Mbone Agenda - November 94 Cc: rem-conf@es.net Opss, the URL is http://www.cilea.it/MBone/agenda.html Cheers -Antonio >Hi. Where is the WWW page of the agenda, do you know? Thanks. > >Cheers, >= Q. Alex Zhao ~{0"UT~} ! Graphics, Visualization & Usability Center > Email: azhao@cc.gatech.edu ! College of Computing > FAX: 404-853-9378 ! Georgia Institute of Technology > Lab: 404-894-9636 ! Atlanta, Georgia 30332-0280 From rem-conf-request@es.net Fri Nov 04 12:00:42 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <21125-0@osi-west.es.net>; Fri, 4 Nov 1994 09:00:10 +0000 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 4 Nov 1994 16:58:48 +0000 To: braden@ISI.EDU cc: rem-conf@es.net, end2end-interest@ISI.EDU Subject: Re: Changing the IP multicast model...? In-reply-to: Your message of "Fri, 04 Nov 94 08:42:58 PST." <199411041642.AA08200@can.isi.edu> Date: Fri, 04 Nov 94 16:58:46 +0000 Message-ID: <1061.783968326@cs.ucl.ac.uk> From: Jon Crowcroft > *> From rem-conf-request@es.net Fri Nov 4 02:49:10 1994 > *> To: R.Cogger@cornell.edu (Richard Cogger) > *> Cc: rem-conf@es.net > *> Subject: Re: nv - CU-SeeMe interoperation > *> In-Reply-To: Your message of "Thu, 03 Nov 94 12:21:26 EST." > *> Date: Fri, 04 Nov 94 08:54:20 +0000 > *> From: Jon Crowcroft > *> Content-Length: 445 > *> X-Lines: 15 > *> > *> > *> >Does PIM include source-specific pruning? > *> > >"Source-specific pruning" is a mechanism. I would say that the >sggested addition to the multicast service model is "source-specific >joins", however achieved. > >Is there a proposal to amend RFC-1112 to addd source-specific joins? >If so, given the lead time to change hosts, it would be best to get >about it soon... Bob it seems to me that filtering at receiver is _not_ a good plan, nor, necessairly is pruing on receiving unwanted traffic, so some sort of indication that some groups are source specific joinable ('multicast lite') while others are 'multicast classic' may be a good plan.... jon From rem-conf-request@es.net Fri Nov 04 12:04:06 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <21166-0@osi-west.es.net>; Fri, 4 Nov 1994 09:03:36 +0000 Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Fri, 4 Nov 1994 08:40:31 -0800 Date: Fri, 4 Nov 1994 08:42:58 -0800 From: braden@ISI.EDU Posted-Date: Fri, 4 Nov 1994 08:42:58 -0800 Message-Id: <199411041642.AA08200@can.isi.edu> Received: by can.isi.edu (5.65c/4.0.3-4) id ; Fri, 4 Nov 1994 08:42:58 -0800 To: rem-conf@es.net, end2end-interest@ISI.EDU Subject: Changing the IP multicast model...? *> From rem-conf-request@es.net Fri Nov 4 02:49:10 1994 *> To: R.Cogger@cornell.edu (Richard Cogger) *> Cc: rem-conf@es.net *> Subject: Re: nv - CU-SeeMe interoperation *> In-Reply-To: Your message of "Thu, 03 Nov 94 12:21:26 EST." *> Date: Fri, 04 Nov 94 08:54:20 +0000 *> From: Jon Crowcroft *> Content-Length: 445 *> X-Lines: 15 *> *> *> >Does PIM include source-specific pruning? *> "Source-specific pruning" is a mechanism. I would say that the sggested addition to the multicast service model is "source-specific joins", however achieved. Is there a proposal to amend RFC-1112 to addd source-specific joins? If so, given the lead time to change hosts, it would be best to get about it soon... Bob Braden From rem-conf-request@es.net Fri Nov 04 12:38:29 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <21459-0@osi-west.es.net>; Fri, 4 Nov 1994 09:37:46 +0000 Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Fri, 4 Nov 1994 09:16:49 -0800 Date: Fri, 4 Nov 1994 09:19:16 -0800 From: braden@ISI.EDU Posted-Date: Fri, 4 Nov 1994 09:19:16 -0800 Message-Id: <199411041719.AA08233@can.isi.edu> Received: by can.isi.edu (5.65c/4.0.3-4) id ; Fri, 4 Nov 1994 09:19:16 -0800 To: braden@ISI.EDU, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Changing the IP multicast model...? Cc: rem-conf@es.net, end2end-interest@ISI.EDU *> *> it seems to me that filtering at receiver is _not_ a good plan, nor, *> necessairly is pruing on receiving unwanted traffic, so some sort of *> indication that some groups are source specific joinable ('multicast *> lite') while others are 'multicast classic' may be a good plan.... *> *> jon *> *> John, Unless I misunderstand you, you are arguing about mechanism. Don't argue with me, *I* don't do multicast routing. :-) Bob From rem-conf-request@es.net Fri Nov 04 12:58:55 1994 Received: from herman.cmf.nrl.navy.mil by osi-west.es.net via ESnet SMTP service id <21630-0@osi-west.es.net>; Fri, 4 Nov 1994 09:58:19 +0000 Received: from localhost (fenner@localhost) by herman.cmf.nrl.navy.mil (8.6.8.1/8.6.6) with SMTP id MAA06623; Fri, 4 Nov 1994 12:55:37 -0500 Message-Id: <199411041755.MAA06623@herman.cmf.nrl.navy.mil> To: steve@vigra.com cc: rem-conf@es.net Subject: Re: MBONE setup questions (fwd) In-reply-to: Your message of "Thu, 03 Nov 94 21:34:04 PST." <9411040534.AA05136@susie.vigra.com> X-Face: -*.ZYbFWa}{2c8NmF| > If I "subscribe to the MBONE" by asking our service provider to route > packets to our network, do we have any method of throttling the > transmissions? The "pruning versions" of mrouted will not send any traffic other than what there are listeners for (except for the periodic flood which triggers more prunes). If both you and your provider are running mrouted 3.x, then you should be ok. In addition, if you kill your mrouted, you will not get any traffic, only occasional probe messages from the other end to check if your mrouted is back yet. Bill From rem-conf-request@es.net Fri Nov 04 14:04:05 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <22511-0@osi-west.es.net>; Fri, 4 Nov 1994 11:02:55 +0000 Received: from dji.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Fri, 4 Nov 1994 10:50:21 -0800 Date: Fri, 4 Nov 1994 10:50:14 -0800 Posted-Date: Fri, 4 Nov 1994 10:50:14 -0800 Message-Id: <199411041850.AA07597@dji.isi.edu> Received: by dji.isi.edu (5.65c/4.0.3-4) id ; Fri, 4 Nov 1994 10:50:14 -0800 From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: J.Crowcroft@cs.ucl.ac.uk Cc: braden@ISI.EDU, rem-conf@es.net, end2end-interest@ISI.EDU In-Reply-To: Jon Crowcroft's message of Fri, 04 Nov 94 16:58:46 +0000 <1061.783968326@cs.ucl.ac.uk> Subject: Changing the IP multicast model...? Reply-To: estrin@usc.edu In-Reply-To: Your message of "Fri, 04 Nov 94 08:42:58 PST." <199411041642.AA08200@can.isi.edu> From: Jon Crowcroft > *> From rem-conf-request@es.net Fri Nov 4 02:49:10 1994 > *> To: R.Cogger@cornell.edu (Richard Cogger) > *> Cc: rem-conf@es.net > *> Subject: Re: nv - CU-SeeMe interoperation > *> In-Reply-To: Your message of "Thu, 03 Nov 94 12:21:26 EST." > *> Date: Fri, 04 Nov 94 08:54:20 +0000 > *> From: Jon Crowcroft > *> Content-Length: 445 > *> X-Lines: 15 > *> > *> > *> >Does PIM include source-specific pruning? > *> > >"Source-specific pruning" is a mechanism. I would say that the >sggested addition to the multicast service model is "source-specific >joins", however achieved. > >Is there a proposal to amend RFC-1112 to addd source-specific joins? >If so, given the lead time to change hosts, it would be best to get >about it soon... Bob it seems to me that filtering at receiver is _not_ a good plan, nor, necessairly is pruing on receiving unwanted traffic, so some sort of indication that some groups are source specific joinable ('multicast lite') while others are 'multicast classic' may be a good plan.... jon We will send out a note sometime before IETF talking about the support of channel selection/source pruning by reservation and mcast routing protocols. From rem-conf-request@es.net Fri Nov 04 14:09:28 1994 Received: from feta.cisco.com by osi-west.es.net via ESnet SMTP service id <22730-0@osi-west.es.net>; Fri, 4 Nov 1994 11:08:30 +0000 Received: (dino@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id LAA04066; Fri, 4 Nov 1994 11:08:03 -0800 Date: Fri, 4 Nov 1994 11:08:03 -0800 From: Dino Farinacci Message-Id: <199411041908.LAA04066@feta.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk Cc: R.Cogger@cornell.edu, rem-conf@es.net In-Reply-To: Jon Crowcroft's message of Fri, 04 Nov 94 08:54:20 +0000 <5634.783939260@cs.ucl.ac.uk> Subject: nv - CU-SeeMe interoperation >> >Does PIM include source-specific pruning? >> >> not yet - that is basically the issue for the model of reflector/mcu >> to mbone interworking, isn't it Just to make this crystal clear. PIM does support source-specific pruning where "source" here means prune off an existing source-based tree. "Source" here can also mean a collection of sources. I believe Jon is referring to source-host specific pruning where a first-hop router tells a host there are no members listening in and it should stop sending traffic. Source-host specific pruning seems most likely an extension to IGMP and can be a local subnet specific function between multicast routers and hosts. Dino From rem-conf-request@es.net Sat Nov 05 04:30:32 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <06036-0@osi-west.es.net>; Sat, 5 Nov 1994 01:28:36 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <03206-0@ceres.fokus.gmd.de>; Sat, 5 Nov 1994 10:31:24 +0100 Subject: RTP (was: Re: IVS on Solaris 2.3) To: rem-conf@es.net MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Sat, 5 Nov 1994 10:31:24 +0100 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de > In message <9411032239.AA00542@mmf.andersen.com> you write: > > I have several SunSparc10s installed with Solaris 2.3. I would like to > > set up a multicast videoconferencing system based on IVS. I understand > > that IVS is currently the only system using RTP. Solaris comes preinstalled > > with IP multicast. So using IPmc and RTP, I would like to setup a multiparty > > videoconferencing system. > > > It's not true that 'ivs' is the only package using RTP. My 'nv' video tool also > uses RTP. Both 'ivs' and 'nv' are capable of multiparty conferencing using > IP multicast. You don't need any special "RTP" package. It is built into both > applications To make matters more complicated, "RTP" can mean a number of things, corresponding roughly to the number of drafts issued. For example, ivs, nevot, nv and Sun's ShowMe (among others) all implement RTP, but I doubt that they can understand each other's packets, beyond the obvious differences in payload encoding. To vary Tanenbaum's famous word about standards: "The nice thing about Internet standards is that you have so many to choose from before they have been declared one..." On my home page (listed below), you'll find a listing of my current knowledge of (announced) RTP applications and my interpretation of the version of RTP they profess to talk. Corrections/additions are appreciated. I can only hope that once we have a real RFC (any day now...), we will rapidly converge to a single version, in particular, so that external tools can be developed quickly. > -- > Ron Frederick > frederick@parc.xerox.com > -- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 219 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin URL: http://www.fokus.gmd.de/htbin/info/minos/hgs From rem-conf-request@es.net Sun Nov 06 13:26:44 1994 Received: from tink.com by osi-west.es.net via ESnet SMTP service id <17212-0@osi-west.es.net>; Sun, 6 Nov 1994 10:26:17 +0000 Received: from tink.com by tink.com (PMDF V4.3-10 #5880) id <01HJ39U5U81S8WYIX7@tink.com>; Sun, 06 Nov 1994 13:28:24 -0500 (EDT) Date: Sun, 06 Nov 1994 13:28:21 -0500 (EDT) From: Bob Tinkelman Subject: subscribe To: rem-conf@es.net Cc: bob@tink.com Message-id: <01HJ5SO3T0328WYIX7@tink.com> Organization: New York Net MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT subscribe From rem-conf-request@es.net Mon Nov 07 05:54:39 1994 Received: from ceres.fokus.gmd.de by osi-east.es.net via ESnet SMTP service id <03543-0@osi-east.es.net>; Mon, 7 Nov 1994 02:54:11 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <06592-0@ceres.fokus.gmd.de>; Mon, 7 Nov 1994 11:53:44 +0100 Subject: Re: Source for sd, vat, and wb? To: J.Crowcroft@cs.ucl.ac.uk Cc: rem-conf@es.net MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Mon, 7 Nov 1994 11:53:44 +0100 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de > Geo: > >So hack on nevot! full sources, assumes unix sound driver but surely you > >can get round that... > > actually, we started this, but nevot is somewhat a can of worms - it > depends on a lot of different versions of other things being right > .... Have you tried recently or in the dimmer past? It does require current versions of the tcl, tk, BLT, and some other libraries, but these are also available compiled and packed up as a tar archive from the same place. Since I can't fix problems that I'm not told about, let me know if you do have problems. -- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 219 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin URL: http://www.fokus.gmd.de/htbin/info/minos/hgs From rem-conf-request@es.net Mon Nov 07 10:07:55 1994 Received: from swan.cl.cam.ac.uk by osi-west.es.net via ESnet SMTP service id <22889-0@osi-west.es.net>; Mon, 7 Nov 1994 07:07:13 +0000 Received: from ouse.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Mon, 7 Nov 1994 15:06:19 +0000 To: rem-conf@es.net, mbone@ISI.EDU, info-hol@leopard.cs.byu.edu Cc: Piete.Brooks@cl.cam.ac.uk Reply-To: Piete.Brooks@cl.cam.ac.uk Subject: Mbone transmission 94/11/9 16:15-17:15 UTC (cl.cam.ac.uk Seminar) Date: Mon, 07 Nov 1994 15:06:13 +0000 From: Piete Brooks Message-ID: <"swan.cl.cam.:197660:941107150633"@cl.cam.ac.uk> As interest has already been expressed to see this seminar outside the UK, I propose using a TTL of 79. If you would like to get the transmission, and you suspect that 79 might not be enough, please email me the name of your nearest MBone router (if you know it), and I'll set the TTL accordingly. Please also say if you want video (of the speaker - slides available separately) We have an improved audio feed this week, so last week's hum should have gone. Note that slides will **ONLY** be available via the WWW -- not on the video feed. NAME: Dr Paul Curzon, University of Cambridge Computer Laboratory DATE: Wednesday 9th November 1994 at 4.15pm (16:15 UTC) PLACE: Babbage Lecture Theatre TITLE: Experiences Verifying the Fairisle Switching Elements We describe a case study concerned with the formal machine-checked verification of several versions of the Fairisle switching element hardware. Fairisle is an Asynchronous Transfer Mode (ATM) network designed in Cambridge by the Systems Research Group. The elements are cell synchronous, self routeing, crossbar switches. They were designed and implemented with no consideration for formal methods. This case study thus gives an indication of the difficulties formally verifying real designs and of tracking design changes with formal verification. The talk is intended for a general audience. We will not go into the details of the formal specifications or proofs. Instead we will focus on practical matters such as problems encountered, time taken, errors found, etc. This seminar will be multicast (audio and video) on the mbone as part of our multimedia test programme. Further information is available at http://www.cl.cam.ac.uk/mbone/#cl. From rem-conf-request@es.net Mon Nov 07 10:39:04 1994 Received: from crdems.GE.COM by osi-west.es.net via ESnet SMTP service id <23136-0@osi-west.es.net>; Mon, 7 Nov 1994 07:38:34 +0000 Received: from grymoire.crd.ge.com by crdems.ge.com (5.65/GE 1.77) id AA28516; Mon, 7 Nov 94 10:33:57 -0500 Received: by grymoire.crd.ge.com (5.0/GE-CRD Standard Sendmail Version S1.5)id AA15991; Mon, 7 Nov 1994 10:30:14 +0500 Date: Mon, 7 Nov 1994 10:30:14 +0500 From: barnett@grymoire.crd.ge.com (Bruce Barnett) Message-Id: <9411071530.AA15991@grymoire.crd.ge.com> To: koduriv@mmf.andersen.com, Thierry.Turletti@sophia.inria.fr, barnett@grymoire.crd.ge.com Subject: Re: IVS on Solaris 2.3 Cc: rem-conf@es.net, simon.gibbs@gmd.de X-Sun-Charset: US-ASCII Content-Length: 114 Here's another reference "Index to Multimedia Information Sources" http://cui_www.unige.ch/OSG/MultimediaInfo/ From rem-conf-request@es.net Mon Nov 07 13:54:11 1994 Received: from xanthus.usc.edu by osi-west.es.net via ESnet SMTP service id <25842-0@osi-west.es.net>; Mon, 7 Nov 1994 10:52:55 +0000 Received: by xanthus.usc.edu (4.1/SMI-4.1+ucs-3.6) id AA04296; Mon, 7 Nov 94 10:54:48 PST From: suhler@acal.usc.edu (Paul A. Suhler) Message-Id: <9411071854.AA04296@xanthus.usc.edu> Subject: wb displayed on Macintosh PowerBook? To: rem-conf@es.net Date: Mon, 7 Nov 94 10:54:47 PST X-Mailer: ELM [version 2.3 PL5] Has anyone tried running wb with the whiteboard displayed on a Mac PowerBook, using MacX? I've found that there just aren't enough pixels on the screen, and some of the tools are off the top of the screen with no way to scroll them back down. Configuration is PB Duo 230, System 7.1, MacX 1.1.7, PPP, and MacTCP 2.0.4. Please reply directly via e-mail, as my subscription hasn't been processed yet. Thanks, Paul Suhler suhler@usc.edu (213) 740-9139 From rem-conf-request@es.net Mon Nov 07 22:59:09 1994 Received: from grimaldi.rutgers.edu by osi-west.es.net via ESnet SMTP service id <00209-0@osi-west.es.net>; Mon, 7 Nov 1994 19:58:39 +0000 Received: (from jim@localhost) by grimaldi.rutgers.edu (8.6.8.1+bestmx/8.6.6) id WAA04373 for rem-conf@es.net; Mon, 7 Nov 1994 22:58:37 -0500 Resent-Message-Id: <199411080358.WAA04373@grimaldi.rutgers.edu> Date: Mon, 7 Nov 94 22:58:35 EST From: Jim Martin To: Roger Fajman Cc: rem-conf@es.net Subject: Re: Source for sd, vat, and wb? In-Reply-To: Your message of Mon, 07 Nov 1994 18:47:23 EST Resent-To: rem-conf@es.net Resent-Date: Mon, 7 Nov 94 22:58:35 EST Resent-From: Jim Martin Message-ID: > We are interested in working on a port of vat, et al to Microsoft > Windows. Sigh... I've been hesitent to announce this to the world until I had completely working code, but since the specific issue is on the table I couldn't ignore it. I'm in the middle of an effort to port the tools to Win32. I've got a (nearly) complete session directory tool, and am in the middle of a VAT-compatible audio tool. It's my hope to have the session directory tool/audio tool pair out in a limited alpha/beta test by the San Jose IETF. My development environment is Daytona (Windows NT 3.5), but I've tested under Chicago (Windows 95) and they work fine there. My Win 3.1/Win32s support suddenly stopped working, but I'm sure that's just a minor setback. > We want to make real use of this emerging technology on our > own network and relatively few users in the potential audience have > Unix workstations. Precisely my reasoning. I've got lots of interested potential users and relatively few sparcs. On the other hand, I'm _really_ worried about our internal network infrastructure when these tools can end up on just about anyone's desk :( > > Now where did I put that asbestos jacket? Oops, the asbestos got > removed... Heh! Now you know why I've been so hesitent to announce my work :) Jim Jim Martin Internet: jim@noc.rutgers.edu Network Services Fax: (908) 445-2968 Rutgers University Phone: (908) 445-3719 From rem-conf-request@es.net Tue Nov 08 04:42:52 1994 Received: from imicilea.cilea.it by osi-west.es.net via ESnet SMTP service id <02070-0@osi-west.es.net>; Tue, 8 Nov 1994 01:42:27 +0000 Received: from [131.175.1.95] by IMICILEA.CILEA.IT (IBM VM SMTP V2R2) with TCP; Tue, 08 Nov 94 10:37:29 MET X-Sender: calegari@imicilea Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 Nov 1994 11:42:18 +0200 To: rem-conf@es.net From: calegari@cilea.it (Antonio Calegari) Subject: sd vat etc on FreeBSD Hi, I tried to install both sd and vat on a FreeBSD 1.1.5.1 and in both cases I got simply Bad system call (core dumped) and nothing else. Under gdb it says Program received signal SIGSYS (12), Bad system call 0xbfe8d in fstat () I compiled the kernel with MULTICAST & MROUTING options set but I don't run mrouted on this machine. The binaries release was i386-sd and i386-vat . Can anyone help? Thank you -Antonio ------------------------------------------------------------------------- Antonio Calegari CILEA - Segrate - Milan tel. : +39 (0)2 26995 257 Interuniversity Computing Centre email: calegari@icil64.cilea.it ITALY From rem-conf-request@es.net Tue Nov 08 09:39:42 1994 Received: from miller.cs.uwm.edu by osi-west.es.net via ESnet SMTP service id <03598-0@osi-west.es.net>; Tue, 8 Nov 1994 06:39:17 +0000 Received: (from james@localhost) by miller.cs.uwm.edu (8.6.9/8.6.9) id IAA26054; Tue, 8 Nov 1994 08:38:51 -0600 Date: Tue, 8 Nov 1994 08:38:51 -0600 From: Jim Lowe Message-Id: <199411081438.IAA26054@miller.cs.uwm.edu> To: calegari@cilea.it, rem-conf@es.net Subject: Re: sd vat etc on FreeBSD > > I tried to install both sd and vat on a FreeBSD 1.1.5.1 and in both cases > I got simply > > Bad system call (core dumped) FreeBSD 1.1.5.1 requires a few kernel mods before you can run vat, sd, or wb. I have a hack to FreeBSD 1.0 for the fstat system call that you could merge into 1.1.5.1 to get rid of the core dump. This gets you to the point where you see the real problem. Vat requires full duplex audio. I have hacked up the sound drivers for 1.0 so vat will work, but I havn't sent my changes back to the FreeBSD core team because I can't make them work on the machines here without modifying the source code for each machine (timing problems with the ISA bus). If you like, I can send you the changes for 1.0. I am planning on implementing a better solution once FreeBSD 2.0 is released. -Jim From rem-conf-request@es.net Wed Nov 09 15:30:38 1994 Received: from hplms26.hpl.hp.com by osi-west.es.net via ESnet SMTP service id <11640-0@osi-west.es.net>; Tue, 8 Nov 1994 21:45:23 +0000 Received: from hplabsz.hpl.hp.com by hplms26.hpl.hp.com with SMTP (1.36.108.4/15.5+ECS 3.3+HPL1.1S) id AA07920; Tue, 8 Nov 1994 21:46:29 -0800 Received: by hplabsz.hpl.hp.com (1.37.109.11/15.5+ECS 3.3+HPL1.1) id AA048299915; Tue, 8 Nov 1994 21:45:15 -0800 From: Laura de Leon Message-Id: <9411082145.ZM4827@hplabsz.hpl.hp.com> Date: Tue, 8 Nov 1994 21:45:15 -0800 X-Mailer: Z-Mail (3.0.0 15dec93) To: rem-conf@es.net Subject: (Fwd) BayLISA meeting: Jonny Goldman: HTTP proxies and data gateways Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 *** SPECIAL MEETING ANNOUNCEMENT *** This November BayLISA will be holding its annual election the board of directors. The meeting will begin at 7:00pm, not 7:30pm as normal, in order for member to pick up their ballots and vote. If your membership has lapsed, or you are not sure, please come anyways, we will have the latest membership list, and plenty of membership forms for you to renew your membership. ************************************* The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. BayLISA holds monthly meetings on the third Thursday of each month at 7:30 PM (please do not arrive before 7:00). We meet at Synopsys Building C in Mountain View, California off Highway 237 at Middlefield. This meeting will also be broadcast via mbone. Schedule -------- November 17th: Jonny Goldman: HTTP proxies and data gateways With the explosion in the availability of information on the Internet and tools to access them (like WAIS, Gopher and the World Wide Web/Mosaic), a need has arisen to both protect private networks while allowing users inside those networks access using the tools. In addition, organizations are looking to provide their current information sources using these new tools. In my talk I will outline some of the methods for allowing internal network access to these information sources using gateways and proxies. I will also give some examples of gateways from internal information sources to these tools. December 15th: Stupid Unix Tricks Bring your stupid user tricks, stupid admin tricks, stupid computer tricks, whatever you've got. This meeting will NOT be broadcast on the mbone. To get further information on the meeting location, you can request it >from the majordomo server on baylisa.org, you can ftp it from ftp.baylisa.org:/BayLISA/location or you can query the BayLISA mail server by cutting and pasting the following line to your shell: echo "index baylisa" | mail majordomo@baylisa.org BayLISA makes video tapes of the meetings available to members. For more information on available videos, please send email to: video@baylisa.org For any other information, please send email to: info@baylisa.org If you have any questions, please contact me or any of the info alias listed above. From rem-conf-request@es.net Wed Nov 09 16:07:59 1994 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <13280-0@osi-east.es.net>; Tue, 8 Nov 1994 15:44:05 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA26994; Tue, 8 Nov 94 15:44:02 PST Date: Tue, 8 Nov 94 15:44:02 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9411082344.AA26994@viipuri.nersc.gov> To: rem-conf@es.net Subject: FORWARDED: Requesting information ----- Begin Included Message ----- >From telapp@ucauca.edu.co Mon Oct 31 13:50:13 1994 Date: Mon, 31 Oct 1994 16:50:18 -0300 (CDT) From: Aplicaciones Telematicas To: Audio/Video Transport Subject: Requesting information Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1266 Dear Gentlemen, We are two electronics engineering students of Cauca University, we are researching about voice transmission through a LAN (type Ethernet), TCP/IP or through Internet. If you have any information about: - Voice transmission in real-time or store-and-forward over a Net Ethernet or TCP/IP. - Voice messaging, in general (e.g over Internet). - Voice electronic mail. - Requirement SW and HW for all previous. - Existing products. - Acquainted topics, people or companies that could be working about it. Besides, name server where we can find information. Please send us, as soon as possible any information. Thanks a lot for your information and help. Friendly, =========================================================================== Javier Andrade Sarria | Investigacion Aplicaciones Telematicas Cesar Antonio Ibarguen | Calle 1AN #11-42 | Universidad del Cauca Popayan | E-mail : telapp@atenea.ucauca.edu.co Colombia , South America | | Facultad de Ingenieria Electronica | Universidad del Cauca =========================================================================== ----- End Included Message ----- From rem-conf-request@es.net Wed Nov 09 16:15:31 1994 Received: from media-lab.media.mit.edu by osi-west.es.net via ESnet SMTP service id <17596-0@osi-west.es.net>; Wed, 9 Nov 1994 11:43:06 +0000 Received: by media.mit.edu (5.57/DA1.0.4.amt) id AA23527; Wed, 9 Nov 94 14:42:01 -0500 Date: Wed, 9 Nov 94 14:42:01 -0500 From: Sarah Dickinson Message-Id: <9411091942.AA23527@media.mit.edu> To: ericd@interop.net, rem-conf@es.net Subject: Re: Sky Cries Mary q From rem-conf-request@es.net Wed Nov 09 22:24:29 1994 Received: from ibminet.awdpa.ibm.com by osi-west.es.net via ESnet SMTP service id <21771-0@osi-west.es.net>; Wed, 9 Nov 1994 19:23:56 +0000 Received: by ibminet.awdpa.ibm.com (5.61/1.15) id AA05001; Wed, 9 Nov 94 19:29:37 -0800 Received: by ibmpa.awdpa.ibm.com (5.65b(em1)/2.06) id AA18928; Wed, 9 Nov 94 19:19:51 -0800 Received: from taurus.cs.nps.navy.mil by ibminet.awdpa.ibm.com (5.61/1.15) id AA04748; Wed, 9 Nov 94 19:12:25 -0800 Received: from trouble.cs.nps.navy.mil by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA02598; Wed, 9 Nov 94 19:08:42 PST Received: by trouble.cs.nps.navy.mil (940715.SGI.52/911001.SGI) for @taurus.cs.nps.navy.mil:rem-conf%es.net@ibmpa.awdpa.ibm.com id AA15865; Wed, 9 Nov 94 19:08:41 -0800 From: Your VE info source Message-Id: <9411091908.ZM15854@trouble.cs.nps.navy.mil> Date: Wed, 9 Nov 1994 19:08:41 -0800 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: rem-conf%es.net@ibmpa.awdpa.ibm.com Subject: PRESENCE Call for Participation: The Human Figure in VE Systems Mime-Version: 1.0 Encoding: 2 TEXT BOUNDARY, 115 MESSAGE, 3 TEXT BOUNDARY Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19411091908.ZM15854.cs.nps.navy.mil" --PART-BOUNDARY=.19411091908.ZM15854.cs.nps.navy.mil Encoding: 109 X-Zm-quoted-printable Content-Description: plain text Content-Type: text/plain ; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Zm-Decoding-Hint: mimencode -q -u PRESENCE: Call for Participation: "The Human Figure in VE Systems" PRESENCE will devote a special issue to "The Human Figure in Virtual = Environment Systems". Co-editors of this special issue are David = Zeltzer of MIT and Michael Zyda of the Naval Postgraduate School. The focus of this issue is on both hardware and software technologies = for integrating the human figure into VE systems, either as = "autonomous actors" under program control, or as "guided actors" controlled by humans in a master/slave mode. Areas of interest = include, but are not limited to: -- Applications that require or would benefit from the inclusion of = human figures; -- Representing, controlling and interacting with autonomous human = agents; -- Technology for instrumenting human VE participants; Software for = recording and interpreting human movements and managing interacti= ons = with actors and objects in the virtual world; -- Technologies that allow combinations of human participants and = autonomous or guided actors to jointly manipulate objects in the = virtual world, perhaps with force feedback. Human figure simulation research has been ongoing for several = decades. We are particularly interested in papers that survey and = reflect on the "grand challenges" for human figure simulation and = interaction, including discussions of the nature of progress made in = the field in the intervening years, and the difficult problems that = remain unsolved. What will be the likely state-of-the-art of human = figure simulation in five years? In fifty years? = We are interested in technical papers, position papers surveying the = field and forum papers describing the frontiers of integrating the = human figure into VE systems. We have the complete issue to fill, = which means we desire=CAtraditional research papers, lab reviews, and = "What's Happening" submissions. For the What's Happening section, = we request information on conference announcements, and other = VE/teleoperation events. PRESENCE is the premier journal of teleoperation and virtual = environments. Manuscripts are accepted for consideration with the = understanding that they represent original material and are not = being considered for publication elsewhere. Manuscripts should be in 12 point type, using double-spaced pages = for all text, including references. For more information, see the = "Instructions to Contributors" note on the inside back cover of = PRESENCE Vol. 3 No. 2 and later issues. Please include an electronic = mail address to which receipt acknowledgment can be sent. FAXed = submissions will NOT be accepted. Send 7 copies of each submitted paper (one for each co-editor, and = one for each of 5 reviewers) to David Zeltzer at the following = address: David Zeltzer PRESENCE Human Figure Issue Massachusetts Institute of Technology Room 36-763, 50 Vassar Street Cambridge MA 02139 Tel: (617) 253-5995 FAX: (617) 258-7003 e-mail: dz@vetrec.mit.edu The deadline for submissions to this special issue is May 15, 1995. = Submitted papers must be at MIT by that date in order for us to = have sufficient review time for our publication schedule. = Important deadlines: -- Submission of papers: May 15, 1995 -- Acceptance notification: July 15, 1995 -- Submission of final, camera-ready papers: September 1, 1995 --PART-BOUNDARY=.19411091908.ZM15854.cs.nps.navy.mil-- From rem-conf-request@es.net Thu Nov 10 04:33:25 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <23705-0@osi-west.es.net>; Thu, 10 Nov 1994 01:32:57 +0000 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 10 Nov 1994 09:32:39 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 or +44 71 387 7050 ext 3666 To: rem-conf@es.net Subject: Minimally Invasive Surgery Date: Thu, 10 Nov 94 09:31:53 +0000 Message-ID: <6288.784459913@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk We hope to multicast a seminar in minimally invasive surgery on the Mbone tomorrow (11th Nov) from 09:00 GMT to 17:00 GMT. This will involve live operations from the Middlesex Hospital in London, and >from hospitals in Gothenburg and San Francisco. The target audience is actually groups of medical students at the Middlesex and Whittington Hospitals in London and in Gothenburg, but if you're interested, we'll be on the following addresses: vat -t 127 224.5.17.12/3456 ivs -t 95 224.5.17.12/2232 We'll actually be sending with a pre-release of Steve McCanne and Van Jacobson's vic video tool using H.261 encoding, but you should be able to decode it using IVS. Sorry for the short notice - if our traffic causes any problems, please mail me to let me know. Mark From rem-conf-request@es.net Thu Nov 10 09:53:30 1994 Received: from expo.x.org by osi-west.es.net via ESnet SMTP service id <25366-0@osi-west.es.net>; Thu, 10 Nov 1994 06:53:04 +0000 Received: from expire.x.org by expo.x.org id AA05439; Thu, 10 Nov 94 09:53:02 -0500 Received: by expire.x.org id AA02164; Thu, 10 Nov 94 09:53:09 EST Message-Id: <9411101453.AA02164@expire.x.org> To: rem-conf@es.net Subject: Call for Participation in X Consortium Multimedia Workshop Date: Thu, 10 Nov 1994 09:53:09 EST From: Bob Scheifler The following workshop may be of interest to developers on this list. The X Consortium is hosting a one-day workshop on multimedia directions. The purpose of the workshop is to understand what the X Consortium should focus on in developing infrastructure standards in this area. Participants will help determine requirements, define application domains, and discuss key architectural issues that result. The workshop is expected to focus on video and synchronization aspects of multimedia systems that should be provided in the X Window System. Participants can assume that an intended direction for the X Consortium is to pursue a standard network audio service. See NAS and AF in the X11R6 contributed software as likely bases for this work. The workshop will be Thursday, February 2, 1995, in Boston. This is the day after the 9th X Technical Conference, so this is a chance to get more value for your airplane ticket. The workshop will last all day. There will be short presentations and group discussion in the morning. The participants will split into subgroups in the afternoon, then come back for summary discussion as one group. The workshop is open to the public; you do not have to work for an X Consortium member organization to participate. Representation is welcome >from end users, independent software and hardware vendors, and platform vendors. Prospective participants must provide a 1-page written position statement, or alternatively a 1-page statement of the relevance of their attending. The position statement should address some or all of the following topics: key application domains key requirements key architectural issues appropriateness of developing standards in the X Consortium appropriate relationships with other industry efforts Participants are also encouraged to propose a short (10 to 20 minute) presentation to give during the morning session to elaborate on their position statement. To register, respond to workshop@x.org by the end of Wednesday, December 14th. In your email message, include your name, company, position within the company, and a plain text version of your position statement. If you want to make a presentation, please include the title, abstract, and desired time duration. If you are accepted into the workshop, the information you provide will be circulated to all attendees prior to the workshop. Notification of acceptance will be given by Friday, December 16. Here are some example application domains to get you thinking: video in a window video on demand video conferencing data conferencing video multicast CD-ROM based training multimedia kiosks video WWW multimedia authoring industrial video editing Hollywood video editing Here are some example architectural issues to get you thinking: analog vs. digital video digital video formats compression techniques reliable vs. unreliable transport unicast vs. multicast quality of service considerations X protocol vs. non-X protocol processing data in client vs. server peer-to-peer server synchronization (e.g., with an audio server) From rem-conf-request@es.net Thu Nov 10 13:06:19 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <27191-0@osi-west.es.net>; Thu, 10 Nov 1994 10:05:53 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 10 Nov 1994 18:05:24 +0000 To: rem-conf@es.net Subject: Re: Call for Participation in X Consortium Multimedia Workshop In-reply-to: Your message of "Thu, 10 Nov 94 09:53:09 EST." <9411101453.AA02164@expire.x.org> Date: Thu, 10 Nov 94 18:05:20 +0000 Message-ID: <3390.784490720@cs.ucl.ac.uk> From: Jon Crowcroft >Here are some example application domains to get you thinking: > video in a window > video on demand > video conferencing > data conferencing > video multicast > CD-ROM based training > multimedia kiosks > video WWW > multimedia authoring > industrial video editing > Hollywood video editing >Here are some example architectural issues to get you thinking: > analog vs. digital video > digital video formats > compression techniques > reliable vs. unreliable transport > unicast vs. multicast > quality of service considerations > X protocol vs. non-X protocol > processing data in client vs. server > peer-to-peer server synchronization (e.g., with an audio server) another, maybe: ? i'm interested in the interaction between the data distribution model and the choice of protocol functionality....be it synchronisation, uni versus multi and reliable versus unreliable...X meets mbone meets www....meets rsvp...meets...? jon From rem-conf-request@es.net Thu Nov 10 14:14:46 1994 Received: from philabs.philips.com by osi-west.es.net via ESnet SMTP service id <28002-0@osi-west.es.net>; Thu, 10 Nov 1994 11:14:19 +0000 Received: from wizard.philabs.philips.com by philabs.philips.com (smail2.5/12-15-87/4.1) id AA13711; Thu, 10 Nov 94 14:14:16 EST Received: from loopback by wizard.philabs.philips.com (4.1/SMI-4.1) id AA20968; Thu, 10 Nov 94 14:14:15 EST Message-Id: <9411101914.AA20968@wizard.philabs.philips.com> To: rem-conf@osi-west.es.net Subject: mrouted problems. Date: Thu, 10 Nov 94 14:14:14 EST From: sud@philabs.philips.com Hi Everyone, Our site has been running MBONE for quite somtime now, and we recently decided to upgrade our bastion host to a new release of OS namely SunOS 4.1.3U1B ( from 4.1.3 ). After the upgrade, I rebuilt the kernel for Multicast support with the new kernel files, namely SunOS 4.1.3U1B. But now, my mrouted does not start up. As before, I tried to start from /etc/rc file, but it would'nt. Even trying to start manually fails. The following is the output in the debug mode: # /usr/etc/mrouted -c /etc/mrouted.conf -d 3 debug level 3 mrouted version 2.0 installing le0 (130.140.55.4 on subnet 130.140.55) as vif #0 installing le1 (192.207.123.2 on subnet 192.207.123) as vif #1 installing tunnel from 192.207.123.2 to 147.225.1.105 as vif #2 installing tunnel from 130.140.55.4 to 130.140.51.6 as vif #3 setsockopt DVMRP_ADD_VIF: Can't assign requested address I would appreciate any pointers/suggestions/workarounds to the above problem. Thank you, Sudheer. From rem-conf-request@es.net Thu Nov 10 14:30:49 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <28151-0@osi-west.es.net>; Thu, 10 Nov 1994 11:30:08 +0000 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 10 Nov 1994 19:29:54 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 cc: rem-conf@es.net Subject: Re: Minimally Invasive Surgery In-reply-to: Your message of "Thu, 10 Nov 94 09:31:53 GMT." <6288.784459913@cs.ucl.ac.uk> Date: Thu, 10 Nov 94 19:29:05 +0000 Message-ID: <7362.784495745@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >We hope to multicast a seminar in minimally invasive surgery on the >Mbone tomorrow (11th Nov) from 09:00 GMT to 17:00 GMT. This will >involve live operations from the Middlesex Hospital in London, and >from hospitals in Gothenburg and San Francisco. The target audience >is actually groups of medical students at the Middlesex and >Whittington Hospitals in London and in Gothenburg, but if you're >interested, we'll be on the following addresses: I was a bit premature in announcing this. We will go ahead tomorrow, but the general concensus after todays test transmissions was that in the interests of the patients' privacy, this should not be done on a public session. The videos we'd seen beforehand hadn't made it obvious the nature of all the video material involved. We've changed the scope of the session, so the traffic will not be so widely sent, and moved to different multicast addresses. This session will not be announced in sd. This is one case where some of the laws on encryption are clearly ridiculous. Apologies again, Mark From rem-conf-request@es.net Thu Nov 10 17:03:22 1994 Received: from cancer.ucs.ed.ac.uk by osi-west.es.net via ESnet SMTP service id <29907-0@osi-west.es.net>; Thu, 10 Nov 1994 14:02:37 +0000 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.9/8.6.9) with ESMTP id WAA11920; Thu, 10 Nov 1994 22:02:27 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id WAA10413; Thu, 10 Nov 1994 22:02:21 GMT Date: Thu, 10 Nov 1994 22:02:20 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: sud@philabs.philips.com cc: rem-conf@es.net Subject: Re: mrouted problems. In-Reply-To: <9411101914.AA20968@wizard.philabs.philips.com> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/~jaw/" X-Phone: +44 31 650 5003 X-Fax: +44 31 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 10 Nov 1994 sud@philabs.philips.com wrote: > Our site has been running MBONE for quite somtime now, and we > recently decided to upgrade our bastion host to a new release > of OS namely SunOS 4.1.3U1B ( from 4.1.3 ). > > After the upgrade, I rebuilt the kernel for Multicast support with > the new kernel files, namely SunOS 4.1.3U1B. But now, my mrouted > does not start up. As before, I tried to start from /etc/rc file, > but it would'nt. Even trying to start manually fails. > > The following is the output in the debug mode: > # /usr/etc/mrouted -c /etc/mrouted.conf -d 3 > > debug level 3 > mrouted version 2.0 ^^^^ here is your problem. The kernel mods for 4.3.1_U1 are only available for versions 3.1 and 3.3 of the multicast code (as far as I am aware). 3.1 and 3.3 use pruning to cut-out the routing of multicast traffic that noone is actively receiving. Version 2.0 of mrouted does not support pruning. You therefore need to use the version of mrouted that came in the tar file with the kernel modificications. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Thu Nov 10 22:09:45 1994 Received: from babar.lm.com by osi-west.es.net via ESnet SMTP service id <01873-0@osi-west.es.net>; Thu, 10 Nov 1994 19:07:45 +0000 Received: (from doug@localhost) by babar.lm.com (8.6.9/8.6.9) id WAA03530; Thu, 10 Nov 1994 22:07:56 -0500 Date: Thu, 10 Nov 1994 22:07:55 -0500 (EST) From: Doug Luce X-Sender: doug@babar.lm.com To: rem-conf@es.net Subject: Censorship debate at Carnegie Mellon Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Tommorrow at 22:00GMT, I'll be broadcasting a 1-hour interview show concerning the recent decision by Carnegie Mellon's administration to remove all Usenet newsgroups that might contain prurient material from campus computers. This will be followed by a rebroadcast of the 2-hour rally on Wednesday held by students protesting the censorship. Watch sd for the session. Doug Luce Telerama Public Access Internet From rem-conf-request@es.net Fri Nov 11 15:28:52 1994 Received: from mercury.unt.edu by osi-west.es.net via ESnet SMTP service id <07829-0@osi-west.es.net>; Fri, 11 Nov 1994 12:28:28 +0000 Received: from noc.unt.edu by mercury.unt.edu with SMTP id AA07478 (5.65c/IDA-1.4.4 for ); Fri, 11 Nov 1994 14:28:25 -0600 Date: Fri, 11 Nov 1994 14:28:16 -0600 (CST) From: Darren Loher To: rem-conf@es.net Subject: looking for nv_record Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am interested in recording today's CMU Censorship presentation/debate. Where can I find nv_record? I need solaris binaries and source. If anyone else is recording this, please let me know! I am very interested in getting a copy of this event. -- Darren Loher University of North Texas darren@unt.edu Datacommunications 817-565-4168 From rem-conf-request@es.net Fri Nov 11 15:59:05 1994 Received: from nps.navy.mil by osi-west.es.net via ESnet SMTP service id <08078-0@osi-west.es.net>; Fri, 11 Nov 1994 12:58:39 +0000 Received: by nps.navy.mil (4.1/SMI-4.1) id AA07786; Fri, 11 Nov 94 12:55:03 PST From: kcohan@mpusd.K12.CA.US Original-Received: from cc:Mail by mpusd.K12.CA.US id AA784586166 Fri, 11 Nov 94 12:36:06 PP-warning: Illegal Received field on preceding line Date: Fri, 11 Nov 94 12:36:06 Encoding: 2312 Text Message-Id: <9410117845.AA784586166@mpusd.K12.CA.US> To: 4947@mgs.com, 71554.3331@compuserve.com, baer@nps.navy.mil, british-cars@autox.team.net, callahan94@aol.com, cchester@fnoc.navy.mil, colu@deepthought.armory.com, JEONG@lfmail.lfc.edu, love@nrlmry.navy.mil, mccann@nps.navy.mil, mira@nps.navy.mil, palese@corp.sgi.com, rem-conf@es.net, sjsmba@ix.netcom.com, sl9@seds.lpl.arizona.edu, SPEAR@NPS.NAVY.MIL, srainwater@ncc.com, Susan_Pond@rand.org, tom.logan@nitelog.com, vgtx08a@prodigy.com, wb8elk@delphi.com, wordy@ucsd.edu, youden@vid.hp.com, zuvella@corp.sgi.com, CHALL@hpci.nsc.com Subject: Celebration on the web. From the folks who brought you the MBONE holography show, and The Jupiter Comet Crash Bash Now- join our upcoming birthday celebration on the web. Anyone who wants to join can check out our web page: The URL will be http://www.sp.nps.navy.mil/kim/kim.html (this is being provided by NPS as an educational opportunity for MIRA, the Cherry Center, and MPUSD, thanks to Steve Bible) We will be updating it with pictures as the event progresses through out the evening. Kim Calling all party animals Kim and Laura are celebrating our birthdays together this year, and you're invited. November 19, 1994 from 3PM to whenever. We have had to upgrade our electrical service at the apartment just to handle the expected power load (I'm not making this up)!! We're making local history (see below) Throw your voice- off the moon. The first moon bounce radio demonstration in monterey county. We'll hit the moon with 50,000 watts of effective radiated power. Your voice hits the lunar surface, bounces off, and 2.7 seconds later, you hear the echo. We will be connected to the internet! As the party rages on, Steve Bible will upload pictures, sound clips, and anything else on the internet for people all around the world to view. We will be running our own internet World wide web mosaic home page. A first for a birthday party! Bring a picture of yourself, your art, or whatever to share with the world. Also we'll do: An electronic fox hunt The skydivers will be back, pending FAA approval. Model rocket drag races. Plane rides A paper airplane contest Starting around sundown: Mariachi music Folk dancing Classical piano by Katie Clare Mazzeo, Laura, and her mom Marge Gospel singing A remote telescope demonstration Be there or be bored. Bring: a picture of yourself to upload to the internet, dancing shoes, some food to share, and a bottle. Kim & Laura Cohan From rem-conf-request@es.net Fri Nov 11 19:08:53 1994 Received: from terminator.rs.itd.umich.edu by osi-west.es.net via ESnet SMTP service id <09362-0@osi-west.es.net>; Fri, 11 Nov 1994 16:08:20 +0000 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.9/2.3) with SMTP id TAA07956; Fri, 11 Nov 1994 19:08:13 -0500 Message-Id: <199411120008.TAA07956@terminator.rs.itd.umich.edu> To: rem-conf@es.net Subject: Audio Echo Cancellation Date: Fri, 11 Nov 1994 19:08:12 -0500 From: Dory Ethan Leifer Does anyone know of software which may run on a general purpose computer that would do a fairly good job at echo cancellation for audio conferencing applications? Possibly a PC program on a soundblaster card? Thank You, Dory LeifeRr University of Michigan From rem-conf-request@es.net Fri Nov 11 20:10:22 1994 Received: from std.sri.com by osi-west.es.net via ESnet SMTP service id <09883-0@osi-west.es.net>; Fri, 11 Nov 1994 17:10:01 +0000 Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1) id AA20193; Fri, 11 Nov 94 17:02:07 PST Message-Id: <9411120102.AA20193@std.sri.com> To: confctrl@isi.edu, rem-conf@es.net Cc: tfrivold@std.sri.com, rlang@std.sri.com Subject: Session Control Protocol Survey for MMUSIC IETF 12/94 Date: Fri, 11 Nov 1994 17:02:09 -0800 From: Ruth Lang The goal of the enclosed survey solicitation is twofold: 1) Gather information in order to solidify a set of functional requirements for session control. These requirements will be reflected in an architecture document and/or functional requirements document to be written by the MMUSIC working group. 2) Serve as a comparative basis for the development of an experimental session control protocol by MMUSIC. Therefore, we are soliciting descriptions of the Session Control Protocols you have defined and developed. Survey information will be made available to the IETF community for review at ftp://venera.isi.edu/confctrl and ftp://ws11.std.sri.com/pub/confctrl. During the IETF MMUSIC session tentatively scheduled on Thursday, December 8, 9:30a-12:00, we will review and discuss a summary of the surveys received and work to solidify a set of session control protocol requirements. In filling out this survey, you may wish to refer to a glossary of session control terms (ftp://ws11.std.sri.com/pub/confctrl/glossary), and the architectural framework diagram contained in ftp://venera.isi.edu/confctrl/minutes/ietf.3.93. Please send your responses to one or all of tfrivold@std.sri.com, rlang@sri.com, and confctrl@isi.edu by November 28, 1994. Later responses will be accepted, but may not be factored into the summary we present at IETF. If for some reason you are unable to complete each question, please send whatever information you can provide. Please post any questions or comments on the survey to us, with cc to confctrl@isi.edu. Thane J. Frivold, tfrivold@std.sri.com Ruth E. Lang, rlang@sri.com ---------------------------------------------------------------------------- Session Control Protocol Survey =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Name of the Protocol (if any) Technical point(s) of contact including email address(es) and organization affiliation General Description ------------------- 1) Between what components is the protocol used? I.e., between media agents, between session managers, session manager to media agent, or other. 2) Describe, at a fairly high level, the characteristics of session control that are key to your protocol. I.e., what is the protocol trying to achieve and what special problems does it solve. E.g., process coordination, resource negotiation, media synchronization, floor control, topology management, etc. 3) Describe, at a fairly high level, the characteristics of session control that you do not care about or have (un)intentionally ignored. See examples in 3. General Protocol Characteristics -------------------------------- 4) Is the representation ASCII or binary? 5) Is the paradigm request/response (client/server model), peer-to-peer, or other? 6) Is it asymmetric or symmetric (e.g. do initiator's have special privileges or state information)? Are all messages sent to all participants or are some sent to a subset? 7) What transport protocol is used (TCP, UDP, multicast)? Does it make use of other protocols such as RTCP? 8) Does your session control protocol rely on that protocol's model of transmission? E.g., does it require reliable, ordered transmission or is multiparty state synchronization not a concern? 9) Briefly describe the addressing model, if any. I.e., how are messages routed to peers? Are they sent directly, are multicast groups used, is message content/registration used, or other? Session Control Characteristics ------------------------------- 10) How are sessions are described? What does a session description specify -- people, resources, scheduling information, etc.? Optionally, include an example session description. 11) Is the session description available and used outside of the context of the session control protocol? If so, how (pre-scheduling, email-based initiation, etc.)? 12) How is a session identified? I.e., what is the session "handle" and to what extent is it globally unique? 13) Briefly describe the membership model and range of models supported. Is the model open (potentially unknown participation and attendance -- lecture hall style), closed (well known and limited -- invitation only style), or other? 14) How are members named and/or identified? Are email-style addresses used, numeric identifiers, etc.? 15) Briefly describe "what" is being controlled within a session. Does the protocol control routing, data flow (e.g., floor control, channel selection), reflectors, end-user applications, etc.? Are these entities controlled in a centralized or distributed manner? 16) How is consensus achieved among parties exchanging this protocol? E.g., does initiator dictate policy, does a mismatch lead to failure, does negotiation occur when agreement can not be achieved? 17) What aspects of the conference are negotiable? Members, protocols, data formats, resources, scheduling, policy, etc.? 18) What policies are implemented explicitly or implicitly (e.g., no latecomers permitted, only one video flow at a time, etc.)? Is the choice of policy driven by system requirements, implementation constraints, resource limitations, etc? Are the policies configurable? Session Control Protocol Specifics ---------------------------------- 19) What is the implementation status of the protocol (paper design, partially or fully implemented)? What language was used to implement the protocol and how is it packaged (in a library, embedded in an application)? Is the implementation freely available? 20) Describe, at a fairly high level, the basic directives of the protocol. I.e., What are the protocol "commands" and what parameters are required? If protocol uses a request-response model, indicate these pairs. (If this information is contained in a publically-available paper or report, please provide a reference rather than detail here). From rem-conf-request@es.net Fri Nov 11 20:19:35 1994 Received: from csa2.lbl.gov by osi-west.es.net via ESnet SMTP service id <09952-0@osi-west.es.net>; Fri, 11 Nov 1994 17:19:09 +0000 Date: Fri, 11 Nov 94 17:19:00 PST From: loken@Csa2.LBL.Gov Message-Id: <941111171900.25424c6a@csa2.lbl.gov> Subject: MBone conference. To: rem-conf@es.net X-ST-Vmsmail-To: ST%"rem-conf@es.net" LBL and the Mathematical Sciences Research Institute (MSRI) are hosting a major conference on the Future of Mathematics Communication The dates are 30 November - 3 December. We plan to broadcast this meeting as a way of introducing the technology as to involve more university participants. The conference is supported by DOE Office of Scientific Computing and the NSF. More information is available on the Web. Stu Loken From rem-conf-request@es.net Fri Nov 11 20:22:15 1994 Received: from std.sri.com by osi-west.es.net via ESnet SMTP service id <09983-0@osi-west.es.net>; Fri, 11 Nov 1994 17:21:42 +0000 Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1) id AA20207; Fri, 11 Nov 94 17:13:49 PST Message-Id: <9411120113.AA20207@std.sri.com> To: confctrl@isi.edu, rem-conf@es.net Cc: tfrivold@std.sri.com, rlang@std.sri.com Subject: SRI's Session Control Protocol Survey Response Date: Fri, 11 Nov 1994 17:13:52 -0800 From: Ruth Lang For both information and an example, the survey describing SRI's Session Control Protocol is included below. Thane J. Frivold Ruth E. Lang ---------------------------------------------- Session Control Protocol Survey =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Protocol Name: None currently Point of Contact: Thane Frivold -- tfrivold@std.sri.com Ruth Lang -- rlang@sri.com SRI International Augmented Collaborative Environments Group General Description ------------------- 1) Between what components is the protocol used? The protocol primarily flows between session managers. A limited amount of control information flows between the session manager and our shared workspace agents (XCPS). All other media agent control is limited to command line configuration. 2) Describe, at a fairly high level, the characteristics of session control that are key to your protocol. The protocol was originally implemented with an eye toward process management as well as reconciling resource requirements and capabilities in a heterogeneous environment. 3) Describe, at a fairly high level, the characteristics of session control that you do not care about or have (un)intentionally ignored. Because we have not ever had a cross media agent requirement for synchronized floor control, the protocol does not manage floor control. It is assumed to be a function of the media agents. Also, the session control protocol does not provide its own transport reliability; that is assumed to be provided by a lower level protocol. General Protocol Characteristics -------------------------------- 4) Is the representation ASCII or binary? The protocol is ASCII. 5) Is the paradigm request/response (client/server model), peer-to-peer, or other? The model is peer-to-peer. 6) Is it asymmetric or symmetric (e.g. do initiator's have special privileges or state information)? Are all messages sent to all participants or are some sent to a subset? All peers are, at the protocol level, considered equal. In the future, we envision any asymmetry to occur because of an imposed or negotiated "policy" for the session. Operationally, most messages are sent to all peers, but the protocol allows directing messages to an arbitrary subset of peers. 7) What transport protocol is used (TCP, UDP, multicast)? Does it make use of other protocols such as RTCP? The protocol currently uses TCP. 8) Does your session control protocol rely on that protocol's model of transmission? E.g., does it require reliable, ordered transmission or is multiparty state synchronization not a concern? The protocol relies upon both the ordered and reliable delivery of messages provided by TCP. 9) Briefly describe the addressing model, if any. I.e., how are messages routed to peers? Are they sent directly, are multicast groups used, is message content/registration used, or other? Messages are sent directly to peers, and thus can be addressed by destination only. Session Control Characteristics ------------------------------- 10) How are sessions are described? What does a session description specify -- people, resources, scheduling information, etc.? Optionally, include an example session description. The current description format consists of a series of peer (session manager hosts), participants (human usrs and their display and execution hosts), and processes (media agents and/or applications). The basic format of each of these directives is: confConfig [add|delete] [peer|participant|process|cma] A sample session description is: confConfig exampleConf add peers foo.com bar.com confConfig exampleConf add participant joe foo.com foo.com foo.com:0.0 confConfig exampleConf add participant sue bar.com bar.com bar.com:0.0 confConfig exampleConf add process audio vat -C "exampleconf" 224.23.45.67 confConfig exampleConf add process textEdit emacs confConfig exampleConf add cma XCPS xcps -server unix:0.0 11) Is the session description available and used outside of the context of the session control protocol? If so, how (pre-scheduling, email-based initiation, etc.)? The protocol is currently used to describe preconfigured sessions which are stored and accessed through an HTTP server. Current development includes incorporating MIME based initiation and, eventually, general session and participant registration. 12) How is a session identified? I.e., what is the session "handle" and to what extent is it globally unique? The session ID is currently a text string and is globally unique only by virtue of global coordination. 13) Briefly describe the membership model and range of models supported. Is the model open (potentially unknown participation and attendance -- lecture hall style), closed (well known and limited -- invitation only style), or other? The environment assumes closed membership (often by invitation only) sessions, at least as far as our shared workspace agent (XCPS) goes. The session manager can initiate arbitrary processes, so MBONE style tools that support open membership can also be used. 14) How are members named and/or identified? Are email-style addresses used, numeric identifiers, etc.? Participants are currently identified by a user name and an X11 display; participant data is publically stored as properties on each X11 display, thus creating a distributed database of information. Current development is moving toward a "globally distributed, locally centralized" model (a la DNS) so that email style addresses could indicate both the individual and the administrative domain to contact for the information. 15) Briefly describe "what" is being controlled within a session. Does the protocol control routing, data flow (e.g., floor control, channel selection), reflectors, end-user applications, etc.? Are these entities controlled in a centralized or distributed manner? The protocol is basically centered around controlling processes (configuration, invocation, and termination) and controlling our shared workspace agent (configuring participants). The processes are all controlled in a distributed manner, although, through session manager communication, certain user actions may be sent from a single session manager to synchronize effects on the others. 16) How is consensus achieved among parties exchanging this protocol? E.g., does initiator dictate policy, does a mismatch lead to failure, does negotiation occur when agreement can not be achieved? Currently, a mismatch will lead to failure. 17) What aspects of the conference are negotiable? Members, protocols, data formats, resources, scheduling, policy, etc.? At present, none. 18) What policies are implemented explicitly or implicitly (e.g., no latecomers permitted, only one video flow at a time, etc.)? Is the choice of policy driven by system requirements, implementation constraints, resource limitations, etc? Are the policies configurable? No explicit policy support is implemented; all peers are considered equal and floor control is assumed to be handled by media agents. Also, because the session managers communicate under a closed model, the protocol implicitly enforces a closed model policy on membership. Session Control Protocol Specifics ---------------------------------- 19) What is the implementation status of the protocol (paper design, partially or fully implemented)? What language was used to implement the protocol and how is it packaged (in a library, embedded in an application)? Is the implementation freely available? The protocol is alive and kicking, albeit currently under continued development. The session manager is implemented in C, but the ASCII protocol is written and interpreted by Tcl. Most of the "protocol" is implemented in Tcl, but certain low level primitives have been added to extend the Tcl vocabulary, so the Tcl code is not completely separable from the session manager. The implementation is not currently available 20) Describe, at a fairly high level, the basic directives of the protocol. I.e., What are the protocol "commands" and what parameters are required? If protocol uses a request-response model, indicate these pairs. (If this information is contained in a publically-available paper or report, please provide a reference rather than detail here). The "logical" directives include the following commands: # # Usage: invite [] # # # Usage: decline [] # # # Usage: confDelete # # # Usage: confExists # # # Usage: confConfig # # = "add" | "delete" # = "cma" | "process" | "participant" | "peers" # # = "cma" | "process" # arg1 = # arg2 = # NOTE: should also have indication of one/multiple instance/invocation # # = "participant" # arg1 = # arg2 = # arg3 = # arg4 = # # = "peers" # arg1 .. argN = # # # Usage: confExec # # = "cma" | "process" # = (as defined in previous call to confConfig) # # # Usage: confKill # # = "cma" | "process" # = (as defined in previous call to confConfig) # # # Usage: confStopped # # # Usage: confStart # # = "cma" | "process" # # # Usage: confStop # # = "cma" | "process" # From rem-conf-request@es.net Fri Nov 11 23:08:12 1994 Received: from nic.funet.fi by osi-west.es.net via ESnet SMTP service id <10784-0@osi-west.es.net>; Fri, 11 Nov 1994 20:07:24 +0000 Received: by nic.funet.fi id <92042-2>; Sat, 12 Nov 1994 06:07:05 +0200 Subject: Re: Audio Echo Cancellation From: Matti Aarnio To: leifer@terminator.rs.itd.umich.edu (Dory Ethan Leifer) Date: Sat, 12 Nov 1994 06:07:02 +0200 Cc: rem-conf@es.net In-Reply-To: <199411120008.TAA07956@terminator.rs.itd.umich.edu> from "Dory Ethan Leifer" at Nov 12, 94 02:08:12 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 1108 Message-Id: <94Nov12.060705eet.92042-2@nic.funet.fi> > Does anyone know of software which may run on a general purpose computer > that would do a fairly good job at echo cancellation for audio conferencing > applications? Possibly a PC program on a soundblaster card? Basically you need "just" a FIR-filter, however the problem comes with the product of sample_rate * max_echo_time. It tells you how many taps the FIR-filter needs to process for each sample. At 8 kHz sampling and 0.25 sec echo it means 2000 FIR-taps to be processed FOR EACH SAMPLE -- 16 million taps per second.. That is why such filtering is usually done with special-purpose processors known as signal processors -- they are specialized to execute FIR-tap kernels et.al. very fast, usually with one clock cycle. (a FIR-tap is: sum += constant[i] * value[i] ) There are other more creative ways to do echo cancellation, but they are not less compute intensive.. On some PC-audio-cards there are signal processing features, but I don't think they have real user-programmable DSPs. > Thank You, > Dory LeifeRr > University of Michigan /Matti Aarnio From rem-conf-request@es.net Fri Nov 11 23:31:32 1994 Received: from rpi.edu by osi-west.es.net via ESnet SMTP service id <10941-0@osi-west.es.net>; Fri, 11 Nov 1994 20:30:12 +0000 Received: from hibp.ecse.rpi.edu (hibp7.ecse.rpi.edu) by rpi.edu (4.1/SMHUB41); id AA25072; Fri, 11 Nov 94 23:30:06 EST for rem-conf@es.net Received: from hibp6.ecse.rpi.edu by hibp.ecse.rpi.edu (4.1/ST26); id AA27131 for rem-conf@es.net; Fri, 11 Nov 94 23:30:05 EST Message-Id: <9411120430.AA27131@hibp.ecse.rpi.edu> To: calegari@cilea.it (Antonio Calegari) Cc: rem-conf@es.net Subject: Re: TimeZone converter In-Reply-To: Your message of "Fri, 11 Nov 1994 10:56:37 +0200." <9411110948.AA03709@hibp6.ecse.rpi.edu.fusion> X-Mailer: exmh version 1.4zeta 6/3/94 Date: Fri, 11 Nov 1994 23:30:03 -0500 From: Paul Stewart I have a timezone converter that appears a little bit more user friendly that the one you supply. It's sort of a chameleon. http://hibp.ecse.rpi.edu/cgi-bin/tzconvert allows one to convert between two timezones, but to convert only to GMT, one can use http://hibp.ecse.rpi.edu/cgi-bin/tzconvert/togmt. It accepts both a date and a time, in order to allow for daylight savings time offsets, and offers a list of timezones to convert from. I basically stole wholesale the code to gmtoff from Markus Buchhorn (with his blessings, though :), and added a few features that fool the machine into converting to and from GMT, given dates and timezones that may not actually be that of the machine that the converter is running on. I've gotten the code to run reliably on the Sun (which is where this httpe server is running), however I need to do a little work to make it work on other platforms. I'm hoping, at the very least to have this be an alternative timezone converter to the one available on the Web MBone agenda. Any comments are welcome. -- Paul From rem-conf-request@es.net Sat Nov 12 02:59:50 1994 Received: from nps.navy.mil by osi-west.es.net via ESnet SMTP service id <11640-0@osi-west.es.net>; Fri, 11 Nov 1994 23:59:10 +0000 Received: by nps.navy.mil (4.1/SMI-4.1) id AA16825; Fri, 11 Nov 94 23:57:03 PST From: kcohan@mpusd.K12.CA.US Original-Received: from cc:Mail by mpusd.K12.CA.US id AA784625833 Fri, 11 Nov 94 23:37:13 PP-warning: Illegal Received field on preceding line Date: Fri, 11 Nov 94 23:37:13 Encoding: 713 Text Message-Id: <9410117846.AA784625833@mpusd.K12.CA.US> To: 4947@mgs.com, 71554.3331@compuserve.com, baer@nps.navy.mil, british-cars@autox.team.net, callahan94@aol.com, cchester@fnoc.navy.mil, CHALL@hpci.nsc.com, cleary@physics.nps.navy.mil, colu@deepthought.armory.com, dfnorman@nps.navy.mil, hietala@netcom.com, JEONG@lfmail.lfc.edu, love@nrlmry.navy.mil, mccann@nps.navy.mil, mira@nps.navy.mil, palese@corp.sgi.com, rem-conf@es.net, sjsmba@ix.netcom.com, sl9@seds.lpl.arizona.edu, SPEAR@NPS.NAVY.MIL, srainwater@ncc.com, srbible@nps.navy.mil, Susan_Pond@rand.org, tom.logan@nitelog.com, vgtx08a@prodigy.com, youden@vid.hp.com, zuvella@corp.sgi.com Subject: Our www home page ready on 11-14-94 77 folks have tried to access the page today. It isnt up yet, but will be in a few days. I am sorry for the inconvenience. The Kim & Laura www home page will be up and running on Monday 11-14-94 at 12:00 PST. It will continue through the party, which is 11-19-94. We have obtained a Apple quick take 100 camera, to update images onto the www home page during the party. The url is: http://www.sp.nps.navy.mil/kim/kim.html Many of the folks who did the mbone holography show, and the MIRA Comet Crash Bash will be at the partym and shown on the www home page. Kim Cohan Carmel Valley, CA From rem-conf-request@es.net Sat Nov 12 08:30:08 1994 Received: from crusher.mcnc.org by osi-west.es.net via ESnet SMTP service id <13511-0@osi-west.es.net>; Sat, 12 Nov 1994 05:29:43 +0000 Received: by crusher.mcnc.org (5.59/tas-concert/6-19-91) id AA02595; Sat, 12 Nov 94 08:29:04 -0500 From: Fengmin Gong Message-Id: <9411121329.AA02595@crusher.mcnc.org> Subject: Re: Audio Echo Cancellation To: mea@nic.funet.fi (Matti Aarnio) Date: Sat, 12 Nov 1994 08:29:04 -0500 (EST) Cc: leifer@terminator.rs.itd.umich.edu, rem-conf@es.net In-Reply-To: <94Nov12.060705eet.92042-2@nic.funet.fi> from "Matti Aarnio" at Nov 12, 94 06:07:02 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2356 Re: message from Matti Aarnio: > >> Does anyone know of software which may run on a general purpose computer >> that would do a fairly good job at echo cancellation for audio conferencing >> applications? Possibly a PC program on a soundblaster card? > I have actually implemented such a thing based on an adaptive FIR filter in C on my Sparc10, however it does not work at all. The problem does not seem to be lack of cycles in particular, but rather due to the "jitter" introduced when reading and sending audio samples to the A/D and D/A hardware. Because this basically destroys the filter's ability to model the feedback path between the local MIC and the speaker. I also tried to play with the Realtime process class within Solaris 2.x but no success. > Basically you need "just" a FIR-filter, however the problem > comes with the product of sample_rate * max_echo_time. > It tells you how many taps the FIR-filter needs to process > for each sample. > > At 8 kHz sampling and 0.25 sec echo it means 2000 FIR-taps > to be processed FOR EACH SAMPLE -- 16 million taps per second.. > That is why such filtering is usually done with special-purpose > processors known as signal processors -- they are specialized to > execute FIR-tap kernels et.al. very fast, usually with one clock > cycle. (a FIR-tap is: sum += constant[i] * value[i] ) > If you try to cancel the echo at the local site that introduced it (between the speaker and the MIC), which I feel that's the main thing to worry about, you may not need to cover 250ms. But again, I do believe a tiny DSP hardware addition to the audio interface on the current workstation will be sufficient to solve the problem. The main problem preventing use of the software is delay variation in the workstation. > There are other more creative ways to do echo cancellation, > but they are not less compute intensive.. Would those be neural net kind of approach? Could you pass some references to the list or to me please? > > On some PC-audio-cards there are signal processing features, > but I don't think they have real user-programmable DSPs. > >> Thank You, >> Dory LeifeRr >> University of Michigan > > /Matti Aarnio > > Thanks, -- Fengmin Gong E-mail: gong@mcnc.org Network Research Engineer Phone: 919 248-9214 MCNC Information Technologies FAX: 919 248-1455 From rem-conf-request@es.net Sat Nov 12 21:58:19 1994 Received: from media-lab.media.mit.edu by osi-west.es.net via ESnet SMTP service id <16414-0@osi-west.es.net>; Sat, 12 Nov 1994 18:57:34 +0000 Received: by media.mit.edu (5.57/DA1.0.4.amt) id AA01745; Sat, 12 Nov 94 21:57:29 -0500 Received: by thinkpix.com (5.0/SMI-SVR4) id AA03074; Sat, 12 Nov 1994 21:57:46 +0500 Date: Sat, 12 Nov 1994 21:57:46 +0500 From: cyrus@thinkpix.com (Cyrus Shaoul) Message-Id: <9411130257.AA03074@thinkpix.com> Content-Type: text Content-Length: 1235 Apparently-To: rem-conf@es.net For Immediate Release. The Stones Jam Live On MBONE! Thinking Pictures (http://thinkpix.com/) and Sun Microsystems (http://www.sun.com/) are proud to announce what will undoubtedly be the first ever live multicast of a major rock band's performance on the Internet. The Rolling Stones will be multicasting 20 minutes of their Dallas Cotton Bowl concert live over the MBONE on Friday, November 18th as promotion for their Pay-Per-View offer North American cable television on November 25th. We asked the Stones for 20-30 minutes of their concert so that the multicast would not severely affect national and international bandwidth. The multicast will occur at off peak hours and will be repeated regularly for 48 hours if permitted. The multicast will begin around 8:00pm USA central time. For details on: How to set up your Internet Host to receive the MBONE multicast or How to register your MBONE multicast Stones party as an official Stones MBONE Site for press coverage from local TV stations, and newspaper photo ops. or How to buy Stones tour merchandise over the Internet. please link to http://www.stones.com/ with your favorite WWW browser. Send questions to multicast@thinkpix.com From rem-conf-request@es.net Sun Nov 13 17:47:18 1994 Received: from sics.se by osi-west.es.net via ESnet SMTP service id <19753-0@osi-west.es.net>; Sun, 13 Nov 1994 14:46:53 +0000 Received: from hans-home.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA07891; Sun, 13 Nov 94 23:46:32 +0100 Message-Id: <9411132246.AA07891@sics.se> X-Mime-Version: 1.0 X-Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Nov 1994 23:47:04 +0100 To: cyrus@thinkpix.com (Cyrus Shaoul) From: hans@sics.se (Hans Eriksson) Subject: Re: rolling stones Cc: rem-conf@es.net, mbone@isi.edu, multicast@thinkpix.com At 21.57 94-11-12 +0500, Cyrus Shaoul wrote: >Thinking Pictures (http://thinkpix.com/) and Sun Microsystems >(http://www.sun.com/) are proud to announce what will undoubtedly be >the first ever live multicast of a major rock band's performance on >the Internet. I think this is a good thing (or rather, could have been). >The Rolling Stones will be multicasting 20 minutes of their Dallas >Cotton Bowl concert live over the MBONE on Friday, November 18th as >promotion for their Pay-Per-View offer North American cable television ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >or > How to buy Stones tour merchandise over the Internet. I think this is a very, very bad thing! Using MBone and whatever Internet resources like this for commercial things??? Come on Sun, I thought you should know better at least! dissapointed (as said in a Fish called Wanda)... /hans Hans Eriksson, SICS, Box 1263, Isafjordsg 22, 164 28 Kista, Sweden Tel: +46 8 752 1527 Fax: +46 8 751 7230 email: hans@sics.se From rem-conf-request@es.net Sun Nov 13 19:26:43 1994 Received: from art.net by osi-west.es.net via ESnet SMTP service id <20237-0@osi-west.es.net>; Sun, 13 Nov 1994 16:26:07 +0000 Received: (from lile@localhost) by art.net (8.6.9/8.6.9) id QAA08196; Sun, 13 Nov 1994 16:20:47 -0800 Date: Sun, 13 Nov 1994 16:20:47 -0800 From: Lile Elam Message-Id: <199411140020.QAA08196@art.net> To: cyrus@thinkpix.com, hans@sics.se Subject: Re: rolling stones Cc: mbone@ISI.EDU, multicast@thinkpix.com, rem-conf@es.net Can we make the MBone "noncommercial"? If so, then lets *do* it! I am all for noncommercial, non-profit, public access MBoning! :) -lile ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lile Elam | "a brush in hand, a wisp of wind, she sighs lile@art.net | knowing that this will be the great one..." http://www.art.net | -lile ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Sun Nov 13 20:52:36 1994 Received: from neoteny.eccosys.com by osi-west.es.net via ESnet SMTP service id <20465-0@osi-west.es.net>; Sun, 13 Nov 1994 17:51:59 +0000 Received: from tube.eccosys.com by eccosys.com (4.1/SMI-4.1-EB-940511.1) id AA00552; Mon, 14 Nov 94 10:57:51 JST Received: from localhost by tube.eccosys.com (4.1/eccosys-V0.7) id AA16496; Mon, 14 Nov 94 10:49:33 JST To: Lile Elam Cc: mbone@isi.edu, rem-conf@es.net Subject: Re: rolling stones In-Reply-To: Your message of "Sun, 13 Nov 1994 15:50:11 PST." <199411132350.PAA07944@art.net> Date: Mon, 14 Nov 1994 10:49:25 +0900 Message-Id: <16493.784777765@eccosys.com> From: Cyrus I am sorry to post this to both mbone and rem-conf, but I am not sure if I can cut out the people on the mbone list yet, even though this seems to be a discussion for rem-conf. Some questions I will ask: 1) Will this Multicast of the Rolling Stones live on Nov 18th, 8pm CST USA conflict with any other multicast? Please tell me if it does as soon as possible, so I can do something about it. Why wasn't this question asked by me about 3 weeks ago? Why only one week before? Because I was not sure if it was going to go through. There are still a few technical hurdles ahead, but things are looking up. 2) [not for rem-conf readers] I would like the concert to reach the European Australian, and Asian MBONEs (any others I don't know about?) What should I set the TTL to be? Any other parameters that would be good to set to a certain value? 3) Are there any other technical problems in general with doing this Multicast? Now some Questions Answered. 1) The physical setup: We are getting the video from Dallas piped up to the Thinking Pictures Studios (thinkpix.com). There, the NTSC signal will be fed into a SparcStation with a SunVideo board. We have a temporary multicast tunnel set up from there to Sprintlink. >From Sprintlink, it goes out to the world. 2) Is this good for the MBONE? I think it is. The words multicast and MBONE have been used in the broadcast media in reference to this, and now many people are asking what they mean. After the initial "Internet?" brouhaha in the broadcast media, they are looking for the NEXT BIG THING, and the MBONE may catch their interest. In term of the Internet community, I also see this as being a good thing. SInce we began talking about this multicast, we have had at least 50 pieces of e-mail from people interested in getting their institutions on the MBONE (for now, just to see the concert, but once you are on, you are on.) I see the growth of MBONE membership as a boon. I am a newbie on the MBONE. There will be many more. But we will learn, and even contribute content, if not programming talent. 3) Is this multicast going to offend people? I am sure it will. But if anybody would like to try to censor the content of the MBONE at this point, I think it is a little premature. In fact, I will try to get a wb session going, so that people can write comments about the concert in real-time. You can also always send e-mail to the Stones at any time to express your feeling about this. Please look on the web server (http://www.sones.com/) for info on how to do that. Compared to the normal world of snail mail and telephone answering service, I think this medium has much greater possibilities for feedback than the non-networked world. Make the 1st amendment live on the Internet!!!! I apologize for the delay in sending this out, and I request your reactions, and questions. If it is personal, don't send it to the list. If it is a flame, make it to me, not the list (NO FLAME WARS!) If it concerns everybody, send it to the list. Thanks, Cyrus Shaoul cyrus@thinkpix.com cyrus@eccosys.com From rem-conf-request@es.net Mon Nov 14 04:08:55 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <22235-0@osi-west.es.net>; Mon, 14 Nov 1994 01:08:23 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 14 Nov 1994 09:07:46 +0000 To: hans@sics.se (Hans Eriksson) cc: cyrus@thinkpix.com (Cyrus Shaoul), rem-conf@es.net, mbone@ISI.EDU, multicast@thinkpix.com Subject: Re: rolling stones In-reply-to: Your message of "Sun, 13 Nov 94 23:47:04 +0100." <9411132246.AA07891@sics.se> Date: Mon, 14 Nov 94 09:07:45 +0000 Message-ID: <558.784804065@cs.ucl.ac.uk> From: Jon Crowcroft >>The Rolling Stones will be multicasting 20 minutes of their Dallas >>Cotton Bowl concert live over the MBONE on Friday, November 18th as >>promotion for their Pay-Per-View offer North American cable television > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >I think this is a very, very bad thing! I agree - it is one thing to put up commercial provided internet infrastructure and then have commercial information services on it is quite another to use the open, largely non-commercial internet infrastructure that carries the mbone traffic to carry such blatant commercial stuff frankly, if we had commercial mbone routers in commercial parts of the internet, then it would be fine, but we don't and it isn't try and get an indy band at least. what is worst is that the investment that the cable tv people are putting in to provide highly centrally controlled pay-per-view is completely coutner-culture to the Internet (and has a less good business case, if they only uderstood this...) the notion of 'off peak' is also totally US centric - your off peak may be our highest load or the pacific rims or someones - it betrays a misunderstanding about the nature of the networked society.... that said, i wouldn't mind catching keef and the boys for nuffing, so long as the quality was any good... jon From rem-conf-request@es.net Mon Nov 14 04:32:43 1994 Received: from sics.se by osi-west.es.net via ESnet SMTP service id <22338-0@osi-west.es.net>; Mon, 14 Nov 1994 01:32:14 +0000 Received: from hans.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA16445; Mon, 14 Nov 94 10:29:56 +0100 Message-Id: <9411140929.AA16445@sics.se> X-Mime-Version: 1.0 X-Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Nov 1994 11:29:57 +0200 To: Cyrus From: hans@sics.se (Hans Eriksson) Subject: Re: rolling stones Cc: mbone@ISI.EDU, rem-conf@es.net At 10.49 94-11-14 +0900, Cyrus wrote: >2) Is this good for the MBONE? I think it is. The words multicast and >MBONE have been used in the broadcast media in reference to this, >and now many people are asking what they mean. After the initial >"Internet?" brouhaha in the broadcast media, they are looking for the NEXT BIG >THING, and the MBONE may catch their interest. If you only send "the Stones", fine! If you also send any promotion stuff (ads, whatever), NOT FINE. Internet usually comes down hard on blatant advertisements. What are your comments on this issue? /hans From rem-conf-request@es.net Mon Nov 14 04:50:55 1994 Received: from bgate.lut.ac.uk by osi-west.es.net via ESnet SMTP service id <22767-0@osi-west.es.net>; Mon, 14 Nov 1994 01:50:10 +0000 Received: by suna.lut.ac.uk (4.1/SMI-4.1) id AA04421; Mon, 14 Nov 94 09:48:00 GMT Date: Mon, 14 Nov 1994 09:40:04 +0000 (GMT) From: "Jon P. Knight" Subject: Re: rolling stones To: Cyrus Cc: mbone@ISI.EDU, rem-conf@es.net In-Reply-To: <9411140929.AA16445@sics.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On a more technical subject, seeing as the US-UK Fat Pipe to SuperJANET (where most of the UK MBONE sites are located) is currently being fixed by a cable laying ship and we're using a high latency satelite to provide the link, how much bandwidth is currently available for UK<->US MBONE comms? Is the satelite link with the Pipex backup fibre supply SuperJANET with roughly similar bandwidth as the Fat Pipe or are we running on fumes at the moment? Also, how will any routing instabilities caused by switching back and forth between the satelite and Pipex affect the playout times of adaptive applications such as vat? Jon -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Research Student in High Performance Networking and Distributed Systems in the Department of _Computer_Studies_ at Loughborough University. * It's not how big your share is, its how much you share that's important * From rem-conf-request@es.net Mon Nov 14 05:14:18 1994 Received: from neoteny.eccosys.com by osi-west.es.net via ESnet SMTP service id <22880-0@osi-west.es.net>; Mon, 14 Nov 1994 02:13:26 +0000 Received: from localhost by eccosys.com (4.1/SMI-4.1-EB-940511.1) id AA15976; Mon, 14 Nov 94 19:18:51 JST To: hans@sics.se, rem-conf@es.net Subject: Re: rolling stones In-Reply-To: Your message of "Mon, 14 Nov 1994 11:29:57 +0200." <9411140929.AA16445@sics.se> Date: Mon, 14 Nov 1994 19:18:48 +0900 Message-Id: <15971.784808328@eccosys.com> From: Cyrus Hi Hans: Let's move this discussion to rem-conf, since it is not related to the topic of the list "mbone@isi.edu". > > If you only send "the Stones", fine! > If you also send any promotion stuff (ads, whatever), NOT FINE. > Internet usually comes down hard on blatant advertisements. > What are your comments on this issue? As far as I know, the only video multicast will be the live feed from the concert. There will be no "commercials" like on broadcast TV. Mutlicast is a different game than broadcast. There is no need to create bland and annoying advertising to appeal/coerce the "masses". With the advent of multicasting, people can choose what they want to watch, and when they want to watch it (nv record). I am sorry to report, Hans, that the Internet is not a person who "come down hard" on anything. The Canter and Sigel mess happened because some people mistook a multicast medium for a broadcast medium, and crossposted the usenet to hell. There was much anger in the Internet community about that, I agree. There are advertisements, but they are on the WWW server called http://www.stones.com/ They will be advertising concert T-shirts and the Cable Pay-per-view event. This is Active advertising, though! If people seek this information, they will find it. Nothing is being shoved down anybody's throat. I think the Internet contains much of this type of advertising by now, and I also think that most users of the Internet find this type of Advertising useful, and not annoying. >From an economic viewpoint, the reason that the Stones and Sun and the other sponsors are giving away 20 mins of a premium concert for FREE to the Internet community, without commercials, is because they realize that this type of Active Advertising is much more powerful than the old Passive type. So in a nutshell, I believe that this multicast fits in well with the spirit of the MBONE, and the Internet community. Please keep responses to this list, or to me personally. Cyrus Cyrus@eccosys.com From rem-conf-request@es.net Mon Nov 14 05:25:30 1994 Received: from neoteny.eccosys.com by osi-west.es.net via ESnet SMTP service id <22944-0@osi-west.es.net>; Mon, 14 Nov 1994 02:24:43 +0000 Received: from localhost by eccosys.com (4.1/SMI-4.1-EB-940511.1) id AA17325; Mon, 14 Nov 94 19:30:35 JST To: rem-conf@es.net Subject: Stones Reruns Date: Mon, 14 Nov 1994 19:30:33 +0900 Message-Id: <17315.784809033@eccosys.com> From: Cyrus Question: I am wainting to hear if there are any conflicts with our current time of Rolling Stones Live multicast. In the meantime, would there be any possibility of using the following times for a rerun a tape of the multicast for those people who could not make the live version? Times: Monday Nov 21st at 12:00 noon GMT? Wednesday Nov 23rd at 12 midnight (0:00) GMT? Thank you, Cyrus cyrus@thinkpix.com cyrus@eccosys.com From rem-conf-request@es.net Mon Nov 14 05:32:24 1994 Received: from sics.se by osi-west.es.net via ESnet SMTP service id <23041-0@osi-west.es.net>; Mon, 14 Nov 1994 02:31:10 +0000 Received: from hans.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA20721; Mon, 14 Nov 94 11:30:33 +0100 Message-Id: <9411141030.AA20721@sics.se> X-Mime-Version: 1.0 X-Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Nov 1994 11:30:35 +0100 To: Cyrus , rem-conf@es.net From: hans@sics.se (Hans Eriksson) Subject: Re: rolling stones Cyrus, your first announcement gave the impression of more commercial stuff being sent using common resources (even if it is multicasted!). Your mail has finally clarified that it wil just be the Stone. Fine, I will enjoy it. /hans From rem-conf-request@es.net Mon Nov 14 05:36:09 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <23047-0@osi-west.es.net>; Mon, 14 Nov 1994 02:31:48 +0000 Received: from muridae.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 14 Nov 1994 10:30:30 +0000 To: hans@sics.se (Hans Eriksson) cc: Cyrus , mbone@ISI.EDU, rem-conf@es.net Subject: Re: rolling stones In-reply-to: Your message of "Mon, 14 Nov 94 11:29:57 +0200." <9411140929.AA16445@sics.se> Date: Mon, 14 Nov 94 10:30:02 +0000 From: Gordon Joly HE> If you only send "the Stones", fine! HE> If you also send any promotion stuff (ads, whatever), NOT FINE. HE> Internet usually comes down hard on blatant advertisements. HE> What are your comments on this issue? Me? My comments are in line with yours. Regards, Gordon Joly http://www.cs.ucl.ac.uk/people/gordo/ Tel +44171 3807934 Email G.Joly@cs.ucl.ac.uk Home: gordo@dircon.co.uk FAX +44171 3871397 Comp Sci, University College London, Gower Street, LONDON WC1E 6BT From rem-conf-request@es.net Mon Nov 14 05:40:17 1994 Received: from imicilea.cilea.it by osi-west.es.net via ESnet SMTP service id <23094-0@osi-west.es.net>; Mon, 14 Nov 1994 02:35:42 +0000 Received: from [131.175.1.95] by IMICILEA.CILEA.IT (IBM VM SMTP V2R2) with TCP; Mon, 14 Nov 94 11:30:41 MET X-Sender: calegari@imicilea Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 14 Nov 1994 12:35:29 +0200 To: rem-conf@es.net From: calegari@cilea.it (Antonio Calegari) Subject: MBone Agenda - update 14 November 94 The MBone Agenda November 94 Please see: http://www.cilea.it/MBone/agenda.html ------------------------------------------------------------------------ All times are given in GMT. ------------------------------------------------------------------------ 03-Nov 16:00 14-Nov 20:00 NASA Shuttle Broadcast - STS - 66 Contact: Alex Deacon - anaops@atlas.arc.nasa.gov NASA's STS-66 Broadcast. Launch time is estimated at 16:56 GMT. The mission is due to last 10 days 20 hours. ------------------------------------------------------------------------ 04-Nov 18:00 04-Nov 19:00 Mike Ruygrok operations Manager Contact: miker@lna.oz.au ------------------------------------------------------------------------ 11-Nov 22:00 12-Nov 01:00 Censorship at Carnegie Mellon Contact: Doug Luce, doug@telerama.lm.com A 1 hour live interview show will be followed by a rebroadcast of a student rally held on Wednesday ------------------------------------------------------------------------ 14-Nov 14:00 15-Nov 21:00 FOB meeting Contact: braden@isi.edu Informal meeting of a small group of network researchers ------------------------------------------------------------------------ 15-Nov 22:00 17-Nov 22:00 Supercomputing '94 Contact: Steve Elbert (elbert@ameslab.gov) The conference schedule is available at http://sc94.ameslab.gov/AP/glance.html (times are eastern). The Keynote Address and Plenary Sessions will be multicast. ------------------------------------------------------------------------ 18-Nov 03:00 18-Nov 06:00 BayLISA meeting: Jonny Goldman on gateways and proxies for H Contact: blw@baylisa.org or deleon@hpl.hp.com The broadcast will be from 7:30-10:00 PDT Nov 17, 1994 ------------------------------------------------------------------------ 23-Nov 02:00 23-Nov 04:00 El Naftazteca: Information Superhighway Bendito Contact: stewart@rpi.edu or djwap@rpi.edu 90-minute live television event with Guillermo Gomez-Pena 21:00-22:30 EST ------------------------------------------------------------------------ 23-Nov 02:00 23-Nov 04:00 El Naftazteca: Information Superhighway Bendito Contact: stewart@rpi.edu 90-minute live television event with Guillermo Gomez-Penao ------------------------------------------------------------------------ 27-Nov 08:00 27-Nov 15:00 Epic multimedia event Contact: richard@rmit.edu.au Television event ------------------------------------------------------------------------ ------------------------------------------------------------------------ calegari@imicilea.cilea.it ------------------------------------------------------------------------- Antonio Calegari CILEA - Segrate - Milan tel. : +39 (0)2 26995 257 Interuniversity Computing Centre email: calegari@icil64.cilea.it ITALY From rem-conf-request@es.net Mon Nov 14 08:13:28 1994 Received: from trystero.radio.com by osi-west.es.net via ESnet SMTP service id <23947-0@osi-west.es.net>; Mon, 14 Nov 1994 05:12:36 +0000 Received: (carl@localhost) by trystero.radio.com (8.6.9/940816.06ccg) id IAA25618 for rem-conf@es.net; Mon, 14 Nov 1994 08:17:02 -0500 From: Carl Malamud Message-Id: <199411141317.IAA25618@trystero.radio.com> Subject: Concerts on the MBONE To: rem-conf@es.net Date: Mon, 14 Nov 1994 08:17:01 -0500 (EST) Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1555 With the recent flurry of "first concert on the Internet" publicity surrounding the Rolling Stones, I thought it might be instructive to give credit where it is due ... Xerox Parc and the fabulous "Severe Tire Damage" had the first live concert on the MBONE on June 24, 1993. Carl > From: weiser:PARC:Xerox > Date: Thu, 24 Jun 93 17:39:56 PDT > Subject: first live music video/audio multicast over the internet > > > So a fun, historic, thing happened at PARC today that Mark Manasse of DEC and I > thought you might find fun. > > Mark, Steve Rubin of ATG at Apple, and I play in a rock and roll band called > "Severe Tire Damage". Today we were playing a gig on the patios at PARC to > celebrate the 10th anniversary of the Xerox fitness center. (Also sitting in > were Anna Karlin, also of DEC, and Daniel Scharstein, a summer intern visiting > PARC from Cornell). > > At the same time, Van Jacobson of LBL was arranging to give a talk at PARC > later that afternoon on the use of the internet for lightweight audio and video > multicast. In order to illustrate his point, his talk was set up to multicast > in real time his slides, his voice, and his video to over 400 other networks > (with tens of thousands of people) on the internet. > > While Severe Tire Damage was playing, someone turned a PARC camera on us. They > plugged this camera and microphone in network connection that had been set up > for Jacobson. And the result was the first live music multicast over the > National Information Infrastructure! > > -mark weiser > From rem-conf-request@es.net Mon Nov 14 09:54:40 1994 Received: from lhc.nlm.nih.gov by osi-west.es.net via ESnet SMTP service id <24492-0@osi-west.es.net>; Mon, 14 Nov 1994 06:53:58 +0000 Received: from billings.csb (billings.nlm.nih.gov) by nlm.nih.gov (4.1/SMI-4.0) id AA17458; Mon, 14 Nov 94 09:53:53 EST Received: by billings.csb (5.0/SMI-SVR4) id AA05890; Mon, 14 Nov 1994 09:55:08 +0500 Date: Mon, 14 Nov 1994 09:55:08 +0500 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <9411141455.AA05890@billings.csb> To: rem-conf@es.net, cyrus@thinkpix.com Subject: Stones on the MBONE X-Sun-Charset: US-ASCII Content-Length: 1073 > The Rolling Stones will be multicasting 20 minutes of their Dallas > Cotton Bowl concert live over the MBONE on Friday, November 18th as > promotion for their Pay-Per-View offer North American cable television > on November 25th. We asked the Stones for 20-30 minutes of their > concert so that the multicast would not severely affect national and > international bandwidth. The multicast will occur at off peak hours > and will be repeated regularly for 48 hours if permitted. The > multicast will begin around 8:00pm USA central time. For details on: If you are concerned about bandwidth, why reply it continuously for 48 hours? I suspect that the real explanation is "The Stones don't want to risk losing revenue by multicasting their entire concert, but they are happy to take advantage of a free form of advertising." Thus what might have been an amusing if rather inconsequential "first" (major rock concert on the MBONE) becomes merely a shabby means of commercially exploiting the MBONE. I don't think that this use of the MBONE is appropriate. Rick Rodgers From rem-conf-request@es.net Mon Nov 14 11:12:41 1994 Received: from 204.95.114.3 by osi-east.es.net via ESnet SMTP service id <21698-0@osi-east.es.net>; Mon, 14 Nov 1994 08:12:19 +0000 Received: by mmf.andersen.com (5.0/Andersen Consulting) id AA08873; Mon, 14 Nov 1994 10:02:10 +0600 Date: Mon, 14 Nov 1994 10:02:10 +0600 From: koduriv@mmf.andersen.com (Vijay L. Koduri) Message-Id: <9411141602.AA08873@mmf.andersen.com> To: rem-conf@es.net Subject: IP multicast on Solaris 2.3 X-Sun-Charset: US-ASCII content-length: 546 I have several Sparc10s installed with Solaris 2.3. As you all know, Solaris comes preinstalled with IP multicasting. However, the version is an older one, and I would like to update it with the current changes (v 3.3). Is it possible to update the files, given that I can only obtain a version for SunOS4.1.3 and not Solaris? If it is, can someone let me know which files to change, what changes to be made to cater to Solaris, etc.? I would *REALLY* appreciate any and all info. Thanks in advance, Vijay Koduri koduriv@mmf.andersen.com From rem-conf-request@es.net Mon Nov 14 11:44:29 1994 Received: from cmgm.Stanford.EDU by osi-east.es.net via ESnet SMTP service id <22644-0@osi-east.es.net>; Mon, 14 Nov 1994 08:44:07 +0000 Received: (mcroot@localhost) by cmgm.stanford.edu (8.6.8/8.6.4) id IAA01545; Mon, 14 Nov 1994 08:42:46 -0800 Date: Mon, 14 Nov 1994 08:42:45 -0800 (PST) From: "Michael Croot (brutlag)" To: Dory Ethan Leifer cc: rem-conf@es.net Subject: Re: Audio Echo Cancellation In-Reply-To: <199411120008.TAA07956@terminator.rs.itd.umich.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 11 Nov 1994, Dory Ethan Leifer wrote: > > Does anyone know of software which may run on a general purpose computer > that would do a fairly good job at echo cancellation for audio conferencing > applications? Possibly a PC program on a soundblaster card? > > Thank You, > Dory LeifeRr > University of Michigan > Dory Is it really necessary to have echo cancellation in your application? Perfectly adequate conference quality can be achieved with other feedback-control mechanisms, like voice-switching (or 'ducking' from the on-air trade) which lowers the level of one signal in response to a higher level signal in the opposite direction. Voice-switching algorithms are much less compute-intensive. Michael From rem-conf-request@es.net Mon Nov 14 12:17:55 1994 Received: from yama.bus.utexas.edu by osi-west.es.net via ESnet SMTP service id <09781-0@osi-west.es.net>; Tue, 8 Nov 1994 16:43:18 +0000 Received: by yama.bus.utexas.edu (1.38.193.4/16.2) id AA11527; Tue, 8 Nov 1994 18:44:42 -0600 From: Ram Chellappa Subject: MBONE Broadcast of "Issues in Pricing/Services on the Internet" To: rem-conf@es.net Date: Tue, 8 Nov 94 18:44:41 CST Reply-To: ram@cism.bus.utexas.edu X-Hpvue$Revision: 1.8 $ Mime-Version: 1.0 Content-Type: Message/rfc822 X-Vue-Mime-Level: 4 Mailer: Elm [revision: 70.85] CENTER FOR INFORMATION SYSTEMS MANAGEMENT Graduate School of Business University of Texas, Austin MBONE BROADCAST DATE & TIME: Nov 9 (WEDNESDAY) 4:45 - 6:00 pm (CST) Proposed experimental broadcast of a discussion on the future of Internet with Smoot Carl-Mitchell, Zilker Internet Park, Austin, TX John Quartermann, Zilker Internet Park, Austin, TX Dr. Andrew Whinston, Prof. of Information Systems, Univ. of Texas, Austin. ------------------------------------------------------------------------- Issues that will be discussed include: The future of the Internet (Commercial providers point of view) Issues in Pricing on Internet (Dr. Andrew B. Whinston) If wish to be familiar with the area of pricing on Internet please look at our home page http://cism.bus.utexas.edu/ under Proceedings of making money on Internet ! The idea of this broadcast is to encourage discussion on these issues over the Internet itself and to address issues such as Commercialization of the Internet . Particpation is greatly encouraged through audio and whiteboard mediums. ------------------------------------------------------------------------- If you have any questions pl. send mail to ram@cism.bus.utexas.edu Ram. -- RAMNATH K CHELLAPPA Ph: 512-467-7813 (home) Assistant Instructor, (C/S Architecture) 512-471-7962 (office) Information Systems Department of MSIS University of Texas, Austin. ramnath@uts.cc.utexas.edu (OSF1) RAMNATH@UTXVMS.CC.UTEXAS.EDU (VAX) email: ram@ccwf.cc.utexas.edu ramc@bongo.cc.utexas.edu (Ultrix) CAUGHT SPEEDING ON THE INFOBAHN :-) From rem-conf-request@es.net Mon Nov 14 12:17:58 1994 Received: from lanshark.hstf.interop.net by osi-west.es.net via ESnet SMTP service id <12702-0@osi-west.es.net>; Wed, 9 Nov 1994 00:44:36 +0000 Received: (from ericd@localhost) by lanshark.hstf.interop.net (8.6.9/8.6.9) id AAA10043; Wed, 9 Nov 1994 00:50:55 -0800 Date: Wed, 9 Nov 1994 00:50:54 -0800 (PST) From: Eric Davis To: rem-conf@es.net Subject: Urgent Parallax Help Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am running nv 3.3b and am getting massive screen flashed, actually blackouts on the order of 3-4 a second on a video screen sent across the net captured from a Parallax Xvideo card. The Parallax utility to view the input does not show this flashing. Is there a know bug here? Machine SS10/51, 128Mb, Parallax Xvideo. Thanks Eric Davis From rem-conf-request@es.net Mon Nov 14 12:18:00 1994 Received: from lanshark.hstf.interop.net by osi-west.es.net via ESnet SMTP service id <11444-0@osi-west.es.net>; Tue, 8 Nov 1994 21:15:21 +0000 Received: (from ericd@localhost) by lanshark.hstf.interop.net (8.6.9/8.6.9) id VAA09645; Tue, 8 Nov 1994 21:21:38 -0800 Date: Tue, 8 Nov 1994 21:21:38 -0800 (PST) From: Eric Davis To: rem-conf@es.net Subject: Re: Sky Cries Mary In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII OOPS.. That is 7:00PM PST (19:00 PST) Sorry Eric On Tue, 8 Nov 1994, Eric Davis wrote: > > The band Sky Cries Mary will be placed on the MBONE this Thursday from > 7:00-8:00 PST. > > Sorry for the short notice, welcome to the world of Rock and Roll. > > The session should be vat (pcm2) and nv (undecided). > > Thanks > Eric Davis > ericd@interop.net > From rem-conf-request@es.net Mon Nov 14 12:18:52 1994 Received: from lanshark.hstf.interop.net by osi-west.es.net via ESnet SMTP service id <11139-0@osi-west.es.net>; Tue, 8 Nov 1994 19:54:42 +0000 Received: (from ericd@localhost) by lanshark.hstf.interop.net (8.6.9/8.6.9) id UAA09535; Tue, 8 Nov 1994 20:01:01 -0800 Date: Tue, 8 Nov 1994 20:01:01 -0800 (PST) From: Eric Davis To: rem-conf@es.net Subject: Sky Cries Mary Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The band Sky Cries Mary will be placed on the MBONE this Thursday from 7:00-8:00 PST. Sorry for the short notice, welcome to the world of Rock and Roll. The session should be vat (pcm2) and nv (undecided). Thanks Eric Davis ericd@interop.net From rem-conf-request@es.net Mon Nov 14 12:57:12 1994 Received: from xanthus.usc.edu by osi-west.es.net via ESnet SMTP service id <01947-0@osi-west.es.net>; Mon, 14 Nov 1994 09:56:01 +0000 Received: by xanthus.usc.edu (4.1/SMI-4.1+ucs-3.6) id AA16515; Mon, 14 Nov 94 09:57:53 PST From: suhler@acal.usc.edu (Paul A. Suhler) Message-Id: <9411141757.AA16515@xanthus.usc.edu> Subject: Re: Audio Echo Cancellation To: rem-conf@es.net Date: Mon, 14 Nov 94 9:57:52 PST In-Reply-To: ; from "Michael Croot" at Nov 14, 94 8:42 am X-Mailer: ELM [version 2.3 PL5] Michael Croot wrote: Is it really necessary to have echo cancellation in your application? Perfectly adequate conference quality can be achieved with other feedback-control mechanisms, like voice-switching (or 'ducking' from the on-air trade) which lowers the level of one signal in response to a higher level signal in the opposite direction. Voice-switching algorithms are much less compute-intensive. I don't know whether you're thinking specifically of VAT and its mike-mutes-net and net-mutes-mike options, but I've found that those lead to so much interference (especially with lots of people on either end) that it was better to kill vat and use a speakerphone. Take that as an argument for echo cancellation, even though it may be expensive to do. Has anyone else had similar experiences? Should I have configured things differently? Paul From rem-conf-request@es.net Mon Nov 14 14:07:42 1994 Received: from ietf.cnri.reston.va.us by osi-west.es.net via ESnet SMTP service id <02517-0@osi-west.es.net>; Mon, 14 Nov 1994 11:06:13 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa05091; 14 Nov 94 11:50 EST 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-cellb-profile-01.txt Date: Mon, 14 Nov 94 11:50:11 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9411141150.aa05091@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 Encapsulation of CellB Video Encoding Author(s) : M. Speer, D. Hoffman Filename : draft-ietf-avt-cellb-profile-01.txt Pages : 24 Date : 11/10/1994 This note describes a packetization scheme for the CellB video encoding using RTP. This document is meant for implementors of video applications that use RTP and CellB. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-cellb-profile-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-cellb-profile-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-cellb-profile-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19941110161406.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-cellb-profile-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-cellb-profile-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941110161406.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Mon Nov 14 15:36:45 1994 Received: from herman.cmf.nrl.navy.mil by osi-east.es.net via ESnet SMTP service id <28602-0@osi-east.es.net>; Mon, 14 Nov 1994 12:36:14 +0000 Received: (from fenner@localhost) by herman.cmf.nrl.navy.mil (8.6.8.1/8.6.6) id PAA19867; Mon, 14 Nov 1994 15:34:55 -0500 Date: Mon, 14 Nov 1994 15:34:55 -0500 From: "William C. Fenner" Message-Id: <199411142034.PAA19867@herman.cmf.nrl.navy.mil> To: rem-conf@es.net, suhler@xanthus.usc.edu Subject: Re: wb displayed on Macintosh PowerBook? Have you tried this X resource? (from the CHANGES file) - Added 'wb.CompactLayout' X resource to force a more compact screen layout (color palatte turned into menu). ... Result of this, font & brush change it that it's possible to shrink a wb down to ~1/4 screen size & still use it. (changes suggested by Atanu Ghosh & Mark Handley of UCL) Bill From rem-conf-request@es.net Mon Nov 14 17:16:12 1994 Received: from swan.cl.cam.ac.uk by osi-west.es.net via ESnet SMTP service id <02276-0@osi-west.es.net>; Mon, 14 Nov 1994 14:14:07 +0000 Received: from swan.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Mon, 14 Nov 1994 22:13:14 +0000 To: rem-conf@es.net, mbone@ISI.EDU Cc: Piete.Brooks@cl.cam.ac.uk Reply-To: Piete.Brooks@cl.cam.ac.uk Subject: JIPS Mbone transmission 94/11/15 16:15-17:15UTC (cl.cam.ac.uk Security) Date: Mon, 14 Nov 1994 22:06:20 +0000 From: Piete Brooks Message-ID: <"swan.cl.cam.:111300:941114220633"@cl.cam.ac.uk> We shall not be transmitting this week's departmental seminar (at the speaker's request), but we hope to be transmitting the Security Group's seminar. It still needs to be set up (using a workstation in a nearby office), there is currently no copy of the slides, and the expected audience is UK sites interested in Security, so the TTL is being set low. It's meant as a "low key" transmission (without anyone manning the camera, etc) but if anyone outside JIPS wants the TTL raised, please let me know. Piers McMahon, ICL, X/Open Cryptographic Service Model With increased requirements for cryptographic security, there is a growing number of products on the market which provide such services as encryption, digital signature, and key exchange. While it is possible to write applications which use these products, there are no vendor-neutral standards, so any applications which use cryptographic services need to bind to proprietary APIs. This talk will give an overview of the work of the X/Open Security Working Group in defining a generic cryptographic service API to meet the requirements for application interfaces to cryptographic and key management services. It will show how the X/Open work is building from existing key management models and from extensive implementation experience; and that the agreed service model will be comprehensive, practical, applicable to both software and hardware, algorithm independent, and take account of compliance with export control laws, and controls on cryptographic usage. This seminar will be multicast (audio and video) on the mbone as part of our multimedia test programme. Further information is available at http://www.cl.cam.ac.uk/mbone/#cl. From rem-conf-request@es.net Mon Nov 14 18:55:32 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <02944-0@osi-west.es.net>; Mon, 14 Nov 1994 15:53:59 +0000 Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 14 Nov 1994 23:53:14 +0000 To: Carl Malamud cc: rem-conf@es.net Subject: Re: Concerts on the MBONE In-reply-to: Your message of "Mon, 14 Nov 94 08:17:01 EST." <199411141317.IAA25618@trystero.radio.com> Date: Mon, 14 Nov 94 23:53:05 +0000 From: Gordon Joly First concert? More like first "blatant advertising dressed up as Stones freebie event" ? Gordo (tm) who was in Hyde Park in 1969. Gordon Joly http://www.cs.ucl.ac.uk/people/gordo/ Tel +44171 3807934 Email G.Joly@cs.ucl.ac.uk Home: gordo@dircon.co.uk FAX +44171 3871397 Comp Sci, University College London, Gower Street, LONDON WC1E 6BT From rem-conf-request@es.net Mon Nov 14 20:49:20 1994 Received: from rpi.edu by osi-east.es.net via ESnet SMTP service id <03814-0@osi-east.es.net>; Mon, 14 Nov 1994 17:48:42 +0000 Received: from hibp.ecse.rpi.edu (hibp7.ecse.rpi.edu) by rpi.edu (4.1/SMHUB41); id AA03403; Mon, 14 Nov 94 20:46:31 EST for rem-conf@es.net Received: from hibp6.ecse.rpi.edu by hibp.ecse.rpi.edu (4.1/ST26); id AA03857 for calegari@cilea.it; Mon, 14 Nov 94 20:46:30 EST Message-Id: <9411150146.AA03857@hibp.ecse.rpi.edu> To: rem-conf@es.net Cc: jed@llnl.gov, schulzrinne@fokus.gmd.de, rodgers@nlm.nih.gov, calegari@cilea.it Subject: TimeZone converter X-Mailer: exmh version 1.4zeta 6/3/94 Date: Mon, 14 Nov 1994 20:46:23 -0500 From: Paul Stewart I'd thank everyone who has graciously offered input reguarding my little timezone converter. The following has been added: * A special mode that adds the target/source timezone in the URL so that one can have the converter in one's hotlist, and not have to set the source/target timezone every time. * An automatic source code dump. * HELP! It's currently up and running on http://hibp.ecse.rpi.edu/cgi-bin/tzconvert . Help and technical information is available from the anchor at the top of the document. The HTML code of the help appears syntactically correct, but I can't guarantee perfect spelling/grammar until I've had some sleep.. As usual, comments and questions will be gladly fielded by me, and time permitting, I'll be perfectly willing to address any feature/bug/documentation queries. -- Paul From rem-conf-request@es.net Mon Nov 14 22:03:46 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <01633-0@osi-west.es.net>; Mon, 14 Nov 1994 19:03:06 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Mon, 14 Nov 1994 19:03:00 -0800 Posted-Date: Mon 14 Nov 94 19:01:50 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Mon, 14 Nov 94 19:01:51 PST Date: Mon 14 Nov 94 19:01:50 PST From: Stephen Casner Subject: Re: IP multicast on Solaris 2.3 To: koduriv@mmf.andersen.com, rem-conf@es.net Message-Id: <784868510.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9411141602.AA08873@mmf.andersen.com> Mail-System-Version: Version 3.3 mrouted cannot be used with Solaris 2.3 because 3.3 requires changes in the kernel code as well as the daemon. I've heard that a future release of Solaris will have the changes to support the pruning version of mrouted (3.3 and new versions to come). All you can do is wait, and meanwhile use mrouted 2.2 (or 2.0). -- Steve ------- From rem-conf-request@es.net Tue Nov 15 05:25:10 1994 Received: from cs.tut.fi by osi-west.es.net via ESnet SMTP service id <04912-0@osi-west.es.net>; Tue, 15 Nov 1994 02:24:39 +0000 Received: from isosotka.cs.tut.fi (mit@isosotka.cs.tut.fi [130.230.17.14]) by cs.tut.fi (8.6.9/8.6.4) with ESMTP id MAA10665; Tue, 15 Nov 1994 12:27:08 +0200 From: Tsokkinen Mikko Received: (mit@localhost) by isosotka.cs.tut.fi (8.6.8/8.6.4) id MAA15351; Tue, 15 Nov 1994 12:27:00 +0200 Date: Tue, 15 Nov 1994 12:27:00 +0200 Message-Id: <199411151027.MAA15351@isosotka.cs.tut.fi> To: koduriv@mmf.andersen.com (Vijay L. Koduri) Cc: rem-conf@es.net Subject: IP multicast on Solaris 2.3 In-Reply-To: <9411141602.AA08873@mmf.andersen.com> References: <9411141602.AA08873@mmf.andersen.com> Vijay L. Koduri writes: > I have several Sparc10s installed with Solaris 2.3. As you all know, > Solaris comes preinstalled with IP multicasting. However, the version is an > older one, and I would like to update it with the current changes (v 3.3). > > Is it possible to update the files, given that I can only obtain a version > for SunOS4.1.3 and not Solaris? If it is, can someone let me know which files > to change, what changes to be made to cater to Solaris, etc.? > > I would *REALLY* appreciate any and all info. Patches are not available (at least not to my knowledge). Most people will upgrade their Solaris to 2.4 soon, so I doubt there will ever be 3.3 patches for Solaris2.3. In Solaris2.4 multicast did not work for me at all, but this was long time ago with prerelease. If you want a good mrouter machine use sunos413, and mrouted3.3. Requires kernel hacking, but once you have made done it, it will work reliably. Mikko Tsokkinen Tampere University of Technology Research Assistant - Project FASTER Distributed Multimedia Applications over ATM-Network From rem-conf-request@es.net Tue Nov 15 07:33:47 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <06264-0@osi-west.es.net>; Tue, 15 Nov 1994 04:33:21 +0000 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Nov 1994 12:32:52 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: suhler@acal.usc.edu (Paul A. Suhler) cc: rem-conf@es.net Subject: Re: Audio Echo Cancellation In-reply-to: Your message of "Mon, 14 Nov 94 09:57:52 PST." <9411141757.AA16515@xanthus.usc.edu> Date: Tue, 15 Nov 94 12:31:59 +0000 Message-ID: <3985.784902719@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >I don't know whether you're thinking specifically of VAT and its >mike-mutes-net and net-mutes-mike options, but I've found that those >lead to so much interference (especially with lots of people on either >end) that it was better to kill vat and use a speakerphone. Take that >as an argument for echo cancellation, even though it may be expensive >to do. > >Has anyone else had similar experiences? Should I have configured >things differently? If the silence supression plays ball, then net-mutes-mike is quite usable between linked up auditoriums. We used it quite successfully for the medical link up with UCSF that we did last week. However, this depends on not having a noisy environment and having decent mikes. I don't think I'd want to do the same thing in a *large* multi-way conference. I've had some pretty bad experiences with speakerphones too. Most of them don't do real echo cancellation either. Mark From rem-conf-request@es.net Tue Nov 15 08:43:11 1994 Received: from burdell.cc.gatech.edu by osi-west.es.net via ESnet SMTP service id <06538-0@osi-west.es.net>; Tue, 15 Nov 1994 05:42:19 +0000 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.6.9/8.6.9) with ESMTP id IAA22607 for ; Tue, 15 Nov 1994 08:42:16 -0500 Received: (from kevin@localhost) by flora.cc.gatech.edu (8.6.9/8.6.9) id IAA02012 for rem-conf@es.net; Tue, 15 Nov 1994 08:42:12 -0500 Date: Tue, 15 Nov 1994 08:42:12 -0500 From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199411151342.IAA02012@flora.cc.gatech.edu> To: rem-conf@es.net Subject: Re: Concerts on the MBONE >>First concert? More like first "blatant advertising dressed up as >>Stones freebie event" ? My concern is the fragility of the MBONE. In my opinion, even in the last couple of months, the use of the MBONE has increased dramatically. I don't believe the conference scheduling mechanisms have been sufficiently developed or even designed. With this latest round of publicity, the increase in demand on the MBONE will continue to grow exponentially. Of course, if the community as a whole believes the MBONE is ready for use by the general Internet community, then by all means. On the other hand, even if "we" decide this concert shouldn't happen, who is going to pull the plug? And can the plug necessarily be pulled? It has already been pointed out that there is no central authority. And finally, on the subject of advertising. You better believe the Stones are going to bill themselves as the first band to broadcast on the Information Superhighway (sic). I can just see the ads, and the promotional material proclaiming the NII has arrived. -Kevin Almeroth Georgia Tech From rem-conf-request@es.net Tue Nov 15 09:40:05 1994 Received: from bgate.lut.ac.uk by osi-west.es.net via ESnet SMTP service id <06832-0@osi-west.es.net>; Tue, 15 Nov 1994 06:39:00 +0000 Received: by suna.lut.ac.uk (4.1/SMI-4.1) id AA09169; Tue, 15 Nov 94 14:38:14 GMT Date: Tue, 15 Nov 1994 14:32:19 +0000 (GMT) From: "Jon P. Knight" Subject: Re: Concerts on the MBONE To: "Kevin C. Almeroth" Cc: rem-conf@es.net In-Reply-To: <199411151342.IAA02012@flora.cc.gatech.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 15 Nov 1994, Kevin C. Almeroth wrote: > And finally, on the subject of advertising. You better believe the Stones > are going to bill themselves as the first band to broadcast on the Information > Superhighway (sic). I can just see the ads, and the promotional material > proclaiming the NII has arrived. Its already happened; the Stones multicast was mentioned in the news slot on the ``Big Breakfast'' TV show* yesterday morning in the UK. I'm just waiting for the screaming hoards from Demon, BBCNC, AOL, et al to start asking how they can get the video and audio multicast over their 14.4K dial up connection. A bit of publicity is handy in getting kit to do multicast experimentation on but there's always the danger of overhyping a technology that isn't yet ready for the limelight. Checkout AI and robotics for examples... Jon * The ``Big Breakfast'' news team seem particularly interested in the Internet for some reason; this morning there was a news item about Danish academics claiming that they were in the crawler lane of the European information highway. :-) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Knight, Research Student in High Performance Networking and Distributed Systems in the Department of _Computer_Studies_ at Loughborough University. * It's not how big your share is, its how much you share that's important * From rem-conf-request@es.net Tue Nov 15 11:37:51 1994 Received: from SKIGO.GRAPHICS.CORNELL.EDU by osi-west.es.net via ESnet SMTP service id <07955-0@osi-west.es.net>; Tue, 15 Nov 1994 08:37:25 +0000 Received: by skigo.graphics.cornell.edu (5.65/DEC-Ultrix/4.3) id AA23011; Tue, 15 Nov 1994 11:37:32 -0500 Message-Id: <9411151637.AA23011@skigo.graphics.cornell.edu> To: rem-conf@es.net Subject: Re: rolling stones In-Reply-To: Your message of "Mon, 14 Nov 94 10:49:25 +0900." <16493.784777765@eccosys.com> X-Mailer: exmh version 1.5omega 10/6/94 Date: Tue, 15 Nov 94 11:37:32 -0500 From: Mitch Collinsworth X-Mts: smtp Heard last night on NPR in an advert for The Capitol Steps (a political satire group). One of the items in their repertoire was titled: "The aging Rolling Stones singing 'Hey, You, Get offa my Lawn!'" -Mitch From rem-conf-request@es.net Tue Nov 15 13:06:36 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <08783-0@osi-west.es.net>; Tue, 15 Nov 1994 10:06:11 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 15 Nov 1994 18:05:37 +0000 To: Mitch Collinsworth cc: rem-conf@es.net Subject: fade away (not...) Date: Tue, 15 Nov 94 18:05:36 +0000 Message-ID: <3594.784922736@cs.ucl.ac.uk> From: Jon Crowcroft my nv's as big as a cadillac try to tell you but mrouted turns me back my net for you has gotta be real mbone's virtual, gonna fade away mbone's really gonna fade away jon From rem-conf-request@es.net Tue Nov 15 14:18:26 1994 Received: from std.sri.com by osi-west.es.net via ESnet SMTP service id <09525-0@osi-west.es.net>; Tue, 15 Nov 1994 11:18:03 +0000 Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1) id AA04448; Tue, 15 Nov 94 11:07:55 PST Message-Id: <9411151907.AA04448@std.sri.com> To: keck@castor.trl.oz.au, schulzrinne@fokus.gmd.de Cc: rem-conf@es.net, confctrl@isi.edu, tfrivold@std.sri.com, rlang@std.sri.com Subject: Re: Session Control Protocol Survey for MMUSIC IETF 12/94 Date: Tue, 15 Nov 1994 11:07:50 -0800 From: Ruth Lang Brian and Henning, The permission problem on ftp://ws11.std.sri.com/pub/confctrl/glossary.txt has been fixed. Thanks for bringing it to my attention. Regards, Ruth Lang From rem-conf-request@es.net Tue Nov 15 17:42:11 1994 Received: from Sun.COM by osi-west.es.net via ESnet SMTP service id <15012-0@osi-west.es.net>; Tue, 15 Nov 1994 14:41:47 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA19405; Tue, 15 Nov 94 14:41:31 PST Received: from amber.eng.sun.com by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16568; Tue, 15 Nov 94 14:41:53 PST Received: by amber.eng.sun.com (5.0/SMI-SVR4) id AA17553; Tue, 15 Nov 1994 14:39:30 +0800 Date: Tue, 15 Nov 1994 14:39:30 +0800 From: Don.Hoffman@Eng.Sun.COM (Don Hoffman) Message-Id: <9411152239.AA17553@amber.eng.sun.com> To: rem-conf@es.net Subject: Sunergy #11 (November 16, 1994 - 8:30 am - 10:00 am PST) X-Sun-Charset: US-ASCII Content-Length: 2779 Announcing Sunergy #11 - Live Broadcast Topic: Reengineering the Enterprise November 16, 1994 8:30 am - 10:00 am PST See the sd session, "Sunergy #11" for addressing information. Standard vat/nv formats will be used. Questions or concerns to hoffman@eng.sun.com Thanks, Don Hoffman email - don.hoffman@eng.sun.com, phone - +415 786 6370, fax - +415 786 6445 --------------------------------------------------------------------------- Announcing Sunergy #11 - Live Interactive Satellite Broadcast Topic: Reengineering the Enterprise November 16, 1994 8:30 am - 10:00 am PST We invite you to attend our live Sunergy broadcast, "Reengineering the Enterprise." Hosted by John Gage, it will feature an array of industry experts who have reengineered their companies' information architecture or charted the course of others in that process. Our previous broadcast brought Steve Jobs, Bud Tribble, and Bill Joy together to discuss the future of objects. This Sunergy follows that theme to find out what large manufacturing companies are doing with distributed applications. The show will demonstrate that the technology that enables companies to be more flexible, distribute information effectively, and bring products to market faster is no longer a futuristic dream. It is available and being used now. Featured Guests: Michael Hammer, author of *Reengineering the Corporation*, will provide an overview of the restructuring problems facing modern enterprises. Hammer is a former MIT professor of computer science who consults with corporations on how to use information technology effectively. Bill Raduchel, CIO of Sun Microsystems, will discuss the lessons Sun has learned in migrating to UNIX as its primary commercial systems platform and running the business using its own open architecture. Ray Lane, President of WorldWide Operations at Oracle Corporation, will discuss how major global manufacturers are using unix client- server technology to reengineer the ways they operate. Dennis Courtney, Chief Information Officer of Dunlop Tire Company, will describe how Dunlop is using new financial and manufacturing solutions in a client-server environment to enable reengineeering the way they do business. George Thompson, Director of Information Systems for worldwide supply chain management at Johnson & Johnson, will discuss the status of J&J's move to client-server computing. If you are interested in downlinking the broadcast with your own dish, please send e-mail to sunergy@sun.com requesting the satellite coordinates. Or phone 1 415/336-5847 or FAX 1 415 969-9131. Currently, coordinates are available for the United States, Canada, Mexico, Latin America, Europe, and Russia (as far east as Moscow). From rem-conf-request@es.net Tue Nov 15 20:30:59 1994 Received: from c3serve.c3.lanl.gov by osi-west.es.net via ESnet SMTP service id <16295-0@osi-west.es.net>; Tue, 15 Nov 1994 17:30:17 +0000 Received: from c3serve.c3.lanl.gov (vetch.c3.lanl.gov [128.165.20.9]) by c3serve.c3.lanl.gov (8.6.8/93112601) with ESMTP id SAA27205 for ; Tue, 15 Nov 1994 18:30:11 -0700 Message-Id: <199411160130.SAA27205@c3serve.c3.lanl.gov> To: rem-conf@es.net Subject: recording (nv_record, vat_record) and non-X11, non-GUI tools Date: Tue, 15 Nov 1994 18:30:06 -0700 From: Dale Carstensen I'd like to time-shift MBONE events, or record them via a cron entry perhaps, and typically I have only a modem connection when I want to find the info that sd can give me about multicast IP addresses, port numbers and session ID's. Aren't there some bare bones command-level tools to find out what sessions are available through simple ASCII output? Maybe they could even generate the nv_record and vat_record commands? Something like a -t option for sd to make it text-only? (I'm also having trouble getting the {nv,vat}_{play,record} programs to work, but I've taken that up with Anders Klemets directly.) Thanks. Mr Dale Carstensen Group CIC-3, MS B265 (505)667-0849 Los Alamos National Lab FAX (505)665-5220 Los Alamos, NM 87545 dlc@lanl.gov From rem-conf-request@es.net Wed Nov 16 08:33:51 1994 Received: from duke.cs.duke.edu by osi-west.es.net via ESnet SMTP service id <19674-0@osi-west.es.net>; Wed, 16 Nov 1994 05:33:26 +0000 Received: from macbeth.cs.duke.edu by duke.cs.duke.edu (5.65/3.10G/4.1.3) id AA00382; Wed, 16 Nov 94 08:30:34 -0500 Received: from localhost by macbeth.cs.duke.edu (5.65/3.10L/4.1.3) id AA12033; Wed, 16 Nov 94 08:33:20 -0500 Message-Id: <9411161333.AA12033@macbeth.cs.duke.edu> To: Dale Carstensen Cc: rem-conf@es.net Subject: Re: recording (nv_record, vat_record) and non-X11, non-GUI tools In-Reply-To: Your message of "Tue, 15 Nov 1994 18:30:06 MST." <199411160130.SAA27205@c3serve.c3.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <12030.784992799.1@macbeth.cs.duke.edu> Date: Wed, 16 Nov 1994 08:33:19 -0500 From: Thomas Pusateri In message <199411160130.SAA27205@c3serve.c3.lanl.gov> you write: >I'd like to time-shift MBONE events, or record them via a cron entry >perhaps, and typically I have only a modem connection when I want to >find the info that sd can give me about multicast IP addresses, port >numbers and session ID's. > >Aren't there some bare bones command-level tools to find out what >sessions are available through simple ASCII output? Maybe they could >even generate the nv_record and vat_record commands? Something like >a -t option for sd to make it text-only? > Try my sd-listen tool. Its available from Tom From rem-conf-request@es.net Wed Nov 16 09:18:04 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <19887-0@osi-west.es.net>; Wed, 16 Nov 1994 06:17:39 +0000 Received: from howser.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 16 Nov 1994 14:17:24 +0000 From: Piers O'Hanlon Organisation: University College London, AV Dept. Phone: +44 171 636 8333 ext 3056 (Hang on in there...) To: rem-conf@es.net cc: P.OHanlon@cs.ucl.ac.uk Subject: Yet more ads for the rolling stones X-Mailer: exmh version 1.5omega 10/6/94 Date: Wed, 16 Nov 94 14:17:20 +0000 Sender: P.OHanlon@cs.ucl.ac.uk Just to see how far this news is getting: STONES ROLLING ONLINE The Rolling Stones will step onto the Net Friday night, cybercasting the first five songs from their show at Dallas' Cotton Bowl stadium. The show is expected to start at 10:30 p.m. and the URL is: http://www.stones.com. (St. Petersburg 11/15/94 D1) *************************************************************************** EDUPAGE is what you've just finished reading. To subscribe to Edupage: send a message to: listproc@educom.edu and in the BODY of the message type: subscribe edupage Mick Jagger (assuming that your name is Mick Jagger; if it isn't, substitute your own name) ... To cancel subscription to Edupage: send a message to: listproc@educom.edu and in the BODY of the message type: unsubscribe edupage. [Edupage is also available in Portuguese and Spanish; to subscribe, send mail to edunews@nc-rj.rnp.br.] This 'cybercasting' sounds like fun. (Maybe it's local to St. Petersburg?!). Piers O'Hanlon ______________ Audio Visual Centre University College London. From rem-conf-request@es.net Wed Nov 16 11:26:20 1994 Received: from b.psc.edu by osi-west.es.net via ESnet SMTP service id <20677-0@osi-west.es.net>; Wed, 16 Nov 1994 08:25:50 +0000 Date: Wed, 16 Nov 1994 11:25:48 -0500 (EST) From: CUNNINGHAM@B.PSC.EDU To: rem-conf@es.net, P.OHanlon@cs.ucl.ac.uk Message-Id: <941116112548.20409e2d@B.PSC.EDU> Subject: Re: Yet more ads for the rolling stones > (Maybe it's local to St. Petersburg?!). Unfortunately not. I have this reoccuring nightmare that my home phone is going to ring some morning because some stone-head somewhere can see Mick protruding his tongue at the world. From rem-conf-request@es.net Wed Nov 16 18:37:57 1994 Received: from wizard.gsfc.nasa.gov by osi-west.es.net via ESnet SMTP service id <25001-0@osi-west.es.net>; Wed, 16 Nov 1994 15:36:43 +0000 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA14477; Wed, 16 Nov 94 18:36:41 -0500 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9411162336.AA14477@wizard.gsfc.nasa.gov> Subject: Modifications to CU-SeeMe Reflector Code for nv v3.3beta To: rem-conf@es.net Date: Wed, 16 Nov 1994 18:36:40 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5891 Since this hasn't made its way into a new release of the CU-SeeMe Reflector code and several people had expressed an interest in it, I'm posting my changes to the Reflector code that makes it compatible with nv v3.3beta, by constructing the proper RTP header for the multicast video data when using the NV-TO-MC Reflector option. Please note that after the change the Reflector will not be compatible with versions of nv earlier than v3.3beta (e.g. v3.2) for displaying CU-SeeMe video if there are multiple CU-SeeMe video streams. Many thanks to Ron Frederick for his considerable help with working up this code although I take full blame for any bugs that might be lurking therein. I have just tested these changes with the most recent version of the Reflector code, namely 2.40b4 which is available via anonymous ftp at gated.cornell.edu in the video/Reflector directory. I do suggest removing all the .o files after making the changes below and before doing a make. I had some problems when I didn't clean the directory first. Also, I've only tested this on a sun4c architecture and all standard disclaimers apply, i.e. it is being made available as-is with no guarantees or warrantees, just in case it might be useful to anyone else. -Bill Changes to make CU-SeeMe Reflector compatible with nv v3.3beta ------------------------------------------------------------------------ reflect.h: The only changes to reflect.h are to modify the value of MHEADERLEN to 8 (from 10) and add a new unsigned long field, clnt_sdesc_time, to the struct client definition. Context diff for reflect.h: *************** *** 123,129 **** #define TRATE 10 #define HRATE 60 ! #define MHEADERLEN 10 #define NVVERSION 0x40 #define NVCONTENT 27 #define NVOBIT 0x80 --- 123,129 ---- #define TRATE 10 #define HRATE 60 ! #define MHEADERLEN 8 #define NVVERSION 0x40 #define NVCONTENT 27 #define NVOBIT 0x80 *************** *** 240,245 **** --- 240,246 ---- short clnt_hdloop; /* # of times through the timer loop before deleting hold downs */ unsigned short clnt_conf_id; /* conference id the client connected with */ unsigned long clnt_flags; /* flags */ + unsigned long clnt_sdesc_time; /* timestamp of last SDESC option transmitted */ unsigned long clnt_bytecnt; /* byte count for video packets */ struct timeval clnt_tp; /* time value used in calculating the byte cnt */ OpenContinueData clnt_config; /* client's configuration */ refutil.c: Replace the entire nv_mcast_wrt routine in the refutil.c module with the following code: #include #define NV_CHAN 32 #define NV_SDESC_TIMER 5 #define SSRCLEN 8 #define SSRC 1 #define RTP_EPOCH_OFFSET ((unsigned long) 2208988800) unsigned long RTPTime(); nv_mcast_wrt(vidptr,cltptr) VideoPacketHeader *vidptr; client *cltptr; { unsigned char *cptr,*tmp; unsigned char id; unsigned short datatype,seqnum,message,client_id; unsigned long timestamp; short len,wlen; #ifdef DEBUG if (debug) printf("Multicasting (for NV) to %s\n",inet_ntoa(nv_mcast.sin_addr)); #endif cptr = ((unsigned char *) vidptr) + HEADERLEN; datatype = vidptr->dataType; bcopy(&datatype,cptr,sizeof(datatype)); client_id = htons(cltptr->clnt_id); seqnum = vidptr->seqNum; /* truncate to 16 bits for RTP header */ message = ntohs(vidptr->message); len = ntohs(vidptr->len) - HEADERLEN + MHEADERLEN + SSRCLEN; timestamp = RTPTime(); if (((timestamp - cltptr->clnt_sdesc_time) >> 16) >= NV_SDESC_TIMER) { cltptr->clnt_sdesc_time = timestamp; wlen = (strlen(cltptr->clnt_config.name) >> 2) + 3; cptr -= (wlen << 2); tmp = cptr; *tmp++ = SDESC | FINAL; /* RTP SDESC option is FINAL option */ *tmp++ = wlen; /* option length */ *((unsigned short *) tmp) = client_id; /* client id */ tmp += sizeof(client_id); bcopy(&cltptr->clnt_addr.addr,tmp,sizeof(struct in_addr)); /* client addr */ tmp += sizeof(struct in_addr); strcpy(tmp,cltptr->clnt_config.name); /* client name */ *(cptr - SSRCLEN) = SSRC; /* RTP SSRC option */ } else { wlen = 0; *(cptr - SSRCLEN) = SSRC | FINAL; /* RTP SSRC option is FINAL option */ } len += (wlen << 2); cptr -= MHEADERLEN + SSRCLEN; tmp = cptr; /* start of RTP header */ *tmp++ = NVVERSION | NV_CHAN; /* nv version & channel id */ *tmp = NVCONTENT | NVOBIT; /* nv content with RTP options */ if (message == kFrameEndMessage) *tmp |= NVSBIT; /* nv framing bit */ tmp++; *((unsigned short *) tmp) = seqnum; /* seq */ tmp += sizeof(seqnum); timestamp = htonl(timestamp); bcopy(×tamp,tmp,sizeof(timestamp)); tmp += sizeof(timestamp) + 1; /* RTP SSRC option */ /* already set RTP option type */ *tmp++ = SSRCLEN >> 2; /* RTP option length */ *((unsigned short *) tmp) = client_id; /* client id */ tmp += sizeof(client_id); bcopy(&cltptr->clnt_addr.addr,tmp,sizeof(struct in_addr)); /* client addr */ if (sendto(nv_mcast_sock,cptr,len,0,&nv_mcast,sizeof(struct sockaddr_in)) != len) dolog("mcast sendto error"); } unsigned long RTPTime() { struct timeval t; gettimeofday(&t, NULL); return ((t.tv_sec + RTP_EPOCH_OFFSET) << 16) | ((t.tv_usec << 10) / 15625); } From rem-conf-request@es.net Wed Nov 16 20:58:42 1994 Received: from Sun.COM by osi-west.es.net via ESnet SMTP service id <25995-0@osi-west.es.net>; Wed, 16 Nov 1994 17:58:05 +0000 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA02511; Wed, 16 Nov 94 17:58:01 PST Received: from vision.Eng.Sun.COM by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA23671; Wed, 16 Nov 94 17:58:27 PST Received: by vision.Eng.Sun.COM (5.0/SMI-SVR4) id AA00661; Wed, 16 Nov 1994 17:58:02 +0800 Date: Wed, 16 Nov 1994 17:58:02 +0800 From: Vincent.Lau@Eng.Sun.COM (Vincent Lau) Message-Id: <9411170158.AA00661@vision.Eng.Sun.COM> To: rem-conf@es.net Subject: RTPv2 for variable frame rate video stream Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Length: 923 Can someone enlighten me how variable frame rate video stream can be supported by the new RTPv2 timestamp? In RTPv1 the timestamp is a partial absolute NTP time. Each frame has an almost unique timestamp (except wrap around). Currently I use the timestamp of the current frame and the previous frame to determine the playtime for a frame. When I record a session (with video/audio stream), it works pretty well even the broadcaster changes the frame rate in the middle of a session. But the RTPv2 timestamp has a new semantics that the frequency is specified in an external profile (e.g. using sd) and the frequency is quite static. Also there is no guarantee that a receiver will get the updated profile before receiving the new video stream. So, how can I achieve this with RTPv2? Vincent Lau Internet: vincent.lau@Eng.Sun.Com Digital Network Media Phone: 415-336-1069 Sun Microsystems Computer Company From rem-conf-request@es.net Thu Nov 17 03:22:29 1994 Received: from ceres.fokus.gmd.de by osi-west.es.net via ESnet SMTP service id <28124-0@osi-west.es.net>; Thu, 17 Nov 1994 00:22:00 +0000 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <05596-0@ceres.fokus.gmd.de>; Thu, 17 Nov 1994 09:21:16 +0100 Subject: Re: RTPv2 for variable frame rate video stream To: Vincent.Lau@Eng.Sun.COM Cc: rem-conf@es.net MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Thu, 17 Nov 1994 09:21:16 +0100 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de > Can someone enlighten me how variable frame rate video stream can be > supported by the new RTPv2 timestamp? > > In RTPv1 the timestamp is a partial absolute NTP time. Each frame has > an almost unique timestamp (except wrap around). Currently I use the > timestamp of the current frame and the previous frame to determine the > playtime for a frame. When I record a session (with video/audio > stream), it works pretty well even the broadcaster changes the frame > rate in the middle of a session. > > But the RTPv2 timestamp has a new semantics that the frequency is > specified in an external profile (e.g. using sd) and the frequency is > quite static. Also there is no guarantee that a receiver will get the > updated profile before receiving the new video stream. So, how can I > achieve this with RTPv2? > > Vincent Lau Internet: vincent.lau@Eng.Sun.Com > Digital Network Media Phone: 415-336-1069 > Sun Microsystems Computer Company > The RTPv2 clock frequency is encoding-specific. Thus, your encoding spec (cell-B? other?) could continue to define NTP rate as the clock rate. MPEG, for example, would likely use the lower 32 bits of their 33 bit timestamp. It is not intended that sd or anything else change the clock rate for each conference. That would indeed have the problems you mentioned. That said, there may be a case to be made that not every video encoding has its own clock rate. Before it's too late, I suggest that the JPEG, H.261 and Cell-B folks get together and see whether they can agree on one rate. NTP and MPEG 90 kHz would seem to be the natural choices. (MPEG argues that its rate divides nicely for the common frame rates of 25 and 30 Hz.) The current profile draft specifies a default clock rate of 65536 Hz (same as RTPv1) for video. Should this be changed? Henning -- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 182 ; Thu, 17 Nov 1994 01:13:20 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Thu, 17 Nov 1994 01:13:16 -0800 Posted-Date: Thu 17 Nov 94 01:12:07 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 17 Nov 94 01:12:08 PST Date: Thu 17 Nov 94 01:12:07 PST From: Stephen Casner Subject: Re: RTPv2 for variable frame rate video stream To: Vincent.Lau@eng.sun.com, rem-conf@es.net Message-Id: <785063527.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9411170158.AA00661@vision.Eng.Sun.COM> Mail-System-Version: > Can someone enlighten me how variable frame rate video stream can be > supported by the new RTPv2 timestamp? The RTPv2 timestamp is defined to be media specific, that is, selected to be appropriate for a particular encoding. For audio encodings like PCM, the clock rate will be the same as the sample rate. However, for several of the video encodings that we have been using, the choice under RTPv2 will be a 65536Hz clock similar to what RTPv1 specified for all media. The difference is that the clock be initialized to a random value and would not be periodically corrected at the source to compensate for drift with respect to real time. Remember also that in both RTPv1 and RTPv2, the clock represents the sampling instant, not the time of packet transmission. In general, it is not a correct technique to ask the system for an NTP timestamp as each packet is being assembled. Instead, the timestamps should be calculated based on the sampling clock (usually 59.94Hz for NTSC video). One might suggest using a 59.94Hz clock for video encodings, but the problem is that this does not provide enough resolution for calculating and representing the media timestamp corresponding to the real-time timestamp representing the time of transmission in an RTCP Sender Report (SR) packet. > In RTPv1 the timestamp is a partial absolute NTP time. Each frame has > an almost unique timestamp (except wrap around). Currently I use the > timestamp of the current frame and the previous frame to determine the > playtime for a frame. When I record a session (with video/audio > stream), it works pretty well even the broadcaster changes the frame > rate in the middle of a session. I think the RTPv2 timestamp, as described above, will still serve these functions in the same way. > But the RTPv2 timestamp has a new semantics that the frequency is > specified in an external profile (e.g. using sd) and the frequency is > quite static. Also there is no guarantee that a receiver will get the > updated profile before receiving the new video stream. So, how can I > achieve this with RTPv2? This isn't quite right. The frequency of the timestamp is specified in the document that defines the particular encoding, which may be a profile spec (like the audio/video profile) or an encoding spec (like the H.261-, JPEG- and MPEG-over-RTP specs). The profile document also specifies the payload type codes that correspond to a default set of encodings, or a session manager such as sd can specify dynamic assignments of payload type codes to other encodings not in the default set. The dynamic payload type mappings would be provided to the receiver at the time it is invoked. During the course of the session, they payload type may change to indicate a different encoding, and the new encoding may use a different timestamp clock frequency, but the receiver will already know what that frequency is if the receiver is prepared to decode that encoding. Does that make the issue any more clear? If you have specific advice on how and where the RTP spec should be more clear about this, I would like to hear it. Thanks for your questions and comments. -- Steve ------- From rem-conf-request@es.net Thu Nov 17 05:21:03 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <29092-0@osi-west.es.net>; Thu, 17 Nov 1994 02:20:14 +0000 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 17 Nov 1994 10:15:52 +0000 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: Vincent.Lau@Eng.Sun.COM (Vincent Lau) cc: rem-conf@es.net Subject: Re: RTPv2 for variable frame rate video stream In-reply-to: Your message of "Wed, 16 Nov 94 17:58:02 +0800." <9411170158.AA00661@vision.Eng.Sun.COM> Date: Thu, 17 Nov 94 10:14:52 +0000 Message-ID: <7870.785067292@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >Can someone enlighten me how variable frame rate video stream can be >supported by the new RTPv2 timestamp? > >In RTPv1 the timestamp is a partial absolute NTP time. Each frame has >an almost unique timestamp (except wrap around). Currently I use the >timestamp of the current frame and the previous frame to determine the >playtime for a frame. When I record a session (with video/audio >stream), it works pretty well even the broadcaster changes the frame >rate in the middle of a session. > >But the RTPv2 timestamp has a new semantics that the frequency is >specified in an external profile (e.g. using sd) and the frequency is >quite static. Also there is no guarantee that a receiver will get the >updated profile before receiving the new video stream. So, how can I >achieve this with RTPv2? There's nothing to stop you using whatever units you want for your timestamps in RTPv2, so long as each of your time units takes the same amount of real time. For variable frame rate video, I would suggest continuing to use NTP timestamps. Also, you would normally specify in RTCP control packets what the relationship between your time units and NTP time is (not in sd). If you use NTP as your RTP timestamps, then this is a null mapping. I can't remember whether there's a default timestamp<->NTP mapping for each RTPv2 media type (I must re-read the spec again), but if there isn't perhaps their should be. Mark From rem-conf-request@es.net Thu Nov 17 05:37:33 1994 Received: from mitsou.inria.fr by osi-west.es.net via ESnet SMTP service id <29196-0@osi-west.es.net>; Thu, 17 Nov 1994 02:36:28 +0000 Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA09933; Thu, 17 Nov 1994 11:39:09 +0100 Message-Id: <199411171039.AA09933@mitsou.inria.fr> To: Stephen Casner Cc: rem-conf@es.net Subject: Re: RTPv2 for variable frame rate video stream In-Reply-To: Your message of "Thu, 17 Nov 1994 01:12:07 PST." <785063527.0.CASNER@XFR.ISI.EDU> Date: Thu, 17 Nov 1994 11:39:09 +0100 From: Christian Huitema Steve, There is one pitfall with coding-specific choice of clocks. As part of our adaptation procedure, we may well envisage to change the encodingin real type, e.g. switch from ADPCM to GSM then to 16khz DVI then to WAV. Or from H.261 to JPEG and back. I understand that why 11.5 khz DVI is better served with a 11.5 khz clock, but we have a problem of synchronisation when we switch from 11.5 khz DVI to 8khz LPC. How are we supposed to solve that? Is an occasional NTP time stamp parameter the correct solution? It may indeed be required in any case for inter-media synchronisation.. Christian huitema From rem-conf-request@es.net Thu Nov 17 07:04:25 1994 Received: from charon.cwi.nl by osi-west.es.net via ESnet SMTP service id <29667-0@osi-west.es.net>; Thu, 17 Nov 1994 04:03:41 +0000 Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP id ; Thu, 17 Nov 1994 13:03:35 +0100 Received: by schelvis.cwi.nl with SMTP id ; Thu, 17 Nov 1994 13:03:34 +0100 Message-Id: <9411171203.AA05336=jack@schelvis.cwi.nl> To: Fengmin Gong Cc: rem-conf@es.net Subject: Re: Audio Echo Cancellation In-Reply-To: Message by Fengmin Gong , Sat, 12 Nov 1994 08:29:04 -0500 (EST) , <9411121329.AA02595@crusher.mcnc.org> Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam Phone: +31 20 5924098(work), +31 20 5924199 (fax), +31 20 6160335(home) X-Last-Band-Seen: Henk Koorn (Buurvrouw, 30-10) X-Mini-Review: Brilliant entertainer, as always Date: Thu, 17 Nov 1994 13:03:33 +0100 From: Jack Jansen Recently, Fengmin Gong said: > > I have actually implemented such a thing based on an adaptive FIR filter > in C on my Sparc10, however it does not work at all. The problem does > not seem to be lack of cycles in particular, but rather due to the > "jitter" introduced when reading and sending audio samples to the A/D > and D/A hardware. Because this basically destroys the filter's ability > to model the feedback path between the local MIC and the speaker. > I did a similar thing on an SGI, also with no success. The SGI is slightly better than the Sparc here, since I can get a +/- 1 indication of which sample is currently going out the speaker (this is not trivial, by the way, so SGI hackers who want more info: contact me. ALgetfillable() alone is not enough). The 1 sample drift is more than enough to ruin the party, though. I thought of going to a higher sample rate like 32K (since that would hopefully ameliorate the effect of the one-sample jitter), but I never got around to it due to lack of time. If anyone else wants to have a go: you're welcome to the (python-)code. -- Jack Jansen | If I can't dance I don't want to be part of Jack.Jansen@cwi.nl | your revolution -- Emma Goldman uunet!cwi.nl!jack G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl From rem-conf-request@es.net Thu Nov 17 10:03:14 1994 Received: from terminator.rs.itd.umich.edu by osi-west.es.net via ESnet SMTP service id <00794-0@osi-west.es.net>; Thu, 17 Nov 1994 07:02:38 +0000 Received: from terminator.rs.itd.umich.edu by terminator.rs.itd.umich.edu (8.6.9/2.3) with SMTP id JAA06323; Thu, 17 Nov 1994 09:58:17 -0500 Message-Id: <199411171458.JAA06323@terminator.rs.itd.umich.edu> To: Jack Jansen Cc: Fengmin Gong , rem-conf@es.net Subject: Re: Audio Echo Cancellation In-reply-to: Your message of Thu, 17 Nov 1994 13:03:33 +0100. <9411171203.AA05336=jack@schelvis.cwi.nl> Date: Thu, 17 Nov 1994 09:58:16 -0500 From: Dory Ethan Leifer Given the complexities of workstation implementations, does anyone have any experience with hardware-based echo cancellation? How well do these devices work in practice? Any suggestions about which products people have had luck with? Thanks, Dory > > Recently, Fengmin Gong said: > > > > I have actually implemented such a thing based on an adaptive FIR filter > > in C on my Sparc10, however it does not work at all. The problem does > > not seem to be lack of cycles in particular, but rather due to the > > "jitter" introduced when reading and sending audio samples to the A/D > > and D/A hardware. Because this basically destroys the filter's ability > > to model the feedback path between the local MIC and the speaker. > > > I did a similar thing on an SGI, also with no success. The SGI is slightly > better than the Sparc here, since I can get a +/- 1 indication of > which sample is currently going out the speaker (this is not trivial, > by the way, so SGI hackers who want more info: contact > me. ALgetfillable() alone is not enough). The 1 sample drift is more > than enough to ruin the party, though. > > I thought of going to a higher sample rate like 32K (since that would > hopefully ameliorate the effect of the one-sample jitter), but I never > got around to it due to lack of time. If anyone else wants to have a > go: you're welcome to the (python-)code. > -- > Jack Jansen | If I can't dance I don't want to be part of > Jack.Jansen@cwi.nl | your revolution -- Emma Goldman > uunet!cwi.nl!jack G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl From rem-conf-request@es.net Thu Nov 17 10:50:42 1994 Received: from crusher.mcnc.org by osi-west.es.net via ESnet SMTP service id <01174-0@osi-west.es.net>; Thu, 17 Nov 1994 07:49:41 +0000 Received: by crusher.mcnc.org (5.59/tas-concert/6-19-91) id AA06275; Thu, 17 Nov 94 10:47:24 -0500 From: Fengmin Gong Message-Id: <9411171547.AA06275@crusher.mcnc.org> Subject: Re: Audio Echo Cancellation To: leifer@terminator.rs.itd.umich.edu (Dory Ethan Leifer) Date: Thu, 17 Nov 1994 10:47:24 -0500 (EST) Cc: Jack.Jansen@cwi.nl, fmg@crusher.mcnc.org, rem-conf@es.net In-Reply-To: <199411171458.JAA06323@terminator.rs.itd.umich.edu> from "Dory Ethan Leifer" at Nov 17, 94 09:58:16 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 963 Re: message from Dory Ethan Leifer: > > >Given the complexities of workstation implementations, does anyone >have any experience with hardware-based echo cancellation? How well >do these devices work in practice? Any suggestions about which products >people have had luck with? > >Thanks, >Dory > >> I am not sure about the bad-luck experience but MCNC has used COHERENT echo cancellers in its video conferencing network with success. I have seen newer products from COHERENT, SHURE, and Gentner but have no experience with them. If you have production conferencing facility getting these boxes should be a good idea and worthwhile investment. They are (at least what I have seen) mostly made for room-based conferences, have several analog MIC and speaker interfaces, thus a little overkill for desktop uses. Regards, -- Fengmin Gong E-mail: gong@mcnc.org Network Research Engineer Phone: 919 248-9214 MCNC Information Technologies FAX: 919 248-1455 From rem-conf-request@es.net Thu Nov 17 11:10:09 1994 Received: from mail1.its.rpi.edu by osi-west.es.net via ESnet SMTP service id <01395-0@osi-west.es.net>; Thu, 17 Nov 1994 08:09:12 +0000 Received: from sabina.its.rpi.edu (garfip@sabina.its.rpi.edu [128.113.68.26]) by mail1.its.rpi.edu (8.6.4/8.6.4) with ESMTP id LAA14726 for ; Thu, 17 Nov 1994 11:09:09 -0500 Received: (garfip@localhost) by sabina.its.rpi.edu (8.6.9/8.6.4) id LAA23012 for rem-conf@es.net; Thu, 17 Nov 1994 11:09:07 -0500 From: garfip@rpi.edu ( ) Message-Id: <9411171109.ZM15842@sabina.its.rpi.edu> Date: Thu, 17 Nov 1994 11:09:06 -0500 X-Mailer: Z-Mail (2.1.5 20sep93) To: rem-conf@es.net Subject: Cyber-Aztechnology: 11/22 CHICANO CYBER-PIRATE TO COMMANDEER TV AIRWAVES The iEAR Studios at Rensselaer Polytechnic Institute invite you to take part in a nationally interactive satellite telecast, beamed live from the RPI campus. Cable and public access operators are invited to downlink this event, transmitted over Ku band, free of charge. Become part of the national audience when performance art pioneer GUILLERMO GOMEZ-PENA, the "High-Tech Aztec" himself, becomes EL NAFTAZTEC (Nafta + Aztec). Watch as El Naftaztec pirates a commercial TV signal in the year 2000 and demonstrates to North America his Chicano Virtual Reality machine, with which he can instantly recall any moment in his or his people's history and display the moment in video image. TUESDAY NOVEMBER 22, 1994 8:45pm - 10:30pm Eastern Join Guillermo Gomez-Pena, a recipient of the prestigious MacArthur "Genius" Fellowship, and more than 1,000,000 viewers nationwide, for this singular evening of interactive Cyber-Aztechnology. In addition to viewing the telecast from the DCC, users on the MBONE network will be able to "tune on" to the production 8:45pm - 10:30pm EST. TECHNICAL INFORMATION - Transmission on Ku Band - Satellite: TELSTAR 401 - Transponder: K-11 - Downlink Frequency: 12040 Vertical/97 degrees West - Audio: 6.2 and 6.8 - Colour bars and test tone: 20:45-21:00 EST - Transmission: 21:00-22:30 EST For more information contact: http://www.rpi.edu/~djwap/ggp.html or GARFIP@RPI.EDU -- ### -- From rem-conf-request@es.net Thu Nov 17 14:54:17 1994 Received: from inet-gw-2.pa.dec.com by osi-west.es.net via ESnet SMTP service id <09500-0@osi-west.es.net>; Thu, 17 Nov 1994 11:53:18 +0000 Received: from bitski.pa.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA12345; Thu, 17 Nov 94 11:45:59 -0800 Received: by bitski.pa.dec.com; id AA21836; Thu, 17 Nov 1994 11:45:57 -0800 Message-Id: <9411171945.AA21836@bitski.pa.dec.com> To: rem-conf@es.net Cc: redell@pa.dec.com Subject: Re: Audio Echo Cancellation In-Reply-To: Message of Thu, 17 Nov 1994 09:58:16 -0500 from leifer@terminator.rs.itd.umich.edu (Dory Ethan Leifer) <199411171458.JAA06323@terminator.rs.itd.umich.edu> Date: Thu, 17 Nov 94 11:45:57 -0800 From: redell@pa.dec.com X-Mts: smtp ------ > Any suggestions about which products people have had luck with? We've tried two: Sony PCS-V4: Mixed results, probably due in part to using a beta-test version. When it works, it seems to give fairly good echo cancellation, although the size and placement of the speaker and microphone (tiny units built into the display-top camera box) impose inherent limits on the sound quality. Shure Concensus ST4300: This works very well, but is quite elaborate and expensive for desktop use. It is intended for conference room situations, uses external speaker and microphone(s) and is about the size of a small stereo receiver. We've also used the NEC VoicePoint echo-cancelling speakerphone, and fiddled around with the Shure and PolyCom units, but I assume those aren't directly relevant to your question, other than as possible benchmarks for comparison. Dave Redell DEC Systems Research Center redell@pa.dec.com From rem-conf-request@es.net Fri Nov 18 01:23:24 1994 Received: from piper.cs.Colorado.EDU by osi-west.es.net via ESnet SMTP service id <02105-0@osi-west.es.net>; Thu, 17 Nov 1994 22:22:58 +0000 Received: from [198.11.16.30] (mac3bryan.cs.colorado.edu [198.11.16.30]) by piper.cs.colorado.edu (8.6.9/8.6.9) with SMTP id XAA28713 for ; Thu, 17 Nov 1994 23:22:54 -0700 Date: Thu, 17 Nov 1994 23:22:54 -0700 X-Sender: mcbr@piper.cs.colorado.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: mcbryan@cs.colorado.edu (Oliver A. McBryan) Subject: Conference Broadcast On Dec 5 University of Colorado is hosting a major telecommunications conference. Featured speakers include two U.S. Senators; Richard McCormick, US WEST; John Malone, TCI; John Perry Barlow, Electronic Fronter Foundation; .... We feel this one day meeting would be of considerable interest to the Internet. We would like to broadcast it on the MBONE from 9AM-5PM MST. What is the procedure for "reserving" this slot, and I'd appreciate any advice on being good citizens, as well as practical advice on doing the audio and video feeds. More conference info is at: http://www.cs.colorado.edu/home/mcbryan/cnii/brochure.html Oliver McBryan; mcbryan@cs.colorado.edu; 303-6650544; Fax 303-4922844 Dept of Computer Science, University of Colorado, Boulder, CO 80309. WWW: http://www.cs.colorado.edu/home/mcbryan/Home.html From rem-conf-request@es.net Fri Nov 18 02:49:37 1994 Received: from merit.edu by osi-west.es.net via ESnet SMTP service id <02537-0@osi-west.es.net>; Thu, 17 Nov 1994 23:49:16 +0000 Received: from localhost (ljb@localhost) by merit.edu (8.6.9/merit-2.0) with SMTP id CAA08786; Fri, 18 Nov 1994 02:49:12 -0500 Message-Id: <199411180749.CAA08786@merit.edu> To: mcbryan@cs.colorado.edu (Oliver A. McBryan) cc: rem-conf@es.net Subject: Re: Conference Broadcast In-reply-to: Your message of "Thu, 17 Nov 1994 23:22:54 MST." Date: Fri, 18 Nov 1994 02:49:12 -0500 From: "Larry J. Blunk" Looks like they picked a bad day to hold the conference as this is the first day of the San Jose IETF. Since the IETF usually takes up a fair amount of bandwidth on the MBONE, I'd strongly recommend not multicasting this conference. -Larry Blunk Merit Network, Inc. > On Dec 5 University of Colorado is hosting a major telecommunications > conference. Featured speakers include two U.S. Senators; Richard > McCormick, US WEST; John Malone, TCI; John Perry Barlow, Electronic > Fronter Foundation; .... > > We feel this one day meeting would be of considerable interest to the Interne >t. > > We would like to broadcast it on the MBONE from 9AM-5PM MST. What is the > procedure for "reserving" this slot, and I'd appreciate any advice on being > good citizens, as well as practical advice on doing the audio and video > feeds. > > More conference info is at: > http://www.cs.colorado.edu/home/mcbryan/cnii/brochure.html > > Oliver McBryan; mcbryan@cs.colorado.edu; 303-6650544; Fax 303-4922844 > Dept of Computer Science, University of Colorado, Boulder, CO 80309. > WWW: http://www.cs.colorado.edu/home/mcbryan/Home.html > > From rem-conf-request@es.net Fri Nov 18 02:51:16 1994 Received: from neoteny.eccosys.com by osi-west.es.net via ESnet SMTP service id <02564-0@osi-west.es.net>; Thu, 17 Nov 1994 23:50:32 +0000 Received: from tube.eccosys.com by eccosys.com (4.1/SMI-4.1-EB-940511.1) id AA17420; Fri, 18 Nov 94 16:55:48 JST Received: from localhost by tube.eccosys.com (4.1/eccosys-V0.7) id AA25863; Fri, 18 Nov 94 16:47:27 JST To: rem-conf@es.net Subject: Stones Multicast Update. Date: Fri, 18 Nov 1994 16:47:20 +0900 Message-Id: <25862.785144840@eccosys.com> From: Cyrus Here is more information on the Rolling Stones Multicast. Please direct non list-related debate to multicast@thinkpix.com. ------- Forwarded Message Date: Fri, 18 Nov 94 01:17:30 -0500 From: multicast@thinkpix.com To: cyrus Subject: Schedule The Stones Cybercast will be from 10:00pm EST to 11:00pm EST, with several rebroadcasts throughout the weekend and to monday. Contents: The multicast consists of a 30minute tape of Stones interviews with a few commercial inserts and then the live concert (approx 20minutes). I have looked through the tape and I think there is maybe two or three 10 second logo/clips, two or three PayPerView 30 second announcements. Nothing which shows a phone number to order pay per view. There is one 30sec Stones merchandise clip which does not ask people to call to order but offers a number to get a catalog. We at Thinking Pictures apologize if this offends anybody and hope that this opening 30minutes is used for people to tune in for the real, commercial free, show that follows. What I mean by tune-up is setting TTL's and configuring machines for optimal bandwidth. ------- End of Forwarded Message This is going to be a controversial multicast. But let us be open to all points of view. I admit that I have reservations about the intial segment, and if you feel that you would be going against the policies of your network to watch this multicast, feel free not to watch it. For those people who do not feel that there is a problem with the multicast, please enjoy the live portion (feel free to kill or hide nv and vat until the live music starts.) Thank you, Cyrus Shaoul cyrus@thinkpix.com cyrus@eccosys.com From rem-conf-request@es.net Fri Nov 18 03:36:40 1994 Received: from maths.anu.edu.au by osi-west.es.net via ESnet SMTP service id <03111-0@osi-west.es.net>; Fri, 18 Nov 1994 00:35:52 +0000 Received: from einstein.anu.edu.au by maths.anu.edu.au with SMTP id AA00439 (5.65c/IDA-1.4.4 for ); Fri, 18 Nov 1994 19:35:46 +1100 Received: by einstein.anu.edu.au id AA06325 (940406.SGI/IDA-1.4.4); Fri, 18 Nov 94 19:35:45 +1100 From: "Ben Evans aka Ben.Evans" Message-Id: <9411181935.ZM6323@einstein.anu.edu.au> Date: Fri, 18 Nov 1994 19:35:44 -0500 X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: rem-conf@es.net Subject: subscribe Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Please subscribe Ben.Evans@maths.anu.edu.au Thanks, Ben From rem-conf-request@es.net Fri Nov 18 04:00:22 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <03236-0@osi-west.es.net>; Fri, 18 Nov 1994 00:59:22 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Fri, 18 Nov 1994 00:59:15 -0800 Posted-Date: Fri 18 Nov 94 00:58:06 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 18 Nov 94 00:58:07 PST Date: Fri 18 Nov 94 00:58:06 PST From: Stephen Casner Subject: Re: RTPv2 for variable frame rate video stream To: Christian.Huitema@sophia.inria.fr, M.Handley@cs.ucl.ac.uk Cc: rem-conf@es.net Message-Id: <785149086.0.CASNER@XFR.ISI.EDU> In-Reply-To: <7870.785067292@cs.ucl.ac.uk> Mail-System-Version: Christian Huitema asked: > How are we supposed to solve that [maintaining synchronization when > switching between encodings with different RTP clock rates]? Is an > occasional NTP time stamp parameter the correct solution? It may > indeed be required in any case for inter-media synchronisation.. Exactly. That's what the RTP and NTP timestamp pair are for in the Sender Report control packet. Mark Handley said: > There's nothing to stop you using whatever units you want for your > timestamps in RTPv2, so long as each of your time units takes the same > amount of real time. This statement might be misinterpreted. One does not choose the units when invoking an application! The person who writes an encoding spec gets to make the choice of timestamp units. For any given encoding, there will be a specified clock rate (timestamp unit), and all applications using the encoding will follow that. > For variable frame rate video, I would suggest continuing to use NTP > timestamps. Almost, except for the random initial value and not correcting at the sender for drift with respect to real time. > I can't remember whether there's a default timestamp<->NTP mapping for > each RTPv2 media type (I must re-read the spec again), but if there > isn't perhaps their should be. There is, although the details of the audio/video profile have received less attention than the main RTP spec itself. -- Steve ------- From rem-conf-request@es.net Fri Nov 18 06:10:41 1994 Received: from dist.dist.unige.it by osi-west.es.net via ESnet SMTP service id <04192-0@osi-west.es.net>; Fri, 18 Nov 1994 03:09:15 +0000 Received: by dist.dist.unige.it (5.61++/IDA-1.2.8) id AA06028; Fri, 18 Nov 94 11:58:31 +0100 From: "Mauro Migliardi." Message-Id: <9411181058.AA06028@dist.dist.unige.it> Subject: UNSUBSCRIBE To: rem-conf@es.net Date: Fri, 18 Nov 94 11:58:30 MET X-Mailer: ELM [version 2.3 PL0] Forwarded message: > From om Thu Nov 17 16:17:14 1994 > Date: Thu, 17 Nov 94 16:16:45 +0100 > From: Mail Delivery Subsystem > Message-Id: <9411171516.AA22294@dist.dist.unige.it> > To: om@dist.dist.unige.it > Cc: Postmaster@dist.dist.unige.it > Subject: Returned mail: User unknown > > ----- Transcript of session follows ----- > While talking to osi-west.es.net: > >>> RCPT To: > <<< 550 Unknown local user 'majordomo' > 550 majordomo@es.net... User unknown > >>> RCPT To: > <<< 550 Unknown local user 'listserv' > 550 listserv@es.net... User unknown > > ----- Unsent message follows ----- > Received: by dist.dist.unige.it > (5.61++/IDA-1.2.8) id AA22287; Thu, 17 Nov 94 16:16:45 +0100 > From: "Mauro Migliardi." > Message-Id: <9411171516.AA22287@dist.dist.unige.it> > Subject: UNSUBSCRIBE > To: listserv@es.net > Date: Thu, 17 Nov 94 16:16:44 MET > Cc: majordomo@es.net > X-Mailer: ELM [version 2.3 PL0] > > Forwarded message: > >From om Thu Nov 17 16:14:53 1994 > Date: Thu, 17 Nov 94 16:14:40 +0100 > From: Mail Delivery Subsystem > Message-Id: <9411171514.AA22224@dist.dist.unige.it> > To: om@dist.dist.unige.it > Cc: Postmaster@dist.dist.unige.it > Subject: Returned mail: User unknown > > ----- Transcript of session follows ----- > While talking to osi-west.es.net: > >>> RCPT To: > <<< 550 Unknown local user 'LISTSERV' > 550 LISTSERV@es.net... User unknown > > ----- Unsent message follows ----- > Received: by dist.dist.unige.it > (5.61++/IDA-1.2.8) id AA22221; Thu, 17 Nov 94 16:14:40 +0100 > From: "Mauro Migliardi." > Message-Id: <9411171514.AA22221@dist.dist.unige.it> > Subject: UNSUBSCRIBE > To: LISTSERV@es.net > Date: Thu, 17 Nov 94 16:14:40 MET > X-Mailer: ELM [version 2.3 PL0] > > Hi to all, I hope I'm writing these lines for no one, because if you are > reading this it means that this message is going through the list :(. > I already tried rem-conf-request@es.net with no success so now I'm trying > this. If someone knows the right way just tell me, please. > Bye. > > Mauro Migliardi > -- > > > -- > I have tried the following: rem-conf-request listserv majordomo no success. I know this is a broadcast, but I have no other ideas. Sorry to bother you guys. Mauro Migliardi -- From rem-conf-request@es.net Fri Nov 18 08:25:53 1994 Received: from sonne.darmstadt.gmd.de by osi-west.es.net via ESnet SMTP service id <04890-0@osi-west.es.net>; Fri, 18 Nov 1994 05:25:14 +0000 Received: from [141.12.61.148] ([141.12.61.148]) by sonne.darmstadt.gmd.de (8.6.9/8.6.9) with SMTP id OAA02355 for ; Fri, 18 Nov 1994 14:26:14 +0100 Message-Id: <199411181326.OAA02355@sonne.darmstadt.gmd.de> Date: Fri, 18 Nov 1994 14:26:59 +0100 To: rem-conf@es.net From: bahr@darmstadt.gmd.de X-Sender: bahr@mailserver.darmstadt.gmd.de Subject: Multicast over ATM I am on a search for papers, notes, articles, drafts, discussions etc on the subject of Multicasting over ATM. Can anyone help, please? Thanks, Knut Bahr From rem-conf-request@es.net Fri Nov 18 08:31:57 1994 Received: from cismsun.univ-lyon1.fr by osi-west.es.net via ESnet SMTP service id <04959-0@osi-west.es.net>; Fri, 18 Nov 1994 05:31:26 +0000 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.9/8.6.6) id OAA27662 for rem-conf@es.net; Fri, 18 Nov 1994 14:31:22 +0100 Message-Id: <199411181331.OAA27662@cismsun.univ-lyon1.fr> Subject: nv on DEC Alpha To: rem-conf@es.net Date: Fri, 18 Nov 1994 14:31:21 +0100 (MET) From: Lucia Gradinariu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 200 Hi, Has anybody experienced nv-3.3beta on a DEC Alph. with J300? I can't get it recognize the J300 a-v board as grabber (it recognize only X11). Thanks for any help Lucia.Gradinariu@univ-lyon1.fr From rem-conf-request@es.net Fri Nov 18 12:27:07 1994 Received: from sirius.brunel.ac.uk by osi-west.es.net via ESnet SMTP service id <06358-0@osi-west.es.net>; Fri, 18 Nov 1994 09:26:12 +0000 Received: from brunel.ac.uk by sirius.brunel.ac.uk with SMTP (PP) id <08728-0@sirius.brunel.ac.uk>; Fri, 18 Nov 1994 17:25:40 +0000 From: Andrew Findlay Message-Id: <2411.9411181725@pluto.brunel.ac.uk> Subject: Mbone lecture on Video Compression To: rem-conf@es.net Date: Fri, 18 Nov 1994 17:25:36 +0000 (GMT) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1880 Mbone Broadcast in the UK: ========================== Video Compression for Digital Networks Ian Wakeman (University College London) Mark Handley (University College London) Thursday 24th November 1994, 19:30 GMT Broadcast from: Room 214, Computer Science, University College London, Gower Street AND Lecture Theatre E, Brunel University, Uxbridge The use of packet switched networks to carry video will be discussed, with particular reference to the various compression schemes available and how they need to be modified to work over a packet network subject to variable delay, congestion and loss. Live demonstrations are planned, using the SuperJANET network. Ian Wakeman will be at Brunel, with an audience from the Institution of Electrical Engineers. Mark Handley will be at UCL, with an audience >from the London Unix User Group. Some of the demonstrations will involve video sent over SuperJANET. Sound and video will be relayed between the two lecture rooms over the network. It may be possible to arrange for groups to view the lecture at other UK universities and research locations. Other mbone sites are welcome to participate, though we may not be able to take questions from everywhere! Organisers: IEE Thames Valley Specialised Section on Electronics Computing Communication and Control IEE Professional Group C14 (Information Technology) London Unix User Group Taking part: Watch for announcements in `sd' on Thursday. Due to the amount of video bandwidth required for the demos this event will be limited to the UK mbone only. ---------------------------------------------------------------------------- | From Andrew Findlay at Brunel University, Uxbridge, UB8 3PH, UK | | Andrew.Findlay@brunel.ac.uk +44 1895 203066 or +44 1895 274000 x2512 | ---------------------------------------------------------------------------- From rem-conf-request@es.net Fri Nov 18 13:24:48 1994 Received: from nps.navy.mil by osi-west.es.net via ESnet SMTP service id <07040-0@osi-west.es.net>; Fri, 18 Nov 1994 10:24:22 +0000 Received: by nps.navy.mil (4.1/SMI-4.1) id AA19043; Fri, 18 Nov 94 10:23:00 PST From: kcohan@mpusd.K12.CA.US Original-Received: from cc:Mail by mpusd.K12.CA.US id AA785181975 Fri, 18 Nov 94 10:06:16 PP-warning: Illegal Received field on preceding line Date: Fri, 18 Nov 94 10:06:16 Encoding: 365 Text Message-Id: <9410187851.AA785181975@mpusd.K12.CA.US> To: rem-conf@es.net Subject: holography web MBONE birthday update The story of how we did the first holography lecture on the MBONE will be up on our birthday web page starting late this afternoon. This web page will be updated with images and sounds from tommrrows birthday party. Hope you'll join us. url: http://www.sp.nps.navy.mil/kim/kim.html Kim Cohan From rem-conf-request@es.net Fri Nov 18 14:50:29 1994 Received: from 134.167.4.10 by osi-west.es.net via ESnet SMTP service id <07818-0@osi-west.es.net>; Fri, 18 Nov 1994 11:49:54 +0000 Received: (from lpz@localhost) by nautique.epm.ornl.gov (8.6.8/8.6.6) id OAA01080; Fri, 18 Nov 1994 14:49:09 -0500 Date: Fri, 18 Nov 1994 14:49:08 -0500 (EST) From: "Lawrence MacIntyre - 615.576.0824" Subject: Re: nv on DEC Alpha To: Lucia Gradinariu cc: rem-conf@es.net In-Reply-To: <199411181331.OAA27662@cismsun.univ-lyon1.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 18 Nov 1994, Lucia Gradinariu wrote: > Has anybody experienced nv-3.3beta on a DEC Alph. with J300? > I can't get it recognize the J300 a-v board as grabber (it > recognize only X11). Available via anonymous ftp from ludwig.ctd.ornl.gov:nv-j300-osf1-2.0 Lawrence ~ ------------------------------------------------------------------------------- lpz@nautique.epm.ornl.gov Lawrence MacIntyre lpz@ornl.gov Oak Ridge National Laboratory 615.574.8696 From rem-conf-request@es.net Fri Nov 18 15:28:41 1994 Received: from d1.ph.gla.ac.uk by osi-west.es.net via ESnet SMTP service id <08112-0@osi-west.es.net>; Fri, 18 Nov 1994 12:27:54 +0000 Received: by d1.ph.gla.ac.uk (5.57/Ultrix3.0-C) id AA05616; Fri, 18 Nov 94 20:28:26 GMT Date: Fri, 18 Nov 1994 20:26:15 +0000 (WET) From: "Alan J. Flavell" Subject: Re: nv on DEC Alpha To: Lucia Gradinariu Cc: rem-conf@es.net In-Reply-To: <199411181331.OAA27662@cismsun.univ-lyon1.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 18 Nov 1994, Lucia Gradinariu wrote: > Has anybody experienced nv-3.3beta on a DEC Alph. with J300? > I can't get it recognize the J300 a-v board as grabber (it > recognize only X11). If I remember correctly, the version of the executable that we run on our ALPHA has been built so that it does not make calls to the library for the J300. This is for people who have not got a J300 board and therefore have not got the library. If my mistake you have this version of the executable, that would explain why it can only do X11 grab. Apologies if this is the wrong answer. From rem-conf-request@es.net Fri Nov 18 16:04:16 1994 Received: from algol.cs.umbc.edu by osi-west.es.net via ESnet SMTP service id <08389-0@osi-west.es.net>; Fri, 18 Nov 1994 13:03:39 +0000 Received: from topdog.cs.umbc.edu (lw@topdog.cs.umbc.edu [130.85.100.62]) by algol.cs.umbc.edu (8.6.9/8.6.9) with ESMTP id QAA17263 for ; Fri, 18 Nov 1994 16:03:36 -0500 From: "Dr. Wei Liu" Received: (lw@localhost) by topdog.cs.umbc.edu (8.6.9/8.6.9) id QAA15036 for rem-conf@es.net; Fri, 18 Nov 1994 16:03:35 -0500 Date: Fri, 18 Nov 1994 16:03:35 -0500 Message-Id: <199411182103.QAA15036@topdog.cs.umbc.edu> To: rem-conf@es.net Subject: Mbone I am interested in subscribing/booking the broadcast session on Information Superhighway, 23/11/94 02:00 - 04:00 Could you tell me how to receive the broadcast in my workstation? Thank you. W. Liu From rem-conf-request@es.net Fri Nov 18 16:13:21 1994 Received: from algol.cs.umbc.edu by osi-west.es.net via ESnet SMTP service id <08478-0@osi-west.es.net>; Fri, 18 Nov 1994 13:12:31 +0000 Received: from topdog.cs.umbc.edu (lw@topdog.cs.umbc.edu [130.85.100.62]) by algol.cs.umbc.edu (8.6.9/8.6.9) with ESMTP id QAA17385; Fri, 18 Nov 1994 16:12:28 -0500 From: "Dr. Wei Liu" Received: (lw@localhost) by topdog.cs.umbc.edu (8.6.9/8.6.9) id QAA15114; Fri, 18 Nov 1994 16:12:27 -0500 Date: Fri, 18 Nov 1994 16:12:27 -0500 Message-Id: <199411182112.QAA15114@topdog.cs.umbc.edu> To: calegari@imicilea.cilea.it Subject: Correction Cc: rem-conf@es.net I made a mistake in booking the time-slot for 23/11/94 02:00-04:00. Please cancel it. Sorry for any inconvenience. What I need is to subscribe the broadcast of that session. Could you advice on how to receice the broadcast for that session? Thanks, W. Liu (lw@cs.umbc.edu) From rem-conf-request@es.net Fri Nov 18 20:11:05 1994 Received: from std.sri.com by osi-west.es.net via ESnet SMTP service id <10229-0@osi-west.es.net>; Fri, 18 Nov 1994 17:10:37 +0000 Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1) id AA20342; Fri, 18 Nov 94 17:02:03 PST Message-Id: <9411190102.AA20342@std.sri.com> To: confctrl@isi.edu, rem-conf@es.net Cc: rlang@std.sri.com Subject: MMUSIC meeting and Session Control Surveys Date: Fri, 18 Nov 1994 17:02:06 -0800 From: Ruth Lang Today I received email from Megan Walnut stating that a room large enough for the MMUSIC meeting is not available Thursday 9:30a - noon. We are coordinating with Megan on the room availability, and Allison Mankin on her schedule in order to choose another time. Please stay tuned. I will send email as soon as the meeting has an official time slot. Keep those survey response forms coming! Two completed surveys (CCCP and SRI) are in both ftp://venera.isi.edu/confctrl/surveys and ftp://ws11.std.sri.com/pub/confctrl/surveys. Feel free to take a look at them as you put together your response which will be key in helping us form requirements for both a general session description and control protocol. Regards, Ruth From rem-conf-request@es.net Fri Nov 18 23:42:24 1994 Received: from wdl1.wdl.loral.com by osi-west.es.net via ESnet SMTP service id <10956-0@osi-west.es.net>; Fri, 18 Nov 1994 20:41:54 +0000 Received: from spl1.spl.loral.com by wdl1.wdl.loral.com (4.1/WDL-4.2) id AA29074; Fri, 18 Nov 94 20:41:43 PST Received: from [137.249.41.42] (spl42) by spl1.spl.loral.com (4.1/SPL-SUN-2.05) id AA15174; Fri, 18 Nov 94 20:41:35 PST Message-Id: <9411190441.AA15174@spl1.spl.loral.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Nov 1994 20:31:31 -0800 To: rem-conf@es.net, CU-SEEME-L@cornell.edu From: rsn@spl1.spl.loral.com (Richard Neale) Subject: Stones Well... How was it? Any net stats available? -------------------------------------------------------------- Richard Neale Loral Corp rsn@spl1.spl.loral.com 3200 Zanker Rd http://spl42.spl.loral.com Mailstop: C01 Software Productivity Lab San Jose CA 95161-9041 Voice: (408) 473-4555 Fax: (408) 473-7131 From rem-conf-request@es.net Sun Nov 20 11:31:04 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <17442-0@osi-west.es.net>; Sun, 20 Nov 1994 08:30:33 +0000 Received: from muridae.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 20 Nov 1994 16:30:18 +0000 To: rem-conf@es.net Subject: ArtAIDS event - initial announcement. Date: Sun, 20 Nov 94 16:29:52 +0000 From: Gordon Joly We plan to launch ArtAIDS in support of AIDS charities (Crusaid in the UK) on the MBONE on Monday 28 November at 18:00 UTC. There will be artists taking part in the UK, Sweden, Belgium, Germany, Australia and the USA. An entry will be made in "sd". During this open meeting, digital art will be discussed and plans for the next twelve months of the ArtAIDS project, including AIDS awareness issues, will be outlined. The project launch was timed to be a few days before World AIDS Day (1 December). See "The ArtAIDS Project" URL at http://artaids.dcs.qmw.ac.uk:8001/ for more details and some examples of work already submitted to the ArtAIDS gallery. All new information will be placed there. The URL will also be used during the discussion to enable the audience to view the pieces. Gordon Joly Email: G.Joly@cs.ucl.ac.uk +441713807934 FAX +441713871397 Computer Science, University College London, Gower St., LONDON WC1E 6BT http://www.cs.ucl.ac.uk/people/gordo/ http://artaids.dcs.qmw.ac.uk:8001/ From rem-conf-request@es.net Sun Nov 20 15:57:02 1994 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <11971-0@osi-east.es.net>; Sun, 20 Nov 1994 12:56:40 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA10309; Sun, 20 Nov 94 12:56:38 PST Date: Sun, 20 Nov 94 12:56:38 PST From: ari@es.net (Ari Ollikainen) Message-Id: <9411202056.AA10309@viipuri.nersc.gov> To: rem-conf@es.net Subject: MPEG-2 effort reaches International Standard (Press Release) --------Begin forwarded message----------------- From: cfogg@netcom.com (Chad Fogg) Subject: MPEG-2 effort reaches International Standard (Press Release) Organization: ISO/IEC JTC1/SC29 WG11 ("MPEG") Date: Sat, 19 Nov 1994 15:14:53 GMT ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND ASSOCIATED AUDIO ISO/IEC JTC1/SC29/WG11 N0822 MPEG 94/ 11 November 1994 Source: Leonardo Chiariglione - Convenor Title: Press release Status: Approved at 29th meeting Press Release Summary: The 29th meeting of ISO/IEC JTC1/SC29/WG11 (MPEG) was held in Singapore this week, hosted by the National Computer Board and the National IT Standards Committee (Singapore). The results achieved at this meeting include: the final approval of part 4 of ISO/IEC 11172-4 (MPEG-1 Conformance Testing) as International Standard (IS); the promotion of ISO/IEC 11172-5 (Software for MPEG-1 coding) to Draft International Standard (DIS) status; the final approval of ISO/IEC 13818-1 (MPEG-2 Systems), ISO/IEC 13818-2 (MPEG-2 Video) and ISO/IEC 13818-3 (MPEG-2 Audio) as IS; the production of the Working Draft of the DSM-CC (Digital Storage Media Command and Control) extension; and the issuing of a Call for Proposals for MPEG-4, the next item of work. The approval of MPEG-2 for publication as an international standard constitutes an important milestone in international standardization that will make possible the establishment of interoperable digital audio-visual services and applications on a world-wide scale while making sure that international standardisation of digital audio-visual matters will not be overtaken by the progression of technology. The continuing work will ensure continued responsiveness to the needs of the digital audio-visual community. Systems: This week saw the promotion of the Draft International Standard 13818-1, better known as "MPEG-2 Systems" to IS status. This part of the MPEG-2 standard provides for the multiplex and synchronisation of multiple audio, video, and data streams. MPEG-2 Systems will form the infrastructure for delivery of audio and video information in many industry sectors, including television distribution, visual telecommunications, and a host of computer and multimedia applications. MPEG-2 Systems specifies two syntaxes, the Transport Stream and the Program Stream, each designed for different applications. Both syntaxes offer a wide range of functions and capabilities. In addition to multiplexing, a major feature is the accurate synchronisation of audio, video, and data for correct presentation at the decoder. The standard addresses the management of buffers at the decoder. Additional functions include random access, identification of information carried within the stream, procedures to support user access control, and error protection mechanisms. Contribution to the development of the MPEG-2 Systems standard has come >from many different industry groups, representing the wide range of interest in the standard. ITU-T Study Group 15 has also participated in the development of the standard and the ITU-T will adopt MPEG-2 Systems as ITU-T Recommendation H.222.1, as part of its Broadband-ISDN audio visual telecommunications terminal. With new transmission technologies allowing high bandwidth connections, and switching technologies such as ATM, MPEG-2 Systems will form the basis of new audio and visual services applications for many years to come. Digital Storage Command and Control: The Working Draft of the Digital Storage Media Command and Control (DSM-CC) extension was also completed this week. This standard will facilitate the interoperability of MPEG applications and equipment by providing a common command and control interface. An example application is the control of remote video servers from home based terminals. A Committee Draft (CD) of the DSM-CC Extension is scheduled for March 1995 and International Standard in November 1995. A requirements document on a multimedia scripting language was also produced. The standard will be developed together with the Multimedia and Hypermedia Experts Group (MHEG), a parallel committee within JTC1/SC29. The language is an important element for the rapid introduction of stand-alone and networked interactive multimedia applications and services. Real Time Interface: Part 9 of ISO/IEC 13818 is the Real Time Interface (RTI), an extension of the MPEG-2 Systems standard defining a common interface point to which terminal equipment manufacturers and network operators can design. RTI specifies a delivery model for the bytes of an MPEG-2 Systems stream at the input of a real decoder, while MPEG-2 Systems defines an idealised byte delivery schedule. Part 9 was promoted to Working Draft (WD) status at this week's Singapore meeting. It is expected to become an International Standard in November 1995. Video: The standard 13818-2, better known as 'MPEG-2 Video' was promoted from DIS to IS status. The standard provides for the digital coding of video at various data rates from about 1.5 Mbit/s to in excess of 60 Mbit/s, enabling a common technology to be adopted for many applications ranging from home entertainment quality video up to HDTV. Subsets of the total video standard known as profiles have been defined to assist in interchange of coded video data between these various applications. Early adopters of this standard include pay-TV cable and satellite broadcasters as well as the emerging interactive 'Video on Demand' market, for which the 'Main Profile' is identified as the most suitable. Other profiles support layered coding techniques suitable for terrestrial broadcasting and IT environments. MPEG-2 Video has been developed jointly with ITU-T SG 15 and will be adopted by that Standards Body as Recommendation H.262. 10 bit video and new profiles: The need to extend the MPEG-2 tools and provide support of efficient bitrate reduction for high-quality video signals quantised with 10 bits, such as those used in the studio, has been recognised and a Call for Proposals has been issued in July 1994. The deadline for submissions is March 1995, but a number of companies have already stated their intention to make proposals. At this meeting another range of applications which may take benefit from the MPEG technology has been identified regarding compression coding of non-chroma-subsampled ordinary video signals at bitrates up to 50 Mbit/s. While many of the committee members are confident that the MPEG coding tools can be successfully applied at these high bitrates, the very demanding performance required by the mentioned applications has prompted MPEG to establish an ad-hoc group with the mandate of providing technical evidence to be submitted at the 30th MPEG meeting in March 1995. The successful outcome of the work of the ad-hoc group will enable MPEG to make a decision on this important extension of its current work. Video Quality Verification Test: MPEG has put considerable efforts into evaluating the quality obtained by the application of its standards to video information sources. This evaluation has been made on various MPEG-2 video profiles for TV and HDTV. A first set of results, obtained as early as March through a set of test video sequences, proved that MPEG-2 Video at 9 Mbit/s coding provides near transparent quality while at 6 Mbit/s the quality equals or exceeds that of conventional TV systems. At lower bit rates, such as 4 Mbit/s high quality pictures will be obtained on most picture material. Expert viewing tests were also carried out on the "Spatially Scalable Profile at H14", a profile for 1440 line HDTV. This profile defines layered coding techniques used to generate a base layer bitstream with an enhancement layer bitstream used to create a higher resolution image. The layered coding allows simultaneous reception of an HDTV signal by both HDTV and standard resolution TV receivers. Initial results seem to indicate that the high layer satisfies the required quality for HDTV at 36 Mbit/s. The quality of the base layer, using 9 of the 36 Mbit/s, is high enough for normal TV broadcasting; it is however not sufficient for an HDTV 'fall back solution', which could occur in the case of bad reception conditions. More tests are planned for testing MPEG-2's "Main Profile" for HDTV use at bitrates of 18, 30 and 45 Mbit/s. Taking into account the intended use of these profiles, the tests will be carried out with video and movie material. Audio: The multichannel MPEG-2 Audio coding system (IS13818-3) has been promoted to IS status during the Singapore meeting. This standard supports the extension of the MPEG-1 Audio compression standard (ISO/IEC 11172-3) to multichannel (up to 5 channels). It also supports the extensions of the MPEG-1 Audio compression standard to lower sampling frequencies and lower bitrates. These extensions have proven to outperform conventional speech codecs at the same rates. Use of the MPEG-2 Audio standard will be further promoted through continuing work on improvements in quality, largely dependent on encoder optimisation, and the distribution of reference software and compressed multichannel audio sequences over the Internet. MPEG is also working on the development of a multichannel audio coding standard that is not backward compatible to MPEG-1 Audio but still part of the MPEG-2 standard. A Call for Proposals was issued in July 1994 and twelve companies have already responded presenting an outline of their intended proposals. Detailed proposals will be presented at the next MPEG meeting (March '95), but the collaboration among the proposers has already started in Singapore using a common reference model. MPEG-4: In its MPEG-4 phase of work MPEG will develop an audio-visual coding standard with new functionalities, such as support for manipulation of the content of audio-visual data, that will find application in diverse areas such as entertainment, distance learning, remote monitoring, and home shopping. Thus continuous improvement in performance of coding is necessary. To provide this capability, MPEG-4 will develop a flexible syntactic descriptive language, and a number of audio-visual coding tools. This approach will provide the ability for decoders to use a rich set of algorithms according to the content or applications. Software implementations of MPEG standards: The full software implementation of the three parts of MPEG-1, contained in part 5 of MPEG-1, was promoted to Draft Technical Report status at this meeting. The software is an aid to implementors and novices providing an example encoder and decoder for Systems, Video, and Audio. This software has also a wide domain of applicability thanks to the ever increasing processing capability of computers that promise to make possible software implementation of the standard under certain conditions. The same work is also being carried out for MPEG-2: a technical report for MPEG-2 Video, including reference software for coding and decoding, was approved for balloting as Proposed Draft Technical Report 13818-5. Conformance testing: The work on MPEG-1 conformance testing was closed at this meeting. This part of MPEG-1 guarantees the quality of MPEG-1 products, and helps to make sure that they conform to the standard. The work on MPEG-2 Conformance is at an advanced stage of development: the conformance document was reviewed and approved as CD 13818-4 and submitted for balloting. Technical note: MPEG is the nickname of an ISO working group. As such it is assigned work items and produces standards. Therefore there is no such thing as an "MPEG-2 committee". This is the full list of work items 11172 (MPEG-1) Coding of moving pictures and associate audio for digital storage media at up to about 1.5 Mbit/s IS date (Year/Month) Part 1 Systems 92/11 Part 2 Video 92/11 Part 3 Audio 92/11 Part 4 Conformance testing 94/11 Part 5 Simulation software 95/03 13818 (MPEG-2) Generic coding of moving pictures and associated audio Part 1 Systems 94/11 Part 2 Video 94/11 Part 3 Audio 94/11 Part 4 Conformance testing 95/07 Part 5 Simulation software 95/07 Part 6 Digital storage media command and control 95/09 Part 7 Non-backwards compatible audio 97/03 Part 8 10 bit video 96/07 Part 9 Real-time interface 95/11 14496 (MPEG-4) Very low bitrate audio-visual coding Part 1 Systems 98/11 Part 2 Video 98/11 Part 3 Audio 98/11 ---- End of MPEG November 11, 1994 Press Release document WG11 N0822 From rem-conf-request@es.net Mon Nov 21 07:20:05 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <21917-0@osi-west.es.net>; Mon, 21 Nov 1994 04:19:32 +0000 Received: from muridae.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 21 Nov 1994 12:18:54 +0000 To: rem-conf@es.net Subject: MICE International Seminars. Date: Mon, 21 Nov 94 12:18:29 +0000 From: Gordon Joly The next MICE seminar will be held at 14:00 UTC (and will finish at appoximately 16:00 UTC). An entry will be made in "sd", on the usual address of 224.5.17.12. We will use vat, wb, and ivs for video. In general, information on the MICE seminars kept up to date in the URL http://www.cs.ucl.ac.uk/mice/seminars/ ******************************** Tone Bratteteig, Institute for Informatics, University of Oslo. http://www.ifi.uio.no/~tone/ Title: The Unbearable Lightness of Using Groupware Abstract: Badly planned implementation of groupware may enhance some of the problematic consequences that we know from traditional computer systems, eg, changes in the distribution of knowledge and professional status. A study of nine Norwegian organisations using Lotus Notes illustrates this. Groupware can be seen as a "work tool" for several organisational levels. However, the cooperative work actually carried out in an organisation is not always met by the functionality offered by the groupware. Successful implementation of groupware requires careful consideration of several organisational levels and of the relations between them. Discussant: Paul Dourish, Department of Computer Science. UCL. ******************************** Gordon Joly http://www.cs.ucl.ac.uk/people/gordo/ Tel +44171 3807934 Email G.Joly@cs.ucl.ac.uk Home: gordo@dircon.co.uk FAX +44171 3871397 Comp Sci, University College London, Gower Street, LONDON WC1E 6BT From rem-conf-request@es.net Mon Nov 21 09:09:20 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <22361-0@osi-west.es.net>; Mon, 21 Nov 1994 06:07:15 +0000 Received: from muridae.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 21 Nov 1994 14:06:43 +0000 To: rem-conf@es.net Subject: Re: MICE International Seminars. Date: Mon, 21 Nov 94 14:06:19 +0000 From: Gordon Joly The date being 29th November, 1994. >> The next MICE seminar will be held at 14:00 UTC (and will finish at >> appoximately 16:00 UTC). An entry will be made in "sd", on the usual >> address of 224.5.17.12. We will use vat, wb, and ivs for video. In >> general, information on the MICE seminars kept up to date in the URL >> http://www.cs.ucl.ac.uk/mice/seminars/ Gordon Joly Email: G.Joly@cs.ucl.ac.uk +441713807934 FAX +441713871397 Computer Science, University College London, Gower St., LONDON WC1E 6BT http://www.cs.ucl.ac.uk/people/gordo/ http://artaids.dcs.qmw.ac.uk:8001/ From rem-conf-request@es.net Mon Nov 21 11:49:28 1994 Received: from imicilea.cilea.it by osi-west.es.net via ESnet SMTP service id <23571-0@osi-west.es.net>; Mon, 21 Nov 1994 08:48:58 +0000 Received: from [131.175.1.95] by IMICILEA.CILEA.IT (IBM VM SMTP V2R2) with TCP; Mon, 21 Nov 94 17:43:55 MET X-Sender: calegari@imicilea Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 21 Nov 1994 18:48:43 +0200 To: rem-conf@es.net From: calegari@cilea.it (Antonio Calegari) Subject: MBone Agenda - Update The MBone Agenda Nov 94 See: http://www.cilea.it/MBone/agenda.html ------------------------------------------------------------------------ All times are given in GMT. ------------------------------------------------------------------------ 15-Nov 22:00 17-Nov 22:00 Supercomputing '94 Contact: Steve Elbert (elbert@ameslab.gov) The conference schedule is available at http://sc94.ameslab.gov/AP/glance.html (times are eastern). The Keynote Address and Plenary Sessions will be multicast. ------------------------------------------------------------------------ 18-Nov 03:00 18-Nov 06:00 BayLISA meeting: Jonny Goldman on gateways and proxies for H Contact: blw@baylisa.org or deleon@hpl.hp.com The broadcast will be from 7:30-10:00 PDT Nov 17, 1994 ------------------------------------------------------------------------ 19-Nov 03:00 19-Nov 04:00 Rolling Stones: Live Concert from Dallas Contact: multicast@thinkpix.com Will be from 8pm to 9pm USA CST on Nov 18th (in the USA) ------------------------------------------------------------------------ 22-Nov 13:00 22-Nov 14:00 Rolling Stones: Concert from Dallas Contact: multicast@thinkpix.com Not live ------------------------------------------------------------------------ 23-Nov 02:00 23-Nov 04:00 El Naftazteca: Information Superhighway Bendito Contact: stewart@rpi.edu or djwap@rpi.edu 90-minute live television event with Guillermo Gomez-Pena 21:00-22:30 EST ------------------------------------------------------------------------ 23-Nov 02:00 23-Nov 04:00 Information Superhighway Contact: lw@cs.umbc.edu ------------------------------------------------------------------------ 24-Nov 01:00 24-Nov 02:00 Rolling Stones: Concert from Dallas Contact: multicast@thinkpix.com Not live ------------------------------------------------------------------------ 27-Nov 08:00 27-Nov 15:00 Epic multimedia event Contact: richard@rmit.edu.au Television event ------------------------------------------------------------------------ 29-Nov 14:00 29-Nov 16:00 MICE: The Unbearable Lightness of Using Groupware Contact: Gordon Joly - G.Joly@cs.ucl.ac.uk See also: http://www.cs.ucl.ac.uk/mice/seminars/ ------------------------------------------------------------------------ ------------------------------------------------------------------------ calegari@imicilea.cilea.it ------------------------------------------------------------------------- Antonio Calegari CILEA - Segrate - Milan tel. : +39 (0)2 26995 257 Interuniversity Computing Centre email: calegari@icil64.cilea.it ITALY From rem-conf-request@es.net Mon Nov 21 16:04:11 1994 Received: from swan.cl.cam.ac.uk by osi-west.es.net via ESnet SMTP service id <25955-0@osi-west.es.net>; Mon, 21 Nov 1994 13:03:32 +0000 Received: from swan.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Mon, 21 Nov 1994 21:03:23 +0000 To: rem-conf@es.net, mbone@ISI.EDU Cc: Piete.Brooks@cl.cam.ac.uk Reply-To: Piete.Brooks@cl.cam.ac.uk Subject: Mbone transmission 94/11/23 16:15-17:15 UTC (cl.cam.ac.uk Seminar) Date: Mon, 21 Nov 1994 21:03:18 +0000 From: Piete Brooks Message-ID: <"swan.cl.cam.:080840:941121210326"@cl.cam.ac.uk> This week's seminar will be trasnmitted at TTL 31 -- i.e. just within JIPS (ac.uk) -- unless anyone wants the TTL raised. If so, please let me know your nearest mrouted, and whether you want just the audio, or audio and video. The video will just be of the speaker (slides will **ONLY** be available via the WWW -- not on the video feed), apart from one clip from a VCR. We had hoped to get this in the WWW as MPEG, but have not yet managed so to do. As such, if requested, we might raise the nv TTL during the VCR clip. [ We still have to receive the Postscript of the slides ] NAME: Dr Richard Connor, University of St Andrews DATE: Wednesday 23rd November 1994 at 4.15pm (16:15 UTC) PLACE: Babbage Lecture Theatre TITLE: Persistence, HyperProgramming and Beyond Orthogonal persistence means that values manipulated by a programming language are treated independently of the length of time of their existence. The immediate benefits of persistence are a reduction in code size and complexity, achieved by the elision of any code necessary to translate data between traditional long and short-term environments. Within an integrated persistent system, however, further benefits are possible. Direct bindings are possible between source code and other values within the persistent space, allowing statically typed programs in the format of hyper-text. A prototype hyper-programming system has been constructed by the persistence research group at St Andrews University; the seminar will demonstrate some of the advantages of this new programming paradigm. This seminar will be multicast (audio and video) on the mbone as part of our multimedia test programme. Further information is available at http://www.cl.cam.ac.uk/mbone/#cl. From rem-conf-request@es.net Tue Nov 22 17:31:51 1994 Received: from feijao.cs.pitt.edu by osi-west.es.net via ESnet SMTP service id <06820-0@osi-west.es.net>; Tue, 22 Nov 1994 14:31:26 +0000 Received: (ghosh@localhost) by feijao.cs.pitt.edu (8.6.9/8.6.5) id RAA11590 for rem-conf@es.net; Tue, 22 Nov 1994 17:31:24 -0500 From: Sunondo Ghosh Message-Id: <199411222231.RAA11590@feijao.cs.pitt.edu> Subject: To: rem-conf@es.net Date: Tue, 22 Nov 1994 17:31:24 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1 From rem-conf-request@es.net Tue Nov 22 19:17:05 1994 Received: from relay.nswc.navy.mil by osi-west.es.net via ESnet SMTP service id <07594-0@osi-west.es.net>; Tue, 22 Nov 1994 16:16:40 +0000 Received: from sunoco (sunoco.nswc.navy.mil) by relay.nswc.navy.mil (4.1/SMI-4.1) id AA02142; Tue, 22 Nov 94 19:16:28 EST Received: from vaxless by sunoco (5.0/SMI-SVR4) id AA03248; Tue, 22 Nov 1994 19:16:28 +0500 Received: by vaxless (5.0/SMI-SVR4) id AA06636; Tue, 22 Nov 1994 19:16:27 +0500 Date: Tue, 22 Nov 1994 19:16:27 +0500 From: pirey@relay.nswc.navy.mil (Phil Irey) Message-Id: <9411230016.AA06636@vaxless> To: mbone@isi.edu, rem-conf@es.net Subject: Multicast support for DEC FDDI board on Ultrix 4.x? X-Sun-Charset: US-ASCII Content-Length: 164 Hi, Does anyone know of any drivers for the DEC FDDI board (fta0) that supports IP multicast? I am assuming that some mods are needed to if_fta.o. thanks, phil From rem-conf-request@es.net Tue Nov 22 19:40:04 1994 Received: from std.sri.com by osi-west.es.net via ESnet SMTP service id <07844-0@osi-west.es.net>; Tue, 22 Nov 1994 16:39:21 +0000 Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1) id AA18815; Tue, 22 Nov 94 16:30:15 PST Message-Id: <9411230030.AA18815@std.sri.com> To: confctrl@isi.edu, rem-conf@es.net Cc: tfrivold@std.sri.com, rlang@std.sri.com Subject: MMUSIC has been scheduled Date: Tue, 22 Nov 1994 16:30:17 -0800 From: Ruth Lang for Wednesday, December 7, 16:00 - 18:00. We plan to distribute a draft agenda tomorrow (Wednesday). Please contact me if you would like to make a presentation. Ruth p.s. This session will be multicast. From rem-conf-request@es.net Wed Nov 23 12:14:35 1994 Received: from cismsun.univ-lyon1.fr by osi-west.es.net via ESnet SMTP service id <12966-0@osi-west.es.net>; Wed, 23 Nov 1994 09:14:10 +0000 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.9/8.6.6) id SAA05226; Wed, 23 Nov 1994 18:14:02 +0100 Message-Id: <199411231714.SAA05226@cismsun.univ-lyon1.fr> Subject: Re: nv on DEC Alpha To: lpz@nautique.epm.ornl.gov (Lawrence MacIntyre - 615.576.0824) Date: Wed, 23 Nov 1994 18:14:00 +0100 (MET) From: Lucia Gradinariu Cc: rem-conf@es.net In-Reply-To: from "Lawrence MacIntyre - 615.576.0824" at Nov 18, 94 08:00:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1085 > > > mme is Digital's version of the mmeserver (from microsquish). You have > to buy it to get the library. They HAVE a regular driver, which nv > supports also, but they won't distribute it. I'm told that the > performance with the driver is much better than with the server, but then > digital is a marketing company, not an engineering company, so they > apparently don't care. Anyway, my binary won't do you any good if you > haven't purchased the mmeserver. The without mme selection is for the > driver. Maybe Ron can clarify or maybe the driver is available now. I > don't know. You may have noticed the other version of nv for the alpha > that was on ludwig, that's the one without mme. > > Lawrence > ~ > ------------------------------------------------------------------------------- Dec's driver for J300 Sound&Motion board is available on http://chocolate.pa.dec.com/mbone/j300.tar.Z (jv2driver) and it works very nice with nv3.3. Thanks to berc@pa.dec.com. lucia@univ-lyon1.fr From rem-conf-request@es.net Wed Nov 23 12:32:04 1994 Received: from cismsun.univ-lyon1.fr by osi-west.es.net via ESnet SMTP service id <13073-0@osi-west.es.net>; Wed, 23 Nov 1994 09:31:30 +0000 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.9/8.6.6) id SAA05828 for rem-conf@es.net; Wed, 23 Nov 1994 18:31:23 +0100 Message-Id: <199411231731.SAA05828@cismsun.univ-lyon1.fr> Subject: vat & AF To: rem-conf@es.net Date: Wed, 23 Nov 1994 18:31:21 +0100 (MET) From: Lucia Gradinariu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 371 Hi, I'm runnig vat between two stations (SS20/Sol2.3 and DecAlph. OSF/1V2.1) and I can't see the Dec station in vat's window on Sun. I have started the AF server (Aj300) on Dec but I don't use AF on the Sun (I dont't think this could be the problem, could it?). I see/hear the Sun on the Dec but not vice-versa. Some hints? Thanks, Lucia.Gradinariu@univ-lyon1.fr From rem-conf-request@es.net Wed Nov 23 17:13:46 1994 Received: from std.sri.com by osi-west.es.net via ESnet SMTP service id <16159-0@osi-west.es.net>; Wed, 23 Nov 1994 14:13:22 +0000 Received: from churchy (churchy.std.sri.com) by std.sri.com (4.1/SMI-4.1) id AA22234; Wed, 23 Nov 94 14:04:28 PST Date: Wed, 23 Nov 94 14:04:28 PST From: rlang@std.sri.com (Ruth Lang) Message-Id: <9411232204.AA22234@std.sri.com> Received: by churchy (4.1/SMI-4.1) id AA26663; Wed, 23 Nov 94 14:04:26 PST To: confctrl@isi.edu, rem-conf@es.net Cc: tfrivold@std.sri.com, rlang@std.sri.com Subject: MMUSIC Draft Agenda Folks, Enclosed is a draft agenda for the upcoming MMUSIC meeting. The first hour will focus on presentations of related and ongoing work. Joerg, Abel, and Ted: please send email to the group indicating what documents are relevant as background reading material for your presentations. The emphasis of the second hour will be on directed discussion. I.e., come with your opinions and be prepared to speak up! As background for the 4th agenda item, review survey responses available at ftp://venera.isi.edu/confctrl/surveys and ftp://ws11.std.sri.com/pub/confctrl/surveys. In preparation for the last agenda item, please obtain the working group charter and review it. The "Goals and Milestones" section is out of date. What work and associated documents do you think this group should do/produce? What can you commit to working on? Discussion in advance of the meeting is welcome. Please send comments on the agenda or in general to confctrl@isi.edu. Regards, Ruth ----------------------------------------------------------- MMUSIC Working Group Meeting Wednesday, December 7, 1994 16:00-18:00 16:00-16:05 Meeting Overview and Agenda Review (Ruth Lang, SRI) 16:05-16:15 ITU Generic Conference Control Update (Joerg Ott, Technical University of Berlin) 16:15-17:00 Progress on Agreement Protocol (Abel Weinrib, Intel and Ted Ko, MIT/Bellcore) 17:00-17:20 Session Protocol Functional Requirements and Survey Report (Thane Frivold, SRI and Ruth Lang, SRI) 17:20-17:45 Session Description Functional Requirements (Mark Handley, UCL, Thane Frivold, SRI, and Ruth Lang, SRI) 17:45-18:00 Discussion of Working Group Direction and Charter Modification (Thane Frivold, SRI and Ruth Lang, SRI) From rem-conf-request@es.net Wed Nov 23 18:21:23 1994 Received: from icsia.ICSI.Berkeley.EDU by osi-west.es.net via ESnet SMTP service id <16756-0@osi-west.es.net>; Wed, 23 Nov 1994 15:20:55 +0000 Received: from icsib77 (whd@icsib77.ICSI.Berkeley.EDU [128.32.201.203]) by icsia.ICSI.Berkeley.EDU (8.6.8/HUB+V8$Revision: 1.21 $) with ESMTP id PAA27328; Wed, 23 Nov 1994 15:20:52 -0800 From: whd@ICSI.Berkeley.EDU (Wieland Holfelder) Received: (whd@localhost) by icsib77 (8.6.8/1.8) id PAA07393; Wed, 23 Nov 1994 15:20:48 -0800 Message-Id: <199411232320.PAA07393@icsib77> Subject: Re: vat & AF To: lucia@univ-lyon1.fr (Lucia Gradinariu) Date: Wed, 23 Nov 1994 15:20:47 -0800 (PST) Cc: rem-conf@es.net (Remote Conferencing) In-Reply-To: <199411231731.SAA05828@cismsun.univ-lyon1.fr> from "Lucia Gradinariu" at Nov 23, 94 06:31:21 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 968 Lucia Gradinariu writes: > Hi, > > I'm runnig vat between two stations (SS20/Sol2.3 and DecAlph. OSF/1V2.1) > and I can't see the Dec station in vat's window on Sun. I have started > the AF server (Aj300) on Dec but I don't use AF on the Sun (I dont't > think this could be the problem, could it?). I see/hear the Sun on the > Dec but not vice-versa. > > Some hints? Given you run the two vat in unicast-mode then your problem might be due to a bug in Solaris. If so, look at ftp://playground.sun.com/pub/solaris2/unicast-vat-workaround.tar -- Wieland ------------------------------------------------------------------------------- Wieland Holfelder International Computer Science Institute Email: whd@icsi.berkeley.edu 1947 Center Street Suite 600 Fax : +1-510-642-6865 Berkeley, CA 94704-1198 Phone: +1-510-642-4274 Ext. 302 URL: http://www.icsi.berkeley.edu/~whd ------------------------------------------------------------------------------- From rem-conf-request@es.net Thu Nov 24 03:28:20 1994 Received: from venera.isi.edu by osi-west.es.net via ESnet SMTP service id <18758-0@osi-west.es.net>; Thu, 24 Nov 1994 00:27:50 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-19) id ; Thu, 24 Nov 1994 00:27:45 -0800 Posted-Date: Thu 24 Nov 94 00:26:35 PST Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 24 Nov 94 00:26:36 PST Date: Thu 24 Nov 94 00:26:35 PST From: Stephen Casner Subject: AVT WG agenda for San Jose IETF To: rem-conf@es.net Message-Id: <785665595.0.CASNER@XFR.ISI.EDU> Mail-System-Version: Audio/Video Transport Working Group: At the Toronto IETF in July, the RTP version 2 draft specification was presented and generally accepted. That draft needed a few additions of explanatory text and some algorithms in the appendix. That process has taken longer than expected (what else is new), but a new Internet-Draft will be submitted before the Monday cutoff date. This draft will also be submitted to the Area Director with a request for IESG Last Call and publication as an RFC. Only one AVT session is scheduled for this IETF. -- Steve Casner Audio/Video Transport WG A G E N D A Tuesday, December 6, 4:00-6:00 - Status of RTP - Overview (a few slides) of RTP specification for newcomers - Discussion of changes since the last draft (mostly details), and an opportunity for comments - RTP implementation experience in "vic" video tool -- McCanne - RTP implementation experience in "Loki" -- Kastenholz (tentative) - Presentation of new drafts of video encodings over RTP (MPEG1/MPEG2; Cell-B) - Assess future working group activity ------- From rem-conf-request@es.net Thu Nov 24 09:29:03 1994 Received: from dxmint.cern.ch by osi-west.es.net via ESnet SMTP service id <20394-0@osi-west.es.net>; Thu, 24 Nov 1994 06:28:33 +0000 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13758; Thu, 24 Nov 1994 15:28:27 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09486; Thu, 24 Nov 1994 15:28:23 +0100 Message-Id: <9411241428.AA09486@dxcoms.cern.ch> Subject: Next LEPC on MBONE To: rem-conf@es.net (rem-conf Distribution List), htc@cearn.cern.ch, hrc@cearn.cern.ch, teleconf@cearn.cern.ch, tele-ext@cearn.cern.ch Date: Thu, 24 Nov 1994 15:28:23 +0100 (MET) From: Christian Isnard - CERN/CN/CS Cc: jzk@cernvm.cern.ch X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1695 CERN is pleased to announce that the 39th LEP Experiments Committee (LEPC) (*) Open Session will be broadcast on MBONE on Friday December 19th between 07:30 GMT and 12:00 GMT (08:30 - 13:00 Geneva Time) ------------------------- This will be a live broadcast of the LEPC Open Session that will take place in the CERN main amphitheater. Provisional Agenda ------------------ Reports on the LEP machine -------------------------- (Geneva Time, GMT+1) 08:30 - 08:45 LEP machine status. 08:45 - 09:15 High luminosity running in LEP 1 and LEP 2. 09:15 - 09:30 Transverse polarization in collision. 09:30 - 10:00 Report from the energy calibration working group. 10:00 - 10:30 Status of the LEP 2 superconducting RF system. 10:30 - 11:00 Break Reports on the LEP experiments ------------------------------ (Geneva Time, GMT+1) 11:00 - 11:30 L3 11:30 - 12:00 OPAL 12:00 - 12:30 DELPHI 12:30 - 13:00 ALEPH The session will be advertised in sd session directory as "CERN - LEPC". The following tools will be used: vat v3.4 (audio), and nv v3.3 (video). (*) CERN is the European Laboratory for Particle Physics. The Large Electron-Positron collider (LEP) is installed in a tunnel measuring 27 km in circumference on the Franco-Swiss border near Geneva. -- Christian Isnard Email: isnard@dxcoms.cern.ch European Laboratory for Particle Physics CERN - CN/CS/EN Computers and Networks division Tel: +41 22 767 23 94 CH-1211 Geneva 23 - Switzerland Fax: +41 22 767 71 55 From rem-conf-request@es.net Thu Nov 24 09:50:38 1994 Received: from dxmint.cern.ch by osi-west.es.net via ESnet SMTP service id <20504-0@osi-west.es.net>; Thu, 24 Nov 1994 06:50:12 +0000 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA18426; Thu, 24 Nov 1994 15:50:07 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA10807; Thu, 24 Nov 1994 15:50:05 +0100 Message-Id: <9411241450.AA10807@dxcoms.cern.ch> Subject: Next LEPC on MBONE (correction) To: rem-conf@es.net, htc@cearn.cern.ch, hrc@cearn.cern.ch, teleconf@cearn.cern.ch, tele-ext@cearn.cern.ch Date: Thu, 24 Nov 1994 15:50:04 +0100 (MET) From: Christian Isnard - CERN/CN/CS Cc: jzk@cernvm.cern.ch X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 214 The LEPC broadcast on MBONE will take place on Friday December 9th (from 07:30 GMT to 12:00 GMT) and not on the 19th as it was incorrectly announced. Sorry for the inconvenience. -- Christian Isnard. From rem-conf-request@es.net Fri Nov 25 07:52:00 1994 Received: from bells.cs.ucl.ac.uk by osi-west.es.net via ESnet SMTP service id <24508-0@osi-west.es.net>; Fri, 25 Nov 1994 04:51:13 +0000 Received: from muridae.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 25 Nov 1994 12:50:59 +0000 To: rem-conf@es.net Subject: ArtAIDS event - Monday 28th November at 20:00 UTC Date: Fri, 25 Nov 94 12:50:32 +0000 From: Gordon Joly Please note the start time: 12 PST (28th Nov) 15 EST (28th Nov) 20 UTC (28th Nov) 21 CET (28th Nov) 7 AEDT (29th Nov) We plan to launch ArtAIDS in support of AIDS charities (Crusaid in the UK) on the MBONE on Monday 28 November at 20:00 UTC. There will be artists taking part in the UK, Sweden, Belgium, Germany, Australia and the USA. An entry will be made in "sd". During this open meeting, commissioned digital art will be discussed and plans for the next twelve months of the ArtAIDS project. The project will raise AIDS awareness: the project launch timed to be a few days before World AIDS Day (1 December). See "The ArtAIDS Project" URL at http://artaids.dcs.qmw.ac.uk:8001/ for more details and some examples of work already submitted to the ArtAIDS gallery. The MBONE event will be kept up to date in http://www.cs.ucl.ac.uk/artaids/mbone.html Gordon Joly Email: G.Joly@cs.ucl.ac.uk +441713807934 FAX +441713871397 Computer Science, University College London, Gower St., LONDON WC1E 6BT http://www.cs.ucl.ac.uk/people/gordo/ http://artaids.dcs.qmw.ac.uk:8001/ From rem-conf-request@es.net Fri Nov 25 11:02:32 1994 Received: from cismsun.univ-lyon1.fr by osi-east.es.net via ESnet SMTP service id <04474-0@osi-east.es.net>; Fri, 25 Nov 1994 08:02:08 +0000 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.9/8.6.6) id RAA09302; Fri, 25 Nov 1994 17:00:45 +0100 Message-Id: <199411251600.RAA09302@cismsun.univ-lyon1.fr> Subject: Re: vat & AF (fwd) To: rem-conf@es.net Date: Fri, 25 Nov 1994 17:00:43 +0100 (MET) From: Lucia Gradinariu Cc: turletti@sophia.inria.fr X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 685 For those running vat in unicast mode on Solaris2.3: > Given you run the two vat in unicast-mode then your problem might be due to a > bug in Solaris. > If so, look at ftp://playground.sun.com/pub/solaris2/unicast-vat-workaround.tar > > -- Wieland > ------------------------------------------------------------------------------- > Wieland Holfelder > International Computer Science Institute Email: whd@icsi.berkeley.edu > 1947 Center Street Suite 600 Fax : +1-510-642-6865 > Berkeley, CA 94704-1198 Phone: +1-510-642-4274 Ext. 302 > URL: http://www.icsi.berkeley.edu/~whd > ------------------------------------------------------------------------------- > > > From rem-conf-request@es.net Fri Nov 25 12:27:56 1994 Received: from cismsun.univ-lyon1.fr by osi-west.es.net via ESnet SMTP service id <01704-0@osi-west.es.net>; Fri, 25 Nov 1994 09:26:39 +0000 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.9/8.6.6) id SAA11609; Fri, 25 Nov 1994 18:26:27 +0100 Message-Id: <199411251726.SAA11609@cismsun.univ-lyon1.fr> Subject: Journee-ROCAD To: rem-conf@es.net Date: Fri, 25 Nov 1994 18:26:26 +0100 (MET) From: Lucia Gradinariu Cc: mbone-eu@sics.se, mbone@isi.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 0 From rem-conf-request@es.net Sun Nov 27 14:29:05 1994 Received: from blacksun.metaverse.com by osi-west.es.net via ESnet SMTP service id <10191-0@osi-west.es.net>; Sun, 27 Nov 1994 11:28:38 +0000 Received: (from uucp@localhost) by blacksun.metaverse.com (8.6.9/8.6.9) id LAA23830; Sun, 27 Nov 1994 11:24:46 -0800 Received: from mailhost(140.174.161.4) by blacksun via smap (V1.3mjr) id sma023822; Sun Nov 27 19:23:51 1994 Received: from beli by metaverse.com (5.x/SMI-SVR4) id AA01458; Sun, 27 Nov 1994 11:25:06 -0800 Date: Sun, 27 Nov 1994 11:22:39 -800 (PST) From: Karl Jacob Reply-To: kaj@metaverse.com Subject: MMDE MBONE transmission Dec 10 94 To: rem-conf@es.net, mbone@ISI.EDU Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, We would like to broadcast the Mega Music Dance Experience on Dec 10 and 11th from Utrecht, Holland 20 miles south of Amsterdam. The show is sold out ( 23,500 people ). Eight cameras will capture the action at the Prince van Oranjehal in the Utrechtse Jaarbeurs-complex. This year's rave dance spectacle, a commercial-free event, will allow Internet users around the world to participate in the fun. There will be 40 Sun workstations on site so guests can surf the Net or chat with virtual guests at their computers around the world. Every fifteen minutes, a new edition of the interactive newspaper, The Dens, will be produced and distributed at the party and via the Internet. The Dens will incorporate the latest color digital photo images of the party scene and newsflashes, with commentary generated by participants in front of computers at home as well by those at the party. The event will start at 20:30 ( 9 hours ahead of Pacific Standard Time ) and end at 6:00. We would also like to test the connection on Dec the 8th. We would like the broadcast to reach the states, so I propose a ttl of 79. If 79 seems off or you would like me to up the ttl to you please mail me. Karl From rem-conf-request@es.net Mon Nov 28 02:08:08 1994 Received: from ell.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <12307-0@osi-west.es.net>; Sun, 27 Nov 1994 23:07:26 +0000 Received: by ell.ee.lbl.gov (8.6.9/1.43r) id XAA11025; Sun, 27 Nov 1994 23:07:23 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199411280707.XAA11025@ell.ee.lbl.gov> To: rem-conf@es.net Subject: Mark Garrett on MBONE (Dec 1, 1:00-2:00pm PST) Date: Sun, 27 Nov 94 23:07:22 PST On Dec 1 at 1:00pm PST, Dr. Mark Garrett will be giving a talk, ``Designing Real Quality of Service into ATM and the Internet'', >from the Internation Computer Science Institute (ICSI) in Berkeley, CA. Audio, video, and whiteboard will broadcast on the MBONE, via the sd session entitled ``Garrett QOS Talk''. See below for the abstract. We plan to transmit the video portion of the talk using H.261 over RTPv2. This is contingent upon our ability to put together a release of our new video tool, ``vic'', by Tuesday, so people will have enough time to grab the software and try it out. In the worst case, a binary-only release will happen by Tuesday. Stay tuned... Steve ===== The International Computer Science Institute is pleased to present a talk: Designing Real Quality of Service into ATM and the Internet Mark W. Garrett Bellcore Thursday, December 1, 1994 1:00 p.m. The design of traffic management and quality of service (QOS) provisions in an integrated services network can be approached top-down by starting with a long list of real applications. From the structure in the "space" of applications requirements, we discover what network functionality will be most useful. A service model is an abstraction which maps applications to network functions, and helps structure the design problem. We derive a rationale for the ATM service categories (CBR, VBR, UBR, ABR) now proposed in the ATM Forum. This service model can be related to a similar one currently being developed for the next-generation Internet protocol in the IETF. A comparison of these two service models is important as it determines how well IP and ATM will interwork. The role of packet/cell queueing and scheduling is key to realizing the goals of appropriate QOS and efficiency. We will discuss Weighted Fair Queueing (and its variations), and other aspects of traffic description and management. This talk will be held in Conference Room 5A at ICSI. 1947 Center Street, Fifth Floor, Berkeley, CA 94704-1198 (On Center between Milvia and Martin Luther King Jr. Way) [http://www.icsi.berkeley.edu/location.html] From rem-conf-request@es.net Mon Nov 28 08:56:50 1994 Received: from cismsun.univ-lyon1.fr by osi-west.es.net via ESnet SMTP service id <14731-0@osi-west.es.net>; Mon, 28 Nov 1994 05:56:23 +0000 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.9/8.6.6) id OAA00962; Mon, 28 Nov 1994 14:56:07 +0100 Message-Id: <199411281356.OAA00962@cismsun.univ-lyon1.fr> Subject: Journee-ROCAD To: mbone-eu@sics.se Date: Mon, 28 Nov 1994 14:56:06 +0100 (MET) From: Lucia Gradinariu Cc: rem-conf@es.net, mbone-fr@inria.fr, telesia-technique@inria.fr, chd@inria.fr X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1497 THIS IS A REPEAT BROADCAST (due to e-mail problems during last week-end) OF THE MESSAGE CONCERNING THE "Journee-ROCAD" ENTRY IN sd Hello, We are pleased to announce you the 3-rd yearly day of conferences and debates organized by ROCAD network manager center, CISM-Lyon1 University, France. ------> The 1-st December 1994 from 8.30 GMT to 17 GMT <----------------- The subject (of the year!) is: NETWORK DISTRIBUTED MULTIMEDIA APPLICATIONS. Please take a look at : ------> http://www.univ-lyon1.fr <----------------- even it's in french (for the moment). The conference will be broadcasted on French MBone (ttl 64) using telesia v3.1, a videoconference application developped at INRIA Rocquencourt, France ------> ftp anonymous electre.inria.fr:pub/videoconf/telesia<------------- ------> sd: Journee-ROCAD (224.2.138.159/57645 fmt:telesia)<------------- But if you want you could: ------> JOIN US ON MBONE <------------------ We should like to expand the scope of the conference, for contacts and debates over Mbone, in the afternoon (13.30-17 GMT), possibly by vat/nv. If anyone is interested to participate to these debates please contact: ============================================================================== Lucia.Gradinariu@univ-lyon1.fr Centre Informatique Scientifique et Medicale Univ. Cl. Bernard-Lyon1, Bat. 101 27&43 Bd. du 11 Novembre 1918 69622 Villeurbanne FRANCE =============================================================================== From rem-conf-request@es.net Mon Nov 28 12:07:47 1994 Received: from tournedoc.inria.fr by osi-west.es.net via ESnet SMTP service id <15933-0@osi-west.es.net>; Mon, 28 Nov 1994 09:07:15 +0000 Received: by jerry.inria.fr (5.65c8/IDA-1.2.8) id AA14809; Wed, 22 Jun 1994 16:10:06 +0200 Message-Id: <199406221410.AA14809@jerry.inria.fr> To: Stephen Casner Cc: rem-conf@es.net Subject: Re: Comments requested: RTP version 2 In-Reply-To: Your message of Tue, 14 Jun 1994 23:54:41 -0700. <771663281.0.CASNER@XFR.ISI.EDU> Reply-To: turletti@jerry.inria.fr Date: Wed, 22 Jun 1994 16:10:02 +0200 From: Thierry Turletti Here are the main points I would like to comment on > o Control information is no longer carried as options in the RTP data > packets. Instead, control information is carried in RTCP packets on > a separate lower-layer transport association (e.g., UDP port). RTCP > packets are self-contained units that can be processed independently. > There is a hook provided to allow profile-specific extensions to the > header of data packets should a requirement arise. Fine. I already used different port numbers for control packets in ivs. > o The RTP timestamp now measures time in a clock rate defined by the > encoding rather than a fixed 65536 Hz clock. The timestamp itself has > no predictable relation to wallclock time, but the relation to an NTP > timestamp may be carried explictly in an RTCP packet. About the media dependant clock timestamp, as Christian said before, we'd rather have the previous timestamp definition. The point with media dependant clock is that the difference between real clock and media clock depends of the load of the machine. More over, we need the real clock timestamp to process the rtt max value useful for our scalable congestion control algorithm. The interarrival jitter is not significant for applications like ivs which do not send packets at regular intervals (output rate control policy, cpu limit...) Clearly, It seems that the timestamp field should also be application dependant. The talk-spurt bit for audio is not really essential but it tells us that we don't have to wait any further to get to the end of the talk-spurt. (saving of time in the playout buffer management). > o The unicast reverse path RTP control packet is eliminated because the > change in SSRC identifers and the encryption method preclude reverse > mapping in translators. Normal (multicast) RTCP is used instead. I disagree with the unicast reverse path RTP control packet removal. It is not clear that multicast reverse feedback is more convenient than simple unicast to the sources. Two policies exists: either you let the source make the decision for the participants or you let each participant process its network state and make its own decision. I'm not sure RTP should decide what policy to use. In all cases I think RTP should not decide currently what policy to use -- we really need to test & compare both schemes. BTW, I think that RTP should also consider the very large broadcast case in which the number of participants is unknown. In this case (e.g. TV broadcasted to N participants, where N is large but unknown) a very loose control scheme should be used: e.g. no control session sent by receiving-only participants. About the new SSRC Random random 32-bit Identifier How long should a shource monitor the transmission of others sources before picking its own value ? To ensure that nobody else has the same SSRC identifier, each participant needs to compare each SSRC identifier received with its own SSRC. This stuff certainly looks to me like we could live without. Regards, Thierry From rem-conf-request@es.net Mon Nov 28 12:11:53 1994 Received: from ietf.cnri.reston.va.us by osi-west.es.net via ESnet SMTP service id <15979-0@osi-west.es.net>; Mon, 28 Nov 1994 09:11:21 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04902; 28 Nov 94 11:14 EST 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-cellb-profile-02.txt Date: Mon, 28 Nov 94 11:14:23 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9411281114.aa04902@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 Encapsulation of CellB Video Encoding Author(s) : M. Speer, D. Hoffman Filename : draft-ietf-avt-cellb-profile-02.txt Pages : 23 Date : 11/23/1994 This note describes a packetization scheme for the CellB video encoding using RTP. This document is meant for implementors of video applications that use RTP and CellB. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-cellb-profile-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-cellb-profile-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-cellb-profile-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19941123091911.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-cellb-profile-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-cellb-profile-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941123091911.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Mon Nov 28 15:02:41 1994 Received: from alpha.Xerox.COM by osi-west.es.net via ESnet SMTP service id <17977-0@osi-west.es.net>; Mon, 28 Nov 1994 12:02:19 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <14430(6)>; Mon, 28 Nov 1994 12:02:11 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16138>; Mon, 28 Nov 1994 12:01:52 -0800 X-Mailer: exmh version 1.5 11/22/94 To: turletti@jerry.inria.fr cc: Stephen Casner , rem-conf@es.net Subject: Re: Comments requested: RTP version 2 In-reply-to: Your message of "Wed, 22 Jun 94 07:10:02 PDT." <199406221410.AA14809@jerry.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Nov 1994 12:01:41 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <94Nov28.120152pst.16138@ecco.parc.xerox.com> In message <199406221410.AA14809@jerry.inria.fr> you write: > About the media dependant clock timestamp, as Christian said before, we'd > rather have the previous timestamp definition. The point with media dependant > clock is that the difference between real clock and media clock depends of > the load of the machine. More over, we need the real clock timestamp to > process the rtt max value useful for our scalable congestion control > algorithm. The interarrival jitter is not significant for applications like > ivs which do not send packets at regular intervals (output rate control > policy, cpu limit...) Clearly, It seems that the timestamp field should also > be application dependant. > There seems to be a lot of confusion about the media timestamp in RTPv2. The only thing which has changed is that we're not fixing the epoch and we're making the rate be encoding-specific. For audio encodings, the rate is the sample rate. For video applications, the general feeling so far has been that sticking with 65536 Hz still makes sense. So, for an application like ivs, the only change is that the timestamp doesn't contain absolute time anymore. It only contains relative time, but still running at the same rate as before. If you still need absolute time, the NTP timestamp in the RTCP packets will allow you to map the media timestamps back to absolute time. I don't understand your comments about the media timestamp being influenced by machine load. The timestamp cannot be application dependent if you want two different applications using the same encoding to sensibly interoperate... -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Mon Nov 28 16:13:07 1994 Received: from extra.ucc.su.OZ.AU by osi-west.es.net via ESnet SMTP service id <18789-0@osi-west.es.net>; Mon, 28 Nov 1994 13:12:32 +0000 Received: from extro.ucc.su.OZ.AU (rossc@extro [129.78.128.1]) by extra.ucc.su.OZ.AU (8.6.9/8.6.9) with ESMTP id IAA06740 for ; Tue, 29 Nov 1994 08:12:28 +1100 From: Ross Cartlidge Received: (rossc@localhost) by extro.ucc.su.OZ.AU (8.6.9/8.6.6) id IAA18946 for rem-conf@es.net; Tue, 29 Nov 1994 08:12:26 +1100 Date: Tue, 29 Nov 1994 08:12:26 +1100 Message-Id: <9411290812.ZM18944@extro> x-face: eo,Rkv4542FG!:?D7C`Ymrj-reW9V|vC:Dm3E?;wj?`9<7ck@'aSxs%X3~FO.;G)H]; Mon, 28 Nov 1994 13:41:04 +0000 Received: from muon.nist.gov by fs1.cam.nist.gov (4.1/SMI-DDN) id AA17810; Mon, 28 Nov 94 16:40:45 EST Received: by muon.nist.gov (4.1/SMI-3.2) id AA27273; Mon, 28 Nov 94 16:44:16 EST Date: Mon, 28 Nov 94 16:44:16 EST From: chang@cam.nist.gov (Wo Chang x3439) Message-Id: <9411282144.AA27273@muon.nist.gov> To: rem-conf@es.net Subject: multicast CIKM '94 Keynote Address Cc: craig@cam.nist.gov, colella@snad.ncsl.nist.gov, sting@central.bldrdoc.gov, sherk@sura.net, paulf@cam.nist.gov, dave@quasar.nist.gov, chang@muon.nist.gov ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ National Institute of Standards and Technology (NIST) is pleased to announce that the Third International Conference on Information and Knowledge Management (CIKM-94) Keynote Address --------------- will be broadcast on MBONE on Tuesday November 29th from 09:00 AM to 10:00 AM (EST) (This slot has been reserved via the MBONE GLOBAL AGENDA) This live broadcast will take place in the NIST Green Auditorium of Gaithersburg, Maryland. The SD entry will be under CIKM '94. ^^^^^^^^ Agenda ======== 09:00 - 09:30 The National Information Infrastructure Speaker: Dr. Arati Prabhakar (Director of NIST, Department of Commerce) 09:30 - 10:00 Digital Libraries - Is it reality or myth? Speaker: Dr. Jacob Slonim (Head of Research, Centre for Advanced Studies, IBM Canada) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Tue Nov 29 02:16:15 1994 Received: from swan.cl.cam.ac.uk by osi-west.es.net via ESnet SMTP service id <21848-0@osi-west.es.net>; Mon, 28 Nov 1994 23:15:48 +0000 Received: from swan.cl.cam.ac.uk (user pb (rfc931)) by swan.cl.cam.ac.uk with SMTP (PP-6.5) to cl; Tue, 29 Nov 1994 07:15:40 +0000 To: rem-conf@es.net, mbone@ISI.EDU Cc: Piete.Brooks@cl.cam.ac.uk Reply-To: Piete.Brooks@cl.cam.ac.uk Subject: Mbone transmission 94/11/29 16:15-17:15 UTC (cl.cam.ac.uk Security) Date: Tue, 29 Nov 1994 07:15:36 +0000 From: Piete Brooks Message-ID: <"swan.cl.cam.:055520:941129071543"@cl.cam.ac.uk> This week's seminar will be trasnmitted at TTL 31 -- i.e. just within JIPS (ac.uk) -- unless anyone wants the TTL raised. If so, please let me know your nearest mrouted, and whether you want just the audio, or audio and video. It's meant as a "low key" transmission (without anyone manning the camera, etc). The video will just be of the speaker (slides will **ONLY** be available via the WWW -- not on the video feed). NAME: Mark Lomas DATE: Tuesday 29rd November 1994 at 4.15pm (16:15 UTC) TITLE: Computer Generated Evidence Recent activity in the security community has concentrated on computer networks and new services they may provide. This work tends to overlook the more mundane services that we take for granted. Computer technology has reduced the entry cost for forgers, or it may be said to reduce the skill necessary to produce convincing forgeries. To combat this I suggest that paper documents such as banknotes and cheques will need to incorporate machine-readable security information, and many documents used as evidence in courts may have to change drastically in the next few years. This seminar will be multicast (audio and video) on the mbone as part of our multimedia test programme. Further information is available at http://www.cl.cam.ac.uk/mbone/#cl. From rem-conf-request@es.net Tue Nov 29 03:25:37 1994 Received: from jerry.inria.fr by osi-west.es.net via ESnet SMTP service id <22361-0@osi-west.es.net>; Tue, 29 Nov 1994 00:25:04 +0000 Received: by jerry.inria.fr (5.65c8/IDA-1.2.8) id AA10064; Tue, 29 Nov 1994 09:24:25 +0100 Message-Id: <199411290824.AA10064@jerry.inria.fr> To: Ron Frederick Cc: Stephen Casner , rem-conf@es.net Subject: Re: Comments requested: RTP version 2 In-Reply-To: Your message of Mon, 28 Nov 1994 12:01:41 -0800. <94Nov28.120152pst.16138@ecco.parc.xerox.com> Reply-To: Thierry.Turletti@sophia.inria.fr Date: Tue, 29 Nov 1994 09:24:24 +0100 From: Thierry Turletti Ron & all, Forget my previous e-mail, it was a very old message sent (or unsent ?) >Received: from sophia.inria.fr by pax.inria.fr with SMTP > (5.65c8/IDA-1.2.8) id AA13471; Mon, 28 Nov 1994 19:35:06 +0100 >Received: by sophia.inria.fr > (5.65c8/IDA-1.2.8) id AA23874; Mon, 28 Nov 1994 19:34:56 +0100 >Received: from osi-west.es.net by sophia.inria.fr with SMTP > (5.65c8/IDA-1.2.8) id AA23859; Mon, 28 Nov 1994 19:34:48 +0100 >Received: from tournedoc.inria.fr by osi-west.es.net via ESnet SMTP service > id <15933-0@osi-west.es.net>; Mon, 28 Nov 1994 09:07:15 +0000 >Received: by jerry.inria.fr (5.65c8/IDA-1.2.8) id AA14809; > Wed, 22 Jun 1994 16:10:06 +0200 ^^^^^^^^^^^^^^^^ >Message-Id: <199406221410.AA14809@jerry.inria.fr> >To: Stephen Casner >Cc: rem-conf@es.net >Subject: Re: Comments requested: RTP version 2 Sorry for the inconvenience, Thierry From rem-conf-request@es.net Tue Nov 29 03:53:38 1994 Received: from faui45.informatik.uni-erlangen.de by osi-west.es.net via ESnet SMTP service id <22475-0@osi-west.es.net>; Tue, 29 Nov 1994 00:53:14 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA04062 (5.65c-6/7.3w-FAU); Tue, 29 Nov 1994 09:53:06 +0100 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA12891 (5.65c-6/7.3m-FAU); Tue, 29 Nov 1994 09:53:04 +0100 From: Toerless Eckert Message-Id: <199411290853.AA12891@faui43.informatik.uni-erlangen.de> Subject: SunVideo question To: rem-conf@es.net Date: Tue, 29 Nov 94 9:52:55 MET Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] Hi I was wondering if someone on this list could comment the following observation. Upon using the SunVideo board with solaris 2.4 on a ss20/612 a message is printed, telling me that "rtvc: DMA mode is not supported in this version of the hardware". I suppose this means that the SunVideo board is suspected to be able to do DMA mode but that this won't work with the board i have. I'd like to know if other people have made the same observation and what kind of throughput can be achieved with the SunVideo board (maybe this may be used as an indication if DMA is enabled or not). The following table contains the throughput i could measure with the SunVideo program that comes with solaris 2.4. The maximum throughput over the bus seem to be 3.6 MByte/sec (for uncompressed RGB color) and this doesn't look very much like DMA to me (i.e.: the old VideoPix graphics board that surely had no DMA would achieve the same throughput). I wanted to buy another couple of SunVideo boards, but if this could mean for example that buying now would give me yet another board without DMA and two month later a board capable of DMA would be available, i'd better wait. ------------------------------------------------------------------------------ Throughput results for running /opt/SUNWits/Graphics-sw/xil/examples/test/SunVideo on a SS20/612 connected to a PAL videocamera. Zoom is always 1. Still picture. Direct GraySc CellB JPEG MPEG/I UYUV F/s F/s F/s F/s F/s F/s Mbps Mbps Mbps Mbps Mbps Mbps B/pxl B/pxl B/pxl B/pxl B/pxl B/pxl No Display 3.6 4.1 7.1 - - 4.4 768x576 36.30 13.98 1.72 - - 30.48 24.0 8.0 0.60 - - 16.0 SX/ 24 bit 2.0 2.1 3.0 - - 1.7 20.34 7.28 0.74 - - 11.77 24.0 8.0 0.59 - - 16.0 SX/ 8 bit 0.2 2.5 7.2 - - 2.6 0.69 8.3 1.71 - - 17.51 8.0 8.0 0.58 - - 16.0 No Display 10 25 25 25 20 13 384x288 25.7 21.09 1.49 2.0 3.56 21.60 24.0 8.0 0.56 0.76 1.7 16.0 -- 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 Toerless.Eckert@Informatik.Uni-Erlangen.DE /C=De/A=D400/P=Uni-Erlangen/OU=Informatik/S=Eckert/G=Toerless/ From rem-conf-request@es.net Tue Nov 29 04:22:44 1994 Received: from datm.inria.fr by osi-west.es.net via ESnet SMTP service id <22732-0@osi-west.es.net>; Tue, 29 Nov 1994 01:22:08 +0000 Received: by jerry.inria.fr (5.65c8/IDA-1.2.8) id AA14809; Wed, 22 Jun 1994 16:10:06 +0200 Message-Id: <199406221410.AA14809@jerry.inria.fr> To: Stephen Casner Cc: rem-conf@es.net Subject: Re: Comments requested: RTP version 2 In-Reply-To: Your message of Tue, 14 Jun 1994 23:54:41 -0700. <771663281.0.CASNER@XFR.ISI.EDU> Reply-To: turletti@jerry.inria.fr Date: Wed, 22 Jun 1994 16:10:02 +0200 From: Thierry Turletti Here are the main points I would like to comment on > o Control information is no longer carried as options in the RTP data > packets. Instead, control information is carried in RTCP packets on > a separate lower-layer transport association (e.g., UDP port). RTCP > packets are self-contained units that can be processed independently. > There is a hook provided to allow profile-specific extensions to the > header of data packets should a requirement arise. Fine. I already used different port numbers for control packets in ivs. > o The RTP timestamp now measures time in a clock rate defined by the > encoding rather than a fixed 65536 Hz clock. The timestamp itself has > no predictable relation to wallclock time, but the relation to an NTP > timestamp may be carried explictly in an RTCP packet. About the media dependant clock timestamp, as Christian said before, we'd rather have the previous timestamp definition. The point with media dependant clock is that the difference between real clock and media clock depends of the load of the machine. More over, we need the real clock timestamp to process the rtt max value useful for our scalable congestion control algorithm. The interarrival jitter is not significant for applications like ivs which do not send packets at regular intervals (output rate control policy, cpu limit...) Clearly, It seems that the timestamp field should also be application dependant. The talk-spurt bit for audio is not really essential but it tells us that we don't have to wait any further to get to the end of the talk-spurt. (saving of time in the playout buffer management). > o The unicast reverse path RTP control packet is eliminated because the > change in SSRC identifers and the encryption method preclude reverse > mapping in translators. Normal (multicast) RTCP is used instead. I disagree with the unicast reverse path RTP control packet removal. It is not clear that multicast reverse feedback is more convenient than simple unicast to the sources. Two policies exists: either you let the source make the decision for the participants or you let each participant process its network state and make its own decision. I'm not sure RTP should decide what policy to use. In all cases I think RTP should not decide currently what policy to use -- we really need to test & compare both schemes. BTW, I think that RTP should also consider the very large broadcast case in which the number of participants is unknown. In this case (e.g. TV broadcasted to N participants, where N is large but unknown) a very loose control scheme should be used: e.g. no control session sent by receiving-only participants. About the new SSRC Random random 32-bit Identifier How long should a shource monitor the transmission of others sources before picking its own value ? To ensure that nobody else has the same SSRC identifier, each participant needs to compare each SSRC identifier received with its own SSRC. This stuff certainly looks to me like we could live without. Regards, Thierry From rem-conf-request@es.net Tue Nov 29 09:40:50 1994 Received: from RUTGERS.EDU by osi-west.es.net via ESnet SMTP service id <24643-0@osi-west.es.net>; Tue, 29 Nov 1994 06:40:26 +0000 Received: from aristotles.rutgers.edu by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12263; Tue, 29 Nov 94 09:40:23 EST Received: by aristotles.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA04063; Tue, 29 Nov 94 09:40:21 EST To: ru-comp-dev-ietf-rem-conf@rutgers.edu Path: aristotles.rutgers.edu!not-for-mail From: hobson@aristotles.rutgers.edu (Kevin Hobson) Newsgroups: ru.comp.dev.ietf.rem-conf Subject: Re: Your rem-conf subscription request Date: 29 Nov 1994 09:40:18 -0500 Organization: Rutgers Telecommunications Lines: 27 Message-Id: <3bfegi$3ut@aristotles.rutgers.edu> References: <9411290105.AA17676@viipuri.nersc.gov> Cc: arup acharya ari@es.net (Ari Ollikainen) writes: >> From acharya@paul.rutgers.edu Mon Nov 21 23:32:29 1994 >> Date: Tue, 22 Nov 1994 02:32:22 -0500 >> From: arup acharya >> To: rem-conf-request@es.net >> Content-Length: 56 >> >> please add me to the mailing list. >> tahnks, >> arup acharya >> > Would it surprise you to know that Rutgers has a local rem-conf > forwarder: rem-conf-list@rutgers.edu > They may even respond to Internet listname-request style requests... Well, we also have it set up as local newsgroup gateway to mailing list so many of us are not deluged with mail (ru.comp.dev.ietf.rem-conf). -- Kevin Hobson ("finger hobson@noc.rutgers.edu" for more information; option WWW) Rutgers - The State University of New Jersey INTERNET:hobson@noc.rutgers.edu Computing Services/Telecommunications Division PHONE: 908-445-4780 Busch Campus, Brett Rd, Hill Center, Rm 018, Piscataway, New Jersey, 08855-0879 From rem-conf-request@es.net Tue Nov 29 15:18:40 1994 Received: from ietf.cnri.reston.va.us by osi-west.es.net via ESnet SMTP service id <27963-0@osi-west.es.net>; Tue, 29 Nov 1994 12:18:17 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa08915; 29 Nov 94 15:11 EST 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-jpeg-00.txt Date: Tue, 29 Nov 94 15:11:34 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9411291511.aa08915@IETF.CNRI.Reston.VA.US> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Encapsulation of JPEG-compressed video. Author(s) : W. Fenner, L. Berc, R. Frederick, S. McCanne Filename : draft-ietf-avt-jpeg-00.txt Pages : 6 Date : 11/28/1994 This draft describes a packetization scheme for JPEG video over RTP. It is optimized for real-time video streams using constant JPEG parameters, as opposed to individual JPEG images coming from different sources. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-jpeg-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-jpeg-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-jpeg-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19941128175553.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-jpeg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-jpeg-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941128175553.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Nov 29 16:04:17 1994 Received: from achilles.ctd.anl.gov by osi-west.es.net via ESnet SMTP service id <28295-0@osi-west.es.net>; Tue, 29 Nov 1994 13:03:43 +0000 Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA23840; Tue, 29 Nov 94 15:03:41 CST Date: Tue, 29 Nov 94 15:03:41 CST Message-Id: <9411292103.AA23840@achilles.ctd.anl.gov> To: rem-conf@es.net Subject: ICMP and FDDI modules for mcast-3.3 From: "Jeffrey S. Curtis" Reply-To: curtis@anl.gov Howdy- I'm new to this list; sorry if these issues have been discussed before... The distribution for version 3.3 of the multicasting software for Sun machines includes an ip_icmp.o module that seems to have been built before Sun patch 101587-01 existed. Does anyone know if a newer ip_icmp.o exists which supports multicasting as well as incorporating the security features fixed in patch 101587-01? Second, the modules for multicasting via FDDI drivers (bf*.o) are based on version 1.0 of these drivers. Does anyone know if there are similar multicasting modules available for the newer versions of the FDDI drivers? Thanks, Jeff -- Jeffrey S. Curtis | Email: curtis@anl.gov Argonne National Laboratory | Voice: 708/252-1789 9700 South Cass Avenue, ECT-221 | Fax: 708/252-9689 Argonne, IL 60439 | From rem-conf-request@es.net Tue Nov 29 18:10:01 1994 Received: from ell.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <29174-0@osi-west.es.net>; Tue, 29 Nov 1994 15:09:25 +0000 Received: by ell.ee.lbl.gov (8.6.9/1.43r) id PAA21922; Tue, 29 Nov 1994 15:09:24 -0800 From: mccanne@ee.lbl.gov (Steven McCanne) Message-Id: <199411292309.PAA21922@ell.ee.lbl.gov> To: rem-conf@es.net Subject: vic available for anonymous ftp Date: Tue, 29 Nov 94 15:09:23 PST This note is to announce an ALPHA source release of the UCB/LBL video conferencing tool, vic. Vic is available via anonymous ftp to ftp.ee.lbl.gov in the directory conferencing/vic, or alternatively from tenet.cs.berkeley.edu in the directory pub/src. To facilitate the distribution, we've put pre-built binaries in the vic directory. Building from source is encouraged (so you can tell us what goes wrong in your environment), but somewhat involved since it requires tcl/tk, libblt, and support libraries for the various video capture devices. For more information, please see ftp://ftp.ee.lbl.gov/conferencing/vic/README. Note this is an ALPHA release. You should expect to encounter bugs and shouldn't run this software unless you are adventurous and would like to help us with its deployment. We appreciate your effort and feedback. As always, we very much want to hear about bugs and problems. Please don't hesitate to offer suggestions or other feedback. Send all vic related correspondence to vic@ee.lbl.gov (this list includes only the developers and is not distributed beyond our site). Thanks. - Steve McCanne & Van Jacobson From rem-conf-request@es.net Tue Nov 29 22:00:45 1994 Received: from jaring.my by osi-west.es.net via ESnet SMTP service id <02027-0@osi-west.es.net>; Tue, 29 Nov 1994 19:00:10 +0000 Received: from srb.UUCP by jaring.my with UUCP id AA25864 (5.67a/IDA-1.5 for rem-conf@es.net); Wed, 30 Nov 1994 10:59:59 +0800 Message-Id: <199411300259.AA25864@jaring.my> Received: from srb by srb.pl.my (UUPC/extended 1.12b) with UUCP; Wed, 30 Nov 1994 08:56:55 GMT From: Saravana Ram Balakrishnan To: rem-conf@es.net Date: Wed, 30 Nov 1994 08:56:54 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Join? Reply-To: Saravana Ram Balakrishnan X-Pmrqc: 1 Priority: normal X-Mailer: PMail v3.0 (R1a) Is think this is how you join? -- Saravana Ram Balakrishnan Tel: +60-3-255-9841 ram@srb.pl.my From rem-conf-request@es.net Wed Nov 30 08:53:56 1994 Received: from rx7.ee.lbl.gov by osi-west.es.net via ESnet SMTP service id <05034-0@osi-west.es.net>; Wed, 30 Nov 1994 05:53:27 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA05775; Wed, 30 Nov 94 05:56:34 -0800 Message-Id: <9411301356.AA05775@rx7.ee.lbl.gov> To: rem-conf@es.net Subject: vic v2.5 available for anonymous ftp Date: Wed, 30 Nov 94 05:56:34 PST From: Van Jacobson A new version of the UCB/LBL video tool vic is available for anonymous ftp from ftp.ee.lbl.gov in directory conferencing/vic. v2.5 fixes a number of problems that showed up in the initial release. Attached is a list of the changes. - Steve McCanne & Van Jacobson ----------------------------------- v2.5alpha Wed Nov 30 01:41:55 PST 1994 - sd.tcl script was wrong - vj used a "switch" construct in a "case" command which doesn't work. also forgot to say "global vic" before using $vic. - wasn't supplying correct timestamp in session messages in nv compat mode so nv-3.3 would occasionally 'lock up' ignoring either session or data packets. (bug reported by George Michaelson) - made first cut at support for 32-bit visuals (e.g., parallax card). (problem reported by Steve Casner) - fix long-standing bug in h261 decoding: were not swapping front & back buffers if only leftmost mba of gob was rendered. (problem reported by Graeme Wood) - was never using shared memory to talk to x server because of stupid initialization error. (bug & fix suggested by Greg Earle) - don't drop core in strlen() if we're given a video format we don't know about. From rem-conf-request@es.net Wed Nov 30 12:09:02 1994 Received: from comm.cpd.tandem.com by osi-west.es.net via ESnet SMTP service id <06174-0@osi-west.es.net>; Wed, 30 Nov 1994 09:08:37 +0000 Received: by comm.Tandem.COM (4.12/4.5) id AA10553; 30 Nov 94 09:09:03 -0800 Date: 30 Nov 94 08:51:00 -0800 From: KIM_ANDY@tandem.com Message-Id: <199411300909.AA10553@comm.Tandem.COM> To: rem-conf@es.net Subject: unsubscribe From rem-conf-request@es.net Wed Nov 30 12:43:16 1994 Received: from ietf.cnri.reston.va.us by osi-west.es.net via ESnet SMTP service id <06420-0@osi-west.es.net>; Wed, 30 Nov 1994 09:42:48 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa02179; 30 Nov 94 9:12 EST 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-06.txt Date: Wed, 30 Nov 94 09:12:10 -0500 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9411300912.aa02179@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, R. Frederick, V. Jacobson Filename : draft-ietf-avt-rtp-06.txt Pages : 47 Date : 11/28/1994 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 is augmented by a control protocol (RTCP) designed to provide minimal control and identification functionality, particularly in multicast networks. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. ***** DISCLAIMER: This document is not completed. See the Open Issues Section. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-06.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-06.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-06.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19941129165945.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-06.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19941129165945.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Wed Nov 30 17:38:18 1994 Received: from inet-gw-1.pa.dec.com by osi-west.es.net via ESnet SMTP service id <09333-0@osi-west.es.net>; Wed, 30 Nov 1994 14:37:51 +0000 Received: from oreo.pa.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA19476; Wed, 30 Nov 94 14:30:17 -0800 Received: by oreo.pa.dec.com; id AA02647; Wed, 30 Nov 94 14:30:16 -0800 Message-Id: <9411302230.AA02647@oreo.pa.dec.com> To: alpha-osf-managers Cc: rem-conf@es.net Subject: MBone tools for DEC Alphas Date: Wed, 30 Nov 94 14:30:16 -0800 From: berc@src.dec.com X-Mts: smtp I have copied the programs needed for putting an Alpha running OSF/1 V2.0 on the MBone into http://chocolate.pa.dec.com/mbone. They may move in the future. The page is aka ftp://chocolate.pa.dec.com/mbone. lance From rem-conf-request@es.net Wed Nov 30 20:15:36 1994 Received: from std.sri.com by osi-west.es.net via ESnet SMTP service id <10446-0@osi-west.es.net>; Wed, 30 Nov 1994 17:15:04 +0000 Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1) id AA13924; Wed, 30 Nov 94 17:13:57 PST Message-Id: <9412010113.AA13924@std.sri.com> To: confctrl@isi.edu, rem-conf@es.net Cc: tfrivold@std.sri.com, rlang@std.sri.com Subject: MMUSIC Agenda Date: Wed, 30 Nov 1994 17:14:00 -0800 From: Ruth Lang Folks, Enclosed is a near final agenda. I will send it for redistribution via ietf-announce tomorrow morning, so please send any updates or comments to me on it by then. Please note and read the 6 session control survey responses received (see either ftp://venera.isi.edu/confctrl/surveys or ftp://ws11.std.sri.com/pub/confctrl/surveys). Also, if you haven't yet sent your response, please do for posting to these two ftp sites. Regards, Ruth ---------------------------------- MMUSIC Working Group Meeting Wednesday, December 7, 1994 16:00-18:00 16:00-16:05 Meeting Overview and Agenda Review (Ruth Lang, SRI) 16:05-16:15 ITU Generic Conference Control Update (Joerg Ott, Technical University of Berlin) 16:15-17:00 Progress on Agreement Protocol (Abel Weinrib, Intel and Ted Ko, MIT/Bellcore) 17:00-17:25 Session Protocol Functional Requirements Discussion - Survey Report (Thane Frivold, SRI and Ruth Lang, SRI) - Requirements for Horizontal and Vertical Conference Control Protocols (Carsten Bormann, U. of Bremen, Joerg Ott, Technical University of Berlin) 17:25-17:45 Session Description Functional Requirements Discussion (Mark Handley, UCL, Thane Frivold, SRI, and Ruth Lang, SRI) 17:45-18:00 Discussion of Working Group Direction and Charter Modification (Thane Frivold, SRI and Ruth Lang, SRI) From rem-conf-request@es.net Wed Nov 30 22:16:38 1994 Received: from SERV02.SLAC.Stanford.EDU by osi-west.es.net via ESnet SMTP service id <11231-0@osi-west.es.net>; Wed, 30 Nov 1994 19:15:48 +0000 Received: from SLACVM.SLAC.STANFORD.EDU (MAILER@SLACVM) by SERV02.SLAC.STANFORD.EDU (PMDF V4.3-10 #6987) id <01HK3NRYSJ7K000EUN@SERV02.SLAC.STANFORD.EDU>; Wed, 30 Nov 1994 19:15:31 -0800 (PST) Received: by SLACVM (Mailer R2.08 R208004) id 9068; Wed, 30 Nov 94 19:14:56 PST Date: Wed, 30 Nov 1994 19:06 -0800 (PST) From: "Charles Granieri 415-926-2844, FAX:926-3329" Subject: SPARC 5s and VideoPIX To: rem-conf@es.net Message-id: <01HK3NRZ6QEQ000EUN@SERV02.SLAC.STANFORD.EDU> X-Envelope-to: rem-conf@es.net Content-transfer-encoding: 7BIT We have just bought two SPARC 5 workstations to use for MBone video conferencing. We are running SunOS 4.1.3_U1 with multicast kernel mods. When we try to load the VideoPix software from CDRom, it exits and says that the software will only work on Sun4c machines. Can someone please tell me how to get the VideoPix drivers loaded on a SPARC 5? Thanks for your help, Charley Granieri SLAC From rem-conf-request@es.net Wed Nov 30 23:10:42 1994 Received: from rpi.edu by osi-west.es.net via ESnet SMTP service id <11546-0@osi-west.es.net>; Wed, 30 Nov 1994 20:10:00 +0000 Received: from hibp.ecse.rpi.edu (hibp7.ecse.rpi.edu) by rpi.edu (4.1/SMHUB41); id AA08606; Wed, 30 Nov 94 23:09:56 EST for rem-conf@es.net Received: from hibp6.ecse.rpi.edu by hibp.ecse.rpi.edu (4.1/ST26); id AA11904 for rem-conf@es.net; Wed, 30 Nov 94 23:09:55 EST Message-Id: <9412010409.AA11904@hibp.ecse.rpi.edu> To: "Charles Granieri 415-926-2844, FAX:926-3329" Cc: rem-conf@es.net Subject: Re: SPARC 5s and VideoPIX In-Reply-To: Your message of "Wed, 30 Nov 1994 19:06:00 PST." <01HK3NRZ6QEQ000EUN@SERV02.SLAC.STANFORD.EDU> X-Mailer: exmh version 1.4zeta 6/3/94 Date: Wed, 30 Nov 1994 23:09:51 -0500 From: Paul Stewart > We have just bought two SPARC 5 workstations to use for MBone video > conferencing. We are running SunOS 4.1.3_U1 with multicast kernel > mods. When we try to load the VideoPix software from CDRom, it exits > and says that the software will only work on Sun4c machines. Can someone > please tell me how to get the VideoPix drivers loaded on a SPARC 5? Disreguard that error. That comes from the install_unbundled script if I remember correctly. The install script is out of date and does not recognize the sun4m architecture. Go straight ahead and find the vfc.INSTALL script, which is on the same CD-ROM. That will install what you need. -- Paul From rem-conf-request@es.net Wed Nov 30 23:54:16 1994 Received: from as0a.sei.cmu.edu by osi-west.es.net via ESnet SMTP service id <11799-0@osi-west.es.net>; Wed, 30 Nov 1994 20:53:42 +0000 Received: from ij.sei.cmu.edu by as0a.sei.cmu.edu (8.6.9/3.00) id XAA29595; Wed, 30 Nov 1994 23:46:13 -0500 Received: from localhost.sei.cmu.edu by ij.sei.cmu.edu (8.6.9/3.00) id XAA09823; Wed, 30 Nov 1994 23:44:26 -0500 Message-Id: <199412010444.XAA09823@ij.sei.cmu.edu> To: jain@engin.umich.edu, jajodia@sitevax.gmu.edu, jakobs@informatik.rwth-aachen.de, jeffay@cs.unc.edu, mrj@rod.mitre.org, kado@isl.hiroshima-u.ac.jp, kahn@parc.xerox.com, tkarren@ingres.com, kawagoe@tsl.cl.nec.co.jp, rnk@SEI.CMU.EDU, keith@pioneer.arc.nasa.gov, klas@icsi.berkeley.edu, korfhage@icarus.lis.pitt.edu, korfhage@weston.poly.edu, hfk@mitl.com, fl08+@andrew.cmu.edu, lam@cs.utexas.edu, laukee@canon.co.uk, dlee@cis.ohio-state.edu, klaus@informatik.rwth-aachen.de, ying@saturn.cs.swin.oz.au, haim@cs.uml.edu, ylien@ihlpy.att.com, hlinger@fcit.monash.edu.au, tdcl@ENGA.BU.EDU, sdl@mitre.org, liu@ernie.scr.siemens.com, maraninx@imag.imag.fr, rmarcus@atc.boeing.com, h133mar@ella.hu, 71431.3312@compuserve.com, edward.martini@eng.sun.com, masui@shpcsl.sharp.co.jp, pmatsira%wcu.BITNET@MitVMA.Mit.Edu, rajiv@ms.uky.edu, kmw@informatik.uni-erlangen.de, midkiff@vtvm1.cc.vt.edu, miyamoto@shpcsl.sharp.co.jp, miyao@mis.hiroshima-u.ac.jp, morimoto@trlvm.vnet.ibm.com, bam@a.gp.cs.cmu.edu, klara@GRADIENT.CIS.UPENN.EDU, neuhold@darmstadt.gmd.de, nigam@mitre.org, okamoto@csd.sumikin.co.jp, ola@adm.csc.ncsu.edu, osborne@software.org, ozsu@cs.ualberta.ca, cap1@thumper.bellcore.com, pax@ankh.metrolink.com, pezze@ipmel2.elet.polimi.it, picone@csc.ti.com, rakow@darmstadt.gmd.de, wilko@informatik.rwth-aachen.de, s.reisman@compmail.com, riedl@hannibal.cs.umn.edu, roman@wucs1.wustl.edu, marek@uh.edu, sato@huis.hiroshima-u.ac.jp, schnorf@canon.com, schooler@isi.edu, schwan@cc.gatech.edu, cts@cs.hut.fi, senay@seas.gwu.edu, mshakar@vrit01.eg, shan@hplmcs.hpl.hp.com, shekhar@cs.umn.edu, sheng@mis.arizona.edu, bjshep@ausvm6.vnet.ibm.com, ben@cs.umd.edu, sinha@trl.mei.co.jp, sklar@era.com, son@server.cs.Virginia.EDU, asood@gmuvax.gmu.edu, speegle@mercury.baylor.edu, steinmet%dhdibm1.BITNET@MitVMA.Mit.Edu, sms@SEI.CMU.EDU, pds@cis.ufl.edu, stro@merl.com, jks@usa.ece.cmu.edu, sugihara@freiland.ics.hawaii.edu, deborah@citi.umich.edu, pete@icbl.heriot-watt.ac.uk, tanimoto@cs.washington.edu, tappan@software.org, tsotras@kanchi.poly.edu, jurban@enws104.eas.asu.edu, ventre@icsi.berkeley.edu, vetter@cs.umn.edu, walpole@cse.ogi.edu, wei@csufres.csufresno.edu, kywhang@mozart.kaist.ac.kr, klwu@watson.ibm.com, wuu@ctt.bellcore.com, yama@trdc008.csc.ti.com, yoshi@huis.hiroshima-u.ac.jp, yu@dbis.eecs.uic.edu, psyu@watson.ibm.com, magda@PENDER.EE.UPENN.EDU, znati@cs.pitt.edu, blattner@ocfkms.llnl.gov, jol@hpl.hp.com, mmm-people@isi.edu, rem-conf@es.net, nik@clos.nnov.su, kas@clos.nnov.su, Geoff Coulson Subject: CFP: IEEE Real-Time Technology and Applications Symposium Date: Wed, 30 Nov 94 23:44:26 EST From: Ragunathan Rajkumar CALL FOR PAPERS =============== IEEE Real-Time Technology and Application Symposium =================================================== May 15-17, 1995 Chicago Since the early 80's, we have witnessed an increased interest in real-time technology because of the need for scientific solutions for time-constrained information processing in various applications such as avionics, multimedia, robotics, automated process control, and manufacturing. Founded in 1983, the IEEE Workshop on Real-Time Operating Systems and Software (RTOSS) has been an important annual forum for exchanging information of emerging principles and practices underlying real-time technology. Consequently, we are seeing a substantial number of new researchers tackling the many challenging problems that remain. Due to the interest shown in, and the success of, the RTOSS, the IEEE technical committee on real-time systems has decided to convert RTOSS into a full symposium entitled: Real-Time Technology and Applications Symposium. The purpose of this symposium is to bring together developers and researchers from universities, industry, and government to advance real-time technology and its applications. Papers on all aspects of real-time computing are sought, including operating systems and scheduling, fault-tolerance, databases, programming languages, tools, communication networks, architectures, performance modeling, formal methods, case studies, and applications. Of particular interest are papers detailing experiments and implementations. This year we are planning special sessions in the areas such as Intelligent Vehicle Highway Systems and Multimedia. Papers on these topics are especially encouraged. Manuscripts should be limited to 20 double spaced pages. Papers submitted to the Symposium should not be submitted elsewhere. Six copies of the paper should reach the program chair no later than January 7, 1995. Authors will be notified of acceptance by Feb 28, 1995. Final camera-ready manuscripts will be due by March 31, 1995. Proposals for two-hour tutorials in technical areas of the conference are also solicited. Tutorial proposals should be submitted to the program chair by January 7, 1995. Important Dates =============== Paper submission: Jan 7, 1995 Tutorial proposal submission: Jan 7, 1995 Acceptance notification: Feb 28, 1995 Final camera-ready manuscript: Mar 31, 1995 ORGANIZING AND PROGRAM COMMITTEES General Chair: Ted Baker Department of Computer Science (4019) Florida State University Tallahassee, FL 32306-4019 phone: 904 644-5452 email: baker@cs.fsu.edu Program Chair: Wei Zhao Department of Computer Science Texas A&M University College Station, TX 77843-3112 phone: 409 845-5098 email: zhao@cs.tamu.edu Treasurer: Ted Giering, Florida State University Publicity Chair: Raj Rajkumar, Software Engineering Institute, CMU Local Arrangements Co-Chairs: Jeffrey Tsai, University of Illinois at Chicago Chengwen Liu, DePaul University Ex-Officio: (RTS-TC Chairs) John Stankovic, University of Massachusetts at Amherst Al Mok, University of Texas at Austin Program Committee: Yahya Y. Al-Salqan West Virginia University Sadler Bridge Texas Transportation Institute/TAMU Alan Burns University of York Richard Gerber University of Maryland Prabha Gopinath Honeywell Inc Steve Howell Navy Surface Warfare Center Jiandong Huang Honeywell Inc Arkady Kanevsky Mitre Corporation Jane Liu University of Illinois at Urbana Steve Liu Texas A&M University Doug Locke Loral Federal Systems David Luginbuhl AFOSR Al Mok University of Texas at Austin Kelvin Nilsen Iowa State University Krithi Ramamritham University of Massachusetts at Amherst Lui Sha Software Engineering Institute/CMU Kang Shin University of Michigan John Stankovic University of Massachusetts at Amherst Alexander D. Stoyenko NJ Institute of Technology Lonnie R. Welch NJ Institute of Technology Victor Wolfe University of Rhode Island Hui Zhang Carnegie Mellon University