From rem-conf-request@es.net Fri Mar 01 04:29:06 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 1 Mar 1996 01:28:31 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA25704; Fri, 1 Mar 1996 01:28:30 -0800 Date: Fri, 1 Mar 1996 01:28:30 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: Agenda for AVT at LA IETF Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Audio/Video Transport Working Group: A meeting of the Audio/Video Transport working group will be held at IETF in Los Angeles next week to discuss several issues raised on this rem-conf list over the past few weeks. We will cover several of the topics that Ross Finlayson suggested in his message calling for a meeting that started the discussion. As he noted, it may be too early for any substantial discussion of interoperability among "industry" participants, however: _________________________________________________________________ | | | Representatives of organizations developing RTP-based | | applications are invited to say a few words about their plans | | to use RTP, or if their plans are not to use RTP, to say what | | problems they have with RTP. | |_________________________________________________________________| A proposed agenda follows. There will be several presentations of 10-15 minutes each, followed by discussion. The quality of the discussion largely depends, of course, on the ideas you all bring to the meeting! -- Steve Casner Audio/Video Transport WG A G E N D A Tuesday, March 5, 13:00-15:00 - Proposed new payload formats - Hierarchical encodings [Michael Speer, Sun] - H.263 [Chad Zhu, Intel] - Redundant encodings [Mark Handley, UCL] - Multiplexed audio, video, image [Tim Kwok, Microsoft] - RTP header compression [Ed Ellesson, IBM] - RTP and MBone monitoring - Tracking session participants [Kevin Almeroth, GA Tech] - Using RTCP feedback [???] - Fostering interoperation through industry adoption of RTP - Brief comments from industry participants if present - Organizing RTP "connectathons" and conformance testing - AVT logistics - Is there new work for a new AVT charter? - Extending RTP for applications other than audio/video - Should AVT and MMUSIC be merged (or AVT expire)? - Other topics, time permitting - One vs. two source ports in RTP loop/collision algorithm - How to transition to RTPv2 audio on MBone (if not covered in MMUSIC) - Should there be an interface service definition for RTP? - ITU-T incorporation of RTP spec into H.225.0 From rem-conf-request@es.net Fri Mar 01 08:00:31 1996 Received: from simon.cs.cornell.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 1 Mar 1996 04:59:50 -0800 Received: from cloyd.cs.cornell.edu (CLOYD.CS.CORNELL.EDU [128.84.227.15]) by simon.cs.cornell.edu (8.6.10/R1.4) with ESMTP id HAA24489 for ; Fri, 1 Mar 1996 07:59:48 -0500 Received: from skadi.cs.cornell.edu (SKADI.CS.CORNELL.EDU [128.84.254.219]) by cloyd.cs.cornell.edu (8.6.10/M1.8) with ESMTP id HAA26826 for ; Fri, 1 Mar 1996 07:59:47 -0500 From: Daisuke Sasaki Received: (sasaki@localhost) by skadi.cs.cornell.edu (8.6.10/C1.3) id HAA21972; Fri, 1 Mar 1996 07:59:44 -0500 Date: Fri, 1 Mar 1996 07:59:44 -0500 Message-Id: <199603011259.HAA21972@skadi.cs.cornell.edu> To: rem-conf@es.net Subject: unsubscribe unsubscribe From rem-conf-request@es.net Fri Mar 01 11:29:31 1996 Received: from mercury.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Fri, 1 Mar 1996 08:29:03 -0800 Received: by mercury.Sun.COM (Sun.COM) id IAA10046; Fri, 1 Mar 1996 08:29:02 -0800 Received: from rebma. (rebma-i.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00824; Fri, 1 Mar 1996 08:28:59 -0800 Received: by rebma. (5.x/SMI-SVR4) id AA01376; Fri, 1 Mar 1996 08:21:04 -0800 Date: Fri, 1 Mar 1996 08:21:04 -0800 From: hoffman@rebma.Eng.Sun.COM (Don Hoffman) Message-Id: <9603011621.AA01376@rebma.> To: rem-conf@es.net, Christian_Maciocco@ccm.jf.intel.com Subject: Re: draft-speer-mccanne-avt-layered-video-00.txt X-Sun-Charset: US-ASCII >From: Christian Maciocco > > By using a single SRCID space for all layers and having RTCP aggregate > the layers report, I think that we lose important per-layer feedback > information. > Although the SRCID space is shared for all layers, the Sender and Receiver reports are done on a per layer basis. Only the SDES is confined to the core layer. Don From rem-conf-request@es.net Sat Mar 02 19:55:12 1996 Received: from bmrc.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Sat, 2 Mar 1996 16:54:35 -0800 Received: from garfield.CS.Berkeley.EDU (garfield.CS.Berkeley.EDU [128.32.32.118]) by bmrc.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id QAA06455 for <298@bmrc.Berkeley.EDU>; Sat, 2 Mar 1996 16:51:18 -0800 Received: from garfield.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by garfield.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id QAA14029; Sat, 2 Mar 1996 16:51:16 -0800 Message-Id: <199603030051.QAA14029@garfield.CS.Berkeley.EDU> From: Andrew Swan To: 298@bmrc.Berkeley.EDU cc: rowe@cs.berkeley.edu Subject: UC Berkeley Multimedia Seminar 3/6/96 - "Blending Technology and Entertainment using Java" X-URL: http://www.cs.berkeley.edu/~aswan/ Date: Sat, 02 Mar 1996 16:51:15 -0800 Sender: aswan@bugs-bunny.CS.Berkeley.EDU This week's Berkeley Multimedia and Graphics seminar will be held Wednesday, March 6, from 12:30 - 2:00 PST in 405 Soda Hall. The speaker will be Karl Jacob from Dimension X, discussing "Blending Technology and Entertainment using Java." The talk will be broadcast on the Internet MBONE, beginning at roughly 12:40 PM PST. Please note that you will need vic 2.7 to watch the broadcast. Pre-compiled vic binaries for most architectures are available from: ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test/ Questions should be directed to Larry Rowe (rowe@cs.berkeley.edu) Abstract: Java provides the core functionality for blending different types of media on the Net. However, the language itself and the tools for working with different types of media are lacking. Dimension X has spent the last year developing technology and tools to allow content providers and technologists to overcome these problems. This talk will cover some of our recent work and the tools used to create them. -- Andrew Swan aswan@cs.berkeley.edu Plateau Multimedia Research Group http://www.cs.berkeley.edu/~aswan/ From rem-conf-request@es.net Sun Mar 03 06:19:01 1996 Received: from cronopio.ibase.br by osi-west.es.net with ESnet SMTP (PP); Sun, 3 Mar 1996 03:18:25 -0800 Received: from ax.ibase.br (ax.ibase.br [200.18.178.1]) by cronopio.ibase.br (8.6.12/Revision: 1.203 ) with SMTP id IAA08686 for ; Sun, 3 Mar 1996 08:14:35 -0300 Received: from DESKTOP (estacao@du-15.du.ibase.org.br [200.18.179.15]) by ax.ibase.br (8.6.12/Revision: 1.14 ) with SMTP id IAA20865 for ; Sun, 3 Mar 1996 08:09:51 -0300 Date: Sun, 3 Mar 1996 08:09:51 -0300 Message-Id: <199603031109.IAA20865@ax.ibase.br> X-Sender: brunovianna@ax.ibase.org.br (Unverified) X-Mailer: Windows Eudora Version 1.4.4 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: bruno@rdc.puc-rio.br.br (Bruno Vianna) Subject: unsubscribe Sender: estacao@du-15.du.ibase.org.br unsubscribe bruno@rdc.puc-rio.br From rem-conf-request@es.net Mon Mar 04 05:29:44 1996 Received: from rzdspc1.informatik.uni-hamburg.de by osi-west.es.net with ESnet SMTP (PP); Mon, 4 Mar 1996 02:28:59 -0800 Received: from ro2.informatik.uni-hamburg.de (ro2.informatik.uni-hamburg.de [134.100.15.162]) by rzdspc1.informatik.uni-hamburg.de (8.7.4/8.7.4) with SMTP id LAA15638 for ; Mon, 4 Mar 1996 11:28:56 +0100 (MET) Received: from ro4.informatik.uni-hamburg.de by ro2.informatik.uni-hamburg.de (4.1/SMI-4.1/RZ-1.04/s) with SMTP id ; Mon, 4 Mar 96 11:28:14 +0100 From: richter@ro2.informatik.uni-hamburg.de (Jan-Peter Richter) Message-Id: <9603041028.AA03986@ro2.informatik.uni-hamburg.de> Subject: Info on vic SW architecture wanted To: rem-conf@es.net Date: Mon, 4 Mar 1996 11:28:54 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Hi all! I want to use vic for my research in the area of QoS management. Where can I find _detailed_ information about the software architecture of vic? I have already read Steve McCanne and Van Jacobson's, "vic: A Flexible Framework for Packet Video" in ACM Multimedia. However, this is by far not enough to work with the code. (At least it would be very helpful to have some kind of a documentation instead of having to guess from reading the code.) I'll have to write some extensions and I want to fix a bug that I have reported to this list earlier: h261-mode doesn't work with VideoPix and a PAL camera. Any help? Jan-Peter Richter ------------------------------------------------------------------------------ Jan-Peter Richter Vogt-Koelln-Str.30 Universitaet Hamburg D-22527 Hamburg Fachbereich Informatik Tel: +49 40 54715-344 Arbeitsbereich Rechnerorganisation Fax: +49 40 54715-345 e-mail: richter@informatik.uni-hamburg.de ------------------------------------------------------------------------------ From rem-conf-request@es.net Mon Mar 04 07:55:55 1996 Received: from rzdspc1.informatik.uni-hamburg.de by osi-west.es.net with ESnet SMTP (PP); Mon, 4 Mar 1996 04:55:18 -0800 Received: from ro2.informatik.uni-hamburg.de (ro2.informatik.uni-hamburg.de [134.100.15.162]) by rzdspc1.informatik.uni-hamburg.de (8.7.4/8.7.4) with SMTP id NAA18236 for ; Mon, 4 Mar 1996 13:55:14 +0100 (MET) Received: from ro4.informatik.uni-hamburg.de by ro2.informatik.uni-hamburg.de (4.1/SMI-4.1/RZ-1.04/s) with SMTP id ; Mon, 4 Mar 96 13:54:32 +0100 From: richter@ro2.informatik.uni-hamburg.de (Jan-Peter Richter) Message-Id: <9603041254.AA05338@ro2.informatik.uni-hamburg.de> Subject: Re: Info on vic SW architecture wanted To: rem-conf@es.net Date: Mon, 4 Mar 1996 13:55:11 +0100 (MET) In-Reply-To: <313ADA5A.5ADB@uab.ericsson.se> from "Jakob Ellerstedt" at Mar 4, 96 12:56:10 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text > > Well, I have tried to contact tehm about their code, escpecially the > framegrabbing part > where they got some non-disclosure info from SUN how to grab frame without > using > the XIL-library. I asked to get the function > prototypes, but no answer was received. Merely using the XIL-library doesn't > provide one with a good solution. > > Anyway, hope you get your info! > > Take care! > > Jakob > Ericsson Research and Development > Stockholm > > Jan-Peter Richter wrote: > > > > Hi all! > > > > I want to use vic for my research in the area of QoS management. Where can > > I find _detailed_ information about the software architecture of vic? [...] Thank you for your comment! However, I don't think I need _that_ detailed information (at least not yet). May be I should be more specific on what kind of information I need: 1.) How does the technique of compiling tcl into c++ (via tcl2c++) work? (sorry, but I'm a newbee to TCL/TK) 2.) there are 81 .cc files and 21 .tcl files: which does what? 3.) How is the class hierarchy of all the c++ objects organized? 4.) ... Thanks Jan-Peter Richter From rem-conf-request@es.net Mon Mar 04 11:09:48 1996 Received: from cc.va.us (actually email.vw.cc.va.us) by osi-west.es.net with ESnet SMTP (PP); Mon, 4 Mar 1996 08:09:08 -0800 Received: from VWCC#u#03-Message_Server by cc.va.us with Novell_GroupWise; Mon, 04 Mar 1996 11:13:29 -0500 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 04 Mar 1996 11:09:57 -0500 From: David Richardson To: rem-conf@es.net Subject: How do I get off this listserv? From rem-conf-request@es.net Mon Mar 04 17:52:15 1996 Received: from elaine.crcg.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 4 Mar 1996 14:51:38 -0800 Received: from condor.crcg.edu by elaine.crcg.edu (4.1/SMI-4.1) id AA16437; Mon, 4 Mar 96 17:51:47 EST Received: by condor.crcg.edu (940816.SGI.8.6.9/SMI-4.0) id WAA10581; Mon, 4 Mar 1996 22:51:08 GMT Date: Mon, 4 Mar 1996 22:51:08 +0000 From: Mike Macedonia X-Sender: mmacedon@condor To: rem-conf@es.net Subject: Thinkpad 850 In-Reply-To: <199602040248.SAA05772@shellx.best.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone have any experience trying to run any mbone tools on the IBM Thinkpad 850 (AIX with PowerPC)? It has an integrated video cam. Thanks, - Mike ----------------------------------------------------------------- | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | | Vice President | EMAIL: mmacedon@crcg.edu | | Fraunhofer CRCG | | | 167 Angell Street | PH : (+1) 401 453-6363 | | Providence, RI 02906 | FAX: (+1) 401 453-0444 | ----------------------------------------------------------------- From rem-conf-request@es.net Tue Mar 05 04:18:24 1996 Received: from red-05-imc.itg.microsoft.com by osi-west.es.net with ESnet SMTP (PP); Tue, 5 Mar 1996 01:17:47 -0800 Received: by red-05-imc.itg.microsoft.com with Microsoft Exchange (IMC 4.0.829.1) id <01BB0A31.9CEA32D0@red-05-imc.itg.microsoft.com>; Tue, 5 Mar 1996 01:18:08 -0800 Message-ID: From: Scott Henson To: "'webmaster@cilea.it'" Cc: "'rem-conf@es.net'" Subject: Our conference listed three times Date: Tue, 5 Mar 1996 01:18:01 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.829.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have just submitted an MBone broadcast that we will be making on March 13th from our Professional Developers Conference. The unfortunate thing is it looks like it is listed three times. Can you please reduce this to one listing? In addition, can you please shorten the title to be "Microsoft Professional Developers Conference"?. It does not want to show up on the screen when the title is that long. Let me know if you would like for me to do anything further. Thanks! Scott Henson Microsoft Corporation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D E-Mail : scotthe@microsoft.com scott_henson_ms@msn.com Phone : (206) 936-9762 Pager : 1-800-SKY-GRAM / pin=3D1410082 Fax : (206) 936-7329 Address : One Microsoft Way Redmond, WA 98052-6399 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =00 From rem-conf-request@es.net Tue Mar 05 09:32:18 1996 Received: from elaine.crcg.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 5 Mar 1996 06:31:51 -0800 Received: from condor.crcg.edu by elaine.crcg.edu (4.1/SMI-4.1) id AA20238; Tue, 5 Mar 96 09:32:00 EST Received: by condor.crcg.edu (940816.SGI.8.6.9/SMI-4.0) id OAA15796; Tue, 5 Mar 1996 14:29:15 GMT Date: Tue, 5 Mar 1996 14:29:15 +0000 From: Mike Macedonia X-Sender: mmacedon@condor To: rem-conf@es.net Subject: Laptops in general Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A follow-up to the Thinkpad question: has anyone had any success running mbone tools (especially video) on any laptop? Thanks, - Mike ----------------------------------------------------------------- | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | | Vice President | EMAIL: mmacedon@crcg.edu | | Fraunhofer CRCG | | | 167 Angell Street | PH : (+1) 401 453-6363 | | Providence, RI 02906 | FAX: (+1) 401 453-0444 | ----------------------------------------------------------------- From rem-conf-request@es.net Tue Mar 05 12:03:05 1996 Received: from red-05-imc.itg.microsoft.com by osi-west.es.net with ESnet SMTP (PP); Tue, 5 Mar 1996 09:02:31 -0800 Received: by red-05-imc.itg.microsoft.com with Microsoft Exchange (IMC 4.0.829.1) id <01BB0A72.8784D6C0@red-05-imc.itg.microsoft.com>; Tue, 5 Mar 1996 09:02:49 -0800 Message-ID: From: Lee Fisher To: "'rem-conf@es.net'" Subject: MBone broadcast of Microsoft Internet developer's conference Date: Tue, 5 Mar 1996 09:02:42 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.829.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [I apologize that this was not sent to Rem-Conf the traditional 2 weeks in advance, I'm rather new to MBone...] Microsoft will be broadcasting on the Mbone sessions from the Microsoft Internet Developers Conference that will be held in San Francisco on March 11-14. Brief description: Eight hours of nothing but the Internet for the developer. What role will you, Microsoft and other companies play in the Internet space? Expect announcements on Microsoft's Internet Client Architecture ("Sweeper"), Internet Server Architecture to BackOffice to Operating Systems. You'll also get the facts on how to use the new Internet-focused Win32 and OLE functionality to build powerful Internet applications. The broadcast times (GMT): March 13 1996, 16:00:00 GMT (8:00 am PST) to=20 March 14 1996, 02:00:00 GMT (6:00 am PST) For a broadcast schedule of talks, see http://www.microsoft.com/devmovies/ (but please re-check this page closer to broadcast time, I believe the schedule will change one more time). For more general info on the conference, see http://www.microsoft.com/showcase/intpdc/default.htm. For more infomation on most of the technical details referenced in the talks, see http://www.microsoft.com/intdev/. During the show, our web server's main page, and this /intdev/ page will contain more up-to-date information. The sessions will be broadcast on the Internet MBONE using the audio tool vat=20 and the video tool vic. Session announcements will be made with sd.=20 You will=20 need vic 2.7 to watch the broadcast. Pre-compiled vic binaries for most architectures are available from: ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test/ Questions about the broadcast can be directed to Andrew Swan (aswan@cs.berkeley.edu). Thanks, Lee __ Lee Fisher, leefi@microsoft.com =00 From rem-conf-request@es.net Tue Mar 05 12:11:24 1996 Received: from MVS.OAC.UCLA.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 5 Mar 1996 09:10:40 -0800 Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 5194; Tue, 05 Mar 96 09:11:38 PST Date: Tue, 05 Mar 96 09:11 PST To: Mike Macedonia From: Denis DeLaRoca (310) 825-4580 Subject: Re: Laptops in general Cc: rem-conf@ES.NET On Tue, 5 Mar 1996 14:29:15 +0000, Mike Macedonia said: > > A follow-up to the Thinkpad question: > > has anyone had any success running mbone tools (especially video) on any > laptop? Or should it be Windows, Linux or FreeBSD? :-) >From what I hear, the FreeBSD ported tools are the most stable. But until recently FreeBSD laptop support has lagged behind that of Linux. The Apple Quicktime TV team has developed some MBONE tools but last I checked they hadn't tested them on MAC Powerbooks. There's always the Sparc laptops from Tadpole and BRI but those, like the AIX laptop, are expensive solutions. It'd be nice to have a Linux/ FreeBSD notebook with a PCMCIA video grabber... -- Denis From rem-conf-request@es.net Tue Mar 05 12:55:08 1996 Received: from hosaka.smallworks.com by osi-west.es.net with ESnet SMTP (PP); Tue, 5 Mar 1996 09:54:10 -0800 Received: from butthead.SmallWorks.COM by hosaka.smallworks.com (5.x/SMI-SVR4) id AA11623; Tue, 5 Mar 1996 11:54:06 -0600 Received: by butthead.SmallWorks.COM (4.1/SPARCbook_POP1.3) id AA01922; Tue, 5 Mar 96 11:52:06 CST From: Jim Thompson Message-Id: <9603051152.ZM1920@butthead.smallworks.com> Date: Tue, 5 Mar 1996 11:52:04 -0600 In-Reply-To: Mike Macedonia "Laptops in general" (Mar 5, 2:29pm) References: X-Mailer: Z-Mail (3.2.1 10oct95) To: Mike Macedonia , rem-conf@es.net Subject: Re: Laptops in general Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 5, 9:11am, Denis DeLaRoca (310) 825-4580 wrote: > Subject: Re: Laptops in general > On Tue, 5 Mar 1996 14:29:15 +0000, > Mike Macedonia said: > > > > A follow-up to the Thinkpad question: > > > > has anyone had any success running mbone tools (especially video) on any > > laptop? A couple years ago, I put the SunOS 4.1.x multicast distribution inside the SPARCbook, and SPARCbook2. For years, Tadpole's mrouter was an otherwise unusable SPARCbook (8MB of mem, 120MB of disk.) The only real work in this was dealing with the Fuji ethernet chip. With the advent of Tadpole's 3rd generation hardware, the distributions should, for the most part, drop-in (if you can live without the save/resume 'feature'.) As for the tools, Audio 'just worked'. Video never got done for various reasons. Jim From rem-conf-request@es.net Tue Mar 05 15:28:54 1996 Received: from atg.apple.com by osi-west.es.net with ESnet SMTP (PP); Tue, 5 Mar 1996 12:28:09 -0800 Received: from [17.255.9.185] (max1.atg.apple.com [17.255.9.185]) by atg.apple.com (8.7.2/8.6.12) with SMTP id MAA26417 for ; Tue, 5 Mar 1996 12:29:29 -0800 (PST) Date: Tue, 5 Mar 1996 12:29:29 -0800 (PST) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-URL: http://interstice.com/~max/ To: rem-conf@es.net From: max@atg.apple.com (Mark Q. Maxham) Subject: multicast-to-unicast gateway? Has anyone written a multicast-to-unicast gateway for RTPv2? Such an app would sit on a multicast-capable host and listen for receiver reports or source descriptions coming over a unicast channel, and take those as a cue for where to redirect the packets. Of course, there are hairy issues concerning mapping sd entries, and this would just be a stopgap. I'm interested in hearing about any attempts to include the multicast-impaired until everyone has it. max From rem-conf-request@es.net Tue Mar 05 16:19:52 1996 Received: from joyride.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 5 Mar 1996 13:18:43 -0800 Received: from joyride.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by joyride.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id NAA26864; Tue, 5 Mar 1996 13:18:40 -0800 From: Elan Amir Message-Id: <199603052118.NAA26864@joyride.CS.Berkeley.EDU> To: max@atg.apple.com (Mark Q. Maxham) cc: rem-conf@es.net Subject: Re: multicast-to-unicast gateway? In-reply-to: Your message of "Tue, 05 Mar 1996 12:29:29 PST." Date: Tue, 05 Mar 1996 13:18:39 -0800 > Has anyone written a multicast-to-unicast gateway for RTPv2? Such an app > would sit on a multicast-capable host and listen for receiver reports or > source descriptions coming over a unicast channel, and take those as a cue > for where to redirect the packets. > > Of course, there are hairy issues concerning mapping sd entries, and this > would just be a stopgap. I'm interested in hearing about any attempts to > include the multicast-impaired until everyone has it. > > max > > Hi Mark, There exists a video gateway, vgw, which will do what you want. The gateway is bidirectional and will transcode or forward RTPv2 video traffic between two RTPv2 sessions either of which can be unicast or multicast. Source and binaries are available from: ftp://daedalus.cs.berkeley.edu/pub/vgw/alpha-test -- Elan From rem-conf-request@es.net Tue Mar 05 16:49:28 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Tue, 5 Mar 1996 13:48:17 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id NAA00606; Tue, 5 Mar 1996 13:46:48 -0800 Message-Id: <199603052146.NAA00606@rah.star-gate.com> To: Denis DeLaRoca 825-4580 (310) cc: Mike Macedonia , rem-conf@es.net Subject: Re: Laptops in general In-reply-to: Your message of "Tue, 05 Mar 1996 09:11:00 PST." <199603052121.NAA00396@rah.star-gate.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <603.826062408.1@rah.star-gate.com> Date: Tue, 05 Mar 1996 13:46:48 -0800 From: "Amancio Hasty Jr." Hi, If a laptop has a parallel port then I don't see any reasons why a Quickcam with nv or vic will not work. Does anyone have a good pointer for pcmia video grabbers and of course a pointer to how to program the pcimia grabber. Amancio >>> Denis DeLaRoca 825-4580 said: > On Tue, 5 Mar 1996 14:29:15 +0000, > Mike Macedonia said: > > > > A follow-up to the Thinkpad question: > > > > has anyone had any success running mbone tools (especially video) on any > > laptop? > > Or should it be Windows, Linux or FreeBSD? :-) > > >From what I hear, the FreeBSD ported tools are the most stable. But > until recently FreeBSD laptop support has lagged behind that of Linux. > > The Apple Quicktime TV team has developed some MBONE tools but last > I checked they hadn't tested them on MAC Powerbooks. > > There's always the Sparc laptops from Tadpole and BRI but those, like > the AIX laptop, are expensive solutions. It'd be nice to have a Linux/ > FreeBSD notebook with a PCMCIA video grabber... > > -- Denis > From rem-conf-request@es.net Tue Mar 05 22:47:48 1996 Received: from virginia.edu (actually mars.itc.Virginia.EDU) by osi-west.es.net with ESnet SMTP (PP); Tue, 5 Mar 1996 19:47:03 -0800 Received: from archive.cs.virginia.edu by mail.virginia.edu id aa08786; 5 Mar 96 22:46 EST Received: from mamba.cs.Virginia.EDU (mamba-fo.cs.Virginia.EDU [128.143.136.18]) by archive.cs.Virginia.EDU (8.7.1/8.6.6) with SMTP id WAA01981; Tue, 5 Mar 1996 22:46:23 -0500 (EST) Received: by mamba.cs.Virginia.EDU (5.x/SMI-2.0) id AA27166; Tue, 5 Mar 1996 22:46:22 -0500 From: jorg@mamba.cs.virginia.edu Message-Id: <9603060346.AA27166@mamba.cs.Virginia.EDU> Subject: Last CFP: HPDC Focus Workshop on MULTIMEDIA AND COLLABORATIVE ENVIRONMENTS To: sigmetrics_bb_list@tay1.dec.com, tccc@cs.umass.edu, multicomm@cc.bellcore.com, infobahn@cs.nps.navy.mil, rem-conf@es.net Date: Tue, 5 Mar 1996 22:46:22 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit CALL FOR PAPERS HPDC Focus Workshop on MULTIMEDIA AND COLLABORATIVE ENVIRONMENTS ON Center, Syracuse, New York. August 6-9, 1996 This workshop is part of the FIFTH IEEE INTERNATIONAL SYMPOSIUM ON HIGH PERFORMANCE DISTRIBUTED COMPUTING (HPDC-5) to be held on August 6-9, 1996 at the ON Center, Syracuse, New York. Note: ----- Selected accepted papers will be invited for submission to Special Issues of "Concurrency: Experience and Practice" and the "Computer Communications Journal". ------------------------------------------------------------------------------ IMPORTANT DATES: SUBMISSION DEADLINE FOR EXTENDED ABSTRACTS (5 pages) March 8, 1996 NOTIFICATION OF ACCEPTANCE April 18, 1996 FULL PAPER DUE (10 pages) May 31, 1996 ADDITIONAL INFORMATION: http://www.cs.virginia.edu/~hpdc-focus/ ------------------------------------------------------------------------------ THEME: With the availability of broadband multi-service networks and with recent advances in multimedia technology, the creation of collaborative environments that offer location-independent shared visualization and interaction tools is becoming increasingly feasible. By providing shared virtual spaces for interaction and communication that go beyond desktop videoconferencing, collaborative environments enable the creation of the virtual analog to laboratories, meeting places, and classrooms. The objective of this workshop is to bring together researchers and developers working in multimedia computing and collaborative environments. The workshop is a forum for engineers and scientists to exchange ideas and research results relating to the state-of-the and future directions of wide-area collaborative environments. TOPICS OF INTEREST: Papers and demonstrations are solicited in all areas of distributed multimedia systems and collaborative environments, including, but not limited to: - Broadband Network Transport - Collaboration Tools - Distance Learning Systems - Electronic Communities - Media Servers - Multimedia Networks - Multimedia Models, Frameworks, and Document Architectures - Network-Based Hypermedia - Quality-of-Service - Security - Software for Distributed Multimedia - Synchronization - Tele-Presence Applications - Wireless Multimedia Systems - Video-On-Demand Services - Video-Conferencing Tools - Virtual Environments HPDC GENERAL CHAIR: Geoffrey Fox, NPAC, Syracuse University, (315)443-4741, hpdc@npac.syr.edu WORKSHOP CO-CHAIRS: Kim Mills, NPAC, Syracuse University Jorg Liebeherr, University of Virginia PROGRAM COMMITTEE: Wolfgang Effelsberg, University of Mannheim Edward A. Fox, Virginia Tech Simon Gibbs, GMD Germany Colin Maunder, BT Laboratories Steven McCanne, Lawrence Berkeley Laboratory Roy Rada, Washington State University Ralf Steinmetz, IBM ENC Rick Stevens, Argonne National Laboratory Marc Willebeek-LeMair, IBM Research Raj Yavatkar, Intel Hui Zhang, Carnegie-Mellon University REGISTRATION AND LOCAL ARRANGEMENTS: Peggy Van Arnam, Syracuse University Phone:(315) 443-3333 Fax: (315) 443-1168 e-mail: MJVANARN@SUADMIN.BITNET PAPER SUBMISSIONS: Authors are requested to submit by March 8, 1996, five copies of an extended abstract (not to exceed 5 pages) to: Prof. Jorg Liebeherr Computer Science Department University of Virginia Charlottesville, VA 22903 PHONE: (804) 982-2212 FAX: (804) 982-2214 EMAIL: jorg@cs.virginia.edu Authors are encouraged to submit in postscript format via ftp to ftp://ftp.cs.virginia.edu/pub/hpdc-focus/. Instructions for electronic submissions are available at http://www.cs.virginia.edu/~hpdc-focus/. All submissions must include name and affiliation of the authors, a contact address of the main author, an abstract, and keywords. Paper Submission Deadline: March 8, 1996 Notification of Acceptance: April 18, 1996 Full Paper due (10 pages): May 31, 1996 DEMONSTRATIONS: Proposals are invited for presentations and live demonstrations of distributed multimedia systems and collaborative environments. Demonstrations will be selected on the basis of technical merit, novel and interesting features, and feasibility. The computing and storage systems to be used for demonstrations during the conference will be connected by a local ATM network and Ethernet. In addition, the conference ATM backbone network will be connected to the NYNET testbed, an ATM Wide Area Network that connects most of main university campuses, industry research labs, and government labs in New York State. Through the ATM connection to the NYNET testbed, it is feasible to access all the High Performance Computing Systems available at the Northeast Parallel Architectures Center (NPAC) at Syracuse University and the Theory Center at Cornell University (e.g., IBM SP2, CM5, Ncube, MasPar, etc.). The organization committee can facilitate obtaining the required resources to run accepted demonstrations. Demonstrations of both in-house and commercial applications, as well as academic and corporate research are sought. Proposals should contain: * A one-page abstract providing the title and description of the demonstration; * Names, affiliations, postal and email addresses, and phone and fax numbers of the demonstrators; * A description of the hardware, software, and technical, on-site requirements or the demonstration. Proposals for demonstrations should be submitted to: Prof. Jorg Liebeherr Computer Science Department University of Virginia Charlottesville, VA 22903 PHONE: (804) 982-2212 FAX: (804) 982-2214 EMAIL: jorg@cs.virginia.edu Submission Deadline for Proposals: March 8, 1996 Notification of Acceptance: April 18, 1996 ------------------------------------------------------------------------- SPONSORS: - IEEE Computer Society - Northeast Parallel Architectures Center (NPAC) at Syracuse University - New York State Center of Advance Technology in Computer Applications and Software Engineering (CASE) Center at Syracuse University IN COOPERATION WITH: - ACM SIGCOMM - Rome Laboratory From rem-conf-request@es.net Wed Mar 06 02:41:34 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Tue, 5 Mar 1996 23:41:08 -0800 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Wed, 6 Mar 1996 08:39:23 +0100 X-Mailer: exmh version 1.6.5 12/11/95 To: Elan Amir cc: max@atg.apple.com (Mark Q. Maxham), rem-conf@es.net From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: multicast-to-unicast gateway? In-reply-to: Your message of "Tue, 05 Mar 1996 13:18:39 PST." <199603052118.NAA26864@joyride.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Mar 1996 08:39:19 +0100 Sender: schulzrinne@fokus.gmd.de > > > Has anyone written a multicast-to-unicast gateway for RTPv2? Such an app > > would sit on a multicast-capable host and listen for receiver reports or > > source descriptions coming over a unicast channel, and take those as a cue > > for where to redirect the packets. > > > > Of course, there are hairy issues concerning mapping sd entries, and this > > would just be a stopgap. I'm interested in hearing about any attempts to > > include the multicast-impaired until everyone has it. > > > > max > > > > > There's also a simple translator that forwards from one address (uc/mc) to any number of other addresses (uc/mc). It also translates vat to RTP in the process (this avoids the problem of having to assign new outgoing sockets to each incoming stream to separate the audio streams). Rtptools (ftp://ftp.fokus.gmd.de/pub/step/rtptools) contains the translator; the version with the built-in vat-to-RTP translator is being tested and available on request. Contact Dorgham Sisalem (dor@fokus.gmd.de) for details. Henning From rem-conf-request@es.net Wed Mar 06 03:09:19 1996 Received: from jekyll.piermont.com (actually 206.1.51.15) by osi-west.es.net with ESnet SMTP (PP); Wed, 6 Mar 1996 00:08:36 -0800 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.3/8.6.12) with SMTP id DAA09111 for ; Wed, 6 Mar 1996 03:07:33 -0500 (EST) Message-Id: <199603060807.DAA09111@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: rem-conf@es.net Subject: The Arctos Group: fwd: ACTA petitions FCC on internet telephony Date: Wed, 06 Mar 1996 03:07:33 -0500 From: "Perry E. Metzger" Got this off of com-priv; the way I read it this could make a lot of the multicast work done on the internet illegal. Perry ------- Forwarded Message Date: Tue, 05 Mar 1996 22:52:19 -0500 To: com-priv@psi.com From: The Arctos Group Subject: fwd: ACTA petitions FCC on internet telephony - ----------begin forwarded text---------- FCC PETITIONED TO STOP MISUSE OF THE INTERNET! WASHINGTON, March 4 /PRNewswire/ -- The America's Carriers Telecommunication Association (ACTA), a trade association of competitive, long distance carriers today petitioned the Federal Communications Commission (FCC) to stop companies from selling software and hardware products that enable use of the Internet to voice long distance services. A growing number of companies are selling software programs with ancillary hardware options that enable a computer to transmit voice conversations. This, in fact, creates the ability to "by-pass" local, long distance and international carriers and allows for calls to be made for virtually "no cost." For example, on-line service providers generally charge users around $10.00 for five hours of access and then around $3.00 for each additional hour. Five hours equals 300 minutes, divided by $10 is 3.3 cents per minute. The average residential long distance telephone call costs about 22 cents per minute or seven times as much. The Internet is a unique form of wire communications. The rapid growth of the Internet is stressing the capacities of the Internet itself. The Internet access points are growing at 50% per month with subscriber growth running close to 30% per month. Individuals are accessing the Internet for more and more business applications such as market research, news, and advertising with corporate web sites exploding, to say nothing about using the Internet for E- mail applications. ACTA submits that it is incumbent upon the FCC to exercise jurisdiction over the use of the Internet for unregulated interstate and international telecommunications services. Long distance and international carriers must be approved by the FCC to operate and must file tariffs before both the FCC and state public service commissions. All of these requirements are stipulated in the Communications Act of 1934 and the Telecommunications Act of 1996. Technology may once again be surpassing government's ability to control its proper use. However, the misuse of the Internet as away to "by-pass" the traditional means of obtaining long distance service could result in a significant reduction of the Internet's ability to transport its ever enlarging amount of data traffic. Therefore, ACTA has petitioned the FCC to define the type of permissible communications which may be effected over the Internet. America's Carriers Telecommunication Association was founded in 1985 by independent long distance companies to serve the needs of small businesses and to advance the goals of more effective competition. ACTA's membership today includes over 130 companies engaged in providing telecommunications services. CONTACT: Charles H. Helein, general counsel, 703-714-1301, or Jennifer Durst-Jarrell, executive director, 407-332-9382, both of America's Carriers Telecommunication Association ------- End of Forwarded Message From rem-conf-request@es.net Wed Mar 06 04:00:29 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Wed, 6 Mar 1996 00:59:41 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id AAA03639 for ; Wed, 6 Mar 1996 00:59:05 -0800 Message-Id: <199603060859.AAA03639@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: rem-conf@es.net Subject: Re: Laptops in general In-reply-to: Your message of "Tue, 05 Mar 1996 09:11:00 PST." <199603052121.NAA00396@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Mar 1996 00:59:05 -0800 From: "Amancio Hasty Jr." >>> Denis DeLaRoca 825-4580 said: > >From what I hear, the FreeBSD ported tools are the most stable. But > until recently FreeBSD laptop support has lagged behind that of Linux. Hi, I forgot to mentioned that on FreeBSD we have a mail archive: http://www.freebsd.org/How/mail-archive.html The following two freebsd mailing lists are useful: freebsd-hackers@freebsd.org for general OS development for instance laptop support. freebsd-multimedia@freebsd.org is multimedia -- sound, video, mbone, etc... Or you can check us out on the MBONE channel FreeBSD Lounge As for mbone tools we have a single tar file which has all the sources for every mbone tool that we can get the sources to 8) Enjoy, Amancio From rem-conf-request@es.net Wed Mar 06 06:22:23 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 6 Mar 1996 03:21:48 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 6 Mar 1996 11:19:32 +0000 To: "Perry E. Metzger" cc: rem-conf@es.net, J.Crowcroft@cs.ucl.ac.uk Subject: Re: The Arctos Group: fwd: ACTA petitions FCC on internet telephony In-reply-to: Your message of "Wed, 06 Mar 1996 03:07:33 EST." <199603060807.DAA09111@jekyll.piermont.com> Date: Wed, 06 Mar 1996 11:19:23 +0000 Message-ID: <1083.826111163@cs.ucl.ac.uk> From: Jon Crowcroft >Got this off of com-priv; the way I read it this could make a lot of >the multicast work done on the internet illegal. Perry sounds like restraint of trade to me if an internet service provider okays the use of mbone (or unicast multimedia rtp) apps, ACTA lose - but the free market will sort this out (except for another year or two in europe, it is not truly free yet) in the UK at least, IP is _explicitly_ a value added service, so ANYTHING layerd on top of it is excempt from our regulatory body's tarriffing rules...and i would imagine that since the typical ISP gets their lines from the typical voice carrier, the typical voice carrier hasn't a leg to stand on... "illegal" means nothing - its whether it is in breach of your telco's contract with your ISP for the line,s or the ISPs contract with a subscriber for the IP service.... i don't see a problem... cheers jon >------- Forwarded Message > >Date: Tue, 05 Mar 1996 22:52:19 -0500 >To: com-priv@psi.com >From: The Arctos Group >Subject: fwd: ACTA petitions FCC on internet telephony > >- ----------begin forwarded text---------- > >FCC PETITIONED TO STOP MISUSE OF THE INTERNET! From rem-conf-request@es.net Wed Mar 06 17:29:30 1996 Received: from wpnext.wpine.com by osi-west.es.net with ESnet SMTP (PP); Wed, 6 Mar 1996 14:29:00 -0800 Received: from [140.249.10.1] by wpnext.wpine.com (8.6.9/WM-941104.2) id RAA09550; Wed, 6 Mar 1996 17:29:06 -0500 X-Sender: bill@wpnext Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Mar 1996 17:30:02 -0800 To: von@Pulver.COM From: bryan@wpine.com (Bill Ryan) Subject: Fwd: FCC Petitioned to stop Internet phone SW Cc: rem-conf@es.net Anyone have any additional info. on this? Please, I have enough opinions about it already, I'm just looking for new info. (like is there a grassroots movement to block this?). Thanks, Bill >> >>FCC PETITIONED TO STOP MISUSE OF THE INTERNET! >> >>WASHINGTON, March 4 /PRNewswire/ -- The America's Carriers >>Telecommunication Association (ACTA), a trade association of >>competitive, long distance carriers today petitioned the Federal >>Communications Commission (FCC) to stop companies from selling >>software and hardware products that enable use of the Internet to >>voice long distance services. >> >> A growing number of companies are selling software programs with >>ancillary hardware options that enable a computer to transmit voice >>conversations. This, in fact, creates the ability to "by-pass" local, >>long distance and international carriers and allows for calls to be >>made for virtually "no cost." For example, on-line service providers >>generally charge users around $10.00 for five hours of access and then >>around $3.00 for each additional hour. Five hours equals 300 minutes, >>divided by $10 is 3.3 cents per minute. The average residential long >>distance telephone call costs about 22 cents per minute or seven times >>as much. >> >> The Internet is a unique form of wire communications. The rapid >>growth of the Internet is stressing the capacities of the Internet >>itself. The Internet access points are growing at 50% per month with >>subscriber growth running close to 30% per month. Individuals are >>accessing the Internet for more and more business applications such as >>market research, news, and advertising with corporate web sites >>exploding, to say nothing about using the Internet for E- mail >>applications. >> >> ACTA submits that it is incumbent upon the FCC to exercise >>jurisdiction over the use of the Internet for unregulated interstate >>and international telecommunications services. Long distance and >>international carriers must be approved by the FCC to operate and must >>file tariffs before both the FCC and state public service commissions. >>All of these requirements are stipulated in the Communications Act of >>1934 and the Telecommunications Act of 1996. >> >> Technology may once again be surpassing government's ability to >>control its proper use. However, the misuse of the Internet as a way >>to "by-pass" the traditional means of obtaining long distance service >>could result in a significant reduction of the Internet's ability to >>transport its ever enlarging amount of data traffic. Therefore, ACTA >>has petitioned the FCC to define the type of permissible >>communications which may be effected over the Internet. >> >> America's Carriers Telecommunication Association was founded in >>1985 by independent long distance companies to serve the needs of >>small businesses and to advance the goals of more effective >>competition. ACTA's membership today includes over 130 companies >>engaged in providing telecommunications services. >> >> >>CONTACT: Charles H. Helein, general counsel, 703-714-1301, or >>Jennifer Durst-Jarrell, executive director, 407-332-9382, both of >>America's Carriers Telecommunication Association >> >> >> >> __________________________________________________________ Bill Ryan (bryan@wpine.com) "Keeping You Connected" Principal Software Engineer "CU-SeeMe Master Licensee" White Pine Software, Inc. http://www.wpine.com 40 Simon Street CUSeeMe: 192.233.34.5 Nashua, NH 03060 PH: 603-886-9050 "Live Free Or Die" - New Hampshire State Motto From rem-conf-request@es.net Wed Mar 06 20:29:31 1996 Received: from freenet.carleton.ca by osi-west.es.net with ESnet SMTP (PP); Wed, 6 Mar 1996 17:29:02 -0800 Received: from freenet3.carleton.ca (ae031@freenet3.carleton.ca [134.117.1.22]) by freenet.carleton.ca (8.6.12/8.6.4) with ESMTP id UAA23507 for ; Wed, 6 Mar 1996 20:28:54 -0500 Received: (ae031@localhost) by freenet3.carleton.ca (8.6.12/NCF-Sun-Client) id UAA21705; Wed, 6 Mar 1996 20:28:41 -0500 Date: Wed, 6 Mar 1996 20:28:41 -0500 Message-Id: <199603070128.UAA21705@freenet3.carleton.ca> From: ae031@freenet.carleton.ca (Andrew Stephens) To: rem-conf@es.net Subject: unsubscribe Reply-To: ae031@freenet.carleton.ca UNSUBSCRIBE ae031@freenet.carleton.ca -- Andrew Stephens | Standard disclaimer: These are my views and NCF -- Ottawa, Canada | not necessarily those of my employer. From rem-conf-request@es.net Wed Mar 06 23:30:16 1996 Received: from mailer.together.net by osi-west.es.net with ESnet SMTP (PP); Wed, 6 Mar 1996 20:29:49 -0800 Received: from sequoia.together.net (sequoia.together.net [204.97.120.25]) by mailer.together.net (8.6.12/8.6.12) with ESMTP id XAA20376; Wed, 6 Mar 1996 23:30:17 -0500 Received: from VTR133.ramp.together.net (VTR133.ramp.together.net [204.97.125.82]) by sequoia.together.net (8.7.3/8.6.12) with SMTP id XAA22090; Wed, 6 Mar 1996 23:35:13 -0500 (EST) Date: Wed, 6 Mar 1996 23:35:13 -0500 (EST) Message-Id: <199603070435.XAA22090@sequoia.together.net> X-Sender: scombs@together.net X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: scombs@together.net (Sandy Combs) Subject: Join VON Coalition - Internet Telephone considered "MISUSE OF THE INTERNET" by ACTA. FCC Petition filed. Please spread the word about the VON Coalition... Thank you. Sandy ------------------------- Forwarded message --------------------------------- ATTENTION ALL VON/FWD/IPONE/NETWATCH Members! ******************************************************* VON ALERT -- FWD ALERT --IPHONE ALERT -- NETWATCH ALERT ******************************************************* It appears that our recent FREE WORLD DIALUP press release was the straw that broke the camel's back. The FCC was petitioned yesterday by ACTA "TO STOP MISUSE OF THE INTERNET". The sale and use of Voice-On-the-Net (VON) software is being challenged by 130 of the USA's largest long distance telephone carriers. Among them, MCI, SPRINT, and LDDS. According to the ACTA press release: "A growing number of companies are selling software programs with ancillary hardware options that enable a computer to transmit voice conversations. This, in fact, creates the ability to "by-pass" local, long distance and international carriers and allows for calls to be made for virtually 'no cost.'" And also, "...the misuse of the Internet as a way to "by-pass" the traditional means of obtaining long distance service could result in a significant reduction of the Internet's ability to transport its ever enlarging amount of data traffic." 'VON' COALITION BEING FORMED A VON Coalition is currently being formed and members will testify at the spring meeting of the FCC when they discus telephony issues. If you don't want to loose your right to VON technology, NOW is the time to be counted. WHAT CAN I DO? We need an immediate head count of those on these lists that CARE ENOUGH TO BECOME INVOLVED! Subscribe RIGHT NOW to this SPECIAL VON Coalition list: vonYES@pulver.com To subscribe: VON Coalition List 1) send E-MAIL to: majordomo@pulver.com 2) leave the SUBJECT blank 3) in the BODY write - subscribe vonyes To subscribe: VON Coalition List Digest 1) send E-MAIL to: majordomo@pulver.com 2) leave the SUBJECT blank 3) in the BODY write - subscribe vonyes-digest Further discussions regarding the VON Coalition will be posted to the above only. If you DO NOT act TODAY, your rights and FREE TELEPHONE via the internet may well be lost! Jeff Pulver Sandy Combs (Press Release distribution authorized by, Jennifer Durst-Jarrell, Executive Director, ACTA 3/5/96) ______________________________________________________________________________ FCC PETITIONED TO STOP MISUSE OF THE INTERNET! WASHINGTON, March 4 /PRNewswire/ -- The America's Carriers Telecommunication Association (ACTA), a trade association of competitive, long distance carriers today petitioned the Federal Communications Commission (FCC) to stop companies from selling software and hardware products that enable use of the Internet to voice long distance services. A growing number of companies are selling software programs with ancillary hardware options that enable a computer to transmit voice conversations. This, in fact, creates the ability to "by-pass" local, long distance and international carriers and allows for calls to be made for virtually "no cost." For example, on-line service providers generally charge users around $10.00 for five hours of access and then around $3.00 for each additional hour. Five hours equals 300 minutes, divided by $10 is 3.3 cents per minute . The average residential long distance telephone call costs about 22 cents per minute or seven times as much. The Internet is a unique form of wire communications. The rapid growth of the Internet is stressing the capacities of the Internet itself. The Internet access points are growing at 50% per month with subscriber growth running close to 30% per month. Individuals are accessing the Internet for more and more business applications such as market research, news, and advertising with corporate web sites exploding, to say nothing about using the Internet for E-mail applications. ACTA submits that it is incumbent upon the FCC to exercise jurisdiction over the use of the Internet for unregulated interstate and international telecommunications services. Long distance and international carriers must be approved by the FCC to operate and must file tariffs before both the FCC and state public service commissions. All of these requirements are stipulated in the Communications Act of 1934 and the Telecommunications Act of 1996. Technology may once again be surpassing government's ability to control its proper use. However, the misuse of the Internet as a way to "by-pass" the traditional means of obtaining long distance service could result in a significant reduction of the Internet's ability to transport its ever enlarging amount of data traffic. Therefore, ACTA has petitioned the FCC to define the type of permissible communications which may be effected over the Internet. America's Carriers Telecommunication Association was founded in 1985 by independent long distance companies to serve the needs of small businesses and to advance the goals of more effective competition. ACTA's membership today includes over 130 companies engaged in providing telecommunications services. - 0 - ____________________ END PRESS RELEASE ____________________________________ From rem-conf-request@es.net Thu Mar 07 05:59:26 1996 Received: from dxmint.cern.ch by osi-west.es.net with ESnet SMTP (PP); Thu, 7 Mar 1996 02:58:02 -0800 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA10724; Thu, 7 Mar 1996 11:48:45 +0100 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA14593; Thu, 7 Mar 1996 11:48:43 +0100 Message-Id: <9603071048.AA14593@dxcoms.cern.ch> Subject: CERN Seminar MBONE Announcement To: rem-conf@es.net, htc@frcpn11.in2p3.fr, hrc@frcpn11.in2p3.fr, htasc@listbox.cern.ch, omartin@dxcoms.cern.ch (Olivier Martin), pgalvez@dxcoms.cern.ch (Philippe Galvez), FLE@cernvm.cern.ch (Martin Fluckiger), julian@vxcern.cern.ch (Julian Bunn), etiennef@vxcern.cern.ch (Francois Etienne), K.BOS@nikhef.nl (Kors BOS), helft@lal.in2p3.fr (Christian Helft), c.d.osland@rl.ac.uk (Chris Osland), onions@mail.cern.ch (Chris Onions), jenni@cernvm.cern.ch (Peter Jenni), j.c.hart@rl.ac.uk (John Hart), jank@sunra1.cern.ch (Werner JANK), brodmanh@st.msm.cern.ch (Herbert Brodmann), karsten@dxcoms.cern.ch, daniel_boileau@macmail.cern.ch (Daniel Boileau), brian@dxcoms.cern.ch (Brian Carpenter), charnay@ccpnxt2.in2p3.fr (Daniel Charnay), enm@sgi5.hep.anl.gov (Edward May) Date: Thu, 7 Mar 1996 11:48:43 +0100 (MET) From: Christian Isnard - CERN/CN/CS X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3310 CERN is pleased to announce that the seminar What If Your Life Depended on Software? Introduction to Software Process by Mr. Watts S. Humphrey (Software Engineering Institute) will be broadcasted live on MBONE(1) on Monday, March 25th from 16:00 CET to 17:00 CET, >from the CERN Council Chamber. ---------------------------------------------------------------------------- Abstract: If your survival depended on software, you would be pretty interested in how it was developed. Few people realize that software is now or soon will be critical to the performance, safety, or security of most advanced electronic products. In this talk, Mr. Humphrey discusses the critical nature of software and the challenges software developers face. He shows that the methods traditionally used to develop quality software are ineffective and that better processes are essential. Two approaches to these problems have shown substantial benefits. The Capability Maturity Model (CMM) is now widely used to help organizations improve their capability. Experience with the CMM shows sharp improvements in product quality and development productivity. The Personal Software Process (PSP) introduces software engineers to disciplined personal methods. After PSP training, engineers produce more accurate plans and develop higher quality products. While the benefits vary by individual, quality improvements of five to ten times are normal and productivity improvements average about 25%. Mr. Humphrey concludes with a summary of steps required to introduce these methods into software organizations. The Speaker: Mr. Humphrey joined the Software Engineering Institute (SEI) of Carnegie Mellon University after his retirement from IBM in 1986. While at the SEI, he established the Process Program, led the initial development of the Software Capability Maturity Model, and introduced the concepts of Software Process Assessment and Software Capability Evaluation. Prior to joining the SEI, he spent 27 years with IBM in various technical executive positions including the management of all IBM commercial software development. This included the first 19 releases of OS/360. Most recently, he was IBM's Director of Programming Quality and Process. Mr. Humphrey holds graduate degrees in Physics from the Illinois Institute of Technology and Business Administration from the University of Chicago. He is an SEI Fellow, a member of the ACM, an IEEE Fellow, and a past member of the Malcolm Baldrige National Quality Award Board of Examiners. His books include A Discipline for Software Engineering, Managing the Software Process (English and Japanese), and Managing for Innovation - Leading Technical People (English and Spanish). He was awarded the 1993 Aerospace Software Engineering Award presented by the American Institute of Aeronautics and Astronautics. He holds five US. patents. ---------------------------------------------------------------------------- 1. The session will be advertised in sd as "CERN: W.S.Humphrey Seminar/SPI". Please inform Arash Khodabandeh if this broadcast may clash with an important event on MBONE. 2. For more information on CMM and PSP see: http://www.sei.cmu.edu/. ---------------------------------------------------------------------------- From rem-conf-request@es.net Thu Mar 07 07:54:46 1996 Received: from venus.rdc.puc-rio.br by osi-west.es.net with ESnet SMTP (PP); Thu, 7 Mar 1996 04:54:17 -0800 Received: from du-30.du.ibase.org.br by venus.rdc.puc-rio.br (AIX 3.2/UCB 5.64/4.03) id AA40197; Thu, 7 Mar 1996 09:52:53 -0300 Message-Id: <2F5DA8DB.74A5@ax.ibase.org.br> Date: Wed, 08 Mar 1995 09:53:47 -0300 From: Bruno Vianna Organization: Tabu 2.0 X-Mailer: Mozilla 2.0 (Win95; I) Mime-Version: 1.0 To: rem-conf@es.net Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit UNSUBSCRIBE bruno@venus.rdc.puc-rio.br From rem-conf-request@es.net Thu Mar 07 11:49:02 1996 Received: from radvision.rad.co.il by osi-west.es.net with ESnet SMTP (PP); Thu, 7 Mar 1996 08:48:18 -0800 Received: from gateway.radvision.rad.co.il by blue.radvision.rad.co.il (4.1/SMI-4.1) id AA00781; Thu, 7 Mar 96 18:45:30 IST Received: by gateway.radvision.rad.co.il with Microsoft Mail id <313FA02B@gateway.radvision.rad.co.il>; Thu, 07 Mar 96 18:49:15 PST From: Ami Amir To: IETF remote conference Subject: subscribe Date: Thu, 07 Mar 96 18:47:00 PST Message-Id: <313FA02B@gateway.radvision.rad.co.il> Return-Receipt-To: Encoding: 4 TEXT X-Mailer: Microsoft Mail V3.0 subscribe ami amir amir@radvision.rad.co.il From rem-conf-request@es.net Thu Mar 07 13:06:05 1996 Received: from asante.asante.com by osi-west.es.net with ESnet SMTP (PP); Thu, 7 Mar 1996 10:05:25 -0800 Received: from sawadee.asante.com by asante.asante.com (4.1/SMI-4.1/Brent-911016) id AA21875; Thu, 7 Mar 96 10:02:48 PST Message-Id: Date: 7 Mar 1996 10:05:24 -0800 From: Edward Ting Subject: mailing list To: Announce Audio/Video , Request Audio/Video , Announce IETF , Request IETF , Announce INTSERV , Request INTSERV , Announce IPATM , Request IPATM , Announce RMONMIB , Request RMONMIB X-Mailer: Mail*Link SMTP/QM 3.0.0 To whom it may concern: Please add my name in the mailing list. Thanx. Edward Ting Asante Technologies, Inc. From rem-conf-request@es.net Thu Mar 07 14:55:19 1996 Received: from basil.cdt.luth.se by osi-west.es.net with ESnet SMTP (PP); Thu, 7 Mar 1996 11:54:47 -0800 Received: from kalkyl.cdt.luth.se (kalkyl.cdt.luth.se [130.240.193.31]) by basil.cdt.luth.se (8.6.12/8.6.12) with ESMTP id UAA22696 for ; Thu, 7 Mar 1996 20:53:42 +0100 Received: from kalkyl (localhost [127.0.0.1]) by kalkyl.cdt.luth.se (8.6.12/8.6.12) with ESMTP id UAA09795 for ; Thu, 7 Mar 1996 20:55:45 +0100 Message-Id: <199603071955.UAA09795@kalkyl.cdt.luth.se> X-Mailer: exmh version 1.6.4 10/10/95 To: rem-conf@es.net X-uri: http://www.cdt.luth.se/~peppar/ Subject: Draft: RTP extension for Scalable Reliable Multicast Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="===_0_Thu_Mar__7_20:53:40_MET_1996" Date: Thu, 07 Mar 1996 20:55:44 +0100 From: Peter Parnes This is a multipart MIME message. --===_0_Thu_Mar__7_20:53:40_MET_1996 Content-Type: text/plain Hi Below is a small draft from northern Sweden on my work in extending RTP2 for Scalable Reliable Multicast, SRM. I have a working prototype implementation of the proposed extension implemented using Java. I just put on my asbestos-suit so fire away and flame me ;-) /P --===_0_Thu_Mar__7_20:53:40_MET_1996 Content-Type: text/plain Content-Description: draft-parnes-avt-srm-00.txt Internet Engineering Task Force Peter Parnes INTERNET-DRAFT LuTH/CDT March 7, 1996 Expires: X/X/96 RTP extension for Scalable Reliable Multicast Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document describes how the Real-time Transport Protocol [RFC- 1889] could be extended to include support for Scalable Reliable Multicast. The scheme proposed could be used for transporting a data flow reliably over the transport protocols supported by RTP. Peter Parnes [Page 1] INTERNET-DRAFT RTP/SRM March 1996 1. Introduction The Real-time Transport Protocol, (RTP) [RFC-1889] is based on UDP which is a best-effort transport protocol meaning that packets can be lost. For some applications this is acceptable but for other, for instance white-board-applications, it is necessary to do retransmission so an end-user can rely on that he has received everything that someone else has sent. This document describe how RTP could be extended to include support for Scalable Reliable Multicast. The scheme proposed could be used for transporting a data flow reliably over the transport protocols supported by RTP. This new RTP/SRM-platform could be used for numerous applications, for instance semi-reliable audio/video, distributed group-ware applications, WWW-cache and FTP updates etc, etc. 2. Scalable Reliable Multicast Scalable Reliable Multicast,(SRM) [SRM-95] is a reliable multicast framework for application level framing and light-weight sessions. The algorithms of this framework are efficient, robust and scale well to both very large networks and very large sessions. The framework has been prototyped in wb, a distributed white-board application, and has been extensively tested on a global scale with sessions ranging from a few to more than 1000 participants. 2.1 The SRM ideas The ideas of SRM can be described as follows: 1) Every packet transmitted is uniquely identified by a sender- identification and a sequence-number that is incremented by one for each transmitted packet. 2) Every member of the sessions buffers a certain amount of packets, even if she is only a receiver and not a sender, so if necessary she can participate in 'repairs' of lost packets. 3) When a receiver notices that she has lost packets (by checking if the difference of the sequence-numbers of the incoming packet and the last heard packet before that is greater than 1) she sends a negative acknowledgment, NACK, using multicasting so all members of the session hears the NACK. But before sending the NACK she wait for a random time determined by the distance of the original source and if she hears a NACK for the same packet Peter Parnes [Page 2] INTERNET-DRAFT RTP/SRM March 1996 from another member she suppress her own NACK. 4) Any member that gets a NACK and has the packet requested can send a repair but just as in the NACK-case she waits a random time before sending the repair. 5) Loss is detected by finding a gap in the sequence space but since it is possible the last data-packet is dropped, each sender send a low-rate, periodic, message, (a heartbeat) announcing the highest sequence number used. Please note that this only gives the ideas of the algorithms used and implementers should read the SRM-paper first. 2.2 How does SRM fit into RTP? Here follows a description of how the SRM ideas fit into RTP according to the points in the previous section. The points here, marked with a changes. 1) RTP has a unique sender-ID, the Synchronization Source (SSRC) and each data-packet has a sequence-number. 2) The buffering can be accomplished without interfering with the protocol itself. 3*) The transmission of NACKs has to be incorporated into RTP using the Real-time Transport Control Protocol, RTCP. 4*) The repairs can either be sent directly without any discrimination from the original packet over the same RTP- data-channel (no change to RTP needed) or it could be marked as special data which would imply changes to RTP. 5*) The heartbeats have to be incorporated into RTP/RTCP. 3. What extensions are needed in RTP/RTCP This section explains the additions to RTP. The added packet-formats are discussed section 5. 3.1 NACKs (point 3) The NACK-transmissions should be implemented using RTCP by adding a new RTCP type, SRM = 205. 3.2 Retransmission of data-packets (point 4) Peter Parnes [Page 3] INTERNET-DRAFT RTP/SRM March 1996 Retransmissions are sent on the RTP-data-port just as ordinary packets. It is a bit unclear how we should handle these retransmissions: * Should we just let applications that don't understand the SRM- extension see the retransmitted packets as original data and interpret them as duplicates or late packets? This would 'break' traffic estimation and analysis programs but applications that don't understand SRM would benefit. * Or should we use some mechanism for encapsulating the packet, for instance using Mark Handley's proposed new payload-type for redundant data? This method has the opposite advantages/disadvantages of the first method. 3.3 Heartbeats (point 5) The heartbeats could be incorporated into the SR-packets using the "profile-specific-extensions" but two things talk against this: * This isn't inter-operable with other payload-specific-extensions as we only can have one header-extension. * The SR-packets are only sent during and once right after a sender transmits data but the heartbeats should be sent all the time, so a receiver that have lost several packets directly after the end of the data-flow would notice that she has lost packets. Instead the heartbeats should be sent using the new RTCP-SRM type. These heartbeats should be sent more often right after a sender has stopped sending so receivers can notice that they have lost packets more quickly. This isn't a problem for small groups as the dynamic delay between RTCP-packets is small but in larger groups the delay could become a problem. Peter Parnes [Page 4] INTERNET-DRAFT RTP/SRM March 1996 4. Packet format This section explains the format of the RTCP-SRM packet. The header is the same for all RTCP-SRM packets: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|CM | Count | PT=SRM=205 | length | header +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Version (V): 2 bits Identifies the version of RTP, two (2). Command (CM): 2 bits The SRM-command as defined below. Count: 4 bits The number of command-data-fields included in this packet. How this field is used depends on the command. Packet type (PT): 8 bits Contains the constant 205 to identify this as an RTCP SRM packet. Packet length (length): 16 bits The length of this RTCP packet in 32-bit words minus one, including the header. (The offset of one makes zero a valid length and avoids a possible infinite loop in scanning a compound RTCP packet, while counting 32-bit words avoids a validity check for a multiple of 4.) Depending on the Command (CM) field the header is followed by any of the following: 4.1 Heartbeat (CM=0) For heartbeats CM contains the constant 0 and the header is followed by 16-bits containing the latest sequence number used by the sender of this packet. The sender is identified by the SSRC field in the SR or RR-report that must come before this SRM-packet. The other 16-bits are not used. Peter Parnes [Page 5] INTERNET-DRAFT RTP/SRM March 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | Not Used | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 4.2 NACK (CM=1) Each NACK-packet includes NACKs for one sender but several NACK- packets may be included into one compound RTCP-packet. For NACKs, CM contains the constant 1 and the count field contains the number of NACKs minus one included in this SRM-packet. This makes zero a useful number as it doesn't make much sense to send an empty NACK packet just containing the SSRC. The header is followed by the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence numbers | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ SSRC: 32 bits The SSRC from the sender from whom we have lost packets. Sequence numbers: 32 bits times Count+1 Count+1 sequence numbers, one for each lost packet from this certain SSRC. Peter Parnes [Page 6] INTERNET-DRAFT RTP/SRM March 1996 5. Acknowledgments This work is done within the Multimedia Assisted distributed Tele- Engineering Services, MATES, project (ESPRIT 20598) which I'd like to thanks for the support. I'd also want to thank the Centre for Distance-spanning Technology for giving me the opportunity to do this work. 6. Author's Address Peter Parnes CDT/Dept of Computer Science University of Lulea S-971 87 Lulea, Sweden Tel: +46 920 72421 Fax: +46 920 91074 E-Mail: peppar@cdt.luth.se WWW: 6. References [RFC-1889] Schulzrine/Casner/Frederic/Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996 [SRM-95] Floyd/Jacobson/McCanne/Liu/Zhang, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", Submitted to IEEE/ACM Transactions on Networking, Peter Parnes [Page 7] --===_0_Thu_Mar__7_20:53:40_MET_1996-- From rem-conf-request@es.net Thu Mar 07 15:58:58 1996 Received: from trystero.radio.com by osi-west.es.net with ESnet SMTP (PP); Thu, 7 Mar 1996 12:58:11 -0800 Received: (carl@localhost) by trystero.radio.com (8.7.4/940816.06ccg) id PAA26005 for rem-conf@es.net; Thu, 7 Mar 1996 15:58:09 -0500 (EST) From: "Carl Malamud [IMS]" Message-Id: <199603072058.PAA26005@trystero.radio.com> Subject: Changes in the IMS Schedule To: rem-conf@es.net Date: Thu, 7 Mar 1996 15:58:09 -0500 (EST) Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi - As part of the closing of our Capitol Hill Studio and our donation of our National Press Building facilities to the University of Virginia, there will be a reduction in our multicast schedule. The World Radio Network VAT stream will go off the air on March 15 and the House and Senate feeds are already off. The Internet Town Hall broadcast of National Press Club luncheons may continue, but that decision is up to the new owners of town.hall.org. The Internet Multicasting Service will continue as a corporate entity to administer programs such as the Internet Software Consortium which pays for projects such as the development and maintenance of BIND. We will, however, be ceasing all our day-to-day operations on April 1, the third anniversary of "going on the air." Thanks for letting us chew up your spare bits for the last couple of year. Carl Malamud From rem-conf-request@es.net Fri Mar 08 01:13:39 1996 Received: from resnet.uoregon.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 7 Mar 1996 22:13:00 -0800 Received: from resnet2.uoregon.edu (riley-net170-160.uoregon.edu [128.223.170.160]) by resnet.uoregon.edu (8.6.12/8.6.12) with SMTP id WAA07607 for ; Thu, 7 Mar 1996 22:13:00 -0800 Message-Id: <1.5.4b11.32.19960308061342.00a1f420@resnet.uoregon.edu> X-Sender: btarr@resnet.uoregon.edu X-Mailer: Windows Eudora Light Version 1.5.4b11 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Mar 1996 22:13:42 -0800 To: rem-conf@es.net From: "Bryan J. Tarr" Subject: Windows95 mbone tools Are there any windows95 mbone tools available? I looked in the archives on this subject and was unable to find an answer. I have heard that windows95 has native support for multicast but I can't find any tools. Thank you, Bryan Tarr | Phone: (541) 346-9656 Residence Network Assistant | sysadmin: resnet.uoregon.edu University of Oregon Housing | email: btarr@resnet.uoregon.edu From rem-conf-request@es.net Fri Mar 08 03:23:59 1996 Received: from sonne.darmstadt.gmd.de by osi-west.es.net with ESnet SMTP (PP); Fri, 8 Mar 1996 00:23:09 -0800 Received: from biela.darmstadt.gmd.de (biela [141.12.62.47]) by sonne.darmstadt.gmd.de (8.7.3/8.7.3) with ESMTP id JAA00095 for ; Fri, 8 Mar 1996 09:23:01 +0100 (MET) From: Patric Hilgert Received: (hilgert@localhost) by biela.darmstadt.gmd.de (8.6.10/8.6.9) id JAA03214 for rem-conf@es.net; Fri, 8 Mar 1996 09:23:01 +0100 Date: Fri, 8 Mar 1996 09:23:01 +0100 Message-Id: <199603080823.JAA03214@biela.darmstadt.gmd.de> To: rem-conf@es.net Subject: Re: Windows95 mbone tools X-Sun-Charset: US-ASCII > > Are there any windows95 mbone tools available? I looked in the > archives on this subject and was unable to find an answer. I have heard > that windows95 has native support for multicast but I can't find any tools. > > Thank you, > > Bryan Tarr | Phone: (541) 346-9656 > Residence Network Assistant | sysadmin: resnet.uoregon.edu > University of Oregon Housing | email: btarr@resnet.uoregon.edu > > Check out the below announcements. Regards, Patric >From mbone-de-request@faui45.informatik.uni-erlangen.de Sat Feb 24 02:59 MET 1996 From: Arlie Davis To: "'mbone@isi.edu'" Cc: "'mikej@thepoint.net'" Subject: (Visual) MBONE Session Directory for Windows NT and Windows 95 Date: Fri, 23 Feb 1996 20:57:17 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit MBONE Session Directory for Windows NT and Windows 95 This is the first test release of my MBONE Session Directory tool. It was written from scratch, by analyzing the (relatively simple) packet format. You can download it at . This version was written from scratch, using MFC under MSVC40. Things it can do: Receive sessions Show detailed information about sessions. Things it cannot (yet) do: Originate sessions Cache known sessions to disk Run external programs I am currently developing Win32 applications which will allow transmission and reception of many audio and video formats that are common on the MBONE. If you are interested in this, feel free to drop me a line. (That said, however, don't write to me if all you are going to say is, "Me too!". I know. Trust me, you'll get a copy when it's ready.) If you enjoy using this, great! If you have suggestions for how to improve it (beyond just urging me to implement what the UNIX SD does), let me know. If you feel like complaining, go write your own version and complain to yourself. -- Arlie Davis >From mbone-de-request@faui45.informatik.uni-erlangen.de Wed Mar 6 00:13 MET 1996 X-Authentication-Warning: sics.se: root set sender to mbone-eu-request using -f From: Arlie Davis To: "'mbone@isi.edu'" , "'mikej@thepoint.net'" Subject: Announcement: New audio tool for Windows 95 / Windows NT Date: Tue, 5 Mar 1996 17:42:36 -0500 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Media Pre-release 0.10 for Windows NT and Windows 95 by Arlie Davis This is the first pre-release of my generalized stream application, = called Media. The primary purpose of this application is to send and = receive media (audio and video) streams over packet- and cell-based = networks. =20 Media is implemented using Microsoft Foundation Classes (MFC) and the = Win32 API. The application was developed using Microsoft's 32-bit WinSock 1.1 = TCP/IP stack. The definitions of some constants relating the TCP/IP = multicast under WinSock 1.1 vary from vendor to vendor. You will need = to use Microsoft's stack or a stack which adheres to their standard. Basically, at this point, the only thing Media is good for is listening = to multicast streams of GSM, DVI4/ADPCM, and PCM streams. The framework = for many more codecs and abilities is there, but is not yet ready for = prime time. Use of Media should be self-explanatory. Start the application, and = select Session, New to create a new multicast listener. You will be = prompted for the multicast group and port number. The multicast session = display shows the total packet and byte counts received and a list of = all of the unique stream sources for that group. Double-click on the = source address for more information about that source. If you have a = sound card, and the source is GSM, DVI4/ADPCM, or PCM, you should hear = audio output. If you have comments or questions about this software, feel free to mail = me at arlie@thepoint.net. Don't bother complaining; this is pre-alpha = software. I will continue to develop this software for some time to = come, so if you are disappointed by it in its current form, just wait a = week or two. Arlie Davis arlie@thepoint.net You can download Media at these locations: ftp://ftp.thepoint.net/Archive/Internet/Interactive%20media/Media/Media.z= ip http://archive.thepoint.net/Internet/Interactive%20media/Media/Media.zip Features Runs on Windows 95 and Windows NT. Win32 is the de facto standard for = modern multimedia applications. Media is built on a generalized framework. It is not a single-protocol = hack. Supports multicast. Bugs Receive-only, right now No video support (at least not releasable yet) Not integrated with SD application (yet) Even though the framework supports Speak Freely and CU See Me, the = codecs aren't there yet. Audio formats supported GSM. Based on the GSM library version 1.07. ADPCM / DVI4 at 8K and 16K samples/second. PCM. Untested. Encapsulations supported RTP version 0 (the pseudo-standard that VAT uses, version 3 and prior) RTP version 1 RTP version 2 Speak Freely CU See Me (simplex; no client-client or client-reflector negotiation = protocol support) Networks supported TCP/IP, unicast and multicast Planned features More audio formats Video Transmission of video and audio Support for ATM, if possible Integration of my SD tool Support for recording and playback of media streams Technical support From rem-conf-request@es.net Fri Mar 08 03:52:39 1996 Received: from relay7.UU.NET by osi-west.es.net with ESnet SMTP (PP); Fri, 8 Mar 1996 00:51:53 -0800 Received: from iisc.ernet.in by relay7.UU.NET with SMTP id QQagcx02011; Fri, 8 Mar 1996 03:51:36 -0500 (EST) Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA28290; Fri, 8 Mar 96 14:27:14+0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA28205; Fri, 8 Mar 96 14:20:08+0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9603080850.AA28205@ece.iisc.ernet.in> Subject: Re: Draft: RTP extension for Scalable Reliable Multicast To: peppar@cdt.luth.se (Peter Parnes) Date: Fri, 8 Mar 96 14:20:08 GMT+5:30 Cc: rem-conf@es.net In-Reply-To: <199603071955.UAA09795@kalkyl.cdt.luth.se>; from "Peter Parnes" at Mar 7, 96 8:55 pm X-Mailer: ELM [version 2.3 PL11] Peter Parnes There is one doubt that I have that goes against the "timeless"ness of the retransmissions. Should we not have some kind of lifetime for these data like packets whose context/relevance, I am sure, is related to other media ? Essentially, I am wondering how this scheme works when we have to have intermedia synchronisation, and how it deals with obsolesense in the presense of other related media like audio. If this issue is already addressed and resolved, can you please let me know ? I might have overlooked something fundamental. Regards Anand. From rem-conf-request@es.net Fri Mar 08 05:50:53 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 8 Mar 1996 02:50:15 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 8 Mar 1996 10:38:59 +0000 To: Peter Parnes cc: rem-conf@es.net Subject: Re: Draft: RTP extension for Scalable Reliable Multicast In-reply-to: Your message of "Thu, 07 Mar 1996 20:55:44 +0100." <199603071955.UAA09795@kalkyl.cdt.luth.se> Date: Fri, 08 Mar 1996 10:38:40 +0000 Message-ID: <1246.826281520@cs.ucl.ac.uk> From: Jon Crowcroft >I just put on my asbestos-suit so fire away and flame me ;-) not at all - i think this is really really excellent! > RTP extension for Scalable Reliable Multicast the SRM paper does describe some mechanisms for timers and that, whilst both NACK timers and buffering to reorder/avoid gaps in delivery at receivers, don't require changes to the RTP spec, they need psecifiying (if only to publically document in a hoped-to-be RFC eventually, the mechanisms for people who don't read ACM/IEEE journals:-) meanwhile, I KNOW that mark handley wants to use this for Nt and other apps in the MMusic group - we want to produce a number of SRM like libraries (as your java one, so a Tcl/Tk, and C++ and so on...) (and an alternative to useing RMP to support T.120 for ISDN-like conference control in the Internet, this is going to scale a lot further....) good stuff! cheers jon From rem-conf-request@es.net Fri Mar 08 11:18:42 1996 Received: from cerc.wvu.edu (actually cathedral.cerc.wvu.edu) by osi-west.es.net with ESnet SMTP (PP); Fri, 8 Mar 1996 08:18:11 -0800 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA26048; Fri, 8 Mar 96 11:17:32 EST Received: by elk (5.x//ident-1.0) id AA11111; Fri, 8 Mar 1996 11:17:28 -0500 Date: Fri, 8 Mar 1996 11:17:26 -0500 (EST) From: "Todd L. Montgomery" Subject: Re: Draft: RTP extension for Scalable Reliable Multicast To: Jon Crowcroft Cc: Peter Parnes , rem-conf@es.net In-Reply-To: <1246.826281520@cs.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 8 Mar 1996, Jon Crowcroft wrote: > not at all - i think this is really really excellent! I as well. I applaud Peter for taking initiative on this and sending his thoughts out. Bravo! > > RTP extension for Scalable Reliable Multicast > > the SRM paper does describe some mechanisms for timers > and that, whilst both NACK timers and buffering to reorder/avoid gaps in > delivery at receivers, don't require changes to the RTP spec, they > need psecifiying (if only to publically document in a hoped-to-be RFC > eventually, the mechanisms for people who don't read ACM/IEEE > journals:-) > meanwhile, I KNOW that mark handley wants to use this for Nt and other > apps in the MMusic group - we want to produce a number of SRM like > libraries (as your java one, so a Tcl/Tk, and C++ and so on...) > > (and an alternative to useing RMP to support T.120 for ISDN-like conference > control in the Internet, this is going to scale a lot further....) I agree. RMP can only accomodate 256 members/clients (the member field is only 8 bits). This is intentional as RMP strives for total ordering as its default (with the ability to change that on a per message basis). Total ordering and message stability is going to require something that is more connection oriented... As a side note. Scalability in RMP is being addresses in two ways: 1 - I am developing new packet formats and extensions to use NACK-based reliability and ALF in RMP as just another option. If progress is made on defining an RTP extension or specification that gives this, I will also support that. 2 - Through a new group communication model (or an extension of an old one depending on how you see it) called listeners. Couple problems I see with using RTP for anything reliable oriented.... 16-bit sequence numbers implies that at 8 bits of data per messages, so the header is 4 bytes (source ID) + 2 bytes (seqnum) + 1 byte (data) = 56 bits, at bandwidth of 2 Mbps, the sequence number space is going to expire at an epoch of (56*2^16)/(2*1024*1024) about 1.75 seconds. Much less than the Max Segment Lifetime (MSL) on some networks. An effective throughput of 2 Mbps at the application is going to (8 bits at 2 Mbps) expire at an epoch of 0.25 seconds. IPv6 does not provide any kind of duplicate or lifetime assurances, so things like TCP or RMP over IPv6 will have to provide them. -- Todd Montgomery tmont@cerc.wvu.edu From rem-conf-request@es.net Fri Mar 08 16:21:47 1996 Received: from cis.Gsu.EDU (actually cis.cis.gsu.edu) by osi-west.es.net with ESnet SMTP (PP); Fri, 8 Mar 1996 13:21:16 -0800 Received: from rpadilla.Gsu.EDU (rpadilla.Gsu.EDU [131.96.33.35]) by cis.Gsu.EDU (8.6.10/8.6.10) with SMTP id QAA22301 for ; Fri, 8 Mar 1996 16:14:55 -0500 Message-Id: <2.2.16.19960308105006.47a721bc@cis.gsu.edu> X-Sender: rpadilla@cis.gsu.edu X-Mailer: Windows Eudora Pro Version 2.2 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Mar 1996 06:50:06 -0400 To: rem-conf@es.net From: Roderick Padilla Subject: [Q]Audio problems ... I do not know if my question is appropriate for this list, but I need some help ... I am running nv (3.4) on a Sparc 5 (Solaris 2.4) and having a "gargling" problem with the speaker. Looks like it is similar to the original problem in Solaris 2.2 (speaker driver problem) .... I called GATech (Our MBONE feed) to check on the problem and they are running the same OS in the same architecture (same nv version) with no problems ... I can use the audiotool as clear as water ( no problems there). The question is ... do I have a bandwidth/config problem? Any help/leads will be appreciated .... Roderick Padilla Office:(404) 651-3832 Systems & Network Administrator Fax: (404) 651-3842 http://www.cis.gsu.edu/~rpadilla Email: rpadilla@gsu.edu Department of Computer Information Systems College of Business Administration Georgia State University PO Box 4015 Atlanta, Georgia, USA 30302-4015 From rem-conf-request@es.net Fri Mar 08 16:53:46 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Fri, 8 Mar 1996 13:53:16 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.4/8.7.3) with SMTP id MAA18975 for ; Fri, 8 Mar 1996 12:02:59 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.6.12/8.6.12) id MAA11224 for rem-conf@es.net; Fri, 8 Mar 1996 12:01:03 -0800 Original-Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Fri, 08 Mar 96 12:01:03 PST PP-warning: Illegal Received field on preceding line Date: Fri, 08 Mar 96 12:00:00 PST From: Mojtaba Mirashrafi Message-ID: To: rem-conf@es.net Subject: Problem of RTP and dynamic port allocation In implementing a point-to-point RTP application, we have discovered the following problem in how RTP restricts the usage of ports. We make the recommendation that RTP not require that the sender and receiver be communicating on the same ports when using unicast. Environment: For simplicity, take the unidirectional, unicast case of a sender S and a receiver R. The receiver allocates a port P and informs the sender of it in some out of band fashion. RTP requires that the port used on each endpoint be the same. So the RTP data stream flows from port P on the sender to port P on the receiver. The sender also infers the receiver's control port as port (P+1). The sender will transmit RTCP sender reports to (P+1) and the receiver will respond with receiver reports to (P+1) as well. Problem: This environment makes dynamic allocation of ports difficult and inefficient. The two endpoints must agree on a common port before communication begins. This negotiation is not guaranteed to find a matching port free on each machine even though each machine may have free ports. For example, suppose that on a server ports 8000 through 8100 are available for dynamic assignment. If this server is heavily loaded only ports 8000 and 8001 may be free (there are 50 other RTP streams being currently served). Now if a client machine is already using ports 8000 or 8001 and attempts to connect, the handshake will fail because a matching pair of ports is not available. It will be denied service even though there are resources available on the server. Proposed Solution: Allow RTP sessions to occur on a dissimilar pair of ports. Given the unidirectional case above, the sender could allocate port X for data and X+1 for control, and the receiver could allocate ports P and P+1. The sender transmits data to P, and sender reports to P+1. The receiver transmits receiver reports to X+1, and if this were the bi-directional case, transmits any data it may have to port X. The handshake required for the exchange of the port information would remain outside of the RTP specification. Gunner Danneels Senior Software Engineer Intel gunner@ibeam.intel.com Philip Lantz Senior Software Engineer Intel prl@ibeam.intel.com Mojy Mirashrafi Senior Software Engineer Intel mojy@ibeam.intel.com From rem-conf-request@es.net Fri Mar 08 18:06:30 1996 Received: from cancer.ucs.ed.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 8 Mar 1996 15:06:00 -0800 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.10/8.6.12) with ESMTP id XAA11806; Fri, 8 Mar 1996 23:05:47 GMT Received: (jaw@localhost) by scorpio.ucs.ed.ac.uk (8.6.9/8.6.9) id XAA27663; Fri, 8 Mar 1996 23:05:45 GMT Date: Fri, 8 Mar 1996 23:05:44 +0000 (GMT) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Roderick Padilla cc: rem-conf@es.net Subject: Re: [Q]Audio problems ... In-Reply-To: <2.2.16.19960308105006.47a721bc@cis.gsu.edu> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 8 Mar 1996, Roderick Padilla wrote: > I do not know if my question is appropriate for this list, but I need some > help ... > > I am running nv (3.4) on a Sparc 5 (Solaris 2.4) and having a "gargling" > problem with the speaker. Looks like it is similar to the original problem > in Solaris 2.2 (speaker driver problem) .... > > I called GATech (Our MBONE feed) to check on the problem and they are > running the same OS in the same architecture (same nv version) with no > problems ... I can use the audiotool as clear as water ( no problems there). > > The question is ... do I have a bandwidth/config problem? Any help/leads > will be appreciated .... The Solaris 2.4 drivers for the SPARC 5 are broken. You need to apply patch 102125-02 which is available from your local Sun Answercentre. BTW nv is a video-only application. I assume you are using vat to drive the audio device. ============================================================================= 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 Mar 08 22:28:21 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 8 Mar 1996 19:27:50 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA07235; Fri, 8 Mar 1996 19:20:25 -0800 Date: Fri, 8 Mar 1996 19:20:25 -0800 (PST) From: Stephen Casner To: Mojtaba Mirashrafi Cc: rem-conf@es.net Subject: Re: Problem of RTP and dynamic port allocation In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > In implementing a point-to-point RTP application, we have discovered > the following problem in how RTP restricts the usage of ports. We > make the recommendation that RTP not require that the sender and > receiver be communicating on the same ports when using unicast. You are right. We have made the same observation. In the RTP spec, I think the only place where this restriction is mentioned is the phrase "common port pair" at the end of the definition of the term "RTP session". Have you found others? -- Steve From rem-conf-request@es.net Sat Mar 09 00:24:31 1996 Received: from mailhost.Ipsilon.COM (actually foo-5-10.Ipsilon.COM) by osi-west.es.net with ESnet SMTP (PP); Fri, 8 Mar 1996 21:23:55 -0800 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id VAA08468; Fri, 8 Mar 1996 21:22:15 -0800 Message-Id: <199603090522.VAA08468@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: richter@ro2.informatik.uni-hamburg.de (Jan-Peter Richter) cc: rem-conf@es.net Subject: Re: Info on vic SW architecture wanted In-reply-to: Your message of "Mon, 04 Mar 1996 13:55:11 +0100." <9603041254.AA05338@ro2.informatik.uni-hamburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Mar 1996 21:22:14 -0800 From: Greg Minshall Jan-Peter Richter, I think if you have the source code, you should be able to figure out the internal structure. Yes, we would all like to have "internals" documents for large bodies of code we encounter, but i'm afraid it isn't reasonable to expect to actually get such a document. Greg Minshall From rem-conf-request@es.net Sat Mar 09 00:39:04 1996 Received: from bh.kyungpook.ac.kr by osi-west.es.net with ESnet SMTP (PP); Fri, 8 Mar 1996 21:35:30 -0800 Received: from palgong.kyungpook.ac.kr (palgong.kyungpook.ac.kr [155.230.12.2]) by bh.kyungpook.ac.kr (8.6.12H1/8.6.9) with ESMTP id OAA23984 for ; Sat, 9 Mar 1996 14:34:19 +0900 Received: from TeNet4.kyungpook.ac.kr by palgong.kyungpook.ac.kr (8.6.12H1/8.6.9) id OAA02513; Sat, 9 Mar 1996 14:36:26 +0900 Message-ID: <313D1FC2.66F@palgong.kyungpook.ac.kr> Date: Wed, 06 Mar 1996 14:16:50 +0900 From: Sang-Jin Hur Organization: KNU EE X-Mailer: Mozilla 2.0GoldB1 (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: SDAP ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi ! folks. How can I find SDAP document ? thanks in advance. From rem-conf-request@es.net Sat Mar 09 14:09:05 1996 Received: from std.sri.com by osi-west.es.net with ESnet SMTP (PP); Sat, 9 Mar 1996 11:08:20 -0800 Received: from churchy.std.sri.com by std.sri.com (4.1/SMI-4.1) id AA16811; Sat, 9 Mar 96 11:06:14 PST Message-Id: <9603091906.AA16811@std.sri.com> To: Sang-Jin Hur Cc: m.handley@cs.ucl.ac.uk, rem-conf@es.net Subject: Re: SDAP ? In-Reply-To: Your message of "Wed, 06 Mar 1996 14:16:50 +0900." <313D1FC2.66F@palgong.kyungpook.ac.kr> Date: Sat, 09 Mar 1996 11:06:11 -0800 From: Ruth Lang > How can I find SDAP document ? A document (Internet Draft) describing SDAP does not yet exist. Postscript files from Mark Handley's SDAP presentations to the MMUSIC working group at the 12/95 and 3/96 IETF meetings should be available via ftp within the next couple of weeks. An announcement regarding their availability will be sent to confctrl@isi.edu. In the meantime, email directly to Mark Handley m.handley@cs.ucl.ac.uk is your best bet. Ruth Lang From rem-conf-request@es.net Sat Mar 09 18:56:47 1996 Received: from apache.mcast.com by osi-west.es.net with ESnet SMTP (PP); Sat, 9 Mar 1996 15:56:09 -0800 Received: from apache (localhost [127.0.0.1]) by apache.mcast.com (8.7.3/8.7.3) with ESMTP id PAA07211 for ; Sat, 9 Mar 1996 15:56:06 -0800 (PST) Message-Id: <199603092356.PAA07211@apache.mcast.com> X-Mailer: exmh version 1.6.5 12/11/95 To: rem-conf@es.net Subject: Re: Draft: RTP extension for Scalable Reliable Multicast In-reply-to: Your message of "Fri, 08 Mar 1996 10:38:40 GMT." <1246.826281520@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Mar 1996 15:56:06 -0800 From: Anders Klemets > the SRM paper does describe some mechanisms for timers > and that, whilst both NACK timers and buffering to reorder/avoid gaps in > delivery at receivers, don't require changes to the RTP spec, they > need psecifiying Yes, additional packets and/or header extensions need to be defined for the participating nodes to exchange timers. You would not want to rely on the NTP timestamp in the RR/SR, and use of the NTP timestamp field is optional anyway. Anders From rem-conf-request@es.net Sun Mar 10 01:27:08 1996 Received: from silas.cc.monash.edu.au by osi-west.es.net with ESnet SMTP (PP); Sat, 9 Mar 1996 22:26:30 -0800 Received: (btonkin@localhost) by silas.cc.monash.edu.au (8.7.3/8.6.4) id RAA02103 for rem-conf@es.net; Sun, 10 Mar 1996 17:24:26 +1100 (EST) Date: Sun, 10 Mar 1996 17:24:26 +1100 (EST) From: Bruce Tonkin Message-Id: <199603100624.RAA02103@silas.cc.monash.edu.au> To: rem-conf@es.net Subject: ATNAC'96 Advance Call for Papers, 4-6 Dec 96, Melbourne, Australia Advance Notice and Call for Papers Australian Telecommunication Networks and Applications Conference 1996 ATNAC'96 "Delivering Quality Services" 4-6 December 1996 The Hilton Hotel Melbourne, Australia ============= = Contents: = ============= * About the Conference * Multimedia and Video Services Stream * Broadband Networks stream * Teletraffic Research stream * Paper Submission details * Authors Schedule * Exhibition * Planning Committee * Registration of interest form ======================================================================= ======================== About the Conference ========================= ======================================================================= ATNAC is the major Australian conference on telecommunications networks and applications. It will include a full program of renowned international keynote and invited speakers. The ATNAC conference consists of three streams: * Multimedia and Video Services * Broadband Networks, and * Teletraffic Research In 1996 significant changes are occurring in the telecommunications industry worldwide. The recent widespread availability of multimedia services on the Internet, low cost software, and the large base of existing Internet sites is giving rise to a 7.5% growth per month in Internet connections. These new interactive services are also stimulating the use of audio, image, and video within corporate networks. At the same time the opening of traditional monopoly markets to competition is stimulating the widespread installation of broadband access networks to residences (such as the hybrid fibre/coax networks being installed in Australia). These developments are in turn stimulating demand for ATM switching in the core of these networks to support the demands for flexible bandwidth, and services incorporating data, video, and voice. In future, users will want the same services available anywhere and anytime. This will necessitate the upgrading of the bandwidth and video coding techniques for mobile networks. This year's theme goes beyond last year's theme of "connecting the systems" to engineering the systems to "deliver quality services" at the lowest possible cost. Recent years have seen the development of stable standards for basic switching and compression that allow the building of a complete system. The issue now is to take advantage of these standards, and enhance these standards based on practical experience, to meet quality of service and cost needs. An understanding of multimedia service design, network design, and modern network traffic behaviour is required to tackle this issue. ===================================================================== =================== Multi-media and Video Services ================== ===================================================================== Stream Chair Dr Michael Frater Telephone: +61 6 268 8236 Fax: +61 6 268 8443 Email: mrf@ee.adfa.oz.au Multimedia services are one of the major outcomes of the current convergence of the telecommunications, computer, and television industries. The multimedia stream of ATNAC'96 will cover a range of issues that are important to the development of quality multimedia services, covering not only discussion of multimedia services themselves, but the network and coding and compression technology required to deliver them. Papers are invited covering the following and related topics: * Multimedia Internet services * Multi-media applications * Multi-media hardware * Multi-media software engineering including hypermedia, operating systems and utilities * Multi-media transport and networking protocols * Multiple media synchronisation * Multipoint, multimedia systems * Image, video and associated audio coding * Multi-media/video storage, database servers and retrieval systems * Digital delivery of television * Video on demand systems * "Set top unit" developments * User interfaces and human factors * HDTV and stereo/3D TV * Packet image and video and the influence of ATM * Error concealment/correction * Satisfying audio/video quality requirements * VLSI multi-media solutions * Virtual reality research and systems ======================================================================= ========================= Broadband Networks ========================== ======================================================================= Stream Chair: Mr Farzad Safaei Telephone: +61 3 9253 6115 Fax: +61 3 9253 6144 Email: f.safaei@trl.oz.au 1996 will be a significant year for broadband networks. On one hand, major progress toward the maturation of ATM standards is expected to take place which will aid both vendors and network providers with their product release and future planning. On the other hand, the accelerated rate of deployment of broadband platforms and services will highlight many complex practical issues such as interworking with existing LANs, Frame Relay, and Internet, operation and management of multiservice networks, and the need for new tariffing structures. The theme of the conference, "Delivering Quality Services" is intended to focus on the fundamental objective of the network in the face of these above-mentioned obstacles. Authors are encouraged to relate their paper to this theme. Papers are sought covering the following and related topics: * Service provision over ATM/SDH and other broadband platforms * Application scenarios, such as distributed computing * Application of broadband technology to the Internet * Economical viability of broadband networks and products * "Low speed" ATM products and interfaces, * Field trials, early commercial services * Network topologies and evolution * Broadband switch architecture * B-ISDN LANs, WANs, and interworking * Network and service management * Routing, signalling and control * B-ISDN protocols * B-ISDN standardization efforts * Operation and management of broadband multiservice networks * Broadband mobile technologies * ATM scalability, beyond ATM ======================================================================= ===================== Teletraffic Research ============================ ======================================================================= Stream Chair: Dr Moshe Zukerman Telephone: +61 3 9253 6332 Fax: +61 3 9253 6144 Email: m.zukerman@trl.oz.au The aim of the teletraffic stream is to provide a focus for theoretical and practical research on load control, performance, and design of telecommunications systems, and to encourage interaction between industry, manufacturers, and academia. Papers are welcome on any branch of teletraffic research; areas of general interest are given below. - Teletraffic modelling and performance of systems and networks * Switching systems * Intelligent networks * Broadband ISDN networks * Signalling networks * ISDN * Private networks * Mobile networks * Distributed systems * ATM LANs * LAN/MAN - Traffic characterisation and modelling, particularly for new applications and services. - Network design methods: * Meeting Quality of Service requirements * Optimisation * Forecasting * Architectures - Network traffic management * Routing algorithms * Traffic control policies * Communications protocols * Multiple access - Queueing theory - Simulation methods ======================================================================= =================== Submission of Papers ============================== ======================================================================= ****************************************************** * Papers will be refereed from FULL PAPERS this year * ****************************************************** A maximum of 6 pages in double column format will be printed in the proceedings. Authors may submit shorter papers that cover early results of research, or papers that explore new ideas without concrete results, as poster papers. All accepted papers will be printed in the proceedings. Authors whose papers are accepted will be expected to present them in person. 4 copies of the full paper should be submitted (as well as a disk containing a postscript version of the paper if possible), along with a cover sheet with your name, address, phone number & email address to: Ms Irene Thavarajah Conference Manager Office of Continuing Education Monash University Wellington Road Clayton Vic 3168 Melbourne, AUSTRALIA ======================================================================= ====================== Authors' Schedule =============================== ======================================================================= FULL paper due: 21 June 96 (4 copies, up to 6 pages, double column) Notification of acceptance: 16 Aug 96 Camera Ready version due: 4 Oct 96 ======================================================================= ========================= Exhibition ================================== ======================================================================= Companies, research organisations and others who wish to exhibit their products at the conference should contact: ATNAC'94 Conference Manager Irene Thavarajah Telephone: 9905 1344 Fax: 9905 1343 Email: irene.thavarajah@adm.monash.edu.au ======================================================================= =================== ATNAC'96 Planning Committee ======================= ======================================================================= Dr Bruce Tonkin, Monash University, Conference Chairman Ms Irene Thavarajah, Monash University, Conference Manager Dr Moshe Zukerman, Telstra Research Laboratories, Teletraffic Stream Chair Dr Michael Frater, Australian Defence Force Academy, Multimedia Stream Chair Mr Farzad Safaei, Telstra Research Laboratories, Broadband Networks Chair Professor John Hullett, Curtin University Dr Peter Beadle, University of Wollongong Professor Gary Anido, University of Wollongong Dr Bill Henderson, University of Adelaide Mr Mick O'Brien, Monash University Mr David Giddy, Telstra Research Laboratories Dr Hugh Bradlow, Telstra Research Laboratories Dr Michael Biggar, Telstra Research Laboratories ======================================================================= ========================= General Inquiries =========================== ======================================================================= Irene Thavarajah, Tel: +61 3 9905 1344 Fax: +61 3 9905 1343 Email: irene.thavarajah@adm.monash.edu.au Or Maureen Kemp, Tel: +61 3 9905 1340 Fax: +61 3 9905 1343 Email: maureen.kemp@adm.monash.edu.au ======================================================================== =================== Expression of Interest ============================= ======================================================================== ---------cut here---------------cut here--------------cut here----------- Return to: Monash University, Office of Continuing Education, Wellington Road, Clayton VIC 3168, Melbourne, AUSTRALIA FAX +61 3 9905 1343 email: irene.thavarajah@adm.monash.edu.au Expression of Interest Australian Telecommunication Network & Applications Conference 4-6 December 1996 First Name: Family Name: Title (Prof/Dr/Mr/Ms): Job Title: Organization: Mailing Address: Country: Telephone number: Facsimile Number: Email: _ |_| I propose to attend the Conference as a delegate _ |_| I am interested in the Exhibition _ |_| Please add my name to the mailing list _ |_| I propose to contribute a paper My areas of interest in order of priority are: (1 is highest level of interest, 3 is lowest level of interest) _ |_| Multimedia & Video Services _ |_| Broadband Networks _ |_| Teletraffic Research From rem-conf-request@es.net Sun Mar 10 12:03:39 1996 Received: from cerc.wvu.edu (actually cathedral.cerc.wvu.edu) by osi-west.es.net with ESnet SMTP (PP); Sun, 10 Mar 1996 09:03:01 -0800 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA09388; Sun, 10 Mar 96 12:02:59 EST Received: by elk (5.x//ident-1.0) id AA12450; Sun, 10 Mar 1996 12:02:58 -0500 Date: Sun, 10 Mar 1996 12:02:57 -0500 (EST) From: "Todd L. Montgomery" Subject: SRM To: rem-conf@es.net, floyd@ee.lbl.gov Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have a couple questions about SRM's use of the latency calculation. Perhaps someone can fill me in on what I am missing.... SRM uses its session messages to determine latency between pairs of sites. In short. Host A sends P1 at t1 Host B recvs P1 at t2 Host B sends P2 with (t1,delta=t3-t2) at t3 Host A recvs P2 at t4 Latency from B to A is = (t4-t1-delta)/2 So, if I understand this correctly, the session messages carry the set of active sources and the last seen sequence numbers for the page. As well as the "Host B sends" information for each active source. (because that information is Host A specific). Correct? The retransmission rate of the session messages must depend on their size (due to the 5% bandwidth restriction). My question is what happens when the size of the session message gets big? Suppose we have a page that has a lot of activity, 100+ members. The session message can get quite large and it is being sent from each site on that page. To maintain the bandwidth restriction, the retransmission period must be extended. This will start to effect how sites calculate latency as the period starts to loose resolution... or is this too extreme? Am I misunderstanding what is being sent in the session messages. Can they get large in this case? Another question I have.... are the session messages used for message stability? -- Todd Montgomery tmont@cerc.wvu.edu From rem-conf-request@es.net Sun Mar 10 14:30:41 1996 Received: from alpha.xerox.com by osi-east.es.net with ESnet SMTP (PP); Sun, 10 Mar 1996 11:30:01 -0800 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15467(11)>; Sun, 10 Mar 1996 11:28:31 PST Received: by redwing.parc.xerox.com id <177521>; Sun, 10 Mar 1996 11:28:28 -0800 Date: Sun, 10 Mar 1996 11:28:26 PST Sender: Lixia Zhang From: Lixia Zhang To: rem-conf@es.net, tmont@cerc.wvu.edu Subject: Re: SRM In-Reply-To: Your message of Sun, 10 Mar 1996 09:02:57 -0800 Message-ID: > The retransmission rate of the session messages must depend on their > size (due to the 5% bandwidth restriction). My question is what happens > when the size of the session message gets big? Suppose we have a page > that has a lot of activity, 100+ members. The session message can get > quite large and it is being sent from each site on that page. To maintain > the bandwidth restriction, the retransmission period must be extended. here's my understanding: instead of extending the session msg period, one simply limits the msg size to a reasonable MTU, and round-robin over all the members. There are a number of heuristics to decide whose info to put into a session msg when it cannot include info for all the members (e.g. give priority to the most recent change, etc). > Another question I have.... are the session messages used for message > stability? not sure I understand what you meant by "message stability". From rem-conf-request@es.net Sun Mar 10 14:35:55 1996 Received: from bmrc.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Sun, 10 Mar 1996 11:35:14 -0800 Received: from haymarket.ed.ac.uk (haymarket.ed.ac.uk [129.215.128.53]) by bmrc.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id LAA01759 for <298@bmrc.berkeley.edu>; Sun, 10 Mar 1996 11:29:13 -0800 Received: from castle.ed.ac.uk (castle.ed.ac.uk [129.215.128.23]) by haymarket.ed.ac.uk (8.6.10/8.6.12) with SMTP id TAA22461; Sun, 10 Mar 1996 19:28:07 GMT Received: from [129.215.162.86] by castle.ed.ac.uk id aa11499; 10 Mar 96 19:26 GMT X-Sender: ekya04@castle.ed.ac.uk Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Mar 1996 19:24:11 +0000 To: Andrew Swan , 298@bmrc.Berkeley.EDU, rowe@cs.berkeley.edu, Robert E Lamm , atm@bbn.com, end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, gtroup@dworkin.wustl.edu, ccrc@dworking.wustl.edu, arl@arl1.wustl.edu, ietf@isi.edu, rem-conf-request@es.net, tcplw@cray.com, tccc@cs.umass.edu, announcements.chi@xerox.com, simon@cui.unige.ch, sound@acm.org, sigmedia@bellcore.com, icad-request@santafe.edu, cip@bbn.com, iplpdn@cnri.reston.va.us, sip-request@catarina.usc.edu, smds@cnri.reston.va.us, s-comput%tcsvm.BITNET@earn-relay.ac.uk, ir-l , tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, sig11@roses.stanford.edu, klaus@informatik.rwth-aachen.de, wittig@vnet.ibm.com, hpdc@npac.syr.edu, jorg@mamba.cs.virginia.edu, sigmetrics_bb_list@tay1.dec.com, tccc@cs.umass.edu, multicomm@cc.bellcore.com, infobahn@cs.nps.navy.mil, rem-conf@es.net, Bruce Tonkin , multimedia@ed.ac.uk, mmis@mailbase.ac.uk, is-multimedia@mailbase.ac.uk, cscw-all@mailbase.ac.uk, make-music@mailbase.ac.uk, epublish@mailbase.ac.uk, cm-collab-learning@mailbase.ac.uk, business-information-all@mailba From: Alfonso Molina - Business Studies Subject: iTV96 Conference INTERACTIVE TELEVISION 1996 - THE SUPERHIGHWAY THROUGH THE HOME? CONFIGURING AND CONSOLIDATING THE VISION A world conference dedicated to interactive television To be held on the 3th, 4th and 5th September, 1996 At the University of Edinburgh - Edinburgh- Scotland, UK. First Call for Participation and Papers The University of Edinburgh's Technology Management and Policy Programme (TechmaPP) is organising the international conference and exhibition i-TV'96 The Superhighway through the Home? - Edinburgh, 3-5 September 1996. The aim of the conference is to provide an international forum for firms, government and academics to exchange experiences and configure and consolidate visions of the emerging Information Society, with specific focus on networked multimedia in the home. Trials and pilots around the world will be coming to Edinburgh to demonstrate their developments and share reflections about success, uncertainties, difficulties, opportunities, strategic approaches and ways of understanding the complexity of inventing the future. The conference starts from the fact that the development of the technology is only a small part of the innovation and diffusion of i-TV. Equally important are the societal issues of i-TV such as: * social and economic acceptance * business strategies to develop and sell services and products * social situating of new media technologies in the home * development of new business networks * regulatory and legislative issues This distinctive combination of practice and reflection in the beautiful setting of Edinburgh will provide a rich environment for companies, universities and government to come, share results and discuss contributions and approaches to building the information society. For further information, contact: James Stewart, Conference Secretary, Unived Technologies Ltd., P.O. Box 13967, Edinburgh EH16 52N, Scotland, UK. Tel: +44 131 650 3475; Fax: +44 131 650 3474; email: iTV96@ed.ac.uk; Internet (http://www.ed.ac.uk/iTV96/i-TV96.html) INTERACTIVE TELEVISION 1996 - THE SUPERHIGHWAY THROUGH THE HOME? CONFIGURING AND CONSOLIDATING THE VISION A world conference dedicated to interactive television To be held on the 3th, 4th and 5th September, 1996 At the University of Edinburgh - Edinburgh- Scotland, UK. First Call for Participation and Papers -------- Conference Themes The development of digital interactive technology is the phenomenon of the decade. The Conference will address this phenomenon by focusing on one of its most challenging aspects : how will the cultural and business success of conventional television be linked to the possibilities of digital networks and information technology. Speakers will be business practitioners and strategists, leading academic thinkers and government policy makers. They will bring strong visions of future developments based on direct experience and research. Participants will share and gain expert insight on media, technology, business and regulatory innovations, as well as entertainment and information culture. Who should attend? The Conference will interest those working in the creative or management aspects of television, telecommunications, retailing, advertising, computer networks, education, publishing, on-line services, business consultancy, market research, government policy, banking and finance and many others sectors. It will provide introductory sessions for those wishing to learn about the possibilities and issues in the development of interactive television. For those already engaged in 'inventing the future', the conference will provide a major forum for discussion of the successes and failures of recent years and a chance to configure and consolidate the visions that will convert today's experiments into tomorrow's daily experience. The Location i-TV'96 is being hosted by Edinburgh University, one of the UK's top research institutions. The University is a leader in the development of interactive media technology and applications, and specialises in research and consultancy in management and public policy related to innovation. As an additional attraction, the Conference will take place immediately after the Edinburgh International Festival which, with the Fringe Festival, the Television Festival, Jazz Festival and Film Festival, make the City the world's leading arts centre during the summer months. * Conference Themes * Conference Structure - intended audiences * Papers, Discussion Topics, Demonstrations, Exhibition space * Conference Secretary and Further Enquiries ---------------------------------------------------------------------------- This Conference is organised by The University of Edinburgh , TechMaPP: Technology and Management Policy Programme, - and supported by: C.E.C DG III - Industry, The European Commission DG III LEEL, Lothian and Edinburgh Enterprise Ltd Edinburgh District Council Edinburgh Telematic Partnership Scottish Enterprise SFE, Scottish Financial Enterprise Scotland Europa DTI's Information Society Initiative ---------------------------------------------------------------------------- Conference Themes Definition of Terms There is a wide debate regarding which platform and infrastructural mechanisms will bring interactive digital communications and new forms of services to the home. For the purposes of this conference, we use interactive television to mean the provision of all kind of interactive multimedia services to domestic spaces. However, the debate on technology is not isolated; it is closely related to the way people perceive and define the phenomenon: infohighway, superhighway, infobahn, networked multimedia, broadband services, Internet, interactive television are but a few variations on the theme. This proliferation of terms has resulted in much misinterpretation within the emerging industry and marketplace. At its most general interactive TV could include services accessed through a wide variety of platforms and infrastructures. At its most specific, it is services and content aimed at exploiting the merger of conventional and digital technologies and building on the familiarity and success of TV as we have come to know it. We believe that definition of terms is an issue to be addressed in this conference (particularly in respect to configuring and consolidating 'visions'). Turning Imagination into Reality It is widely recognised that the development of the information infrastructure and services is beyond the resources and capabilites of a single organisation. Success requires a major collaborative system-building exercise: the creation of new knowledge, technology, business partnerships and legal frameworks. It requires the integration of expertise and resources >from across industry sectors, user groups and governments. In the past few years, pioneers with strong visions of the potential of i-TV have made huge efforts to turn those visions into reality. Many lessons have been learnt >from these efforts, but only now are the technologies and the alliances really being put to the test, as real user trials are undertaken and competing technologies bid for the attention of the business sector and consumer markets. This is what the central theme of this conference is all about. It is about the visions shaping, and shaped by, socio-technical and socio-economic realities; it is about the opportunities, difficulties and real lessons drawn from the experience of current trials and pilots. The conference will highlight how much the vision of i-TV's potential is shared by designers and makers of i-TV technologies, services and content material. How much do these match the expectations and needs of potential consumers who form the 'early-adopters' of such systems? In all circumstances, designers of i-TV products must be able to visualise the capabilities, attributes, features and functionalities which will realistically satisfy the future demands and use of the new digital technologies and services. But how much are these imagined possibilities tempered, on the one hand, by development, manufacturing, production and marketing capabilities and, on the other, by issues of standardisation, legislation, and regulation. Other shaping forces derive from relations with commercial partners, fellow consortium members, individual clients needs, etc., and last but not least, the consumer market. These are all central concerns of the collective reflection the conference wishes to stimulate. i-TV into Everyday Life Consumers - those who will use i-TV in their everyday lives - must be in a position to anticipate and visualise its benefits before they buy or subscribe to it. Once they have bought into the system they must be able to realise the relevance and potential of i-TV products and services within the context of their existing media and leisure activities. In short, domestication is a key factor if i-TV is to be a market success. However, this demands more than good marketing. It requires a well informed understanding of how such technologies are likely to integrate into people's media and leisure activities. The conference focus here will be upon the psycho-social, economic and cultural elements which may motivate and contribute to i-TV consumption and use processes. The Innovation Question For company strategists, designers and marketing personnel innovating the new systems, key questions the conference will explore are: * What will be the relationship between current media/entertainment and the emerging opportunities made possible by the new channels, modes of interaction and use? * How can this be understood and tackled in economic, social, legal, cultural and semiotic dimensions? These questions involve a range of more specific themes of both a social and technical nature: Understanding possible uses and users (e.g., the situating of i-TV in the home; new ways of buying and selling goods; understanding the likely evolution of media consumption and communication due to the new technology; relevant methods of conducting user research; identify the socio- economic characteristics of new media markets) Getting the technology to work (e.g., cost-effectiveness, interface design; system architectures; standards; communications infrastructure) Getting content and service providers involved (e.g., why should service providers enter the learning process; how can the case for the new technology be made in contexts dominated by established technologies; how can the new opportunities be relevant to existing businesses) Creating and maintaining innovative alliances (e.g., integrating the multidisciplinary knowledge and expertise required for new content and services - what and who is needed and where can you go to get it? how can you stimulate effective communication and alignment between different organisations? - how can common visions be configured and consolidated for the benefit of all partners, including the consumer?) Creating the appropriate legislative and regulatory environment (e.g., the critical issues surrounding copyright, privacy, network regulation and universal access, secure commercial transactions, the standardisation process and so on) ---------------------------------------------------------------------------- Why this Conference? The motivation for this conference stems from an understanding that 'vision' plays a substantial part in shaping and bringing i-TV to the mass market. i-TV system-building is an extremely complex matter. There are many pitfalls when those involved in the development, propagation, regulation and consumption of the technology are not aligned in their perceptions of each other, their projects and their environment. This plays an important role in holding back the innovation and deployment of large-scale systems. Who will attend? This conference will bring together producers, innovators, potential distributors of i-TV hardware and services, financial organisations and public sector representatives (academics, government, politicians, and regulators). By reflecting on the successes and failures of practical experiences, they will share, define, agree and/or contest the visions and realities of i-TV and its anticipated users. Through focusing on real or hypothetical cities, regions and communities, the participants will explore how successful i-TV services will develop from the seeds of today's experiments. Further, the conference will serve as a forum for individuals or companies with little knowledge or experience of advanced media forms to learn something of the potential advantages and limitations of actual and future i-TV systems. In addition these participants will have the opportunity to engage the system promoters in discussions about what makes i-TV relevant to their business and communitiy. As such, the conference will provide a pragmatic learning environment for a multitude of individuals who have direct or indirect interest in the business of inventing the digital future. ---------------------------------------------------------------------------- The Conference Programme Day One: The What, Who, Why, Where and When of i-TV An entry level introduction as well as a strategic overview to what is and what will be available to consumers through i-TV technologies and services. The presentations will introduce the many facets of i-TV and other 'superhighway' technologies. The focus will be on their socio-economic, cultural, media and technical contexts. Day two: The Future Environment of i-TV Day Two will focus on service and content provision with particular emphasis on how i-TV may affect industries such as retail, service and media. It will stress the central role of these industries in the development and eventual success of i-TV. This will be of particular interest to those who promote or conduct their activities through the media and advertising. It will be of great interest to media and media-related businesses themselves; publishers, advertisers, infrastructure providers, distributors, graphic designers, film and television producers, as well as multimedia developers and programmers. Day three: Innovation of the i-TV industry Building on the issues of day 2, the conference will focus on real initiatives and issues in organisational, regulatory, infrastructure and technical change. It will include topics in the innovation process, such as alliance building, social learning, domestication of technology, technical standards, IPR, government and political agendas, and the development of new creative media languages. The conference will have concurrent sessions devoted to papers, presentations of current work and group discussions. In parallel, there will an exhibition and demonstration of leading-edge products and services from commercial experiences, trials, pilots and projects. Attendance is strictly limited, with an expected 400 core participants over the entire three days. Others are expected to attend individual days. A full-events calendar includes sightseeing, a formal civic reception and a conference dinner held in the centre of historic Edinburgh. ---------------------------------------------------------------------------- Papers, discussion topics, demonstrations, exhibition space The conference organisers will consider full papers and panel papers. Papers will be reviewed for acceptance and publication in the proceedings and a subsequent book. Final versions of accompanying videos will appear in the video proceedings. Please submit 5 copies of the abstract or proposed paper (maximum 6000 words) and 5 copies of any accompanying multimedia material with your name, address, phone, fax, and e-mail by May 1, 1996, to the Conference Secretary. Applications for exhibition or poster space should be made at the earliest possible time. Full technical assistance will be available on request. ---------------------------------------------------------------------------- Conference Secretary For Enquiries, Papers, and Pre-registration mail or phone James Stewart Research Centre for Social Sciences The University of Edinburgh Old Surgeons' Hall High School Yards Edinburgh EH1 1LZ +44- (0)131 650 6392 +44(0)131 650 6399 iTV96@ed.ac.uk ---------------------------------------------------------------------------- University of Edinburgh , Feb. 1996 http://www.ed.ac.uk/~rcss/iTV96/i-TV96.html From rem-conf-request@es.net Sun Mar 10 14:36:34 1996 Received: from haymarket.ed.ac.uk by osi-west.es.net with ESnet SMTP (PP); Sun, 10 Mar 1996 11:36:03 -0800 Received: from castle.ed.ac.uk (castle.ed.ac.uk [129.215.128.23]) by haymarket.ed.ac.uk (8.6.10/8.6.12) with SMTP id TAA22461; Sun, 10 Mar 1996 19:28:07 GMT Received: from [129.215.162.86] by castle.ed.ac.uk id aa11499; 10 Mar 96 19:26 GMT X-Sender: ekya04@castle.ed.ac.uk Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 10 Mar 1996 19:24:11 +0000 To: Andrew Swan , 298@bmrc.berkeley.edu, rowe@cs.berkeley.edu, Robert E Lamm , atm@bbn.com, end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, gtroup@dworkin.wustl.edu, ccrc@dworking.wustl.edu, arl@arl1.wustl.edu, ietf@isi.edu, rem-conf-request@es.net, tcplw@cray.com, tccc@cs.umass.edu, announcements.chi@xerox.com, simon@cui.unige.ch, sound@acm.org, sigmedia@bellcore.com, icad-request@santafe.edu, cip@bbn.com, iplpdn@cnri.reston.va.us, sip-request@catarina.usc.edu, smds@cnri.reston.va.us, s-comput%tcsvm.BITNET@earn-relay.ac.uk, ir-l , tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, sig11@roses.stanford.edu, klaus@informatik.rwth-aachen.de, wittig@vnet.ibm.com, hpdc@npac.syr.edu, jorg@mamba.cs.virginia.edu, sigmetrics_bb_list@tay1.dec.com, tccc@cs.umass.edu, multicomm@cc.bellcore.com, infobahn@cs.nps.navy.mil, rem-conf@es.net, Bruce Tonkin , multimedia@ed.ac.uk, mmis@mailbase.ac.uk, is-multimedia@mailbase.ac.uk, cscw-all@mailbase.ac.uk, make-music@mailbase.ac.uk, epublish@mailbase.ac.uk, cm-collab-learning@mailbase.ac.uk, business-information-all@mailba From: Alfonso Molina - Business Studies Subject: iTV96 Conference INTERACTIVE TELEVISION 1996 - THE SUPERHIGHWAY THROUGH THE HOME? CONFIGURING AND CONSOLIDATING THE VISION A world conference dedicated to interactive television To be held on the 3th, 4th and 5th September, 1996 At the University of Edinburgh - Edinburgh- Scotland, UK. First Call for Participation and Papers The University of Edinburgh's Technology Management and Policy Programme (TechmaPP) is organising the international conference and exhibition i-TV'96 The Superhighway through the Home? - Edinburgh, 3-5 September 1996. The aim of the conference is to provide an international forum for firms, government and academics to exchange experiences and configure and consolidate visions of the emerging Information Society, with specific focus on networked multimedia in the home. Trials and pilots around the world will be coming to Edinburgh to demonstrate their developments and share reflections about success, uncertainties, difficulties, opportunities, strategic approaches and ways of understanding the complexity of inventing the future. The conference starts from the fact that the development of the technology is only a small part of the innovation and diffusion of i-TV. Equally important are the societal issues of i-TV such as: * social and economic acceptance * business strategies to develop and sell services and products * social situating of new media technologies in the home * development of new business networks * regulatory and legislative issues This distinctive combination of practice and reflection in the beautiful setting of Edinburgh will provide a rich environment for companies, universities and government to come, share results and discuss contributions and approaches to building the information society. For further information, contact: James Stewart, Conference Secretary, Unived Technologies Ltd., P.O. Box 13967, Edinburgh EH16 52N, Scotland, UK. Tel: +44 131 650 3475; Fax: +44 131 650 3474; email: iTV96@ed.ac.uk; Internet (http://www.ed.ac.uk/iTV96/i-TV96.html) INTERACTIVE TELEVISION 1996 - THE SUPERHIGHWAY THROUGH THE HOME? CONFIGURING AND CONSOLIDATING THE VISION A world conference dedicated to interactive television To be held on the 3th, 4th and 5th September, 1996 At the University of Edinburgh - Edinburgh- Scotland, UK. First Call for Participation and Papers -------- Conference Themes The development of digital interactive technology is the phenomenon of the decade. The Conference will address this phenomenon by focusing on one of its most challenging aspects : how will the cultural and business success of conventional television be linked to the possibilities of digital networks and information technology. Speakers will be business practitioners and strategists, leading academic thinkers and government policy makers. They will bring strong visions of future developments based on direct experience and research. Participants will share and gain expert insight on media, technology, business and regulatory innovations, as well as entertainment and information culture. Who should attend? The Conference will interest those working in the creative or management aspects of television, telecommunications, retailing, advertising, computer networks, education, publishing, on-line services, business consultancy, market research, government policy, banking and finance and many others sectors. It will provide introductory sessions for those wishing to learn about the possibilities and issues in the development of interactive television. For those already engaged in 'inventing the future', the conference will provide a major forum for discussion of the successes and failures of recent years and a chance to configure and consolidate the visions that will convert today's experiments into tomorrow's daily experience. The Location i-TV'96 is being hosted by Edinburgh University, one of the UK's top research institutions. The University is a leader in the development of interactive media technology and applications, and specialises in research and consultancy in management and public policy related to innovation. As an additional attraction, the Conference will take place immediately after the Edinburgh International Festival which, with the Fringe Festival, the Television Festival, Jazz Festival and Film Festival, make the City the world's leading arts centre during the summer months. * Conference Themes * Conference Structure - intended audiences * Papers, Discussion Topics, Demonstrations, Exhibition space * Conference Secretary and Further Enquiries ---------------------------------------------------------------------------- This Conference is organised by The University of Edinburgh , TechMaPP: Technology and Management Policy Programme, - and supported by: C.E.C DG III - Industry, The European Commission DG III LEEL, Lothian and Edinburgh Enterprise Ltd Edinburgh District Council Edinburgh Telematic Partnership Scottish Enterprise SFE, Scottish Financial Enterprise Scotland Europa DTI's Information Society Initiative ---------------------------------------------------------------------------- Conference Themes Definition of Terms There is a wide debate regarding which platform and infrastructural mechanisms will bring interactive digital communications and new forms of services to the home. For the purposes of this conference, we use interactive television to mean the provision of all kind of interactive multimedia services to domestic spaces. However, the debate on technology is not isolated; it is closely related to the way people perceive and define the phenomenon: infohighway, superhighway, infobahn, networked multimedia, broadband services, Internet, interactive television are but a few variations on the theme. This proliferation of terms has resulted in much misinterpretation within the emerging industry and marketplace. At its most general interactive TV could include services accessed through a wide variety of platforms and infrastructures. At its most specific, it is services and content aimed at exploiting the merger of conventional and digital technologies and building on the familiarity and success of TV as we have come to know it. We believe that definition of terms is an issue to be addressed in this conference (particularly in respect to configuring and consolidating 'visions'). Turning Imagination into Reality It is widely recognised that the development of the information infrastructure and services is beyond the resources and capabilites of a single organisation. Success requires a major collaborative system-building exercise: the creation of new knowledge, technology, business partnerships and legal frameworks. It requires the integration of expertise and resources >from across industry sectors, user groups and governments. In the past few years, pioneers with strong visions of the potential of i-TV have made huge efforts to turn those visions into reality. Many lessons have been learnt >from these efforts, but only now are the technologies and the alliances really being put to the test, as real user trials are undertaken and competing technologies bid for the attention of the business sector and consumer markets. This is what the central theme of this conference is all about. It is about the visions shaping, and shaped by, socio-technical and socio-economic realities; it is about the opportunities, difficulties and real lessons drawn from the experience of current trials and pilots. The conference will highlight how much the vision of i-TV's potential is shared by designers and makers of i-TV technologies, services and content material. How much do these match the expectations and needs of potential consumers who form the 'early-adopters' of such systems? In all circumstances, designers of i-TV products must be able to visualise the capabilities, attributes, features and functionalities which will realistically satisfy the future demands and use of the new digital technologies and services. But how much are these imagined possibilities tempered, on the one hand, by development, manufacturing, production and marketing capabilities and, on the other, by issues of standardisation, legislation, and regulation. Other shaping forces derive from relations with commercial partners, fellow consortium members, individual clients needs, etc., and last but not least, the consumer market. These are all central concerns of the collective reflection the conference wishes to stimulate. i-TV into Everyday Life Consumers - those who will use i-TV in their everyday lives - must be in a position to anticipate and visualise its benefits before they buy or subscribe to it. Once they have bought into the system they must be able to realise the relevance and potential of i-TV products and services within the context of their existing media and leisure activities. In short, domestication is a key factor if i-TV is to be a market success. However, this demands more than good marketing. It requires a well informed understanding of how such technologies are likely to integrate into people's media and leisure activities. The conference focus here will be upon the psycho-social, economic and cultural elements which may motivate and contribute to i-TV consumption and use processes. The Innovation Question For company strategists, designers and marketing personnel innovating the new systems, key questions the conference will explore are: * What will be the relationship between current media/entertainment and the emerging opportunities made possible by the new channels, modes of interaction and use? * How can this be understood and tackled in economic, social, legal, cultural and semiotic dimensions? These questions involve a range of more specific themes of both a social and technical nature: Understanding possible uses and users (e.g., the situating of i-TV in the home; new ways of buying and selling goods; understanding the likely evolution of media consumption and communication due to the new technology; relevant methods of conducting user research; identify the socio- economic characteristics of new media markets) Getting the technology to work (e.g., cost-effectiveness, interface design; system architectures; standards; communications infrastructure) Getting content and service providers involved (e.g., why should service providers enter the learning process; how can the case for the new technology be made in contexts dominated by established technologies; how can the new opportunities be relevant to existing businesses) Creating and maintaining innovative alliances (e.g., integrating the multidisciplinary knowledge and expertise required for new content and services - what and who is needed and where can you go to get it? how can you stimulate effective communication and alignment between different organisations? - how can common visions be configured and consolidated for the benefit of all partners, including the consumer?) Creating the appropriate legislative and regulatory environment (e.g., the critical issues surrounding copyright, privacy, network regulation and universal access, secure commercial transactions, the standardisation process and so on) ---------------------------------------------------------------------------- Why this Conference? The motivation for this conference stems from an understanding that 'vision' plays a substantial part in shaping and bringing i-TV to the mass market. i-TV system-building is an extremely complex matter. There are many pitfalls when those involved in the development, propagation, regulation and consumption of the technology are not aligned in their perceptions of each other, their projects and their environment. This plays an important role in holding back the innovation and deployment of large-scale systems. Who will attend? This conference will bring together producers, innovators, potential distributors of i-TV hardware and services, financial organisations and public sector representatives (academics, government, politicians, and regulators). By reflecting on the successes and failures of practical experiences, they will share, define, agree and/or contest the visions and realities of i-TV and its anticipated users. Through focusing on real or hypothetical cities, regions and communities, the participants will explore how successful i-TV services will develop from the seeds of today's experiments. Further, the conference will serve as a forum for individuals or companies with little knowledge or experience of advanced media forms to learn something of the potential advantages and limitations of actual and future i-TV systems. In addition these participants will have the opportunity to engage the system promoters in discussions about what makes i-TV relevant to their business and communitiy. As such, the conference will provide a pragmatic learning environment for a multitude of individuals who have direct or indirect interest in the business of inventing the digital future. ---------------------------------------------------------------------------- The Conference Programme Day One: The What, Who, Why, Where and When of i-TV An entry level introduction as well as a strategic overview to what is and what will be available to consumers through i-TV technologies and services. The presentations will introduce the many facets of i-TV and other 'superhighway' technologies. The focus will be on their socio-economic, cultural, media and technical contexts. Day two: The Future Environment of i-TV Day Two will focus on service and content provision with particular emphasis on how i-TV may affect industries such as retail, service and media. It will stress the central role of these industries in the development and eventual success of i-TV. This will be of particular interest to those who promote or conduct their activities through the media and advertising. It will be of great interest to media and media-related businesses themselves; publishers, advertisers, infrastructure providers, distributors, graphic designers, film and television producers, as well as multimedia developers and programmers. Day three: Innovation of the i-TV industry Building on the issues of day 2, the conference will focus on real initiatives and issues in organisational, regulatory, infrastructure and technical change. It will include topics in the innovation process, such as alliance building, social learning, domestication of technology, technical standards, IPR, government and political agendas, and the development of new creative media languages. The conference will have concurrent sessions devoted to papers, presentations of current work and group discussions. In parallel, there will an exhibition and demonstration of leading-edge products and services from commercial experiences, trials, pilots and projects. Attendance is strictly limited, with an expected 400 core participants over the entire three days. Others are expected to attend individual days. A full-events calendar includes sightseeing, a formal civic reception and a conference dinner held in the centre of historic Edinburgh. ---------------------------------------------------------------------------- Papers, discussion topics, demonstrations, exhibition space The conference organisers will consider full papers and panel papers. Papers will be reviewed for acceptance and publication in the proceedings and a subsequent book. Final versions of accompanying videos will appear in the video proceedings. Please submit 5 copies of the abstract or proposed paper (maximum 6000 words) and 5 copies of any accompanying multimedia material with your name, address, phone, fax, and e-mail by May 1, 1996, to the Conference Secretary. Applications for exhibition or poster space should be made at the earliest possible time. Full technical assistance will be available on request. ---------------------------------------------------------------------------- Conference Secretary For Enquiries, Papers, and Pre-registration mail or phone James Stewart Research Centre for Social Sciences The University of Edinburgh Old Surgeons' Hall High School Yards Edinburgh EH1 1LZ +44- (0)131 650 6392 +44(0)131 650 6399 iTV96@ed.ac.uk ---------------------------------------------------------------------------- University of Edinburgh , Feb. 1996 http://www.ed.ac.uk/~rcss/iTV96/i-TV96.html From rem-conf-request@es.net Sun Mar 10 14:43:20 1996 Received: from basil.cdt.luth.se by osi-west.es.net with ESnet SMTP (PP); Sun, 10 Mar 1996 11:40:53 -0800 Received: from kalkyl.cdt.luth.se (kalkyl.cdt.luth.se [130.240.193.31]) by basil.cdt.luth.se (8.6.12/8.6.12) with ESMTP id UAA20382; Sun, 10 Mar 1996 20:36:24 +0100 Received: from kalkyl (localhost [127.0.0.1]) by kalkyl.cdt.luth.se (8.6.12/8.6.12) with ESMTP id UAA13084; Sun, 10 Mar 1996 20:38:34 +0100 Message-Id: <199603101938.UAA13084@kalkyl.cdt.luth.se> X-Mailer: exmh version 1.6.4 10/10/95 To: rem-conf@es.net cc: mates@cdt.luth.se X-uri: http://www.cdt.luth.se/~peppar/ Subject: Draft: RTP extension for Scalable Reliable Multicast, version 1.3 Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="===_0_Sun_Mar_10_20:37:58_MET_1996" Date: Sun, 10 Mar 1996 20:38:34 +0100 From: Peter Parnes This is a multipart MIME message. --===_0_Sun_Mar_10_20:37:58_MET_1996 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Here's a new version of my draft for you to comment :-) It's version 1.3.= = I've added discussions about the timers and host-to-host calculations. I = now can say that I don't have a working prototype :-) = Are people interested in diff-files? The draft has grown from 7 to 11 pag= es. = I'd appreciate if someone could tell how to make a nice postscript-versio= n of a nroff-version of the draft. How does people usually write drafts? = I had to learn nroff again, it's simple but I don't remember the fancy st= uff :-) = /P --===_0_Sun_Mar_10_20:37:58_MET_1996 Content-Type: text/plain; charset=iso-8859-1 Content-Description: draft-parnes-avt-srm-00.txt Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force Peter Parnes INTERNET-DRAFT LuTH/CDT March 10, 1996 Expires: X/X/96 RTP extension for Scalable Reliable Multicast <$Id: draft-parnes-avt-srm-00.ms,v 1.3 1996/03/10 19:27:39 pepparh Exp $>= Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document describes how the Real-time Transport Protocol [RFC- 1889] could be extended to include support for Scalable Reliable Multicast. The scheme proposed could be used for transporting a data flow reliably over the transport protocols supported by RTP. Peter Parnes [Page 1] =0C INTERNET-DRAFT RTP/SRM March 1996 1. Introduction The Real-time Transport Protocol, (RTP) [RFC-1889] is based on UDP which is a best-effort transport protocol meaning that packets can be lost. For some applications this is acceptable but for other, for instance white-board-applications, it is necessary to do retransmission so an end-user can rely on that he has received everything that someone else has sent. This document describe how RTP could be extended to include support for Scalable Reliable Multicast. The scheme proposed could be used for transporting a data flow reliably over the transport protocols supported by RTP. This new RTP/SRM-platform could be used for numerous applications, for instance semi-reliable audio/video, distributed group-ware applications, WWW-cache and FTP updates etc, etc. 2. Scalable Reliable Multicast Scalable Reliable Multicast,(SRM) [SRM-95] is a reliable multicast framework for application level framing and light-weight sessions. The algorithms of this framework are efficient, robust and scale well to both very large networks and very large sessions. The framework has been prototyped in wb, a distributed white-board application, and has been extensively tested on a global scale with sessions ranging from a few to more than 1000 participants. 2.1 The SRM ideas The ideas of SRM can be described as follows: 1) Every packet transmitted is uniquely identified by a sender- identification and a sequence-number that is incremented by one for each transmitted packet. 2) Every member of the sessions buffers a certain amount of packets, even if she is only a receiver and not a sender, so if necessary she can participate in 'repairs' of lost packets. 3) When a receiver notices that she has lost packets (by checking if the difference of the sequence-numbers of the incoming packet and the last heard packet before that is greater than 1) she sends a negative acknowledgment, NACK, using multicasting so all members of the session sees the NACK. But before sending the NACK she wait for a random time determined by the distance of the original source and if she hears a NACK for the same packet Peter Parnes [Page 2] =0C INTERNET-DRAFT RTP/SRM March 1996 from another member she suppress her own NACK. See section 4 for a discussion of how the timers and distance should be calculated. 4) Any member that gets a NACK and has the packet requested can send a repair but just as in the NACK-case she waits a random time before sending the repair. Again see section 4 for the calculation of the delay-timers. 5) Loss is detected by finding a gap in the sequence space but since it is possible the last data-packet is dropped, each sender send a low-rate, periodic, message, (a heartbeat) announcing the highest sequence number used. Please note that this only gives the ideas of the algorithms used and implementers should read the SRM-paper first. 3. Calculating timers (point 6) Every timer is based on the distance, D, between the sender and the receiver. A member that only is active in repairs is also called a sender. 3.1 NACK timers When loss is detected a timer is started. The expire-time is chosen from the uniform distribution on 2^i*[C1*Dsa, (C1+C2)*Dsa] seconds, where Dsa is host A's estimate of the one-way delay to the original source S of the missing data, C1 and C2 are parameters of the request algorithm and i is initially 0. When the request timer expires, host A multicasts the NACK for the missing data, and doubles the request timer by increasing i to wait for the repair. If host A receives a NACK for the missing data before its own request timer for that missing data expires, then host A does a (random) exponential back-off, and resets its request timer. This means that the new timers expire-time is randomly chosen from the uniform distribution on 2^(i+1)*[C1*Dsa, (C1+C2)*Dsa] To improve the repair time we don't back-off the request timer for every duplicate request that is received. For example, if a member receives several duplicate requests immediately after receiving the Peter Parnes [Page 3] =0C INTERNET-DRAFT RTP/SRM March 1996 initial request, then that member only backs off its request timer once, not several times. After the initial timer back-off, we only back-off the timer again if a request is received close to the time when the timer is set to expire. More precisely, when we back-off the request timer, then we set an ignore-back-off variable to a time halfway between the current time and the expiration time, and we ignore additional duplicate requests until ignore-back-off time. 3.2 Repair timers When host B receives a request from A that host B is capable of answering, host B sets a repair timer to a random value from the uniform distribution on [D1*Dab, (D1+D2)*Dab] seconds where Dab is host B's estimate of the one-way delay to host A, and D1 and D2 are parameters of the repair algorithm. If host B receives a repair for the missing data before its repair timer expires, host B cancels its repair timer. Otherwise, when host B's repair timer for that data expires host B multicasts the repair. A host could receive duplicate NACKs immediately after sending a repair and in order to prevent duplicate NACKs from triggering a responding set of duplicate repairs, host B ignores NACKs for data d for 3*Dsb seconds after sending or receiving a repair for that data, where host s is either the original source of data d or the source of the first NACK. 3.3 Initial values of the timer parameters The initial values of the timer parameters should be set to C1=3DC2=3D= 2, D1=3DD2=3Dlog10(G), where G is is the current number of members in the= session. An adaptive algorithm for changing these parameters is presented in [SRM-1995]. 4. Calculating the host-to-host distances (point 7) In order to be able to calculate the NACK and repair timers we need to have some knowledge of the host-to-host distance. This distance is calculated in seconds based on how long it takes for a packet to travel from host A to host B. To be able to do this each member of the session sends a time-stamp. This time-stamp is used in the following way to calculate the host- Peter Parnes [Page 4] =0C INTERNET-DRAFT RTP/SRM March 1996 to-host distance: Assume that host A sends a session packet P1 at time t1 and host B receives P1 at time t2. At some later time, t3, host B generates a session packet P2, containing (t1, d), where d =3D t3 - t2 (time t1 is included in P2 to make the algorithm robust to lost session packets). Upon receiving P2 at time t4, host A can estimate the latency from host B to host A as (t4 - t1 - d)/2. Note that while this estimate does assume that the paths are symmetric, it does not assume synchronized clocks. 5. How does SRM fit into RTP? Here follows a description of how the SRM ideas fit into RTP according to the points in earlier sections. The points here, marked with a changes. 1) RTP has a unique sender-ID, the Synchronization Source (SSRC) and each data-packet has a sequence-number. 2) The buffering can be accomplished without interfering with the protocol itself. 3*) The transmission of NACKs has to be incorporated into RTP using the Real-time Transport Control Protocol, RTCP. 4*) The repairs can either be sent directly without any discrimination from the original packet over the same RTP- data-channel (no change to RTP needed) or it could be marked as special data which would imply changes to RTP. 5*) The heartbeats have to be incorporated into RTP/RTCP. 6) The timer calculations don't imply any changes to RTP/RTCP. 7*) The time-stamps should be incorporated into RTCP. The NTP- time-stamp in the RTCP/SR packet can't be used as the RTP specification has left it optional for clients to use this field. In order to calculate the host-to-host delay all clients need to have some notion of wall-clock time or elapsed time. Out-of-order packets could initially be seen as lost packets and lead to a started NACK-timer but when the "lost" packet(s) arrives the NACK-timer should be cancelled and an ignore flag should be hissed for a time of 3*Dsa, where Dsa is the receivers notion of the distance to the sender. All further NACKs received within this time should be ignored. Peter Parnes [Page 5] =0C INTERNET-DRAFT RTP/SRM March 1996 6. What extensions are needed in RTP/RTCP This section explains the additions to RTP/RTCP. The added packet- formats are discussed section 7. 6.1 NACKs (point 3) The NACK-transmissions should be implemented using RTCP by adding a new RTCP type, SRM =3D 205. 6.2 Retransmission of data-packets (point 4) Retransmissions are sent on the RTP-data-port just as ordinary data- packets. The retransmissions could be handled in two ways: * Either we just let applications that don't understand the SRM- extension see the retransmitted packets as original data and interpret them as duplicates or late packets. This would be nice because applications that don't understand SRM would benefit, but this would unfortunately 'break' traffic estimation and analysis programs. It would also break applications like for instance the MBone-tool VAT because they adjust the play-out delay according to the jitter of the incoming packets. * Or some mechanism for encapsulating the packet, for instance using Mark Handley's proposed new payload-type for redundant data? This would not break existing applications. The second method is to be used. 6.3 Heartbeats (point 5) The heartbeats could be incorporated into the SR-packets using the "profile-specific-extensions" but two things talk against this: * This isn't inter-operable with other payload-specific-extensions as we only can have one header-extension. * The SR-packets are only sent during and once right after a sender transmits data but the heartbeats should be sent all the time, so a receiver that have lost several packets directly after the end of the data-flow would notice that she has lost packets. Instead the heartbeats should be sent using the new RTCP-SRM type. These heartbeats should be sent more often right after a sender has Peter Parnes [Page 6] =0C INTERNET-DRAFT RTP/SRM March 1996 stopped sending so receivers can notice that they have lost packets more quickly. This isn't a problem for small groups as the dynamic delay between RTCP-packets is small but in larger groups the delay could become a problem. 6.4 Time-stamps (point 7) The time-stamps should be added into the new RTCP-type and divided into two modes. The first mode is "time-stamp queries" where a member sends out his wall-clock time-stamp and every other member of the session is expected to answer this query using the second mode "time-stamp replies". A time-stamp query should be included in the first RTCP-packet that a new member sends out after joining the session. Replies to pending queries (if any) should be sent each time we send a RTCP-packet. Several replies can be contained in the same RTCP- packet as this would lower the overhead. The time-stamp replies for a new member should have higher priority than replies for an old member. When old receivers see a new member they should set a query-timer chosen randomly from the interval [0.5 , 5]*current_RTCP_interval with a minimum of 5 seconds and a maximum of 2 minutes. If they before the expire don't see another query they send out a query of their own. If they on the other hand do see a query they reset their query-timer and choose a new random expire-time. Each 5*current_RTCP_interval since last query, (minimum 2 minutes, maximum 5 minutes) the member sends out a new query. 7. Packet format This section explains the format of the RTCP-SRM packet. The header is the same for all RTCP-SRM packets: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=3D2|CM | Count | PT=3DSRM=3D205 | length = | header +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ Version (V): 2 bits Peter Parnes [Page 7] =0C INTERNET-DRAFT RTP/SRM March 1996 Identifies the version of RTP, two (2). Command (CM): 2 bits The SRM-command as defined below. Count: 4 bits The number of command-data-fields minus one included in this packet. How this field is used depends on the command. Packet type (PT): 8 bits Contains the constant 205 to identify this as an RTCP SRM packet. Packet length (length): 16 bits The length of this RTCP packet in 32-bit words minus one, including the header. (The offset of one makes zero a valid length and avoids a possible infinite loop in scanning a compound RTCP packet, while counting 32-bit words avoids a validity check for a multiple of 4.) Depending on the Command (CM) field the header is followed by any of the following: 7.1 Heartbeat (CM=3D0) For heartbeats CM contains the constant 0 and the header is followed by 16-bits containing the latest sequence number used by the sender of this packet. The sender is identified by the SSRC field in the SR or RR-report that must come before this SRM-packet. The other 16-bits are not used. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | Not Used | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ 7.2 NACK (CM=3D1) Each NACK-packet includes NACKs for one sender but several NACK- packets may be included into one compound RTCP-packet. For NACKs, CM contains the constant 1 and the count field contains the number of NACKs minus one included in this SRM-packet. This makes zero a useful number as it doesn't make much sense to send an empty NACK packet just containing the SSRC. The header is followed by the following: Peter Parnes [Page 8] =0C INTERNET-DRAFT RTP/SRM March 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence number | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ SSRC: 32 bits The SSRC from the sender from whom we have lost a packet. Sequence number: 32 bits The sequence number for the lost packet from this certain SSRC. 7.3 Time-stamp queries (CM=3D2) To be able to calculate the host-to-host delay a member has to send out a time-stamp. The time-stamp is composed as the 32 middle bits of a 64 bits NTP time-stamp, meaning the 16 first bits signify the seconds and the later 16 bits signifying the fraction. The field CM of the header contains the constant 2 and the count field is not used. The header is followed by the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | time-stamp | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ time-stamp: 32 bits The senders current wall-clock time as defined above. 7.4 Time-stamp replies (CM=3D3) Several time-stamp replies can be contained in the same SRM-packet and the number of replies are count+1. A reply-packet for a certain receiver should only be issued if we earlier have received a time-stamp query. Peter Parnes [Page 9] =0C INTERNET-DRAFT RTP/SRM March 1996 The header is followed by the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC_1 |block= 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Last time-stamp(LTQ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLTQ | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ | SSRC_2 |block= 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+ SSRC_n: 32 bits To whom we are answering. Last time-stamp query (LTQ): 32 bits The time-stamp that SSRC_n sent out earlier Delay since last time-stamp query (DLTQ): 32 bits The delay, expressed in units of 1/65536 seconds, between receiving the last time-stamp query packet from source SSRC_n and sending this reply. If SSRC_n receives this reply at time A the host-to-host delay, D, can be calculated as D =3D (A - LTQ - DLTQ) / 2 8. Further issues [SRM-1995] presents algorithms for dynamically adjusting the timer parameters C1,C2,D1 and D2. These algorithms should be included but do not imply any changes to the actual packet-format. It also presents methods for "local recovery" meaning that we don't multicast NACKs to the whole session but instead minimize the scope of the NACKs by adjusting the TTL. This TTL is adaptively changing as clients get to know the "loss neighbourhood". 9. Acknowledgments I'd like to thank Anders Klemets, Jon Crowcroft and Todd Montgomery for creative comments and encouragements. Peter Parnes [Page 10] =0C INTERNET-DRAFT RTP/SRM March 1996 This work is done within the Multimedia Assisted distributed Tele- Engineering Services, MATES, project (ESPRIT 20598) which I'd like to thank for the support. I'd also want to thank the Department of Computer Science and the Centre for Distance-spanning Technology at LuTH for giving me the opportunity to do this work. And of course nanna, J{D. 10. Author's Address Peter Parnes CDT/Dept. of CS University of Lulea S-971 87 Lulea, Sweden Tel: +46 920 72421 Fax: +46 920 91074 E-Mail: peppar@cdt.luth.se WWW: 11. References [RFC-1889] Schulzrine/Casner/Frederic/Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996 [SRM-95] Floyd/Jacobson/McCanne/Liu/Zhang, "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing", Proceedings of ACM SIGCOMM 95, . An extended and corrected version is submitted to IEEE/ACM Transactions on Networking, $Id: draft-parnes-avt-srm-00.ms,v 1.3 1996/03/10 19:27:39 pepparh Exp $ Peter Parnes [Page 11] --===_0_Sun_Mar_10_20:37:58_MET_1996-- From rem-conf-request@es.net Sun Mar 10 21:19:37 1996 Received: from cs.rpi.edu by osi-west.es.net with ESnet SMTP (PP); Sun, 10 Mar 1996 18:19:01 -0800 Received: from colossus.cs.rpi.edu by cs.rpi.edu (5.67a/1.4-RPI-CS-Dept) id AA00192; Sun, 10 Mar 1996 21:19:41 -0500 (glinert from colossus.cs.rpi.edu) Date: Sun, 10 Mar 96 21:19:34 EST From: glinert@cs.rpi.edu Received: by colossus.cs.rpi.edu (4.1/2.3-RPI-CS-client) id AA27407; Sun, 10 Mar 96 21:19:34 EST Message-Id: <9603110219.AA27407@colossus.cs.rpi.edu> To: end2end-interest@venera.isi.edu, f-troup@AURORA.CIS.UPENN.edu, ir-l%uccvma.bitnet@cunyvm.cuny.edu, rem-conf-request@es.net, rem-conf@es.net, sound@PASCAL.acm.org, tccc@cs.umass.edu Subject: Reminder: ASSETS'96 ASSETS'96 The 2nd International ACM Conference on Assistive Technologies April 11 - 12, 1996 Waterfront Centre Hotel, Vancouver BC, Canada The cutoff for the EARLY REGISTRATION DISCOUNT is approaching The cutoff for hotel rooms at the special conference rate is MARCH 15 ===>> ===>> SPACE IS GOING FAST, DON'T BE LEFT OUT! <<=== <<=== Sponsored by the ACM's Special Interest Group on Computers and the Physically Handicapped, ASSETS'96 is the second of a new series of conferences whose goal is to provide a forum where researchers and developers from academia and industry can meet to exchange ideas and report on new developments relating to computer-based systems to help people with impairments and disabilities of all kinds. A copy of the Registration Forms is attached. The Advance Program can be viewed on the conference web pages at http://www.cs.rpi.edu/assets For further information, please contact the ASSETS'96 General Chair: Ephraim P. Glinert Dept. of Computer Science, RPI, Troy NY 12180 Phone: (518) 276 2657 E-mail: glinert@cs.rpi.edu /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ ASSETS'96 REGISTRATION FORM =========================== This form is 2 pages long. Please print it out, complete both pages and mail it WITH FULL PAYMENT to: Ephraim P. Glinert, ASSETS'96 Dept. of Computer Science R. P. I. Troy, NY 12180 We're sorry, but e-mail registration forms and/or forms not accompanied by full payment (check or credit card information) CANNOT be accepted. CONFERENCE REGISTRATION FEES EARLY LATE / ON-SITE -------------------------------------------------------- ACM member: $ 395 $ 475 Nonmember: $ 580 $ 660 Full time student: $ 220 $ 270 -------------------------------------------------------- 1: CONFERENCE REGISTRATION (from the table above): $ ___________ 2: SECOND BUFFET DINNER TICKET (Thursday, April 11): $ 50 ___YES ___NO 3: SECOND COPY OF THE CONFERENCE PROCEEDINGS: $ 30 ___YES ___NO TOTAL AMOUNT DUE: $ ___________ NOTES: o Registration fee includes: ADMISSION to all sessions ONE COPY of the conference PROCEEDINGS RECEPTION, 5 MEALS AND 4 BREAKS as shown in the Advance Program!!! o To qualify for the EARLY RATE, your registration must be postmarked on or before WEDNESDAY, MARCH 27, 1996. If you are an ACM MEMBER, please supply your ID# __________________ . STUDENTS, please attach a clear photocopy of your valid student ID. o CANCELLATIONS will be accepted up to FRIDAY, MARCH 15, 1996 subject to a 20% handling fee. ASSETS'96 REGISTRATION FORM (continued) ======================================= PERSONAL INFORMATION: Name __________________________________________________________________________ Affiliation ___________________________________________________________________ Address _______________________________________________________________________ City _______________________________ State/Province __________________________ Country __________________________________ ZIP/Postal Code ___________________ E-mail ________________________________________________________________________ Phone ___________________________________ FAX ________________________________ ***I have a disability for which I require special accommodation ___YES ___NO If YES, please attach a separate sheet with details. Thank you! PAYMENT INFORMATION: ___CHECK in U.S. funds enclosed, made payable to "ACM ASSETS'96" ___Please charge $ ___________ to my CREDIT CARD: Card type: ___AMEX ___VISA ___MasterCard Card # _______________________________________ Expiration Date ___________ Name On Card ______________________________________________________________ Billing Address ___________________________________________________________ Cardholder Signature ________________________________________ (ASSETS'96) /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ HOTEL INFORMATION ================= All conference events will take place at the Waterfront Centre Hotel, a member of the Canadian Pacific group. The hotel is located in downtown Vancouver, next to the convention center and cruise ship terminal. Waterfront Centre Hotel 900 Canada Place Way Vancouver, British Columbia V6C 3L5 CANADA Phone: (604) 691 1991 or (800) 441 1414 FAX: (604) 691 1999 A block of rooms for attendees of ASSETS'96 has been set aside at specially discounted rates: Single $140 Canadian per night, plus applicable taxes Double/Twin $160 Canadian per night, plus applicable taxes Waterfront Suite $360 Canadian per night, plus applicable taxes To reserve space at these prices, please call the hotel directly on or before MARCH 15, 1996 and refer to "ACM ASSETS'96". /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ From rem-conf-request@es.net Mon Mar 11 02:55:02 1996 Received: from kanto.cc.jyu.fi by osi-west.es.net with ESnet SMTP (PP); Sun, 10 Mar 1996 23:54:36 -0800 Received: (from kallio@localhost) by kanto.cc.jyu.fi (8.7.2/8.7.2) id JAA29183; Mon, 11 Mar 1996 09:54:21 +0200 (EET) Date: Mon, 11 Mar 1996 09:54:21 +0200 (EET) From: Seppo Kallio To: "Bryan J. Tarr" cc: rem-conf@es.net Subject: Re: Windows95 mbone tools In-Reply-To: <1.5.4b11.32.19960308061342.00a1f420@resnet.uoregon.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Look at ftp.funet.fi there is winsd, winvat, winnv + some other tools. maybe pub/networking/multicast/msdos ? Seppo On Thu, 7 Mar 1996, Bryan J. Tarr wrote: > Are there any windows95 mbone tools available? I looked in the > archives on this subject and was unable to find an answer. I have heard > that windows95 has native support for multicast but I can't find any tools. > > Thank you, > > Bryan Tarr | Phone: (541) 346-9656 > Residence Network Assistant | sysadmin: resnet.uoregon.edu > University of Oregon Housing | email: btarr@resnet.uoregon.edu > From rem-conf-request@es.net Mon Mar 11 05:18:47 1996 Received: from basil.cdt.luth.se by osi-west.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 02:18:17 -0800 Received: from ganymede.cdt.luth.se (root@ganymede.cdt.luth.se [130.240.34.6]) by basil.cdt.luth.se (8.6.12/8.6.12) with ESMTP id LAA25561 for ; Mon, 11 Mar 1996 11:17:08 +0100 Received: from ganymede.cdt.luth.se (hakanl@localhost [127.0.0.1]) by ganymede.cdt.luth.se (8.6.12/8.6.12) with ESMTP id LAA05713 for ; Mon, 11 Mar 1996 11:15:12 +0100 Message-Id: <199603111015.LAA05713@ganymede.cdt.luth.se> X-Mailer: exmh version 1.6.2 7/18/95 To: rem-conf@es.net Subject: Re: Windows95 mbone tools Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Mar 1996 11:15:09 +0100 From: Hakan Lennestal In message , Seppo Kallio writes: > > > Look at ftp.funet.fi there is winsd, winvat, winnv + some other tools. > > maybe pub/networking/multicast/msdos ? > > Seppo > > On Thu, 7 Mar 1996, Bryan J. Tarr wrote: > > > Are there any windows95 mbone tools available? I looked in the > > archives on this subject and was unable to find an answer. I have heard > > that windows95 has native support for multicast but I can't find any tools. > > > > > Thank you, > > > > Bryan Tarr | Phone: (541) 346-9656 > > Residence Network Assistant | sysadmin: resnet.uoregon.edu > > University of Oregon Housing | email: btarr@resnet.uoregon.edu > > Hi all ! Winsd, winvat and winnv does only work with a specific ip protocol stack (can't remember which). I do however know by personal experience that it does not work with the MS or the PC-TCP stack. Also, these implementations is now rather old and came out from a now terminated (?) project at the university of Singapore. The original source code for vic (2.7 a37) and vat (4.0 a6) is now according to the README-files adapted for Win32. Are binaries for these available anywhere ? o o /Hakan Lennestal From rem-conf-request@es.net Mon Mar 11 08:24:46 1996 Received: from cerc.wvu.edu (actually cathedral.cerc.wvu.edu) by osi-west.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 05:24:11 -0800 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA22870; Mon, 11 Mar 96 08:24:03 EST Received: by elk (5.x//ident-1.0) id AA12581; Mon, 11 Mar 1996 08:23:59 -0500 Date: Mon, 11 Mar 1996 08:23:58 -0500 (EST) From: "Todd L. Montgomery" Subject: Re: SRM To: Lixia Zhang Cc: rem-conf@es.net In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 10 Mar 1996, Lixia Zhang wrote: > here's my understanding: instead of extending the session msg period, > one simply limits the msg size to a reasonable MTU, and round-robin > over all the members. There are a number of heuristics to decide > whose info to put into a session msg when it cannot include info for > all the members (e.g. give priority to the most recent change, etc). Makes sense... > > Another question I have.... are the session messages used for message > > stability? > > not sure I understand what you meant by "message stability". A message is stable when you know everyone has it and you can get rid of it. By looking at the session messages, I was thinking that perhaps the session messages could be used to limit SRMs buffering. Actually, the thought was only passing because there is now way in SRM to know who "everyone" is composed of since it is designed into wb. Stability has to be a higher function of ALF. So, my question should have been _could_ the session messages be used for message stability. And by SRMs nature, the answer is no....but ALF can do it depending on how the application is set up. And then the session messages could be used to notify of stability.... -- Todd From rem-conf-request@es.net Mon Mar 11 10:06:06 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 07:05:38 -0800 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14591(1)>; Mon, 11 Mar 1996 07:05:21 PST Received: by redwing.parc.xerox.com id <177520>; Mon, 11 Mar 1996 07:05:15 -0800 Date: Mon, 11 Mar 1996 07:05:03 PST Sender: Lixia Zhang From: Lixia Zhang To: "Todd L. Montgomery" Cc: rem-conf@es.net Subject: Re: SRM In-Reply-To: Your message of Mon, 11 Mar 1996 05:23:58 -0800 Message-ID: > > > Another question I have.... are the session messages used for message > > > stability? > > > > not sure I understand what you meant by "message stability". > > A message is stable when you know everyone has it and you can get rid of > it. By looking at the session messages, I was thinking that perhaps > the session messages could be used to limit SRMs buffering. Actually, > the thought was only passing because there is now way in SRM to know > who "everyone" is composed of since it is designed into wb. Stability > has to be a higher function of ALF. That's right. And let me add another issue into "message stability" (that is, whether one can get rid of the history), the dynamic changes of the group membership. One can indeed figure out, from the session message exchanges, whether all the *current* members have received data from source X up to sequence number N, but that does not mean that X can delete the history up to N, such as in wb case, because new members may pop up later (which I do very often, e.g. to catch up with Berkeley MM seminar that chooses to start at 12:30 instead of 1:00 :-), and still want to see all the previous pages that have been posted to the group before my join. Again, the best way to handle it is to leave to ALF. Lixia From rem-conf-request@es.net Mon Mar 11 10:42:30 1996 Received: from cerc.wvu.edu (actually cathedral.cerc.wvu.edu) by osi-west.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 07:42:03 -0800 Received: from elk (elk.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA26296; Mon, 11 Mar 96 10:42:00 EST Received: by elk (5.x//ident-1.0) id AA12661; Mon, 11 Mar 1996 10:41:58 -0500 Date: Mon, 11 Mar 1996 10:41:58 -0500 (EST) From: "Todd L. Montgomery" Subject: Re: SRM To: Lixia Zhang Cc: rem-conf@es.net In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Mar 1996, Lixia Zhang wrote: > And let me add another issue into "message stability" (that is, > whether one can get rid of the history), the dynamic changes of the > group membership. One can indeed figure out, from the session message > exchanges, whether all the *current* members have received data from > source X up to sequence number N, but that does not mean that X can > delete the history up to N, such as in wb case, because new members > may pop up later (which I do very often, e.g. to catch up with > Berkeley MM seminar that chooses to start at 12:30 instead of 1:00 :-), > and still want to see all the previous pages that have been posted > to the group before my join. > Again, the best way to handle it is to leave to ALF. For those cases where message stability is important, such as where keeping the whole history is very wasteful - distributed dbs and some groupware applications with rapidly changing variables, then ALF gets you part of the way. The other part has to do with how state is propogated to new members. Actually, if you take a wide view of ALF, then this is also covered.... Sudhir Koka took this approach with a replicated object system based on RMP. So did Isis and Horus with their object replication work.... I guess in a very real sense ALF has been practiced unknowlingly for a while now. This adds yet another angle to my work on API issues for group semantics. :) -- Todd Montgomery From rem-conf-request@es.net Mon Mar 11 15:15:04 1996 Received: from cerc.wvu.edu (actually cathedral.cerc.wvu.edu) by osi-west.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 12:14:35 -0800 Received: from anawalt (anawalt.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA04630; Mon, 11 Mar 96 15:14:25 EST From: alsalqan@cerc.wvu.edu (Yahya Alsalqan) Received: by anawalt (5.x//ident-1.0) id AA02658; Mon, 11 Mar 1996 15:14:22 -0500 Message-Id: <9603112014.AA02658@anawalt> Subject: Enterprise Security To: tmont@es.net (Todd L. Montgomery) Date: Mon, 11 Mar 1996 15:14:22 -0500 (EST) Cc: lixia@parc.xerox.com, rem-conf@es.net In-Reply-To: from "Todd L. Montgomery" at Mar 11, 96 10:41:58 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The Deadline for submission is March 15th. E-mail submission will be accepted in ps format. Call For Papers A WET ICE 96 WORKSHOP International Workshop on Enterprise Security June 19-21 Stanford University, Stanford, California Co-sponsored by the IEEE Computer Society and the Concurrent Engineering Research Center (CERC) at West Virginia University Hosted by the Center for Design Research, Stanford University ============================================================================== Enterprises are increasingly dependent on their information systems to support their business and workflow activities. There is a need for universal electronic connectivity to support interaction and cooperation between multiple organisations. This makes enterprise security and confidentiality more important, but more difficult to achieve, as the multiple organisations may have differences in their security policies and may have to interact via an inscure internet. These inter-organisational enterprise systems may be very large and so tools and techniques are needed to support the specification, analysis and implementation of security. This workshop will focus on the problems and challenges relating to enterprise security in inter-organisational systems. We aim to biring together principal players from both the internetwork and enterprise security community and will provide plenty of time for discussion. Topics to be addressed include: - Specifying and Analysing Enterprise Security Policy - Role-Based Access Control - Security infrastructre for large-scale systems - Supporting enterprise security over the internet - Conflicts and harmonization of inter- and intra-organizational Security - Distributed Database Security - Secure Transactions - Security in Workflow Process - Object Oriented and CORBA Security - Secure Applications and Environments - Integrating Heterogeneous Security Environments - Managing inter-oranisational Enterprise Security - Internet Security protocols - Security Algorithms This workshop will be part of the IEEE Fifth Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET-ICE 96) organized by the Concurrent Engineering Research Center (CERC)/ West Virginia University and will be hosted by the Center for Design Research, Stanford University, California. Important Dates: ================ Papers Due March 15, 1996 Panel Proposals March 15, 1996 Authors notified of acceptance April 19, 1996 Workshop June 19-21, 1996 Camera Ready June 28, 1996 INFORMATION FOR AUTHORS OF PAPERS TO BE INCLUDED IN THE PROCEEDINGS =================================================================== Mail six copies of an original (not submitted or published elsewhere) paper (double-spaced) of 3000-5000 words to the Program Chair. Include the title of the paper, the name and affiliation of each author, a 150-word abstract and no more than 8 keywords. The name, position, address, telephone number, and if possible, fax number and e-mail address of the author responsible for correspondence of the paper must be included. An e-mail submission in postscrip format will be accepted. INFORMATION FOR PANEL ORGANIZERS ================================ Send six copies of panel proposals to the Program Chair. Include the title, a 150-word scope statement, proposed session chair and panelists and their affiliations, the organizer's affiliation, address, telephone and fax number, and e-mail address. INFORMATION FOR AUTHORS OF POSITION PAPERS ========================================== Send six copies of position paper of 2-3 pages to the Program Chair. Include the title of the paper, the name and affiliation of each author, a 150-word abstract and no more than 8 keywords. The name, position, address, telephone number, and if possible, fax number and e-mail address of the author responsible for correspondence of the paper must be included. An accepted position paper will get less presentation time than full paper. Program Committee ================= Program Chair Yahya Al-Salqan Concurrent Engineering Research Center P.O. Box 6506 886 Chestnut Ridge Road West Virginia University Morgantown, WV 26506 USA Ph: (304) 293-7226 Fax: (304) 293-7541 e-mail: alsalqan@cerc.wvu.edu Workshop Program Committee (Partial List): ========================================== Takasi Arano, NTT Corp, Japan Germano Caronni, ETH-Zurich, Switzerland Chikuang Chao, AT&T, USA Taher ElGamal, Netscape Corp., USA Matthias Hirsch, BSI (Federal Department of Security in the Information Technology-Germany Steve Kent, BBN, USA W. Douglas Maughan, Technical Director, National Security Agency (NSA), USA Clifford Neuman, USC/ISI, USA LouAnna Notargiacomo, Oracle Corp., USA Morris Sloman, Department of Computing: Imperial College, UK Badie Taha, Al-Quds University, Jerusalem Ravi Sandhu, Department of Information and Software Engineering, George Mason University, USA Robert Thomys, BSI (Federal Department of Security in the Information Technology-Germany Nick Zhang, CERC, West Virginia University, USA Interrnet Hotline ================= Information on Enterprise Security Workshop may be obtained through the WWW using the URL http://www.cerc.wvu.edu/SECWK/ You don't need to have a paper to attend the workshop. From rem-conf-request@es.net Mon Mar 11 18:23:23 1996 Received: from chook.cs.adelaide.edu.au by osi-west.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 15:22:42 -0800 Received: from matthew@chook.cs.adelaide.edu.au by chook.cs.adelaide.edu.au (8.7.3/AndrewR-MatthewD-950530-CS) id JAA05512 for rem-conf@es.net; Tue, 12 Mar 1996 09:52:24 +1030 (CST) X-Authentic-Sender: matthew@chook.cs.adelaide.edu.au From: Matthew Donaldson Message-Id: <199603112322.JAA05512@chook.cs.adelaide.edu.au> Subject: Connectix Quick Cam To: rem-conf@es.net Date: Tue, 12 Mar 1996 09:52:24 +1030 (CST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi all. We are considering playing with a Connectix Quick Cam, running under Solaris x86. This camera sends its data over a serial line at high speed to the receiving machine. Has anyone had any experience with this camera or know of any drivers for it? Any help much appreciated. Also, does anyone know if there are any multicast tools for Solaris x86? Thanks -Matthew +--------------------------------------------------------------------------+ | Matthew Donaldson Email: matthew@cs.adelaide.edu.au | | Computer Science Department Phone: +61 8 303 5583 _ | | University of Adelaide Fax: +61 8 303 4366 John / \/ | | South Australia 5005 Telex: UNIVAD AA89141 3:16 \_/\ | +--------------------------------------------------------------------------+ From rem-conf-request@es.net Mon Mar 11 19:48:48 1996 Received: from pioneer.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 16:48:20 -0800 Received: by pioneer.arc.nasa.gov (8.7.1/1.35) id QAA14071; Mon, 11 Mar 1996 16:48:24 -0800 (PST) Date: Mon, 11 Mar 1996 16:48:24 -0800 (PST) From: paden@pioneer.arc.nasa.gov (Gary R. Paden) Message-Id: <199603120048.QAA14071@pioneer.arc.nasa.gov> To: rem-conf@es.net Subject: Live From Hubble Broadcast All, We are planing an mbone presentation March 14, 1996 >from 13:00 to 14:00 EST. We will be using vic2.7 and vat for the entire presentation. The broadcast will be approximately one hour in duration. If this presentation conflicts with any previously scheduled broadcasts please contact me by e-mail or phone. Gary Paden NASA Ames/Sterling paden@pioneer.arc.nasa.gov (415)604-0082 From rem-conf-request@es.net Mon Mar 11 22:28:05 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 19:27:16 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id TAA06201; Mon, 11 Mar 1996 19:25:01 -0800 Message-Id: <199603120325.TAA06201@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Matthew Donaldson cc: rem-conf@es.net Subject: Re: Connectix Quick Cam In-reply-to: Your message of "Tue, 12 Mar 1996 09:52:24 +1030." <199603112322.JAA05512@chook.cs.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Mar 1996 19:25:00 -0800 From: "Amancio Hasty Jr." Check around in a FreeBSD or Linux group there are folks using the QuickCam with vic and nv. Currently, there is a library at least for FreeBSD and Linux which talks to the QuickCam via the parallel interface. Amancio >>> Matthew Donaldson said: > Hi all. We are considering playing with a Connectix Quick Cam, running unde r > Solaris x86. This camera sends its data over a serial line at high speed to > the receiving machine. > > Has anyone had any experience with this camera or know of any drivers for it ? > Any help much appreciated. > > Also, does anyone know if there are any multicast tools for Solaris x86? > > Thanks > > -Matthew > > +--------------------------------------------------------------------------+ > | Matthew Donaldson Email: matthew@cs.adelaide.edu.au | > | Computer Science Department Phone: +61 8 303 5583 _ | > | University of Adelaide Fax: +61 8 303 4366 John / \/ | > | South Australia 5005 Telex: UNIVAD AA89141 3:16 \_/\ | > +--------------------------------------------------------------------------+ From rem-conf-request@es.net Tue Mar 12 00:28:17 1996 Received: from bmrc.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 21:27:41 -0800 Received: from inter.net.il (parker.inter.net.il [205.164.141.8]) by bmrc.Berkeley.EDU (8.6.11/8.6.9) with SMTP id VAA04229 for <298@bmrc.berkeley.edu>; Mon, 11 Mar 1996 21:23:44 -0800 Received: from kube99.access.net.il by inter.net.il with SMTP id AA30223 (5.67b/IDA-1.5 for <298@bmrc.berkeley.edu>); Tue, 12 Mar 1996 07:24:52 +0300 Received: by kube99.access.net.il with Microsoft Mail id <01BB0FE4.A2D5C7A0@kube99.access.net.il>; Tue, 12 Mar 1996 07:22:14 +-200 Message-Id: <01BB0FE4.A2D5C7A0@kube99.access.net.il> From: Benny Kedem To: "'298@bmrc.berkeley.edu'" <298@bmrc.Berkeley.EDU>, "'announcements.chi@xerox.com'" , "'arl@arl1.wustl.edu'" , "'aswan@cs.berkeley.edu'" , "'atm@bbn.com'" , "'btonkin@silas.cc.monash.edu.au'" To: "'business-information-all%mailba@ACM.ORG'" , "'ccrc@dworking.wustl.edu'" , "'cip@bbn.com'" , "'cm-collab-learning@mailbase.ac.uk'" , "'cscw-all@mailbase.ac.uk'" , "'cync@world.std.com'" To: "'end2end-interest@isi.edu'" , "'epublish@mailbase.ac.uk'" , "'f-troup@aurora.cis.upenn.edu'" , "'gtroup@dworkin.wustl.edu'" , "'hpdc@npac.syr.edu'" , "'icad-request@santafe.edu'" To: "'ietf@isi.edu'" , "'infobahn@cs.nps.navy.mil'" , "'iplpdn@cnri.reston.va.us'" , "'ir-l@uccvma.bitnet'" , "'is-multimedia@mailbase.ac.uk'" , "'jorg@mamba.cs.virginia.edu'" To: "'klaus@informatik.rwth-aachen.de'" , "'mmis@mailbase.ac.uk'" , "'multicomm@cc.bellcore.com'" , "'multimedia@ed.ac.uk'" , "'rem-conf@es.net'" , "'request@es.net'" To: "'rowe@cs.berkeley.edu'" , "'s-comput@tcsvm.BITNET'" , "'sig11@roses.stanford.edu'" , "'sigmedia@bellcore.com'" , "'sigmetrics_bb_list@tay1.dec.com'" , "'simon@cui.unige.ch'" To: "'sip-request@catarina.usc.edu'" , "'smds@cnri.reston.va.us'" , "'sound@ACM.ORG'" , "'tccc@cs.umass.edu'" , "'tccc@cs.umass.edu'" , "'tcplw@cray.com'" To: "'tf-mm@i4serv.informatik.rwth-aachen.de'" , "'uist.chi@xerox.com'" , "'wittig@vnet.ibm.com'" Subject: A personal Invitation Date: Mon, 11 Mar 1996 18:02:05 +-200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, You are invited to visit my interesting, useful, and provocative web site at the following address: http://www.teletel.co.il/benny Feel free to forward this message to people who may be interested. Waiting for your compliments or curses. Benny Kedem From rem-conf-request@es.net Tue Mar 12 00:32:41 1996 Received: from inter.net.il (actually parker.inter.net.il) by osi-west.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 21:31:27 -0800 Received: from kube99.access.net.il by inter.net.il with SMTP id AA30223 (5.67b/IDA-1.5); Tue, 12 Mar 1996 07:24:52 +0300 Received: by kube99.access.net.il with Microsoft Mail id <01BB0FE4.A2D5C7A0@kube99.access.net.il>; Tue, 12 Mar 1996 07:22:14 +-200 Message-Id: <01BB0FE4.A2D5C7A0@kube99.access.net.il> From: Benny Kedem To: "'298@bmrc.berkeley.edu'" <298@bmrc.berkeley.edu>, "'announcements.chi@xerox.com'" , "'arl@arl1.wustl.edu'" , "'aswan@cs.berkeley.edu'" , "'atm@bbn.com'" , "'btonkin@silas.cc.monash.edu.au'" To: "'business-information-all%mailba@ACM.ORG'" , "'ccrc@dworking.wustl.edu'" , "'cip@bbn.com'" , "'cm-collab-learning@mailbase.ac.uk'" , "'cscw-all@mailbase.ac.uk'" , "'cync@world.std.com'" To: "'end2end-interest@isi.edu'" , "'epublish@mailbase.ac.uk'" , "'f-troup@aurora.cis.upenn.edu'" , "'gtroup@dworkin.wustl.edu'" , "'hpdc@npac.syr.edu'" , "'icad-request@santafe.edu'" To: "'ietf@isi.edu'" , "'infobahn@cs.nps.navy.mil'" , "'iplpdn@cnri.reston.va.us'" , "'ir-l@uccvma.bitnet'" , "'is-multimedia@mailbase.ac.uk'" , "'jorg@mamba.cs.virginia.edu'" To: "'klaus@informatik.rwth-aachen.de'" , "'mmis@mailbase.ac.uk'" , "'multicomm@cc.bellcore.com'" , "'multimedia@ed.ac.uk'" , "'rem-conf@es.net'" , "'request@es.net'" To: "'rowe@cs.berkeley.edu'" , "'s-comput@tcsvm.BITNET'" , "'sig11@roses.stanford.edu'" , "'sigmedia@bellcore.com'" , "'sigmetrics_bb_list@tay1.dec.com'" , "'simon@cui.unige.ch'" To: "'sip-request@catarina.usc.edu'" , "'smds@cnri.reston.va.us'" , "'sound@ACM.ORG'" , "'tccc@cs.umass.edu'" , "'tccc@cs.umass.edu'" , "'tcplw@cray.com'" To: "'tf-mm@i4serv.informatik.rwth-aachen.de'" , "'uist.chi@xerox.com'" , "'wittig@vnet.ibm.com'" Subject: A personal Invitation Date: Mon, 11 Mar 1996 18:02:05 +-200 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, You are invited to visit my interesting, useful, and provocative web site at the following address: http://www.teletel.co.il/benny Feel free to forward this message to people who may be interested. Waiting for your compliments or curses. Benny Kedem From rem-conf-request@es.net Tue Mar 12 01:32:05 1996 Received: from broon.off.connect.com.au by osi-east.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 22:31:09 -0800 Received: (from ggm@localhost) by broon.off.connect.com.au id QAA12800 (8.6.12/IDA-1.6 for rem-conf@es.net); Tue, 12 Mar 1996 16:28:07 +1000 Date: Tue, 12 Mar 1996 16:28:07 +1000 From: George Michaelson Message-ID: <199603120628.QAA12800@broon.off.connect.com.au> To: rem-conf@es.net Subject: a brief monologue on the meaning of "scope" Content-Length: 4151 I've finally decided to try and enable some scope rules into our mrouted setup. I'm finding the idea of scope very confusing. If I can beg your collective forbearance, I would appreciate knowing if I have the following concepts right. For a totally isolated, private mbone network consisting of: Brisbane--64k--Sydney--64k--Melbourne | 64k | Wellington Where each location is "active" ie people can participate, as well as acting as a transition point, the following is observed: (1) To define a subset of the complete space of all nodes, and use scoping rules to prevent traffic leakage to a non-included space, appears to me to be functionally identical to defining a network of point-to-point connected nodes. Scope rules must be defined to prevent leakage to unwanted subnets. This means the rules defining the *maximal* number of scopes are equivalent to combinatorial arithmetic across the set of all nodes. (2) However since in my above instance only one place is a transition node, whilst all nodes require to know all the scopes to use them in specifying a session, only Sydney in the above example requires all the restriction rules to prevent packetflow leaking out to its lan, or being forwarded down the wrong tunnel. In effect, transition nodes need to know what sub-sets of the complete set of all nodes might pass, and include a scope boundary on the LAN and tunnel sets to exclude these passing sets. (3) Noting that it doesn't scale, for the smaller private mbone instances this would appear just at the limit of workable, and would allow me to define scopes which might be: only Brisbane-Melbourne participants only Brisbane-Sydney-Melbourne participants only Brisbane-Sydney-Wellington participants by excluding the scope from the Sydney lan segment to prevent local recipients seeing that dataflow. (3) In the case where we had 2 or more "hub" locations, the issue becomes a bit more complex since there are more transition points which need slightly different versions of the scope rules. If this doesn't make sense, merely defining a boundary scope would at least permit me to ensure no leakage of traffic off the private network, but would not prevent some forms of unneccessary traffic flow. Wellington for instance is likely to remain a 64k link passing via many intermediate IP routers (at least until we get mbone across that path and decide to open our private in-house mbone to the world, and apply encryption and...) whilst the remainder will be re-graded to megabit speeds shortly. That would mean fine tuning the ttl which well defined scope rules might complement nicely. The localization of scope clearly means that session and other tools need to be configured to understand specific scope definitions, if only to be able to present a mapping symbolicname:base/mask/ttl which can then be worked on to derive a unique instance (sdr appears to do this in sdr.tcl) I would expect that by defining symbolic names clearly, you could obviate the need to get into details about what a given scope achieved. The existing scopes of local/region/national/world embody this idea. Otherwise, scopes like sessions need a lot of associated text to define what the behaviour of a given scope would be. I cannot see any global definition of what subspace of 224-land is expected to be scoped, and what should remain globally visible. I cannot see any reason to use less than 8 bits, or more than 16 to define a scope, so intend using 224.2.x.0/17 as a space, based on some cribbed code in sdr. I intend doing the following: enumerate and name the 16 combinations of nodes to derive a list of potential scopes. define (pick at random?) mappings from these named subsets to scoped addresses within 224.2.x.0/17 space. add these scopes to mrouted.conf and test dataflow with mtest and ping. find a way to make sdr and analogous tools understand these scopes and present human-friendly lists of scopes which map naturally onto subsets of the local mbone space. (is this .sdr_conf?) -George From rem-conf-request@es.net Tue Mar 12 02:09:21 1996 Received: from brolga.cc.uq.oz.au by osi-west.es.net with ESnet SMTP (PP); Mon, 11 Mar 1996 23:08:35 -0800 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Tue, 12 Mar 1996 17:08:13 +1000 To: videophone@es.net, rem-conf@es.net Subject: MPEGator Date: Tue, 12 Mar 1996 17:08:09 +1000 From: David Vu Message-ID: <"brolga.cc.uq:170670:960312070818"@cc.uq.oz.au> I just found some info on a real time MPEG1 encoder for under $1,000. Does anyone have any experience with this product? MPEGator The First Affordable real-time MPEG 1 encoder Priced below $1,000! Full ISO-11172 compression/decompression in real time! Full IBP compression in real time! Compresses audio synchronously! H.261 is coming soon (software update)! Ideal for Video Conferencing, Security and Video CD production! Uses 32-bit PCI bus! Native Windows 95 software! Check out http://darvision.kaist.ac.kr/news.html -David- From rem-conf-request@es.net Tue Mar 12 04:00:30 1996 Received: from garfield.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 00:59:52 -0800 Received: from garfield.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by garfield.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id AAA01786 for ; Tue, 12 Mar 1996 00:59:51 -0800 Message-Id: <199603120859.AAA01786@garfield.CS.Berkeley.EDU> From: Andrew Swan To: "'rem-conf@es.net'" Subject: Reminder: Microsoft Internet Developer's Conference In-reply-to: Your message of "Tue, 05 Mar 1996 09:02:42 PST." X-URL: http://www.cs.berkeley.edu/~aswan/ Date: Tue, 12 Mar 1996 00:59:50 -0800 Sender: aswan@plateau.CS.Berkeley.EDU Just a reminder that footage from the Microsoft Internet Developer's Conference will be broadcast on the MBone Tuesday through Thursday. More information on the conference and the schedule is available from http://www.microsoft.com/showcase/intpdc/default.htm Questions can be address either to me or to Lee Fisher (leefi@microsoft.com) -- Andrew Swan aswan@cs.berkeley.edu Plateau Multimedia Research Group http://www.cs.berkeley.edu/~aswan/ From rem-conf-request@es.net Tue Mar 12 04:35:00 1996 Received: from cismsun.univ-lyon1.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 01:34:19 -0800 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id KAA24034; Tue, 12 Mar 1996 10:34:07 +0100 Message-Id: <199603120934.KAA24034@cismsun.univ-lyon1.fr> Subject: Re: Windows95 mbone tools To: hakanl@cdt.luth.se (Hakan Lennestal) Date: Tue, 12 Mar 1996 10:34:07 +0100 (MET) From: Lucia Gradinariu Cc: rem-conf@es.net In-Reply-To: <199603111015.LAA05713@ganymede.cdt.luth.se> from "Hakan Lennestal" at Mar 11, 96 11:15:09 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 681 > > Hi all ! > > Winsd, winvat and winnv does only work with a specific ip protocol stack > (can't remember which). I do however know by personal experience that it > does not work with the MS or the PC-TCP stack. with OnNet from FTP Software (i've tested with Win95 and they really work) -------------------------------------------------------------------------------- Lucia GRADINARIU, Eng. CISM-Univ. Cl. Bernard Lyon1 voice:(33).72.43.13.69 Bat. 101 Bd. du 11 Novembre 1918 fax:(33).72.44.84.10 69622 Villeurbanne FRANCE email:lucia@univ-lyon1.fr http://www.univ-lyon1.fr/CISM/lucia --------------------------------------------------------------------------------- From rem-conf-request@es.net Tue Mar 12 04:48:00 1996 Received: from fenris.hiof.no by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 01:47:17 -0800 Received: from gyda.hiof.no by fenris.hiof.no with SMTP (PP) id <05069-0@fenris.hiof.no>; Tue, 12 Mar 1996 10:47:09 +0100 Date: Tue, 12 Mar 1996 10:47:06 +0100 (MET) From: "Halvor Kise jr." X-Sender: halvork@gyda To: Hakan Lennestal cc: rem-conf@es.net Subject: Re: Windows95 mbone tools In-Reply-To: <199603111015.LAA05713@ganymede.cdt.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 11 Mar 1996, Hakan Lennestal wrote: > Winsd, winvat and winnv does only work with a specific ip protocol stack > (can't remember which). I do however know by personal experience that it > does not work with the MS or the PC-TCP stack. > Also, these implementations is now rather old and came out from a now > terminated (?) project at the university of Singapore. You have to use winsock from Ftp-software. - Halvor. -- *** MEMENTO MORI *** PGP-key by fingering halvork@frodo.hiof.no http://www.hiof.no/~halvork/ From rem-conf-request@es.net Tue Mar 12 08:16:54 1996 Received: from labtam.labtam.OZ.AU by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 05:16:08 -0800 Received: from labtam.labtam.oz.au by labtam.labtam.OZ.AU (8.6.12/8.6.6+1.15) with ESMTP id AAA21293; Wed, 13 Mar 1996 00:16:00 +1100 Message-Id: <199603121316.AAA21293@labtam.labtam.OZ.AU> To: George Michaelson cc: rem-conf@es.net Subject: Re: a brief monologue on the meaning of "scope" In-reply-to: Your message of "Tue, 12 Mar 1996 16:28:07 +1000." <199603120628.QAA12800@broon.off.connect.com.au> Date: Wed, 13 Mar 1996 00:16:00 +1100 From: Mark Treacy Hi George, The slides in, ftp://ftp.ee.lbl.gov/talks/adminscope.ps.Z should go a long way to helping with your query. Cheers, - Mark. From rem-conf-request@es.net Tue Mar 12 09:39:59 1996 Received: from gw1.att.com by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 06:39:28 -0800 Received: from arch4.ho.att.com by ig2.att.att.com id AA16157; Tue, 12 Mar 96 09:40:12 EST Received: from dahlia (dahlia.ho.att.com) by arch4.ho.att.com (4.1/EMS-1.2 GIS) id AA09654; Tue, 12 Mar 96 09:27:52 EST Received: by dahlia (4.1/EMS-1.1 SunOS) id AA21454; Tue, 12 Mar 96 09:30:02 EST Date: Tue, 12 Mar 96 09:30:02 EST From: shur@arch4.ho.att.com Message-Id: <9603121430.AA21454@dahlia> To: hakanl@cdt.luth.se, lucia@univ-lyon1.fr Subject: Re: Windows95 mbone tools Cc: rem-conf@es.net > > > > > Hi all ! > > > > Winsd, winvat and winnv does only work with a specific ip protocol stack > > (can't remember which). I do however know by personal experience that it > > does not work with the MS or the PC-TCP stack. > > with OnNet from FTP Software (i've tested with Win95 and they really work) Can anyone describe the hardware config. they used and how well their setup performed? E.g., Using a pentium xMhz, y Mbytes, z Graphics accelerator, some video capture board, one is able to generate a frames per second, using window size b, etc. thanks, David (d.shur@att.com). From rem-conf-request@es.net Tue Mar 12 10:57:09 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 07:56:22 -0800 Received: from thud.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Mar 1996 15:55:38 +0000 To: Peter Parnes cc: rem-conf@es.net, mates@cdt.luth.se Subject: Re: Draft: RTP extension for Scalable Reliable Multicast, version 1.3 In-reply-to: Your message of "Sun, 10 Mar 1996 20:38:34 +0100." <199603101938.UAA13084@kalkyl.cdt.luth.se> Date: Tue, 12 Mar 1996 15:55:33 +0000 Message-ID: <10070.826646133@cs.ucl.ac.uk> From: Jon Crowcroft >I've added discussions about the timers and host-to-host calculations. I = >now can say that I don't have a working prototype :-) = sure.....but soon we hope:-) >I'd appreciate if someone could tell how to make a nice postscript-versio= >n of a nroff-version of the draft. How does people usually write drafts? = >I had to learn nroff again, it's simple but I don't remember the fancy st= >uff :-) = you need troff/ditroff/psroff - what macros do you use - i can generate a postscripot if you send me nroff source... (itend to write stuff in latex, and then have the problem getting it into ascii text INSTEAD of postscript:-) meanwhile, comments.... >3.3 Initial values of the timer parameters > > The initial values of the timer parameters should be set to C1=3DC2=3D= >2, > D1=3DD2=3Dlog10(G), where G is is the current number of members in the= > > session. > > An adaptive algorithm for changing these parameters is presented in > [SRM-1995]. maybe state that the tradeoff for timers is Timeliess of repair versus number of NACKs and responses >4. Calculating the host-to-host distances (point 7) > In order to be able to calculate the NACK and repair timers we need > to have some knowledge of the host-to-host distance. This distance is > calculated in seconds based on how long it takes for a packet to > travel from host A to host B. > To be able to do this each member of the session sends a time-stamp. > This time-stamp is used in the following way to calculate the host- > to-host distance: > > Assume that host A sends a session packet P1 at time t1 and host B > receives P1 at time t2. At some later time, t3, host B generates a > session packet P2, containing (t1, d), where d =3D t3 - t2 (time t1 > is included in P2 to make the algorithm robust to lost session > packets). Upon receiving P2 at time t4, host A can estimate the > latency from host B to host A as (t4 - t1 - d)/2. Note that while > this estimate does assume that the paths are symmetric, it does not > assume synchronized clocks. it is worth talking about errors in the distance estimation here (again just to allay arguments from some readers) whilst the clock wander may be high, so that the basis for calculating the d i nthe experssion (t4 - t1 - d)/2, may be inaccuate over long values of d, the timers can all be based on running averages and include RTT estimation style safeguards of additional variances.... the path may be assymetric, but we can always again err on the igh side (the equation actually computes the average of the outbounmd and return path delay.....) whilsts TCP uses a simuilar scheme which doesn't care about assymetry on path (because of how it is used), and also updates the estimate just about every packet (well every ack that is not to a lost packet), we are running over a much lower frequency here, so our errors due to path changes (whether route changes, or conditions changing in either or both directions) are higher.... but then we don't care as much... ... > 7*) The time-stamps should be incorporated into RTCP. The NTP- > time-stamp in the RTCP/SR packet can't be used as the RTP > specification has left it optional for clients to use this > field. In order to calculate the host-to-host delay all clients > need to have some notion of wall-clock time or elapsed time. i don't understand this one surely, so long as an SRM/RTP user _+uses the wallcalock to geerate the t1,t4, and the receiver uses the same clock in setting what are state variables, t2/t3 to calculate d, why can't we just stay with the RTCP timestamp sure its optional for clients to use it for their own use, but what use would that be for such a non-rela time application that can tolerate the NACK/Repair delay inherent in using SRM??? (if there is such an application, then ignore my argument - the rest of your design for the heartbeat, timestamp query and response all looks fine then!) >6.4 Time-stamps (point 7) > The time-stamps should be added into the new RTCP-type and divided > into two modes. > The first mode is "time-stamp queries" where a member sends out his > wall-clock time-stamp and every other member of the session is > expected to answer this query using the second mode "time-stamp > replies". > A time-stamp query should be included in the first RTCP-packet that a > new member sends out after joining the session. > Replies to pending queries (if any) should be sent each time we send > a RTCP-packet. Several replies can be contained in the same RTCP- > packet as this would lower the overhead. remind people abut RTPs neat stacking facility here!!! good stuff..... jon From rem-conf-request@es.net Tue Mar 12 11:01:35 1996 Received: from pioneer.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 08:01:06 -0800 Received: by pioneer.arc.nasa.gov (8.7.1/1.35) id IAA20586; Tue, 12 Mar 1996 08:01:16 -0800 (PST) Date: Tue, 12 Mar 1996 08:01:16 -0800 (PST) From: paden@pioneer.arc.nasa.gov (Gary R. Paden) Message-Id: <199603121601.IAA20586@pioneer.arc.nasa.gov> To: rem-conf@es.net Subject: Live From Hubble Broadcast All, We are planing an mbone presentation March 14, 1996 >from 13:00 to 14:00 EST. We will be using vic2.7 and vat for the entire presentation. The broadcast will be approximately one hour in duration. If this presentation conflicts with any previously scheduled broadcasts please contact me by e-mail or phone. Gary Paden NASA Ames/Sterling paden@pioneer.arc.nasa.gov (415)604-0082 From rem-conf-request@es.net Tue Mar 12 14:34:08 1996 Received: from fate.eng.buffalo.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 11:33:35 -0800 Received: from cclaven.eng.buffalo.edu.bell (cclaven.eng.buffalo.edu [128.205.25.7]) by fate.eng.buffalo.edu (SMI-8.6/8.5) with SMTP id OAA19703; Tue, 12 Mar 1996 14:36:39 -0500 Received: by cclaven.eng.buffalo.edu.bell (5.0/SMI-SVR4) id AA01277; Tue, 12 Mar 1996 14:32:56 -0500 Date: Tue, 12 Mar 1996 14:32:51 -0500 (EST) From: Matthew A Earley To: Gene Heyler S1A Cc: rem-conf@es.net Subject: UNSUBSCRIBE In-Reply-To: <9601181229.ZM15456@retro.jhuapl.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII UNSUBSCRIBE From rem-conf-request@es.net Tue Mar 12 17:29:14 1996 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 14:28:36 -0800 Received: from localhost (ggm@localhost) by broon.off.connect.com.au with SMTP id IAA17429 (8.6.12/IDA-1.6); Wed, 13 Mar 1996 08:28:25 +1000 X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs X-Authentication-Warning: broon.off.connect.com.au: Host localhost didn't use HELO protocol To: Mark Treacy cc: rem-conf@es.net Subject: Re: a brief monologue on the meaning of "scope" In-reply-to: Your message of "Wed, 13 Mar 1996 00:16:00 +1100." <199603121316.AAA21293@labtam.labtam.OZ.AU> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17423.826669702.1@connect.com.au> Date: Wed, 13 Mar 1996 08:28:23 +1000 Message-ID: <17425.826669703@connect.com.au> From: George Michaelson Thanks Mark. how are you? I'm freezing to death in air-conditioning that has only one entry point in my room and no exit. If I shut the door I get refridgerated. If i leave it open the world sings to me too loudly. -George From rem-conf-request@es.net Tue Mar 12 17:49:16 1996 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 14:48:46 -0800 Received: (from ggm@localhost) by broon.off.connect.com.au id IAA17638 (8.6.12/IDA-1.6 for rem-conf@es.net); Wed, 13 Mar 1996 08:48:36 +1000 Date: Wed, 13 Mar 1996 08:48:36 +1000 From: George Michaelson Message-ID: <199603122248.IAA17638@broon.off.connect.com.au> To: rem-conf@es.net Subject: sorry for cc posting Content-Length: 37 didn't edit header. many apologies From rem-conf-request@es.net Tue Mar 12 18:09:29 1996 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 15:08:37 -0800 Received: (from ggm@localhost) by broon.off.connect.com.au id JAA17992 (8.6.12/IDA-1.6 for rem-conf@es.net); Wed, 13 Mar 1996 09:08:31 +1000 Date: Wed, 13 Mar 1996 09:08:31 +1000 From: George Michaelson Message-ID: <199603122308.JAA17992@broon.off.connect.com.au> To: rem-conf@es.net Subject: MMCC-like programs on PC's as well as unix. Content-Length: 309 MMCC is too useful to die. Is there anything filling this niche which also works on PC's and Macs? now that speak freely interops with vat4, we need a rendesvous agent that fills a gap between calling by telephone/email/talk to force a vat session manually, and multicasting an announcement in sdr. -George From rem-conf-request@es.net Tue Mar 12 22:18:19 1996 Received: from vlsi.cs.caltech.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 19:17:37 -0800 Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1) id AA06584; Tue, 12 Mar 96 19:17:23 PST Date: Tue, 12 Mar 96 19:17:23 PST From: schooler@cs.caltech.edu (Eve Schooler) Message-Id: <9603130317.AA06584@vlsi.cs.caltech.edu> To: ggm@connect.com.au Subject: Re: MMCC-like programs on PC's as well as unix. Cc: rem-conf@es.net, schooler@cs.caltech.edu Hi George, >MMCC is too useful to die. Is there anything filling this >niche which also works on PC's and Macs? now that speak freely >interops with vat4, we need a rendesvous agent that fills a gap >between calling by telephone/email/talk to force a vat session >manually, and multicasting an announcement in sdr. I apologize for being so silent. Since I left for Caltech I really haven't been very responsive on the MMCC front; it's not you, it's just my silly schedule. However, last summer there was a big push to release the sources. We had a grad student make some important changes to the software (e.g., message parallelism, additional scenario debugging, etc), and more recently, the control protocol has evolved into something simpler and SIP-like (see ftp://ftp.isi.edu/confctrl/docs/*.sip-00.ps.*). I also added a multicast user directory to it, and have wanted to field that as well. Finally, there is a version of MMCC that was ported to Linux that should probably get released along with the rest of this stuff. I was hoping to have consensus on the invitation protocol (ongoing work in the mmusic WG) before making a new release, but perhaps we can use the tool as a vehicle for that. There is still the issue that the latest vat has changed startup arguments, though I consider that a minor change that I could probably make easily (and in the near future). Anyway, thanks for your input, and let me see if I can resurrect the code....Granted it does not work on Macs or under Windows, but perhaps someone else would like to port it to those platforms :-) E. From Rem-Conf-request@es.net Wed Mar 13 00:30:56 1996 Received: from emout10.mail.aol.com (actually emout10.mx.aol.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 12 Mar 1996 21:29:30 -0800 Received: by emout10.mail.aol.com (8.6.12/8.6.12) id AAA07579; Wed, 13 Mar 1996 00:30:35 -0500 Date: Wed, 13 Mar 1996 00:30:35 -0500 From: MahshidR@aol.com Message-ID: <960313003034_445161105@emout10.mail.aol.com> To: videophone@es.net, Rem-Conf@es.net, CU-SEEME-L@cornell.edu cc: GVSI@aol.com Subject: RE: Intel Proshare Hope this will help everyone who has been sending me emails about where I have been able to purchase the Intel Proshare 200 for $850.00. The place that I am buying them from is Global Videoconferencing Solutions. They are located in San Jose California. Their phone number is 1-800-909-4874. I believe the email address is GVSI@aol.com. PLEASE no more emails asking where I have been buying the Proshare at this price. Thanks --MMR-- From rem-conf-request@es.net Wed Mar 13 16:00:34 1996 Received: from VNET.IBM.COM by osi-west.es.net with ESnet SMTP (PP); Wed, 13 Mar 1996 12:59:54 -0800 Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7104; Wed, 13 Mar 96 15:59:36 EST Date: Wed, 13 Mar 96 15:58:17 EST From: "Rick Gillaspy (254-9812)" To: rem-conf@es.net Subject: Subscribe to discussion list -subscribe Rick Gillaspy Please subscribe me to the discussion list about RTP. Thanks, Rick Gillaspy gillaspy@vnet.ibm.com From rem-conf-request@es.net Wed Mar 13 17:45:19 1996 Received: from cs.nps.navy.mil by osi-west.es.net with ESnet SMTP (PP); Wed, 13 Mar 1996 14:44:39 -0800 Received: from libra.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA21344; Wed, 13 Mar 96 14:44:00 PST From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9603132244.AA21344@cs.nps.navy.mil> Subject: BOOK: "MBone: Interactive Multimedia on the Internet" To: mbone@isi.edu (Multicast Backbone mail list), rem-conf@es.net (Remote Conferencing mail list) Date: Wed, 13 Mar 1996 14:43:59 -0800 (PST) Cc: iirg@navy.stl.nps.navy.mil (Information Infrastructure Research Group) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Content-Length: 1047 Unsolicited plug: this is a great book! I recommend it for anyone interested in using the MBone. Besides providing a thorough overview of key topics, Vinay's chapter "System Administrator's Guide to the MBone" covers a lot of advanced concepts and tools clearly in one place. Kumar, Vinay, _MBone: Interactive Multimedia on the Internet_, New Riders Publishing, Indianapolis Indiana, 1996. ISBN 1-56205-397-3. (U.S.) Library of Congress QA76.76.I59K85 Of course Vinay's page is at http://www.best.com/~prince/techinfo/mbone.html New Riders is at http://www.mcp.com/newriders List price on the back $32 USA/$44 Canada/29.49 UK I'm making a public recommendation because the book is a tremendous resource that has not been discussed much on the lists. I found it very useful. all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman From rem-conf-request@es.net Wed Mar 13 17:56:20 1996 Received: from IETF.cnri.reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Wed, 13 Mar 1996 14:55:41 -0800 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa27044; 13 Mar 96 17:53 EST To: IETF-Announce:; cc: rem-conf@es.net From: The IESG Subject: Last Call: RTP Payload Format documents to Proposed Standard Date: Wed, 13 Mar 96 17:53:28 -0500 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9603131753.aa27044@IETF.CNRI.Reston.VA.US> The IESG has received a request from the Audio/Video Transport Working Group to consider the following Internet-Drafts as Proposed Standards: 1. RTP Payload Format for H.261 video streams 2. RTP Payload Format for JPEG-compressed Video 3. RTP Payload Format for MPEG1/MPEG2 Video The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@cnri.reston.va.us or ietf@cnri.reston.va.us mailing lists by March 27, 1996. From rem-conf-request@es.net Wed Mar 13 19:21:19 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Wed, 13 Mar 1996 16:20:20 -0800 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.4/8.7.3) with SMTP id QAA14958 for ; Wed, 13 Mar 1996 16:20:17 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.6.12/8.6.12) id QAA15616; Wed, 13 Mar 1996 16:20:16 -0800 Original-Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Wed, 13 Mar 96 16:20:15 PST PP-warning: Illegal Received field on preceding line Date: Wed, 13 Mar 96 16:18:00 PST From: Gunner Danneels Message-ID: To: rem-conf@es.net, Mojtaba_Mirashrafi@ccm.jf.intel.com Subject: Re[2]: Problem of RTP and dynamic port allocation Text item: The "common port pair" was the only place that we found the restriction. Can we assume that this restriction will be eliminated? Gunner (et. al.) ______________________________ Reply Separator _________________________________ Subject: Re: Problem of RTP and dynamic port allocation Author: rem-conf-request@es.net at SMTPGATE Date: 3/8/96 7:20 PM > In implementing a point-to-point RTP application, we have discovered > the following problem in how RTP restricts the usage of ports. We > make the recommendation that RTP not require that the sender and > receiver be communicating on the same ports when using unicast. You are right. We have made the same observation. In the RTP spec, I think the only place where this restriction is mentioned is the phrase "common port pair" at the end of the definition of the term "RTP session". Have you found others? -- Steve Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Content-Type: TEXT/PLAIN; charset=US-ASCII Mime-Version: 1.0 Message-Id: In-Reply-To: Subject: Re: Problem of RTP and dynamic port allocation Cc: rem-conf@es.net To: Mojtaba Mirashrafi From: Stephen Casner Date: Fri, 8 Mar 1996 19:20:25 -0800 (PST) Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA07235; Fri, 8 Mar 1996 19:20:25 -0800 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 8 Mar 1996 19:27:50 -0800 Received: from osi-west.es.net (osi-west.es.net [128.55.32.32]) by ormail.intel. com (8.7.4/8.7.3) with SMTP id TAA04683; Fri, 8 Mar 1996 19:31:02 -0800 (PST) Received: from ormail.intel.com by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0tvFNw-000RTQC; Fri, 8 Mar 96 19:32 PST Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by relay.jf. intel.com (8.6.12/8.6.12) with SMTP id TAA06231 for ; Fri, 8 Mar 1996 19:31:18 -0800 Return-Path: rem-conf-request@es.net From rem-conf-request@es.net Thu Mar 14 10:28:55 1996 Received: from elaine.crcg.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 14 Mar 1996 07:28:11 -0800 Received: from condor.crcg.edu by elaine.crcg.edu (4.1/SMI-4.1) id AA14451; Thu, 14 Mar 96 09:47:00 EST Received: by condor.crcg.edu (940816.SGI.8.6.9/SMI-4.0) id JAA15226; Thu, 14 Mar 1996 09:34:21 -0500 Date: Thu, 14 Mar 1996 09:34:20 +30000 From: Mike Macedonia X-Sender: mmacedon@condor To: Don Brutzman Cc: Multicast Backbone mail list , Remote Conferencing mail list , Information Infrastructure Research Group Subject: Re: BOOK: "MBone: Interactive Multimedia on the Internet" In-Reply-To: <9603132244.AA21344@cs.nps.navy.mil> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I agree with Don. Vinay did a fine job. I bought two copies for the office. Got them at Computer Literacy. - Mike ----------------------------------------------------------------- | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | | Vice President | EMAIL: mmacedon@crcg.edu | | Fraunhofer CRCG | | | 167 Angell Street | PH : (+1) 401 453-6363 | | Providence, RI 02906 | FAX: (+1) 401 453-0444 | ----------------------------------------------------------------- From rem-conf-request@es.net Fri Mar 15 00:34:20 1996 Received: from gateway-gw.pictel.com by osi-east.es.net with ESnet SMTP (PP); Thu, 14 Mar 1996 21:33:46 -0800 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA24245; Fri, 15 Mar 96 00:33:44 EST Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA01765; Fri, 15 Mar 96 00:30:51 EST Received: by smtpnotes.pictel.com (4.1/SMI-4.1) id AA15863; Fri, 15 Mar 96 00:30:49 EST Message-Id: <9603150530.AA15863@smtpnotes.pictel.com> Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id A20448B24C9F8E0DCA2562EE001406B5; Fri, 15 Mar 96 05:30:47 To: imtc Cc: h32z2-list , rem-conf , Ami Amir , Gary Thom , Dale Skran , Sakae Okubo , Neil Starkey From: Rich Baker/PicTel Date: 15 Mar 96 14:24:56 EDT Subject: Tel Aviv venue for IMTC H.323 meeting, 15-18 Apr 96 Mime-Version: 1.0 Content-Type: Text/Plain Hi folks: Last month, I announced that the IMTC CNC AG will hold a meeting 15-18 Apr 96 to review in detail the H.323 documents for editorial completeness and technical accuracy. RADVision has graciously offered to host the meeting in Tel Aviv (The Sheraton Hotel, Hayarkon Street). During the past week, I have received a couple of e-mails asking me to confirm the venue, in light of recent tragic events. One participant likely will choose not to attend. My personal view is that many of today's urban cities are much less safe than Tel Aviv. And I am concerned about changing an international gathering in reaction to terrist activities. My preference is to move forward as planned, but this is our collective meeting. Your comments / reactions? We need to close on this quickly -- I suspect many have already purchased non-refundable tickets. Unless more folks voice concern, I wish to move forward as planned. On another note, I'd like to remind all about the ground rules, re-printed below, among which is the requirement that "all written contributions must be posted on the H.323 reflector (h32z2-list @ mtgbcs.mt.att.com) in final form, with a document number assigned by me at least 7 days before the start of our meeting." There are 23 days left. Many thanks, and shalom! -rich baker Chair, IMTC CNC AG bake@pictel.com +1.508.623.4459 ===== To: imtc @ world.std.com @ smtp cc: h32z2-list @ mtgbcs.mt.att.com @ smtp, rem-conf @ es.net @ smtp, gthom @ interramp.com (Gary Thom) @ smtp, dls @ mtgbcs.att.com (Dale Skran) @ smtp, okubo @ gctech.co.jp @ ig1.att.att.com (Sakae Okubo) @ smtp, nstarkey @ databeam.com (Neil Starkey) @ smtp From: Rich Baker/PicTel Date: 02/12/96 12:09:40 PM EST Subject: H.323 IMTC Meeting, Tel Aviv, 15-18 Apr 96 To: IMTC Corporate Network Conferencing AG members All participants at Ipswich AVC meeting From: Rich Baker, Chair IMTC CNC AG) Dear IMTC CNC AG members and H.323 experts: I am writing to invite you to a special meeting of the IMTC Corporate Network Conferencing Activity Group to be held 15-18 April 95 in Tel Aviv, Israel, and graciously hosted by RADVision Ltd. As you may know, the final White contribution versions of draft Rec. H.323 and H.225.0 have been submitted for the May 1996 meeting of ITU-T Study Group 15, with the intention of being approved ("Decision") at that time. The H.323 expert's group under Rapporteur Sakae Okubo, H.323 editor Gary Thom and H.225.0 editor Dale Skran has done an excellent job developing these documents in record time, which are key to advancing the entire conferencing industry. I understand that all the remaining open issues on these documents were resolved at the Ipswich AVC meeting during the week of January 15. Closing these issues required the editors to complete a great deal of editorial work during the meeting and in the single week following in order to meet the SG15 White contribution deadline. But experience tells us that, despite the best efforts of the editors and experts, it is unrealistic to expect that these numerous editorial changes could be incorporated flawlessly in the few days available. So in the interest of delivering a strong, stable, and technically correct standard which will enable implementors to build compatible terminals and hosts, a number of the experts involved have suggested the need for a collective review of the final White documents prior to the SG15 meeting, with ample time for focused work to ensure that these documents fully reflect the agreements of Ipswich in a clear, unambiguous, and technically correct way. Hence, this meeting in Tel Aviv. Please note that the meeting is not sponsored by the ITU; it is a meeting of IMTC members and guests concerned with the editorial correctness of H.323 and H.225.0. As such, it would be inappropriate in Tel Aviv to change decisions made by Rapporteur Okubo's Experts Group. However, it is entirely appropriate for representatives within the IMTC to identify any errors or ambiguity in the White documents and to suggest editorial improvements. The IMTC, as a California corporation, can then propose contributions to SG15 via the normal United States approval process through US Study Group C. (The deadline for SGC submissions prior to SG15's meeting is 24 Apr 96.) The ITU-T process is such that proposals for substantive changes at this stage are very unlikely to be accepted and could cause the documents to be considered not ready for approval. Therefore, to ensure the maximum chance of SG15 approval in May, while allowing us to focus productively on improving the existing White documents, I am establishing the following rules for our meeting: GROUND RULES * We will carefully review the H.323 and H.225.0 White documents for TECHNICAL CORRECTNESS, TECHNICAL CLARITY, and MINOR EDITORIAL CHANGES. * NO proposals for changes to decisions already reflected in the White Documents will be considered, unless it can be shown that an existing method specified in the text is technically unworkable, violates the Ipswitch agreements, or is technically inconsistent with the rest of the document. * All written contributions to the meeting must be in the form of proposed alternate text to the White documents, listed by section number in H.323 or H.225.0, or will not be considered. * All written contributions must be posted on the H.323 reflector (h32z2-list @ mtgbcs.mt.att.com) in final form, with a document number assigned by me at least 7 days before the start of our meeting. * Authors must bring 40 copies of each contribution to the meeting, marked with the assigned document number. (Let's not waste our time standing over a photocopier!) Contributions which do not meet these requirements will not be considered at the meeting. OUTPUT DOCUMENTS Our output will be a list of proposed changes to the White documents H.323 and H.225.0. We must work to keep this list as small as possible, while correcting all critical problems with the documents. Two change lists (one each for H.323 and H.225.0) will then be proposed to US SG C as U.S. contributions for the May SG15 meeting. MEETING PROCESS Our meeting will do a careful section-by-section review of the White Paper documents, checking for MEANING, CLARITY, SELF CONSISTENCY, TECHNICAL CORRECTNESS and matching previously agreed upon INTENT. Our objective is to ensure the text accurately reflects agreements already made by Rapporteur Okubo's experts group, is interpreted by us all in the same way, and will work (no holes). I look forward to seeing you in Tel Aviv for this final critical review of these documents. Cheers! Rich Baker, Chair IMTC CNC AG bake@pictel.com +1.508.623.4459 From rem-conf-request@es.net Fri Mar 15 02:19:02 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 14 Mar 1996 23:18:24 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA14060; Thu, 14 Mar 1996 23:11:09 -0800 Date: Thu, 14 Mar 1996 23:11:09 -0800 (PST) From: Stephen Casner To: Gunner Danneels Cc: rem-conf@es.net, Mojtaba_Mirashrafi@ccm.jf.intel.com Subject: Re: Re[2]: Problem of RTP and dynamic port allocation In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Gunner (et. al.) > The "common port pair" was the only place that we found the restriction. > Can we assume that this restriction will be eliminated? That would be my vote. I'd like to hear from other RTP implementors and interested parties if there is some problem that would result from allowing separate destination port numbers on the two ends of a unicast RTP session. I have not thought of any. Having a common port provides an association between the two directions, but it is only a weak association and probably not functional. My recommendation is to change this definition when the RFC is advanced to Draft Standard. I have not yet tried to figure out what the replacement wording should be. -- Steve From rem-conf-request@es.net Fri Mar 15 11:27:18 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Fri, 15 Mar 1996 08:26:47 -0800 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <15701(13)>; Fri, 15 Mar 1996 08:26:21 PST Received: from localhost by ecco.parc.xerox.com with SMTP id <16136>; Fri, 15 Mar 1996 08:26:10 -0800 To: Stephen Casner cc: rem-conf@es.net Subject: Re: Re[2]: Problem of RTP and dynamic port allocation In-reply-to: Your message of "Thu, 14 Mar 96 23:11:09 PST." Date: Fri, 15 Mar 1996 08:26:03 PST Sender: Ron Frederick From: Ron Frederick Message-Id: <96Mar15.082610pst.16136@ecco.parc.xerox.com> In message y ou write: > That would be my vote. I'd like to hear from other RTP implementors > and interested parties if there is some problem that would result from > allowing separate destination port numbers on the two ends of a > unicast RTP session. I have not thought of any. Having a common port > provides an association between the two directions, but it is only a > weak association and probably not functional. > This seems like a reasonable change, but I believe we should still keep the semantics of the "port pair" intact, with the same even/odd rules for where RTP & RTCP traffic goes. We would simply be allowing a different pair to be chosen at each end. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Fri Mar 15 11:44:34 1996 Received: from europe.std.com by osi-east.es.net with ESnet SMTP (PP); Fri, 15 Mar 1996 08:44:04 -0800 Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id LAA07342; Fri, 15 Mar 1996 11:43:55 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA25983; Fri, 15 Mar 1996 11:38:22 -0500 Date: Fri, 15 Mar 1996 11:38:21 -0500 (EST) From: Robert E Lamm Subject: ACM Multimedia '96 To: klara@cs.uiuc.edu, rem-conf@es.net, confctrl@ISI.EDU, f-troup@aurora.cis.upenn.edu, klas@darmstadt.gmd.de, dbworld@cs.wisc.edu, hofmann@sap-ag.de Cc: tdcl@bu.edu In-Reply-To: <199603150102.UAA26053@catwoman.bu.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Can you publicize this within your group and anywhere else you think this might be appropriate? Thanks! -Bob Lamm MM '96 Publicity ___________________________________________ ACM MULTIMEDIA'96 November 18 - 22, 1996 Hynes Convention Center Boston, MA, USA PRELIMINARY CALL FOR PARTICIPATION THE FOURTH ACM INTERNATIONAL MULTIMEDIA CONFERENCE AND EXHIBITION Sponsored by the ACM SIG Multimedia, SIGCOMM, SIGLINK, SIGMIS and SIGGRAPH, in cooperation with SIGBIT, SIGIR, SIGCHI, and SIGOIS (tentative lists) Multimedia technology can substantially improve the communication between information providers and consumers. It contributes to the general accessibility of information, through new interactive media as well as through new forms of production, delivery and perception of existing media. ACM Multimedia'96 will provide an international forum for papers, panels, videos, demonstrations, courses, workshops, and exhibits focusing on all aspects of this multi-disciplinary field: from underlying technologies to applications and issues, and from theory to practice. We invite your participation. Topics include, but are not limited to: applications in art, education, entertainment, government, medicine, etc.; collaboration environments; databases; digital libraries; distributed systems; documents and authoring; hardware and architectures; image, video and audio compression techniques; information retrieval; interactive television; media integration and synchronization; networking and communication; operating system extensions; programming paradigms and environments; standards and legal issues; storage and I/O architectures; tools; user interfaces; and virtual reality. ACM Multimedia'96 will be co-located with SPIE's Symposium on Voice, Video and Data Communications, and Broadband Communications Expo. It will overlap with CSCW, to be held in nearby Cambridge. Papers: ------- Technical papers on completed or in-progress research, innovative applications, or experience with multimedia systems are solicited. Submissions must use a minimum of 10-point typeface, and be up to 12 pages (preferably double sided), including figures, tables, and references. Where applicable, prototype demonstrations or videotape presentations are encouraged to supplement the papers. Papers must be accompanied by an electronic cover sheet (see submission instructions below). Submit complete papers to: Wendy Hall, Program co-Chair. Outstanding papers on different areas of multimedia will be given awards. Papers with a student as the primary author will enter a student paper award competition. A cover letter must identify the paper as a candidate for the student paper competition. Selected papers will be forwarded to ACM/Springer-Verlag Multimedia Systems, Communications of the ACM, IEEE/ACM Transactions on Networking, or ACM Transactions on Information Systems. Multimedia and Art: ------------------- Submissions by artists presenting innovative work in the field are encouraged. A specific selection process and a special Multimedia and Art session will take place. Submissions by artists should include a paper presentation, a single VHS NTSC video and demonstration requirements when applicable, and a biography. Submit to: Art chair. Panels: ------- Panels are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Proposals should be limited to 2 pages, plus a biography of at most one paragraph for each participant. Submit panel proposals to: Bob Allen, Panels Chair. Demonstrations: --------------- We solicit demonstrations of working systems in technical and artistic categories. Submissions (at most 2 pages) should include a description of the exhibit, demo requirements, a biography, and a single VHS NTSC video. Submit demonstrations to: Arding Hsu, Demonstrations Chair. Courses: -------- There will be a series of 1/2-day tutorial courses, focused on issues relevant to researchers and/or practitioners of multimedia technology. Proposals (at most 5 pages) should include a description of the subject matter and brief biographical sketches of the instructors. Evaluation of proposals will be based on expertise and experience of instructors, relevance of subject matter, and the use of multimedia technology in the presentation. Submit tutorial proposals to: Rajiv Mehrotra, Tutorials Chair. Workshops: ---------- Workshops preceding the conference will allow participants to exchange ideas on a topic. Workshop results and issues will be integrated into the main body of the conference. Submit workshop proposals to: Wayne Wolf, Workshops Chair. Exhibits: --------- Exhibits for ACM Multimedia'96 will be combined with those for SPIE's Symposium on Voice, Video, and Data Communications, offering vendors and publishers a unique opportunity to exhibit and demonstrate multimedia products. For more information, contact exhibits@spie.org IMPORTANT SUBMISSION INFORMATION Authors should consult the World Wide Web at http://www.acm.org/sigmm/MM96/ for more detailed submission guidelines and up-to-date information about ACM Multimedia'96. Authors of accepted submissions will be required to submit both a camera-ready copy of the manuscript for the printed proceedings and an electronic copy for the CD ROM proceedings. Authors must assign copyright to ACM as a condition of publishing their work in the proceedings. An author who embeds an object, such as an art image, copyrighted by a third party is expected to obtain that party's permission to include the object with the understanding that the entire work may be distributed as a unity to ACM members and others. IMPORTANT DATES All Submissions (6 copies for papers) due: April 24, 1996 Notification of acceptance: July 15, 1996 Final submissions due: August 26, 1996 CONFERENCE COMMITTEE General Chairs: Philippe Aigrain, IRIT, Univ. P. Sabatier, Toulouse, France and V. Michael Bove, MIT Media Laboratory Proceedings: Lena Davis, MIT Media Laboratory Electronic Information: Stephan Fischer, University of Mannheim, Germany and H. Zhang, CMU Publicity: Bob Lamm, Cync Corp. Treasurer: John Buford, University of Massachusetts Eurographics Liaison: Jose Encarnacao, Fraunhofer-IGD, Darmstadt, Germany Asian/Pacific Liaison: Yoshinobu Tonomura, NTT Human Interface Laboratory, Japan Steering Committee Chairs: Steve Bulick, US West and Allan Kuchinsky, Hewlett Packard Labs. PROGRAM CHAIRS: Wendy Hall Dept. of Elec. and Computer Engr. University of Southampton, Southampton SO17 1BJ United Kingdom Phone: +44-1703-592388 Fax: +44-1703-592865 W.Hall@ecs.soton.ac.uk T.D.C. Little ECS Dept. Boston University 44 Cummington St. Boston, MA 02215, USA Phone: +1-617-353-9877 Fax: +1-617-353-6440 tdcl@bu.edu Program Committee Members (to date): John Buford, University of Massachusetts at Lowell Shih-Fu Chang, Columbia University Wolfgang Effelsberg, University of Mannheim Carole Goble, Manchester University Jorge Haake, GMD-IPSI Wolfgang Klas, GMD-IPSI Wendy Mackay, University of Paris Klara Nahrstedt, University of Illinois, Urbana-Champ. Brian Smith, Cornell Univiversity Dan Swinehart, Xerox Palo Alto Research Center Yuzuru Tanaka, Hokkaido University William Tetzlaff, IBM T.J. Watson Research Center Hirotada Ueda, Hitachi Denshi, Ltd. Harrick Vin, University of Texas at Austin HongJiang Zhang, HP Labs Hui Zhang, Carnegie Mellon University PANELS CHAIR: Bob Allen Bellcore, 1A352R 445 South Street Morristown, NJ 07960 Phone: +1-201-829-4315 Fax: +1-201-829-5981 rba@bellcore.com DEMONSTRATIONS CHAIR: Dr. Arding Hsu Head, Multimedia/Video Dept. Siemens Corp. Research 755 College Road East Princeton, NJ 08540 Phone: +1-609-734-6548 Fax: +1-609-734-6565 ahsu@scr.siemens.com TUTORIALS CHAIR: Rajiv Mehrotra Dept of Math. and Comp. Sci. Univ. of Missouri - St. Louis 8001 Natural Bridge Road St. Louis, MO 63121-4499 Phone: +1-314-516-6342 Fax: +1-314-516-5400 rajiv@mayura.cs.umsl.edu WORKSHOPS CHAIR: Wayne Wolf Dept. of Electrical Engineering Princeton University Princeton, NJ 08544-5263 Phone: +1-609-258-1424 Fax: +1-609-258-3745 wolf@ee.princeton.edu ART CHAIR: Watch the Web pages for further information coming soon. GENERAL INFORMATION: http://www.acm.org/sigmm/MM96/ or http://www.uni-mannheim.de/acm96/ From rem-conf-request@es.net Fri Mar 15 11:55:33 1996 Received: from pioneer.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Fri, 15 Mar 1996 08:54:54 -0800 Received: by pioneer.arc.nasa.gov (8.7.1/1.35) id IAA12153; Fri, 15 Mar 1996 08:55:03 -0800 (PST) Date: Fri, 15 Mar 1996 08:55:03 -0800 (PST) From: paden@pioneer.arc.nasa.gov (Gary R. Paden) Message-Id: <199603151655.IAA12153@pioneer.arc.nasa.gov> To: rem-conf@es.net Subject: NASA Shuttle STS-76 Broadcast We are planing an mbone broadcast of the NASA Shuttle Mission STS-76. The broadcast is scheduled for 3/21 to 3/30. We will be using vic 2.7a and vat for the entire broadcast. In addition to the Shuttle Mission coverage, prelaunch video will be broadcasted from NASA KSC. For broadcast times and prelaunch coverage times please see the NASA Shuttle Mission STS-76 posting in the sessions direstory (sd). If this broadcast conflicts with any previously scheduled broadcasts please e-mail or call. Thank you, Gary Paden NASA Ames/Sterling paden@pioneer.arc.nasa.gov (415)604-0082 From rem-conf-request@es.net Fri Mar 15 12:46:36 1996 Received: from cerc.wvu.edu (actually cathedral.cerc.wvu.edu) by osi-west.es.net with ESnet SMTP (PP); Fri, 15 Mar 1996 09:45:50 -0800 Received: from anawalt (anawalt.cerc.wvu.edu) by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA21501; Fri, 15 Mar 96 12:40:05 EST From: alsalqan@cerc.wvu.edu (Yahya Alsalqan) Received: by anawalt (5.x//ident-1.0) id AA04960; Fri, 15 Mar 1996 12:40:02 -0500 Message-Id: <9603151740.AA04960@anawalt> Subject: Enterprise Security (Extended Deadline) To: cync@world.std.com (Robert E Lamm) Date: Fri, 15 Mar 1996 12:40:01 -0500 (EST) Cc: klara@cs.uiuc.edu, rem-conf@es.net, confctrl@isi.edu, f-troup@aurora.cis.upenn.edu, klas@darmstadt.gmd.de, dbworld@cs.wisc.edu, hofmann@sap-ag.de, tdcl@bu.edu In-Reply-To: from "Robert E Lamm" at Mar 15, 96 11:38:21 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The new Deadline is March 25th Call For Papers -Extended Deadline A WET ICE 96 WORKSHOP International Workshop on Enterprise Security June 19-21 Stanford University, Stanford, California Co-sponsored by the IEEE Computer Society and the Concurrent Engineering Research Center (CERC) at West Virginia University Hosted by the Center for Design Research, Stanford University ============================================================================== Enterprises are increasingly dependent on their information systems to support their business and workflow activities. There is a need for universal electronic connectivity to support interaction and cooperation between multiple organisations. This makes enterprise security and confidentiality more important, but more difficult to achieve, as the multiple organisations may have differences in their security policies and may have to interact via an inscure internet. These inter-organisational enterprise systems may be very large and so tools and techniques are needed to support the specification, analysis and implementation of security. This workshop will focus on the problems and challenges relating to enterprise security in inter-organisational systems. We aim to biring together principal players from both the internetwork and enterprise security community and will provide plenty of time for discussion. Topics to be addressed include: - Specifying and Analysing Enterprise Security Policy - Role-Based Access Control - Security infrastructre for large-scale systems - Supporting enterprise security over the internet - Conflicts and harmonization of inter- and intra-organizational Security - Distributed Database Security - Secure Transactions - Security in Workflow Process - Object Oriented and CORBA Security - Secure Applications and Environments - Integrating Heterogeneous Security Environments - Managing inter-oranisational Enterprise Security - Internet Security protocols - Security Algorithms This workshop will be part of the IEEE Fifth Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WET-ICE 96) organized by the Concurrent Engineering Research Center (CERC)/ West Virginia University and will be hosted by the Center for Design Research, Stanford University, California. Important Dates: ================ Papers Due March 25, 1996 Panel Proposals March 15, 1996 Authors notified of acceptance April 19, 1996 Workshop June 19-21, 1996 Camera Ready June 28, 1996 INFORMATION FOR AUTHORS OF PAPERS TO BE INCLUDED IN THE PROCEEDINGS =================================================================== Mail six copies of an original (not submitted or published elsewhere) paper (double-spaced) of 3000-5000 words to the Program Chair. Include the title of the paper, the name and affiliation of each author, a 150-word abstract and no more than 8 keywords. The name, position, address, telephone number, and if possible, fax number and e-mail address of the author responsible for correspondence of the paper must be included. An e-mail submission in postscrip format will be accepted. INFORMATION FOR PANEL ORGANIZERS ================================ Send six copies of panel proposals to the Program Chair. Include the title, a 150-word scope statement, proposed session chair and panelists and their affiliations, the organizer's affiliation, address, telephone and fax number, and e-mail address. INFORMATION FOR AUTHORS OF POSITION PAPERS ========================================== Send six copies of position paper of 2-3 pages to the Program Chair. Include the title of the paper, the name and affiliation of each author, a 150-word abstract and no more than 8 keywords. The name, position, address, telephone number, and if possible, fax number and e-mail address of the author responsible for correspondence of the paper must be included. An accepted position paper will get less presentation time than full paper. Program Committee ================= Program Chair Yahya Al-Salqan Concurrent Engineering Research Center P.O. Box 6506 886 Chestnut Ridge Road West Virginia University Morgantown, WV 26506 USA Ph: (304) 293-7226 Fax: (304) 293-7541 e-mail: alsalqan@cerc.wvu.edu Workshop Program Committee (Partial List): ========================================== Takasi Arano, NTT Corp, Japan Germano Caronni, ETH-Zurich, Switzerland Chikuang Chao, AT&T, USA Taher ElGamal, Netscape Corp., USA Matthias Hirsch, BSI (Federal Department of Security in the Information Technology-Germany Steve Kent, BBN, USA W. Douglas Maughan, Technical Director, National Security Agency (NSA), USA Clifford Neuman, USC/ISI, USA LouAnna Notargiacomo, Oracle Corp., USA Morris Sloman, Department of Computing: Imperial College, UK Badie Taha, Al-Quds University, Jerusalem Ravi Sandhu, Department of Information and Software Engineering, George Mason University, USA Robert Thomys, BSI (Federal Department of Security in the Information Technology-Germany Nick Zhang, CERC, West Virginia University, USA Interrnet Hotline ================= Information on Enterprise Security Workshop may be obtained through the WWW using the URL http://www.cerc.wvu.edu/SECWK/ You don't need to have a paper to attend the workshop. From rem-conf-request@es.net Fri Mar 15 13:32:04 1996 Received: from jekyll.piermont.com by osi-west.es.net with ESnet SMTP (PP); Fri, 15 Mar 1996 10:31:11 -0800 Received: (from perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) id NAA11891; Fri, 15 Mar 1996 13:31:08 -0500 (EST) Date: Fri, 15 Mar 1996 13:31:08 -0500 (EST) Message-Id: <199603151831.NAA11891@jekyll.piermont.com> From: "Perry E. Metzger" To: rem-conf@es.net Subject: full time multicast? Reply-to: perry@piermont.com X-Reposting-Policy: please ask before redistributing I've been working with a public radio station in the New York metropolitan area that has recently become interested in disseminating its signal, full time, over the mbone. It is my understanding that once multicast routing is fully in place fairly soon, this should only impact those links that have listeners downstream, which is likely much friendlier than, say, having hundreds of realaudio pipes in use. My questions to the rem-conf mailing list are... 1) When is "proper routing" going to be in place over the mbone? 2) Does anyone see why this should not be done given "proper routing" in place on the mbone? I mean, it is part of what the whole thing was designed for... Perry From rem-conf-request@es.net Fri Mar 15 14:15:29 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Fri, 15 Mar 1996 11:14:32 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id LAA01932; Fri, 15 Mar 1996 11:13:35 -0800 Message-Id: <199603151913.LAA01932@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: paden@pioneer.arc.nasa.gov (Gary R. Paden) cc: rem-conf@es.net Subject: Re: NASA Shuttle STS-76 Broadcast In-reply-to: Your message of "Fri, 15 Mar 1996 08:55:03 PST." <199603151655.IAA12153@pioneer.arc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Mar 1996 11:13:34 -0800 From: "Amancio Hasty Jr." >>> Gary R. Paden said: Hi , How much bandwith is your broadcast going to take ? For instance, is it possible to broadcast the audio channel using gsm instead of PCM which takes about 70kb/sec? It would be nice if the video stream is kept around 100Kb/sec so that those of us who are behind a 128kb ISDN line can enjoy the video. Tnks, Amancio From rem-conf-request@es.net Fri Mar 15 16:03:34 1996 Received: from trystero.radio.com by osi-west.es.net with ESnet SMTP (PP); Fri, 15 Mar 1996 13:03:02 -0800 Received: (carl@localhost) by trystero.radio.com (8.7.5/940816.06ccg) id PAA06683; Fri, 15 Mar 1996 15:46:06 -0500 (EST) From: "Carl Malamud [IMS]" Message-Id: <199603152046.PAA06683@trystero.radio.com> Subject: Re: full time multicast? To: perry@piermont.com Date: Fri, 15 Mar 1996 15:46:06 -0500 (EST) Cc: rem-conf@es.net In-Reply-To: <199603151831.NAA11891@jekyll.piermont.com> from "Perry E. Metzger" at Mar 15, 96 01:31:08 pm Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi - The only caution you should have is to look at the license agreement that the public radio station has with the Public Radio Satellite System and with either PRI or NPR. You'll find that the rights for some things (e.g., All Things Considered and the "embedded" material such as AP Wire) are somewhat restrictive. IMS was a member of the Public Radio Satellite System, which gave us rights to independent productions, but the NPR and PRI (American Public Radio) agreements are more restrictive. Carl Malamud According to Perry E. Metzger: > > > I've been working with a public radio station in the New York > metropolitan area that has recently become interested in disseminating > its signal, full time, over the mbone. It is my understanding that > once multicast routing is fully in place fairly soon, this should only > impact those links that have listeners downstream, which is likely > much friendlier than, say, having hundreds of realaudio pipes in use. > > My questions to the rem-conf mailing list are... > > 1) When is "proper routing" going to be in place over the mbone? > 2) Does anyone see why this should not be done given "proper routing" > in place on the mbone? I mean, it is part of what the whole thing > was designed for... > > Perry > From rem-conf-request@es.net Fri Mar 15 17:08:45 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 15 Mar 1996 14:07:45 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA14844; Fri, 15 Mar 1996 14:07:41 -0800 Date: Fri, 15 Mar 1996 14:07:41 -0800 (PST) From: Stephen Casner To: Ron Frederick Cc: rem-conf@es.net Subject: Re: Re[2]: Problem of RTP and dynamic port allocation In-Reply-To: <96Mar15.082610pst.16136@ecco.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ron, > This seems like a reasonable change, but I believe we should still keep the > semantics of the "port pair" intact, with the same even/odd rules for where > RTP & RTCP traffic goes. We would simply be allowing a different pair to be > chosen at each end. I agree completely. Sorry for not making that clear in my message. -- Steve From rem-conf-request@es.net Sat Mar 16 07:33:07 1996 Received: from radvision.rad.co.il by osi-west.es.net with ESnet SMTP (PP); Sat, 16 Mar 1996 04:32:29 -0800 Received: from gateway.radvision.rad.co.il by blue.radvision.rad.co.il (4.1/SMI-4.1) id AA06871; Sat, 16 Mar 96 14:28:42 IST Received: by gateway.radvision.rad.co.il with Microsoft Mail id <314B4234@gateway.radvision.rad.co.il>; Sat, 16 Mar 96 14:35:32 PST From: Ami Amir To: IMTC Members , IETF remote conference , h32z2-list Cc: Rich Baker , Revital Cohen , Karen Turel , Eli Doron Subject: IMTC Tel Aviv - Registration Reminder Date: Sat, 16 Mar 96 14:31:00 PST Message-Id: <314B4234@gateway.radvision.rad.co.il> Encoding: 118 TEXT X-Mailer: Microsoft Mail V3.0 Dear Colleagues, This letter is following Rich Baker's letter from last week. We understand the hesitation that some people feel in coming over after the events of last month. However, ne result is that security has really tightened up, and as a father to three kids (12 to 24 years of age), I feel absolutely comfortable in letting them roam the streets at any time (day or night). Assuming that the meeting does actually take place here: Time flies, and we need to finalize the arrangements for the Tel Aviv IMTC meeting. For those of you that have yet to register, please do so BEFORE or on MARCH 31. It will be difficult to guarantee hotel rooms for those registering later than that date. It is the height of the tourist season, and hotels are filling up. As a reminder - to register please contact: Ms. Revital Cohen revitalc@radvision.rad.co.il; tel:+972/3/645-5220; fax:+972/3/647-6669. enclosed: further details. Ami ============================================================================= Location: The Sheraton Hotel, Hayarkon Street Tel Aviv Two meeting rooms, lunch and refreshments are provided for. Accomodations: The Sheraton is located in Tel Aviv's hotel strip by the beach. You may choose a hotel according to your budget and personal preferences >from the following list (special rates have been arranged - if you are calling in directly, please indicate that you are part of the IMTC/RAD rates). All rates include a buffet style breakfast. The Sheraton - (5 star) $180 The Yamit - (4 star) $91 less than 5 minute stroll Hotel Basel - (4 star) $70 less than 3 minutes walk, smaller rooms All major credit cards are accepted. ATM machines will provide local currency (3 sheqels = $1.0). For administrative reasons, we ask that you make your reservations with our Office Manager: Ms. Revital Cohen revitalc@radvision.rad.co.il; tel:+972/3/645-5220; fax:+972/3/647-6669. Last minute changes and any special requests and questions - hotel contacts: Sheraton "Ganani Reservations" via Phone/Fax +972/3/547-0398 Yamit Phone - +972/3/519-7111, Fax - +972/3/517-4719 Basel Phone - +972/3/546-8126, Fax - +972/3/546-7687 How to get here: All major European Airlines plus El Al and TWA (both with direct flights >from JFK or EWR) land here. El Al also has direct flights from the Far East. Ben Gurion Airport is 30 minutes away. Take a cab to the hotel. It is about 60 NIS - New Israeli Sheqel, equivalent to $20. Get some local currency at the airport's ATM machines or banks. In dire straits - cabs will accept dollars. Local Transportation: It is recommended that you do not rent cars ahead of time, and if you wish to pick up a car for a day or so, many rental offices are around the corner. Cabs are cheap and almost everything is within walking distance. Dress Code: Tel Aviv is VERY informal, no ties, suits. You may bring a jacket and/or pullover for an evening stroll. No "dress code" in restaurants or bars (although shorts and sandals are frowned upon in some of the better places). Weather: Averaging 25 deg C (70 deg F), hardly any rain, and the beach is a stone's throw away from the hotels. Communications and E Mail: Keep in mind that hotels' phone bills are exhorbitant. AT&T, MCI and Sprint have local access numbers. Phone jacks in hotels are RJ 11 / DTMF. We will provide you with telnet access via our router (local call). We are also checking with the hotel and the local PTT - Bezeq - might be able to provide ISDN remote access from the hotel. Extracurricular Activities: We are organizing and hosting a bus tour of Jerusalem (it's 40 miles/60km >from Tel Aviv) for Saturday, April 20th. Jerusalem is unique, and should not be missed. We recommend you plan your flights accordingly. Please let us know if you wish to join. We would also like to invite you to a night in town - Wednesday, April 17. CU Ami amir@radvision.rad.co.il +972/3/645-5280 From rem-conf-request@es.net Sat Mar 16 09:51:54 1996 Received: from watson.ibm.com by osi-west.es.net with ESnet SMTP (PP); Sat, 16 Mar 1996 06:51:22 -0800 Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5943; Sat, 16 Mar 96 09:49:56 EST Date: Sat, 16 Mar 96 09:48:41 EST From: "Shu-Ping Chang ((914)784-7746, FAX:()" To: perform@tay1.dec.com, end2end-interest@isi.edu, ietf@isi.edu, rem-conf@es.net, announcements.chi@Xerox.com, arl@arl1.wustl.edu, atm@bbn.com, cip@bbn.com, cnom@maestro.bellcore.com, ccrc@dworkin.wustl.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, globecom@signet.com.sg, hipparch@sophia.inria.fr, icad-request@santafe.edu, iplpdn@cnri.reston.va.us, sigmedia@bellcore.com, smds@cnri.reston.va.us, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-a, uist.chi@Xerox.com, xtp-relay@cs.concordia.ca Subject: The 21st LCN Conference, Oct. 13-16, 1996, Minneapolis, MN, USA CALL FOR PAPERS 21st Annual Conference on Local Computer Networks "The Conference on Practical Leading Edge Computer Networking" October 13 - October 16, 1996, Minneapolis, Minnesota, USA Sponsored by: IEEE Computer Society TC - Computer Communications With the growing trend of personal communications and human central interfaces, future networks, both at home and in the office, will have very different characteristics. Wireless networks and multimedia applications further complicate the system design issue. The number of home offices is growing for environmental or economic reasons. Is there a system equally good for both home and office? Or, they are so different that a common system design won't be able to satisfy both? "Networking to/at home and office" will be the focus of the 21st LCN. Papers that cover these area are explicitly sought and will be given preference. Sessions are being organized on: Internetworking/Routers/Bridges Multimedia Personal Communications User Interfaces ATM Congestion Control Emerging Technology System Designs Networking to/at home and office High Speed Networks Wireless Networks LANs, MANs and WANs Real-time Networks High Performance Protocols Network Management Important Dates: Submission: April 12, 1996 Acceptance: June 18, 1996 Camera Copy: Aug. 1, 1996 For more information, please view the LCN Web page at: http://www.hill.com/lcn/lcn.html Information for Authors: All authors must submit 5 copies of the full technical paper in English by mail or delivery services. DO NOT SUBMIT COMPLETE PAPERS BY FAX. However, E-mail submission of plain postscript file is encouraged. In this case, no encoding, postscript is ASCII, and no compression is allowed. Further, the postscript file must be able to print on 8.5"x11" paper. The first page must contain: title of the paper, author's names including affiliations, complete mailing address, telephone and fax numbers, E-mail address, and a 250-word (maximum) abstract (double spaced) to Shu-Ping Chang, Program Chair, at the address below: Dr. Shu-Ping Chang IBM, Thomas J. Watson Research Center 30 Saw Mill River Road, H2-C18 Hawthorne, NY 10532 USA Phone: +1 914 784-7746 Fax: +1 914 784-6318 Internet: spchang@watson.ibm.com From rem-conf-request@es.net Mon Mar 18 22:16:19 1996 Received: from bmrc.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 18 Mar 1996 19:15:45 -0800 Received: from garfield.CS.Berkeley.EDU (garfield.CS.Berkeley.EDU [128.32.32.118]) by bmrc.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id TAA18917 for <298@bmrc.berkeley.edu>; Mon, 18 Mar 1996 19:12:21 -0800 Received: from garfield.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by garfield.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id TAA03558; Mon, 18 Mar 1996 19:12:17 -0800 Message-Id: <199603190312.TAA03558@garfield.CS.Berkeley.EDU> From: Andrew Swan To: 298@bmrc.Berkeley.EDU cc: rowe@cs.berkeley.edu Subject: UC Berkeley Multimedia Seminar 3/20/96 - "Buying Renting and Selling Information Goods" X-URL: http://www.cs.berkeley.edu/~aswan/ Date: Mon, 18 Mar 1996 19:12:17 -0800 Sender: aswan@bugs-bunny.CS.Berkeley.EDU This week's Berkeley Multimedia and Graphics seminar will be held Wednesday, March 20, from 12:30 - 2:00 PST in 405 Soda Hall. The speaker will be Hal Varian from the U.C. Berkeley School of Information Management and Systems, discussing "Buying, Renting and Sharing Information Goods." The talk will be broadcast on the Internet MBONE, beginning at roughly 12:40 PM PST. Please note that you will need vic 2.7 to watch the broadcast. Pre-compiled vic binaries for most architectures are available from: ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test/ Questions should be directed to Larry Rowe (rowe@cs.berkeley.edu) Abstract: Information goods such as books, journals, computer software, videos, etc. can often be copied and/or shared. I outline conditions under which the possibility of sharing may increase or decrease producer profits. If a rental market is present, more copies will be sold at a lower price, and I derive conditions that illustrate when this is more or less profitable than a sales-only market. When users have heterogeneous tastes, a rental market provides a nice way to segment high-value and low value users. Both of these effects tend to suggest that rental markets may often increase profits, contrary to widespread views to the contrary. -- Andrew Swan aswan@cs.berkeley.edu Plateau Multimedia Research Group http://www.cs.berkeley.edu/~aswan/ From rem-conf-request@es.net Tue Mar 19 02:33:34 1996 Received: from ix2.ix.netcom.com by osi-west.es.net with ESnet SMTP (PP); Mon, 18 Mar 1996 23:33:03 -0800 Received: from by ix2.ix.netcom.com (8.6.13/SMI-4.1/Netcom) id XAA27870; Mon, 18 Mar 1996 23:32:52 -0800 Date: Mon, 18 Mar 1996 23:32:52 -0800 Message-Id: <199603190732.XAA27870@ix2.ix.netcom.com> From: gvsi@ix.netcom.com (Megan Kirst ) Subject: Fwd: BOOK: "MBone: Interactive Multimedia on the Internet" To: cu-seeme-l@cornell.edu To: videophone@es.net To: rem-conf@es.net ---- Begin Forwarded Message Subject: BOOK: "MBone: Interactive Multimedia on the Internet" >>Unsolicited plug: this is a great book! I recommend it for anyone interested >>in using the MBone. Besides providing a thorough overview of key topics, >>Vinay's chapter "System Administrator's Guide to the MBone" covers a lot of >>advanced concepts and tools clearly in one place. >>Kumar, Vinay, _MBone: Interactive Multimedia on the Internet_, New Riders >>Publishing, Indianapolis Indiana, 1996. ISBN 1-56205-397-3. >>(U.S.) Library of Congress QA76.76.I59K85 >>Of course Vinay's page is at http://www.best.com/~prince/techinfo/mbone.html >>New Riders is at http://www.mcp.com/newriders >>List price on the back $32 USA/$44 Canada/29.49 UK >>I'm making a public recommendation because the book is a tremendous resource >>that has not been discussed much on the lists. I found it very useful. >>all the best, Don -- Don, A couple of other great books about videoconferencing are: "Videoconferencing the Whole Picture" by Toby Trowt-Bayard, "Internet TV With CU-SeeMe" by Michael Sattler Both of them are avalible by calling 1-800-909-4784 are sending an email to GVSI@aol.com Meg From rem-conf-request@es.net Tue Mar 19 06:26:10 1996 Received: from elaine.crcg.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 03:25:28 -0800 Received: from condor.crcg.edu by elaine.crcg.edu (4.1/SMI-4.1) id AA26303; Tue, 19 Mar 96 06:25:27 EST Received: by condor.crcg.edu (940816.SGI.8.6.9/SMI-4.0) id FAA29715; Tue, 19 Mar 1996 05:56:17 -0500 Date: Tue, 19 Mar 1996 05:56:17 +30000 From: Mike Macedonia X-Sender: mmacedon@condor To: rem-conf@es.net Cc: cu-seeme-l@cornell.edu, mbone@isi.edu, videophone@es.net Subject: MCI to offer video services over the Internet In-Reply-To: <199603190732.XAA27870@ix2.ix.netcom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII MCI says in a news article that it will include videoconferencing as part of its new Internet services. Does anyone have any details? Does this mean multicast? ----------------------------------------------------------------- | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | | Vice President | EMAIL: mmacedon@crcg.edu | | Fraunhofer CRCG | | | 167 Angell Street | PH : (+1) 401 453-6363 | | Providence, RI 02906 | FAX: (+1) 401 453-0444 | ----------------------------------------------------------------- From rem-conf-request@es.net Tue Mar 19 08:17:43 1996 Received: from davinci.gmu.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 05:16:56 -0800 Received: by davinci.gmu.edu (950215.SGI.8.6.10/940406.SGI.AUTO) id IAA07024; Tue, 19 Mar 1996 08:14:12 -0500 From: mbenson@davinci.gmu.edu (Michael Benson) Message-Id: <199603191314.IAA07024@davinci.gmu.edu> Subject: Re: MCI to offer video services over the Internet To: mmacedon@crcg.edu (Mike Macedonia) Date: Tue, 19 Mar 1996 08:14:09 -0500 (EST) Cc: rem-conf@es.net, cu-seeme-l@cornell.edu, mbone@ISI.EDU, videophone@es.net In-Reply-To: from "Mike Macedonia" at Mar 19, 96 05:56:17 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 905 Where was this news article? Usually it is possible to call the author for complete information that did not appear in the article. Michael > > > MCI says in a news article that it will include videoconferencing as > part of its new Internet services. > > Does anyone have any details? Does this mean multicast? > > ----------------------------------------------------------------- > | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | > | Vice President | EMAIL: mmacedon@crcg.edu | > | Fraunhofer CRCG | | > | 167 Angell Street | PH : (+1) 401 453-6363 | > | Providence, RI 02906 | FAX: (+1) 401 453-0444 | > ----------------------------------------------------------------- > > -- Michael Benson Computer science graduating student of George Mason University WWW: http://cne.gmu.edu/~mbenson Email: mbenson@gmu.edu Whois: whois -h gmu.edu mbenson From rem-conf-request@es.net Tue Mar 19 08:34:13 1996 Received: from postoffice.reston.mci.net by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 05:33:13 -0800 Received: from localhost (it.Reston.mci.net [204.70.128.10]) by postoffice.reston.mci.net (8.6.12/8.6.6) with ESMTP id IAA25498; Tue, 19 Mar 1996 08:33:07 -0500 Message-Id: <199603191333.IAA25498@postoffice.reston.mci.net> To: Mike Macedonia cc: rem-conf@es.net, cu-seeme-l@cornell.edu, mbone@isi.edu, videophone@es.net Subject: Re: MCI to offer video services over the Internet In-reply-to: Your message of "Tue, 19 Mar 1996 05:56:17." Date: Tue, 19 Mar 1996 08:32:36 -0500 From: Jeff Young i don't honestly know. where did you see the press release? no one has approached us about using the multicast backbone for videoconferencing... Jeff Young young@mci.net > Return-Path: majordom@ISI.EDU > Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by postoffice.reston.mci.net (8.6.12/8.6.6) with SMTP id GAA24552; Tue, 19 Mar 1996 06:47:24 -0500 > Received: by zephyr.isi.edu (5.65c/5.61+local-20) > id ; Tue, 19 Mar 1996 03:26:15 -0800 > Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20) > id ; Tue, 19 Mar 1996 03:26:14 -0800 > Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-22) > id ; Tue, 19 Mar 1996 03:26:13 -0800 > Received: by zephyr.isi.edu (5.65c/5.61+local-20) > id ; Tue, 19 Mar 1996 03:25:28 -0800 > Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20) > id ; Tue, 19 Mar 1996 03:25:25 -0800 > Received: from elaine.crcg.edu by venera.isi.edu (5.65c/5.61+local-22) > id ; Tue, 19 Mar 1996 03:25:23 -0800 > Received: from condor.crcg.edu by elaine.crcg.edu (4.1/SMI-4.1) > id AA26303; Tue, 19 Mar 96 06:25:27 EST > Received: by condor.crcg.edu (940816.SGI.8.6.9/SMI-4.0) > id FAA29715; Tue, 19 Mar 1996 05:56:17 -0500 > Date: Tue, 19 Mar 1996 05:56:17 +30000 > From: Mike Macedonia > X-Sender: mmacedon@condor > To: rem-conf@es.net > Cc: cu-seeme-l@cornell.edu, mbone@ISI.EDU, videophone@es.net > Subject: MCI to offer video services over the Internet > In-Reply-To: <199603190732.XAA27870@ix2.ix.netcom.com> > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Sender: owner-mbone-na@ISI.EDU > Precedence: bulk > > > MCI says in a news article that it will include videoconferencing as > part of its new Internet services. > > Does anyone have any details? Does this mean multicast? > > ----------------------------------------------------------------- > | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | > | Vice President | EMAIL: mmacedon@crcg.edu | > | Fraunhofer CRCG | | > | 167 Angell Street | PH : (+1) 401 453-6363 | > | Providence, RI 02906 | FAX: (+1) 401 453-0444 | > ----------------------------------------------------------------- > > From rem-conf-request@es.net Tue Mar 19 09:08:41 1996 Received: from didier.ee.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 06:07:46 -0800 Received: from [130.207.230.109] (nina.ee.gatech.edu [130.207.230.109]) by didier.ee.gatech.edu (8.7.4/8.7.2) with SMTP id JAA28120; Tue, 19 Mar 1996 09:05:38 -0500 (EST) X-Sender: maxene@mail.ee.gatech.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 09:11:02 -0500 To: alias.TOTALE.ieeetcpc@ccvm.sunysb.edu, orcs-l%osuvm1.BITNET@searn.sunet.se, glynn@leland.stanford.edu, ietf-announce@cnri.reston.va.us, mobile-ip , f-troup@aurora.cis.upenn.edu, rem-conf-request@es.net, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, arpanet-bboard@mc.lcs.mit.edu, cnom@meatro.bellcore.com, globecom@signet.com.sig, ietf@isi.edu, tccc From: Maxene.Pentecost@ee.gatech.edu (Maxene Pentecost) Subject: AD FOR FACULTY POSITIONS AT GEORGIA TECH Cc: maxene@eeserv.ee.gatech.edu, ian@eeserv.ee.gatech.edu ADVERTISEMENT FOR FACULTY CANDIDATES Georgia Institute of Technology: The School of Electrical and Computer Engineering currently seeks applicants for tenure track faculty positions at all levels. A Ph.D in EE, or equivalent, and clear potential for distinguished performance in teaching and research are required. Areas of special need include computer engineering, telecommunications, analog electronics, and the intersection of those areas with related areas such as microelectronics, electromagnetics, and signal processing. Resumes and statements of interest should be addressed to: Chair, School of Electrical and Computer Engineering, Georgia Institute of Technology, Atlanta, GA 30332-0250. Immigration status of non-US citizens should be indicated. Georgia Tech is is an equal opportunity/affirmative action employer. Maxene L. Pentecost Administrative Coordinator School of Electrical & Computer Engineering Georgia Institute of Technology Atlanta, GA 30332-0250 (404) 894-4468 FAX (404) 894-4641 From rem-conf-request@es.net Tue Mar 19 09:39:20 1996 Received: from elaine.crcg.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 06:38:52 -0800 Received: by elaine.crcg.edu (4.1/SMI-4.1) id AA27171; Tue, 19 Mar 96 09:39:06 EST Date: Tue, 19 Mar 1996 09:39:05 -0500 (EST) From: Mike Macedonia X-Sender: mmacedon@elaine To: Jeff Young Cc: rem-conf@es.net, mbone@isi.edu Subject: Re: MCI to offer video services over the Internet In-Reply-To: <199603191333.IAA25498@postoffice.reston.mci.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Jeff, See http://www.mci.com/virtual/news-news/top-headline-827152577.html >From the release: MCI also announced it has formed an advanced applications unit to focus on developing emerging Internet applications for its customers. The new unit will report to Fred Briggs, MCI's chief engineering officer, and Vint Cerf, MCI's senior vice president of data architecture. A few of the technologies under development include the use of direct broadcast satellite for high-speed Internet connectivity, ** videoconferencing over the Internet **, shared applications, multi-media messaging and advanced security. ----------------------------------------------------------------- | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | | Vice President | EMAIL: mmacedon@crcg.edu | | Fraunhofer CRCG | | | 167 Angell Street | PH : (+1) 401 453-6363 | | Providence, RI 02906 | FAX: (+1) 401 453-0444 | ----------------------------------------------------------------- On Tue, 19 Mar 1996, Jeff Young wrote: > i don't honestly know. where did you see the press release? > no one has approached us about using the multicast backbone > for videoconferencing... > > Jeff Young > young@mci.net > > > > Return-Path: majordom@ISI.EDU > > Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by postoffice.reston.mci.net (8.6.12/8.6.6) with SMTP id GAA24552; Tue, 19 Mar 1996 06:47:24 -0500 > > Received: by zephyr.isi.edu (5.65c/5.61+local-20) > > id ; Tue, 19 Mar 1996 03:26:15 -0800 > > Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20) > > id ; Tue, 19 Mar 1996 03:26:14 -0800 > > Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-22) > > id ; Tue, 19 Mar 1996 03:26:13 -0800 > > Received: by zephyr.isi.edu (5.65c/5.61+local-20) > > id ; Tue, 19 Mar 1996 03:25:28 -0800 > > Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20) > > id ; Tue, 19 Mar 1996 03:25:25 -0800 > > Received: from elaine.crcg.edu by venera.isi.edu (5.65c/5.61+local-22) > > id ; Tue, 19 Mar 1996 03:25:23 -0800 > > Received: from condor.crcg.edu by elaine.crcg.edu (4.1/SMI-4.1) > > id AA26303; Tue, 19 Mar 96 06:25:27 EST > > Received: by condor.crcg.edu (940816.SGI.8.6.9/SMI-4.0) > > id FAA29715; Tue, 19 Mar 1996 05:56:17 -0500 > > Date: Tue, 19 Mar 1996 05:56:17 +30000 > > From: Mike Macedonia > > X-Sender: mmacedon@condor > > To: rem-conf@es.net > > Cc: cu-seeme-l@cornell.edu, mbone@ISI.EDU, videophone@es.net > > Subject: MCI to offer video services over the Internet > > In-Reply-To: <199603190732.XAA27870@ix2.ix.netcom.com> > > Message-Id: > > Mime-Version: 1.0 > > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Sender: owner-mbone-na@ISI.EDU > > Precedence: bulk > > > > > > MCI says in a news article that it will include videoconferencing as > > part of its new Internet services. > > > > Does anyone have any details? Does this mean multicast? > > > > ----------------------------------------------------------------- > > | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | > > | Vice President | EMAIL: mmacedon@crcg.edu | > > | Fraunhofer CRCG | | > > | 167 Angell Street | PH : (+1) 401 453-6363 | > > | Providence, RI 02906 | FAX: (+1) 401 453-0444 | > > ----------------------------------------------------------------- > > > > > > From rem-conf-request@es.net Tue Mar 19 10:25:53 1996 Received: from mermoz.ensica.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 07:24:55 -0800 Received: from magic (magic.ensica.fr [192.70.110.76]) by mermoz.ensica.fr (8.6.10/kit5.1-0504) with ESMTP id QAA18237 for ; Tue, 19 Mar 1996 16:21:28 GMT Original-Received: by magic, Tue, 19 Mar 1996 16:21:44 +0100 PP-warning: Illegal Received field on preceding line Date: Tue, 19 Mar 1996 16:21:44 +0100 From: pdss@ensica.fr Message-Id: <199603191521.QAA10770@magic> To: rem-conf@es.net Subject: 2nd CFP: MultiMedia Modeling (MMM'96) in Toulouse, France, Nov. 12-15 ----------------------------------------------------------------------------- MMM'96 ----------------------------------------------------------------------------- Call for Papers Third International Conference on MULTIMEDIA MODELING Toulouse, France, 12-15 November 1996 The purpose of the MMM series of conferences is to bring together activities related to all aspects of multimedia modeling, in its broader sense, from multimedia networking to virtual worlds. Its ultimate goal is to provide a better understanding of the basic paradigms and to establish conceptual links between them for a better design of future advanced multimedia systems. In cooperation with IFIP WG5.10 and the Computer Graphics Society, (ACM and IEEE requested), MMM'96 will be a forum for presentation of the state of the art in the representation, processing, interaction, integration and retrieval of multimedia information, and will also provide an excellent orientation for newcomers. Research papers as well as proposals for tutorials and tool demonstrations are solicited particularly (but not restricted to) in the following areas: - Multimedia and Hypermedia (MM & HM) - Model-based Video/Vision/Graphics - Formal models for MM & HM - Indexing & Retrieval of MM & HM - Topological & Geometric Modeling - Integration of Graphics & Vision - Integration of MM Information - Synchronization of MM & HM Information - Interactive MM & HM - MM & HM Virtual Reality - MM & HM Operating Systems - MM & HM Networking - MM & HM Database Modeling - Speech & Music Modeling - Applications of MM & HM MMM'96 will start with one day of tutorials, and will continue with three days of technical presentations. Tool presentations will be possible throughout the conference. The conference, organized by both LAAS-CNRS and ENSICA, will be held at ENSICA in Toulouse. Conference Chairperson: Michel Diaz (LAAS-CNRS, France) Program Committee Chairperson: Jean-Pierre Courtiat (LAAS-CNRS, France) Tutorial Chairperson: Dick Bulterman (CWI, The Netherlands) Conference Organization Chairperson: Patrick Senac (ENSICA, France) International Program Committee: Dick Bulterman (CWI, The Netherlands), Tat Seng Chua (NUS, Singapore), Geoff Coulson (U. of Lancaster, United Kingdom), Jean-Pierre Courtiat (LAAS-CNRS, France), Michel Diaz (LAAS-CNRS, France), Christophe Diot (INRIA, France), Wolfgang Effelsberg (U. of Mannheim, Germany), Serge Fdida (U. of Paris, France), Michael Fry (UTS, Australia), Arif Ghafoor (Purdue U., USA), Simon Gibbs (GMD, Germany), Shuji Hashimoto (Waseda University, Japan), Ahmed Karmouch (U. of Ottawa, Canada), Brigitte Kerherve (UQAM, Canada), Tosiyasu L. Kunii (U. of Aizu, Japan), Myeong-Won Lee (Korean Telecom, Korea), Guy Leduc (University of Liege, Belgium), Alain Leger (CCETT, France), Nadia Magnenat-Thalmann (U. of Geneva, Switzerland), Hung-Keng Pung (NUS, Singapore), Guy Pujolle (U. of Versailles, France), Patrick Senac (ENSICA, France), Gary Schloss (SUNY at Stony Brooks, USA), Yoshihisa Shinagawa (U. of Tokyo, Japan), Jean-Bernard Stefani (CNET, France), Ralf Steinmetz (IBM, Germany), Daniel Thalmann (EPFL, Switzerland), P. Venkat Rangan (UCSD, USA) Important Dates: April 10, 1996 Submission deadline (for more details, see below) June 6, 1996 Notification of acceptance July 15, 1996 Camera-ready copy for final proceedings due Submission policy: Solicited are: - Full original research papers (in English), 5 copies, up to 16 pages (including bibliography), 12 point, single spaced, including an informative abstract as well as names and affiliations of all authors, and a list of keywords facilitating the assignment of papers to referees. A cover letter naming a contact author (including postal and E-mail address) is required. The cover letter should also state that the paper has not been presented at another conference nor is it currently being considered by another conference or by a journal. Finally, the cover letter should include the statement that "when accepted, one of the authors will attend the conference to present the paper". Accepted papers will appear in a Proceedings book published by World Scientific (given to participants) - Proposals for tool demonstrations (including hardware and software requirements) - Proposals for tutorials. All submissions should be sent to: Jean-Pierre Courtiat MMM'96 LAAS-CNRS 7, avenue du Colonel Roche Tel: (33) 61.33.62.44 31077 Toulouse Cedex Fax: (33) 61.33.64.11 France Email: courtiat@laas.fr For further information: MMM'96 Organization Committee, ENSICA Place Emile Blouin Tel: (33) 61.58.75.14 (Patrick Senac) 31056 Toulouse Cedex Fax: (33) 61.58.75.95 France Email: mmm96@ensica.fr To obtain additional information, you may also browse our World-Wide Web pages. The URL is http://www.ensica.fr/~mmm96 Expression of interest in MMM'96: If you are interested in MMM'96, please return the following information to the Conference Organization Chairperson (preferably by E-mail to mmm96@ensica.fr): Name (including title): ............................................... Affiliation: .......................................................... Address: .............................................................. Tel: ................ Fax: ............. Email: ....................... o I would like to receive further information about MMM'96 by MAIL or ELECTRONIC MAIL (please indicate), please put me on your mailing lists. o I intend to submit to MMM'96 a research paper entitled: ........................................................... ..................................................................... o I intend to submit to MMM'96 a proposal for a tool demonstration entitled: ........................................................... ..................................................................... o I would be interested in offering a tutorial entitled: ........................................................... Pierre de Saqui-Sannes pdss@ensica.fr ENSICA Place Emile Blouin tel. +33 61.58.75.78 31056 Toulouse Cedex fax. +33 61.58.75.95 From rem-conf-request@es.net Tue Mar 19 10:29:34 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 07:28:55 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 19 Mar 1996 15:24:10 +0000 To: Mike Macedonia cc: Jeff Young , rem-conf@es.net, mbone@ISI.EDU Subject: Re: MCI to offer video services over the Internet In-reply-to: Your message of "Tue, 19 Mar 96 09:39:05 EST." Date: Tue, 19 Mar 96 15:24:06 +0000 Message-ID: <2931.827249046@cs.ucl.ac.uk> From: Jon Crowcroft >satellite for high-speed Internet connectivity, ** videoconferencing over the >Internet **, shared applications, multi-media messaging and advanced >security. so thats ok then i assume MCI will now lean on the fellow mambers of ACTA to withdraw their absurd (absurd because it is unenforceable, and meaningless) petition to the FCC..... :-) otherwise i can see myself as able to run voice over PSTN and IP over PSTN but not voice over IP over PSTN, which is looking a pretty atractive combination with some of the new modems and compression algorithms and PC performance to run them! (e.g. a 28kbps modem with a 14kbpsa voice channel leaves 14kbps for my email and so on...) i spose voice over IP over fax is out of the question:-) cheers jon From rem-conf-request@es.net Tue Mar 19 16:09:58 1996 Received: from black-ice.cc.vt.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 13:09:09 -0800 Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.5/8.7.3) with ESMTP id QAA14836; Tue, 19 Mar 1996 16:08:55 -0500 Message-Id: <199603192108.QAA14836@black-ice.cc.vt.edu> X-Mailer: exmh version 1.6.5 12/8/95 To: Jon Crowcroft cc: Mike Macedonia , Jeff Young , rem-conf@es.net, mbone@ISI.EDU Subject: Re: MCI to offer video services over the Internet In-reply-to: Your message of "Tue, 19 Mar 1996 15:24:06 GMT." <2931.827249046@cs.ucl.ac.uk> From: Valdis.Kletnieks@vt.edu X-URL: http://black-ice.cc.vt.edu/~valdis/ References: <2931.827249046@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Mar 1996 16:08:50 -0500 On Tue, 19 Mar 1996 15:24:06 GMT, Jon Crowcroft said: > i spose voice over IP over fax is out of the question:-) See RFC 1149. Also, I believe there was a draft RFC for IP encapsulation inside RFC822, but implementors of this should read RFC1326. -- Valdis Kletnieks Computer Systems Engineer Virginia Tech From rem-conf-request@es.net Tue Mar 19 16:47:54 1996 Received: from venera.isi.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 13:47:18 -0800 Received: from ash-s.isi.edu (ash-a.isi.edu) by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 19 Mar 1996 13:47:14 -0800 Date: Tue, 19 Mar 1996 13:43:33 -0800 From: touch@ISI.EDU Posted-Date: Tue, 19 Mar 1996 13:43:33 -0800 Message-Id: <199603192143.AA07496@ash-s.isi.edu> Received: by ash-s.isi.edu (5.65c/4.0.3-4) id ; Tue, 19 Mar 1996 13:43:33 -0800 To: mmacedon@crcg.edu, J.Crowcroft@cs.ucl.ac.uk Subject: Re: MCI to offer video services over the Internet Cc: young@mci.net, rem-conf@es.net, mbone@ISI.EDU X-Auto-Sig-Adder-By: faber@isi.edu > From rem-conf-request@es.net Tue Mar 19 11:35:24 1996 > Subject: Re: MCI to offer video services over the Internet > Date: Tue, 19 Mar 96 15:24:06 +0000 > From: Jon Crowcroft > > >satellite for high-speed Internet connectivity, ** videoconferencing over the > >Internet **, shared applications, multi-media messaging and advanced > >security. Hmm. Doing telephony over satellite - seems like one or two such hops and you're dead, given that the latency will creep over 1/2 second. High-speed still isn't low latency. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From rem-conf-request@es.net Tue Mar 19 23:31:34 1996 Received: from black-ice.cc.vt.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 20:31:07 -0800 Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.5/8.7.3) with ESMTP id XAA24874; Tue, 19 Mar 1996 23:29:34 -0500 Message-Id: <199603200429.XAA24874@black-ice.cc.vt.edu> X-Mailer: exmh version 1.6.5 12/8/95 To: touch@ISI.EDU cc: mmacedon@crcg.edu, J.Crowcroft@cs.ucl.ac.uk, young@mci.net, rem-conf@es.net, mbone@ISI.EDU Subject: Re: MCI to offer video services over the Internet In-reply-to: Your message of "Tue, 19 Mar 1996 13:43:33 PST." <199603192143.AA07496@ash-s.isi.edu> From: Valdis.Kletnieks@vt.edu X-URL: http://black-ice.cc.vt.edu/~valdis/ References: <199603192143.AA07496@ash-s.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Mar 1996 23:29:26 -0500 On Tue, 19 Mar 1996 13:43:33 PST, touch@ISI.EDU said: > Hmm. Doing telephony over satellite - seems like one or two such > hops and you're dead, given that the latency will creep over 1/2 second. Hmm.. I must have blinked here and missed a sarcasm alert. Wasn't the original reason for geosyncronous satellites to provide long distance telephone service? Remember.. 0.5 seconds latency may be an eternity for silicon-based life, but for us carbon-based critters, it's still a blink of an eye... -- Valdis Kletnieks Computer Systems Engineer Virginia Tech From rem-conf-request@es.net Wed Mar 20 01:56:49 1996 Received: from catarina.usc.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 22:56:20 -0800 Received: from excalibur.usc.edu (excalibur.usc.edu [128.125.51.11]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id WAA08353; Tue, 19 Mar 1996 22:56:05 -0800 Received: (ahelmy@localhost) by excalibur.usc.edu (8.6.10/8.6.9) id WAA20717; Tue, 19 Mar 1996 22:56:04 -0800 Date: Tue, 19 Mar 1996 22:56:04 -0800 (PST) From: Ahmed A-G Helmy To: Valdis.Kletnieks@vt.edu cc: touch@ISI.EDU, mmacedon@crcg.edu, J.Crowcroft@cs.ucl.ac.uk, young@mci.net, rem-conf@es.net, mbone@ISI.EDU Subject: Re: MCI to offer video services over the Internet In-Reply-To: <199603200429.XAA24874@black-ice.cc.vt.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > Hmm. Doing telephony over satellite - seems like one or two such > > hops and you're dead, given that the latency will creep over 1/2 second. > > Hmm.. I must have blinked here and missed a sarcasm alert. Wasn't the original > reason for geosyncronous satellites to provide long distance telephone service? > > Remember.. 0.5 seconds latency may be an eternity for silicon-based life, but > for us carbon-based critters, it's still a blink of an eye... Jitter (variance of delay), however, may render voice unintelligible.. ! From rem-conf-request@es.net Wed Mar 20 02:03:45 1996 Received: from black-ice.cc.vt.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 23:03:13 -0800 Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.5/8.7.3) with ESMTP id CAA29318; Wed, 20 Mar 1996 02:02:30 -0500 Message-Id: <199603200702.CAA29318@black-ice.cc.vt.edu> X-Mailer: exmh version 1.6.5 12/8/95 To: Ahmed A-G Helmy cc: touch@ISI.EDU, mmacedon@crcg.edu, J.Crowcroft@cs.ucl.ac.uk, young@mci.net, rem-conf@es.net, mbone@ISI.EDU Subject: Re: MCI to offer video services over the Internet In-reply-to: Your message of "Tue, 19 Mar 1996 22:56:04 PST." From: Valdis.Kletnieks@vt.edu X-URL: http://black-ice.cc.vt.edu/~valdis/ References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Mar 1996 02:01:59 -0500 On Tue, 19 Mar 1996 22:56:04 PST, Ahmed A-G Helmy said: > Jitter (variance of delay), however, may render voice unintelligible.. ! Is *that* why I'm incoherent unless I've had the proper dosage of caffeine? ;) From rem-conf-request@es.net Wed Mar 20 02:13:45 1996 Received: from central.cnet.com by osi-west.es.net with ESnet SMTP (PP); Tue, 19 Mar 1996 23:13:18 -0800 Received: from scarface (scarface [204.162.81.17]) by central.cnet.com (8.6.12/8.6.12) with SMTP id XAA03957; Tue, 19 Mar 1996 23:12:10 -0800 Date: Tue, 19 Mar 1996 23:12:10 -0800 (PST) From: ken emery X-Sender: ken@scarface To: Valdis.Kletnieks@vt.edu cc: touch@ISI.EDU, mmacedon@crcg.edu, J.Crowcroft@cs.ucl.ac.uk, young@mci.net, rem-conf@es.net, mbone@ISI.EDU Subject: Re: MCI to offer video services over the Internet In-Reply-To: <199603200429.XAA24874@black-ice.cc.vt.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 19 Mar 1996 Valdis.Kletnieks@vt.edu wrote: > On Tue, 19 Mar 1996 13:43:33 PST, touch@ISI.EDU said: > > Hmm. Doing telephony over satellite - seems like one or two such > > hops and you're dead, given that the latency will creep over 1/2 second. > > Hmm.. I must have blinked here and missed a sarcasm alert. Wasn't the > original reason for geosyncronous satellites to provide long distance > telephone service? > > Remember.. 0.5 seconds latency may be an eternity for silicon-based life, but > for us carbon-based critters, it's still a blink of an eye... Actually 0.5 seconds is about the point where us "carbon-based critters" can start to detect the echo/delay inherent in satalite hops. Basically Bell labs found that if it was below 0.5 seconds the human ear could not detect the delay, over that and it was quite annoying (a friend of mine actually worked on this project at Bell Labs). They also found that is satalite was used one way and land lines the other that it was more difficult to detect the echo (by the human :-) bye, ken emery From rem-conf-request@es.net Wed Mar 20 03:29:50 1996 Received: from silver.sms.fi by osi-west.es.net with ESnet SMTP (PP); Wed, 20 Mar 1996 00:29:18 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id KAA01800; Wed, 20 Mar 1996 10:25:26 +0200 Date: Wed, 20 Mar 1996 10:25:26 +0200 Message-Id: <199603200825.KAA01800@silver.sms.fi> From: Petri Helenius To: Valdis.Kletnieks@vt.edu Cc: touch@ISI.EDU, mmacedon@crcg.edu, J.Crowcroft@cs.ucl.ac.uk, young@mci.net, rem-conf@es.net, mbone@ISI.EDU Subject: Re: MCI to offer video services over the Internet In-Reply-To: <199603200429.XAA24874@black-ice.cc.vt.edu> References: <199603192143.AA07496@ash-s.isi.edu> <199603200429.XAA24874@black-ice.cc.vt.edu> Valdis Kletnieks writes: > On Tue, 19 Mar 1996 13:43:33 PST, touch@ISI.EDU said: > > Hmm. Doing telephony over satellite - seems like one or two such > > hops and you're dead, given that the latency will creep over 1/2 second. > > Hmm.. I must have blinked here and missed a sarcasm alert. Wasn't the original > reason for geosyncronous satellites to provide long distance telephone service? > > Remember.. 0.5 seconds latency may be an eternity for silicon-based life, but > for us carbon-based critters, it's still a blink of an eye... And for many of the 'multimedia'-applications jitter (delay variance) and bandwidth are actually more important than the actual latency. Usually low jitter comes with either intelligent queueing or high bandwidth. I would also count low loss as one of the factors since I've yet to see data- interleaving audio application ... Pete From rem-conf-request@es.net Wed Mar 20 03:51:21 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 20 Mar 1996 00:50:33 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 20 Mar 1996 08:49:27 +0000 To: ken emery cc: rem-conf@es.net, mbone@ISI.EDU Subject: Re: MCI to offer video services over the Internet In-reply-to: Your message of "Tue, 19 Mar 1996 23:12:10 PST." Date: Wed, 20 Mar 1996 08:49:23 +0000 Message-ID: <810.827311763@cs.ucl.ac.uk> From: Jon Crowcroft >On Tue, 19 Mar 1996 Valdis.Kletnieks@vt.edu wrote: > >> On Tue, 19 Mar 1996 13:43:33 PST, touch@ISI.EDU said: >> > Hmm. Doing telephony over satellite - seems like one or two such >> > hops and you're dead, given that the latency will creep over 1/2 second. >> >> Hmm.. I must have blinked here and missed a sarcasm alert. Wasn't the >> original reason for geosyncronous satellites to provide long distance >> telephone service? >> >> Remember.. 0.5 seconds latency may be an eternity for silicon-based life, but >> for us carbon-based critters, it's still a blink of an eye... > >Actually 0.5 seconds is about the point where us "carbon-based critters" >can start to detect the echo/delay inherent in satalite hops. this confuses 2 things 1/ there is a end to end delay limit (around 200msec) for the turnaroudn that makes "natural conversation possible 2/ there is a delay loop limit (also around 200ms) around which it is impossible to speak whilst hering one's OWN voice fed back >Bell labs found that if it was below 0.5 seconds the human ear could not >detect the delay, over that and it was quite annoying (a friend of mine >actually worked on this project at Bell Labs). They also found that is >satalite was used one way and land lines the other that it was more >difficult to detect the echo (by the human :-) obviously a round trip time (for case 2) where the outbound is satellite, and the return path terrestrial removes one of the two 1/4 sec satellite hops - no mystery....and gets you down close (but not quite close enough) to the 200 msec....it is still unpleasant to use on the subject of jitter.... so long as the jitter is a second order effect (as is likely with satellite hops, unless your satellite is seriously out of geosynch - e.g. LEO), then you can accomodate it easily with playout buffers.....if the _mean_ delay varies (e.g. satellite slowly drifts:-), you need an adaptive playout buffer....technology exists for this, doesn't it :-) [this is the mbone list, right - have a look at the vat code.....or half a dozen other pieces of internet phone technology) a lot of telephone engineers get confused coz they think in terms of nets with non-work conserving switches, and "terminals" with a few bits bufferingh (i.e. ISDN telephones) whereas WE (the real world:-) use computers which tend to have enough memory to have a few minuites of audio playout and enough processing to do things like varying the silence gap lenghts between talk spurts in real time, or even adding pink noise between missing samples of talk spurt.....or even interpolating the speech (given half of the compression algorithms are based on a speech model, this is not really any more than an obvious extrapolation of the compression scheme to do either a) make up for loss b) make up for delayed samples going the other way (if the delay decreases rapidly - e.g. your satellite is coming down to earth:-), can be tricky for heavily comprewssed speech, but its doable....and easy for 64kbps PCM... sorry to repeat all this gubbins again.... jon From rem-conf-request@es.net Wed Mar 20 04:11:54 1996 Received: from silver.sms.fi by osi-west.es.net with ESnet SMTP (PP); Wed, 20 Mar 1996 01:11:03 -0800 Received: (from pete@localhost) by silver.sms.fi (8.6.12/8.6.9) id LAA01944; Wed, 20 Mar 1996 11:09:50 +0200 Date: Wed, 20 Mar 1996 11:09:50 +0200 Message-Id: <199603200909.LAA01944@silver.sms.fi> From: Petri Helenius To: Jon Crowcroft Cc: ken emery , rem-conf@es.net, mbone@ISI.EDU Subject: Re: MCI to offer video services over the Internet In-Reply-To: <810.827311763@cs.ucl.ac.uk> References: <810.827311763@cs.ucl.ac.uk> Jon Crowcroft writes: > > 2/ there is a delay loop limit (also around 200ms) around which it is impossible > to speak whilst hering one's OWN voice fed back > > obviously a round trip time (for case 2) where the outbound is > satellite, and the return path terrestrial removes one of the two > 1/4 sec satellite hops - no mystery....and gets you down close (but > not quite close enough) to the 200 msec....it is still unpleasant to > use > > on the subject of jitter.... > Try mixing digital cellular phones with intercontinental satellite telephone and then you are talking about delay loops and transmission latency! Pete From rem-conf-request@es.net Wed Mar 20 04:59:46 1996 Received: from nico.aarnet.edu.au by osi-west.es.net with ESnet SMTP (PP); Wed, 20 Mar 1996 01:58:40 -0800 Received: from [139.130.25.53] (sdup4.telstra.net [139.130.25.53]) by nico.aarnet.edu.au (8.6.10/8.6.10) with SMTP id TAA09767; Wed, 20 Mar 1996 19:47:51 +1000 Date: Wed, 20 Mar 1996 19:47:51 +1000 X-Sender: gih@nico.aarnet.edu.au Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Valdis.Kletnieks@vt.edu From: gih@aarnet.edu.au (Geoff Huston) Subject: Re: MCI to offer video services over the Internet Cc: touch@ISI.EDU, mmacedon@crcg.edu, J.Crowcroft@cs.ucl.ac.uk, young@mci.net, rem-conf@es.net, mbone@ISI.EDU For those folk such as myself who only got off satellite links about 3 years ago for international telephony, 0.5 of a second (0.65 to be precise) is a huge problem - not only do you have a very significant echo cancellation problem, which current equipment still has not completely solved, the delay of 0.5 second makes any useful interactive conversation close to impossible for us carbon-based lifeforms in the antipodes. I recall a study which placed a threshold of some 0.15 - 0.2 second as the point at which people had to adjust speech to accomodate for the delay, but I've completely forgotten the reference. Thanks, geoff At 4:29 AM 20/3/96, Valdis.Kletnieks@vt.edu wrote: >On Tue, 19 Mar 1996 13:43:33 PST, touch@ISI.EDU said: >> Hmm. Doing telephony over satellite - seems like one or two such >> hops and you're dead, given that the latency will creep over 1/2 second. > >Hmm.. I must have blinked here and missed a sarcasm alert. Wasn't the original >reason for geosyncronous satellites to provide long distance telephone service? > >Remember.. 0.5 seconds latency may be an eternity for silicon-based life, but >for us carbon-based critters, it's still a blink of an eye... >-- > Valdis Kletnieks > Computer Systems Engineer > Virginia Tech From rem-conf-request@es.net Wed Mar 20 06:39:38 1996 Received: from enterprise.pulver.com by osi-west.es.net with ESnet SMTP (PP); Wed, 20 Mar 1996 03:38:55 -0800 Received: (from jeff@localhost) by enterprise.pulver.com (8.6.12/8.6.12) id GAA10635; Wed, 20 Mar 1996 06:38:50 -0500 Date: Wed, 20 Mar 1996 06:38:48 -0500 (EST) From: Jeff Pulver To: rem-conf@es.net, mbone@isi.edu Subject: ** Announcemnet ** -- VON Coalition Formed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, For those of you who have been tracking ACTA's petition to the FCC to ban Internet Telephony, I thought you might want to know that a coalition has been formed with the immediate purpose and goal to persuade the FCC NOT to act favorably upon the ACTA petition. If you would like more information on the VON Coalition, please feel free to visit http://www.von.org. Your support would be appreciated. A copy of the VON Coalition press release is attached below. Jeff Pulver VON Coalition Chairman http://www.von.org ### COALITION FORMED IN RESPONSE TO PHONE COMPANY ATTEMPTS TO BLOCK INTERNET SERVICES New York, NY, March 18/PRNewswire/ - The "Voice On the Net" (VON) Coalition (http://www.von.org/) announces its formation in response to recent phone company attempts to regulate Internet services. The VON Coalition is taking action to preserve the worldwide network as a place for emerging technologies and business. Charter VON members include Internet users, technology companies and others intent on keeping the Internet open to all forms of electronic commerce, including voice transmission. The issue of voice on the Internet has heated up in recent weeks. New technology advances have led to the availability of computer programs that allow people to carry on real-time voice conversations over the Internet. While Internet calls are not of the same high quality as those placed through traditional long distance services, they offer some compelling advantages. For example, using this technology, school children in a rural American community could easily and inexpensively communicate with a scientist in London. Their conversation could include video and drawings along with interactive voice transmission. A growing number of Internet voice products, including VocalTec Inc.'s (NASDAQ: VOCLF) Internet Phone and Quarterdeck's (NASDAQ:QDEK) WebTalk, can be purchased today. Other companies including Intel, Microsoft, and Netscape, have announced their intent to produce similar products. The Long Distance industry, however, is trying to stop this competition. On March 4, ACTA, a trade association representing 130 of America's long distance companies, filed a petition asking the FCC to block the sale and use of such software products. ACTA is further asking that the FCC step in and begin regulating use of the Internet. The VON Coalition, along with the majority of Internet users, vehemently opposes such regulation. Public notice of the ACTA petition was issued on March 8, 1996 by the FCC (Report No. 2124). Comments to the petition must be submitted to the FCC by April 8, 1996. The VON Coalition will take a lead role in opposing the ACTA filing. "ACTA is, in effect, attempting to eliminate outside competition by banning emerging technologies" says VON Coalition Chairman Jeff Pulver. "The immediate mission of the VON Coalition is to persuade the FCC to deny the ACTA petition." "The ACTA petition asks the FCC to 'define the type of permissible communication which may be effected over the Internet'", says Elon Ganor, Chairman & CEO of VocalTec, Inc. "This is the kind of regulation that the US government and people have traditionaly criticized third world countries for." "ACTA is asking that the FCC declare specific software companies as 'Telecom Carriers'", Ganor continues. "Microsoft and Netscape recently announced audio and video strategies for the Internet. Does this mean they are now telecom carriers? Where will we draw the line?" Howard Gordon, President of Xing Technologies, makers of the Streamworks audio and video streaming product, says his organization is strongly opposed to any efforts which limit the ability of content providers to develop alternative distribution channels. "While the ACTA filing directly targets 2-way communications, we expect it's only a matter of time before similar efforts are directed against Internet radio and television broadcasting", says Gordon. According to VON Coalition member Takeshi Utsumi, Ph.D., Laureate of the prestigious Lord Perry Award for Excellence in Distance Education, "The U.S. data communication networks such as ARPANET, Telenet (now SprintNet), and the Internet, have been unregulated since the early 1980s. The fact that these networks were unregulated allowed the use of email to successfully replace more expensive Telex communications." Charter members of the VON Coalition include: VocalTec, Inc. (NASDAQ: VOCLF), Voxware Inc. , VDONet Corproation, Jabra Corporation, FreeTel Communications, Inc., The DSP Group (NASDAQ: DSPG), Insoft, White Pine Software, Netspeak Corporation, Xing Technology Inc., IDT Corporation, GLOSAS/USA and GU/USA, and Electric Magic Company. Individuals and corporations interested joining the VON Coalition can visit the VON web site at http://www.von.org/. Anyone interested in submitting individual comments to the FCC may do so by writing to: Federal Communications Commission 1919 M Street Washington, DC 20554 All responses to the FCC should include a reference to Rulemaking No. 8775. The FCC's website is http://www.fcc.gov. -0- 3/18/96 /CONTACT: Sandy Combs, Director, VON Coalition, 802-878-9884 or / From rem-conf-request@es.net Wed Mar 20 10:49:04 1996 Received: from lpsmail.ksc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 20 Mar 1996 07:48:34 -0800 Received: from tenet.ksc.nasa.gov (smtpgw [163.206.51.100]) by lpsmail.ksc.nasa.gov (8.6.12/8.6.12) with SMTP id KAA34511; Wed, 20 Mar 1996 10:48:25 -0500 Received: by tenet.ksc.nasa.gov with Microsoft Mail id <315052F3@tenet.ksc.nasa.gov>; Wed, 20 Mar 96 10:48:19 PST From: "Kyramarios, Steve N" To: Rem-Conf Cc: Fred Rounds , Dan Machak , "Brown, Charles T" Subject: Pre-Flight coverage of STS-76 Date: Wed, 20 Mar 96 10:43:00 PST Message-ID: <315052F3@tenet.ksc.nasa.gov> Encoding: 18 TEXT X-Mailer: Microsoft Mail V3.0 In support of the NASA-Ames Shuttle coverage, KSC is providing the Mbone community with pre-launch video. This video coverage consists of a sequence of shots looking at the shuttle. The present configuration has a 15 second cycle that switches between four camera views i.e. Overall pad shot, White room, External tank, and Remote service structure. The video stream for the pre-launch coverage has been set to 64K in an effort to conserve bandwidth. In addition, there will be no audio until NASA Select begins its coverage, which is approximate 3 to 4 hours prior to launch. In order to provide the best possible service, please direct your comments, pretaining to this service, to "kyramarios@cidnet.ksc.nasa.gov". For comments regarding flight coverage, please continue to direct all comment to Mr. Paden at "garyp@nren-vod.arc.nasa.gov". thanks, steve kyramarios/ksc From rem-conf-request@es.net Wed Mar 20 22:38:36 1996 Received: from postoffice.reston.mci.net by osi-west.es.net with ESnet SMTP (PP); Wed, 20 Mar 1996 19:38:02 -0800 Received: from localhost (it.Reston.mci.net [204.70.128.10]) by postoffice.reston.mci.net (8.6.12/8.6.6) with ESMTP id WAA12011; Wed, 20 Mar 1996 22:37:41 -0500 Message-Id: <199603210337.WAA12011@postoffice.reston.mci.net> To: Mike Macedonia cc: rem-conf@es.net, mbone@isi.edu Subject: Re: MCI to offer video services over the Internet In-reply-to: Your message of "Tue, 19 Mar 1996 09:39:05 EST." Date: Wed, 20 Mar 1996 22:36:30 -0500 From: Jeff Young this may just be marketspeak for the work that we've done on the mbone. i honestly don't know of a product that will be announced, nor am i aware of any effort to bring commercial videoconferencing to the internet. but then, i don't speak on behalf of mci. Jeff Young young@mci.net > Return-Path: mmacedon@crcg.edu > Received: from elaine.crcg.edu (elaine.crcg.edu [199.0.94.1]) by postoffice.reston.mci.net (8.6.12/8.6.6) with SMTP id JAA26524 for ; Tue, 19 Mar 1996 09:38:47 -0500 > Received: by elaine.crcg.edu (4.1/SMI-4.1) > id AA27171; Tue, 19 Mar 96 09:39:06 EST > Date: Tue, 19 Mar 1996 09:39:05 -0500 (EST) > From: Mike Macedonia > X-Sender: mmacedon@elaine > To: Jeff Young > Cc: rem-conf@es.net, mbone@isi.edu > Subject: Re: MCI to offer video services over the Internet > In-Reply-To: <199603191333.IAA25498@postoffice.reston.mci.net> > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > Jeff, > > See http://www.mci.com/virtual/news-news/top-headline-827152577.html > > >From the release: > > MCI also announced it has formed an advanced applications unit to focus on > developing emerging Internet applications for its customers. The new unit > will report to Fred Briggs, MCI's chief engineering officer, and Vint > Cerf, MCI's senior vice president of data architecture. A few of the > technologies under development include the use of direct broadcast > satellite for high-speed Internet connectivity, ** videoconferencing over the > Internet **, shared applications, multi-media messaging and advanced > security. > > > ----------------------------------------------------------------- > | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | > | Vice President | EMAIL: mmacedon@crcg.edu | > | Fraunhofer CRCG | | > | 167 Angell Street | PH : (+1) 401 453-6363 | > | Providence, RI 02906 | FAX: (+1) 401 453-0444 | > ----------------------------------------------------------------- > > > On Tue, 19 Mar 1996, Jeff Young wrote: > > > i don't honestly know. where did you see the press release? > > no one has approached us about using the multicast backbone > > for videoconferencing... > > > > Jeff Young > > young@mci.net > > > > > > > Return-Path: majordom@ISI.EDU > > > Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by postoffice.reston.mci.net (8.6.12/8.6.6) with SMTP id GAA24552; Tue, 19 Mar 1996 06:47:24 -0500 > > > Received: by zephyr.isi.edu (5.65c/5.61+local-20) > > > id ; Tue, 19 Mar 1996 03:26:15 -0800 > > > Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20) > > > id ; Tue, 19 Mar 1996 03:26:14 -0800 > > > Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-22) > > > id ; Tue, 19 Mar 1996 03:26:13 -0800 > > > Received: by zephyr.isi.edu (5.65c/5.61+local-20) > > > id ; Tue, 19 Mar 1996 03:25:28 -0800 > > > Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20) > > > id ; Tue, 19 Mar 1996 03:25:25 -0800 > > > Received: from elaine.crcg.edu by venera.isi.edu (5.65c/5.61+local-22) > > > id ; Tue, 19 Mar 1996 03:25:23 -0800 > > > Received: from condor.crcg.edu by elaine.crcg.edu (4.1/SMI-4.1) > > > id AA26303; Tue, 19 Mar 96 06:25:27 EST > > > Received: by condor.crcg.edu (940816.SGI.8.6.9/SMI-4.0) > > > id FAA29715; Tue, 19 Mar 1996 05:56:17 -0500 > > > Date: Tue, 19 Mar 1996 05:56:17 +30000 > > > From: Mike Macedonia > > > X-Sender: mmacedon@condor > > > To: rem-conf@es.net > > > Cc: cu-seeme-l@cornell.edu, mbone@ISI.EDU, videophone@es.net > > > Subject: MCI to offer video services over the Internet > > > In-Reply-To: <199603190732.XAA27870@ix2.ix.netcom.com> > > > Message-Id: > > > Mime-Version: 1.0 > > > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > Sender: owner-mbone-na@ISI.EDU > > > Precedence: bulk > > > > > > > > > MCI says in a news article that it will include videoconferencing as > > > part of its new Internet services. > > > > > > Does anyone have any details? Does this mean multicast? > > > > > > ----------------------------------------------------------------- > > > | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | > > > | Vice President | EMAIL: mmacedon@crcg.edu | > > > | Fraunhofer CRCG | | > > > | 167 Angell Street | PH : (+1) 401 453-6363 | > > > | Providence, RI 02906 | FAX: (+1) 401 453-0444 | > > > ----------------------------------------------------------------- > > > > > > > > > > From rem-conf-request@es.net Thu Mar 21 10:15:20 1996 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 21 Mar 1996 07:14:33 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id HAA04856; Thu, 21 Mar 1996 07:16:44 -0800 Message-Id: <199603211516.HAA04856@rx7.ee.lbl.gov> To: richter@ro2.informatik.uni-hamburg.de (Jan-Peter Richter) cc: rem-conf@es.net Subject: Re: bug?:VideoPix/Vic2.7a26/PAL/h.261 In-reply-to: Your message of Tue, 16 Jan 96 11:59:10 N. Date: Thu, 21 Mar 96 07:16:43 PST From: Van Jacobson > I have some trouble using a (PAL-) color videocamera and a > VideoPix video capture board with VIC v 2.7a26. Whenever I use > the h.261 encoding the picture turns orange at the top and green > at the bottom but there are no true colors. Using grayscale by > deselecting "color" in the main vic window or using color with > one of the other encodings (nv, nvdct and cellb) works just > fine. It seems to me that the software does not recognize the > PAL color signal correctly in h.261 mode. Is this a known bug? > Is there a known fix? Thank you for the bug report. This problem should be fixed in vic-2.7a38 which is now available at ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test/ BTW, the vic bug report address is vic@ee.lbl.gov. - Van From rem-conf-request@es.net Thu Mar 21 10:59:35 1996 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 21 Mar 1996 07:59:01 -0800 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id IAA04895; Thu, 21 Mar 1996 08:00:27 -0800 Message-Id: <199603211600.IAA04895@rx7.ee.lbl.gov> To: Jakob.Ellerstedt@eua.ericsson.se cc: rem-conf@es.net Subject: Re: Info on vic SW architecture wanted In-reply-to: Your message of Mon, 04 Mar 96 13:55:11 N. Date: Thu, 21 Mar 96 08:00:26 PST From: Van Jacobson > Well, I have tried to contact tehm about their code, escpecially the > framegrabbing part > where they got some non-disclosure info from SUN how to grab frame without > using > the XIL-library. I asked to get the function > prototypes, but no answer was received. Merely using the XIL-library doesn't > provide one with a good solution. Jakob, There appear to be a number of misunderstandings here. First, we do not disclose information that we received under non-disclosure. If there is any ambiguity about what is or is not covered by a non-disclosure agreement, we always err on the side of caution. Second, there are no "function prototypes" at this level of interface -- the API only exists at the XIL level. Below that there are only hundreds of nasty details about what bits you have to set when to sequence & load the board, what magic numbers you have to drop in magic places for the microcode to function, etc. You cannot talk directly to the board without knowing all this information but it is exactly what we agreed not to disclose. Finally, I receive an average of 300 email messages a day. Long ago I realized that there was a binary choice between answering them & doing useful work and I decided I'd rather work. So a lot of messages don't get answered. And requests for disclosure of proprietary, complex interfaces don't tend to be on the front of the list. On a more positive note, Sun asked us not to disclose the information but they were not trying to be obstructionist: they want to make the RTVC information available as badly as we do but they have some legitimate intellectual property questions to resolve. We first approached them about releasing the RTVC grabber source a little over a year ago and they have been working to make it possible since. About two weeks ago they gave us the go ahead. So, I'm pleased to let you know that the source of our SunVideo grabber is now included in the vic source distribution available at ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test/vicsrc-2.7a38.tar.gz - Van From rem-conf-request@es.net Thu Mar 21 13:04:44 1996 Received: from anchor.cs.colorado.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 21 Mar 1996 10:03:33 -0800 Received: (from evi@localhost) by anchor.cs.colorado.edu (8.7.5/8.7.3) id LAA17542; Thu, 21 Mar 1996 11:03:28 -0700 (MST) Date: Thu, 21 Mar 1996 11:03:28 -0700 (MST) From: Evi Nemeth Message-Id: <199603211803.LAA17542@anchor.cs.colorado.edu> To: rem-conf@es.net Subject: Univ of Colorado, CS Colloquium, Thurs 3:30pm MST Cc: evi@anchor.cs.colorado.edu University of Colorado, Computer Science Department Colloquium Series, 3:30PM, MST (GMT-7). We will be broadcasting audio and video (vic 2.7). Musical Instruments, Models, and Machines Neil Gershenfeld, Prof. Physics & Media Group MIT Media Lab Cambridge, MA A traditional musical instrument is an analog computer that integrates equations of motion based on applied boundary conditions. We are approaching a remarkable time when advances in transducers, real-time computing, and mathematical modeling will enable new technology to emulate and generalize the physics of great musical instruments >from first principles, helping virtuosic musicians to do more and non-musicians to engage in creative expression. I will discuss the underlying problems, including non-contact sensing and state reconstruction for nonlinear systems, describe exploratory performance collaborations with artists ranging from Yo-Yo Ma to Penn & Teller, and then consider the broader implications of these devices for the interaction between people and machines in new applications such as smart furniture and intra-body signaling. From rem-conf-request@es.net Thu Mar 21 14:42:13 1996 Received: from maelstrom.cc.mcgill.ca by osi-west.es.net with ESnet SMTP (PP); Thu, 21 Mar 1996 11:41:30 -0800 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id OAA04874; Thu, 21 Mar 1996 14:42:47 -0500 (EST) Message-Id: <199603211942.OAA04874@maelstrom.cc.mcgill.ca> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Original-Received: by NeXT.Mailer (1.118.2) PP-warning: Illegal Received field on preceding line From: Yves Lepage Date: Thu, 21 Mar 96 14:42:45 -0500 To: mbone@isi.edu, rem-conf@es.net Subject: New MBone book Reply-To: yves@cc.mcgill.ca Hi all, I would like to plug a new book (of which I am a co-author, so that's a motivated plug) about the MBone: MBone: Multicasting Tomorrow's Internet by Kevin Savetz, Neil Randall, and Yves Lepage ISBN: 1-56884-723-8 Published by IDG Books Worldwide, Inc. An International Data Group Company 919 E. Hillsdale Blvd., Suite 400, Foster City, CA 94404 You can check the promo pages at http://www.northcoast.com/savetz/mbone This page contains a link to IDG's homepage. The intended audience for that book is people who heard about the MBone and want to know more about it, what it is, how to get on it, etc... How to create your own events, what rules must be followed (Do not flood the MBONE with 400kbps of video), what software to use etc... The book has also been made suitable for ISP's who would like to offer MBONE services to their customers and would like to have more know-how. The writing also takes into consideration, those sites who don't have a high speed link to the Internet and want to know if they can use the technology for their own use or if they have a high speed link, how the MBone can be useful to them. Basicly, it is a book that will serve as guidance for the first steps into this other universe which is the MBone. Things are explained in a way that (I think) breaks the old paradigm from the FAQ that says "you gotta be a network guru if you want to get onto the MBone". The book also is technical enough so that for example, an ISP will be able to setp itself up with an MBONE router and be able to provides MBone services to its customers, and be able to charge for it. Finally, as I discovered while writing that part of the book, understanding the what and how of administrative scopes wasn't a totally easy job. :-) I've put it all in this book, what they are, what they can do for you, how they interact with SDR and how to set them up. I won't abuse so that's it. :-) Regards, Yves Lepage From rem-conf-request@es.net Thu Mar 21 15:36:21 1996 Received: from rags.rutgers.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 21 Mar 1996 12:35:02 -0800 Received: (from badri@localhost) by rags.rutgers.edu (8.6.12+bestmx+oldruq+newsunq/8.6.12) id PAA03255; Thu, 21 Mar 1996 15:28:49 -0500 Date: Thu, 21 Mar 1996 15:28:49 -0500 From: Br Badrinath Message-Id: <199603212028.PAA03255@rags.rutgers.edu> To: ieeetcpc@ccvm.sunysb.edu, orcs-l%osuvm1.BITNET@searn.sunet.se, glynn@leland.stanford.edu, ietf-announce@cnri.reston.va.us, mobile-ip , f-troup@aurora.cis.upenn.edu, rem-conf-request@es.net, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, arpanet-bboard@mc.lcs.mit.edu, cnom@meatro.bellcore.com, globecom@signet.com.sig, ietf@isi.edu, tccc@cs.umass.edu Subject: Call for Papers ------------------------------------------------------------------ | SECOND ACM/IEEE INTERNATIONAL CONFERENCE | | ON | | MOBILE COMPUTING AND NETWORKING 1996 | | | | (ACM/IEEE MobiCom'96) | | | | November 11-12, 1996 (Tutorials on Sunday, November 10, 1996 | | Rye Hilton, Rye, New York, USA | | | | Sponsored by: | | | | ACM CESDIS NASA IEEE | | Sigcomm, Sigmetrics, ComSoc | | Sigops, Sigact | ------------------------------------------------------------------ The wireless communication revolution is bringing fundamental changes to telecommunication and computing. Wide-area cellular systems and wireless LANs promise to make integrated networks a reality and provide fully distributed and ubiquitous mobile computing and communications, thus bringing an end to the tyranny of geography. Furthermore, services for the mobile user are maturing and are poised to change the nature and scope of communication. This conference, the second of an annual series, serves as the premier international forum addressing networks, systems, algorithms, and applications that support the symbiosis of portable computers and wireless networks. PAPERS Technical papers describing previously unpublished, original, completed, and not currently under review by another conference or journal are solicited on topics at the link layer and above. Topics will include, but are not limited to: * Applications and computing services supporting the mobile user. * Network architectures, protocols or service algorithms to cope with mobility, limited bandwidth, or intermittent connectivity. * Design and analysis of algorithms for online and mobile environments. * Mobile network protocols * Performance characterization of mobile/wireless networks and systems. * Network management for mobile and wireless networks. * Data management in mobile computing * Service integration and interworking of wired and wireless networks. * Characterization of the influence of lower layers on the design and performance of higher layers. * Security, scalability and reliability issues for mobile/wireless systems * Mobile computing * Mobile agents * Power management * Wireless multimedia systems * Satellite communication * Location-dependent applications * Distributed system aspects of mobile systems * Adaptive applications interfaces suitable for mobile systems * Architectures of wireless and mobile networks and systems * Traffic integration for mobile applications All papers will be refereed by the program committee. Accepted papers will be published in conference proceedings. Papers of particular merit will be selected for publication in the ACM/Baltzer Journal on Wireless Networks and the ACM/Baltzer Mobile Networks & Nomadic Applications Journal. HOW TO SUBMIT Paper submission will be handled electronically. Authors should Email a PostScript version of their full paper to: mobicom96@gucci.mirc.gatech.edu This Email address will become operational on March 1, 1996. In order to print the PS versions of the papers, authors should ensure that their papers meet these restrictions: - PostScript version 2 or later - no longer than 15 pages - fits properly on "US Letter" size paper (8.5x11 inches) - reference only Computer Modern or standard Adobe fonts (i.e., Courier, Times Roman, or Helvetica); other fonts may be used but must be included in the PostScript file In addition, authors should separately Email the title, author names, full address and abstract of their paper to the program chairs. All submitted papers will be judged based on their quality through double-blind reviewing where the identities of the authors are withheld from the reviewers. Authors' names should not appear on the paper or in the postscript file. TUTORIALS Proposals for tutorials are solicited. Evaluation of the proposals will be based on expertise and experience of instructors, and the relevance of the subject matter. Potential instructors are requested to submit at most 5 pages, including a biographical sketch to Arvind Krishna (krishna@watson.ibm.com). PANELS Panels are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed more than 3 pages, including biographical sketches of the panelist. Potential panel organizers should contact Tom LaPorta (tlp@boole.att.com). STUDENT PARTICIPATION Papers with a student as a primary author will enter a student paper award competition. The student will receive a cash award of $500,- US Dollars. A cover letter must identify the paper as a candidate for the student paper competition. IMPORTANT DATES Submissions due: May 1, 1996 Notification of acceptance: July 15, 1996 Camera-ready version due: August 31, 1996 For More Information: Please contact Ian F. Akyildiz (ian@ee.gatech.edu) or Zygmunt J. Haas (zjh1@cornell.edu), the Program Co-Chairs. WWW/GOPHER INFORMATION This CFP and other ACM related activities may be found in http://info.acm.org/sigcomm/mobicom96 (for WWW browsers) +-------------------------------------------------------------------------+ GENERAL CO-CHAIRS: HAMID AHMADI RANDY KATZ IBM T. J. Watson Research Center Computer Science Division Room H3-C04 EECS Department P. O. Box 704 University of California Yorktown Heights, NY 10598 Berkeley, CA 94720-1776 Tel: 914-784-7219 Tel.: 510-642-8778 Fax: 914-784-6205 Fax.: 510-642-5775 Email: hamid@watson.ibm.com Email: randy@cs.Berkeley.edu PROGRAM CO-CHAIRS IAN F. AKYILDIZ ZYGMUNT J. HAAS School of ECE School of Electrical Engineering Georgia Tech Cornell University Atlanta, GA, 30332 Ithaca, N.Y. 14853 Tel.: 404-894-5141 Tel.: 607-255-3454 Fax.: 404-894-5028 Fax.: 607-255-9072 Email: ian@ee.gatech.edu Email: zjh1@cornell.edu TUTORIAL CHAIR LOCAL CHAIR ARVIND KRISHNA BOB FLYNN, Polytechnic University IBM T.J. Watson Research Center P.O. Box 704, H3-D32 VICE CHAIR Yorktown Heights, NY 10598 TOM LaPORTA, AT&T Bell Labs Tel.: (914) 784-7965 Fax.: (914) 784-6205 PUBLICITY CHAIR Email: krishna@watson.ibm.com B.R. BADRINATH, Rutgers Univ. TREASURER STEERING COMMITTEE CHAIR RAJIV JAIN, Bellcore IMRICH CHLAMTAC, Boston Univ. PROGRAM COMMITTEE Rafael Alonso, Matsushita Labs Victor Bahl, DEC Brian Bershad, U. of Washington Ramon Caceres, AT&T Imrich Chlamtac, Boston U. Tony Dahbura, Motorola John Daigle, U. of Mississippi Maurizio Decina, CEFRIEL JJ Garcia Luna, UC Santa Cruz Mario Gerla, UCLA Peter Honeyman, U. of Michigan Pierre Humblet, Eurecom Tom Imilienski, Rutgers U. David Johnson, CMU Phil Karn, Qualcomm Mark Karol, AT&T Jay Kistler, DEC Barry Leiner, ARPA Jason Ying Bin Lin, NCTU Teresa Meng, Stanford U. Mahmoud Naghshineh, IBM TJ Peter O'Reilly, GTE Labs Charlie Perkins, IBM TJ Ray Pickholtz, GWU Dhiraj Pradhan, Texas A&M Chris Rose, Rutgers U. Krishan Sabnani, AT&T Mischa Schwartz, Columbia U. Martha Steenstrup, BBN Gordon Stuber, GaTech David Tennenhouse, MIT Marvin Theimer, XEROX Mehmet Ulema, Bellcore Newman Wilson, D. Sarnoff RC Parviz Yegani, Qualcomm From rem-conf-request@es.net Thu Mar 21 18:40:31 1996 Received: from ns.gte.com by osi-west.es.net with ESnet SMTP (PP); Thu, 21 Mar 1996 15:39:39 -0800 Received: from popserver.gte.com by ns.gte.com (8.6.10/8.6.10) id SAA07929; Thu, 21 Mar 1996 18:32:39 -0500 Received: from [132.197.70.52] by popserver.gte.com (8.6.9/8.6.9) with SMTP id SAA00431; Thu, 21 Mar 1996 18:32:07 -0500 Date: Thu, 21 Mar 1996 18:32:07 -0500 Message-Id: <199603212332.SAA00431@popserver.gte.com> X-Sender: bk00@pophost.gte.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atm-list@csc.com, perform@tay1.dec.com, end2end-interest@isi.edu, ietf@isi.edu, rem-conf@es.net, announcements.chi@Xerox.com, arl@arl1.wustl.edu, atm@BBN.COM, cip@BBN.COM, cnom@maestro.bellcore.com, ccrc@dworkin.wustl.edu, enternet-ec@BBN.COM, enternet@BBN.COM, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, globecom@signet.com.sg, hipparch@sophia.inria.fr, icad-request@santafe.edu, iplpdn@cnri.reston.va.us, sigmedia@bellcore.com, smds@cnri.reston.va.us, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-a, uist.chi@Xerox.com, xtp-relay@cs.concordia.ca, tsuzuki@ccsd.ho.nec.co.jp, Faouzi.Daoud@prism.uvsq.fr, fad@prism.uvsq.fr, chuanyi@ecse.rpi.edu, yoshida@rosso.mss.netwk.ntt-at.co.jp, bumblis@mcc.com, rdantu@tddcae99.fnts.com, bhumip@gte.com, scott_linke@aus.hp.com, pradeep@dstc.uts.edu.au, guthery@austin.sar.slb.com, paulcov@bnr.ca, mohan@ccmail.inet.com, lewis@ctron.com, clytle@sed.stel.com, bobchap@ibm.net, oliveira@eurecom.fr, sidou@eurecom.fr, labetoul@eurecom.fr, dotti@fokus.gmd.de, enternet-ec@BBN.COM, jandre@imtn.tpd.dsccc.com, prabhu@ee.uta.edu, vik@ihades.att.com, g.weisman@ieee.org, waisum@buckaroo.ho.att.com, ahmadi@engn.uwindsor.ca, braudyb@aol.com, rlfike@aol.com, david.kirsch@east.sun.com, dkirsch@east.sun.com, bran@silcom.com, just4net@aol.com, murase@nwk.cl.nec.co.jp, 100765.3267@compuserve.com, sikama@hat.hon.melco.co.jp, kseo@BBN.COM, kpogran@BBN.COM, w2xd@mrspock.mt.att.com, aidarous@bnr.ca, kjl@bellcore.com, bhumip@gte.com, sbw@ccrl.nj.nec.com, 21STLCN-PC@VM1.NODAK.EDU, nfonseca@dcc.unicamp.br, ian@armani.mirc.gatech.edu, zjh1@cornell.edu, m.zukerman@trl.oz.au, sohraby@cstp.umkc.edu, ray@ccrl.nj.nec.com, jpgs@gte.com, rchoen@csa.cs.technion.ac.il From: bhumip@gte.com (Dr Bhumip Khasnabish +1-617-466-2080) Subject: Advance Program of Enterprise Networking Workshop,1996 (ENW-96) Cc: bk00@gte.com Enterprise Networking Workshop (ENW-96) - Advance Program Thursday, June 27, 1996 (in Conjunction with the ICC/SUPERCOMM'96) Dallas Convention Center, Dallas, Texas, USA Sponsored by the IEEE Communications Society's Technical Committee on Enterprise Networking (EnterNet, enternet@bbn.com) [To join EnterNet, send request to enternet-request@bbn.com, Visit EnterNet's Web Page at http://www.bbn.com/enternet/ ] Program Chair: Bhumip Khasnabish (bhumip@gte.com),GTE Labs.Inc.,USA. Program Committee: Majid Ahmadi (ahmadi@engn.uwindsor.ca), U of Windsor,Canada Salah Aidarous (aidarous@bnr.ca), BNR, Canada Robert S. Braudy (braudyb@aol.com), BTG, LLC, USA Bob Fike (rlfike@aol.com), RNF Systems, USA David Kirsch (just4net@aol.com), NDC, USA Ken Lutz (kjl@bellcore.com), BellCore, USA Branislav Meandzija (bran@silcom.com), GI, USA Totumo Murase (murase@nwk.cl.nec.co.jp), NEC, Japan Toshihiro Sikama (100765.3267@compuserve.com), Mitsubishi, France Karen Seo (kseo@bbn.com), BBN, USA Steven Weinstein (sbw@ccrl.nj.nec.com), NEC, USA Douglas N. Zuckerman (w2xd@mtnms.att.com), AT&T, USA ======================The Program ============================ ______________________________________________________ 08:00 am to 09:45 am AM-1: Experience with and Current Challenges of the ENs Session Chairs: David Kirsch,NDC USA and Majid Ahmadi U. Windsor, Canada ____________________________________________________ AM-1.1: The Effect of Network Loading due to Client-Server Applications and Application Development by Joseph R. Bumblis (bumblis@mcc.com), Microelectronics & Comp. Tech. Co., USA. AM-1.2: Traffic Management in an Enterprise Networking Switch: Few Case Studies by Ram Dantu (rdantu@tddcae99.fnts.com) et al, Fujitsu, Texas, USA. AM-1.3: Interworking with ATM - What to test for ! by Scott Linke (scott_linke@aus.hp.com), Hewlett-Packard Co., Australia. AM-1.4: Evaluation Criteria for Enterprise Network Management Systems by Pradeep Ray (pradeep@dstc.uts.edu.au) et al, University of Technology, Australia. ______________________________________________________ 09:45 am to 10:00 am - Coffee Break ___________________________________________________ 10:00 am to 11:15 am AM-2: Future Directions of ENs and Integration with Emerging Technologies/Services Session Chairs: Steve Weinstein, NEC USA and Ken Pogran, BBN USA. ____________________________________________________ AM-2.1: Wireless Relay Networks by Scott Guthery (guthery@austin.sar.slb.com), Schlumberger Austin Product Center, USA. AM-2.2: Voice Quality in Enterprise Networks by Paul Coverdale (paulcov@bnr.ca), NorTel Technology (BNR) Canada. AM-2.3: Designing the Enterprise Networks for Multimedia Telecollaboration by K. S. Ram Mohan (mohan@ccmail.inet.com), I-NET, USA. _____________________________________________________ 11:15 am to 03:00 pm (including Lunch from noon to 01:00 pm) Panel of the ENW-96: Outsourcing Enterprise Networking Services - Concerns of Users and Service Providers Moderator: Robert S. Braudy of the B.T.G., LLC, NJ, USA. ______________________________________________________ Speakers: 1. Dieter Muernseer, Muernseer Associates GMBH, Germany. 2. T. Travers Waltrip, TravCo, USA. 3. Kazuyoshi Morino, Sen. Engineer of Network Planning Dept., NTT, Japan. 4. Walter Sing, Vice President of the CMP Publications, USA. 5. Tom DeCanio, Vice President of the Chase Manhattan Bank, USA. 6. Robert L. Waid, Division VP, Industry Management, Infrastructure Services Communications Group, EDS, USA. 7. Brian Maloney, Client Partner, AT&T Communications Solutions, USA. ______________________________________________________ 03:00 pm to 03:15 pm - Coffee Break ______________________________________________________ 03:15 pm to 05:30 pm PM-1: Outsourcing the Operations, Management and Design of ENs Session Chairs: Douglas N. Zuckerman, AT&T and Salah Aidarous, BNR Canada. ______________________________________________________ PM-1.1: Challenges Facing Network, Systems, and Enterprise Management Implementors, by Cathy Lytle (clytle@sed.stel.com), Stanford Telecommunication, Inc., USA. PM-1.2: Distributed Multi-Level Reasoning for Enterprise Network Management, by Lundy Lewis (lewis@ctron.com) and Jim Frey, Cabletron Systems, USA. PM-1.3: Customized network management based on applications requirements, by Raul Oliveira, Dominique Sidou and Jacques labetoulle, (oliveira@eurecom.fr, sidou@eurecom.fr, labetoul@eurecom.fr), Institut EURECOM, France. PM-1.4: Management Outsourcing in Open Distributed Environments, by Fernando Luis Dotti (dotti@fokus.gmd.de), Res. Inst for Open Sys., Germany. PM-1.5: Insourcing After the Outsource, by Robert Chapman (bobchap@ibm.net), Institute of Advanced Development Strategies, Inc., USA. ============================================================= Registration and Other Info. About ICC-96 and SuperComm-96 can be found at http://www-ee.uta.edu/organizations/commsoc/icc96home.html, and http://www.super-comm.com/ Thanks a lot, with all the best wishes and regards, --------------------------------------------------------------------- Dr. Bhumip Khasnabish, GTE Labs. Inc., Tel +1-617-466-2080 40 Sylvan Road, Fax +1-617-890-9320 Waltham MA 02254 Res +1-617-647-5356 U.S.A. E-Mail: bhumip@gte.com ..................................................................... Web Page within GTE Labs: http://cnsmacic.gte.com/users/bhumip/ ===================================================================== From rem-conf-request@es.net Fri Mar 22 00:55:59 1996 Received: from realtime.cc.missouri.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 21 Mar 1996 21:55:30 -0800 Received: from localhost (ccshag@localhost) by realtime.cc.missouri.edu (8.7.1/8.7.1) with SMTP id XAA12876; Thu, 21 Mar 1996 23:55:25 -0600 (CST) X-Authentication-Warning: realtime.cc.missouri.edu: ccshag owned process doing -bs Date: Thu, 21 Mar 1996 23:55:25 -0600 (CST) From: Paul 'Shag' Walmsley Sender: ccshag@cclabs.missouri.edu To: rem-conf@es.net Subject: Equinox - live audio feed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Friday, March 22, the "Equinox" electronic music dance event is taking place in Columbia, MO. Equinox will feature a variety of dance music styles, from straight house through breakbeats and drum and bass to live ex-scatological post-Electro. As part of the event, we are planning to multicast a direct GSM audio feed via vat over a 28.8kbps modem link to the MBONE at large. The event commences at 10PM CST (0400 Saturday Mar 23 GMT) and ends at 6AM CST (1000 Saturday Mar 23 GMT). The address will be 224.2.221.173 on port 54473 with a conference ID of 14890. James Cooper says, "So if you're sitting at your workstation and you're bored with your CDs, tune in." - Paul "Shag" Walmsley "Praise and blame alike mean nothing." -- Virginia Woolf P.S. apologies for the previous aborted message. From rem-conf-request@es.net Fri Mar 22 01:05:35 1996 Received: from realtime.cc.missouri.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 21 Mar 1996 22:05:03 -0800 Received: from localhost (ccshag@localhost) by realtime.cc.missouri.edu (8.7.1/8.7.1) with SMTP id XAA12834; Thu, 21 Mar 1996 23:32:11 -0600 (CST) X-Authentication-Warning: realtime.cc.missouri.edu: ccshag owned process doing -bs Date: Thu, 21 Mar 1996 23:32:11 -0600 (CST) From: Paul 'Shag' Walmsley Sender: ccshag@cclabs.missouri.edu To: rem-conf@es.net Subject: Equinox - live audio feed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Friday March 22, the electronic music dance event "Equinox" -- cx is taking place in Columbia, MO. - Paul "Shag" Walmsley "Praise and blame alike mean nothing." -- Virginia Woolf From rem-conf-request@es.net Fri Mar 22 18:27:39 1996 Received: from charlie-brown.cs.berkeley.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 22 Mar 1996 15:26:57 -0800 Received: (radhika@localhost) by charlie-brown.cs.berkeley.edu (8.6.10/8.3) id PAA05696; Fri, 22 Mar 1996 15:26:56 -0800 From: Radhika Malpani Message-Id: <199603222326.PAA05696@charlie-brown.cs.berkeley.edu> Subject: Simple Conference Control Protocol To: rem-conf@es.net Date: Fri, 22 Mar 1996 15:26:55 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 187 Hi, Would someone please direct me to information on the Simple Conference Control Protocol presented at the last IETF meeting in LA. Thanks, Radhika Malpani radhika@cs.berkeley.edu From rem-conf-request@es.net Fri Mar 22 21:20:55 1996 Received: from vlsi.cs.caltech.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 22 Mar 1996 18:20:14 -0800 Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1) id AA16497; Fri, 22 Mar 96 18:20:32 PST Date: Fri, 22 Mar 96 18:20:32 PST From: schooler@cs.caltech.edu (Eve Schooler) Message-Id: <9603230220.AA16497@vlsi.cs.caltech.edu> To: radhika@bugs-bunny.cs.berkeley.edu Subject: Re: Simple Conference Control Protocol Cc: rem-conf@es.net, schooler@cs.caltech.edu The minutes and slides from the MMusic WG meetings in LA (which include info on the Simple Conference Control Protocol) can be found at ftp://ftp.isi.edu/confctrl/minutes in the files ietf.3.96 and slides.3.96.{tar, tar.Z}. Eve From rem-conf-request@es.net Mon Mar 25 05:43:11 1996 Received: from cismsun.univ-lyon1.fr by osi-west.es.net with ESnet SMTP (PP); Mon, 25 Mar 1996 02:42:37 -0800 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id LAA01552 for rem-conf@es.net; Mon, 25 Mar 1996 11:42:28 +0100 Message-Id: <199603251042.LAA01552@cismsun.univ-lyon1.fr> Subject: MPEG/RTP/IP multicast appli? To: rem-conf@es.net Date: Mon, 25 Mar 1996 11:42:27 +0100 (MET) From: Lucia Gradinariu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 564 Hi, Is there any videoconference application able to send/receive MPEG1/RTPv1 or v2 packets on an IP multicast address (didn't find on RTP Home Page). Thanks for any pointer, -------------------------------------------------------------------------------- Lucia GRADINARIU, Eng. CISM-Univ. Cl. Bernard Lyon1 voice:(33).72.43.13.69 Bat. 101 Bd. du 11 Novembre 1918 fax:(33).72.44.84.10 69622 Villeurbanne FRANCE email:lucia@univ-lyon1.fr http://www.univ-lyon1.fr/CISM/lucia --------------------------------------------------------------------------------- From rem-conf-request@es.net Mon Mar 25 10:38:54 1996 Received: from xeno.ist.ucf.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 25 Mar 1996 07:38:13 -0800 Received: from ist_smtp.ist.ucf.edu by xeno.ist.ucf.edu (5.0/SMI-SVR4) id AA22671; Mon, 25 Mar 1996 10:37:56 +0500 Received: by ist_smtp.ist.ucf.edu with Microsoft Mail id <3156BE39@ist_smtp.ist.ucf.edu>; Mon, 25 Mar 96 10:39:37 EST From: "Myjak, Michael" To: majordom , Mike Macedonia Cc: mbone , rem-conf Subject: Re: MCI to offer video services over the Internet Date: Mon, 25 Mar 96 10:40:00 EST Message-Id: <3156BE39@ist_smtp.ist.ucf.edu> Encoding: 145 TEXT X-Mailer: Microsoft Mail V3.0 content-length: 5685 It would be nice, just for once, for the marketing folk to talk to the technical folk once in a while, if not just so the customer folk can know what's really going on. Mike, can you fax me a cc of that press release? I wonder whether this service, if it exists, can be used for other "multimedia" applications (like DIS). -- Michael Myjak Senior Research Scientist Institute for Simulation and Training University of Central Florida 3280 Progress Drive Orlando, Florida 32826 email: myjak@ist.ucf.edu voice: 407.658.5043 FAX: 407.658.5059 Off the keyboard, over the bridge, through the router... nothing but 'net! ---------- From: majordom To: Mike Macedonia Cc: rem-conf; mbone Subject: Re: MCI to offer video services over the Internet Date: Wednesday, March 20, 1996 10:36PM this may just be marketspeak for the work that we've done on the mbone. i honestly don't know of a product that will be announced, nor am i aware of any effort to bring commercial videoconferencing to the internet. but then, i don't speak on behalf of mci. Jeff Young young@mci.net > Return-Path: mmacedon@crcg.edu > Received: from elaine.crcg.edu (elaine.crcg.edu [199.0.94.1]) by postoffice.reston.mci.net (8.6.12/8.6.6) with SMTP id JAA26524 for ; Tue, 19 Mar 1996 09:38:47 -0500 > Received: by elaine.crcg.edu (4.1/SMI-4.1) > id AA27171; Tue, 19 Mar 96 09:39:06 EST > Date: Tue, 19 Mar 1996 09:39:05 -0500 (EST) > From: Mike Macedonia > X-Sender: mmacedon@elaine > To: Jeff Young > Cc: rem-conf@es.net, mbone@isi.edu > Subject: Re: MCI to offer video services over the Internet > In-Reply-To: <199603191333.IAA25498@postoffice.reston.mci.net> > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > Jeff, > > See http://www.mci.com/virtual/news-news/top-headline-827152577.html > > >From the release: > > MCI also announced it has formed an advanced applications unit to focus on > developing emerging Internet applications for its customers. The new unit > will report to Fred Briggs, MCI's chief engineering officer, and Vint > Cerf, MCI's senior vice president of data architecture. A few of the > technologies under development include the use of direct broadcast > satellite for high-speed Internet connectivity, ** videoconferencing over the > Internet **, shared applications, multi-media messaging and advanced > security. > > > ----------------------------------------------------------------- > | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | > | Vice President | EMAIL: mmacedon@crcg.edu | > | Fraunhofer CRCG | | > | 167 Angell Street | PH : (+1) 401 453-6363 | > | Providence, RI 02906 | FAX: (+1) 401 453-0444 | > ----------------------------------------------------------------- > > > On Tue, 19 Mar 1996, Jeff Young wrote: > > > i don't honestly know. where did you see the press release? > > no one has approached us about using the multicast backbone > > for videoconferencing... > > > > Jeff Young > > young@mci.net > > > > > > > Return-Path: majordom@ISI.EDU > > > Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by postoffice.reston.mci.net (8.6.12/8.6.6) with SMTP id GAA24552; Tue, 19 Mar 1996 06:47:24 -0500 > > > Received: by zephyr.isi.edu (5.65c/5.61+local-20) > > > id ; Tue, 19 Mar 1996 03:26:15 -0800 > > > Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20) > > > id ; Tue, 19 Mar 1996 03:26:14 -0800 > > > Received: from zephyr.isi.edu by venera.isi.edu (5.65c/5.61+local-22) > > > id ; Tue, 19 Mar 1996 03:26:13 -0800 > > > Received: by zephyr.isi.edu (5.65c/5.61+local-20) > > > id ; Tue, 19 Mar 1996 03:25:28 -0800 > > > Received: from venera.isi.edu by zephyr.isi.edu (5.65c/5.61+local-20) > > > id ; Tue, 19 Mar 1996 03:25:25 -0800 > > > Received: from elaine.crcg.edu by venera.isi.edu (5.65c/5.61+local-22) > > > id ; Tue, 19 Mar 1996 03:25:23 -0800 > > > Received: from condor.crcg.edu by elaine.crcg.edu (4.1/SMI-4.1) > > > id AA26303; Tue, 19 Mar 96 06:25:27 EST > > > Received: by condor.crcg.edu (940816.SGI.8.6.9/SMI-4.0) > > > id FAA29715; Tue, 19 Mar 1996 05:56:17 -0500 > > > Date: Tue, 19 Mar 1996 05:56:17 +30000 > > > From: Mike Macedonia > > > X-Sender: mmacedon@condor > > > To: rem-conf@es.net > > > Cc: cu-seeme-l@cornell.edu, mbone@ISI.EDU, videophone@es.net > > > Subject: MCI to offer video services over the Internet > > > In-Reply-To: <199603190732.XAA27870@ix2.ix.netcom.com> > > > Message-Id: > > > Mime-Version: 1.0 > > > Content-Type: TEXT/PLAIN; charset=US-ASCII > > > Sender: owner-mbone-na@ISI.EDU > > > Precedence: bulk > > > > > > > > > MCI says in a news article that it will include videoconferencing as > > > part of its new Internet services. > > > > > > Does anyone have any details? Does this mean multicast? > > > > > > ----------------------------------------------------------------- > > > | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | > > > | Vice President | EMAIL: mmacedon@crcg.edu | > > > | Fraunhofer CRCG | | > > > | 167 Angell Street | PH : (+1) 401 453-6363 | > > > | Providence, RI 02906 | FAX: (+1) 401 453-0444 | > > > ----------------------------------------------------------------- > > > > > > > > > > From rem-conf-request@es.net Tue Mar 26 02:46:35 1996 Received: from cismsun.univ-lyon1.fr by osi-west.es.net with ESnet SMTP (PP); Mon, 25 Mar 1996 23:46:06 -0800 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id IAA29608; Tue, 26 Mar 1996 08:44:25 +0100 Message-Id: <199603260744.IAA29608@cismsun.univ-lyon1.fr> Subject: Re: MPEG/RTP/IP multicast appli? To: berc@pa.dec.com Date: Tue, 26 Mar 1996 08:44:25 +0100 (MET) From: Lucia Gradinariu Cc: rem-conf@es.net In-Reply-To: <9603251758.AA14744@bigpink.pa.dec.com> from "berc@pa.dec.com" at Mar 25, 96 09:58:22 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 905 > > > MPEG seems like a particularly poor choice of encoding for IP multicast. > The vic H.261 encoder is probably superior in all respects. > > lance > Thanks for your answer, I need such an applic. because I have a new TektroTX which has IPmulti and a brand new MPEG vplay listening on a port/IPmulti addr. to get RTP encapsulated packets! (no doc available, just waiting for Tek. support to send me one) Anyhow I was wandering about the applic. they used to test the client. The IPmulti seems to be OK. -------------------------------------------------------------------------------- Lucia GRADINARIU, Eng. CISM-Univ. Cl. Bernard Lyon1 voice:(33).72.43.13.69 Bat. 101 Bd. du 11 Novembre 1918 fax:(33).72.44.84.10 69622 Villeurbanne FRANCE email:lucia@univ-lyon1.fr http://www.univ-lyon1.fr/CISM/lucia --------------------------------------------------------------------------------- From rem-conf-request@es.net Tue Mar 26 05:12:34 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 26 Mar 1996 02:11:46 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA07658; Tue, 26 Mar 1996 02:11:44 -0800 Date: Tue, 26 Mar 1996 02:11:44 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: Transition to RTP audio on MBone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII [This note is sent to the rem-conf list where followups should go, but is blind-cc'd to the mbone list in case some folks are only there.] To the MBone Community: With the Real-time Transport Protocol (RTPv2) now published as Proposed Standard RFC 1889, it is time for us to make a significant transition and begin using RTP to carry audio on the MBone. As the chair of the IETF AVT working group, I'm sending this message to start the process and will continue to "evangelize" as needed. The key elements of this transition are: - running vat with the -r option to select RTPv2 - using the new UCL tool sdr as a replacement for sd to automatically invoke vat with that option. You should start running sdr now! The native "vat protocol" (sometimes referred to as RTPv0) that encapsulates the encoding formats implemented by the vat program has served well since 1992. However, vat version 4.0, which has been in alpha test for a few months, implements RTPv2 in addition to the native protocol and will use RTPv2 when started with the -r option. Note that the authors of vat and sd at LBL fully support this transition. The vat 4.0 documentation says: RTP is far superior to the original vat protocol and we hope it will soon become the default but in the interim we have to figure out the right sequence of tool deployment and sd/sdr changes to coordinate an orderly transition between the two protocols. We encourage experimenters to use RTP mode whenever possible. The transition from sd to sdr is necessary because the protocol implemented in sd and the .sd.tcl files _as deployed_ do not provide a means to specify the use of RTP and invoke vat with the -r option. The sdr program implements a second generation of the Session Directory Protocol (SDP) that can specify the use of RTP, and the sdr program chooses RTP as the default for audio when creating sessions. Besides, sdr implements a bunch of nicer features that the authors of sd have refrained from implementing because this transition was planned. What To Do ========== 1. Get sdr either from its home at UCL or the USA mirror site: ftp://cs.ucl.ac.uk/mice/sdr/ ftp://parcftp.xerox.com/pub/net-research/apps/sdr/ Binaries are there for 5 or 6 UNIX platforms. 2. Please start running sdr now so that you will see sessions using RTP audio that are only advertised in sdr. There is a gateway which listens to the global sd advertisements and retransmits them to sdr, so you don't need to run sd. 3. If you have an old (3.x) version of vat, it is definitely time to upgrade. Note that new versions of vat and vic, including binaries, have been posted in the past few days to: ftp://ftp.ee.lbl.gov/conferencing/vat/alpha-test ftp://ftp.ee.lbl.gov/conferencing/vic/alpha-test It is predicted that these programs will advance from alpha release status soon! 4. If you are transmitting a session, please help promote this transition by advertising your session with sdr rather than sd and using RTP (the default) for audio protocol (you may independently choose PCM, DVI or GSM encoding as before). If you send email about your session, mention that listeners should find it with sdr. I hope to see all events make this transition by the time of the next IETF meeting (late June). Try It Now ========== Hugh LaMaster at NASA was kind enough to create an RTP test session in sdr as a secondary channel for the current STS-76 shuttle mission and possibly contining next week with other NASA Select programming. You can use this session to make sure you've got all the necessary software in place and to test out the new features of sdr and of vat when operating in RTP mode. Note that this RTP test session will appear in sdr in addition to the STS-76 Audio and Video sessions that are gatewayed from sd. This secondary shuttle channel is being sent at low bandwidth (64kb/s for video, and GSM for audio) to conserve bandwith but also in response to requests from folks who wanted to be able to watch over 128kb/s ISDN lines. Comments welcome. -- Steve From rem-conf-request@es.net Wed Mar 27 09:20:34 1996 Received: from elaine.crcg.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 27 Mar 1996 06:19:56 -0800 Received: by elaine.crcg.edu (4.1/SMI-4.1) id AA11082; Wed, 27 Mar 96 09:17:11 EST Date: Wed, 27 Mar 1996 09:17:10 -0500 (EST) From: Mike Macedonia X-Sender: mmacedon@elaine To: tstaff@crcg.edu Cc: rem-conf@es.net, mbone@isi.edu Subject: intro to multicast routing Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=NextPart Content-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Wed, 27 Mar 96 08:51:38 -0500 From: Internet-Drafts@CNRI.Reston.VA.US To: IETF-Announce: ; Subject: I-D ACTION:draft-rfced-info-semeria-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Introduction to IP Multicast Routing Author(s) : C. Semeria, T. Maufer Filename : draft-rfced-info-semeria-00.txt Pages : 55 Date : 03/26/1996 The first part of this paper describes the benefits of multicasting, the MBONE, Class D addressing, and the operation of the Internet Group Management Protocol (IGMP). The second section explores a number of different algorithms that may potentially be employed by multicast routing protocols: - Flooding - Spanning Trees - Reverse Path Broadcasting (RPB) - Truncated Reverse Path Broadcasting (TRPB) - Reverse Path Multicasting (RPM) - Core Based Trees The third part contains the main body of the paper. It describes how the previous algorithms are implemented in multicast routing protocols available today. - Distance Vector Multicast Routing Protocol (DVMRP) - Multicast OSPF (MOSPF) - Protocol-Independent Multicast (PIM) 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-rfced-info-semeria-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-rfced-info-semeria-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) 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-rfced-info-semeria-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 Content-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ds.internic.net" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-rfced-info-semeria-00.txt"; SITE="ds.internic.net"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- From rem-conf-request@es.net Wed Mar 27 11:57:03 1996 Received: from maelstrom.cc.mcgill.ca by osi-west.es.net with ESnet SMTP (PP); Wed, 27 Mar 1996 08:56:21 -0800 Received: (from yves@localhost) by maelstrom.cc.mcgill.ca (8.7.1/8.6.6) id LAA28413; Wed, 27 Mar 1996 11:57:53 -0500 (EST) Message-Id: <199603271657.LAA28413@maelstrom.cc.mcgill.ca> Content-Type: text/plain MIME-Version: 1.0 (NeXT Mail 3.3 v118.2) Original-Received: by NeXT.Mailer (1.118.2) PP-warning: Illegal Received field on preceding line From: Yves Lepage Date: Wed, 27 Mar 96 11:57:50 -0500 To: mbone@isi.edu, rem-conf@es.net Subject: SDR for NeXT Reply-To: yves@cc.mcgill.ca Hi all, I'd like to announce that I've finally found the time to port SDR to the NeXT. I only have an m68k version for now. Being able to produce quad-fat binaries will require some more efforts as I will have to install everything for all 4 archs (tcl/tk, libs, X libs etc...). You can find the m68k version at: ftp://ftp.mcgill.ca/pub/systems/NeXT/mbone SDR is there along with nv and sd_listen. You'll of course need to have an X server running on your machine to be able to profit from these MBone apps. My next project will be vic2.7. Have fun. Yves Lepage From rem-conf-request@es.net Wed Mar 27 12:07:22 1996 Received: from timbuk.cray.com by osi-west.es.net with ESnet SMTP (PP); Wed, 27 Mar 1996 09:06:35 -0800 Received: from nothing.cray.com (daw@nothing.cray.com [128.162.123.35]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id LAA09077 for ; Wed, 27 Mar 1996 11:04:23 -0600 Received: by nothing.cray.com id AA00516; 5.0/CRI-5.6; Wed, 27 Mar 1996 11:04:18 -0600 From: daw@tngstar.cray.com (Dave Wright) Message-Id: <9603271704.AA00516@nothing.cray.com> Subject: Re: Transition to RTP audio on MBone To: casner@precept.com (Stephen Casner) Date: Wed, 27 Mar 1996 11:04:15 -0600 (CST) Cc: rem-conf@es.net, tat@pandora.cray.com In-Reply-To: from "Stephen Casner" at Mar 26, 96 02:11:44 am X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 2424 Hello Mbone Participants, With the recent email about upgrading to the newest SDR, vat, vic I have several problems to note. Right now these are show stoppers from US using Mbone. First our environment is Sun Sparc 5 with a Parallax Xvideo board. We are running Solaris 2.3 and don't know if we will upgrade to Solaris 2.4 or switch to SGI Indy's with IRIX with the CRAY/SGI merger. Problem #1: vat 4.0a8 Our old vat was flakey and breaks up alot but did work. I have not yet gotten vat to work. I do get noise for a second and then no audio. This is both in transmit and receiving the Test RTP - ARC Digital Video - NASA TV signal. I can get video but not audio. Same is true with the session NASA Shuttle Mission STS-76. Problem #2: sdr v2.1a12 I often get sdr to give an error window though things do seem to start up. When I click on the session I wish to watch I often get a window that says: Error in TCl Script Error: bad window path name ".descb67de9bd" Problem #3: vic 2.7a38 with the parallax board I often have Sparc 5 system crashes and reboots. I do get a core file in my home directory after bringing the system back up. Parallax has a vic support person but his works fine as well. Problem #4 : mrouted 2.2 mrouted is filling our /var/adm/messages filesystem with lots of messages: Jan 29 17:23:30 tngstar mrouted[320]: warning - 128.162.18.1 reports an invalid origin (193.232.72.0) and/or mask (fffff800) Jan 29 17:23:30 tngstar mrouted[320]: warning - 128.162.18.1 reports an invalid origin (194.85.64.0) and/or mask (fffff800) Jan 29 17:23:30 tngstar mrouted[320]: warning - 128.162.18.1 reports an invalid origin (194.85.104.0) and/or mask (fffff800) Jan 29 17:23:30 tngstar mrouted[320]: warning - 128.162.18.1 reports an invalid origin (194.85.240.0) and/or mask (fffff800) Jan 29 17:23:30 tngstar mrouted[320]: warning - 128.162.18.1 reports an invalid origin (194.88.0.0) and/or mask (fffff800) Jan 29 17:23:30 tngstar mrouted[320]: warning - 128.162.18.1 reports an invalid origin (194.135.176.0) and/or mask (fffff800) Jan 29 17:23:30 tngstar mrouted[320]: warning - 128.162.18.1 reports an invalid origin (194.190.160.0) and/or mask (fffff800) We wanted to run mrouted 3.8 but no luck at all. PS I am not the sysadmin for the router and don't have what the error message was. Can anyone offer help with these problems before the tools go into Beta test? Dave Wright Software Instructor From rem-conf-request@es.net Wed Mar 27 15:00:56 1996 Received: from gw2.att.com by osi-west.es.net with ESnet SMTP (PP); Wed, 27 Mar 1996 12:00:18 -0800 Received: from arch4.ho.att.com by ig1.att.att.com id AA12212; Wed, 27 Mar 96 14:57:27 EST Received: from dahlia (dahlia.ho.att.com) by arch4.ho.att.com (4.1/EMS-1.2 GIS) id AA20083; Wed, 27 Mar 96 14:58:07 EST Received: by dahlia (4.1/EMS-1.1 SunOS) id AA16495; Wed, 27 Mar 96 15:00:19 EST Date: Wed, 27 Mar 96 15:00:19 EST From: shur@arch4.ho.att.com Message-Id: <9603272000.AA16495@dahlia> To: rem-conf@es.net, casner@precept.com Subject: Re: Transition to RTP audio on MBone Cc: m.handley@cs.ucl.ac.uk Where can I find printable documentation on sdr? The on-line help is useful but I don't know how to print it out. Thanks, David Shur. From rem-conf-request@es.net Wed Mar 27 15:09:50 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Wed, 27 Mar 1996 12:08:54 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14765(4)>; Wed, 27 Mar 1996 12:08:42 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Wed, 27 Mar 1996 12:08:39 -0800 To: daw@tngstar.cray.com (Dave Wright) cc: rem-conf@es.net, tat@pandora.cray.com Subject: Re: Transition to RTP audio on MBone In-reply-to: Your message of "Wed, 27 Mar 96 09:04:15 PST." <9603271704.AA00516@nothing.cray.com> Date: Wed, 27 Mar 1996 12:08:32 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <96Mar27.120839pst.177478@crevenia.parc.xerox.com> In message <9603271704.AA00516@nothing.cray.com> you write: >Problem #2: sdr v2.1a12 >I often get sdr to give an error window though things do seem to start up. >When I click on the session I wish to watch I often get a window that says: >Error in TCl Script Error: bad window path name ".descb67de9bd" This happens when you double-click on a session name. sdr's user interface is not the same as sd's; you middle-click on a session to start it, or you left-click once and click on the "Start" button that appears in the Session Information window. >Problem #4 : mrouted 2.2 >mrouted is filling our /var/adm/messages filesystem with lots of messages: Yup, 2.2 will certainly do that. You need to run 3.8 to participate properly in today's MBONE. Unfortunately, 3.8 requires kernel patches, which are available for Solaris 2.4 and 2.5 but not for 2.3 . Bill From rem-conf-request@es.net Wed Mar 27 18:35:03 1996 Received: from rpi.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 27 Mar 1996 15:34:13 -0800 Received: from hibp.ecse.rpi.edu (hibp7.ecse.rpi.edu) by rpi.edu (4.1/SMHUB41); id AA25849; Wed, 27 Mar 96 18:34:03 EST for rem-conf@es.net Received: from chopin.ecse.rpi.edu by hibp.ecse.rpi.edu (4.1/ST26); id AA08919 for @hibp7.ecse.rpi.edu:daw@tngstar.cray.com; Wed, 27 Mar 96 18:34:01 EST Received: from chopin.ecse.rpi.edu by chopin.ecse.rpi.edu via ESMTP (940816.SGI.8.6.9/940406.SGI) id SAA17327; Wed, 27 Mar 1996 18:33:11 -0500 Message-Id: <199603272333.SAA17327@chopin.ecse.rpi.edu> X-Mailer: exmh version 1.6.4 10/10/95 Reply-To: stewart@hibp7.ecse.rpi.edu To: daw@tngstar.cray.com (Dave Wright) Cc: casner@precept.com (Stephen Casner), rem-conf@es.net, tat@pandora.cray.com Subject: Re: Transition to RTP audio on MBone In-Reply-To: Your message of "Wed, 27 Mar 1996 11:04:15 CST." <9603271704.AA00516@nothing.cray.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Mar 1996 18:33:10 -0500 From: Paul Stewart In message <9603271704.AA00516@nothing.cray.com>, Dave Wright writes: >Problem #2: sdr v2.1a12 >I often get sdr to give an error window though things do seem to start up. >When I click on the session I wish to watch I often get a window that says: >Error in TCl Script Error: bad window path name ".descb67de9bd" I've seen this frequently myself. I think it happens when I fall back to the old "sd" habit of double clicking. The UI runs into a race condition of a sort with a half-realized window. You essentially close the information window before it's completely open, which causes things that were trying to perform actions on it to fail. Sure, it's ugly, but I don't think it's quite fatal, once I learn to restrain my instinct... -- Paul From rem-conf-request@es.net Wed Mar 27 19:19:53 1996 Received: from dfw.dfw.net by osi-west.es.net with ESnet SMTP (PP); Wed, 27 Mar 1996 16:18:58 -0800 Received: by dfw.dfw.net (4.1/SMI-4.1) id AA20515; Wed, 27 Mar 96 18:16:59 CST Date: Wed, 27 Mar 1996 18:16:57 -0600 (CST) From: Aleph One To: Bill Fenner Cc: rem-conf@es.net Subject: Re: Transition to RTP audio on MBone In-Reply-To: <96Mar27.120839pst.177478@crevenia.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 27 Mar 1996, Bill Fenner wrote: > Yup, 2.2 will certainly do that. You need to run 3.8 to participate > properly in today's MBONE. Unfortunately, 3.8 requires kernel patches, > which are available for Solaris 2.4 and 2.5 but not for 2.3 . Talking about participating in todays MBONE this is my thrid plea for someone to give us a tunnel. He are connected through AGIS in San Diego california, off the agis los anageles ring. Anyone willing to give us a tunnel? > Bill Elias Levy technology@cyberworks.net http://www.cyberworks.net/ From rem-conf-request@es.net Wed Mar 27 19:42:15 1996 Received: from bh.kyungpook.ac.kr by osi-west.es.net with ESnet SMTP (PP); Wed, 27 Mar 1996 16:41:19 -0800 Received: from palgong.kyungpook.ac.kr (palgong.kyungpook.ac.kr [155.230.12.2]) by bh.kyungpook.ac.kr (8.6.12H1/8.6.9) with ESMTP id JAA05702 for ; Thu, 28 Mar 1996 09:39:49 +0900 Received: from Tenet4.kyungpook.ac.kr by palgong.kyungpook.ac.kr (8.6.12H1/8.6.9) id JAA13693; Thu, 28 Mar 1996 09:41:34 +0900 Message-ID: <315995E5.19A3@palgong.kyungpook.ac.kr> Date: Thu, 28 Mar 1996 04:24:21 +0900 From: Hur Sang Jin Organization: KNU X-Mailer: Mozilla 2.0GoldB1 (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Audio mixing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all. Can you tell me audio mixing algorithm for Sound Bluster linear 16 bits sample ? I have tested my ideas. First, I guess audio mixing in 16 bits simply add two sources and then clip results ( -32767 ~ 32767 ). but the sound is some noisy. Second, interleaving two sources in byte unit. resulting sound is acceptable but play duaration is double. Some other elegant algorithm exists ? please help me. thanks in advance. e-mail : hsj@palgong.kyungpook.ac.kr hsj@cihost.comin.co.kr >from : Sang-jin Hur. From rem-conf-request@es.net Thu Mar 28 01:00:08 1996 Received: from atg.apple.com by osi-west.es.net with ESnet SMTP (PP); Wed, 27 Mar 1996 19:35:31 -0800 Received: from [17.255.9.143] (jpallas.atg.apple.com [17.255.9.143]) by atg.apple.com (8.7.2/8.6.12) with SMTP id TAA18083; Wed, 27 Mar 1996 19:37:30 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Mar 1996 19:35:24 -0700 To: Stephen Casner , rem-conf@es.net From: Pallas@Apple.COM (Joe Pallas) Subject: Re: Transition to RTP audio on MBone Steve, I agree whole-heartedly with this goal. Unfortunately, there is a small problem with moving to sdr. I have yet to find a pointer to the SDAP specification that will allow "the rest of us" to play. Having sdr for a couple of flavors of Unix is great, but without either a spec or source code, no other platforms will be able to support the new session announcement protocol. I'm really glad that we have an SDP spec, but that's only half the problem (and it's the easy half to reverse-engineer without a spec). Right now, I don't even know what groups to join or what port to listen on to hear sdr's announcements, let alone the mysterious stuff I never found out about how sd times its announcements based on scope and bandwidth. I'm not suggesting the transition to RTP audio should wait. I'm just saying that if it depends on the new announcement protocol, then the community needs documentation for that protocol right away. joe -- Joe Pallas Apple Computer, Advanced Technology Group, Lab X When your only problem is a nail, every tool looks like a hammer. From rem-conf-request@es.net Thu Mar 28 05:48:34 1996 Received: from vlsi.cs.caltech.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 28 Mar 1996 02:47:44 -0800 Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1) id AA06919; Thu, 28 Mar 96 02:47:56 PST Date: Thu, 28 Mar 96 02:47:56 PST From: schooler@cs.caltech.edu (Eve Schooler) Message-Id: <9603281047.AA06919@vlsi.cs.caltech.edu> To: daw@tngstar.cray.com, stewart@hibp7.ecse.rpi.edu Subject: Re: Transition to RTP audio on MBone Cc: casner@precept.com, mhandley@reward.hpc.org, rem-conf@es.net, tat@pandora.cray.com Further explanation of the sdr error: >From: Mark Handley >To: schooler@cs.caltech.edu (Eve Schooler) >Cc: mhandley@reward.hpc.org >Subject: Re: Transition to RTP audio on MBone > >>>Problem #2: sdr v2.1a12 >>>I often get sdr to give an error window though things do seem to start up. >>>When I click on the session I wish to watch I often get a window that says: >>>Error in TCl Script Error: bad window path name ".descb67de9bd" >> >>I get this as well, but only when I double-click (vs using mouse button >>1, 2, or 3) on a session entry. Is double-clicking not allowed anymore, >>or perhaps it is my version of tk/tcl? > >There is a problem with tk and double clicking - I changed the "start >this session immediately" button to be the middle button rather than >double-left. > >Basically the problem is that double clicking is treated by tk to be a >double click event and two single click events, and there appears to >be no way round this. Thus when I wanted different behaviours for >click on something that;s not displayed, click on something that's >displayed and doubel click there was no way to do it :-( > >Mark From rem-conf-request@es.net Thu Mar 28 20:25:39 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 28 Mar 1996 17:25:08 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA14340; Thu, 28 Mar 1996 17:25:02 -0800 Date: Thu, 28 Mar 1996 17:25:02 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: Re: Transition to RTP audio on MBone In-Reply-To: <199603261642.JAA02018@dandelion.cs.colorado.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am pleased by the response I've seen to my message about making the transition to RTPv2 for audio. Several people have asked questions that I think merit a reply to the list. First, let me point out that vat was written by Van Jacobson and Steve McCanne at LBNL, and sdr was written by Mark Handley at UCL, so they are the ones who really know the answers and the ones to whom compliments about improvements in the tools should be directed. About vat: ========== - Is the new vat backward compatible with the old vat? Yes, if you don't run it in RTP mode (i.e., if you omit the -r option). However, the point of this exercise is to begin running vat in RTP mode which will NOT be compatible with the old vat. The objective is to obsolete the old vat. - Is the proposed scheme of using sdr and the new vat in RTP mode compatible with the new MBONE tools coming out for PCs and Macs. Some of the tools are compatible only with old vat and with nv, and for them, the answer is no. However, others do implement RTPv2 and should be compatible. Again, the objective of this exercise is to maximize interoperability by pushing all the tools to use the Proposed Standard RTP. Similarly, there have recently some implementations of sd for non-UNIX platforms. These need to move to SDPv2, and I know at least one already is. - Where can I get a version of the new vat that includes encryption like the old one? This is a political issue, not a technical one. I don't know if there are any plans to make DES code available for users in the US (if indeed there is a legal and practical way to do so). One respondent suggested that a solution would be for someone in a country not bound by ridiculous export regulations to make available a version of vat 4.0 with DES. Then we could all fetch it from there though that would not be the most efficient use of the net. About sdr: ========== - Is there more documentation on sdr? Not as far as I know. See Mark Handley's announcement of sdr from November 1995, appended below. - Do I need a .sdr.tcl file? You don't need one, and I don't have a description of the format. Again, see Mark Handley's announcement below. - sdr doesn't seem to cache the sessions It does for me. Perhaps it only saves the sessions if you exit with the "Quit" button, as with sd. About differences between the sdr implementation and the SDPv2 spec: ==================================================================== I should point out that sdr V2.1a12 is not up-to-date with recent changes to the SDPv2 spec, and in fact, some additional changes were discussed at the IETF MMUSIC session three weeks ago. Per Mark's sdr release message, the current sdr format is documented in the first Internet-Draft of SDPv2, draft-ietf-mmusic-sdp-01.{txt,ps}, available >from Internet-Draft archives, or at least is pretty close to that. The newest SDPv2 draft is in http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.02.1.ps.gz. Actually, the changes between these two drafts are pretty small, per Mark: The only significant changes from the -01 draft are on pages 12, 13 and 14 regarding RTP payload types as I mentioned in my message in December. However, as mentioned above, some changes to the SDPv2 draft may still be made, specifically moving information from the "m=" line to the "c=" line. I expect that there will be new versions of sdr that may not be compatible with the existing version, and this will require some transition steps. Mark Handley may feel that I have shanghaied him while he is on travel because I'm pushing on the use of sdr now. However, an sdr upgrade incompatibility already existed because sdr has been out since November and the SDP spec has changed since then. I believe it is important to start the transition to RTP now, even though more work remains on sdr, for a few reasons: - to discourage any more development of tools compatible with the old protocols that are to be obsoleted; - we need to get as much experience with implementation and use of RTP as we can during this Proposed Standard stage so we will be prepared to go to Draft Standard stage; - it will take time to make this transition, and my goal is to have use of sdr and RTP audio be widespread enough by the next IETF meeting in late June that they can be used for that meeting. My hope is that those of you who are responding now will also quickly pick up a new version of sdr when it is ready. It should be possible to manage the transition in a manner similar to that planned by the LBNL folks for vic 2.7 to 2.8: the next version of sdr could be designed to send in the same format as the current one but accept both the current format and the final SDPv2 format, and then that would be followed by a version that sends SDPv2 format but still accepts both. Some time later, the code to accept the old format could be eliminated. This same model should be followed by anyone who wants to do an independent implementation of SDPv2 now. Such a program should also accept both the format sent by the current sdr and what the final version of SDPv2 will be. This is a pain, but such is life on the leading edge. -- Steve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date: Mon, 27 Nov 1995 22:36:04 +0000 From: Mark Handley To: rem-conf@es.net Cc: M.Handley@cs.ucl.ac.uk Subject: sdr Session Directory available An alpha release of sdr, a new session directory compliant with draft-ietf-mmusic-sdp-01.{txt,ps} is now available as an alpha release in the mice/sdr directory on cs.ucl.ac.uk. Currently binaries are available for SunOS{4,5} OSF1/2.0 and Irix 5.3. HPUX, linux and BSDI should hopefully follow shortly. Note: - this is an alpha release - there are sure to be bugs! - sdr is *not* compatible with sd - though a relay from sd to sdr should be available shortly - there's no decent manual page yet (though there is a fair amount of built in help) - source will be available shortly, but if you want to port it to a new platform now, let me know - the UK-US link is *very* slow at the moment - a US mirror site would be useful! sdr will read a .sdr.tcl file on startup. Don't just copy your .sd.tcl file to .sdr.tcl - some things are done differently. If you live in an admin scope zone, sdr can support this. Put an add_admin command in your .sdr.tcl file: add_admin Thus, for the UK, which has a scope boundary 239.128.16.0/24, you'd add: add_admin UK 239.128.16.255 9874 239.128.16.0 24 47 This is a horrible way to configure this, and will be replaced in due course! If you want to use sdr to record sessions, you'll need to write a script. To record a session sdr execs record_session and feeds the relevant SDP description to it on stdin. Suggestions for a better generic record interface would be gratefully accepted! The to-do list is still very long, but hopefully this addresses some of the things on the wish list! Mark From rem-conf-request@es.net Thu Mar 28 21:22:13 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 28 Mar 1996 18:21:38 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA14492; Thu, 28 Mar 1996 18:21:33 -0800 Date: Thu, 28 Mar 1996 18:21:32 -0800 (PST) From: Stephen Casner To: Joe Pallas Cc: rem-conf@es.net Subject: Re: Transition to RTP audio on MBone In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Joe, > I agree whole-heartedly with this goal. Unfortunately, there is a small > problem with moving to sdr. I have yet to find a pointer to the SDAP > specification that will allow "the rest of us" to play. Having sdr for a > couple of flavors of Unix is great, but without either a spec or source > code, no other platforms will be able to support the new session > announcement protocol. Well, I believe Mark Handley is working on an SDAP spec. I know he has a number of things on his plate, and knowing how much trouble I have getting all the things done that I want to do, I'm not going to fault him. One observation I would make is that there was no document about sd, either, so it seems you are no worse off. > I'm really glad that we have an SDP spec, but that's only half the problem > (and it's the easy half to reverse-engineer without a spec). Right now, I > don't even know what groups to join or what port to listen on to hear sdr's > announcements, let alone the mysterious stuff I never found out about how > sd times its announcements based on scope and bandwidth. The multicast address and port for global sdr announcements are one less than those used for sd in both cases. Indeed, it would be good to have the "mysterious stuff" documented. -- Steve From rem-conf-request@es.net Fri Mar 29 10:17:32 1996 Received: from relay.hp.com by osi-west.es.net with ESnet SMTP (PP); Fri, 29 Mar 1996 07:16:33 -0800 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA150102589; Fri, 29 Mar 1996 07:16:29 -0800 Received: from tisbury.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA273342588; Fri, 29 Mar 1996 10:16:28 -0500 Message-Id: <2.2.32.19960329151628.007177c0@pop-e3.ch.apollo.hp.com> X-Sender: brezak@pop-e3.ch.apollo.hp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Mar 1996 10:16:28 -0500 To: rem-conf@es.net From: John Brezak Subject: PCMCIA Video capture ? Does anyone know of vendors that sell PCMCIA video capture cards ? Ideally they will accept composite video in and supply a Video for Windows capture interface. From rem-conf-request@es.net Fri Mar 29 11:54:28 1996 Received: from elaine.crcg.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 29 Mar 1996 08:53:46 -0800 Received: by elaine.crcg.edu (4.1/SMI-4.1) id AA02305; Fri, 29 Mar 96 11:52:43 EST Date: Fri, 29 Mar 1996 11:52:42 -0500 (EST) From: Mike Macedonia X-Sender: mmacedon@elaine To: John Brezak Cc: rem-conf@es.net Subject: Re: PCMCIA Video capture ? In-Reply-To: <2.2.32.19960329151628.007177c0@pop-e3.ch.apollo.hp.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII John, Quadrant International makes CardCam. Mobile Planet sells it. Don't know how good it is. BTW, we got nv and vat running on a 133 Pentium laptop (Ergo) with linux and QuickCam as the video source. It works but is unstable right now. However, we are getting better performance than from our SGI Indy. - Mike ----------------------------------------------------------------- | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | | Vice President | EMAIL: mmacedon@crcg.edu | | Fraunhofer CRCG | | | 167 Angell Street | PH : (+1) 401 453-6363 | | Providence, RI 02906 | FAX: (+1) 401 453-0444 | ----------------------------------------------------------------- On Fri, 29 Mar 1996, John Brezak wrote: > Does anyone know of vendors that sell PCMCIA video capture cards ? Ideally > they will accept composite video in and supply a Video for Windows capture > interface. > > From rem-conf-request@es.net Fri Mar 29 13:01:13 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Fri, 29 Mar 1996 10:00:31 -0800 Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id JAA02306; Fri, 29 Mar 1996 09:58:08 -0800 Message-Id: <199603291758.JAA02306@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Mike Macedonia cc: John Brezak , rem-conf@es.net Subject: Re: PCMCIA Video capture ? In-reply-to: Your message of "Fri, 29 Mar 1996 11:52:42 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Mar 1996 09:58:08 -0800 From: "Amancio Hasty Jr." >>> Mike Macedonia said: > > John, > > Quadrant International makes CardCam. Mobile Planet sells it. Don't know > how good it is. > > BTW, we got nv and vat running on a 133 Pentium laptop (Ergo) with linux and > QuickCam as the video source. It works but is unstable right now. > However, we are getting better performance than from our SGI Indy. Since the SGI Indy was mentioned... Try using a PCI video card such as the Matrox Meteor on a 133 Pentium 8) I am not sure if linux supports Philips chipset based video cards as well as FreeBSD. At any rate, our Matrox Meteor driver is rock solid with nv, vic and tv which has support for direct video transfer from the meteor capture board straight to the video frame buffer. Cheers, Amancio From rem-conf-request@es.net Fri Mar 29 16:21:26 1996 Received: from fenris.hiof.no by osi-west.es.net with ESnet SMTP (PP); Fri, 29 Mar 1996 13:20:33 -0800 Received: from abdallah.hiof.no by fenris.hiof.no with SMTP (PP) id <02721-0@fenris.hiof.no>; Fri, 29 Mar 1996 21:50:30 +0100 Received: by abdallah.hiof.no (940816.SGI.8.6.9/940406.SGI.AUTO) id UAA03779; Fri, 29 Mar 1996 20:49:52 GMT Date: Fri, 29 Mar 1996 20:49:50 +0000 (GMT) From: Borre Ludvigsen To: Mike Macedonia cc: John Brezak , rem-conf@es.net Subject: Re: PCMCIA Video capture ? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII How about a PCMCIA codec for a MAC 5300 Powerbook? - Barre On Fri, 29 Mar 1996, Mike Macedonia wrote: > > John, > > Quadrant International makes CardCam. Mobile Planet sells it. Don't know > how good it is. > > BTW, we got nv and vat running on a 133 Pentium laptop (Ergo) with linux and > QuickCam as the video source. It works but is unstable right now. > However, we are getting better performance than from our SGI Indy. > > - Mike > > ----------------------------------------------------------------- > | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | > | Vice President | EMAIL: mmacedon@crcg.edu | > | Fraunhofer CRCG | | > | 167 Angell Street | PH : (+1) 401 453-6363 | > | Providence, RI 02906 | FAX: (+1) 401 453-0444 | > ----------------------------------------------------------------- > > > On Fri, 29 Mar 1996, John Brezak wrote: > > > Does anyone know of vendors that sell PCMCIA video capture cards ? Ideally > > they will accept composite video in and supply a Video for Windows capture > > interface. > > > > > Borre Ludvigsen - http://www.hiof.no/~borrel finger: borrel@abdallah.hiof.no From rem-conf-request@es.net Fri Mar 29 19:21:16 1996 Received: from dns1.eecs.wsu.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 29 Mar 1996 16:20:17 -0800 Received: from pace.eecs.wsu.edu by dns1.eecs.wsu.edu (8.7.1/8.950224) id QAA28673; Fri, 29 Mar 1996 16:20:07 -0800 (PST) From: Tong-yee Lee - EECS (CPTS541) Received: by pace.eecs.wsu.edu (1.38.193.4) id AA13894; Fri, 29 Mar 1996 16:20:07 -0800 Message-Id: <9603300020.AA13894@pace.eecs.wsu.edu> Subject: Information To: casner@precept.com (Stephen Casner) Date: Fri, 29 Mar 1996 16:20:07 -0800 (PST) Cc: rem-conf@es.net In-Reply-To: from "Stephen Casner" at Mar 28, 96 05:25:02 pm X-Mailer: ELM [version 2.4 PL24 ME8b] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi: I would like to start to play and implement something like send video, audio, etc on net. Please give me some reference to read and where I can find source code (C) to study. I would like to play it on HP or SUn wks or PC. BTW, what kind hardware I need to buy? Any suggestion? Thanks, Lee