From rem-conf-request@es.net Thu Jul 01 11:47:33 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <09020-0@osi-west.es.net>; Thu, 1 Jul 1993 08:18:23 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 1 Jul 1993 16:17:52 +0100 To: Jim Martin cc: rem-conf@es.net Subject: Re: Shuttle audio yet again... In-reply-to: Your message of "Mon, 21 Jun 93 17:27:39 EDT." Date: Thu, 01 Jul 93 16:17:48 +0100 From: Jon Crowcroft >Hence, I've created a new session titled "Live Shuttle Audio (STS-57)" >viewable via sd. This session should stay in effect for the duration >of the mission. I'm including the mission information that I had sent >earlier. well, we justr finished watching and listening to the shuttle landing from london, england, and are suitably impressed.... jolly good show. j From rem-conf-request@es.net Thu Jul 01 13:19:19 1993 Received: from jerry.inria.fr by osi-west.es.net with SMTP (PP) id <10670-0@osi-west.es.net>; Thu, 1 Jul 1993 09:59:13 +0000 Received: by jerry.inria.fr (5.65c/IDA-1.2.8) id AA06508; Thu, 1 Jul 1993 19:00:09 +0200 Message-Id: <199307011700.AA06508@jerry.inria.fr> To: rem-conf@es.net Subject: New ivs version 3.2 Date: Thu, 01 Jul 93 19:00:07 +0200 From: Thierry TURLETTI Hi all, The new version of ivs is now available by anonymous ftp from avahi.inria.fr (138.96.24.30) in the /pub/videoconference directory. -rw-rw-r-- 1 turletti 441672 Jul 1 18:12 ivs3.2-src.tar.Z -rw-rw-r-- 1 turletti 1874253 Jul 1 17:11 ivs3.2-sun4OS4-px.tar.Z -rw-rw-r-- 1 turletti 2137607 Jul 1 15:51 ivs3.2-sun4OS4-vfc.tar.Z -rw-rw-r-- 1 turletti 3452419 Jul 1 18:57 ivs3.2-sgi.tar.Z I'll add SGI, DEC and HP binaries as soon as I receive them. Here are the main changes since version 3.1: *The old CSDESC packet is now called CDESCRIPTOR, and it follows the new RTP format described in the Internet-Draft from Henning Schulzrinne, (March 26). * The HELLO packet is removed. Now, a station will send its CDESCRIPTOR periodically *and* when it receives a CDESCRIPTOR for a new station (If feedback allowed). *** This implies that version 3.2 is incompatible with previous versions... * The -r option bug is fixed. The active stations remained active even if they stop their emission. * The -N option now allows to specify a full name without the @host.. Note that the SendNACK and SendFIR procedures have been changed. The input is now the host_coder's sin_addr and not the host_coder's name. * It is now possible to change the image size and color at the decoder side on the fly (This is done by clicking on the image) * The -I option is removed. You can now specify the UDP ports used. It is useful to differenciate several ivs conferences in the same machine. For example: UNICAST MODE: e.g. to jerry.inria.fr: --> ivs jerry.inria.fr or ivs jerry.inria.fr/2235 --> ivs 138.96.24.78 or ivs 138.96.24.78/2235 MULTICAST MODE: e.g. to 224.8.8.8 group: --> ivs 224.8.8.8 or ivs 224.8.8.8/2232 * The Cosine transform routines are faster by about 40% * Color grabbing procedures have been added for VideoPix/NTSC, Parallax, VIDEOTX and INDIGOVIDEO. * A receive only mode is added (option -recvonly); In this mode, the ivs panel size is reduced. * When you iconify an image, now the decoding process is interrupted and a small 64x64 iconized image is shown. * The grabbing procedures and grabbing window management routines for the PARALLAX XV card have been completely rewritten. Please refer to the README.PARALLAX file. On SPARC 10/Parallax, we obtain the following frame rate: # QCIF between 9 and 19 fps # CIF between 3 and 8 fps # SCIF between 0.7 and 1.8 fps I'd like to thank all the people who participated and tested this new version. Please let me know if this version has problems. Thanks. Thierry From rem-conf-request@es.net Thu Jul 01 14:09:33 1993 Received: from grimaldi.rutgers.edu by osi-west.es.net with SMTP (PP) id <11526-0@osi-west.es.net>; Thu, 1 Jul 1993 10:55:59 +0000 Received: by grimaldi.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27643; Thu, 1 Jul 93 13:55:46 EDT Date: Thu, 1 Jul 93 13:55:43 EDT From: Jim Martin To: Jon Crowcroft Cc: rem-conf@es.net Subject: Re: Shuttle audio yet again... In-Reply-To: Your message of Thu, 01 Jul 93 16:17:48 +0100 Message-Id: > > well, we justr finished watching and listening to the shuttle landing > from london, england, and are suitably impressed.... > I was impressed too, but I can't claim credit. About midway through the mission, Alan Clegg (abc@concert.net) took over the re-broadcasting since he had a better audio source and had a video source as well. Many thanks to him for providing the feed! Jim -- Jim Martin Internet: jim@noc.rutgers.edu Network Services UUCP: {backbone}!rutgers!jim Rutgers University Phone: (908) 932-3719 From rem-conf-request@es.net Thu Jul 01 21:10:06 1993 Received: from viipuri.nersc.gov by osi-west.es.net with SMTP (PP) id <01150-0@osi-west.es.net>; Thu, 1 Jul 1993 18:00:50 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA08333; Thu, 1 Jul 93 18:00:48 PDT Date: Thu, 1 Jul 93 18:00:48 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9307020100.AA08333@viipuri.nersc.gov> To: dvtf@es.net Subject: Connect918 Cc: rcwg@nic.hep.net, rem-conf@es.net I just returned from a visit to the Macintosh Connectivity Conference/Show (Mactivity93) in SanJose. I saw the latest version of a desktop video conferencing system from a company headquartered in HongKong with the unlikely name of NUTS Technologies...I first saw this product in prototype form running on an ethernet at COMNET93 in February and was sufficiently impressed to try to get an on-site demo. Unfortunately, the guy that NUTS had hired to head their US marketing/sales effort turned out to be a bit inexperienced and kept getting buried under similar requests without being able to meet any of them as well as developing sales channels. A new marketing and sales head and team is now in place and ready to push the product onto desktops, everywhere... Their product is now called the Connect918 (formerly HELLO918) "DeskTop VideoConferencing system": Features: -Three-way conferencing -Mac/PC conferencing -Full color and full motion -File transfer -Screen sharing with audio -Audio/video recording -System available on analog and high speed lines, or on LAN environment Works on PC or Macintosh: PC requirements -80386 or above w/atleast 2 ISA slots - VGA or SVGA monitor - Windows3.1 or later - 8MB RAM Macintosh requirements - At least 1 NuBus slot - System 7.0 or later - Apple Communications Toolbox - 8MB RAM - QuickTime version 1.0 or better (optional for recording and playback) Connect918 Technical Information - Full color - Full motion (30fps max) - Compatible with CCITT H.261, H.221, H.242, H.320 standards - Resolution: QCIF (176x144)@30fps CIF (352x288)@15fps - Compatible with CCITT G.711, G.722, G.728 standards - Proprietary communications/compression technology: ROPS - Three Mini-DIN connectors - Supports ISDN, analog telephone lines, and other high-speed links - Modem based version operates at 5-10fps US Retail Prices Connect918 Modem/LAN $4,250 Includes CODEC board, camera w/microphone, software, cables, user manual. Will run with network interface, or internal or external modem (9.6kb/s or 14.4kb/s) Connect918 SW56 $5,000 Includes CODEC board, camera w/microphone, software, cables, user manual. Will interface with a Switched 56 card. Connect918 ISDN $5,850 Includes CODEC board, camera w/microphone, software, cables, user manual. Interfaces with included ISDN board. Also runs with LAN interface and/or internal/external modem. --------End of Product Information----------- Aside from lacking sales channels, the product has been delayed. If I am to believe the current marketing director, they will be shipping later this month. The marketing organization will also have demonstration units available for large potential accounts. The ISDN version is due to be introduced at MacWorld in Boston, in August. The PC version is quoted as becoming available for delivery in September. PC version pricing was said to be "similar" to the Macintosh based product. The ISDN version, initially will do 1 B video, and 1 B audio and 2B, later, perhaps by year end (that's when a G.728 audio solution "might" be available). I asked about H.320 interoperability tests and was told the same thing as at COMNET: They have tested the ISDN version against a PictureTel standards implementation. I asked for more details and was told that "someone more technical" would contact me. The image quality of the "postage stamp" image on the modem version was on par with the first IETF videocasts (except in color). Admittedly the demo was at 14.4kb/s! It was not as good as the ShareVision product. The ethernet version demo(s) had high motion (close to "full") and good color as well as impressive image quality. The audio is sourced through the builtin microphone in the nifty camera box which has an adjustable for angle lens (only need to rotate the lens_ball in which lens is off-center to "point" lens). The camera is auto-iris, fixed focus (don't know equivalent width of field). Audio is played through a speaker which comes with the product. I didn't play with the screen sharing at Mactivity93. Anyone else seen, heard, or otherwise have any more detail to add about Connect918? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ari Ollikainen ari@es.net National Energy Research Supercomputer Center ESnet (Energy Sciences Network) Lawrence Livermore National Laboratory 510-423-5962 FAX:510-423-8744 P.O. BOX 5509, MS L-561, Livermore, CA 94550 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Fri Jul 02 06:45:26 1993 Received: from loki.cee.hw.ac.uk by osi-west.es.net with SMTP (PP) id <04640-0@osi-west.es.net>; Fri, 2 Jul 1993 03:28:38 +0000 Received: from cee.hw by cee.hw with smtp (Smail3.1.27.1 #14) id m0oBiMd-0002wzC; Fri, 2 Jul 93 11:29 BST Received: by cee.hw (Smail3.1.27.1 #8) id m0oBiCa-0003btC; Fri, 2 Jul 93 11:18 BST Message-Id: Date: Fri, 2 Jul 93 11:18 BST From: donaldh@cee.hw.ac.uk (Donald I Hunter) To: rem-conf@es.net Subject: unsubscribe unsubscribe me please. From rem-conf-request@es.net Fri Jul 02 07:08:41 1993 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net with SMTP (PP) id <04820-0@osi-west.es.net>; Fri, 2 Jul 1993 03:59:07 +0000 Via: uk.ac.edinburgh.castle; Fri, 2 Jul 1993 11:58:46 +0100 To: rem-conf@es.net, rem-conf@es.net Subject: Networking Multimedia Applications - a reminder From: Chris Adie Date: Fri, 2 Jul 93 11:58:40 WET DST Message-ID: <9307021158.aa03376@castle.ed.ac.uk> July 1993 IETF Meeting in Amsterdam BOF Session on NETWORKING MULTIMEDIA APPLICATIONS (MULTIAPP) The above BOF is scheduled for 1930 to 2200 on Tuesday 13 July in Room H, RAI, Amsterdam. BOF Agenda: 1. Introduction 2. Identifying the issues 3. Goals for future work One or two people have asked if they can formally present research projects, but it's not that sort of meeting. As you can see from the abstract below, it is really oriented towards service development within the Internet. If your research is relevant, please bring it up in the discussion, but there are no formal slots allocated for speakers within the BOF. If you are coming, you may wish to read [the summary of] a RARE report "Network Access to Multimedia Information". You can fetch this by anonymous FTP from: Host: ftp.ed.ac.uk Directory: /pub/mmaccess Filenames: report.doc Report in Word for Windows 2 format (binary!) report.ps Report in Postscript form report.txt Report in ASCII text form summary.doc Summary in Word for Windows 2 format (binary!) summary.ps Summary in Postscript form summary.txt Summary in ASCII text form *.*.Z Each of the above files run through Unix compress program (binary!) Here's the abstract of what will be discussed at the BOF. BOF ABSTRACT ============ The ready availability of user-friendly multimedia authoring tools such as Authorware Professional, Asymmetrix Multimedia Toolbook, Macromind Director and many more, has stimulated much interest in multimedia within the user community. Sophisticated interactive multimedia applications are being developed in many disparate subjects and for a wide range of purposes. Users are now beginning to ask us, as network technologists, "how can I make my multimedia application available to others across the network?". In a parallel development, existing client-server network information retrieval tools are being enhanced with multimedia handling features. Gopher+ for instance has been designed with multimedia data firmly in mind. The World Wide Web project is currently defining a new version of its hypertext markup language, to be called HMML - HyperMedia Markup Language - which includes multimedia support. A third strand of activity is the emergence of network technologies capable of carrying audio and video data across the network, initially driven by multimedia conferencing applications. Network technologies such as ATM and protocols such as RTP are potentially capable of handling isochronous multimedia data in an effective way. This BOF session will focus on issues which link these three strands. Particular questions to be addressed are: * What are user requirements in terms of responsiveness, and what demands this places on the network and server system, and how these might be mitigated. * The prospects for making existing interactive multimedia applications available over the network - eg by writing conversion tools from proprietary formats to a suitable open format. * To what extent can existing network information retrieval tools such as Gopher, WWW, WAIS be used for sophisticated multimedia applications? What about the tools emerging from the research community such as AthenaMuse 2 (MIT), Microcosm (U of Southampton), HyperG (U of Graz)? Do we need another tool, or can we build on what we have? * How can such tools be enhanced to take advantage of isochronous data streams? * What relevance do standards such as HyTime and MHEG have? * What are the security implications of providing interactive multimedia applications in an inter-enterprise environment? The BOF is intended to test interest in the subject, to define issues that need resoving, and to see whether a WG can be formed to work on those issues. Chris Adie Phone: +44 31 650 3363 Edinburgh University Computing Service Fax: +44 31 662 4809 University Library, George Square Email: C.J.Adie@edinburgh.ac.uk Edinburgh EH8 9LJ, United Kingdom From rem-conf-request@es.net Fri Jul 02 09:04:47 1993 Received: from desire.wright.edu by osi-west.es.net with SMTP (PP) id <05505-0@osi-west.es.net>; Fri, 2 Jul 1993 05:45:58 +0000 Received: from DESIRE.WRIGHT.EDU by DESIRE.WRIGHT.EDU (PMDF V4.2-10 #2485) id <01H027DQ8INK0007SA@DESIRE.WRIGHT.EDU>; Fri, 2 Jul 1993 08:45:41 EST Date: Fri, 02 Jul 1993 08:45:41 -0500 (EST) From: Ed Jones Subject: To: rem-conf@es.net Message-id: <01H027DQ8INM0007SA@DESIRE.WRIGHT.EDU> X-VMS-To: IN%"rem-conf@es.net" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I apologize for sending this to the whole list but I have tried rem-conf-request 3 times. Please remove me from this list as I am currenlty receiving it on 2 machines. Only need one copy :) Ed Jones **************************************************************************** * Ed Jones | ejones@desire.wright.edu * * Department of Psychology | ejones@sdl.psych.wright.edu * * Signal Detection Lab | ejones@wsu (Bitnet) * * Wright State University | * **************************************************************************** From rem-conf-request@es.net Fri Jul 02 10:11:35 1993 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net with SMTP (PP) id <06049-0@osi-west.es.net>; Fri, 2 Jul 1993 06:56:19 +0000 Via: uk.ac.rutherford.informatics; Fri, 2 Jul 1993 14:55:39 +0100 Received: from bingo by inf.rl.ac.uk; Fri, 2 Jul 93 14:55:32 BST Date: Fri, 2 Jul 93 14:55:29 BST From: ijj@informatics.rutherford.ac.uk Message-Id: <9307021355.AA02523@bingo> To: rem-conf Subject: VideoPix under Solaris 2.2 X-Sun-Charset: US-ASCII Content-Length: 1286 You can get an "unofficial" patch to enable VideoPix to run under 2.2: you should contact your Sun sales rep. or your Sun Support Hotline to obtain this. I don't know when (if?) Sun will officially support VideoPix under 2.2, but it seems to work for me. Here's what the Sun UK Multimedia rep. said: ========= The situation is that Solaris 2.x binary versions of a VideoPix device driver, the VideoPix interface library (libvfc.a), the video frame capture tool (vfctool), and the newly created VideoPix XIL pipeline library (xilSUNWvfc.so) will be made available without support. These are in the form of two Solaris 2.x packages, one for the VideoPix device driver (SUNWvpx.tar.Z) and one for the VideoPix XIL support including "libvfc.a" (SUNWvpu.tar.Z); and a "compressed tar archive" containing the Solaris 2.x version of the video frame capture tool, "vfctool", and include files, vfc_ioctls.h and vfc_lib.h (SUNWvfc.tar.Z). The XIL support package includes the source code for an example program ("display.c") that captures image data from VideoPix via XIL calls and displays it in an X window. ========== ---- "You can't get the wood!" Ian Johnson JANET: ijj@uk.ac.rl.inf Rutherford Appleton Laboratory, UUCP: ..!mcsun!ukc!rlinf!ijj Chilton, Didcot, Oxon OX11 0QX. From rem-conf-request@es.net Fri Jul 02 17:42:47 1993 Received: from thumper.bellcore.com by osi-west.es.net with SMTP (PP) id <11548-0@osi-west.es.net>; Fri, 2 Jul 1993 14:31:35 +0000 Received: from able.bellcore.com by thumper.bellcore.com (4.1/4.7) id for rem-conf@es.net; Fri, 2 Jul 93 17:31:23 EDT Received: by able.bellcore.com (5.57/4.7) id AA17570; Fri, 2 Jul 93 17:31:23 -0400 Received: from Messages.8.4.N.CUILIB.3.45.SNAP.NOT.LINKED.able.pmax.ul4 via MS.5.6.able.pmax_ul4; Fri, 2 Jul 1993 17:31:22 -0400 (EDT) Message-Id: Date: Fri, 2 Jul 1993 17:31:22 -0400 (EDT) From: Abel Weinrib Content-Type: text/plain; charset=US-ASCII To: confctrl@ISI.EDU, rem-conf@es.net Subject: Multiparty Multimedia Session Control (mmusic) Cc: mankin@cmf.nrl.navy.mil A new IETF working group has been formed (in the Transport Area) to design and specify a protocol for multiparty multimedia session control. The charter is attached below. This working group will be meeting at the next IETF in Amsterdam on Tuesday 7/13 and Wednesday 7/14 at 9:00 AM. Both sessions will be multicast over the mbone on channel 2. A preliminary agenda for the meeting appears below, following the charter. Other related information will follow on the confctrl mailing list. (If you received this mail more than once, accept our apologies--we wanted this first message to get a broad exposure.) Hope to see you in Amsterdam. Eve Schooler Abel Weinrib ================ Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- Charter Chair(s): Eve Schooler Abel Weinrib Transport Area Director(s) Allison Mankin Mailing lists: General Discussion:confctrl@isi.edu To Subscribe: confctrl-request@isi.edu Archive: venera.isi.edu:~/confctrl/confcrtl.mail Description of Working Group: The demand for Internet teleconferencing has arrived, yet an infrastructure to support this demand is barely in place. Multimedia session control, defined as the management and coordination of multiple sessions and their multiple users in multiple media (e.g., audio, video), is one component of the infrastructure. The Multiparty Multimedia Session Control Working Group is chartered to design and specify a protocol to perform these functions. The protocol will provide negotiation for session membership, underlying communication topology and media configuration. In particular, the protocol will support a user initiating a multimedia multiparty session with other users (``calling'' other users) over the Internet by allowing a teleconferencing application on one workstation to explicitly rendezvous with teleconferencing applications running on remote workstations. Defining a standard protocol will enable session-level interoperability between different teleconferencing implementations. The focus of the Working Group is to design a session negotiation protocol that is tailored to support tightly-controlled conferences. The MBONE currently carries primarily loosely-controlled sessions, i.e., sessions with little to no interaction among members and with no arbitration facility, security, or coordination of quality-of-service options for time-critical media. Users may learn of available sessions using the ``sd'' utility or other out of band mechanisms (e.g., e-mail). However, there is clearly also a need for tightly-controlled sessions that provide mechanisms for directly contacting other users to initiate a session and for negotiating conference parameters such as membership, media encodings and encryption keys. In addition, these sessions should support renegotiation during a session, for example to add or delete members or change the media encoding. It is possible that the protocol will, in the limiting case, also support loosely-controlled sessions. The main goal of the Working Group will be to specify the session control protocol for use within teleconferencing software over the Internet. The Working Group will focus on the aspects of the session control problem that are well understood, while keeping an eye on evolving research issues. Toward this end, the Working Group has made an inventory of existing conferencing systems and their session control protocols. The Working Group will document the requirements of the existing prototypes as a basis for the protocol development. The Working Group will iteratively refine the protocol based on implementation and operational experience. Furthermore, the Working Group will coordinate with other efforts related to multimedia conferencing, such as directory services for cataloguing users and conferences, the RTP and RTCP protocols developed by the Audio/Video Transport working group, resource reservation and management at the network level, and schemes for multicast address allocation. Goals and Milestones: May 93 Hold an on-line working group meeting to discuss the conference control framework, the relevant terminology, a functional taxonomy and how different conversational styles place requirements on session protocols. Jun 93 Submit the Conference Session Control Protocol to the IESG for consideration as an Experimental Protocol. Aug 93 Post an Internet-Draft describing the Session Control Requirements. Nov 93 Post an Internet-Draft of the Session Control Protocol. Mar 94 Submit a revised Internet-Draft based on implementation experience. =================== Agenda: Topics for Discussion ----------------------------- - Charter: motivation behind forming a working group, name change, narrower focus, Transport Area, milestone schedule - Terminology discussion: glossary handout - Mappings document: status report - Framework: how the protocol might fit in to a general framework for multimedia multiparty teleconferencing - Functional taxonomy: Define the services the protocol provides: o Descriptions of what we want to be able to do, e.g., negotiate about membership, media, encryption keys, privacy policies, etc. o Priorities: membership, media capabilities, qos negotiation, session merging, side-chats? o Other sorts of interactions? o Other applications that could make use of the protocol - Implementation realities: messaging choices, ease of implementation, impact of light-weight choices - Operation Environment Realities: Internet constraints, RTCP - Strawman Protocol o How general? What would it look like? o Communications blocks o Negotiation styles o General session functions o Parameterization o Sample message exchanges or session functions - First Milestone: protocol requirements doc, more writing assignments - Update from Liaisons - Bibliography: ISI has space to be central repository for docs - Other topics From rem-conf-request@es.net Fri Jul 02 21:48:36 1993 Received: from viipuri.nersc.gov by osi-west.es.net with SMTP (PP) id <14113-0@osi-west.es.net>; Fri, 2 Jul 1993 18:41:41 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA09458; Fri, 2 Jul 93 18:41:33 PDT Date: Fri, 2 Jul 93 18:41:33 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9307030141.AA09458@viipuri.nersc.gov> To: rem-conf@es.net, cja@castle.edinburgh.ac.uk Subject: Re: Networking Multimedia Applications - a reminder Cc: mmis@mailbase.ac.uk > Sophisticated interactive multimedia > applications are being developed in many disparate subjects and for a > wide range of purposes. Users are now beginning to ask us, as network > technologists, "how can I make my multimedia application available to > others across the network?". > Apparently IBM, Intel, Northern Telecom, Telstra (Australia), BT, France Telecom and DB Telekom are preparing to address this question with the formation of the "Multimedia Communications Community of Interest" at a meeting last week in France. "... The group says its charter is to promote the use of applications that let people in different locations view documents, images, graphics and full-motion video on a personal computer screen. These applications also let people discuss what they see on the screen as well as make changes that all other participants can see. They will also greatly increase the amount of communications bandwidth used by business, which is why telecom companies are very interested. They will also promote the use of high-end microcomputers, which is behind IBM and Intel's interest. The companies said their success will depend on the degree to which the work can be accomplished regardless of the operating system, computer equipment, or telecom company being used. Where no standards exist, the group will define working specifications until open standards are adopted. The group said it will begin work with a series of field trials in the first quarter of next year aimed at testing services on a coordinated, global basis. ..." One can only guess at the "services"... DVI based Windows Telephony and VfW...I noticed that Microsoft was not (yet) a member. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ari Ollikainen ari@es.net National Energy Research Supercomputer Center ESnet (Energy Sciences Network) Lawrence Livermore National Laboratory 510-423-5962 FAX:510-423-8744 P.O. BOX 5509, MS L-561, Livermore, CA 94550 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Sun Jul 04 16:33:43 1993 Received: from cathedral.cerc.wvu.edu by osi-west.es.net with SMTP (PP) id <22092-0@osi-west.es.net>; Sun, 4 Jul 1993 13:25:32 +0000 Received: by cerc.wvu.edu (4.1/SMI-4.0:RAL-041790) id AA21760; Sun, 4 Jul 93 16:25:27 EDT From: kannan@cerc.wvu.edu (R. Kannan) Message-Id: <9307042025.AA21760@cerc.wvu.edu> Subject: Please remove me from this list. To: rem-conf@es.net Date: Sun, 4 Jul 1993 16:25:26 -0400 (EDT) Cc: kannan (R. Kannan)@es.net In-Reply-To: <01H027DQ8INM0007SA@DESIRE.WRIGHT.EDU> from "Ed Jones" at Jul 2, 93 08:45:41 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 249 Please remove me from this list. -- -- thank you very much R. Kannan email:kannan@cerc.wvu.wvnet.edu Courtesy of : Concurrent Engineering Research Center West Virginia University Morgantown, WV 26505 All standard disclaimers are in effect. From rem-conf-request@es.net Mon Jul 05 23:17:41 1993 Received: from brolga.cc.uq.oz.au by osi-west.es.net with SMTP (PP) id <00110-0@osi-west.es.net>; Mon, 5 Jul 1993 20:09:03 +0000 Received: from cc.uq.oz.au by brolga.cc.uq.oz.au id <08665-0@brolga.cc.uq.oz.au>; Tue, 6 Jul 1993 13:05:27 +1000 To: rem-conf@es.net Subject: ivs anonymous ftp servers Date: Tue, 6 Jul 1993 13:05:27 +1000 From: George Michaelson Sender: G.Michaelson@cc.uq.oz.au *.inria.fr are failing FTP. connects but times out at login, connects but never comes back from cd/dir/ls commands. any US-hosted sources for the newer IVS code? -George From rem-conf-request@es.net Tue Jul 06 03:00:22 1993 Received: from jerry.inria.fr by osi-west.es.net with SMTP (PP) id <00979-0@osi-west.es.net>; Mon, 5 Jul 1993 23:50:19 +0000 Received: by jerry.inria.fr (5.65c/IDA-1.2.8) id AA17474; Tue, 6 Jul 1993 08:51:07 +0200 Message-Id: <199307060651.AA17474@jerry.inria.fr> To: rem-conf@es.net, ivs-users@sophia.inria.fr Cc: ber@fid.morgan.com, berc@src.dec.com Subject: Re: New ivs version 3.2 Date: Tue, 06 Jul 93 08:51:07 +0200 From: Thierry TURLETTI New site to retrieve ivs 3.2 is zenon.inria.fr (138.96.32.21) in the directory "rodeo/ivs" -rw-rw-r-- 1 turletti 0 Jul 2 10:03 VERSION_3.2 -rw-rw-r-- 1 turletti 1120053 Jul 2 15:48 ivs3.2-hps700.tar.Z -rw-rw-r-- 1 turletti 3452419 Jul 2 10:02 ivs3.2-sgi.tar.Z -rw-rw-r-- 1 turletti 441672 Jul 2 10:02 ivs3.2-src.tar.Z -rw-rw-r-- 1 turletti 1874253 Jul 2 10:02 ivs3.2-sun4OS4-px.tar.Z -rw-rw-r-- 1 turletti 2137607 Jul 2 10:03 ivs3.2-sun4OS4-vfc.tar.Z Hope this ftp site more reliable than avahi.inria.fr. Thierry From rem-conf-request@es.net Tue Jul 06 06:27:57 1993 Received: from rx7.ee.lbl.gov by osi-west.es.net with SMTP (PP) id <02076-0@osi-west.es.net>; Tue, 6 Jul 1993 03:16:04 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA07422; Tue, 6 Jul 93 03:15:12 -0700 Message-Id: <9307061015.AA07422@rx7.ee.lbl.gov> To: rem-conf@es.net, mbone@isi.edu Subject: new vat (v2.14) available Date: Tue, 06 Jul 93 03:15:09 PDT From: Van Jacobson A new version of vat is available for anonymous ftp from ftp.ee.lbl.gov files: sun-vat.tar.Z (statically linked sparc binary for Sun OS 4.1.x) sun-vat-dyn.tar.Z (dynamically linked sparc binary - should work with Sun OS 4.1.x & Solaris 2.2) dec-vat.tar.Z (Ultrix 4.x binary for DEC 5000 series MIPS machines) sgi-vat.tar.Z (SGI IRIX binary) This version contains some additional audio encoding options: PCM2, DVI2, PCM4 & DVI4 that increase the audio frame size to 40 or 80ms which cuts the audio packet rate to 25 p/s or 12.5 p/s. (Older versions of vat can receive these larger packets with no problem so these new formats are backwards compatible.) I would encourage anyone intending to listen to the upcoming IETF audiocast from Amsterdam to upgrade to this version of vat -- it contains several significant bug fixes and performance improvements, particularly compared to the 1.x Sun versions. Attached is a list of the changes. Please let us know of any problems (via mail to vat@ee.lbl.gov). Thanks. - Van Jacobson & Steve McCanne ------------------ v2.14beta, Wed Jun 30 18:48:50 PDT 1993 [First vat v2 public release (v2 based on Interviews 3.x rather than 2.6 -- seems to fix lots of X performance problems)]. - added PCM2, DVI2, PCM4 & DVI4 audio formats (40 & 80ms frames) to test whether dropping packet rate helps the IETF distribution more than the increased error susceptibility hurts. (test suggested by Paul Milazzo at BBN.) - Sense of 'no silence suppression' button was backwards (diagnosed by Jim Martin at Rutgers). - re-did audio class to handle problems with Sun streams audio driver not giving us the amount of data we requested on reads. (SunOS problems diagnosed by Ron Frederick at PARC) - Fix problem where vat 'locks up' after running continuously for a couple of days. Problem was file position index on audio fd incrementing through sign bit which causes system to abort future reads & writes with EINVAL error. Now we lseek to 0 on EINVAL from audio read since it probably means we wrapped through the sign bit in the file position. - Put echo-cancel button back (currently only works on DEC with Lofi running Steve McCanne's DSP kernel). - Add rover to Network::SendIDList() so all sites eventually get sent even if they don't all fit in one packet. - Added -S (suppress all new sites) flag and SuppressAll X resource. - Added SiteDropTime X resource that sets number of minutes until an inactive (grayed out) site is deleted from sitebox. Default is 30 minutes. If SiteDropTime drop time is zero, sites will only be deleted when a `c' command is given. - Made `c' command delete sites that have never sent session messages (ones that appear as IP numbers in the sitebox). - Require that both addresses be specified if mixing (-m) -- too many people were using -m without understanding it & cross- connecting some random conference with Mbone Audio. - Fixed bug in session messages backoff -- was dividing where I should have multiplied so session messages were always being sent at 6 second intervals rather than at rate determined by number of participants & conference bandwidth. - Fixed bug where vat would core dump if session packet arrived while vat window was being mapped. ('canvas' pointer in sitebox was initialized to zero.) - On SGIs, made volume & speaker sliders use same scaling as sliders on SGI's Audio Control panel. (scaling supplied by Andrew Cherenson.) - On SGIs added high-pass filter (first order Bessel filter with ~15Hz passband) in audio read routine to get rid of DC bias introduced by mike 'phantom power' signal. (This was screwing up vat's power calculations & breaking the speakerphone modes & vu meters.) I have some trouble understanding why SGI didn't invest the dime it would cost to capacitively couple the mike or put the 4 instructions into the Indigo's DSP that it would take remove this DC bias. Clearly audio is far, far down on SGI's priority list. From rem-conf-request@es.net Tue Jul 06 08:18:07 1993 Received: from Sun.COM by osi-west.es.net with SMTP (PP) id <02694-0@osi-west.es.net>; Tue, 6 Jul 1993 05:05:35 +0000 Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA10599; Tue, 6 Jul 93 05:05:34 PDT Received: from East.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA19419; Tue, 6 Jul 93 05:05:31 PDT Received: from sunpix.East.Sun.COM (string-beans.East.Sun.COM) by East.Sun.COM (4.1/SMI-4.1) id AA00967; Tue, 6 Jul 93 08:05:29 EDT Received: from beale.East.Sun.COM by sunpix.East.Sun.COM (4.1/SMI-4.1) id AA16404; Tue, 6 Jul 93 08:05:29 EDT Date: Tue, 6 Jul 93 08:05:29 EDT From: Herman.Towles@East.Sun.COM (Herman Towles - Sun NC Development Center) Message-Id: <9307061205.AA16404@sunpix.East.Sun.COM> To: rem-conf@es.net Subject: ftp access to VideoPix Drivers for Solaris 2.x X-Sun-Charset: US-ASCII Now available via anonymous ftp on playground.sun.com. /pub/videopix/SUNWvfc.tar.Z VideoPix vfctool & includes /pub/videopix/SUNWvpu.tar.Z VideoPix XIL support & examples /pub/videopix/SUNWvpx.tar.Z VideoPix device driver This software was "ported" from SunOS 4.1.3 to Solaris 2.0 and been used within Sun Engineering as part of other development activities. No problems have been reported with this software, although it has undergone no formal testing. Since proper & formal testing has not been performed, these binaries are considered to be less than Alpha-level. Installing the VideoPix device driver: 1) login as "root" 2) add the following line to /etc/devlink.tab (NOTE: This line must have *no* spaces) type=ddi_pseudo;name=vfc \M0 3) cp vfc /kernel/drv 4) add_drv -m '* 0666 root bin' vfc 5) ls -l /dev/vfc0 6) boot -r System boots will automatically install the driver if the device is installed on the SBus and found by system probe & selftest. Note: if /dev/vfc0 is not created, something is wrong. From rem-conf-request@es.net Tue Jul 06 08:29:04 1993 Received: from runix.runit.sintef.no by osi-west.es.net with SMTP (PP) id <02835-0@osi-west.es.net>; Tue, 6 Jul 1993 05:23:25 +0000 Received: from runit.sintef.no by runix.runit.sintef.no with SMTP (PP) id <07792-0@runix.runit.sintef.no>; Tue, 6 Jul 1993 14:23:08 +0200 Received: by ravn (4.1/Runit-cl-1.0) id AA24500; Tue, 6 Jul 93 14:23:03 +0200 Date: Tue, 6 Jul 1993 14:15:20 +0200 (MET DST) From: Steinar Haug Subject: Re: New ivs version 3.2 To: Thierry TURLETTI Cc: rem-conf@es.net, ivs-users@sophia.inria.fr In-Reply-To: <199307060651.AA17474@jerry.inria.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > New site to retrieve ivs 3.2 is zenon.inria.fr (138.96.32.21) > in the directory "rodeo/ivs" > > -rw-rw-r-- 1 turletti 0 Jul 2 10:03 VERSION_3.2 > -rw-rw-r-- 1 turletti 1120053 Jul 2 15:48 ivs3.2-hps700.tar.Z What is necessary to run IVS on HP 700 hosts? HP Norway has been completely unable to answer questions about the availability of IP multicasting in HP-UX. Steinar Haug, system/networks administrator SINTEF RUNIT, University of Trondheim, NORWAY Email: Steinar.Haug@runit.sintef.no, Steinar.Haug@delab.sintef.no From rem-conf-request@es.net Tue Jul 06 11:30:09 1993 Received: from ocfmail.ocf.llnl.gov by osi-west.es.net with SMTP (PP) id <04344-0@osi-west.es.net>; Tue, 6 Jul 1993 08:22:15 +0000 Received: from framsparc.ocf.llnl.gov.ocf by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA26137; Tue, 6 Jul 93 08:22:12 PDT Received: by framsparc.ocf.llnl.gov.ocf (4.1/SMI-4.1) id AA18665; Tue, 6 Jul 93 08:22:11 PDT From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian) Message-Id: <9307061522.AA18665@framsparc.ocf.llnl.gov.ocf> Subject: Future Prospect of Videoconference via Internet To: rem-conf@es.net Date: Tue, 6 Jul 1993 08:22:10 -0700 (PDT) X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9006 [The note attached below T. Utsumi's memo makes some interesting statements] >Date: Sat, 3 Jul 1993 23:08:39 -0400 >From: "T. UTSUMI" > >To: Multiple recipients of list DEVEL-L >Subject: Future Prospect of Videoconference via Internet GLOSAS/USA Memorandum Date: July 3, 1993 To: Electronic Colleagues From: Takeshi Utsumi, Ph.D. Subject: Future Prospect of Videoconferencing via Internet **************************************** Dear Colleagues: (1) I have previously announced our "Global Lecture Hall" (GLH) (TM) multipoint-to-multipoint multimedia interactive videoconference for our U.S.-Russia Electronic Distance Education System (EDES), which will be held at the occasion of TeleTeaching'93 in Trondheim, Norway, on August 21st. During the GLH, we will have a demonstration of videoconference via a packet-switching data telecommunication network, including Internet, albeit limited range yet, by Professor Kevin Jeffay of the University of North Carolina at Chapel Hill. (2) Mr. Gary Welz, President of the Science and Engineering Television Network, Inc. in New York City responded to my announcement and kindly sent me an abstract of his talk on the future prospect of the videocon- ferencing via Internet which talk is to be given at a conference in Italy in a few weeks. Since I consider that this "cutting-edge" technology of videoconferenc- ing without use of satellite and dish antenna, will provide not only our Global (electronic) University project, but also entire Internet community with profound benefits, I obtained his permission to distrib- ute the abstract here. (3) There are now several pairs of universities around the world developing this technology, such as Cornell University; Columbia University with Royal Institute of Technology in Stockholm, Sweden; University of Milano, Italy, with University of Utah, etc. (4) Next week, Mr. Welz and I will meet to discuss how we can accelerate their development, in such a way that the technology will be available to every Internet users in very near future. Please respond me if you are interested in joining our attempt. Best, Tak **************************************** ATTACHMENT Date: Fri, 02 Jul 93 13:06:57 EDT From: "Gary Welz, President, SETN" Subject: Television on the Internet To: "Dr. Takeshi Utsumi" Dear Dr. Utsumi, Thank you for the materials you sent me concerning your work and the materials you forwarded concerning other television broadcasts. Below you will find the abstract of the talk I will be giving in two weeks at the Conference of the International Federation of Science Editors at Consorzio Mario Negri Sud. You have my permission to pubish this abstract in GLOSAS NEWS if the editor so desires. I would welcome comments and advice from any who read it. SCIENCE AND ENGINEERING TELEVISION ON THE INTERNET: Scientific Publishing in a New Medium July 2, 1993 Mr. Gary Welz, President Science and Engineering Television Network, Inc. Many scientists and engineers create moving pictures in their research. These pictures range from the dazzling supercomputer animations produced by mathema- ticians and physicists to the video images of living cells shot by biologists through powerful microscopes. Until recently they have not had a means of publishing these moving pictures and could only distribute them by mailing their peers self-copied videocassettes. Today the increasing capacity of the Internet and rapidly evolving computer hardware and software is beginning to make possible the production and global distribution of digital audio and video. These developments allow scientists to publish research documents in the medium of television. Computers are now commonly used for videoconferencing - video cameras are frequently mounted on the tops of computer screens for precisely this purpose. Soon cameras will be as standard a computer accessory as microphones and speakers are now. Manufacturers of computers and peripherals offer a wide range of video support hardware and software. Among the more popular and least expensive are IBM's Action Media II card and Apple's Quicktime. These were designed for the multimedia market and have yet to be fully exploited for scientific communication - though their potential is enormous. Two products that may play a pivotal role in this are multimedia authoring tools from Macromedia, Authorware Professional and Director. These offer the ability to create documents (multimedia programs) that can be viewed on both Macintosh and Windows platforms with video playback software supplied with the program itself - thus alleviating the need for the viewer to obtain additional hardware or software. At the higher end are the Silicon Graphics Indigo video card and the Xvideo card made by Parallax for use on Sun work-stations - Sun also sells a multimedia authoring tool. Using products like those mentioned above, an author can digitize and compress a 30 minute video presentation into 300 megabytes of data. This will be good quality video, full color and nearly full motion with screen resolution about equal to NTSC, the American broadcast standard. This program can be down- loaded across a T3 (i.e. 45 Megabit/sec) link to a distant viewer's computer in 53 seconds. When the NSFNet is upgraded to OC3 (i.e. 155 Megabits/sec) during the next two years the required download time will drop to 15 seconds. When the US "data superhighway" with a 1 Gigabit/second data rate is opera- tional - some say in 4 years or less - the download time for a 30 minute video program will be only 2.4 seconds. At that point virtually unlimited use of the Internet for the exchange of video documents and live video multi-casting will be possible. One can anticipate that a number of new publication models will arise. Some may be patterned after print journals, offering selected viewer submissions, others will be familiar television formats like talk shows, news reports and live viewer "call-ins". Many of these video publica- tions will be organized by discipline, much as the current bulletin boards are, some will be interdisciplinary, like the journals Science and Nature. We are entering the age of video email, video computer bulletin boards and ultimately video journals with the same degree of editorial quality control that now exists in print. The average scientist is now able to put a televi- sion reception, production and distribution center on his desk for under $10,000. This has turned the computer into the television equivalent of the ham radio set. Television will no longer be only a mass audience medium, instead, in a very short time, it will be the most common and the the pre- ferred form of scientific communication. Mr. Gary Welz President Science and Engineering Television Network, Inc. c/o Association for Computing Machinery 1515 Broadway 17th floor New York, NY 10036 Phone (212) 626-0555 email setn@acmvm.bitnet Your comments and suggestions are welcome. Addendum: Below is a chart showing the download time for a 30 minute video program compressed into 300 megabytes of data and transmitted across lines of various bandwidths 14.4kb/s 128kb/s 1.5Mb/s 45Mb/s 155Mb/s 620Mb/s 1Gb/s Dial-up ISDN T1 T3 OC3(2yrs) OC12(4yrs?) Data SuperHway(4yrs?) 46hrs 5.2hrs 27min 53sec 15sec 4sec 2.4sec (Science and Engineering Television Network, Inc. is a non-profit consortium of professional societies including the Association for Computing Machinery, the American Physical Society, the American Mathematical Society and others. It's purpose is to develop, produce and distribute scientific publications in the medium of television.) ********************************************************************** * Takeshi Utsumi, Ph.D. * * President, Global University in the U.S.A. (GU/USA) * * A Divisional Activity of GLOSAS/USA * * (GLObal Systems Analysis and Simulation Association in the U.S.A.) * * 43-23 Colden Street, Flushing, NY 11355-3998, U.S.A. * * Phone: 718-939-0928; EIES: 492 or TAK; * * SprintMail: TUTSUMI/GU.USA/ASSOCIATES.TNET * * INTERNET: utsumi@columbia.edu * ********************************************************************** -- Mark Boolootian booloo@llnl.gov +1 510 423 1948 Disclaimer: booloo speaks for booloo and no other. From rem-conf-request@es.net Tue Jul 06 14:48:03 1993 Received: from hp.com by osi-west.es.net with SMTP (PP) id <07139-0@osi-west.es.net>; Tue, 6 Jul 1993 11:38:33 +0000 Received: from hpujjp0.yhp.hp.com by hp.com with SMTP (16.8/15.5+IOS 3.13) id AA04469; Tue, 6 Jul 93 11:38:31 -0700 Received: by hpujjp0.yhp.hp.com (16.6/15.5+IOS 3.22) id AA17425; Wed, 7 Jul 93 03:38:18 +0900 From: Yoshihiro Satoh Message-Id: <9307061838.AA17425@hpujjp0.yhp.hp.com> Subject: Re: New ivs version 3.2 To: Steinar.Haug@runit.sintef.no Date: Wed, 7 Jul 93 3:38:17 JST Cc: Thierry.Turletti@sophia.inria.fr, rem-conf@es.net, ivs-users@sophia.inria.fr, y_satoh@hpujisa.yhp.hp.com In-Reply-To: ; from "Steinar Haug" at Jul 6, 93 2:15 pm Mailer: Elm [revision: 66.36.1.1] > > > New site to retrieve ivs 3.2 is zenon.inria.fr (138.96.32.21) > > in the directory "rodeo/ivs" > > > > -rw-rw-r-- 1 turletti 0 Jul 2 10:03 VERSION_3.2 > > -rw-rw-r-- 1 turletti 1120053 Jul 2 15:48 ivs3.2-hps700.tar.Z > > What is necessary to run IVS on HP 700 hosts? HP Norway has been > completely unable to answer questions about the availability of IP > multicasting in HP-UX. > In this time unfortunately, HP-UX does not support IP multicasting, you can use single host connection only with ivs. Yoshihiro Satoh (e.mail: y_satoh@yhp.hp.com) Japan Technical Center / Yokogawa Hewlett Packard ------- From rem-conf-request@es.net Tue Jul 06 15:06:24 1993 Received: from gateway-gw.pictel.com by osi-west.es.net with SMTP (PP) id <07384-0@osi-west.es.net>; Tue, 6 Jul 1993 11:54:59 +0000 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.910919.1) id AA28440; Tue, 6 Jul 93 14:54:10 EDT Received: from geronimo.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA15181; Tue, 6 Jul 93 14:56:36 EDT Date: Tue, 6 Jul 93 14:56:36 EDT From: phillips@roadrunner.pictel.com (Carl Phillips) Message-Id: <9307061856.AA15181@roadrunner.pictel.com> To: rem-conf@es.net Subject: subscribe From rem-conf-request@es.net Tue Jul 06 15:58:18 1993 Received: from colossus.apple.com by osi-west.es.net with SMTP (PP) id <07862-0@osi-west.es.net>; Tue, 6 Jul 1993 12:47:05 +0000 Received: from talisman.kaleida.com by colossus.apple.com with SMTP (5.65/22-Jun-1993-eef) id AA29062; Tue, 6 Jul 93 12:39:30 -0700 for Received: from [130.43.11.117] (arodriguez.kaleida.com) by talisman.kaleida.com (4.1/SMI-4.1) id AA20933; Tue, 6 Jul 93 12:39:20 PDT Date: Tue, 6 Jul 93 12:39:20 PDT Message-Id: <9307061939.AA20933@talisman.kaleida.com> To: rem-conf@es.net From: aar@kaleida.com X-Sender: aar@talisman.kaleida.com unsubscribe ____________________________________________________ Arturo A. Rodriguez, Ph.D. Kaleida Labs, 1945 Charleston Road, Mt. View, CA 94043 internet: aar@kaleida.com ph: (415) 966-0866 From rem-conf-request@es.net Tue Jul 06 22:08:18 1993 Received: from world.std.com by osi-west.es.net with SMTP (PP) id <11700-0@osi-west.es.net>; Tue, 6 Jul 1993 19:00:11 +0000 Received: by world.std.com (5.65c/Spike-2.0) id AA06189; Tue, 6 Jul 1993 22:00:04 -0400 Date: Tue, 6 Jul 1993 22:00:04 -0400 From: oj@world.std.com (Oliver Jones) Message-Id: <199307070200.AA06189@world.std.com> To: phillips@roadrunner.pictel.com Cc: rem-conf@es.net In-Reply-To: Carl Phillips's message of Tue, 6 Jul 93 14:56:36 EDT <9307061856.AA15181@roadrunner.pictel.com> Subject: subscribe Date: Tue, 6 Jul 93 14:56:36 EDT From: phillips@roadrunner.pictel.com (Carl Phillips) Hi, Carl. How's it going? You have to send mail to rem-conf-request@es.net to subscribe to this mail list. Regards, Oliver Jones VP Engineering Vivo Software, Inc. Tel: +1(617)899-8900 x 21 411 Waverley Oaks Road Fax: +1(617)899-1400 Waltham, MA 02154 Email: oj@vivo.com From rem-conf-request@es.net Wed Jul 07 18:55:01 1993 Received: from ocfmail.ocf.llnl.gov by osi-west.es.net with SMTP (PP) id <22392-0@osi-west.es.net>; Wed, 7 Jul 1993 15:46:26 +0000 Received: from framsparc.ocf.llnl.gov.ocf by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA18640; Wed, 7 Jul 93 15:46:23 PDT Received: by framsparc.ocf.llnl.gov.ocf (4.1/SMI-4.1) id AA24127; Wed, 7 Jul 93 15:46:22 PDT From: booloo@framsparc.ocf.llnl.gov (Mark Boolootian) Message-Id: <9307072246.AA24127@framsparc.ocf.llnl.gov.ocf> Subject: Assistance for demonstration sought To: mbone@isi.edu, rem-conf@es.net Date: Wed, 7 Jul 1993 15:46:21 -0700 (PDT) X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1124 Greetings, On July 29th, I will be giving a group of gifted children a tour of parts of LLNL. I'd like to give them a demonstration of the MBONE, which I know will really floor them. If possible, I'd like to arrange for someone at a distant site (distant from California - preferably Europe, Asia, or Australia) to chat for a few minutes with the kids, hopefully someone who is video-capable so they can see to whom they are speaking. These kids will go nuts when they find they are able to talk to someone on the other side of the world while sitting in front of a computer. The demonstration shouldn't last more than 15 minutes, and it will take place between 0930 and 1130 PDT (which I think is 1730 to 1930 GMT). I will be able to nail down a more precise time in the next week or so. Perhaps I'd be better off just looking for people on MBone Audio the day the kids are here, but I'd feel more comfortable with a prior arrangement. If I can't make such arrangements, then we'll just wing it on the 29th. Any assistance is greatly appreciated. regards, mb -- Mark Boolootian booloo@llnl.gov +1 510 423 1948 From rem-conf-request@es.net Thu Jul 08 06:52:30 1993 Received: from itd.nrl.navy.mil by osi-west.es.net with SMTP (PP) id <28133-0@osi-west.es.net>; Thu, 8 Jul 1993 03:36:20 +0000 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA27563; Thu, 8 Jul 93 06:36:18 EDT Date: Thu, 8 Jul 93 06:36:18 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307081036.AA27563@itd.nrl.navy.mil> To: rem-conf@es.net Subject: novice multicast questions Friends, We're now starting to have fairly widespread use of IP based multicast conferencing and so forth here at NRL (thanks to the folks who have provided the IP multicast code, vat, nevot, sd, nv, and ivs). We'd like to setup some local-only multicast conferences using these same tools. I want to be sure that we confine our traffic locally so as not to impact folks outside NRL. I also want to be sure that we use IP multicast addresses that won't conflict with other uses in the Internet. In short, we want to be civilised and considerate in our use of the net. I would appreciate some guidance from experts in what steps I need to take to ensure that we do "the right thing" in our local usage. If I've overlooked a FAQ, please point me towards it and accept my apologies. I'm not sure if this is of general interest to the list, so please be thoughtful in where you send your replies. Thanks very much, Ran atkinson@itd.nrl.navy.mil Naval Research Laboratory Washington, DC, USA From rem-conf-request@es.net Thu Jul 08 07:54:32 1993 Received: from magician.dcs.qmw.ac.uk by osi-west.es.net with SMTP (PP) id <28499-0@osi-west.es.net>; Thu, 8 Jul 1993 04:39:05 +0000 Received: from dcs.qmw.ac.uk by magician.dcs.qmw.ac.uk with SMTP (PP) id <21714-0@magician.dcs.qmw.ac.uk>; Thu, 8 Jul 1993 12:38:49 +0100 Received: by aux21.dcs.qmw.ac.uk (5.64/QMW-Minimal-1.14) id AA00461; Thu, 8 Jul 93 12:35:09 BST From: sylvia@dcs.qmw.ac.uk Message-Id: <9307081135.AA00461@aux21.dcs.qmw.ac.uk> Subject: Re: novice multicast questions To: rem-conf@es.net Date: Thu, 8 Jul 1993 12:35:08 +0000 (BST) Cc: robb@dcs.qmw.ac.uk (Robert Bradshaw) In-Reply-To: <9307081036.AA27563@itd.nrl.navy.mil> from "Ran Atkinson" at Jul 8, 93 06:36:18 am X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 573 > >> > We'd like to setup some local-only multicast conferences using these > same tools. I want to be sure that we confine our traffic locally so > as not to impact folks outside NRL. I also want to be sure that we > use IP multicast addresses that won't conflict with other uses in the > Internet. We also are thinking along these lines, and would welcome some advice on these points. Many thanks, Sylvia Wilbur ------------------------------------- Dept. of Computer Science, Queen Mary and Westfield College, London Tel: +44 71 975 5202 Fax: +44 81 980 6533 From rem-conf-request@es.net Thu Jul 08 08:38:06 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <28754-0@osi-west.es.net>; Thu, 8 Jul 1993 05:15:27 +0000 Received: from mercedes.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 8 Jul 1993 13:15:14 +0100 To: sylvia@dcs.qmw.ac.uk cc: rem-conf@es.net, robb@dcs.qmw.ac.uk (Robert Bradshaw) Subject: Re: novice multicast questions In-reply-to: Your message of "Thu, 08 Jul 93 12:35:08 -0100." <9307081135.AA00461@aux21.dcs.qmw.ac.uk> Date: Thu, 08 Jul 93 13:15:12 +0100 From: Jon Crowcroft >> We'd like to setup some local-only multicast conferences using these >> same tools. I want to be sure that we confine our traffic locally so >> as not to impact folks outside NRL. I also want to be sure that we >> use IP multicast addresses that won't conflict with other uses in the >> Internet. Sylvia if you a single LAN site, just use ttl 1 and use sd (or other scheme) to get unique addresses if you are a site with internal hops, then you need to devise a ttl and threshol setting scheme... when we have a scheme for disjoint mbone trees, and can stop overloading ttl for scoping, bandwidth and media selection this will all be easier several schemes are being discussed next week at IETF... jon From rem-conf-request@es.net Thu Jul 08 08:41:29 1993 Received: from fs1.cam.nist.gov by osi-west.es.net with SMTP (PP) id <28759-0@osi-west.es.net>; Thu, 8 Jul 1993 05:16:16 +0000 Received: from muon.nist.gov by fs1.cam.nist.gov (4.1/SMI-DDN) id AA19231; Thu, 8 Jul 93 08:16:24 EDT Received: by muon.nist.gov (4.1/SMI-4.1-MHS-7.0) id AA17733; Thu, 8 Jul 93 08:21:17 EDT Date: Thu, 8 Jul 93 08:21:17 EDT From: chang@muon.nist.gov (Wo_Chang_x3439) Message-Id: <9307081221.AA17733@muon.nist.gov> To: rem-conf@es.net Subject: Re: novice multicast questions >> >>> >> We'd like to setup some local-only multicast conferences using these >> same tools. I want to be sure that we confine our traffic locally so >> as not to impact folks outside NRL. I also want to be sure that we >> use IP multicast addresses that won't conflict with other uses in the >> Internet. > > We also are thinking along these lines, and would welcome some advice on these > points. I'm third in motion. Thanks. --Wo Chang From rem-conf-request@es.net Thu Jul 08 13:10:01 1993 Received: from lbl.gov by osi-west.es.net with SMTP (PP) id <02114-0@osi-west.es.net>; Thu, 8 Jul 1993 09:56:29 +0000 Received: from [131.243.64.62] (moustic.lbl.gov) by lbl.gov (4.1/1.39) id AA10403; Thu, 8 Jul 93 10:01:17 PDT Message-Id: <9307081701.AA10403@lbl.gov> Date: Thu, 8 Jul 1993 09:56:25 -0800 To: rem-conf@es.net From: jnmoyne@lbl.gov (Jean-Noel Moyne) X-Sender: jnmoyne@net.lbl.gov Subject: Re: novice multicast questions At 6:36 AM 7/8/93 -0400, Ran Atkinson wrote: > We'd like to setup some local-only multicast conferences using these >same tools. I want to be sure that we confine our traffic locally so >as not to impact folks outside NRL. I also want to be sure that we >use IP multicast addresses that won't conflict with other uses in the >Internet. In short, we want to be civilised and considerate in our >use of the net. I would appreciate some guidance from experts in what >steps I need to take to ensure that we do "the right thing" in our >local usage. If I've overlooked a FAQ, please point me towards it and >accept my apologies. The way to control propagation of the multicast packets is with the TTL field of the IP packets, also called threshold in this case. The conventions are the following (right now): 0 restricted to the host 1 restricted to the lan 32 " " to the site 64 " " to the region 128 " " to the continent 256 not restricted. You set this threshold with sd when you create the session. And each time you setup a mrouted, you also setup thresholds for the different interfaces and tunels. I understand that those numbers and what they mean could be changed in the future. In any case, when you create a session for yourself, just make sure the 'site' button is checked in sd. JNM From rem-conf-request@es.net Thu Jul 08 13:48:39 1993 Received: from bnl.gov by osi-west.es.net with SMTP (PP) id <02722-0@osi-west.es.net>; Thu, 8 Jul 1993 10:36:34 +0000 Received: by bnl.gov (5.57/Ultrix3.0-C) id AA03594; Thu, 8 Jul 93 13:36:31 -0400 Received: by maeva.ccd.bnl.gov.ccd (4.1/SMI-4.1) id AA27045; Thu, 8 Jul 93 13:36:30 EDT Date: Thu, 8 Jul 93 13:36:30 EDT From: gc@maeva.ccd.bnl.gov (Graham Campbell) Message-Id: <9307081736.AA27045@maeva.ccd.bnl.gov.ccd> To: rem-conf@es.net Subject: IETF Schedule Could someone post the IETF videocast schedule. Thanks, Graham From rem-conf-request@es.net Thu Jul 08 13:52:47 1993 Received: from bnl.gov by osi-west.es.net with SMTP (PP) id <02767-0@osi-west.es.net>; Thu, 8 Jul 1993 10:40:35 +0000 Received: by bnl.gov (5.57/Ultrix3.0-C) id AA03685; Thu, 8 Jul 93 13:40:30 -0400 Received: by maeva.ccd.bnl.gov.ccd (4.1/SMI-4.1) id AA27053; Thu, 8 Jul 93 13:40:29 EDT Date: Thu, 8 Jul 93 13:40:29 EDT From: gc@maeva.ccd.bnl.gov (Graham Campbell) Message-Id: <9307081740.AA27053@maeva.ccd.bnl.gov.ccd> To: rem-conf@es.net Subject: SGI version of vat I am just bringing up the SGI version of the tools. I cannot have multiple audio conferences at once - get an error message from bind about address already in use. Is this a known problem or have I got something wrong? Graham From rem-conf-request@es.net Thu Jul 08 16:43:37 1993 Received: from motgate.mot.com by osi-west.es.net with SMTP (PP) id <05272-0@osi-west.es.net>; Thu, 8 Jul 1993 13:32:59 +0000 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA04832; Thu, 8 Jul 1993 15:32:57 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA11929; Thu, 8 Jul 1993 15:32:54 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA29773; Tue, 6 Jul 93 16:28:59 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA40080; Tue, 6 Jul 1993 16:28:57 MST Message-Id: <00112.2824820937.40080@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list), rem-conf@es.net (rem-conf) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 6 Jul 1993 16:28:33 MST Subject: IPSEC & Multipoint IPSEC & Multipoint Regarding IPSP and support for multipoint communications: >Date: 6 Jul 93 13:13:04 -0400 >From: Ran Atkinson >To: ipsec@ans.net, > >I have a couple of comments on the agenda... > > ... > ... Also conference control security > is a problem for the working group on internet conferencing not for > IPSP. The conference control problem is not necessarily best solved > at the IP layer and the IPSP WG should narrow its focus to IP security. and >From: Stuart Stubblebine > >1. I agree with Ran that conference control is not what needs to be >addressed in the IPSEC WG meeting. Instead the -shortened- item of >"multicasting" is the requirement/consideration at the network layer for the >scalability of secure conferencing. For secure conferencing, the security >services of data confidentiality and data origin authentication should scale >well for datagrams addressed to large multicast groups. (Furthermore, the >time to process the datagrams should be minimal.) I did not put *conference control* on the agenda, only multicast and conferencing. I agree that conference control is not in the scope of the IP Security Protocol (IPSP), but we need to document the IPSP mechanisms that support mulipoint communications. Not all IP communications are point-to-point. Broadcast, multicast, or multipoint communications all require special cryptographic considerations. The key used to decrypt multipoint traffic must be available to all recipients. This impacts the way that security identifiers need to be allocated in the IPSP clear header. Some portion of the identifier space needs to be reserved for multipoint communications. Conferencing is just one application of the multipoint mechanism and I will remove this specific reference from the agenda. Paul From rem-conf-request@es.net Thu Jul 08 16:46:55 1993 Received: from motgate.mot.com by osi-west.es.net with SMTP (PP) id <05276-0@osi-west.es.net>; Thu, 8 Jul 1993 13:33:04 +0000 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA04838; Thu, 8 Jul 1993 15:33:01 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA11935; Thu, 8 Jul 1993 15:32:58 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA29785; Tue, 6 Jul 93 16:52:40 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA40083; Tue, 6 Jul 1993 16:56:23 MST Message-Id: <00112.2824822583.40083@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list), rem-conf@es.net (rem-conf) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 6 Jul 1993 16:51:46 MST Subject: IPSEC & Multipoint IPSEC & Multipoint Regarding IPSP and support for multipoint communications: >Date: 6 Jul 93 13:13:04 -0400 >From: Ran Atkinson >To: ipsec@ans.net, > >I have a couple of comments on the agenda... > > ... > ... Also conference control security > is a problem for the working group on internet conferencing not for > IPSP. The conference control problem is not necessarily best solved > at the IP layer and the IPSP WG should narrow its focus to IP security. and >From: Stuart Stubblebine > >1. I agree with Ran that conference control is not what needs to be >addressed in the IPSEC WG meeting. Instead the -shortened- item of >"multicasting" is the requirement/consideration at the network layer for the >scalability of secure conferencing. For secure conferencing, the security >services of data confidentiality and data origin authentication should scale >well for datagrams addressed to large multicast groups. (Furthermore, the >time to process the datagrams should be minimal.) I did not put *conference control* on the agenda, only multicast and conferencing. I agree that conference control is not in the scope of the IP Security Protocol (IPSP), but we need to document the IPSP mechanisms that support mulipoint communications. Not all IP communications are point-to-point. Broadcast, multicast, or multipoint communications all require special cryptographic considerations. The key used to decrypt multipoint traffic must be available to all recipients. This impacts the way that security identifiers need to be allocated in the IPSP clear header. Some portion of the identifier space needs to be reserved for multipoint communications. Conferencing is just one application of the multipoint mechanism and I will remove this specific reference from the agenda. Paul From rem-conf-request@es.net Thu Jul 08 16:51:14 1993 Received: from motgate.mot.com by osi-west.es.net with SMTP (PP) id <05278-0@osi-west.es.net>; Thu, 8 Jul 1993 13:33:08 +0000 Received: from pobox.mot.com ([129.188.137.100]) by motgate.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA04844; Thu, 8 Jul 1993 15:33:05 -0500 Received: from phx.sectel.mot.com (rambo.phx.sectel.mot.com) by pobox.mot.com with SMTP (5.65c/IDA-1.4.4/MOT-2.15 for ) id AA11941; Thu, 8 Jul 1993 15:33:02 -0500 Received: from poncho.phx.sectel.mot.com by phx.sectel.mot.com (4.1/SMI-4.1) id AA29805; Tue, 6 Jul 93 17:11:27 MST Received: from SECTEL (QM 2.5.1) by poncho.phx.sectel.mot.com (SMTP\QM 1.1.3) id AA40085; Tue, 6 Jul 1993 17:15:09 MST Message-Id: <00112.2824823709.40085@poncho.phx.sectel.mot.com> X-Charset: MACINTOSH To: ipsec@ans.net (ip security mailing list), rem-conf@es.net (rem-conf) From: Paul_Lambert@poncho.phx.sectel.mot.com (Paul Lambert) Date: Tue, 6 Jul 1993 17:11:50 MST Subject: Re: IPSEC & Multipoint RE>IPSEC & Multipoint Oops, let me withdraw my previous comment about : >I did not put *conference control* on the agenda, only multicast and conferencing. The 9:45 IPSP agenda item had *Multicast and Conferencing* and the 11:00 Key management item did have *Multicast and Conference Control*. Sorry for the confusion and the double posting (a jittery mouse finger). I will remove conference control from the Key Management agenda item. While removing this item from the next meeting, it is still an interesting issue to consider the relationship of multipoint key distribution to conference control. The control of the multipoint key distribution ought to be a service that can be used by other applications, like conference control, to securely establish connectivity. Paul From rem-conf-request@es.net Fri Jul 09 10:06:20 1993 Received: from survis.surfnet.nl by osi-west.es.net with SMTP (PP) id <04787-0@osi-west.es.net>; Fri, 9 Jul 1993 06:43:13 +0000 Received: from localhost by survis.surfnet.nl with SMTP (PP) id <08478-0@survis.surfnet.nl>; Fri, 9 Jul 1993 15:43:05 +0200 To: rem-conf@es.net Subject: Multicast kernel for SPARCbook2 From: Erik-Jan.Bos@SURFnet.nl X-Mailer: MH X-Organization: SURFnet bv, Utrecht, The Netherlands X-Phone-Number: +31 30 310290 X-Fax-Number: +31 30 340903 Date: Fri, 09 Jul 93 15:43:04 +0200 Sender: Erik-Jan.Bos@SURFnet.nl Message-ID: <"survis.sur.482:09.06.93.13.43.07"@surfnet.nl> Rem-Conf, does any of you have a multicast capable kernel for a SPARCbook2 in the Amsterdam IETF terminal room available to us? We cannot seem to build one, due to the fact that the kernel source and object files are missing. Thanks in advance. __ Erik-Jan. From rem-conf-request@es.net Sat Jul 10 17:18:51 1993 Received: from survis.surfnet.nl by osi-west.es.net with SMTP (PP) id <11148-0@osi-west.es.net>; Sat, 10 Jul 1993 14:11:33 +0000 Received: from localhost by survis.surfnet.nl with SMTP (PP) id <20258-0@survis.surfnet.nl>; Sat, 10 Jul 1993 23:11:16 +0200 To: ietf@ietf.cnri.reston.va.us, rem-conf@es.net Subject: Amsterdam IETF Multicast announcement Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Sat, 10 Jul 93 23:11:13 +0200 From: "Erik Huizer (SURFnet BV)" Message-ID: <"survis.sur.261:10.06.93.21.11.17"@surfnet.nl> As in the past few IETF meetings, live audio and video from the plenary and some working group sessions of the Amsterdam IETF will be multicast out across the Internet. Two simultaneous working group sessions will be transmitted on separate "channels". Included below is the "IETF TV Guide". To receive this multicast, you must have an audio-capable workstation (SPARC, SGI, DEC 5000) with IP multicast software added to the operating system. You must also be connected to the semi-permanent virtual IP multicast network known as the MBONE. Since this effort has been going on for some time now, it is hoped that all those who are interested have already arranged to be connected. If not, contact your network provider to see if they are providing MBONE connections, but please don't be disappointed if they can't respond before IETF. The MBONE is currently structured to follow network topology as best as it can. Please don't break this structure by trying to connect just anywhere. Contact your network provider for the best MBONE connection for your case. More information about the MBONE, including what hardware and software is required to receive the multicast, is available by anonymous FTP from venera.isi.edu in the file mbone/faq.txt. For each of the two channels, "IETF Channel 1" and "IETF Channel 2", there may be three concurrent multicast streams: - low-rate audio for those with slow links (GSM encoding; approx 16 kbps) - "normal"-rate audio (PCM encoding; approx. 70 kbps) - video (one of two encodings; approx. 25 to 128 kbps) During plenary sessions, when there is only one audio stream, both video channels may be active with two views from the plenary room. Each of these streams will be be advertised as a session in the LBL Session Directory tool, sd, which can be used to automatically invoke the audio and video programs with the appropriate address and TTL parameters. For those who want or need to invoke the programs manually, these parameters are listed as an appendix to this message. The audio will be originated by the vat program from LBL; you may use vat or any other vat-compatible application to listen in and talk back. Video will be transmitted and received with program nv, version 3.2, from Xerox PARC (older versions will not be able to receive the signal when transmitted in color). Following is the tentative schedule of plenary meetings and working group sessions to be transmitted; to interpret the acronyms, see the IETF Agenda. This schedule is also subject to Murphy's Law. MONDAY 0900-0930 0930-1200 1330-1530 1600-1800 - --------+-------------+-------------+-------------+-------------| CHAN 1 |intro plenary|tech. plenary| ?# atm | # sip | - ----------------------+-------------+-------------+-------------+ CHAN 2 | # " | # " | uri | uri | - --------+-------------+-------------+-------------+-------------| TUESDAY 0900-1200 1330-1530 1600-1800 1930-2200 - --------+------------+-------------+-------------+-------------+ CHAN 1 | pip | # pip | # tuba | madman | - --------+------------+-------------+ ------------+-------------+ CHAN 2 | # mmusic | ? atm | idmr | ? multiapp | - --------+------------+-------------+-------------+-------------+ WEDNESDAY 0900-1200 1330-1530 1600-1800 1930-2200 - --------+-------------+-------------+-------------+-------------+ CHAN 1 | sdr | osiextnd | mobileip | ipdecide | - --------+-------------+-------------+-------------+-------------+ CHAN 2 |# mmusic | ?# atm | # idmr | ? iiir | - --------+-------------+-------------+-------------+-------------+ THURSDAY 0900-0930 0930-1200 1330-1530 1600-1700 1700-1930 - --------+-------------+-------------+-------------+-------------+------------+ CHAN 1 |tech. plenary| mobileip | sip |tech. plenary|open plenary| - --------+-------------+-------------+-------------+-------------+------------+ CHAN 2 | # " | # x400ops | isn | # " | # " | - --------+-------------+-------------+-------------+-------------+------------+ FRIDAY 0900-1200 - --------+-------------+ ? means that this is not confirmed yet! CHAN 1 |tech. plenary| # means replay later that day - --------+-------------+ CHAN 2 | " | - --------+-------------+ ------------------------------------------------------------------------------ Starting ca. 30 minutes after the last session of the day we will replay on two channels some of the sessions broadcasted earlier the same day. As we have only 4 hour VCRs, we had to make a choice as to what will be replayed. Sessions indicated with a # in the schedule above will be replayed 30 minutes after the last session on one of the two channels. On friday there will be no replay. So the tentative replay schedule looks like this: Monday Tuesday Wednesday Thursday ca 1800 ca 2230 ca 2230 ca 2000 Chan 1 atm,sip pip,tuba atm,idmr afternoon&open plenary Chan 2 plenary mmusic mmusic morning plenary, x400ops ------------------------------------------------------------------------------ Advice for participants: Please keep your microphones muted and your video transmissions disabled during the plenaries and working group sessions, unless or until invited to respond by the chair of the session. Vat users can disable reception of accidental sources of audio multicasts (such as people who forget to mute their mics) by clicking in the box next to that source's name. If reception is lossy, selecting "Lecture Mode" may improve it. Any comments or reports of problems should be emailed to rem-conf@es.net, though response cannot be assured. ------------- Erik From rem-conf-request@es.net Sun Jul 11 06:44:22 1993 Received: from survis.surfnet.nl by osi-west.es.net with SMTP (PP) id <15360-0@osi-west.es.net>; Sun, 11 Jul 1993 03:37:44 +0000 Received: from localhost by survis.surfnet.nl with SMTP (PP) id <23075-0@survis.surfnet.nl>; Sun, 11 Jul 1993 12:37:27 +0200 To: arc@xingping.esd.sgi.com (Andrew Cherenson) Cc: ietf@ietf.cnri.reston.va.us, rem-conf@es.net Subject: Re: Amsterdam IETF Multicast announcement In-reply-to: Your message of Sat, 10 Jul 93 15:01:55 -0700. <9307102201.AA18175@xingping.esd.sgi.com> Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Sun, 11 Jul 93 12:37:25 +0200 From: "Erik Huizer (SURFnet BV)" Message-ID: <"survis.sur.078:11.06.93.10.37.28"@surfnet.nl> ==> From: Andrew Cherenson > >Each of these streams will be be advertised as a session in the LBL Session > >Directory tool, sd, which can be used to automatically invoke the audio and > >video programs with the appropriate address and TTL parameters. For those > >who want or need to invoke the programs manually, these parameters are > >listed as an appendix to this message. > > The parameters were not listed in the message. > rem-conf@es.net Ooops: Channel 1 Video : ttl 127 Audio : ttl 191 GSM audio : ttl 225 Channel 2 Video : ttl 95 Audio : ttl 159 GSM audio : ttl 223 > >Following is the tentative schedule of plenary meetings and working group > > > >MONDAY 0900-0930 0930-1200 1330-1530 1600-1800 > > Are these times in GMT? If not, what's the time difference for Amsterdam? No they are in local Amsterdam time (GMT -2 during DST). Thus for the East coast time subtract 6 hours, for the west coast substract 9 hours. Erik From rem-conf-request@es.net Sun Jul 11 14:54:24 1993 Received: from tivoli.tivoli.com by osi-west.es.net with SMTP (PP) id <16645-0@osi-west.es.net>; Sun, 11 Jul 1993 11:46:17 +0000 Received: from mojo.ots.utexas.edu by tivoli.com (4.1/SMI-4.1) id AA03565; Sun, 11 Jul 93 10:04:55 CDT Received: by mojo.ots.utexas.edu id AA29312 (5.65+/IDA-1.3.5); Sun, 11 Jul 93 09:54:27 -0500 Received: from moe.rice.edu by mojo.ots.utexas.edu with SMTP id AA29308 (5.65+/IDA-1.3.5 for /usr/lib/sendmail -odq -oi -fowner-thenet-ops thenet-ops-list); Sun, 11 Jul 93 09:54:07 -0500 Received: from SESQUI.NET by moe.rice.edu (AA08923); Sun, 11 Jul 93 09:51:27 CDT Received: from brazos.is.rice.edu by SESQUI.NET (AA26194); Sun, 11 Jul 93 09:51:18 CDT Received: by brazos.is.rice.edu (AA26593); Sun, 11 Jul 93 09:51:09 CDT Received: from moe.rice.edu by is.rice.edu (AA28255); Sat, 10 Jul 93 17:29:58 CDT Received: from osi-west.es.net by moe.rice.edu (AA05938); Sat, 10 Jul 93 17:29:54 CDT Received: from survis.surfnet.nl by osi-west.es.net with SMTP (PP) id <11148-0@osi-west.es.net>; Sat, 10 Jul 1993 14:11:33 +0000 Received: from localhost by survis.surfnet.nl with SMTP (PP) id <20258-0@survis.surfnet.nl>; Sat, 10 Jul 1993 23:11:16 +0200 To: ietf@ietf.cnri.reston.va.us, rem-conf@es.net Subject: Amsterdam IETF Multicast announcement Organisation: SURFnet bv Address: Cluetinckborch, P.O. Box 19035, 3501 DA Utrecht, NL Phone: +31 30 310290 Telefax: +31 30 340903 Date: Sat, 10 Jul 93 23:11:13 +0200 From: "Erik Huizer (SURFnet BV)" Message-Id: <"survis.sur.261:10.06.93.21.11.17"@surfnet.nl> Sender: bmanning@is.rice.edu As in the past few IETF meetings, live audio and video from the plenary and some working group sessions of the Amsterdam IETF will be multicast out across the Internet. Two simultaneous working group sessions will be transmitted on separate "channels". Included below is the "IETF TV Guide". To receive this multicast, you must have an audio-capable workstation (SPARC, SGI, DEC 5000) with IP multicast software added to the operating system. You must also be connected to the semi-permanent virtual IP multicast network known as the MBONE. Since this effort has been going on for some time now, it is hoped that all those who are interested have already arranged to be connected. If not, contact your network provider to see if they are providing MBONE connections, but please don't be disappointed if they can't respond before IETF. The MBONE is currently structured to follow network topology as best as it can. Please don't break this structure by trying to connect just anywhere. Contact your network provider for the best MBONE connection for your case. More information about the MBONE, including what hardware and software is required to receive the multicast, is available by anonymous FTP from venera.isi.edu in the file mbone/faq.txt. For each of the two channels, "IETF Channel 1" and "IETF Channel 2", there may be three concurrent multicast streams: - low-rate audio for those with slow links (GSM encoding; approx 16 kbps) - "normal"-rate audio (PCM encoding; approx. 70 kbps) - video (one of two encodings; approx. 25 to 128 kbps) During plenary sessions, when there is only one audio stream, both video channels may be active with two views from the plenary room. Each of these streams will be be advertised as a session in the LBL Session Directory tool, sd, which can be used to automatically invoke the audio and video programs with the appropriate address and TTL parameters. For those who want or need to invoke the programs manually, these parameters are listed as an appendix to this message. The audio will be originated by the vat program from LBL; you may use vat or any other vat-compatible application to listen in and talk back. Video will be transmitted and received with program nv, version 3.2, from Xerox PARC (older versions will not be able to receive the signal when transmitted in color). Following is the tentative schedule of plenary meetings and working group sessions to be transmitted; to interpret the acronyms, see the IETF Agenda. This schedule is also subject to Murphy's Law. MONDAY 0900-0930 0930-1200 1330-1530 1600-1800 - --------+-------------+-------------+-------------+-------------| CHAN 1 |intro plenary|tech. plenary| ?# atm | # sip | - ----------------------+-------------+-------------+-------------+ CHAN 2 | # " | # " | uri | uri | - --------+-------------+-------------+-------------+-------------| TUESDAY 0900-1200 1330-1530 1600-1800 1930-2200 - --------+------------+-------------+-------------+-------------+ CHAN 1 | pip | # pip | # tuba | madman | - --------+------------+-------------+ ------------+-------------+ CHAN 2 | # mmusic | ? atm | idmr | ? multiapp | - --------+------------+-------------+-------------+-------------+ WEDNESDAY 0900-1200 1330-1530 1600-1800 1930-2200 - --------+-------------+-------------+-------------+-------------+ CHAN 1 | sdr | osiextnd | mobileip | ipdecide | - --------+-------------+-------------+-------------+-------------+ CHAN 2 |# mmusic | ?# atm | # idmr | ? iiir | - --------+-------------+-------------+-------------+-------------+ THURSDAY 0900-0930 0930-1200 1330-1530 1600-1700 1700-1930 - --------+-------------+-------------+-------------+-------------+------------+ CHAN 1 |tech. plenary| mobileip | sip |tech. plenary|open plenary| - --------+-------------+-------------+-------------+-------------+------------+ CHAN 2 | # " | # x400ops | isn | # " | # " | - --------+-------------+-------------+-------------+-------------+------------+ FRIDAY 0900-1200 - --------+-------------+ ? means that this is not confirmed yet! CHAN 1 |tech. plenary| # means replay later that day - --------+-------------+ CHAN 2 | " | - --------+-------------+ ------------------------------------------------------------------------------ Starting ca. 30 minutes after the last session of the day we will replay on two channels some of the sessions broadcasted earlier the same day. As we have only 4 hour VCRs, we had to make a choice as to what will be replayed. Sessions indicated with a # in the schedule above will be replayed 30 minutes after the last session on one of the two channels. On friday there will be no replay. So the tentative replay schedule looks like this: Monday Tuesday Wednesday Thursday ca 1800 ca 2230 ca 2230 ca 2000 Chan 1 atm,sip pip,tuba atm,idmr afternoon&open plenary Chan 2 plenary mmusic mmusic morning plenary, x400ops ------------------------------------------------------------------------------ Advice for participants: Please keep your microphones muted and your video transmissions disabled during the plenaries and working group sessions, unless or until invited to respond by the chair of the session. Vat users can disable reception of accidental sources of audio multicasts (such as people who forget to mute their mics) by clicking in the box next to that source's name. If reception is lossy, selecting "Lecture Mode" may improve it. Any comments or reports of problems should be emailed to rem-conf@es.net, though response cannot be assured. ------------- Erik From rem-conf-request@es.net Sun Jul 11 21:03:44 1993 Received: from research.att.com by osi-west.es.net with SMTP (PP) id <17590-0@osi-west.es.net>; Sun, 11 Jul 1993 17:58:03 +0000 Received: by inet; Sun Jul 11 20:57 EDT 1993 Date: Sun, 11 Jul 93 20:57:22 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: rem-conf@es.net Subject: SunOS 4.1.3 multicast support for FDDI? When installing the SunOS 4.1.3 multicast extensions, the FDDI driver (bf0 device) no longer loads: bf: ld: Undefined symbol _addmultiaddr _delmultiaddr Is there a modified version of the FDDI device driver that supports these functions? Or a version with dummy calls so that we can at least use the FDDI device in unicast mode while the multicast kernel is running. Thanks. Henning Schulzrinne hgs@research.att.com From rem-conf-request@es.net Sun Jul 11 23:03:10 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <17985-0@osi-west.es.net>; Sun, 11 Jul 1993 19:56:03 +0000 Received: from mmc.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Sun, 11 Jul 1993 19:55:59 -0700 Posted-Date: Sun 11 Jul 93 19:55:55-PDT Received: by mmc.isi.edu (4.1/4.0.3-4) id ; Sun, 11 Jul 93 19:55:56 PDT Date: Sun 11 Jul 93 19:55:55-PDT From: Stephen Casner Subject: Re: SunOS 4.1.3 multicast support for FDDI? To: hgs@research.att.com, rem-conf@es.net Message-Id: <742445755.0.CASNER@MMC.ISI.EDU> In-Reply-To: <199307120108.AA05779@venera.isi.edu> Mail-System-Version: Henning, Anders Klemets developed a patch to allow the FDDI device to be used in unicast mode. In another message, I'll forward to you the message from Anders explaining it. -- Steve ------- From rem-conf-request@es.net Mon Jul 12 04:01:07 1993 Received: from apple.com by osi-west.es.net with SMTP (PP) id <19269-0@osi-west.es.net>; Mon, 12 Jul 1993 00:58:14 +0000 Received: by apple.com with SMTP (5.61/22-Jun-1993-eef) id AA18689; Mon, 12 Jul 93 00:58:11 -0700 for rem-conf@es.net From: "Erik E. Fair" (Your Friendly Postmaster) Subject: problems so far To: rem-conf@es.net Date: Mon, 12 Jul 93 00:58:09 -0700 Message-Id: <18687.742463889@apple.com> Sender: fair@apple.com 1. sd is not finding the IETF stuff, during the 'casts - probably the packets are getting lost. Can someone please post a copy of their .sd_cache here? 2. Speakers in Amsterdam are encouraged to: 2.1. Enunciate carefully. 2.2. Stand Still 2.3. Once you put your slides up, Don't Touch Them! The object of all of these requests is to improve the signal quality out here in mbone land... Erik E. Fair apple!fair fair@apple.com From rem-conf-request@es.net Mon Jul 12 04:46:02 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <19393-0@osi-west.es.net>; Mon, 12 Jul 1993 01:21:28 +0000 Received: from mmc.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Mon, 12 Jul 1993 01:21:17 -0700 Posted-Date: Mon 12 Jul 93 01:21:11-PDT Received: by mmc.isi.edu (4.1/4.0.3-4) id ; Mon, 12 Jul 93 01:21:13 PDT Date: Mon 12 Jul 93 01:21:11-PDT From: Stephen Casner Subject: Re: problems so far To: FAIR@apple.com, rem-conf@es.net Message-Id: <742465271.0.CASNER@MMC.ISI.EDU> In-Reply-To: <18687.742463889@apple.com> Mail-System-Version: Erik, Thanks for the report. What loss rate does vat report for you? (Type 's' in vat window; output is on its stdout.) I'm getting a loss rate of 1% or less, so I think I've heard most everything. I do hear packet drops, but most don't impact intelligibility. Standing still would help, but isn't likely. Not touching slides is a good guidline. My .sd_cache is enclosed. -- Steve n=2148114532 2148114532 734117628 s=** Please don't start a radio session i=There is not enough bandwidth to allow more than one global radio session at a time. See Radio Free Vat session to get a time slot. For further explanation, email casner@isi.edu o=casner@oak.isi.edu c=224.2.174.143 191 0 0 m=audio 52858 17126 n=2225079044 2225079044 742274226 s=GMS-4 Composite i=JPEG Weather images of the Earth o=wkd@dorsai.net.Hawaii.Edu c=224.2.158.99 127 0 0 m=video 37793 9762 a=fmt:jpg n=2225079044 2225079044 742274108 s=GMS-4 IR i=JPEG Infrared satellite images of Earth o=wkd@dorsai.net.Hawaii.Edu c=224.2.170.143 127 0 0 m=video 41224 5928 a=fmt:jpg n=2225079044 2225079044 742273989 s=GMS-4 VIS i=JPEG Visible Satellite Images of Earth o=wkd@dorsai.net.Hawaii.Edu c=224.2.255.227 127 0 0 m=video 54008 16433 a=fmt:jpg n=3225506057 3225506057 742274068 s=IETF Channel 1 Audio i=27th IETF, Amsterdam, The Netherlands (test signal, every hour on the hour) o=bos@surgeon.surfnet.nl c=224.0.1.11 191 2828438896 2828870896 m=audio 4110 0 a=fmt:pcm n=3225506057 3225506057 742274211 s=IETF Channel 1 GSM Audio i=27th IETF, Amsterdam, The Netherlands (no signal currently) o=bos@surgeon.surfnet.nl c=224.0.1.10 255 2828438896 2828870896 m=audio 4100 0 a=fmt:gsm n=3225506057 3225506057 742274107 s=IETF Channel 1 Video i=27th IETF, Amsterdam, The Netherlands (test signal, every hour on the hour) o=bos@surgeon.surfnet.nl c=224.0.1.12 127 2828438896 2828870896 m=video 4444 0 a=fmt:nv n=3225506057 3225506057 742274138 s=IETF Channel 2 Audio i=27th IETF, Amsterdam, The Netherlands (test signal, every hour on the hour) o=bos@surgeon.surfnet.nl c=224.0.1.14 159 2828438896 2828870896 m=audio 4140 0 a=fmt:pcm n=3225506057 3225506057 742273949 s=IETF Channel 2 GSM Audio i=27th IETF, Amsterdam, The Netherlands (no signal currently) o=bos@surgeon.surfnet.nl c=224.0.1.13 223 2828438896 2828870896 m=audio 4130 0 a=fmt:gsm n=3225506057 3225506057 742274179 s=IETF Channel 2 Video i=27th IETF, Amsterdam, The Netherlands (test signal, every hour on the hour) o=bos@surgeon.surfnet.nl c=224.0.1.15 95 2828438896 2828870896 m=video 4444 0 a=fmt:nv n=2147708930 2147708930 742274041 s=MBone Audio i=Audio conference on the default vat multicast address o=van@ee.lbl.gov c=224.2.0.1 191 0 0 m=audio 3456 0 n=2210144822 2210144822 742274258 s=Mbone DE Audio i=German language audio channel o=eckert@faui45r.informatik.uni-erlangen.de c=224.2.176.171 127 2828136496 2829346096 m=audio 3456 0 n=218264772 218264772 742274205 s=MBone Video i=NV 3.x format video on the default nv multicast address o=frederic@ecco.parc.Xerox.COM c=224.2.1.1 127 0 0 m=video 4444 0 a=fmt:nv n=2157249554 2157249554 742274219 s=Radio Free Vat i=Music for your Listening Pleasure. For more information (or to get a slot) send mail to vat-radio-request@elxr.jpl.nasa.gov o=dave@elxr.jpl.nasa.gov c=224.2.253.119 127 0 0 m=audio 42147 56416 n=2147709061 2147709061 742274091 s=UCB Audio i=Drop-in audio session for UCB/LBL discussions. o=mccanne@spin.ee.lbl.gov c=224.2.237.69 72 2827974500 2829184100 m=audio 35921 20291 ------- From rem-conf-request@es.net Mon Jul 12 05:19:50 1993 Received: from PANDANUS.NTU.EDU.AU by osi-west.es.net with SMTP (PP) id <19683-0@osi-west.es.net>; Mon, 12 Jul 1993 02:15:38 +0000 Received: from nutmeg.cs.ntu.edu.au by pandanus.cs.ntu.edu.au with SMTP id AA04551 (5.65c/IDA-1.4.4 for ); Mon, 12 Jul 1993 18:45:30 +0930 Received: by nutmeg.cs.ntu.edu.au (4.1/SMI-4.1) id AA29504; Mon, 12 Jul 93 18:49:01 CST From: malcolm@nutmeg.cs.ntu.edu.au (Malcolm Caldwell) Message-Id: <9307120919.AA29504@nutmeg.cs.ntu.edu.au> Subject: Nothing. To: rem-conf@es.net Date: Mon, 12 Jul 1993 18:49:00 +0930 (CST) Reply-To: malcolm@PANDANUS.NTU.EDU.AU (Malcolm Caldwell) X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 595 Hello all. I am not getting any audio through on IETF Channel 1 GSM Audio, and I am fairly sure that none is comming in on Channel 2 either. I have change my vat name asking if it was just me and a few others changed theirs indicating that they were getting nothing as well. Is the rebroadcast of the PCM audio to GSM audio going? -- Malcolm Caldwell |Email:malcolm@it.ntu.edu.au Technical Officer |Ph: +61 89 466546 School of Information Technology |Fax: +61 89 270612 Northern Territory University,Darwin|Mail:PO BOX 40146 CASUARINA 0811 Australia From rem-conf-request@es.net Mon Jul 12 05:52:52 1993 Received: from survis.surfnet.nl by osi-west.es.net with SMTP (PP) id <19886-0@osi-west.es.net>; Mon, 12 Jul 1993 02:42:17 +0000 Received: from localhost by survis.surfnet.nl with SMTP (PP) id <06582-0@survis.surfnet.nl>; Mon, 12 Jul 1993 11:42:00 +0200 To: "Erik E. Fair" (Your Friendly Postmaster) Cc: rem-conf@es.net Subject: Re: problems so far In-reply-to: Your message of Mon, 12 Jul 93 00:58:09 -0700. From: Erik-Jan.Bos@SURFnet.nl X-Mailer: MH X-Organization: SURFnet bv, Utrecht, The Netherlands X-Phone-Number: +31 30 310290 X-Fax-Number: +31 30 340903 Date: Mon, 12 Jul 93 11:41:57 +0200 Sender: Erik-Jan.Bos@SURFnet.nl Message-ID: <"survis.sur.586:12.06.93.09.42.02"@surfnet.nl> Erik, > 1. sd is not finding the IETF stuff, during the 'casts - probably the > packets are getting lost. Can someone please post a copy of their > .sd_cache here? The mrouted on my host back home crashed. Here is the .sd_cache: n=3225506057 3225506057 742456168 s=IETF Channel 1 Audio i=27th IETF, Amsterdam, The Netherlands o=bos@surgeon.surfnet.nl c=224.0.1.11 191 2828438907 2828870907 m=audio 4110 0 n=3225506057 3225506057 742456199 s=IETF Channel 1 GSM Audio i=27th IETF, Amsterdam, The Netherlands o=bos@surgeon.surfnet.nl c=224.0.1.10 255 2828438947 2828870947 m=audio 4100 0 n=3225506057 3225506057 742456221 s=IETF Channel 1 Video i=27th IETF, Amsterdam, The Netherlands o=bos@surgeon.surfnet.nl c=224.0.1.12 127 2828438908 2828870908 m=video 4444 0 n=3225506057 3225506057 742456240 s=IETF Channel 2 Audio i=27th IETF, Amsterdam, The Netherlands o=bos@surgeon.surfnet.nl c=224.0.1.14 159 2828438925 2828870925 m=audio 4140 0 n=3225506057 3225506057 742456251 s=IETF Channel 2 GSM Audio i=27th IETF, Amsterdam, The Netherlands o=bos@surgeon.surfnet.nl c=224.0.1.13 223 2828438939 2828870939 m=audio 4130 0 n=3225506057 3225506057 742456264 s=IETF Channel 2 Video i=27th IETF, Amsterdam, The Netherlands o=bos@surgeon.surfnet.nl c=224.0.1.15 95 2828438951 2828870951 m=video 4444 0 n=3225506057 3225506057 742456408 s=IETF Channel 1 Audio i=27th IETF, Amsterdam, The Netherlands o=bos@surgeon.surfnet.nl c=224.0.1.11 191 2828438911 2828870911 m=audio 4110 0 Since the mrouted on surgeon.surfnet.nl is up again you should be able to see the entries in vat. > 2. Speakers in Amsterdam are encouraged to: > > 2.1. Enunciate carefully. > 2.2. Stand Still > 2.3. Once you put your slides up, Don't Touch Them! > > The object of all of these requests is to improve the signal quality > out here in mbone land... I'll talk to the organisers on this. __ Erik-Jan @ Amsterdam IETF terminal room. From rem-conf-request@es.net Mon Jul 12 06:02:17 1993 Received: from tadpole.Tadpole.COM by osi-west.es.net with SMTP (PP) id <19929-0@osi-west.es.net>; Mon, 12 Jul 1993 02:49:08 +0000 Received: from ono-sendai (ono-sendai.tadtec.co.uk) by tadpole.tadpole.com (4.1/SMI-4.1) id AA20466; Mon, 12 Jul 93 04:48:58 CDT Received: by ono-sendai (4.1/SPARCbook_POP1.3) id AA29311; Mon, 12 Jul 93 09:48:42 GMT Date: Mon, 12 Jul 93 09:48:42 GMT From: jim@tadpole.com Message-Id: <9307120948.AA29311@ono-sendai> To: com-priv@psi.com Subject: SIGkids Cc: coco@siggraph.org, fringeware@wixer.bga.com, jim@tadpole.com, mbone@isi.edu, rem-conf@es.net [ Appologies to those of you on the mbone list who may have already read this, and those of you who otherwise receive multiple copies. If you're on mbone@isi.edu, please read through the message, there is a call for your participation at the bottom. --jim ] Last summer, ACM SIGGRAPH (Association for Computing Machinery's Special Interest Group on Computer Graphics) offered the future to a group of young students, grades 6-12, by inviting them to participate in the SIGKids '92 Learning Lab Workshop. The workshop took place on site and ran concurrently with the SIGGRAPH '92 Conference in Chicago. Computers, art, sound, video, multimedia, LEGO/Logo, digital journal keeping, access to the InterNet, and interactive projects were explored by fifty computer using students. Learning Matters, the new PBS educational program, was on hand to document the week. SIGKids aired on over 300 PBS stations nationwide during the month of November 1992. Sixteen hours of documentary footage of the event was recorded and will be available at SIGKids this summer. This summer the 20th Annual International Conference On Computer Graphics And Interactive Techniques, SIGGRAPH '93, will take place in Anaheim, California, August 1-6. SIGKids has once again been invited to participate. SIGKids will have over 6,500 square feet across the aisle from the main exhibit floor. 30,000 attendees will see first hand, what can be done with computers and video in the classroom when students are allowed to visualize what they are learning using a variety of powerful hardware and software 'tools' instead of only one type of computer or drill and practice 'applications.' SIGKids is about creating a technology rich environment in which children can construct the future through artistic expression. This summer, SIGKids will show students using visualization technology and graphical interfaces to study virtual reality, real time simulation, and tool building. They are designing a networking highway, learning about long distance collaboration and identifying new interface needs. With SIGKids as the vehicle we have the opportunity to design new models and experiment with new approaches to more effectively integrate technology into our schools. SIGKids objective is to collect and modify tools for remote experience and remote learning and to allow students to shape their use. Many students are hard at work getting their projects ready to show at the conference. Students from Alta High School in Salt Lake City will attend this year and spend the week exploring high end graphics packages and computers. Rowland High School's Animation and math students will present their award winning productions combining computer graphics, animation, and claymation. Both schools sent in videos of their work last year. Another group of students from Santa Cruz have been building a Multimedia Fun House, complete with mirrors! A group of students with and without disabilities from the Santa Monica Computer Access Center will be demonstrating the various enabling technologies they use to make their projects. Designers at Walt Disney Imagineering are mentoring a group of students from several high schools in their area. Students in Boulder Colorado will be working on a telepainting project using a T1 line that SIGKids will have access to via Ethernet. South Tech High School of Eugene Oregon will be showing their CD-Rom year books. Teachers and other visitors to SIGKids '92 were most impressed by the child-centered and collaborative learning demonstrated by students in our technology-rich learning culture. The most often asked question heard, was "what are computers teaching these kids?" It is not an atypical question in education. This is why the documentary footage we are shooting is important. If educators view a tape about students learning by doing and exploring, problem solving and building, then their schools and the purchasers of the technology might let go of two fears. One fear is that unless all teachers understand what to do with computers, the students will just have to wait. The second myth is that computers are capable of teaching. This year SIGKids will be situated across the aisle from the main SIGGRAPH '93 Anaheim Conference exhibit floor. We will have almost 7,000 square feet. We hope that your organization will join us as a SIGKids partner. SIGKids '93 will be the kick off event of a national educational networking (computer and video) demonstration leading up to Showcase at SIGGRAPH '94 Orlando. I'm currently assisting by attempting to bring the Internet to SIGkids. I'm hoping to connect to the mbone in order to provide face-to-face connectivity between researchers and other explores, and the young pepole and techers at SIGkids. In order to do this, I need a group of 'remote (mbone-based) guides'. These individuals would be available to answer student questions in real-time. If you'ld like to participate as a guide, please send me your name, areas of interest or expertise, and availability via email. If you have other ideas about how to showcase Internet technology during the week of SIGkids, please send them to both Coco and I, via email or fax. Jim Thompson For more information contact: Coco Conn - Homer & Associates SIGKids Chair '93 2207 Willetta Ave. Hollywood, CA 90068 213.466.3813 Voice 213.462.2109 Fax coco@siggraph.org From rem-conf-request@es.net Mon Jul 12 06:38:29 1993 Received: from ibm1.scri.fsu.edu by osi-west.es.net with SMTP (PP) id <20223-0@osi-west.es.net>; Mon, 12 Jul 1993 03:24:00 +0000 Received: by ibm1.scri.fsu.edu id AA86218 (5.65c/IDA-1.4.4 for rem-conf@es.net); Mon, 12 Jul 1993 06:23:48 -0400 Date: Mon, 12 Jul 1993 06:23:48 -0400 From: Ken Hays Message-Id: <199307121023.AA86218@ibm1.scri.fsu.edu> To: malcolm@PANDANUS.NTU.EDU.AU (Malcolm Caldwell) Cc: rem-conf@es.net In-Reply-To: <9307121011.AA00651@nutmeg.cs.ntu.edu.au> Subject: Re: Nothing. Reply-To: Ken Hays Malcolm, Got a chance to ask Daniel over the PCM channel and he agrees that they were not putting anything out on the GSM channel. They will try to get it right after lunch. Later, Ken --------------------------------------------------------------------------- Kenneth M. Hays, Assistant Director hays@scri.fsu.edu Supercomputer Computations Research Institute scri::hays (HEPnet/SPAN) Florida State University, *B-186 voice=904-644-7053 400 Dirac Science Center Library fax=904-644-0098 Tallahassee, Florida 32306-4052 ---------------------------------------------------------------------------- From rem-conf-request@es.net Mon Jul 12 07:09:57 1993 Received: from survis.surfnet.nl by osi-west.es.net with SMTP (PP) id <20418-0@osi-west.es.net>; Mon, 12 Jul 1993 03:54:09 +0000 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <08403-0@survis.surfnet.nl>; Mon, 12 Jul 1993 12:54:03 +0200 Received: from localhost.surfnet.nl by surgeon.surfnet.nl (4.1/SMI-4.1(EJB01)) id AA05322; Mon, 12 Jul 93 12:54:07 +0200 Message-Id: <9307121054.AA05322@surgeon.surfnet.nl> To: malcolm@pandanus.ntu.edu.au (Malcolm Caldwell) Cc: rem-conf@es.net Subject: Re: Nothing. In-Reply-To: Your message of Mon, 12 Jul 93 18:49:00 +0930. From: Erik-Jan.Bos@SURFnet.nl X-Mailer: MH X-Organization: SURFnet bv, Utrecht, The Netherlands X-Phone-Number: +31 30 310290 X-Fax-Number: +31 30 340903 Date: Mon, 12 Jul 93 12:54:05 +0200 Sender: Erik-Jan.Bos@SURFnet.nl Malcolm, > I am not getting any audio through on IETF Channel 1 GSM Audio, and I am > fairly sure that none is comming in on Channel 2 either. I have change my vat > name asking if it was just me and a few others changed theirs indicating that > they were getting nothing as well. The plenairies are only on audio channel 1, this afternoon, local Amsterdam time, there will be two parallel sessions, which will both have audio. > Is the rebroadcast of the PCM audio to GSM audio going? The mixer is running now... __ Erik-Jan. From rem-conf-request@es.net Mon Jul 12 08:17:15 1993 Received: from apple.com by osi-west.es.net with SMTP (PP) id <21080-0@osi-west.es.net>; Mon, 12 Jul 1993 05:05:37 +0000 Received: by apple.com with SMTP (5.61/22-Jun-1993-eef) id AA09183; Mon, 12 Jul 93 05:05:34 -0700 for rem-conf@es.net From: "Erik E. Fair" (Your Friendly Postmaster) Subject: a notation on camera work during WG meetings To: rem-conf@es.net Date: Mon, 12 Jul 93 05:05:33 -0700 Message-Id: <9168.742478733@apple.com> Sender: fair@apple.com Given hobson's choice between seeing the speakers, and seeing their visual aids (e.g. slides, overheads, transparencies, etc), I vote for the visual aids every time. High speed panning with slow scan video does not work. I say, shoot the overhead screen, and leave it there. Concentrate on getting people to use the mikes effectively, and/or placing them to just pick up all the ambient conversation. Sound quality is of paramount important - video can be sacrificed because it's a "nice to have". Erik E. Fair apple!fair fair@apple.com From rem-conf-request@es.net Mon Jul 12 08:58:27 1993 Received: from bnl.gov by osi-west.es.net with SMTP (PP) id <21406-0@osi-west.es.net>; Mon, 12 Jul 1993 05:47:32 +0000 Received: by bnl.gov (5.57/Ultrix3.0-C) id AA15812; Mon, 12 Jul 93 08:47:27 -0400 Received: by maeva.ccd.bnl.gov.ccd (4.1/SMI-4.1) id AA27801; Mon, 12 Jul 93 08:47:19 EDT Date: Mon, 12 Jul 93 08:47:19 EDT From: gc@maeva.ccd.bnl.gov (Graham Campbell) Message-Id: <9307121247.AA27801@maeva.ccd.bnl.gov.ccd> To: rem-conf@es.net Subject: Re: problems so far We just got the IETF 'casts up, but are seeing an average of about 13% loss rate. Is this the general experience or do we have a problem. The audio is pretty bad. Graham From rem-conf-request@es.net Mon Jul 12 09:08:17 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <21628-0@osi-west.es.net>; Mon, 12 Jul 1993 06:03:41 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 12 Jul 1993 14:03:15 +0100 To: Ron Frederick cc: rem-conf@es.net Subject: Re: New version of nv (3.2) -- now supporting color! In-reply-to: Your message of "Wed, 26 May 93 22:22:31 PDT." <93May26.222237pdt.16136@ecco.parc.xerox.com> Date: Mon, 12 Jul 93 14:03:15 +0100 From: Jon Crowcroft couple of things - during todays ietf cast, i have seen my machine run out of memoruy - since it wasnt doing anything apart from sd, nv, vat and has 56 Meg of memory and 50 Meg swap, so its a bit alarming! sd 1.14 vat 2.14 beta nv 3.2 since i was out of mem, i couldnt start ps or top/mon/pstat/vmstat to find out who was the culprit... while we're here, minor niggle: nv bombs out with X Error: BadWindow Request Major code 15 () Request Minor code 0 ResourceID 0x0 Error Serial #1118 Current Serial #1118 when i try to click on preview window to close the full size video window.. From rem-conf-request@es.net Mon Jul 12 09:49:59 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <21908-0@osi-west.es.net>; Mon, 12 Jul 1993 06:36:30 +0000 Received: from kant.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 12 Jul 1993 14:35:48 +0100 To: gc@maeva.ccd.bnl.gov (Graham Campbell) cc: rem-conf@es.net, J.Crowcroft@cs.ucl.ac.uk Subject: Re: problems so far In-reply-to: Your message of "Mon, 12 Jul 93 08:47:19 EDT." <9307121247.AA27801@maeva.ccd.bnl.gov.ccd> Date: Mon, 12 Jul 93 14:35:45 +0100 From: Jon Crowcroft >We just got the IETF 'casts up, but are seeing an average of about 13% >loss rate. Is this the general experience or do we have a problem. >The audio is pretty bad. Graham we were getting it pretty well except for the hiatus when the cern/mae routing flap was on... i'm seeing ietf!&2onm nv asnd was hearing fairly reasonable audio til a few minutes ago... jon From rem-conf-request@es.net Mon Jul 12 10:03:06 1993 Received: from relay2.nswc.navy.mil by osi-west.es.net with SMTP (PP) id <22032-0@osi-west.es.net>; Mon, 12 Jul 1993 06:47:09 +0000 Received: from galaxy.nswc.navy.mil by relay2.nswc.navy.mil (4.1/SMI-4.1) id AA21407; Mon, 12 Jul 93 09:47:02 EDT Received: by galaxy.nswc.navy.mil (4.1/SMI-4.1) id AA11396; Mon, 12 Jul 93 09:47:00 EDT Date: Mon, 12 Jul 93 09:47:00 EDT From: rhott@relay.nswc.navy.mil (Bob Hott - K31) Message-Id: <9307121347.AA11396@galaxy.nswc.navy.mil> To: gc@maeva.ccd.bnl.gov, rem-conf@es.net Subject: Re: problems so far We had the IETF up for a while (until ~8am) but then lost it. I notified my feed (SURA) and they were investigating. This appears to happening at other sites (based on discussions on the MBONE Audio channel). Any guesses, or info?? Bob Hott ====================== #include ========================= Bob Hott, NSWCDD, Networks Branch (Code K31) |"If man were not meant to play Dahlgren, Virginia 22448 (703) 663 - 8305 | volleyball, why are there so rhott@relay.nswc.navy.mil | many beaches?" - Bob Hott - From rem-conf-request@es.net Mon Jul 12 11:36:41 1993 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net with SMTP (PP) id <23106-0@osi-west.es.net>; Mon, 12 Jul 1993 08:24:03 +0000 Via: uk.ac.edinburgh.castle; Mon, 12 Jul 1993 16:22:20 +0100 Received: from scorpio.castle.ed.ac.uk by castle.ed.ac.uk id aa01942; 12 Jul 93 16:22 WET DST Date: Mon, 12 Jul 93 16:22:14 BST Message-Id: <15824.9307121522@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: problems so far To: rem-conf@es.net In-Reply-To: Graham Campbell's message of Mon, 12 Jul 93 08:47:19 EDT Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Phone: +44 (0)31 650 5003 X-Fax: +44 (0)31 662 4712 > We just got the IETF 'casts up, but are seeing an average of about 13% > loss rate. Is this the general experience or do we have a problem. > The audio is pretty bad. We are getting the same here. This morning was much better at the plenary session though. Audio and both video streams were good at less than 5% loss on video and almost 0% loss on audio. The sound system in the working group rooms appears to be pretty bad . I don't know why this is because last week during the tests it was ok. Part of the problem is that people aren't speaking anywhere near the mikes and I don't think that they have turned of silence supppression so vat keeps cutting out. Also the camera operators are moving the cameras about too much causing poor video quality which will also impinge on the audio. Graeme From rem-conf-request@es.net Mon Jul 12 11:40:56 1993 Received: from giane.cs.umass.edu by osi-west.es.net with SMTP (PP) id <23146-0@osi-west.es.net>; Mon, 12 Jul 1993 08:28:43 +0000 Received: by giane.cs.umass.edu (5.57/Ultrix3.0-C) id AA21793; Mon, 12 Jul 93 11:27:36 -0400 Date: Mon, 12 Jul 93 11:27:36 -0400 From: sbmoon@freya.cs.umass.edu Message-Id: <9307121527.AA21793@giane.cs.umass.edu> To: rem-conf@es.net Subject: mbone site list Could somebody please tell me where I could get the list of mbone sites? Thanks in advance. -Sue From rem-conf-request@es.net Mon Jul 12 12:10:15 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <23763-0@osi-west.es.net>; Mon, 12 Jul 1993 09:04:47 +0000 Received: from kant.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 12 Jul 1993 17:04:09 +0100 To: Graeme.Wood@edinburgh.ac.uk cc: rem-conf@es.net Subject: Re: problems so far In-reply-to: Your message of "Mon, 12 Jul 93 16:22:14 BST." <15824.9307121522@scorpio.ucs.ed.ac.uk> Date: Mon, 12 Jul 93 17:04:07 +0100 From: Jon Crowcroft >The sound system in the working group rooms appears to be pretty bad . I >don't know why this is because last week during the tests it was ok. the sound on the podia is good, but inside the conference crowd its poor - this aint surpirsing as when people test ,they tend to test for privalged sites only:-) >Also the camera operators are moving the cameras about too much causing >poor video quality which will also impinge on the audio. they are also using nv, which in my opinion is great for slides but not much good for natural scenes, like people...the satuiff we are putting out at similar data rate for mice using h.261 video from there is a lot nicer... jon From rem-conf-request@es.net Mon Jul 12 13:21:10 1993 Received: from nic.funet.fi by osi-west.es.net with SMTP (PP) id <24602-0@osi-west.es.net>; Mon, 12 Jul 1993 10:00:26 +0000 Received: by nic.funet.fi id <91393-2>; Mon, 12 Jul 1993 20:00:12 +0300 Subject: Re: problems so far From: Matti Aarnio To: rhott@relay.nswc.navy.mil (Bob Hott - K31) Date: Mon, 12 Jul 1993 20:00:09 +0300 Cc: gc@maeva.ccd.bnl.gov, rem-conf@es.net In-Reply-To: <9307121347.AA11396@galaxy.nswc.navy.mil> from "Bob Hott - K31" at Jul 12, 93 04:47:00 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 868 Message-Id: <93Jul12.200012eet_dst.91393-2@nic.funet.fi> > We had the IETF up for a while (until ~8am) but then lost it. I notified my > feed (SURA) and they were investigating. This appears to happening at > other sites (based on discussions on the MBONE Audio channel). That 8am east cost is a sort of a give-away. I just checked that this server was pushing about 50-80 kB/s over TCP connections to clients outside NORDUnet area, not anymore though. That traffic is mostly to USA, and often at full tilt of the network... There are a few fairly popular ftp-servers in sweden, which also contribute to line flood. We will see tomorrow. > Any guesses, or info?? Above are guesses, of course.. > Bob Hott > Bob Hott, NSWCDD, Networks Branch (Code K31) |"If man were not meant to play > rhott@relay.nswc.navy.mil | many beaches?" - Bob Hott - /Matti Aarnio at Amsterdam.. From rem-conf-request@es.net Mon Jul 12 14:08:41 1993 Received: from hybrid.com by osi-west.es.net with SMTP (PP) id <25368-0@osi-west.es.net>; Mon, 12 Jul 1993 10:58:53 +0000 Received: from virtual-city.virtual.net. by hybrid.com (4.1/SMI-4.1) id AA08099; Mon, 12 Jul 93 10:56:02 PDT Received: by virtual-city.virtual.net. (4.1/SMI-4.1) id AA17805; Mon, 12 Jul 93 10:56:45 PDT Date: Mon, 12 Jul 93 10:56:44 PDT From: "M. Strata Rose" Reply-To: strata@hybrid.com To: rem-conf-request@es.net Cc: Ron Frederick , rem-conf@es.net Subject: Re: New version of nv (3.2) -- now supporting color! In-Reply-To: Your message of Mon, 12 Jul 93 14:03:15 +0100 Message-Id: Ron, you always want to have 2.5 times your physical memory in swap space. You should have 125M of swap. One way to get it in a hurry is to find a partition with space and do "mkfile -v 75M newswapfile", then once it's made do "/usr/etc/swapon newswapfile". Caveats: 1) don't touch that file after you start swapping on it! You'll need to reboot your machine in order to delete the file later on, as it must not be modified once it's being swapped on. 2) talk to your local friendly sysadmins about more swap space for the future. Cheers, _Strata PS- to see your swap, on Suns and similar machines, do "pstat -s"; the output will be something like: 7752k allocated + 424k reserved = 8176k used, 99816k available In my case, I have just shy of 100M of swap, most of which is going spare right now.. M. Strata Rose Unix & Network Consultant, SysAdmin & Internet Information Virtual City Project strata@virtual-city.virtual.net | strata@hybrid.com | strata@apple.com | strata@eddie.mit.edu From rem-conf-request@es.net Mon Jul 12 14:36:34 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <25777-0@osi-west.es.net>; Mon, 12 Jul 1993 11:22:37 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11678>; Mon, 12 Jul 1993 11:21:53 PDT Received: by ecco.parc.xerox.com id <16136>; Mon, 12 Jul 1993 11:21:42 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Mon, 12 Jul 1993 11:21:40 -0700 (PDT) Message-ID: Date: Mon, 12 Jul 1993 11:21:40 PDT Sender: Ron Frederick From: Ron Frederick To: Jon Crowcroft Subject: Re: New version of nv (3.2) -- now supporting color! CC: rem-conf@es.net In-Reply-To: <93Jul12.060337pdt.11565@alpha.xerox.com> References: <93Jul12.060337pdt.11565@alpha.xerox.com> Since I've received this report several times now, I thought I would send out a public announcement... > nv bombs out with > X Error: BadWindow > Request Major code 15 () > Request Minor code 0 > ResourceID 0x0 > Error Serial #1118 > Current Serial #1118 I've seen this problem with certain virtual window managers (X11R5 tvtwm in particular). It has to do with that fact that nv asks Tk to withdraw windows from the window manager's control in order to unmap them _without_ iconifying them. The point is that the "icons" for these windows are in my control panel, and having extra window manager icons around just seems wasteful. Unfortunately, the Tk docs say that some window managers don't handle this correctly... As far as I know, the X11R4 tvtwm didn't have this problem, and so that may be an option for some of you. The only other fix I know is to change the "wm withdraw" commands in nv to "wm iconify", but I really don't want to do that in the normal case... Oh - there's one other crash I've seen which leads to "BadWindow" which I believe I _have_ fixed in the next release. It would sometimes happen when a source timed out & disappeared when running nv on some 24-bit displays. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Tue Jul 13 04:05:24 1993 Received: from att.att.com by osi-west.es.net with SMTP (PP) id <03333-0@osi-west.es.net>; Tue, 13 Jul 1993 00:55:18 +0000 From: yy@qsun.att.com Date: Tue, 13 Jul 93 03:52 EDT To: Andrew Cherenson , "Erik Huizer (SURFnet BV)" Cc: ietf@IETF.CNRI.Reston.VA.US, rem-conf@es.net Subject: Re: Amsterdam IETF Multicast announcement It is 3:30 EST, I am trying to record pip audio session, but don't get anthing recorded, I tried channel 2 which should have music, nothing either. With a dumb terminal at home, I can only check file existance/size as the only way to tell (no help from sd or vat). Can anyone tell me if there is live broadcasting or not? Thanks. Yung Yu AT&T Bell Labs From rem-conf-request@es.net Tue Jul 13 04:37:19 1993 Received: from apple.com by osi-west.es.net with SMTP (PP) id <03518-0@osi-west.es.net>; Tue, 13 Jul 1993 01:27:01 +0000 Received: by apple.com with SMTP (5.61/22-Jun-1993-eef) id AA10256; Tue, 13 Jul 93 01:26:52 -0700 for rem-conf@es.net From: "Erik E. Fair" (Your Friendly Postmaster) Subject: Re: Amsterdam IETF Multicast announcement In-Reply-To: <9307130823.AA09631@apple.com> To: yy@qsun.att.com X-Return-Path: rem-conf-request@es.net Cc: Andrew Cherenson , "Erik Huizer (SURFnet BV)" , ietf@IETF.CNRI.Reston.VA.US, rem-conf@es.net Date: Tue, 13 Jul 93 01:26:50 -0700 Message-Id: <10254.742552010@apple.com> Sender: fair@apple.com I am getting audio and video on both channels right now. Erik E. Fair apple!fair fair@apple.com From rem-conf-request@es.net Tue Jul 13 10:19:36 1993 Received: from KARIBA.BBN.COM by osi-west.es.net with SMTP (PP) id <05623-0@osi-west.es.net>; Tue, 13 Jul 1993 07:05:12 +0000 Date: Tue, 13 Jul 93 10:00:12 EDT From: Chip Elliott To: rem-conf@es.net Subject: Who's our FCC? I just noticed this on net news, and it reinforces a feeling I've had that the internet is about to drown in audio/video. Who will be acting as gatekeeper to reject radio stations? Are there any guidelines they'll be following?? -- Chip - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Has anyone tried out xmosaic developed by NCSA, in particular internet radio? It's pretty neat. xmosaic is public domain software. There is also a public domain software named "radio" which has two executables, broadbcast and receive. For netters in Cali, how about re-broadcasting Vietnamese radio channel over the Internet using the radio program. All one needs is a workstation such as Sp arc 2 or 10 that has a mic outlet and a radio tuned to a local channel. To broadcast and receive mono channel, one only needs 64Kbps access to the Inter net. To broadcast stereo, one needs a T1 access. Please let me know if any netter in Cali would like to do this. Thanks, Matt From rem-conf-request@es.net Tue Jul 13 11:13:09 1993 Received: from tadpole.Tadpole.COM by osi-west.es.net with SMTP (PP) id <06241-0@osi-west.es.net>; Tue, 13 Jul 1993 08:09:36 +0000 Received: from ono-sendai (ono-sendai.tadtec.co.uk) by tadpole.tadpole.com (4.1/SMI-4.1) id AA00573; Tue, 13 Jul 93 10:09:13 CDT Received: by ono-sendai (4.1/SPARCbook_POP1.3) id AA18551; Tue, 13 Jul 93 15:08:55 GMT Date: Tue, 13 Jul 93 15:08:55 GMT From: jim@tadpole.com Message-Id: <9307131508.AA18551@ono-sendai> To: celliott@BBN.COM, rem-conf@es.net Subject: Re: Who's our FCC? You've raised an issue that has been raised many times before. That issue is: Define acceptable use of bandwidth. About all you can fall back on is the AUPs of the various memeber networks. Yes, the Internet is about to drown in multimedia. About the time the common person can easily send audio/video either as part of a MIME document, or even do so in real time, all the sites with less than T1 connectivity are going to scream in pain. Jim From rem-conf-request@es.net Tue Jul 13 12:14:26 1993 Received: from Lehman.COM by osi-west.es.net with SMTP (PP) id <06969-0@osi-west.es.net>; Tue, 13 Jul 1993 09:03:42 +0000 Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA02117; Tue, 13 Jul 93 12:02:44 EDT Received: from lehman.com by shearson.com (4.1/LB-0.6) id AA13056; Tue, 13 Jul 93 12:02:22 EDT Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA02107; Tue, 13 Jul 93 12:01:53 EDT Received: from snark.shearson.com by shearson.com (4.1/LB-0.6) id AA13047; Tue, 13 Jul 93 12:01:33 EDT Received: by snark.shearson.com (4.1/SMI-4.1) id AA21967; Tue, 13 Jul 93 12:01:31 EDT Message-Id: <9307131601.AA21967@snark.shearson.com> To: jim@tadpole.com Cc: rem-conf@es.net Subject: Re: Who's our FCC? In-Reply-To: Your message of "Tue, 13 Jul 1993 15:08:55 GMT." <9307131508.AA18551@ono-sendai> Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Tue, 13 Jul 1993 12:01:30 -0400 From: "Perry E. Metzger" jim@tadpole.com says: > You've raised an issue that has been raised many times before. > That issue is: Define acceptable use of bandwidth. About all > you can fall back on is the AUPs of the various memeber networks. > > Yes, the Internet is about to drown in multimedia. About the time > the common person can easily send audio/video either as part of a MIME > document, or even do so in real time, all the sites with less than T1 > connectivity are going to scream in pain. Trying to stop this from happening is going to be like trying to shovel the ocean. On the other hand, its not unreasonable to try to come up with ways to control the handling of the traffic and make sure it doesn't overwhelm us. However, make no mistake -- we can't stop it. Perry From rem-conf-request@es.net Tue Jul 13 12:24:53 1993 Received: from tadpole.Tadpole.COM by osi-west.es.net with SMTP (PP) id <07163-0@osi-west.es.net>; Tue, 13 Jul 1993 09:14:39 +0000 Received: from ono-sendai (ono-sendai.tadtec.co.uk) by tadpole.tadpole.com (4.1/SMI-4.1) id AA01249; Tue, 13 Jul 93 11:14:24 CDT Received: by ono-sendai (4.1/SPARCbook_POP1.3) id AA21085; Tue, 13 Jul 93 16:14:02 GMT Date: Tue, 13 Jul 93 16:14:02 GMT From: jim@tadpole.com Message-Id: <9307131614.AA21085@ono-sendai> To: rem-conf@es.net Subject: Re: Who's our FCC? > Trying to stop this from happening is going to be like trying to > shovel the ocean. On the other hand, its not unreasonable to try to > come up with ways to control the handling of the traffic and make sure > it doesn't overwhelm us. However, make no mistake -- we can't stop it. Isn't that about what I said? Interestingly, I've been saying the same thing around my company for a while. The person-in-charge here in the UK seems to think that networks with limited bandwidth will refuse to carry same. The example in question is Pipex, who have 128k accross the pond. I insist that if they try, their customer base will desert them. Jim From rem-conf-request@es.net Tue Jul 13 12:41:11 1993 Received: from itd.nrl.navy.mil by osi-west.es.net with SMTP (PP) id <07435-0@osi-west.es.net>; Tue, 13 Jul 1993 09:30:35 +0000 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA14642; Tue, 13 Jul 93 12:30:28 EDT Date: Tue, 13 Jul 93 12:30:28 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307131630.AA14642@itd.nrl.navy.mil> To: rem-conf@es.net Subject: Re: Who's our FCC? Actually, I've seen a whole lot of local (NRL) interest in using the voice/video/whiteboard tools. Other parts of the Navy are interested and also the DoD generally. So I think there really will be a commercial market for this once the IETF finishes its work on conference control protocols and such like (work that is already underway). Moreover, several vendors now sell multimedia networking products. For example, Sun Microsystems now sells a network whiteboard tool commercially that we are experimenting with. BBN is selling its PictureWindow voice/video software commercially. Sites with limited bandwidth are going to probably want to do more filtering at their routers based on application protocol and there really will be more pressure to increase bandwidth everywhere. I think the work on flows and the material that Dave Clark talked about in Columbus will make a big difference, but it isn't clear to me how close that work is to being deployable. In my mind, support for flows is needed in IP:TNG. Ran atkinson@itd.nrl.navy.mil From rem-conf-request@es.net Tue Jul 13 13:19:00 1993 Received: from sci.sci.ccny.cuny.edu by osi-west.es.net with SMTP (PP) id <08049-0@osi-west.es.net>; Tue, 13 Jul 1993 10:08:37 +0000 Date: Tue, 13 Jul 93 13:07:37 -0400 From: Jian Huang Received: by sci.sci.ccny.cuny.edu (5.61/031893-CCNY Science) id AA09925; Tue, 13 Jul 93 13:07:37 -0400 Message-Id: <9307131707.AA09925@sci.sci.ccny.cuny.edu> To: rem-conf@es.net Subject: help help From rem-conf-request@es.net Tue Jul 13 15:11:11 1993 Received: from ds.internic.net by osi-west.es.net with SMTP (PP) id <09987-0@osi-west.es.net>; Tue, 13 Jul 1993 12:00:51 +0000 Received: by ds.internic.net (4.1/SMI-4.1) id AA21514; Tue, 13 Jul 93 14:59:17 EDT Date: Tue, 13 Jul 93 14:59:17 EDT From: yy@ds.internic.net (Yung Yu) Message-Id: <9307131859.AA21514@ds.internic.net> To: ietf@IETF.CNRI.Reston.VA.US, rem-conf@es.net Subject: Recorded MBONE audio sessions available Cc: in-techs@cerf.net We apologize for the multiple copies you may receive due to cross posting. Regards. Yung Yu yy@ds.internic.net ----------------------- ANNOUNCING AMSTERDAM IETF AUDIO SESSION ARCHIVE As in the past few IETF meetings, live audio and video from the plenary and some working group sessions of the Amsterdam IETF will be multicast out across the Internet. InterNIC Directory and Database Services is now recording the audio sessions for later retrieval. STRUCTURE OF THE ARCHIVE: InterNIC Directory and Database Services has created the directory "/pub/ietf/amsterdam-ietf", subdirectories "mon", "tue", . .. "fri", for each date, and "plenary", "sdr", etc. directories under each date for each audio session. Each directory will contain a number of files, and each file contains about 30 minutes of recorded audio. examples: /pub/ietf/amsterdam-ietf/mon/uri/audio.2c4176d0.1b2 /pub/ietf/amsterdam-ietf/tue/tuba/audio.2c42da18.cf ACCESS VIA ANONYMOUS FTP: Anonymous FTP to ds.internic.net and change directory to /pub/ietf/amsterdam-ietf/, then go to the date and session you are looking for. TIME TO LIVE OF THE ARCHIVE Due to the large amount of storage required, this recorded audio archive is not permanent. It will be available until approximately 2 weeks after working group meeting minutes or reports are completed. WHERE TO GET TOOLS The tool to receive audio is available by anonymous FTP from ftp.ee.lbl.gov in the file sun-vat.tar.Z, dec-vat.tar.Z, or sgi-vat.tar.Z. The tool to replay recorded audio sessions is available by anonymous FTP from sics.se. in the archive/vat_record.tar.Z. More information about the MBONE, including what hardware and software is required to receive the multicast, is available by anonymous FTP from venera.isi.edu in the file mbone/faq.txt. From rem-conf-request@es.net Tue Jul 13 16:10:49 1993 Received: from charlie.CES.CWRU.Edu by osi-west.es.net with SMTP (PP) id <10706-0@osi-west.es.net>; Tue, 13 Jul 1993 13:01:50 +0000 Received: by charlie.CES.CWRU.Edu (5.64+/ane.09.11.90.2) id AA16900; Tue, 13 Jul 93 16:01:38 -0400 Date: Tue, 13 Jul 93 16:01:38 -0400 From: Aydin Edguer Message-Id: <9307132001.AA16900@charlie.CES.CWRU.Edu> To: rem-conf@es.net Subject: Re: Who's our FCC? Just to address a few points. > There is also a public domain software named "radio" which has two > executables, broadbcast and receive. The last time I looked at "radio" it used UDP broadcast packets. Thus the only people that radio will affect is the local subnet. It would be a matter of local policy whether radio could be used or not. From reading the message, it sound like radio has been enhanced to send packets across the Internet (multicast? unicast?). > Who will be acting as gatekeeper to reject radio stations? Well, there are a number of routes to take. If someone is broadcasting or multicasting a radio station over the Internet, there are a number of ways to approach the problem (assuming that the *cast is causing problems). The first is local filtering of the remote site if possible. This is not necessarily the correct solution, but it is the solution that is under your control. A second approach is to contact your network service provider. Yet another is to contact the technical contact for the remote zone. Yet another is to contact the user at the remote site. A final approach is to contact the radio station being broadcast. Unauthorized rebroadcast of a radio or television signal is frequently frowned upon by commercial stations and a call from the general manager (or legal consultant) of the radio station would discourage most users. At this time the gatekeeper(s) for the MBONE are the participants. We have already seen a few times where someone needed to be asked to stop sending while MBONE tests or meetings were being conducted. Radio Free Vat stops sending whenever IETF or other announced conferences are going on. As researchers (or just end-users) most of us try to be polite. (When someone rewrites IRC to use multicast and send audio instead of text, we will find a number of not-so-polite people - !shudder!) > About the time the common person can easily send audio/video either as > part of a MIME document.... I don't see this as a problem. FTP, SMTP, and NNTP (and most TCP) applications are all relatively well behaved applications. Users may start to become annoyed when it takes 2-5 minutes to get the rest of the parts to their multimedia mail message or when they hit their disk quota before they can download that same message (and system managers may howl when their spools overflow when someone *includes* the video instead of just a pointer) but in terms of network usage, I don't think this is the same problem as real-time multimedia services. After all that nit-picking I have to agree I see the problem coming on and I don't see any solutions coming along. The IETF-WGs are coming up with ways of allocating bandwitdth, limiting traffic, setting up sessions, etc, for well behaved applications, but I still see no solutions to people who start setting up tunnels and build their own private MBONE. The only way to find such uses/abuses is after they have already started to cause problems (at which point you start trying to watch traffic patterns, etc). And the only way of stopping the use/abuse without many free speech and "But I'm paying $$" arguments is having a local fair-use policy. Aydin From rem-conf-request@es.net Tue Jul 13 18:59:04 1993 Received: from uu5.psi.com by osi-west.es.net with SMTP (PP) id <12905-0@osi-west.es.net>; Tue, 13 Jul 1993 15:51:19 +0000 Received: by uu5.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA21648 for ; Tue, 13 Jul 93 18:13:48 -0400 Date: Tue, 13 Jul 93 17:46:42 EDT From: hhs@teleoscom.com (Chip Sharp 6424) Received: by teleoscom.com (4.1/3.2.083191-Teleos Communications Inc.) id AA06134; Tue, 13 Jul 93 17:46:42 EDT Message-Id: <9307132146.AA06134@teleoscom.com> To: edguer@alpha.ces.cwru.edu Cc: rem-conf@es.net In-Reply-To: Aydin Edguer's message of Tue, 13 Jul 93 16:01:38 -0400 <9307132001.AA16900@charlie.CES.CWRU.Edu> Subject: Who's our FCC? Do you really want the FCC regulating network bandwdith? On the surface this seems ludicrous, but if the "National Communications Superhighway" is built with public funds (i.e., our tax dollars), then the government may feel a need to step in. In addition, do I want my tax dollars spent to provide a gigabit network so people can use inefficient network protocols and blast radio and television programs over the internet? What is to stop someone from hooking up TV to the Internet and broadcasting 24 hours a day? And what happens when someone starts broadcasting "pornography" across the internet? One option is to just have the networks charge according to usage. If someone wants to broadcast radio across the internet, then charge them for the cost of usage of the network (plus margin). That way, if more bandwidth is needed, the network can fund it based on demand. As for the social issues, I'm not sure how this will be handled. Chip Sharp From rem-conf-request@es.net Wed Jul 14 00:24:13 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <15141-0@osi-west.es.net>; Tue, 13 Jul 1993 21:16:23 +0000 Received: from mu.parc.xerox.com ([13.2.116.81]) by alpha.xerox.com with SMTP id <12153>; Tue, 13 Jul 1993 21:11:29 PDT Received: by mu.parc.xerox.com id <58372>; Tue, 13 Jul 1993 21:11:19 -0700 From: Pavel Curtis Sender: Pavel Curtis Fake-Sender: pavel@parc.xerox.com To: mbone@isi.edu, rem-conf@es.net Subject: New MBone Map Available Message-Id: <93Jul13.211119pdt.58372@mu.parc.xerox.com> Date: Tue, 13 Jul 1993 21:11:09 PDT There is a new version of the MBone map available for anonymous FTP from parcftp.xerox.com, in the pub/net-research/ directory as the files: mbone-map-small.{ps,ps.Z} mbone-map-big.{ps,ps.Z} mbone-map.gr The `small' map fits on one 8.5 x 11 page but is a bit tricky to read at 300 dpi. The `big' map is a blowup of the small one by a linear factor of 2, printing out as 4 pages that have to be trimmed and taped together for viewing. The `.gr' file is the GraphEd-format editable representation of the map. Sorry it took me so long to get this version done, but y'all have managed to grow the MBone by about 50% since the last map (only a month ago!), and that represents a fair piece of new manual layout for me to do... :-( Pavel Curtis Occasional MBone Cartographer From rem-conf-request@es.net Wed Jul 14 02:25:50 1993 X400-Received: by mta osi-west.es.net in /PRMD=ESnet/ADMD= /C=US/; Relayed; Tue, 13 Jul 1993 23:20:28 +0000 Date: Tue, 13 Jul 1993 23:20:28 +0000 X400-Originator: rem-conf-request@es.net X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=ESnet/ADMD= /C=US/;osi-west.e.479:14.06.93.06.20.28] Priority: Non-Urgent DL-Expansion-History: rem-conf@es.net ; Tue, 13 Jul 1993 23:18:46 +0000; From: Erik Wilde Message-ID: <952*/S=wilde/OU=komsys/OU=tik/O=ethz/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> To: rem-conf Subject: unsubscription! Importance: High Sorry for sending this to you all, but the request address seems not to work. Please delete me from this mailing list. I'm on holiday and my mailbox is exploding! Thank you very much! Erik. (wilde@tik.ethz.ch) From rem-conf-request@es.net Wed Jul 14 02:50:34 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <15542-0@osi-west.es.net>; Tue, 13 Jul 1993 23:42:25 +0000 Received: from mmc.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Tue, 13 Jul 1993 23:42:22 -0700 Posted-Date: Tue 13 Jul 93 23:42:17-PDT Received: by mmc.isi.edu (4.1/4.0.3-4) id ; Tue, 13 Jul 93 23:42:18 PDT Date: Tue 13 Jul 93 23:42:17-PDT From: Stephen Casner Subject: Re: Who's our FCC? To: celliott@bbn.com, rem-conf@es.net Message-Id: <742632137.0.CASNER@MMC.ISI.EDU> In-Reply-To: <199307131422.AA28950@venera.isi.edu> Mail-System-Version: In the next release of the multicast software, planned for the end of summer, there will be mechanisms to limit the total bandwidth of multicast traffic forwarded on any given link and to prioritize traffic based on address information. That will allow us to protect the MBONE from overuse and to insure that, for example, IETF traffic gets priority. Other calls will see excessive packet loss and will stop. However, this does not prevent private tunnels nor unicast traffic for 2-party calls. Network providers may want to monitor traffic to detect illicit tunnels. This seems feasible. I'm not sure how we draw the line on unicast audio/video communication. I happened to have a conversation with Steve Wolff on the MBone Audio channel about this. I asked if we should refrain from releasing session control software that facilitates setting up unicast A/V sessions, and he replied that he has never believed in trying to repress new developments in that manner. Let the demand come and drive an increase in capacity. This should be fun to watch! -- Steve ------- From rem-conf-request@es.net Wed Jul 14 04:23:54 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <16101-0@osi-west.es.net>; Wed, 14 Jul 1993 01:04:09 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 14 Jul 1993 09:03:44 +0100 To: jim@tadpole.com cc: rem-conf@es.net Subject: Re: Who's our FCC? In-reply-to: Your message of "Tue, 13 Jul 93 16:14:02 GMT." <9307131614.AA21085@ono-sendai> Date: Wed, 14 Jul 93 09:03:41 +0100 From: Jon Crowcroft >Interestingly, I've been saying the same thing around my company for a while. >The person-in-charge here in the UK seems to think that networks with limited >bandwidth will refuse to carry same. The example in question is Pipex, who have >128k accross the pond. I insist that if they try, their customer base will desert them. Jim i just hope that demand for bandwidth from this makes the telcos realize they can make more money by selling an order of magnitude more bandwwidth for the same price to more customers... jon From rem-conf-request@es.net Wed Jul 14 06:02:58 1993 Received: from charon.cwi.nl by osi-west.es.net with SMTP (PP) id <16369-0@osi-west.es.net>; Wed, 14 Jul 1993 02:38:01 +0000 Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP id AA03785 (5.65b/3.8/CWI-Amsterdam); Wed, 14 Jul 1993 11:37:57 +0200 Received: by schelvis.cwi.nl with SMTP id AA00700 (5.65b/3.8/CWI-Amsterdam); Wed, 14 Jul 1993 11:37:56 +0200 Message-Id: <9307140937.AA00700=jack@schelvis.cwi.nl> To: Aydin Edguer Cc: rem-conf@es.net Subject: Re: Who's our FCC? In-Reply-To: Message by Aydin Edguer , Tue, 13 Jul 93 16:01:38 -0400 , <9307132001.AA16900@charlie.CES.CWRU.Edu> Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam Phone: +31 20 5924098(work), +31 20 5924199 (fax), +31 20 6160335(home) X-Last-Band-Seen: Hitmen 3, Loveslug (Melkweg, 10-7) X-Mini-Review: Pretty neat. Date: Wed, 14 Jul 1993 11:37:55 +0200 From: Jack Jansen Recently, Aydin Edguer said: > > There is also a public domain software named "radio" which has two > > executables, broadbcast and receive. > > The last time I looked at "radio" it used UDP broadcast packets. > Thus the only people that radio will affect is the local subnet. > It would be a matter of local policy whether radio could be used > or not. Well, there are a few things called 'radio'. The CWI radio software (which is widely available) can use either UDP broadcast or multicast, so it is clearly a potential problem. Also, the problem is not as much that there is no way to stop the casts, but more that it is a bloody nuisance if admins all over the world have to take action to stop people at the other end of the world every week or so. Wait until the students return next fall and you'll see... -- Jack Jansen | If I can't dance I don't want to be part of Jack.Jansen@cwi.nl | your revolution -- Emma Goldman uunet!cwi.nl!jack G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl From rem-conf-request@es.net Wed Jul 14 06:35:20 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <16606-0@osi-west.es.net>; Wed, 14 Jul 1993 03:31:20 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 14 Jul 1993 11:31:12 +0100 To: rem-conf@es.net Subject: session activity msg aggregation Date: Wed, 14 Jul 93 11:31:10 +0100 From: Jon Crowcroft during this IETF cast, i have been tracking several shared drawing programs, the MICE demo (4 video, several audio) and both IETF auido and video sessions, but failing to do so well,m becuase a) vat switches (nicely) based on the priotry i choose b) video doesnt c) shared applcs don't it'd be nice if sd gave me some key that would associate all thse, and interacted with each to switch associated media togther... (another possibility is to trigger attention by tracking particular people rather than sessions, via, for instance, an active badge system...) jon From rem-conf-request@es.net Wed Jul 14 07:32:20 1993 Received: from itd.nrl.navy.mil by osi-west.es.net with SMTP (PP) id <16876-0@osi-west.es.net>; Wed, 14 Jul 1993 04:27:28 +0000 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02776; Wed, 14 Jul 93 07:27:24 EDT Date: Wed, 14 Jul 93 07:27:24 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307141127.AA02776@itd.nrl.navy.mil> To: rem-conf@es.net Subject: CWI radio software Jack, You talk about "UDP broadcast". Broadcast seems like a really bad thing to me. Do you know what this means in more detail and why the CWI folks want broadcast instead of multicast ? Ran atkinson@itd.nrl.navy.mil From rem-conf-request@es.net Wed Jul 14 11:15:21 1993 Received: from ds.internic.net by osi-west.es.net with SMTP (PP) id <18518-0@osi-west.es.net>; Wed, 14 Jul 1993 08:07:31 +0000 Received: by ds.internic.net (4.1/SMI-4.1) id AA13336; Wed, 14 Jul 93 11:07:14 EDT Date: Wed, 14 Jul 93 11:07:14 EDT From: yy@ds.internic.net (Yung Yu) Message-Id: <9307141507.AA13336@ds.internic.net> To: ietf@IETF.CNRI.Reston.VA.US, rem-conf@es.net Subject: directory for IETF audio sessions The Amsterdam IETF audio sessions recorded from MBONE are under /ftp/ietf/amsterdam-ietf on all our InterNIC Directory and Database servers (ds.internic.net). The original announcement has an extra "pub" in the path which is not correct. Sorry for the incovenience. Yung Yu yy@ds.internic.net From rem-conf-request@es.net Wed Jul 14 11:15:39 1993 Received: from charon.cwi.nl by osi-west.es.net with SMTP (PP) id <18451-0@osi-west.es.net>; Wed, 14 Jul 1993 07:59:17 +0000 Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP id AA12036 (5.65b/3.8/CWI-Amsterdam); Wed, 14 Jul 1993 16:59:06 +0200 Received: by schelvis.cwi.nl with SMTP id AA01616 (5.65b/3.8/CWI-Amsterdam); Wed, 14 Jul 1993 16:59:04 +0200 Message-Id: <9307141459.AA01616=jack@schelvis.cwi.nl> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: rem-conf@es.net Subject: Re: CWI radio software In-Reply-To: Message by atkinson@itd.nrl.navy.mil (Ran Atkinson) , Wed, 14 Jul 93 07:27:24 EDT , <9307141127.AA02776@itd.nrl.navy.mil> Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam Phone: +31 20 5924098(work), +31 20 5924199 (fax), +31 20 6160335(home) X-Last-Band-Seen: Hitmen 3, Loveslug (Melkweg, 10-7) X-Mini-Review: Pretty neat. Date: Wed, 14 Jul 1993 16:59:04 +0200 From: Jack Jansen Recently, atkinson@itd.nrl.navy.mil (Ran Atkinson) said: > You talk about "UDP broadcast". Broadcast seems like a really bad > thing to me. Do you know what this means in more detail and why the > CWI folks want broadcast instead of multicast ? The main reason is that UDP broadcast is supported on all platforms, so people can use our radio stuff without having to have ipmulti support in their kernel. Another (minor) reason is that you don't get as many packets on the nets in some cases. We have two ethers on which we broadcast radio here, and no hosts with two interfaces. So, using ipmulticast each packet would be seen twice on each cable (once ipmulticast and once while in transit across the tunnel). We advise people to use ipmulticast whenever possible, though. -- Jack Jansen | If I can't dance I don't want to be part of Jack.Jansen@cwi.nl | your revolution -- Emma Goldman uunet!cwi.nl!jack G=Jack;S=Jansen;O=cwi;PRMD=surf;ADMD=400net;C=nl From rem-conf-request@es.net Wed Jul 14 11:30:41 1993 Received: from nynex-ms.nynexst.com by osi-west.es.net with SMTP (PP) id <18408-0@osi-west.es.net>; Wed, 14 Jul 1993 07:54:56 +0000 Received: from texas.nynexst.com (texas-gw.nynexst.com) by nynexst.com (4.1/SMI-4.1) id AA13627; Wed, 14 Jul 93 10:59:17 EDT Received: from psl31.nynexst.com by texas.nynexst.com (4.1/SMI-DDN) id AA00924; Wed, 14 Jul 93 10:54:50 EDT Date: Wed, 14 Jul 93 10:54:50 EDT From: chatterj@nynexst.com (Samir Chatterj) Message-Id: <9307141454.AA00924@texas.nynexst.com> To: rem-conf@es.net Subject: Recorded MBONE audio sessions Hi, I am interested in listining to the audio form the IETF meeting. I have FTPed the vat .exe. But there are no instructions on how to use it. Could some one please help me with this? Thanks in adv. Samir. From rem-conf-request@es.net Wed Jul 14 11:32:45 1993 Received: from thuer.netcs.com by osi-west.es.net with SMTP (PP) id <18726-0@osi-west.es.net>; Wed, 14 Jul 1993 08:22:10 +0000 Received: from bunt.netcs.com by thuer.netcs.com with SMTP (5.67a8+/25-eef) id AA07695; Wed, 14 Jul 1993 17:20:48 +0200 From: Clemens Schrimpe Message-Id: <199307141520.AA07695@thuer.netcs.com> Subject: Re: Recorded MBONE audio sessions available To: yy@ds.internic.net (Yung Yu) Date: Wed, 14 Jul 1993 17:12:46 +0200 (MET DST) Cc: ietf@IETF.CNRI.Reston.VA.US, rem-conf@es.net, in-techs@cerf.net In-Reply-To: <9307131859.AA21514@ds.internic.net> from "Yung Yu" at Jul 13, 93 02:59:17 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1776 X-Charset: ASCII X-Char-Esc: 29 <> ANNOUNCING AMSTERDAM IETF AUDIO SESSION ARCHIVE <> <> As in the past few IETF meetings, live audio and video from the <> plenary and <> some working group sessions of the Amsterdam IETF will be multicast out <> across the Internet. InterNIC Directory and Database Services is now <> recording the audio sessions for later retrieval. <> <> STRUCTURE OF THE ARCHIVE: <> <> InterNIC Directory and Database Services has created the directory <> "/pub/ietf/amsterdam-ietf", subdirectories "mon", "tue", . .. "fri", <> for each date, and "plenary", "sdr", etc. directories under each date <> for each audio session. Each directory will contain a number of files, <> and each file contains about 30 minutes of recorded audio. <> <> examples: <> /pub/ietf/amsterdam-ietf/mon/uri/audio.2c4176d0.1b2 <> /pub/ietf/amsterdam-ietf/tue/tuba/audio.2c42da18.cf It would have been an interesting experiment, if you would record VIDEO simultaneously and then publish the whole thing on say Exabyte tapes or CD ROM(s) for folks like me, which couldn't follow all proceedings due to technical reasons or due to commercial reasons (those, who use commercial Internet providers, who charge by the bit). Greetings to all lucky AUDIO/VIDEO receivers (sigh) - Clemens Schrimpe, netCS Berlin PS: Does somebody else record the VIDEO stuff - I'd love to have at least some minutes or even just seconds to see, what the conference looked like??? -- INTERNET: csch@netcs.com BITNET: csch@TUB.BITNET PSI: PSI%26245050230409::CSCH X.25/WIN: 2624 50502 30409 PHONE: +49-30-856 999-0 FAX: +49-30-855 52 18 X.400: /S=Schrimpe/P=netCS/A=DBP/C=DE/ [on Research Networks] From rem-conf-request@es.net Wed Jul 14 12:00:50 1993 Received: from crdems.GE.COM by osi-west.es.net with SMTP (PP) id <19203-0@osi-west.es.net>; Wed, 14 Jul 1993 08:55:17 +0000 Received: from crdns.crd.ge.com by crdems.ge.com (5.65/GE 1.60) id AA11331; Wed, 14 Jul 93 11:53:53 -0400 Received: from alydar.crd.ge.com by crdns.crd.ge.com (5.65/sendmail.ease_1.75(6/2/93))id AA15540(crdns.crd.ge.com); Wed, 14 Jul 93 11:53:51 -0400 Received: from rodson.crd.Ge.Com by alydar.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease1.14 01/06/93)id AA03099; Wed, 14 Jul 93 11:53:49 EDT Date: Wed, 14 Jul 93 11:53:49 EDT From: bloomer@alydar.crd.ge.com (John Bloomer) Message-Id: <9307141553.AA03099@alydar.crd.Ge.Com> To: rem-conf@es.net Subject: Re: CWI radio software >From: Jack Jansen >Date: Wed, 14 Jul 1993 16:59:04 +0200 ... >The main reason is that UDP broadcast is supported on all platforms, ... It's the same case on our LANS and WANS as well. We have developed voice and video conf. on top of RPCs, allowing use of UDP broadcasts when point to multi-point conferences are requested, but using predominantly point to point UDPing. There's no reason why multicasting shouldn't be just another transport (option) for RPC or a messaging API. Today, for GE, there is a lot of legacy equipment, prototype gear and a variety of computers involved, mandating some support of broadcasting. I too would advise people to use ipmulticast whenever possible, though. John Bloomer KWC317, General Electric Corporate Research and Development PO Box 8, Schenectady NY 12301 From rem-conf-request@es.net Thu Jul 15 04:01:18 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <26580-0@osi-west.es.net>; Thu, 15 Jul 1993 00:40:54 +0000 Received: from mmc.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Thu, 15 Jul 1993 00:40:50 -0700 Posted-Date: Thu 15 Jul 93 00:40:37-PDT Received: by mmc.isi.edu (4.1/4.0.3-4) id ; Thu, 15 Jul 93 00:40:38 PDT Date: Thu 15 Jul 93 00:40:37-PDT From: Stephen Casner Subject: Re: Who's our FCC? To: rem-conf@es.net Message-Id: <742722037.0.CASNER@MMC.ISI.EDU> In-Reply-To: <742632137.0.CASNER@MMC.ISI.EDU> Mail-System-Version: I received a few private messages today in response to my explanation of enhancements to the multicast software planned by the folks at PARC to allow prioritization of different traffic streams. In essence, these messages asked, "Why should IETF traffic have priority?" Hold it, folks! You missed that I said "for example". I'm not trying to dictate policy here! Now, I expect that a fair portion of the community would consider the IETF multicast important, but I don't know by what means the policies should be established. It is my expectation, at least in the early deployment, that the adminstrator of each multicast router will have control over what priorities and traffic limits are set on that mrouter. To achieve good quality distribution, though, we're going to need some coordination of the settings in the "core" mrouters. Right now we have a few individuals who act as part-time "MBone gurus", but it might be necessary to formalize that a little more if the participants are willing to grant such authority (and if we can find someone to do it :-) -- Steve ------- From rem-conf-request@es.net Thu Jul 15 04:52:56 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <26705-0@osi-west.es.net>; Thu, 15 Jul 1993 01:14:58 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 15 Jul 1993 09:14:51 +0100 To: rem-conf@es.net Subject: Re: Who's our FCC? In-reply-to: Your message of "Thu, 15 Jul 93 00:40:37 PDT." <742722037.0.CASNER@MMC.ISI.EDU> Date: Thu, 15 Jul 93 09:14:51 +0100 From: Jon Crowcroft steve addressed the question: > "Why should IETF traffic have priority?" with: >Hold it, folks! You missed that I said "for example". I'm not >trying to dictate policy here! Now, I expect that a fair portion of >the community would consider the IETF multicast important, but I don't >know by what means the policies should be established. right - one thing we have experienced is unfounded accusations that the multicast traffic is swamping the net (in the UK) - the mechanisms steve describes are part of a "quality assurance" that will go a long weay to pursuading people we are NOT doing things we cannot control - indeed, it is the first step in something that eventually may have to be imposed on _data_ traffic as well as the multimedia traffic - who knows, we may be asking why someone's archie server is swamping our ACM conference cast someday! >It is my expectation, at least in the early deployment, that the >adminstrator of each multicast router will have control over what >priorities and traffic limits are set on that mrouter. To achieve >good quality distribution, though, we're going to need some >coordination of the settings in the "core" mrouters. Right now we >have a few individuals who act as part-time "MBone gurus", but it >might be necessary to formalize that a little more if the participants >are willing to grant such authority (and if we can find someone to do >it :-) in the UK, we are moving Mbone management INTO the backbone management as I speak - it is regarded as an important service, and to that end, mbone routers are being provided - we would very much welcome this technology in supported products (hint, hint!). jon From rem-conf-request@es.net Thu Jul 15 05:46:40 1993 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net with SMTP (PP) id <26983-0@osi-west.es.net>; Thu, 15 Jul 1993 02:25:17 +0000 Via: uk.ac.edinburgh.castle; Thu, 15 Jul 1993 10:24:38 +0100 Received: from scorpio.castle.ed.ac.uk by castle.ed.ac.uk id aa02037; 15 Jul 93 10:24 WET DST Date: Thu, 15 Jul 93 10:24:35 BST Message-Id: <22244.9307150924@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: Who's our FCC? To: rem-conf@es.net In-Reply-To: Stephen Casner's message of Thu 15 Jul 93 00:40:37-PDT Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Phone: +44 (0)31 650 5003 X-Fax: +44 (0)31 662 4712 > I received a few private messages today in response to my explanation > of enhancements to the multicast software planned by the folks at PARC > to allow prioritization of different traffic streams. In essence, > these messages asked, > > "Why should IETF traffic have priority?" > > Hold it, folks! You missed that I said "for example". I'm not > trying to dictate policy here! Now, I expect that a fair portion of > the community would consider the IETF multicast important, but I don't > know by what means the policies should be established. > > It is my expectation, at least in the early deployment, that the > adminstrator of each multicast router will have control over what > priorities and traffic limits are set on that mrouter. To achieve > good quality distribution, though, we're going to need some > coordination of the settings in the "core" mrouters. Right now we > have a few individuals who act as part-time "MBone gurus", but it > might be necessary to formalize that a little more if the participants > are willing to grant such authority (and if we can find someone to do > it :-) The problem here is what is a "core" router. I can foresee serious problems ensuing with this. What somebody regards as important an important coneference session may be regarded as not so important by someone else who controls an mbone router somewhere between the source and the recipient. This means that recipient effectively gets cut off from the conference. There are a large number of sites (looking at the latest map) which seem to be connected through a single mbone router (the whole of Japan for instance), thus placing the burden of control of what is "right and proper" on administrators in certain sites. Now I admit at this time this is probably not going to be a problem but as the number of multicast-using sites increases the number of conf. sessions will also increase making this decision making very difficult and I can see that this will be a problem very soon (rather than some time off yet). How will an "mbone guru" act impartially when he is asked to decide between routing the IETF or an archaelogical conference on ancient Samoan civilization? I guess you are hoping that the increase in bandwidth available is going to keep pace with the increase in the number of people wanting to use these services. Have I understood the situation correctly? Graeme From rem-conf-request@es.net Thu Jul 15 08:16:34 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <27788-0@osi-west.es.net>; Thu, 15 Jul 1993 04:54:12 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 15 Jul 1993 12:54:04 +0100 To: rem-conf@es.net Subject: Re: RTP broader application thereof Date: Thu, 15 Jul 93 12:54:01 +0100 From: Jon Crowcroft at the IETF we were using Active badges to track our people on the MICE demo from london to amsterdam - these devices are sensed i nthe infrared, we then multicast out badge sightings (with a low ttl usually, buyt higher in this case) it seems to me that this is exactly like some of the session info in vat/etc so we could apply rtp here too...you also need the "media" info, since the same infrared stuff can be used for cookers, answerfones, VCRs as well as badges, so you dn't want your toaster popping up in an IETF audio session (or do you?) someone care to write the rfc? cheers jon From rem-conf-request@es.net Thu Jul 15 09:29:45 1993 Received: from charon.cwi.nl by osi-west.es.net with SMTP (PP) id <28213-0@osi-west.es.net>; Thu, 15 Jul 1993 06:26:13 +0000 Received: from voorn.cwi.nl by charon.cwi.nl with SMTP id AA04070 (5.65b/3.8/CWI-Amsterdam); Thu, 15 Jul 1993 15:25:28 +0200 Received: by voorn.cwi.nl with SMTP id AA01903 (5.65b/3.8/CWI-Amsterdam); Thu, 15 Jul 1993 15:25:28 +0200 Message-Id: <9307151325.AA01903=guido@voorn.cwi.nl> To: rem-conf@es.net Subject: "On the Internet, nobody knows you're a dog" From: Guido.van.Rossum@cwi.nl X-Organization: CWI (Centrum voor Wiskunde en Informatica) X-Address: P.O. Box 4079, 1009 AB Amsterdam, The Netherlands X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax) Date: Thu, 15 Jul 1993 15:25:27 +0200 Sender: Guido.van.Rossum@cwi.nl (I know this isn't the right forum, but I don't know a better one... Flame ahead but flame in private.) At the IETF, someone showed a cartoon from the New Yorker (I believe) with the caption "On the Internet, nobody knows you're a dog." Could someone in the lucky posession of both a scanner and a copy of the issue containing the cartoon make it available for ftp as a GIF file? Thanks in advance! --Guido van Rossum, CWI, Amsterdam From rem-conf-request@es.net Thu Jul 15 09:34:38 1993 Received: from research.att.com by osi-west.es.net with SMTP (PP) id <28176-0@osi-west.es.net>; Thu, 15 Jul 1993 06:18:06 +0000 Received: by inet; Thu Jul 15 09:17 EDT 1993 Date: Thu, 15 Jul 93 09:17:22 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: RTP broader application thereof Cc: rem-conf@es.net RTP for active badges: Seems easy. Just write a small profile defining the contents of the FMT field and some other minor stuff; see the profile RTP document. You get timestamps for free, too. Given this application, it may be worthwhile to add a "location" SDES field that would be filled in by the system that picks up the badge reading. Interesting question: do you want everybody in the world to be on the same multicast address or have one per company. I'd be interested in following up on that with whoever is writing the batch multicast application. I probably have a set of routines so that writing the programs should be an afternoon affair. Henning --- Henning Schulzrinne (hgs@research.att.com) AT&T Bell Laboratories (MH 2A-244) 600 Mountain Ave; Murray Hill, NJ 07974 phone: +1 908 582-2262; fax: +1 908 582-5809 From rem-conf-request@es.net Thu Jul 15 13:41:30 1993 Received: from nic.funet.fi by osi-west.es.net with SMTP (PP) id <00669-0@osi-west.es.net>; Thu, 15 Jul 1993 10:19:04 +0000 Received: by nic.funet.fi id <91471-1>; Thu, 15 Jul 1993 20:18:58 +0300 Subject: Re: "On the Internet, nobody knows you're a dog" From: Matti Aarnio To: Guido.van.Rossum@cwi.nl Date: Thu, 15 Jul 1993 20:18:56 +0300 Cc: rem-conf@es.net In-Reply-To: <9307151325.AA01903=guido@voorn.cwi.nl> from "Guido.van.Rossum@cwi.nl" at Jul 15, 93 04:25:27 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-Length: 691 Message-Id: <93Jul15.201858eet_dst.91471-1@nic.funet.fi> > (I know this isn't the right forum, but I don't know a better one... > Flame ahead but flame in private.) > > At the IETF, someone showed a cartoon from the New Yorker (I believe) > with the caption "On the Internet, nobody knows you're a dog." Could > someone in the lucky posession of both a scanner and a copy of the > issue containing the cartoon make it available for ftp as a GIF file? > > Thanks in advance! > > --Guido van Rossum, CWI, Amsterdam I am at the Confrence presently, and will try to ask CNRI to put that picture online. Alternate place is ISOC server, where-ever that was.. /Matti Aarnio reporting at Amsterdam ;) From rem-conf-request@es.net Thu Jul 15 15:51:52 1993 Received: from viipuri.nersc.gov by osi-west.es.net with SMTP (PP) id <02094-0@osi-west.es.net>; Thu, 15 Jul 1993 12:40:00 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA17408; Thu, 15 Jul 93 12:39:57 PDT Date: Thu, 15 Jul 93 12:39:57 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9307151939.AA17408@viipuri.nersc.gov> To: Guido.van.Rossum@cwi.nl, mea@nic.nersc.gov Subject: Re: "On the Internet, nobody knows you're a dog" Cc: rem-conf@es.net > > > > At the IETF, someone showed a cartoon from the New Yorker (I believe) > > with the caption "On the Internet, nobody knows you're a dog." Could > > someone in the lucky posession of both a scanner and a copy of the > > issue containing the cartoon make it available for ftp as a GIF file? > > > > Thanks in advance! > > > > --Guido van Rossum, CWI, Amsterdam > > I am at the Confrence presently, and will try to ask CNRI to put that > picture online. Alternate place is ISOC server, where-ever that was.. > > /Matti Aarnio reporting at Amsterdam ;) > This may seem, on the surface, like a silly question: Aren't cartoons, and articles in paper media, generally protected by a copyright? Would the scanning and redistribution of the cartoon by electronic means be legal without express permission from the copyright holder? Copyright: the exclusive legal right to reproduce, publish, and sell the matter and form of a literary, musical, or artistic work And I _know_ the rem-conf list is the _wrong_ place for this discussion... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ari Ollikainen ari@es.net National Energy Research Supercomputer Center ESnet (Energy Sciences Network) Lawrence Livermore National Laboratory 510-423-5962 FAX:510-423-8744 P.O. BOX 5509, MS L-561, Livermore, CA 94550 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Thu Jul 15 17:19:49 1993 Received: from charon.cwi.nl by osi-west.es.net with SMTP (PP) id <02935-0@osi-west.es.net>; Thu, 15 Jul 1993 13:58:43 +0000 Received: from voorn.cwi.nl by charon.cwi.nl with SMTP id AA19626 (5.65b/3.8/CWI-Amsterdam); Thu, 15 Jul 1993 22:58:34 +0200 Received: by voorn.cwi.nl with SMTP id AA02661 (5.65b/3.8/CWI-Amsterdam); Thu, 15 Jul 1993 22:58:33 +0200 Message-Id: <9307152058.AA02661=guido@voorn.cwi.nl> To: rem-conf@es.net Subject: Stop the copyright flames! From: Guido.van.Rossum@cwi.nl X-Organization: CWI (Centrum voor Wiskunde en Informatica) X-Address: P.O. Box 4079, 1009 AB Amsterdam, The Netherlands X-Phone: +31 20 5924127 (work), +31 20 6225521 (home), +31 20 5924199 (fax) Date: Thu, 15 Jul 1993 22:58:33 +0200 Sender: Guido.van.Rossum@cwi.nl (Regarding my request to post a New Yorker cartoon.) OK, OK, OK, I forgot completely about the copyright issues! Let's forget the whole thing (unless someone can get permission to publish). --Guido van Rossum, CWI, Amsterdam From rem-conf-request@es.net Fri Jul 16 05:56:43 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <07600-0@osi-west.es.net>; Fri, 16 Jul 1993 02:28:05 +0000 Received: from mmc.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Fri, 16 Jul 1993 02:27:58 -0700 Posted-Date: Fri 16 Jul 93 02:27:52-PDT Received: by mmc.isi.edu (4.1/4.0.3-4) id ; Fri, 16 Jul 93 02:27:53 PDT Date: Fri 16 Jul 93 02:27:52-PDT From: Stephen Casner Subject: Re: Who's our FCC? To: Graeme.Wood@edinburgh.ac.uk, rem-conf@es.net Message-Id: <742814872.0.CASNER@MMC.ISI.EDU> In-Reply-To: <22244.9307150924@scorpio.ucs.ed.ac.uk> Mail-System-Version: Graeme, Yes, I think you understand the situation correctly, though we may differ on what to do about it or when. > There are a large number of sites (looking at the > latest map) which seem to be connected through a single mbone router > (the whole of Japan for instance) This is a function of the underlying physical topology and can't really be changed. > How will an "mbone guru" act impartially when he is asked to decide > between routing the IETF or an archaelogical conference on ancient Samoan > civilization? I know which I'd choose :-) So far, we haven't have much problem with overlapping events. As the popularity increases, overlap is more likely, and I would expect that we'd use some combination of FCFS and receivers bidding for what they want to hear. > This means that recipient effectively gets cut off > from the conference. He can always demand a refund of what he paid for it ($0). This is never going to satisfy all the customers until appripriate charges can be made and that revenue used to keep the provisioning ahead of demand. > I guess you are hoping that the increase in bandwidth available is going > to keep pace with the increase in the number of people wanting to use > these services. Well, this is a hope, but it is not going to happen unless multicast goes into the production routers. We are nowhere near the T3 limit, but we are already bumping into some limits of the multicast routers and their local ethernets due to the replication for many tunnels. This limit is reached with "one full IETF load", about 500Kb/s and 250 packets/second. So, we are going to have to select among overlapping events for a while. Pruning of multicast trees will help somewhat, but not much for the "core" multicast routers that are providing transit service across the physical backbone, for example. Careful use of TTL scoping for local events can be a big help, too, though there are multiple "local" communities that intersect in various ways so this only goes so far. -- Steve ------- From rem-conf-request@es.net Fri Jul 16 11:10:06 1993 Received: from research.att.com by osi-west.es.net with SMTP (PP) id <08569-0@osi-west.es.net>; Fri, 16 Jul 1993 05:36:14 +0000 Received: by inet; Fri Jul 16 08:35 EDT 1993 Date: Fri, 16 Jul 93 08:35:33 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: casner@isi.edu, frederic@parc.xerox.com Subject: Flow IDs and SSRC Cc: rem-conf@es.net After some discussions, I wrote up this little "FDQ" to clarify the role of SSRC and FlowIDs within RTP. SSRC vs. FlowID: Frequently Discussed Questions transport address :== network address (e.g., IPv4 address) and transport demultiplexer (e.g., UDP port) Definition: SSRC distinguishes synchronization sources when two or more share the same transport source address within the same conference. Example use: The main use is in translators so that multiple sources forwarded by the translator, all having the same transport source address, can be distinguished by the receiver. Remark: In the past, we had limited SSRC to translators as they are clearly necessary in that context (witness the difficulty that the vat recorder faces in trying to allocate a new socket for each source, something that clearly does not scale to a conference of even a hundred concurrent users.) So far, a single end system application (nv, nevot, vat, etc.) have not had more than one stream for the same conference. I do not really foresee that changing, at least not to the extent that distinct output sockets (ie., distinct ports and thus transport addresses) would not be sufficient. Distinct sockets are clearly more efficient in terms of processing and per-packet overhead. However, there seems no **conceptual** reason to outlaw the use by end systems. Only end systems that have this peculiar need have to worry about inserting SSRCs. Receivers, bridges, translators act as before, with no changes, as they have had to handle SSRC in any event. Thus, allowing SSRC insertion by end systems is merely a logical extension of the current mechanism and does not introduce any hidden changes that I am aware of. (See further discussion below in the context of FlowIDs). FlowID: Definition: The flow identifier is used to distinguish conferences (groups of sites) within the same multicast group and transport access point (e.g., UDP port). Use: On arrival, a packet is assigned first to a "conference" based on the multicast group and destination port (implicitly) and the FlowID. Then, the source within the conference is determined based on network source address, source port and SSRC (if present, assumed 0 if not). Note that ports serve two different functions: The destination port (well known, say 3456 for MBONE audio) is used to distinguish conferences within the same multicast group. The source port (randomly assigned by the sender's operating system, say 11588) is used to distinguish sources with the same network source address. If it helps, you can view the FlowID as an extension of the multicast address and well-known port number (224.2.0.1 and 3456, say), and SSRC as an extension of the source port number (192.11.12.13 and 11588, in our example). Both are needed where the underlying transport level distinction is insufficient. *** Thus, all sources within a conference have the same FlowID. **** I repeat: *** THUS, ALL SOURCES WITHIN A CONFERENCE HAVE THE SAME FLOWID. **** There is a notational difficulty as ``conference'' may mean different things to different layers of software. An RTP-level conference is equivalent to a single audio or video session as currently defined within the existing MBONE tools. We will call several media belonging together in some higher layer a multimedia conference. Questions: Q1: What happens for a multimedia conference that has both audio and video? Two choices: a) Audio and video use two different transport-level associations (that is, different multicast group and/or different ports). This may be appropriate if different transport-level treatment is desired, for example, if some sites only want to receive audio or if audio and video are to receive different priority within the network. The same multicast group, but different port is appropriate if different treatment is desired only at the receiving host. b) Both use the same multicast group and port, but different flow ids. This may be appropriate if the same transport-level treatment is to be ensured for both and if the same application is likely to handle both. (Note that they could be handled by different applications, but both would discard packets with the wrong flowid, which is rather inefficient.) Q2: What happens with two audio channels in a single ``conference''? Same as above. Q3: How are flow id's established? By out-of-band agreement (e.g., a conference setup protocol). Q4: Do translators look at flow id's? They don't need to, but may. SSRCs only have to be unique within a single FlowID, so a translator could keep track of that if it chooses to. Q5: Couldn't we use FlowIDs to tie together everything that belongs to a single multimedia conference, e.g., the audio streams, the whiteboard stream and the video streams used for, say, an IETF session? The FlowID field isn't big enough for that. Also, not all streams within a conference are going to use RTP. Plus, the association of streams with higher-layer multimedia conferences may change and is best left to conference control tools (like sd or MMCC). Also, conferences may be hierarchical (IETF - IETF sessions - audio, video, whiteboard) so that a linear enumeration may be cumbersome. Q6: Is the flowID space large enough? Given the discussion above, we only run out if there are more than 64 component media handled by the same application through the same transport level association. So far, I have not seen a likely application of that scenario. Q7: What's the difference between VATs conference identifier and the FlowID? Size and name. There is no attempt to use it to enlarge the address space for conferences as this RTP-level mechanism defeats any filtering (pruning) applied by multicast routing and forces every application within the same host subscribed to the same multicast address and port to inspect every packet and discard most. From rem-conf-request@es.net Sat Jul 17 14:12:33 1993 Received: from media-lab.media.mit.edu by osi-west.es.net with SMTP (PP) id <20055-0@osi-west.es.net>; Sat, 17 Jul 1993 11:03:51 +0000 Received: by media.mit.edu (5.57/DA1.0.4.amt) id AA06478; Sat, 17 Jul 93 14:03:49 -0400 Date: Sat, 17 Jul 93 14:03:49 -0400 From: Sarah Dickinson Message-Id: <9307171803.AA06478@media.mit.edu> To: rem-conf@es.net Subject: Subsciption request for Sarah Dickinson sarah@media.mit.edu Thank you. From rem-conf-request@es.net Tue Jul 20 03:22:02 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <07235-0@osi-west.es.net>; Tue, 20 Jul 1993 00:12:49 +0000 Received: from mmc.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Tue, 20 Jul 1993 00:12:45 -0700 Posted-Date: Tue 20 Jul 93 00:12:40-PDT Received: by mmc.isi.edu (4.1/4.0.3-4) id ; Tue, 20 Jul 93 00:12:41 PDT Date: Tue 20 Jul 93 00:12:40-PDT From: Stephen Casner Subject: Re: Flow IDs and SSRC To: hgs@research.att.com Cc: rem-conf@es.net Message-Id: <743152360.0.CASNER@MMC.ISI.EDU> In-Reply-To: <199307161236.AA15944@venera.isi.edu> Mail-System-Version: Henning, > *** Thus, all sources within a conference have the same FlowID. **** > I repeat: > *** THUS, ALL SOURCES WITHIN A CONFERENCE HAVE THE SAME FLOWID. **** It is clear that you are convinced of this point, and you may be right! However, it's not what I had in mind when I introduced the flow id idea in Boston, and even though the flow id has evolved since then, I still thought that flow id's were assigned by each source. I expect there are others who share(d) my understanding. So, a discussion of this issue is very important to make sure there are no constraints that have been overlooked. Thanks for the FDQ to get it started. I've gone back and reviewed the notes from the earlier meetings and the discussions in between, and I've tried to think through the issues of source- vs. destination-specific flow id's. For multimedia conferences, I agree that a common pre-assignment of destination flow id's should work fine, and that 64 should be sufficient. [By the way, I don't believe that the number of flows per application will always be only one. I expect that as these applications mature (perhaps, dare we say it, to the point of products being developed), there will be a higher level of integration than we see now while everyone is still experimenting.] I have some concern, though, that for applications other than multimedia conferencing the limit of 64 common flows might be a problem. The example of distributed simulation comes to mind, but I'm not working in that area and I'd like to hear from others who are. I can imagine the need to transmit many flows (more than the socket limit), but there would be no commonality for the flows among all sites. Now, it would be possible to use SSRC to solve this problem as you have described, but it increases the packet overhead. Maybe this is a non-problem, because there would need to be some application-specific multiplexing to carry multiple flows in each packet anyway. So, as I said, I'd like to hear more from those who are working in this area. A couple of specific comments: > Q3: How are flow id's established? > > By out-of-band agreement (e.g., a conference setup protocol). I don't think there is any point in assigning these flow id's randomly. There is a (temporary) constraint in nv for the flow id to be 32 or greater in order to allow detection of version mismatches with pre-RTP nv. > Q7: What's the difference between VATs conference identifier and > the FlowID? > > Size and name. Perhaps, but the difference in size means that the flow id is not useful as a further discriminator to avoid collisions of randomly-assigned addresses and ports. However, as you note, there are several disadvantages in depending upon that discrimination function: > There is no attempt to use it to enlarge the > address space for conferences as this RTP-level mechanism defeats any > filtering (pruning) applied by multicast routing and forces every > application within the same host subscribed to the same multicast > address and port to inspect every packet and discard most. Perhaps the main difference is intent: multiple flow id's would be intended for use within the same multicast address and port when the same transport treatment is desired for all, rather than as a means to keep apart separate conferences that happend to share the address and port. -- Steve ------- From rem-conf-request@es.net Tue Jul 20 08:09:56 1993 Received: from research.att.com by osi-west.es.net with SMTP (PP) id <08186-0@osi-west.es.net>; Tue, 20 Jul 1993 04:59:16 +0000 Received: by inet; Tue Jul 20 07:55 EDT 1993 Date: Tue, 20 Jul 93 07:55:12 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: CASNER@ISI.EDU, Christian.Huitema@sophia.inria.fr Subject: Re: Flow IDs and SSRC Cc: rem-conf@es.net I'll try to lower my volume by a few dB (hopefully without being cut off by the silence suppression...) > From research!mitsou.inria.fr!huitema Tue Jul 20 07:40:46 1993 > To: Stephen Casner > Cc: hgs@research.att.com, rem-conf@es.net > Subject: Re: Flow IDs and SSRC > Date: Tue, 20 Jul 93 13:41:29 +0200 > From: Christian Huitema > Content-Length: 1022 > > Steve, > > I am a bit puzzled by this "flow-id" discussion. In my simple mind, I had the > following assumptions: > > * that a source is really identified by a host + port tuple, Not quite complete. Because of translators (firewalls, if you like), we need more than that as all sources coming out of a translators will share the host/port tuple. That's what SSRC is for - it distinguishes several sources within the same conference who happen to share the same host/port tuple either a) they originate within the same application b) they came from a translator Logically, the two cases are one and the same and should be treated as such. > > * that there are cases where a source needs to send multiple flows, If the 'flows' (whatever that means) are part of the same conference, they get different SSRCs. If they are part of two different RTP-level conferences (say, audio and video), they get different flow ids. > > * that in these cases the source uses different flow-ids, and also > uses "source description" parameters to determine what flow it is. Source description? Not quite sure where/what that is. > > * that in any case the source chose what flow id to use. > > I can see two typical usages: > > * a video source handling several cameras in parallel uses different ids > to differentiate the various streams, If within the same conference, use different SSRCs. If different RTP-level conferences (say, we maintain a speaker camera and a transparency camera), use different multicast groups (best) or different flow ids. > > * a multimedia firewall that receives several flows identified by port, flow-id> forwards them with . The flow-id space is too small to serve for the firewall case (it would only work for conferences with up to 64 participants). It is too small for random allocation. When discussing this, please be very specific as what you mean by 'flow'. The name is too generic to be of much use without qualifications. From rem-conf-request@es.net Tue Jul 20 08:16:25 1993 Received: from mitsou.inria.fr by osi-west.es.net with SMTP (PP) id <08253-0@osi-west.es.net>; Tue, 20 Jul 1993 05:12:20 +0000 Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA04372; Tue, 20 Jul 1993 14:13:20 +0200 Message-Id: <199307201213.AA04372@mitsou.inria.fr> To: hgs@research.att.com (Henning G. Schulzrinne) Cc: CASNER@ISI.EDU, rem-conf@es.net Subject: Re: Flow IDs and SSRC In-Reply-To: Your message of "Tue, 20 Jul 93 07:55:12 EDT." <199307201157.AA18647@sophia.inria.fr> Date: Tue, 20 Jul 93 14:13:18 +0200 From: Christian Huitema Henning, I believe we broadly agree on what we mean by "flow". => > => > * that there are cases where a source needs to send multiple flows, => If the 'flows' (whatever that means) are part of the same conference, => they get different SSRCs. If they are part of two different RTP-level => conferences (say, audio and video), they get different flow ids. => ... => > I can see two typical usages: => > => > * a video source handling several cameras in parallel uses different ids => > to differentiate the various streams, => => If within the same conference, use different SSRCs. If different => RTP-level conferences (say, we maintain a speaker camera and a => transparency camera), use different multicast groups (best) or => different flow ids. I was working under the assumption that a multicast group identified an intended set of receivers. As such, it cannot exactly be used to identify sources. The reason why I want different flow-ids is indeed sequence control, or rather transmission control. The SSRC parameters are embedded in the stream; they are adequate for "sequential multiplexing" (e.g. switching between several cameras) but not for "parallel multiplexing" (e.g. sending both a transparency and a speaker screen). So my definition of flow is indeed a set of message that are organized in a single sequence; sequence numbers should be sequentials, and time stamps should be non decreasing. In the firewall case, we have two solutions. Either give one flow id to each participant, with the 64 sources limit that you mention, or use some form of sequential multiplexing (which may be OK for voice, but is not acceptable for video). Christian Huitema From rem-conf-request@es.net Tue Jul 20 08:16:43 1993 Received: from mitsou.inria.fr by osi-west.es.net with SMTP (PP) id <08120-0@osi-west.es.net>; Tue, 20 Jul 1993 04:40:24 +0000 Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA04301; Tue, 20 Jul 1993 13:41:31 +0200 Message-Id: <199307201141.AA04301@mitsou.inria.fr> To: Stephen Casner Cc: hgs@research.att.com, rem-conf@es.net Subject: Re: Flow IDs and SSRC In-Reply-To: Your message of "Tue, 20 Jul 93 00:12:40 PDT." <743152360.0.CASNER@MMC.ISI.EDU> Date: Tue, 20 Jul 93 13:41:29 +0200 From: Christian Huitema Steve, I am a bit puzzled by this "flow-id" discussion. In my simple mind, I had the following assumptions: * that a source is really identified by a host + port tuple, * that there are cases where a source needs to send multiple flows, * that in these cases the source uses different flow-ids, and also uses "source description" parameters to determine what flow it is. * that in any case the source chose what flow id to use. I can see two typical usages: * a video source handling several cameras in parallel uses different ids to differentiate the various streams, * a multimedia firewall that receives several flows identified by forwards them with . Now, I don't see how this matches Henning's forceful assertion: > *** Thus, all sources within a conference have the same FlowID. **** > I repeat: > *** THUS, ALL SOURCES WITHIN A CONFERENCE HAVE THE SAME FLOWID. **** .. or else, I don't see what flow-ids are for. Christian Huitema From rem-conf-request@es.net Tue Jul 20 09:12:48 1993 Received: from mitsou.inria.fr by osi-west.es.net with SMTP (PP) id <08663-0@osi-west.es.net>; Tue, 20 Jul 1993 06:06:39 +0000 Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA04553; Tue, 20 Jul 1993 15:07:42 +0200 Message-Id: <199307201307.AA04553@mitsou.inria.fr> To: hgs@research.att.com (Henning G. Schulzrinne) Cc: rem-conf@es.net Subject: Re: Flow IDs and SSRC In-Reply-To: Your message of "Tue, 20 Jul 93 08:56:06 EDT." <199307201259.AA28119@sophia.inria.fr> Date: Tue, 20 Jul 93 15:07:41 +0200 From: Christian Huitema Henning, The one point on which we seem to violently disagree is usage of SSRC in conjunction with RTP sequence numbering. The one and only thing I care is that one maps into exactly one sequence number space, regardless of the value of the SSRC parameter. That is, I did not believe until know that I had to check the SSRC parameter in order to validate the RTP sequence number. If we look at the receiver site, that means that I have to maintain one "context" per tuple, NOT one per SSRC value. Christian Huitema From rem-conf-request@es.net Tue Jul 20 09:14:03 1993 Received: from research.att.com by osi-west.es.net with SMTP (PP) id <08568-0@osi-west.es.net>; Tue, 20 Jul 1993 05:58:51 +0000 Received: by inet; Tue Jul 20 08:56 EDT 1993 Date: Tue, 20 Jul 93 08:56:06 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: Christian.Huitema@sophia.inria.fr Subject: Re: Flow IDs and SSRC Cc: CASNER@ISI.EDU, rem-conf@es.net > From research!mitsou.inria.fr!huitema Tue Jul 20 08:35:50 1993 > To: hgs@research.att.com (Henning G. Schulzrinne) > Cc: CASNER@ISI.EDU, rem-conf@es.net > Subject: Re: Flow IDs and SSRC > Date: Tue, 20 Jul 93 14:13:18 +0200 > From: Christian Huitema > Content-Length: 1686 > > Henning, > > I believe we broadly agree on what we mean by "flow". Unfortunately, I'm not so sure. You are confusing me more by the minute. > > I was working under the assumption that a multicast group identified an > intended set of receivers. As such, it cannot exactly be used to identify > sources. I didn't mean to imply that a multicast group identify sources. It identifies a group of sources and receivers (what we commonly call a conference, with the understanding that we are referring to a single-media conference at this level). > > The reason why I want different flow-ids is indeed sequence control, or > rather transmission control. The SSRC parameters are embedded in the stream; > they are adequate for "sequential multiplexing" (e.g. switching between > several cameras) but not for "parallel multiplexing" (e.g. sending both a > transparency and a speaker screen). So my definition of flow is indeed a set > of message that are organized in a single sequence; sequence numbers should be > sequentials, and time stamps should be non decreasing. Flow id and SSRC are both embedded in the stream. The speaker/transparency case can be viewed as two different cases: a) like two different participants, with no semantic difference between the two (makes sense if the camera assignment isn't fixed and if only one or a few sites use several cameras). If you use two applications (with different source port), they will appear as two sources within the same conference. If you want to use a single multi-camera application, either send them through two different sockets or give them different SSRC. If you want to do sequential multiplexing, as you call it, i.e., enable one camera or the other, that is handled just fine. b) like participants in two different conferences (the speaker conference and the 'transparency' conference). In this case, give the two different multicast addresses (if you want network selectivity, i.e., some subset of receivers don't care about seeing the speaker) or two different flow ids if you want the same network treatment. > > In the firewall case, we have two solutions. Either give one flow id to each > participant, with the 64 sources limit that you mention, or use some form of > sequential multiplexing (which may be OK for voice, but is not acceptable for > video). I never suggested forcing several voice sources into one 'source' ( as perceived by a receiver) at a translator, even for voice. That's why we have SSRCs. We have two orthogonal notions: -- a conference (a group of sources using a single medium) one application at a single site may - contribute several sources A conference is identified by the triple mcast address/destination port/flow id -- a source A source is identified by the triple source address/source port/SSRC where SSRC is optional and needed only if the source address and source port are not sufficient to identify a source. A higher-layer conference control protocol may group several conferences into a single 'CONFERENCE' (as seen by a user), possibly hierarchically (see Rangan's paper). From rem-conf-request@es.net Tue Jul 20 13:46:24 1993 Received: from research.att.com by osi-west.es.net with SMTP (PP) id <11439-0@osi-west.es.net>; Tue, 20 Jul 1993 10:35:48 +0000 Received: by inet; Tue Jul 20 13:33 EDT 1993 Date: Tue, 20 Jul 93 13:32:59 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: Christian.Huitema@sophia.inria.fr Subject: Re: Flow IDs and SSRC Cc: rem-conf@es.net > From research!es.net!rem-conf-request Tue Jul 20 10:06:44 1993 > To: hgs@research.att.com (Henning G. Schulzrinne) > Cc: rem-conf@es.net > Subject: Re: Flow IDs and SSRC > Date: Tue, 20 Jul 93 15:07:41 +0200 > From: Christian Huitema > Content-Length: 588 > > Henning, > > The one point on which we seem to violently disagree is usage of SSRC in > conjunction with RTP sequence numbering. The one and only thing I care is that > one maps into exactly one sequence number > space, regardless of the value of the SSRC parameter. That is, I did not > believe until know that I had to check the SSRC parameter in order to validate > the RTP sequence number. What you ask for is impossible (or defeats the purpose of SSRC). Example: A translator receives packets from one multicast group and sources A and B. The two sources A and B know nothing of each other, so their sequence number spaces are going to be different. They HAVE to have a different SSRC (since they have the same source address and source port), otherwise the poor receiver wouldn't know whether a packet came from A or B. As I said earlier, renaming the Flow ID to take over SSRC duties is a bad idea since it restricts conferences to 64 participants. The amount of state kept by the translators would not change. Thus, the receiver algorithm is simple: 1) determine the conference a packet belongs to (using the flow id); if there is only one flow id in a multicast group/destination port pair, the conference follows directly from the socket the packet arrives on. 2) determine the synchronization source within that conference (sequence number space) by matching the three quantities source address, source port, SSRC If your application doesn't know about conferences, you map sources by socket, flow id, source address, source port, SSRC. Henning From rem-conf-request@es.net Tue Jul 20 15:01:35 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <12559-0@osi-west.es.net>; Tue, 20 Jul 1993 11:46:12 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11864>; Tue, 20 Jul 1993 11:45:59 PDT Received: by ecco.parc.xerox.com id <16136>; Tue, 20 Jul 1993 11:45:52 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Tue, 20 Jul 1993 11:45:47 -0700 (PDT) Message-ID: Date: Tue, 20 Jul 1993 11:45:47 PDT Sender: Ron Frederick From: Ron Frederick To: Christian Huitema Subject: Re: Flow IDs and SSRC CC: rem-conf@es.net In-Reply-To: <199307201307.AA04553@mitsou.inria.fr> References: <199307201307.AA04553@mitsou.inria.fr> Christian: I had always thought that flow id meant what you thought it did as well. However, I think Henning's point about that use of it being superfluous given the SSRC is correct. In particular, you wrote: > If we look at the receiver site, that means that I have to maintain one > "context" per tuple, NOT one per > SSRC value. This is simply incorrect. Independent of how you choose to interpret the flow id, you need to treat each tuple as having its own context. A syncronization source does retiming, and will generate a new set of sequence numbers. So, if you see two different SSRC ids, you'll have two different sequence number spaces. Now, under Henning's interpretation, you _don't_ need to include the flow id in this, so it's not a major effort to change the software. You simply use the tuple to distinguish conferences (which really means binding to that host & port and throwing away any packets which don't have the right flow id for most applications), and the tuple to distinguish sources within that conference. If there's anything that concerns me in this new scheme, it is only the question about whether we need the flow id at all. If you really believe that you want to have multiple conferences which desire exactly the same transport characteristics, then you do, but do we really ever want that? In the case where you have both audio & video and you choose to have them always delivered together, for example, there's no reason not to have ONE conference and just have each sender send multiple streams with different content types... -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Tue Jul 20 18:01:27 1993 Received: from research.att.com by osi-west.es.net with SMTP (PP) id <14828-0@osi-west.es.net>; Tue, 20 Jul 1993 14:51:28 +0000 Received: by inet; Tue Jul 20 17:50 EDT 1993 Date: Tue, 20 Jul 93 17:05:52 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: Christian.Huitema@sophia.inria.fr, frederic@parc.xerox.com Subject: Re: Flow IDs and SSRC Cc: rem-conf@es.net > From research!es.net!rem-conf-request Tue Jul 20 16:45:31 1993 > Date: Tue, 20 Jul 1993 11:45:47 PDT > Sender: Ron Frederick > From: Ron Frederick > To: Christian Huitema > Subject: Re: Flow IDs and SSRC > Cc: rem-conf@es.net > Content-Length: 1751 > > Christian: > > I had always thought that flow id meant what you thought it did as well. > However, I think Henning's point about that use of it being superfluous > given the SSRC is correct. In particular, you wrote: > ... Thanks for the additional clarification, Ron. > > If there's anything that concerns me in this new scheme, it is only the > question about whether we need the flow id at all. If you really believe > that you want to have multiple conferences which desire exactly the > same transport characteristics, then you do, but do we really ever want > that? In the case where you have both audio & video and you choose to > have them always delivered together, for example, there's no reason not > to have ONE conference and just have each sender send multiple streams > with different content types... > -- > Ron Frederick > frederick@parc.xerox.com > I was afraid somebody would open that can of worms... First, to limit the confusion, encoding, format (FMT) and content type field are one and the same, just different names. (The draft avoids the name content type since content source has a somewhat unrelated and different meaning, but I digress...) Flow Id and content type are different: A single source may change encoding (or format) without becoming a different source; sequence number range and time stamp all are unchanged, just the interpretation of the data changes by the 'next layer'. Now, it may be possible to overload the content field by setting aside some encodings for video and some for audio, say, but that seems a bit kludged. You'd probably argue for a bigger encoding field than 6 bits and we are pretty much back to where we started. I believe (not that I'm biased or anything...) that flow id, SSRC and format (FMT) serve three distinguishable and useful functions. I hope that this discussion (and the upcoming draft) has made (will make) the distinctions clear. As I pointed out through the speaker/transparency example, different uses of these fields are appropriate in different contexts. If you want to call that 'mechanism instead of policy', be my guest :-) I also agree that the Flow Id is probably the most expendable of the bunch. I see one use where several 'conferences' are carried in the same RTP packet (e.g., audio and video for easier synchronization and lower header overhead). Henning From rem-conf-request@es.net Tue Jul 20 19:35:10 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <16460-0@osi-west.es.net>; Tue, 20 Jul 1993 16:22:06 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <12038>; Tue, 20 Jul 1993 16:21:50 PDT Received: by ecco.parc.xerox.com id <16136>; Tue, 20 Jul 1993 16:21:40 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Tue, 20 Jul 1993 16:21:33 -0700 (PDT) Message-ID: <8gH7rxgB0bH4E2YhcQ@ecco.parc.xerox.com> Date: Tue, 20 Jul 1993 16:21:33 PDT Sender: Ron Frederick From: Ron Frederick To: hgs@research.att.com (Henning G. Schulzrinne) Subject: Re: Flow IDs and SSRC CC: rem-conf@es.net In-Reply-To: <93Jul20.145131pdt.11899@alpha.xerox.com> References: <93Jul20.145131pdt.11899@alpha.xerox.com> > Flow Id and content type are different: A single source may change > encoding (or format) without becoming a different source; sequence > number range and time stamp all are unchanged, just the interpretation > of the data changes by the 'next layer'. Right - I was a bit unclear in my example. I was actually implying that you would simply create multiple streams (each with their own SSRC) in one conference, rather than creating multiple parallel conferences. The question I was raising was really whether we think that parallel conferences with the same multicast address and port are ever really an interesting or useful thing. By having them be multiple conferences, we require that a user participating in more than one actually has to repeat SDES information in all of them, for example. This seems really wasteful. It makes more sense to me to just have a single conference, where some participants will send multiple streams. In the case where we really do want to send only audio to some sites and both audio & video to others, I think it makes sense to have multiple conferences, but there you will want to use a different multicast address for the different conferences, so again you don't need the flow id. Even there, sending multiple SDES records is somewhat wasteful, and it might make sense to have a way of tying these multicast destinations together, so all participants can look in one place for participant information. That's an orthogonal issue to the flow id question, though. Does anyone have a good example of where it makes sense to have parallel conferences with the same multicast address and port, such that two different flow ids would be needed? -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Tue Jul 20 19:53:11 1993 Received: from zephyr.isi.edu by osi-west.es.net with SMTP (PP) id <16808-0@osi-west.es.net>; Tue, 20 Jul 1993 16:42:03 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Tue, 20 Jul 1993 16:41:52 -0700 Date: Tue, 20 Jul 1993 16:41:52 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199307202341.AA02176@zephyr.isi.edu> To: Christian.Huitema@sophia.inria.fr, frederic@parc.xerox.com, hgs@research.att.com Subject: Re: Flow IDs and SSRC Cc: rem-conf@es.net This discussion of RTP is relevent to RSVP. The question in RSVP is, how to address the finest entity that can receive its own reservation? We have been using a (IP address, port number) pair for this purpose. If RTP is the transport protocol, should it be (IP address, port number, flowId)? I have been thinking that RSVP should define the entity which can receive a reservation by the pair (IP address, ApplicFlowId), where ApplicFlowId is a 32 bit number whose structure need be known only to the application layer in the end systems. It might contain simply a port number, or it might contain (Port number, flowId), or it might contain a 32-bit demultiplexing field from some future transport protocol. The top of the service architecture of RSVP should match the service requirements at the bottom of the application layer. Bob Braden From rem-conf-request@es.net Wed Jul 21 01:34:31 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <23120-0@osi-west.es.net>; Tue, 20 Jul 1993 22:23:44 +0000 Received: from mmc.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Tue, 20 Jul 1993 22:23:40 -0700 Posted-Date: Tue 20 Jul 93 22:23:34-PDT Received: by mmc.isi.edu (4.1/4.0.3-4) id ; Tue, 20 Jul 93 22:23:36 PDT Date: Tue 20 Jul 93 22:23:34-PDT From: Stephen Casner Subject: Cash for sockets To: rem-conf@es.net Message-Id: <743232214.0.CASNER@MMC.ISI.EDU> Mail-System-Version: While I was discussing the RTP FlowID / SSRC issues with Bob Braden, he asked why we need SSRC, why not just use multiple source port numbers. I countered that there are constraints on the number of sockets one can have. He said that was just a UNIX-ism, why not use one socket to send on multiple ports. Hmmm. One could re-bind() to socket for each send, but that might be too expensive. If the total number of sources is large, but only a smaller number are active at any given time, how about using a cache of sockets to reduce the frequency of re-binding. One would have to supply one's own port numbers, rather than letting the system allocate them. -- Steve ------- From rem-conf-request@es.net Wed Jul 21 01:50:38 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <23113-0@osi-west.es.net>; Tue, 20 Jul 1993 22:20:42 +0000 Received: from mmc.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Tue, 20 Jul 1993 22:20:38 -0700 Posted-Date: Tue 20 Jul 93 22:20:33-PDT Received: by mmc.isi.edu (4.1/4.0.3-4) id ; Tue, 20 Jul 93 22:20:35 PDT Date: Tue 20 Jul 93 22:20:33-PDT From: Stephen Casner Subject: Re: Flow IDs and SSRC To: rem-conf@es.net Message-Id: <743232033.0.CASNER@MMC.ISI.EDU> In-Reply-To: <199307202341.AA02176@zephyr.isi.edu> Mail-System-Version: First, I forgot to mention in my message of last night that having the FlowIDs be an extension of the destination address (multicast group and port) means that a bridge (e.g., audio mixer) will be receiving the same FlowID from all the sources it will mix, and will send on the mixed packet with the same FlowID. That means we avoid the problem of needing to translate the FlowID backward in passing QOS information back beyond the mixer to the sources (when that is appropriate). Now, some comments on today's discussion: Christian> * there are cases where a source needs to send multiple flows, Under Henning's model where the FlowID is part of the destination addressing, it is still possible for a source to send multiple flows using different FlowIDs, but the FlowIDs are defined in common for all the sources in the set that are communicating (have to be careful with the word "conference"). Note that all sources need not use all the defined FlowIDs. Christian> * that in these cases the source uses different flow-ids, and also Christian> uses "source description" parameters to determine what flow it is. I'm not sure whether the SDES option was intended to be flow-specific or general for all flows from a single (synchronization) source. I did not see that specific question addressed in the draft. Are there strong reasons why it should be one way or the other? (See below). Christian> I can see two typical usages: Christian> * a video source handling several cameras in parallel uses Christian> different ids to differentiate the various streams, This still works, as described above, assuming that it is feasible to define ahead of time some number of FlowIDs for camera1, ... cameraN. Henning> That's what SSRC is for - it distinguishes Henning> several sources within the same conference who happen to share the Henning> same [source] host/port tuple [because] either Henning> Henning> a) they originate within the same application Henning> b) they came from a translator Case (a) is appropriate for the record/playback application, as Henning has mentioned, but that's really because it is just a very slow translator. For the multiple-camera example, I think the use of separate "conferences" (different FlowIDs or multicast addresses) rather than SSRCs is better for two reasons: 1. It has less header overhead than using SSRC. 2. As Henning noted, the semantics may be different. For example, if I have two cameras on my workstation, we may well want those two images to be presented with a different relationship to each other than they would have to the image from the camera on Ron's workstation. When these flows go through a bridge, we may also want different processing for the two images from my workstation than we would want between the camera1 image from my workstation and the camera1 image from Ron's workstation. If the two cameras are only distinguished by SSRCs, then you can't tell those cases apart. Henning suggested that it was better to use different multicast groups than different FlowIDs. This would be true if you want the distribution trees to be different for the two camera signals. However, if the distribution trees should be the same, or if the switching should be dynamic using the filtering capabilities of RSVP (that's another message), then the multicast groups should be the same so as not to consume that resource any more rapidly than necessary. It also seems that we might want to consider multiple flows with different FlowIDs but the same multicast address and port to be grouped, whereas flows with different multicast addresses would not be. In the case of the video bridge just mentioned, we might want the two camera images from my workstation, distinguished by FlowID, to be treated together in some way, whereas two video flows to different multicast addresses would bear no relation to each other. Christian> The SSRC parameters are embedded in the stream; they are Christian> adequate for "sequential multiplexing" (e.g. switching Christian> between several cameras) but not for "parallel Christian> multiplexing" (e.g. sending both a transparency and a Christian> speaker screen). Perhaps you are confusing SSRC and SDES? The SSRC parameter would be carried on every packet in those places where it is needed, and is adequate for "parallel multiplexing". SDES is the periodic option used to describe a source. Henning> As I said earlier, renaming the Flow ID to take over SSRC duties is Henning> a bad idea since it restricts conferences to 64 participants. Also, SDES would have to be defined to be particular to each flow if the FlowID were used this way. That may be right or wrong. See below. Henning> I believe (not that I'm biased or anything...) that flow id, SSRC and Henning> format (FMT) serve three distinguishable and useful functions. I agree. Henning> I also agree that the Flow Id is probably the most expendable of the Henning> bunch. I see one use where several 'conferences' are carried in the Henning> same RTP packet (e.g., audio and video for easier synchronization and Henning> lower header overhead). You lost me here. Are you talking about the case when using the (not-yet-defined) profile which dictates that a framing length always be included so that multiple RTP PDUs can be put into one (for example) UDP packet? This isn't really multiple 'conferences' in one RTP packet. Ron> I was actually implying that Ron> you would simply create multiple streams (each with their own SSRC) Ron> in one conference, rather than creating multiple parallel conferences. I don't like this because of the extra header overhead of SSRC. Ron> The question I was raising was really whether we think that parallel Ron> conferences with the same multicast address and port are ever really Ron> an interesting or useful thing. By having them be multiple conferences, Ron> we require that a user participating in more than one actually has to Ron> repeat SDES information in all of them, for example. This seems really Ron> wasteful. This seems backwards to me. Having one host send multiple streams in one "conference" using different SSRCs is the case that requires multiple SDES options to be sent (unless some streams are to be left unidentified). The same SDES cannot apply to all the streams or else in the case of several independent hosts sending their streams through a translator (and having SSRCs applied), the received would be instructed to overlay all the SDESs on top of each other and apply them to all the streams. That would be similar to the flip-flopping names we sometimes see in vat. On the other hand, it seems to me that using separate "conferences" distinguished by different FlowIDs but one synchronization source, we could define the SDES to apply to all FlowIDs. (As I said near the top of this missive, I'm not sure what is the current definition.) Or, if we do want the SDES to apply to only one FlowID so we can name the flows (e.g., "Ron's Transparencies"), then the SDES has to be repeated for either the FlowID or SSRC choice, so that cost is the same. [As an aside, note that we used to have an FDESC (flow descriptor), but we got rid of it as part of the RTCP bashing.] Ron> In the case where we really do want to send only audio to some Ron> sites and both audio & video to others, I think it makes sense to Ron> have multiple conferences, but there you will want to use a Ron> different multicast address for the different conferences, so Ron> again you don't need the flow id. Even there, sending multiple Ron> SDES records is somewhat wasteful, and it might make sense to Ron> have a way of tying these multicast destinations together, so all Ron> participants can look in one place for participant information. Ron> That's an orthogonal issue to the flow id question, though. Almost, except considering what Bob Braden said: Bob> I have been thinking that RSVP should define the entity which can Bob> receive a reservation by the pair (IP address, ApplicFlowId), where Bob> ApplicFlowId is a 32 bit number whose structure need be known only to Bob> the application layer in the end systems. It might contain simply Bob> a port number, or it might contain (Port number, flowId), or it Bob> might contain a 32-bit demultiplexing field from some future Bob> transport protocol. Perhaps in this case we should use the same multicast address for both audio and video, and use RSVP filters to achieve the subset for audio only (especially if the selection of whether or not to include video or what size of video is likely to be dynamic). [The RSVP folks have assumed that change to the multicast routing might be too slow -- I hope I have not misstated this.] Then, if the multicast address is the same, the audio and video flows might be distinguished for RSVP and the application by port number or by FlowID. If we choose FlowID, and SDES applies to all flows, then we don't have the waste to which Ron refers. -- Steve ------- From rem-conf-request@es.net Wed Jul 21 04:07:38 1993 Received: from mitsou.inria.fr by osi-west.es.net with SMTP (PP) id <24070-0@osi-west.es.net>; Wed, 21 Jul 1993 00:59:37 +0000 Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA06353; Wed, 21 Jul 1993 10:00:30 +0200 Message-Id: <199307210800.AA06353@mitsou.inria.fr> To: Ron Frederick Cc: hgs@research.att.com (Henning G. Schulzrinne), rem-conf@es.net Subject: Re: Flow IDs and SSRC In-Reply-To: Your message of "Tue, 20 Jul 93 16:21:33 PDT." <8gH7rxgB0bH4E2YhcQ@ecco.parc.xerox.com> Date: Wed, 21 Jul 93 10:00:29 +0200 From: Christian Huitema Ron, I read what you read to, but it seems that we really have opened "a can of worms". If two implementors groups have a major misreading of the RTP spec, then it seems that something need to be done. Up to now, I thought that the characteristics of RTP where the following: * "Flow" is identified by source address, source port, flow-id, * within one flow, packets are sequence numbered, * packets carry a date, which is expected to monotically increase within a flow, * packets carry a content ID, which really is an "encoding id", and carries reserved values for "ADPCM audio" or "H.261 video" -- or whatever, * packets may (but need not) carry various parameters, which can be either optional attributes of the flow (e.g. some identification of the source) or application specific. What I read from the present discussion is: 1) That flow-id really is useless. The function is performed by the SSRC parameter, which if I understand correctly becomes mandatory. 2) that there is a desire to carry multiple RTP contents within the same (UDP?) packet, e.g. a voice segment and a video frame. 3) that there is a desire to handle the "conference" concept at the RTP level, i.e. pass parameters which are somehow common to multiple streams. I think that this grants a major revision of RTP, and should be discussed within the group. I personally don't believe that we need (3) as conference control functionalities, i.e. the "coordination" or "synchronisation" of multiple streams should really be handle outside RTP -- we should wait for the output of mmusic. Functionality (1) really means that we should revise the protocol and either drop the flow-id and SSRC concepts entirely (mandate that different streams originate from different UDP ports) or merge them in a revised RTP header (a 32 bits flow-id?). Functionality (2) would also need a major revision of the protocol. It opens an interesting can of worms.. What about the "keep it simple, stable" principle? Christian Huitema From rem-conf-request@es.net Wed Jul 21 12:22:25 1993 Received: from zephyr.isi.edu by osi-west.es.net with SMTP (PP) id <26664-0@osi-west.es.net>; Wed, 21 Jul 1993 09:10:33 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Wed, 21 Jul 1993 09:10:30 -0700 Date: Wed, 21 Jul 1993 09:10:30 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199307211610.AA08676@zephyr.isi.edu> To: rem-conf@es.net, CASNER@ISI.EDU Subject: Re: Cash for sockets *> From rem-conf-request@es.net Tue Jul 20 22:37:55 1993 *> Date: Tue 20 Jul 93 22:23:34-PDT *> From: Stephen Casner *> Subject: Cash for sockets *> To: rem-conf@es.net *> Mail-System-Version: *> Content-Length: 685 *> X-Lines: 12 *> *> While I was discussing the RTP FlowID / SSRC issues with Bob Braden, *> he asked why we need SSRC, why not just use multiple source port *> numbers. I countered that there are constraints on the number of *> sockets one can have. He said that was just a UNIX-ism, why not use *> one socket to send on multiple ports. Hmmm. One could re-bind() to *> socket for each send, but that might be too expensive. If the total *> number of sources is large, but only a smaller number are active at *> any given time, how about using a cache of sockets to reduce the *> frequency of re-binding. One would have to supply one's own port *> numbers, rather than letting the system allocate them. *> -- Steve *> ------- *> I guess that's what they call an elegant kludge! It's a BSDism; unfair to blame all of Unix. My comment was that it was a limitation of a particular operating system, and need not hold for all time in all places. Bob From rem-conf-request@es.net Wed Jul 21 13:40:14 1993 Received: from interlock.ans.net by osi-west.es.net with SMTP (PP) id <27538-0@osi-west.es.net>; Wed, 21 Jul 1993 10:28:08 +0000 Received: by interlock.ans.net id AA06324 (InterLock SMTP Gateway 1.1 for rem-conf@es.net); Wed, 21 Jul 1993 13:23:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 21 Jul 1993 13:23:08 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 21 Jul 1993 13:23:08 -0400 From: Curtis Villamizar Message-Id: <199307211726.AA60804@foo.ans.net> To: braden@ISI.EDU (Bob Braden) Cc: rem-conf@es.net, CASNER@ISI.EDU, curtis@ans.net Subject: Re: Cash for sockets In-Reply-To: (Your message of Wed, 21 Jul 93 09:10:30 MST.) <199307211610.AA08676@zephyr.isi.edu> Date: Wed, 21 Jul 93 13:26:26 -0500 > *> While I was discussing the RTP FlowID / SSRC issues with Bob Braden, > *> he asked why we need SSRC, why not just use multiple source port > *> numbers. I countered that there are constraints on the number of > *> sockets one can have. He said that was just a UNIX-ism, why not use > *> one socket to send on multiple ports. Hmmm. One could re-bind() to > *> socket for each send, but that might be too expensive. If the total > *> number of sources is large, but only a smaller number are active at > *> any given time, how about using a cache of sockets to reduce the > *> frequency of re-binding. One would have to supply one's own port > *> numbers, rather than letting the system allocate them. > *> -- Steve > *> ------- > *> > > I guess that's what they call an elegant kludge! > > It's a BSDism; unfair to blame all of Unix. My comment was that it was > a limitation of a particular operating system, and need not hold for all > time in all places. > > Bob Bob, How about retaining SSRC as a "practical consideration" reflecting a limitation of certain commonly used operating systems and the need to avoid the resulting inefficiency otherwise nessecary to work around the limitation. I realize that you could also consider this a redundant appendage to the protocol to avoid the need for a somewhat inefficient hack or at best the proposed Casner "elegant kludge". As long as you can come up with some reasonable usage guidelines keeping the SSRC might work out. Curtis From rem-conf-request@es.net Wed Jul 21 13:47:54 1993 Received: from zephyr.isi.edu by osi-west.es.net with SMTP (PP) id <27659-0@osi-west.es.net>; Wed, 21 Jul 1993 10:35:28 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Wed, 21 Jul 1993 10:35:22 -0700 Date: Wed, 21 Jul 1993 10:35:22 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199307211735.AA11074@zephyr.isi.edu> To: braden@ISI.EDU, curtis@ans.net Subject: Re: Cash for sockets Cc: rem-conf@es.net, CASNER@ISI.EDU *> Bob, *> *> How about retaining SSRC as a "practical consideration" reflecting a *> limitation of certain commonly used operating systems and the need to *> avoid the resulting inefficiency otherwise nessecary to work around *> the limitation. I realize that you could also consider this a *> redundant appendage to the protocol to avoid the need for a somewhat *> inefficient hack or at best the proposed Casner "elegant kludge". As *> long as you can come up with some reasonable usage guidelines keeping *> the SSRC might work out. *> *> Curtis *> Curtis, Sounds reasonable to me, I guess, as long as it does not cost too much or is not too ugly. The discussion I was having with Steve was about the granularity of resource reservation... whether or not port numbers are sufficient. I am still very puzzled about this issue. [Over the years, I have typically taken the pragmatic side in protocol discussions myself, and looking back, I'll have to say that I was probably wrong most of the time. I won't tell you which kludges still in the protocols are partly my fault, but I can admit that I favored rubber EOL in TCP and GiveBacks in NCP... (!).] Bob From rem-conf-request@es.net Wed Jul 21 17:17:19 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <00832-0@osi-west.es.net>; Wed, 21 Jul 1993 14:08:41 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <12219>; Wed, 21 Jul 1993 14:08:30 PDT Received: by ecco.parc.xerox.com id <16136>; Wed, 21 Jul 1993 14:08:21 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Wed, 21 Jul 1993 14:08:10 -0700 (PDT) Message-ID: Date: Wed, 21 Jul 1993 14:08:10 PDT Sender: Ron Frederick From: Ron Frederick To: Stephen Casner Subject: Re: Flow IDs and SSRC CC: rem-conf@es.net In-Reply-To: <743232033.0.CASNER@MMC.ISI.EDU> References: <743232033.0.CASNER@MMC.ISI.EDU> Yes, I think this discussion has definitely evolved into the can-of-worms phase, but I think it's good we discovered this basic difference in model and that we're working to resolve it... Steve> I'm not sure whether the SDES option was intended to be Steve> flow-specific or general for all flows from a single Steve> (synchronization) source. I did not see that specific question Steve> addressed in the draft. Are there strong reasons why it should be Steve> one way or the other? (See below). I agree that this isn't really addressed in the draft one way or the other, but I'm really uncomfortable with the notion of sharing information of this sort across multiple flow ids. I'd like to keep the demultiplexing as clean as possible, and that means that you would use the socket packets arrived on plus the flow id to do your first bit of state lookup (determining whether the packet was for a conference you were currently involved in). Any information about participants would be conference specific. Trying to share that information strikes me as yet _another_ model for what the flow id means! I'm not sure I like that one. Steve> It also seems that we might want to consider multiple flows with Steve> different FlowIDs but the same multicast address and port to be Steve> grouped, whereas flows with different multicast addresses would Steve> not be. In the case of the video bridge just mentioned, we might Steve> want the two camera images from my workstation, distinguished Steve> by FlowID, to be treated together in some way, whereas two video Steve> flows to different multicast addresses would bear no relation to Steve> each other. This really inverts the meaning of flow id, back to what Henning says SSRC is for. It's true that the flow id takes up less space in the back than SSRC, and that might be a reason to _remove_ SSRC and make the flow id field take over the SSRC functionality, but it doesn't convince me at all that we should have both of them. Bob> I have been thinking that RSVP should define the entity which can Bob> receive a reservation by the pair (IP address, ApplicFlowId), where Bob> ApplicFlowId is a 32 bit number whose structure need be known Bob> only to the application layer in the end systems. It might contain Bob> simply a port number, or it might contain (Port number, flowId), or Bob> it might contain a 32-bit demultiplexing field from some future Bob> transport protocol. Steve> Perhaps in this case we should use the same multicast address for Steve> both audio and video, and use RSVP filters to achieve the subset for Steve> audio only (especially if the selection of whether or not to include Steve> video or what size of video is likely to be dynamic). [The RSVP Steve> folks have assumed that change to the multicast routing might be Steve> too slow -- I hope I have not misstated this.] I think we have to be careful here not to make RTP depend on RSVP. It's good that we think about how to make what RTP does be RSVP-friendly, but RTP should be able to run efficiently even when RSVP isn't present. As a result, I think expecting to be able to use RSVP to do the audio-only filtering is a bad idea. It might be fine to do that for a conference which happens to be between people which all have RSVP, but we still have to deal with the non-RSVP case for some time to come. Given that, I still can't really come up with a situation where I'd like to see the flow id (defined as Henning currently has in mind) be used. I agree with Henning that 6 bits is probably too little for SSRC, because you'd then be forcing translators to start opening up more than one source socket (or toggle between port bindings) in order to handle more than 64 conference participants. Also, while the SSRC overhead is 4 bytes, you only need it for the streams you send after the first one. If you still consider that overhead too great, you can always choose to use multiple source ports instead. So, I guess I would recommend leaving the SSRC as-is both in meaning and implementation, but seriously considering whether we shouldn't just eliminate the flow-id field entirely... -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Jul 21 17:20:08 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <00854-0@osi-west.es.net>; Wed, 21 Jul 1993 14:10:28 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Wed, 21 Jul 1993 14:10:25 -0700 Posted-Date: Wed 21 Jul 93 14:09:48-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 21 Jul 93 14:09:49 PDT Date: Wed 21 Jul 93 14:09:48-PDT From: Stephen Casner Subject: Re: Cash for sockets To: rem-conf@es.net Message-Id: <743288988.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199307211735.AA11074@zephyr.isi.edu> Mail-System-Version: It has been pointed out to me that it may not be possible to bind() a socket more than once under most/all BSD-derived systems. I suppose that to maintain a limit on the number of sockets used, one could choose the LRU socket and close it, then create a new one and bind it. This is more overhead, of course. The bind is required because you must maintain the same port number for a given logical source across the multiple times that you may set up a socket for it. If multiple processes on one host are doing this, and if they might be participating in the same session (multicast address, destination port, and FlowID in the case of RTP), then it is possible they will simultaneously use the same source port number because we are defeating the unique allocation that the kernel provides. -- Steve ------- From rem-conf-request@es.net Wed Jul 21 20:10:54 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <03149-0@osi-west.es.net>; Wed, 21 Jul 1993 17:02:04 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <12210>; Wed, 21 Jul 1993 17:01:43 PDT Received: by ecco.parc.xerox.com id <16136>; Wed, 21 Jul 1993 17:01:31 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Wed, 21 Jul 1993 17:01:16 -0700 (PDT) Message-ID: Date: Wed, 21 Jul 1993 17:01:16 PDT Sender: Ron Frederick From: Ron Frederick To: Christian Huitema Subject: Re: Flow IDs and SSRC CC: rem-conf@es.net In-Reply-To: <199307210800.AA06353@mitsou.inria.fr> References: <199307210800.AA06353@mitsou.inria.fr> More random stuff... Christian> 1) That flow-id really is useless. The function is performed by Christian> the SSRC parameter, which if I understand correctly becomes Christian> mandatory. SSRC doesn't become mandatory. If the option is not present, you assign an SSRC of 0. So, _one_ of the streams you send can omit the SSRC option. If that's the only stream from that network source address and port, you're all set. So, if you don't ever want to use SSRC, you can simply use different network source ports. If those become scarce, or if it is more convenient to stick with one source port, you can use SSRC. However, I agree about the flow-id being useless. Christian> 2) that there is a desire to carry multiple RTP contents within Christian> the same (UDP?) packet, e.g. a voice segment and a video Christian> frame. You could use the existing RTP framing options for this, to simply bundle multiple RTP data units in the lower level transport unit. However, I don't think we want to get into multiple RTP data streams within a single RTP data unit. I'm not really sure if that was even being suggested, but if it was I agree it is a bad idea, or at least a major protocol design change. Christian> 3) that there is a desire to handle the "conference" concept at Christian> the RTP level, i.e. pass parameters which are somehow Christian> common to multiple streams. I think maybe it was something I said (about duplicate SDESs) that might have triggerred this. I wasn't really implying it should be at the RTP level, necessarily. I think some out of band mechanism to recognize that conferences are related (sd might say so, for example) would be enough. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Jul 21 21:03:33 1993 Received: from itd.nrl.navy.mil by osi-west.es.net with SMTP (PP) id <03617-0@osi-west.es.net>; Wed, 21 Jul 1993 17:56:44 +0000 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10269; Wed, 21 Jul 93 20:56:41 EDT Date: Wed, 21 Jul 93 20:56:41 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307220056.AA10269@itd.nrl.navy.mil> To: rem-conf@es.net Subject: FlowIDs, etc. I notice all of the discussion has been assuming the case where one is using multicast addressing. Some few of us also plan to use something like RTP for unicast applications and some few of us can see a use for IP-level flows (and flowIDs) even when we might not be using either multicast or something like RTP. I'd feel more comfortable if we didn't assume multicast in these dicussions. Regards, Ran atkinson@itd.nrl.navy.mil From rem-conf-request@es.net Thu Jul 22 03:17:03 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <05247-0@osi-west.es.net>; Wed, 21 Jul 1993 23:52:35 +0000 Received: from mmc.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Wed, 21 Jul 1993 23:52:31 -0700 Posted-Date: Wed 21 Jul 93 23:52:24-PDT Received: by mmc.isi.edu (4.1/4.0.3-4) id ; Wed, 21 Jul 93 23:52:26 PDT Date: Wed 21 Jul 93 23:52:24-PDT From: Stephen Casner Subject: Re: Flow IDs and SSRC To: rem-conf@es.net Message-Id: <743323944.0.CASNER@MMC.ISI.EDU> In-Reply-To: Mail-System-Version: I think part of the confusion in this discussion comes from nomenclature. I am uncomfortable with the term "conference" as Henning has defined it to refer to a combination of (multicast address, destination port, FlowID). For one thing, it is too application specific, and for another, I think it suggests a way of thinking about flows that is too restrictive. I'd prefer to call them "flows". If you think that implies something that comes from a single source, then how about "channels", in the sense that sites with two cameras can each send the signal from one camera on the first channel, and the signal from the second channel on the second channel. Receivers will listen to the first channel to receive all the first-camera images, and to the second channel to receive all the second-camera images. The receivers might display the multiple images from one site in one dimension, versus the multiple sites in another dimension, if that grouping makes sense for the application. These channels could be distinguished by separate multicast addresses, separate destination ports, or separate FlowIDs. Having the FlowID expands the addressing space, but not by much, hence the claim that it is useless. But it would be useful for the case when: - you want the same group addressing (and don't want to incur the extra cost of using multiple multicast addresses for the same group -- we should expect that there is some cost), or when you are using unicast addressing; and - it is convenient to use a single port (and single socket) to receive all the channels. Based on this explanation, I disagree that: Ron> This really inverts the meaning of flow id, back to what Henning says Ron> SSRC is for. As a few people have said in various ways, the SSRC is simply a way to expand the source port number space or to conserve the use of source ports (or sockets). The use of separate sources, whether distinguished by source port or SSRC, is orthogonal to the use of separate channels (destinations), whether distinguished by address, port, or FlowID. Ron> I think we have to be careful here not to make RTP depend on RSVP. It's Ron> good that we think about how to make what RTP does be RSVP-friendly, Ron> but RTP should be able to run efficiently even when RSVP isn't present. I agree completely. I am only arguing that we should not require or assume the use of separate multicast addresses because there may be cases when it would be better to use a single multicast address with RSVP. Ron> So, I guess I would recommend leaving the SSRC as-is both in meaning Ron> and implementation, but seriously considering whether we shouldn't just Ron> eliminate the flow-id field entirely... I agree that SSRC remains the same (though the rule that end systems couldn't insert them may be removed). I am reluctant to eliminate the FlowID field, however. I believe it does have some use, and we are not trying to shoe-horn something else into its place. As Christian said, some stability is desirable! Christian> 3) that there is a desire to handle the "conference" concept at Christian> the RTP level, i.e. pass parameters which are somehow Christian> common to multiple streams. The only parameter which has been considered to apply to multiple streams is the SDES parameter, i.e., why pass the same participant name once for audio and once for video. The sequence number space, etc. as you have listed, are all distinct for each stream (flow). More tomorrow on ways that we might want to group flows/channels. -- Steve ------- From rem-conf-request@es.net Thu Jul 22 04:00:06 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <05016-0@osi-west.es.net>; Wed, 21 Jul 1993 22:46:00 +0000 Received: from mmc.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Wed, 21 Jul 1993 22:45:56 -0700 Posted-Date: Wed 21 Jul 93 22:45:51-PDT Received: by mmc.isi.edu (4.1/4.0.3-4) id ; Wed, 21 Jul 93 22:45:52 PDT Date: Wed 21 Jul 93 22:45:51-PDT From: Stephen Casner Subject: Re: FlowIDs, etc. To: atkinson@itd.nrl.navy.mil, rem-conf@es.net Message-Id: <743319951.0.CASNER@MMC.ISI.EDU> In-Reply-To: <9307220056.AA10269@itd.nrl.navy.mil> Mail-System-Version: Ran, > I'd feel more comfortable if we didn't assume multicast in these dicussions. Thanks for pointing that out. With unicast, one cannot use different destination addresses to distinguish flows. However, one can use different destination port numbers, so I don't think the need for FlowIDs is any stronger (or weaker). If we tried to assign a fixed port number to identify which profile was selected, then we'd be in trouble. I entertained this idea at one time, but I don't think it is workable. If I'm missing something, please point it out. -- Steve ------- From rem-conf-request@es.net Thu Jul 22 07:36:44 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <06516-0@osi-west.es.net>; Thu, 22 Jul 1993 04:24:31 +0000 Received: from reeves.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 22 Jul 1993 12:24:15 +0100 To: Stephen Casner cc: rem-conf@es.net Subject: Re: Flow IDs and SSRC In-reply-to: Your message of "Wed, 21 Jul 93 23:52:24 PDT." <743323944.0.CASNER@MMC.ISI.EDU> Date: Thu, 22 Jul 93 12:24:15 +0100 From: Zheng Wang >I think part of the confusion in this discussion comes from >nomenclature. I am uncomfortable with the term "conference" as >Henning has defined it to refer to a combination of (multicast >address, destination port, FlowID). For one thing, it is too >application specific, and for another, I think it suggests a way of >thinking about flows that is too restrictive. I think we should also avoid the term "Flow" or "Flow ID" here as they have been frequently used in resource reservation/management. It may be easier to look at the problem from the multiplexing /de-multilpexing perspective. The question is really whether we need RTP-level demultiplexing. RTP ???? (call it session ID??) UDP port number (can be used for demultiplexing for m-cast and unicast) IP address (m-cast address can be used for demultiplexing) Cheers Zheng From rem-conf-request@es.net Thu Jul 22 09:02:27 1993 Received: from yonge.csri.toronto.edu by osi-west.es.net with SMTP (PP) id <06944-0@osi-west.es.net>; Thu, 22 Jul 1993 05:49:46 +0000 Received: from alias by yonge.csri.toronto.edu with UUCP id <14543>; Thu, 22 Jul 1993 08:49:33 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA25454 (5.65a/IDA-1.4.2 for CASNER@ISI.EDU); Thu, 22 Jul 93 08:42:25 -0400 Received: by dino.alias.com id AA16499 (5.65a/IDA-1.4.2 for rem-conf@es.net); Thu, 22 Jul 93 08:42:23 -0400 Date: Thu, 22 Jul 1993 08:42:23 -0400 From: mandrews@alias.com (Mark Andrews) Message-Id: <9307221242.AA16499@dino.alias.com> To: Stephen Casner , rem-conf@es.net Subject: Re: Cash for sockets >It has been pointed out to me that it may not be possible to bind() >a socket more than once under most/all BSD-derived systems. In the default state, yes. But if you setsockopt(sockno, SO_REUSEADDR, ...), it allows an application to use the same , for multiple connections. The only hitch with this is that the complete 4-tuple denoting a a connection: , , must be unique for each connection or the connect will fail indicating address already in use. >I suppose that to maintain a limit on the number of sockets used, one >could choose the LRU socket and close it, then create a new one and >bind it. This is more overhead, of course. The bind is required >because you must maintain the same port number for a given logical >source across the multiple times that you may set up a socket for it. > >If multiple processes on one host are doing this, and if they might be >participating in the same session (multicast address, destination >port, and FlowID in the case of RTP), then it is possible they will >simultaneously use the same source port number because we are >defeating the unique allocation that the kernel provides. Mark From rem-conf-request@es.net Thu Jul 22 09:19:09 1993 Received: from jazz.concert.net by osi-west.es.net with SMTP (PP) id <07066-0@osi-west.es.net>; Thu, 22 Jul 1993 06:04:02 +0000 Received: by jazz.concert.net (5.59/tas-concert/8-12-92) id AA27195; Thu, 22 Jul 93 09:03:45 -0400 From: Fengmin Gong Message-Id: <9307221303.AA27195@jazz.concert.net> Subject: Re: Flow IDs and SSRC To: Z.Wang@cs.ucl.ac.uk (Zheng Wang) Date: Thu, 22 Jul 1993 09:03:44 -0400 (EDT) Cc: CASNER@ISI.EDU, rem-conf@es.net In-Reply-To: <"6531 Thu Jul 22 04:27:23 1993"@es.net> from "Zheng Wang" at Jul 22, 93 06:24:15 am X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1502 Zheng Wang wrote in a previous message: > >I think we should also avoid the term "Flow" or "Flow ID" here as they >have been frequently used in resource reservation/management. > I think "flow" is the proper term to use, partly due to the fact that it is used in resource reservation/management. Because then we can map nicely to a per-flow reservation protocol when requesting service for RTP. If remember correctly, Bob Braden's message yesterday was suggesting somethings along this line. >It may be easier to look at the problem from the multiplexing /de-multilpexing >perspective. The question is really whether we need RTP-level demultiplexing. > > Yes, it is a multiplexing issue. I think we need to look at what it will costs to leave Flow-ID there or what to gain to remove it. No doubt that Flow-ID allows flexibility when dealing with transport of multimedia streams. Steve Casner and Cristian Huitima have cited several examples. I think it may also be useful when you have a white board (maybe other shared windows) in addition to the audio/video streams, it may be advantageous to mux them onto an existing distribution tree, for example. >RTP ???? (call it session ID??) > As I said Flow-ID is preferred, not to mention the potential conflict with the session control protocol from the mmusic WG. >UDP port number (can be used for demultiplexing for m-cast and unicast) > >IP address (m-cast address can be used for demultiplexing) > > >Cheers >Zheng > Thanks, Fengmin From rem-conf-request@es.net Thu Jul 22 09:41:49 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <07212-0@osi-west.es.net>; Thu, 22 Jul 1993 06:27:18 +0000 Received: from reeves.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 22 Jul 1993 14:27:04 +0100 To: Fengmin Gong cc: rem-conf@es.net Subject: Re: Flow IDs and SSRC In-reply-to: Your message of "Thu, 22 Jul 93 09:03:44 EDT." <9307221303.AA27195@jazz.concert.net> Date: Thu, 22 Jul 93 14:27:04 +0100 From: Zheng Wang >>I think we should also avoid the term "Flow" or "Flow ID" here as they >>have been frequently used in resource reservation/management. >> >I think "flow" is the proper term to use, partly due to the fact that it >is used in resource reservation/management. Because then we can map >nicely to a per-flow reservation protocol when requesting service for >RTP. If remember correctly, Bob Braden's message yesterday was suggesting >somethings along this line. Well, if the two flow-ids are not exactly the same, we should use different terms. Otherwise, we may have to say "IP flow id" or "RTP flow id" >>RTP ???? (call it session ID??) >> >As I said Flow-ID is preferred, not to mention the potential conflict with the >session control protocol from the mmusic WG. If there is demultiplexing at session layer, we should also take it into consideration. Cheers Zheng From rem-conf-request@es.net Thu Jul 22 09:50:49 1993 Received: from jazz.concert.net by osi-west.es.net with SMTP (PP) id <07270-0@osi-west.es.net>; Thu, 22 Jul 1993 06:34:10 +0000 Received: by jazz.concert.net (5.59/tas-concert/8-12-92) id AA28029; Thu, 22 Jul 93 09:34:01 -0400 From: Fengmin Gong Message-Id: <9307221334.AA28029@jazz.concert.net> Subject: Re: Flow IDs and SSRC To: Z.Wang@cs.ucl.ac.uk (Zheng Wang) Date: Thu, 22 Jul 1993 09:34:00 -0400 (EDT) Cc: rem-conf@es.net In-Reply-To: <9307221327.AA27901@jazz.concert.net> from "Zheng Wang" at Jul 22, 93 02:27:04 pm X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1049 Zheng Wang wrote in a previous message: > > > >>I think we should also avoid the term "Flow" or "Flow ID" here as they > >>have been frequently used in resource reservation/management. > >> > >I think "flow" is the proper term to use, partly due to the fact that it > >is used in resource reservation/management. Because then we can map > >nicely to a per-flow reservation protocol when requesting service for > >RTP. If remember correctly, Bob Braden's message yesterday was suggesting > >somethings along this line. > >Well, if the two flow-ids are not exactly the same, we should use >different terms. Otherwise, we may have to say "IP flow id" or "RTP flow id" > > >>RTP ???? (call it session ID??) > >> > >As I said Flow-ID is preferred, not to mention the potential conflict with the > >session control protocol from the mmusic WG. > >If there is demultiplexing at session layer, we should also >take it into consideration. > >Cheers >Zheng > Agreed. I will raise this concern at later mmusic discussion if no one does. Thanks, Fengmin From rem-conf-request@es.net Thu Jul 22 11:17:47 1993 Received: from gatekeeper.es.dupont.com by osi-west.es.net with SMTP (PP) id <08088-0@osi-west.es.net>; Thu, 22 Jul 1993 07:58:56 +0000 Received: by gatekeeper.es.dupont.com (5.65/ULTRIX-mjr-062991); id AA12740; Thu, 22 Jul 93 10:58:53 -0400 Received: by esds01.es.dupont.com (5.65/ULTRIX-mjr-063191); id AA02240; Thu, 22 Jul 93 10:55:14 -0400 Date: Thu, 22 Jul 93 10:55:13 -0400 Message-Id: <9307221455.AA02240@esds01.es.dupont.com> From: swam00@uke.dnet.dupont.com (Mike Swaby) To: "rem-conf@es.net"@ESDS01.dnet.dupont.com Cc: SWAM00@esds01.es.dupont.com Subject: Unsubscribe request Please unsubscribe me from the rem-conf list !!! Apologies for sending this to the entire list but the rem-conf-request mailbox doesn't appear to work. Mike. Mike Swaby Conoco (UK) Ltd. From rem-conf-request@es.net Thu Jul 22 11:53:28 1993 Received: from mitsou.inria.fr by osi-west.es.net with SMTP (PP) id <08539-0@osi-west.es.net>; Thu, 22 Jul 1993 08:36:45 +0000 Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA09760; Thu, 22 Jul 1993 17:36:53 +0200 Message-Id: <199307221536.AA09760@mitsou.inria.fr> To: Zheng Wang Cc: Fengmin Gong , rem-conf@es.net Subject: Re: Flow IDs and SSRC In-Reply-To: Your message of "Thu, 22 Jul 93 14:27:04 BST." <199307221527.AA13331@sophia.inria.fr> Date: Thu, 22 Jul 93 17:36:53 +0200 From: Christian Huitema => >As I said Flow-ID is preferred, not to mention the potential conflict with the => >session control protocol from the mmusic WG. => => If there is demultiplexing at session layer, we should also => take it into consideration. => => Cheers => Zheng Humm. Just look at the effects of vocabulary. MMUSIC rightly uses the name "session" as in "session control", "teleconference session", etc. But then, "session" is also used to designate one layer in that ISO tower. So, bingo, here we are with a layer of "session" on top of RTP! Please don't! The OSI model is dead, and one of the reason it is dead is precisely because this stacking of layers business, while useful for some form of pastries, is wholly inadequate for high speed transmissions. I sure hope we do not envisage a "layer of demultiplexing" on top of RTP. What we should envisage is the contrary -- an association of several RTP controlled flows (streams?) so they get coordinated in a single "session" (conference?). Note that this association could well have transport related effects, e.g. for bandwidth management. Christian Huitema From rem-conf-request@es.net Thu Jul 22 12:00:14 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <08721-0@osi-west.es.net>; Thu, 22 Jul 1993 08:44:49 +0000 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 22 Jul 1993 16:44:30 +0100 To: Christian Huitema cc: rem-conf@es.net Subject: Re: Flow IDs and SSRC In-reply-to: Your message of "Thu, 22 Jul 93 17:36:53 +0100." <199307221536.AA09760@mitsou.inria.fr> Date: Thu, 22 Jul 93 16:44:28 +0100 From: Zheng Wang >I sure hope we do not envisage a "layer of demultiplexing" on top of RTP. What We should look at de/multiplexing at all levels (i.e. layers :-) and decide how many we really need. Cheers Zheng From rem-conf-request@es.net Thu Jul 22 12:04:19 1993 Received: from zephyr.isi.edu by osi-west.es.net with SMTP (PP) id <08747-0@osi-west.es.net>; Thu, 22 Jul 1993 08:46:49 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Thu, 22 Jul 1993 08:46:46 -0700 Date: Thu, 22 Jul 1993 08:46:46 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199307221546.AA26673@zephyr.isi.edu> To: rem-conf@es.net, CASNER@ISI.EDU Subject: Re: Flow IDs and SSRC *> From rem-conf-request@es.net Thu Jul 22 00:42:53 1993 *> Date: Wed 21 Jul 93 23:52:24-PDT *> From: Stephen Casner *> Subject: Re: Flow IDs and SSRC *> To: rem-conf@es.net *> In-Reply-To: *> Mail-System-Version: *> Content-Length: 3575 *> X-Lines: 76 *> *> I think part of the confusion in this discussion comes from *> nomenclature. I am uncomfortable with the term "conference" as *> Henning has defined it to refer to a combination of (multicast *> address, destination port, FlowID). For one thing, it is too *> application specific, and for another, I think it suggests a way of *> thinking about flows that is too restrictive. *> This would correspond to what we call a "session" in RSVP, I believe (except we don't have a FlowID). Bob From rem-conf-request@es.net Thu Jul 22 12:12:02 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <08946-0@osi-west.es.net>; Thu, 22 Jul 1993 08:57:14 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11532>; Thu, 22 Jul 1993 08:56:57 PDT Received: by ecco.parc.xerox.com id <16136>; Thu, 22 Jul 1993 08:56:47 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Thu, 22 Jul 1993 08:56:41 -0700 (PDT) Message-ID: Date: Thu, 22 Jul 1993 08:56:41 PDT Sender: Ron Frederick From: Ron Frederick To: Stephen Casner Subject: Re: did you see this? CC: rem-conf@es.net In-Reply-To: <743331136.0.CASNER@XFR.ISI.EDU> References: <743331136.0.CASNER@XFR.ISI.EDU> > I think the way the MBone Audio channel is used now to contact people > is silly. It makes no sense at all to disturb many people just to > find out if one person is available. What you want it the functional > equivalent of a telephone ring, although it could be implemented in a > whole variety of nicer ways. That's exactly what Eve's MMCC > program is designed to do. If you really want to have a private conversation with someone, then I agree that a more telephone-like rendevous is appropriate. I think, however, there are advantages to having many of the discussions we have in a public way. Others often chime in after the discussion begins, or at least pick up some useful information along the way. So, I was simply trying to avoid those cases where the initial rendevous fails and no real discussion ever happens. > There are precedents for Andy's suggestion of a mic-on indication. In > some commercial videoconferencing systems, the words "MIC ON" are > superimposed on the video when the mic is on. If we have mics & silence detection algorithms that made this practical, I might push harder for it. The fact is that open-mike conferences really just don't work well with our current equipment, though. Under those conditions, the mic being muted necessarily means something different, and you need a different indicator of when people want privacy. > If "mute" is application dependent, then it should probably be > indicated by an application-defined option. On the other hand, if it > is sufficiently application independent, then it might make sense to > add it, either as a new option, or as an SDES class. I haven't > thought about SDES indicating state changes, though. Yeah - this is tricky. Certainly the notion of some form of mutedness is pretty general, but I'm not sure that it really will have all the same implications across different applications. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Jul 22 14:04:59 1993 Received: from Sun.COM by osi-west.es.net with SMTP (PP) id <10954-0@osi-west.es.net>; Thu, 22 Jul 1993 10:54:25 +0000 Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA24300; Thu, 22 Jul 93 10:54:21 PDT Received: from video.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA09023; Thu, 22 Jul 93 10:54:23 PDT Received: by video.Eng.Sun.COM (4.1/SMI-4.1) id AA04384; Thu, 22 Jul 93 10:54:14 PDT Date: Thu, 22 Jul 93 10:54:14 PDT From: David.Gedye@Eng.Sun.COM (Dave Gedye) Message-Id: <9307221754.AA04384@video.Eng.Sun.COM> To: rem-conf@es.net Subject: Conferencing over PC networks? Does anybody have any experience with sending live audio and video over PC networks such as NetWare, Windows NT, Lan Manager, etc? I know you can buy implementations of IP that work on or beside PC networking, but I'm really interested to know if it's at all possible to do any of this stuff on the networks that PCs are already running or will be running in a few years. Do they support any unreliable protocols? Do any of them have any notion of multicast routing? Thanks in advance for any answers, or pointers to answers. Dave Gedye SunSoft. Inc. From rem-conf-request@es.net Thu Jul 22 14:30:07 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <11372-0@osi-west.es.net>; Thu, 22 Jul 1993 11:17:22 +0000 Received: from elm.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Thu, 22 Jul 1993 11:17:12 -0700 Date: Thu, 22 Jul 1993 11:17:03 -0700 From: schooler@ISI.EDU Posted-Date: Thu, 22 Jul 1993 11:17:03 -0700 Message-Id: <199307221817.AA04041@elm.isi.edu> Received: by elm.isi.edu (5.65c/4.0.3-4) id ; Thu, 22 Jul 1993 11:17:03 -0700 To: Z.Wang@cs.ucl.ac.uk, Christian.Huitema@sophia.inria.fr Subject: Re: Flow IDs and SSRC Cc: gong@concert.net, rem-conf@es.net, abel@thumper.bellcore.com >Humm. Just look at the effects of vocabulary. MMUSIC rightly uses the name >"session" as in "session control", "teleconference session", etc. But then, >"session" is also used to designate one layer in that ISO tower. So, bingo, >here we are with a layer of "session" on top of RTP! >... >I sure hope we do not envisage a "layer of demultiplexing" on top of RTP. What >we should envisage is the contrary -- an association of several RTP controlled >flows (streams?) so they get coordinated in a single "session" (conference?). >Note that this association could well have transport related effects, e.g. for >bandwidth management. I see the layer above RTP as providing more of a mux'ing than demux'ing abstraction. In the MMusic WG, we recently proposed that a "conference" consists of three components: a control session, related media associations, and conference policies. By "session" we mean an association of members for control; for instance, to control a conference with multiple conferees. A "media association" is the encapsulation of the transport (point-to-point or multipoint) in a single medium. These media associations are meant to be RTP flows or streams (We would happily replace the term media association if someone could suggest something better). Finally, "conference policies" are the rules regarding the style of interaction for a conference. Eve From rem-conf-request@es.net Thu Jul 22 16:35:36 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <13018-0@osi-west.es.net>; Thu, 22 Jul 1993 13:25:29 +0000 Received: from btn.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Thu, 22 Jul 1993 13:25:21 -0700 Date: Thu, 22 Jul 93 13:25:18 -0700 From: touch@ISI.EDU Posted-Date: Thu, 22 Jul 93 13:25:18 -0700 Message-Id: <9307222025.AA05150@btn.isi.edu> Received: by btn.isi.edu (NX5.67c/4.0.3-4) id ; Thu, 22 Jul 93 13:25:18 -0700 Original-Received: by NeXT.Mailer (1.87.1) PP-warning: Illegal Received field on preceding line Original-Received: by NeXT Mailer (1.87.1) PP-warning: Illegal Received field on preceding line To: schooler@ISI.EDU Subject: MMUSIC Flow IDs and SSRC Cc: rem-conf@es.net Interesting - MMUSIC proposes control, media assoc, and policy. I'd summarize as control data meta-control Confining the media associations to media-specific "webs" is also a TM artifact that I'd prefer die a nasty death, though. Joe From rem-conf-request@es.net Thu Jul 22 16:52:39 1993 Received: from colossus.apple.com by osi-west.es.net with SMTP (PP) id <13282-0@osi-west.es.net>; Thu, 22 Jul 1993 13:43:42 +0000 Received: from talisman.kaleida.com by colossus.apple.com with SMTP (5.65/22-Jun-1993-eef) id AA01629; Thu, 22 Jul 93 13:23:57 -0700 for Received: from [130.43.11.117] (arodriguez.kaleida.com) by talisman.kaleida.com (4.1/SMI-4.1) id AA09088; Thu, 22 Jul 93 13:24:04 PDT Date: Thu, 22 Jul 93 13:24:04 PDT Message-Id: <9307222024.AA09088@talisman.kaleida.com> To: rem-conf@es.net From: aar@kaleida.com (Arturo A. Rodriguez) X-Sender: aar@talisman.kaleida.com Please remove me from this list. All attempts to unsubscribe to rem-conf-request@es.net have been unsuccessful. From rem-conf-request@es.net Thu Jul 22 19:15:39 1993 Received: from MANNIX.BBN.COM by osi-west.es.net with SMTP (PP) id <15451-0@osi-west.es.net>; Thu, 22 Jul 1993 16:06:41 +0000 To: rem-conf@es.net Subject: Flow ID Date: Thu, 22 Jul 93 19:04:40 -0400 From: Julio Escobar Hi Henning, Steve, Christian, I have been out of touch for a while, partly due to an involuntary absence from the US that lasted for 1.5 months, with the subsequent sequel of back log. This preface is to apologize if my comments are out of place or miss the mark, as I have not been keeping up. (Also, I am going through my backlog for the week and I see futher messages on this topic ahead.) I just read some of the flow ID messages. For synchronization, it is often important to identify individual sources within a host, even as they may share the same port. At the moment, it is common that a host uses a port for single source audio and another for single source video. However, I can imagine multiple audio sources (or video sources) served by the same real-time transport program and multiplexing them through the same port. (Simulation is an example, as Steve mentioned.) My guess is that each such source could have its own flow ID. JULIO From rem-conf-request@es.net Fri Jul 23 03:00:33 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <19094-0@osi-west.es.net>; Thu, 22 Jul 1993 23:41:18 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Thu, 22 Jul 1993 23:41:14 -0700 Posted-Date: Thu 22 Jul 93 23:40:32-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 22 Jul 93 23:40:38 PDT Date: Thu 22 Jul 93 23:40:32-PDT From: Stephen Casner Subject: Summary on FlowID/SSRC To: rem-conf@es.net Message-Id: <743409632.0.CASNER@XFR.ISI.EDU> Mail-System-Version: I had a telephone conversation with Henning and Ron today to try clarify some of these issues we've been discussing, but in a more efficient manner than jumbograms. This message summarizes the conclusions we reached, and I invite others to comment. Defininitions Henning and Ron accepted my suggestion to use the term "channel" to identify the destination triple (multicast/unicast address, destination port, FlowID). We agreed to keep the separate term FlowID for the third item by itself. Many sources may send to a channel. The combination of all the sources that are sending to a channel, and the receivers that are receiving it, might be called a conference or a session, but we don't really need to name that collection in RTP. Grouping of channels to share SDES I had suggested that we might want to define the SDES to be shared for all the channels with the same destination address and port to which a source was sending. The idea was that an integrated application might want to send audio and video to separate channels from the same source address and port, and there would be no need to duplicate the SDES information on both channels. However, it may be just as desirable to group those audio and video channels when the multicast (destination) addresses are selected to be different so the routing tree can be pruned if some sites elect not to receive the video. The SDES information still need only be sent to the audio channel. Therefore, we agreed that there is no reason why we should define any grouping within RTP. Since there is no requirement that SDES be sent on any channel, all that's needed is an agreement at the application level on which channel(s) SDES should be sent. This is up to the higher-layer control protocol. If the sender and receiver have different views of the grouping, then the receiver will either get multiple SDES's to be stored in one place, or will get no SDES's on some channels. A consequence of this decision is inverse of my suggestion; that is, the SDES may be specific to the channel on which it is received unless there is some higher-level agreement to the contrary. However, as always, the SDES must be specific to a single source triple (address, port, SSRC). [Remember that SSRC is not mandatory; zero is used if no SSRC is present.] Audio and video in the same packet I got a clarification from Henning that when he talked about carrying audio and video in the same RTP packet, he really meant to say multiple RTP PDUs in the same lower-layer (e.g. UDP) packet. As Ron mentioned, this is not a new capability nor a major revision to the protocol. The spec says that the framing length field is prepended to each RTP PDU if the underlying layer provides only the abstraction of a continuous bit stream rather than messages, or if the profile being used declares that the framing length is always to be included. So far, we have only one profile defined, and it does not make that declaration. This provision identifies at least one case when the FlowID is needed. In order to be able to send multiple RTP PDUs to different channels within one UDP packet, it is necessary for the channels to be distinguished by the FlowID because the address and port are common for the whole UDP packet. It would be possible to include packets from multiple sources in the same UDP packet if they are distinguished using SSRC options, because again, the source address and port are in common for all the RTP PDUs in the UDP packet. Remember that FlowID belongs to the destination triple, while SSRC belongs to the source triple, and that the two addressing dimensions are orthogonal (they serve different purposes). I hope the level of confusion is dropping, and that the worms are back in their can! -- Steve ------- From rem-conf-request@es.net Fri Jul 23 03:31:51 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <19554-0@osi-west.es.net>; Fri, 23 Jul 1993 00:28:00 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 23 Jul 1993 08:27:33 +0100 To: David.Gedye@Eng.Sun.COM (Dave Gedye) cc: rem-conf@es.net Subject: Re: Conferencing over PC networks? In-reply-to: Your message of "Thu, 22 Jul 93 10:54:14 PDT." <9307221754.AA04384@video.Eng.Sun.COM> Date: Fri, 23 Jul 93 08:27:31 +0100 From: Jon Crowcroft >Does anybody have any experience with sending live audio and video over >PC networks such as NetWare, Windows NT, Lan Manager, etc? windows NT comes with TCP... >I know you can buy implementations of IP that work on or beside PC >networking, but I'm really interested to know if it's at all possible >to do any of this stuff on the networks that PCs are already running or >will be running in a few years. yes -good question ? novell? >Do they support any unreliable protocols? >Do any of them have any notion of multicast routing? indeed - also, when are sun and SGI (and any other u**x folks) going to ship mrouted and IP with encapsualtion multicast instead of LSR as we need this in the UK for service...(LSR Is banned...)? jon From rem-conf-request@es.net Fri Jul 23 04:33:40 1993 Received: from sun2.nsfnet-relay.ac.uk by osi-west.es.net with SMTP (PP) id <19753-0@osi-west.es.net>; Fri, 23 Jul 1993 01:21:45 +0000 Via: uk.ac.edinburgh.castle; Fri, 23 Jul 1993 09:21:25 +0100 Received: from scorpio.castle.ed.ac.uk by castle.ed.ac.uk id aa01946; 23 Jul 93 9:20 WET DST Date: Fri, 23 Jul 93 09:20:45 BST Message-Id: <3266.9307230820@scorpio.ucs.ed.ac.uk> From: Graeme Wood Subject: Re: did you see this? To: rem-conf@es.net In-Reply-To: Ron Frederick's message of Thu, 22 Jul 1993 08:56:41 PDT Reply-To: Graeme.Wood@edinburgh.ac.uk X-Department: Unix Systems Support, Computing Services X-Organisation: The University of Edinburgh X-Phone: +44 (0)31 650 5003 X-Fax: +44 (0)31 662 4712 > > I think the way the MBone Audio channel is used now to contact people > > is silly. It makes no sense at all to disturb many people just to > > find out if one person is available. What you want it the functional > > equivalent of a telephone ring, although it could be implemented in a > > whole variety of nicer ways. That's exactly what Eve's MMCC > > program is designed to do. If you really only want to talk to a single person then vat (and I think nevot too) already provides you with this functionality. You click the middle button on that person's name and another vat session is started up for you. However, I agree with Ron... > If you really want to have a private conversation with someone, then I > agree that a more telephone-like rendevous is appropriate. I think, > however, there are advantages to having many of the discussions we have > in a public way. Others often chime in after the discussion begins, or at > least pick up some useful information along the way. So, I was simply > trying to avoid those cases where the initial rendevous fails and no real > discussion ever happens. If you don't want to be disturbed then you can always not run vat or mute your speaker/headphones :-). [other stuff deleted] Graeme From rem-conf-request@es.net Fri Jul 23 04:55:53 1993 X400-Received: by mta osi-west.es.net in /PRMD=ESnet/ADMD= /C=US/; Relayed; Fri, 23 Jul 1993 01:35:14 +0000 Date: Fri, 23 Jul 1993 01:35:14 +0000 X400-Originator: rem-conf-request@es.net X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=ESnet/ADMD= /C=US/;osi-west.e.868:23.06.93.08.35.14] Priority: Non-Urgent DL-Expansion-History: rem-conf@es.net ; Fri, 23 Jul 1993 01:32:31 +0000; From: " (Arnold Bloemer)" Message-ID: <9307230831.AA05441@helios.tnt.uni-hannover.de> To: rem-conf@es.net Cc: bloemer@mgate.uni-hannover.d400.de Subject: Re: Unsubscribe request > Please unsubscribe me from the rem-conf list !!! > > Apologies for sending this to the entire list but the rem-conf-request > mailbox doesn't appear to work. These kind of postings appear since a couple of month regularly on the list. Can anybody please explain why rem-conf-request doesn't work and what is the right way to subscribe and unsubscribe? > From rem-conf-request@es.net Thu Jul 22 17:53:30 1993 > From: swam00@uke.dnet.dupont.com (Mike Swaby) > To: "rem-conf@es.net"@ESDS01.dnet.dupont.com > Cc: SWAM00@esds01.es.dupont.com > Subject: Unsubscribe request Why do I get all mails from rem-conf-request? That is at least a little bit confusing. Arnold ________________________________________________________________________________ Dipl.-Ing. Arnold Bloemer Universitaet Hannover Institut fuer Theoretische Nachrichtentechnik und Informationsverarbeitung bloemer@tnt.uni-hannover.de Appelstrasse 9A fax: +49 511 762-5333 D-30167 Hannover phone: +49 511 762-5320 Germany ________________________________________________________________________________ From rem-conf-request@es.net Fri Jul 23 05:25:51 1993 Received: from mitsou.inria.fr by osi-west.es.net with SMTP (PP) id <20094-0@osi-west.es.net>; Fri, 23 Jul 1993 02:21:57 +0000 Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA11571; Fri, 23 Jul 1993 11:22:55 +0200 Message-Id: <199307230922.AA11571@mitsou.inria.fr> To: Stephen Casner Cc: rem-conf@es.net Subject: Re: Summary on FlowID/SSRC In-Reply-To: Your message of "Thu, 22 Jul 93 23:40:32 PDT." <743409632.0.CASNER@XFR.ISI.EDU> Date: Fri, 23 Jul 93 11:22:55 +0200 From: Christian Huitema Steve, Your message is indeed bringing a lot of clarification, but I am not really satisfied by the: Remember that FlowID belongs to the destination triple, while SSRC belongs to the source triple, and that the two addressing dimensions are orthogonal (they serve different purposes). It would make things even clearer if we were speaking about dest-flow-id (your interpretation of flow-id) and source-flow-id (the current SSRC). Also, it would help if we could have a "usage" document that highlights different uses of "dest flow id" and "source flow id", as well as the handling of thie channel abstraction by mmusic. Note that there is some potential difference between audio and video here -- one loudspeaker per channel for audio, vs. one window per channel per source for video. That may well explain part of the difficulty in understanding. Christian Huitema From rem-conf-request@es.net Fri Jul 23 14:25:24 1993 Received: from mailgate.Cadence.COM by osi-west.es.net with SMTP (PP) id <24352-0@osi-west.es.net>; Fri, 23 Jul 1993 11:03:56 +0000 Received: from cadence.Cadence.COM by mailgate.Cadence.COM (5.65c/SMI-4.1) id AA02749; Fri, 23 Jul 1993 10:51:04 -0700 Date: Fri, 23 Jul 93 10:35:17 -0700 From: nadig@Cadence.COM (Deepak Nadig) Message-Id: <9307231735.AA05212@cadence.Cadence.COM> Received: by cadence.Cadence.COM (5.61/3.14) id AA05212; Fri, 23 Jul 93 10:35:17 -0700 To: rem-conf@es.net Subject: "information for SunOS 4.1.2" Hi, I was planning on installing conferencing software on my workstation. I was looking for some pointers on what software is available (and where) and what were the hardware requirements for all of them. Thank you in advance, Deepak From rem-conf-request@es.net Fri Jul 23 15:04:36 1993 Received: from zephyr.isi.edu by osi-west.es.net with SMTP (PP) id <25111-0@osi-west.es.net>; Fri, 23 Jul 1993 11:39:35 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Fri, 23 Jul 1993 11:39:31 -0700 Date: Fri, 23 Jul 1993 11:39:31 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199307231839.AA17083@zephyr.isi.edu> To: rem-conf@es.net, jescobar@BBN.COM Subject: Re: Flow ID *> *> I just read some of the flow ID messages. For synchronization, it is *> often important to identify individual sources within a host, even as *> they may share the same port. At the moment, it is common that a host *> uses a port for single source audio and another for single *> source video. However, I can imagine multiple audio sources (or video *> sources) served by the same real-time transport program and *> multiplexing them through the same port. (Simulation is an example, *> as Steve mentioned.) My guess is that each such source could have its *> own flow ID. *> *> JULIO *> *> Julio, Taking a reductionist viewpoint, I have to ask... why not always use a DIFFERENT port for distinguishable flows? Abstractly, that is what ports are for... Why add a new mechanism when the old one suffices [Postel Rule #2]? Bob Braden From rem-conf-request@es.net Fri Jul 23 16:32:57 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <26297-0@osi-west.es.net>; Fri, 23 Jul 1993 13:22:01 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Fri, 23 Jul 1993 13:21:35 -0700 Posted-Date: Fri 23 Jul 93 13:20:43-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 23 Jul 93 13:20:44 PDT Date: Fri 23 Jul 93 13:20:43-PDT From: Stephen Casner Subject: Re: Unsubscribe request To: bloemer@tnt.uni-hannover.d400.de Cc: rem-conf@es.net Message-Id: <743458843.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9307230831.AA05441@helios.tnt.uni-hannover.de> Mail-System-Version: > Can anybody please explain why rem-conf-request doesn't work and what > is the right way to subscribe and unsubscribe? I don't mean to step on the toes of the rem-conf list adminstrator, but I think I can safely reply that rem-conf-request is the right way to subscribe and unsubscribe, the only question is what you should expect as the response time. > > From rem-conf-request@es.net Thu Jul 22 17:53:30 1993 > > From: swam00@uke.dnet.dupont.com (Mike Swaby) > > To: "rem-conf@es.net"@ESDS01.dnet.dupont.com > > Cc: SWAM00@esds01.es.dupont.com > > Subject: Unsubscribe request > > Why do I get all mails from rem-conf-request? That is at least a > little bit confusing. All the messages are forced to appear as if they came from rem-conf-request so that if there are mail delivery failures, those delivery failure notices will go to the list administrator and not to the original sender of the message who does not want to be bothered and can't do anything about the delivery failure anyway. You'll see the same technique in use on the ietf mailing list. -- Steve ------- From rem-conf-request@es.net Fri Jul 23 17:10:38 1993 Received: from ucdavis.ucdavis.edu by osi-west.es.net with SMTP (PP) id <27021-0@osi-west.es.net>; Fri, 23 Jul 1993 13:56:23 +0000 Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA14754; Fri, 23 Jul 93 13:45:08 PDT From: rdhobby@ucdavis.edu (Russ Hobby) Date: Fri, 23 Jul 93 13:45:08 PDT Message-Id: <9307232045.AA14754@ucdavis.ucdavis.edu> To: rem-conf@es.net Subject: INET 93 Broadcast on MBONE? Hi all, Somehow I get roped into coordination of demos at INET 93, and of course one of the things that came up was demoing the video conferencing that has been going on over the Internet. Not to hard to set up that. However, the subject came up on broadcasting the main sessions at INET 93 over the MBONE. Now that I would need some help from those that have experience in doing the IETF broadcasts. Any of you in the SF Bay Area willing to help? INET 93 is Aug 17-20 the week before INTEROP. We are planning network setup the weekend and Monday before. We would need help with the setup and operation. Any takers? Thanks, Russ Russell Hobby Director Advanced Networked and Scientific Applications U. C. Davis IT/ANSA INTERNET: rdhobby@ucdavis.edu Davis Ca 95616 BITNET: RDHOBBY@UCDAVIS Phone: (916) 752-0236 UUCP: ...!ucbvax!ucdavis!rdhobby From rem-conf-request@es.net Mon Jul 26 05:46:18 1993 Received: from fwide.fujitsu.co.jp by osi-west.es.net with SMTP (PP) id <08974-0@osi-west.es.net>; Mon, 26 Jul 1993 02:16:29 +0000 Received: from fdm.fujitsu.co.jp by fwide.fujitsu.co.jp (4.1/2.7W-fujitsu/1.1) id AA07724; Mon, 26 Jul 93 18:16:06 JST From: eiki@hodaka.mfd.cs.fujitsu.co.jp Received: from [133.161.1.84] by fdm.fujitsu.co.jp (5.65/6.4J.6) id AA11099; Mon, 26 Jul 93 18:15:48 +0900 Received: from hodaka.mfd.cs.fujitsu.co.jp by mfdgw.mfd.cs.fujitsu.co.jp (5.67+1.6W[+alpha]/6.4J[+CSMX]) id AA05907; Mon, 26 Jul 93 18:15:44 JST Received: from eiki (eiki.ARPA) by hodaka.mfd.cs.fujitsu.co.jp (4.12/6.4J.5) id AA04158; Mon, 26 Jul 93 18:15:54 JST Date: Mon, 26 Jul 93 18:15:54 JST Return-Path: Message-Id: <9307260915.AA04158@hodaka.mfd.cs.fujitsu.co.jp> To: rem-conf@es.net Subject: Inquirery for participating in AVT-WG activity X-Mailer: Harada's PC/M [v1.4] How do you do ? I am a staff of Fujitsu Limited(Japanese Mainflame Vendor), and my working area is planning for multi-media products line. Therefore, I am very interested in lower-layer protocols commonly used by realtime applications (especially multimedia). I have read some documents on RTP released by you. I strongly hope to catch up with the ongoing discussion on RTP. This is why I made the following inquiries. 1. I would like to participate in your mailing-list. 2. I have some questions on RTP documents. May I ask you these questions by email ? Or any better way to get quick answer ? 3. Are there any news-groups discussing multimedia protocols, such as RTP? If so, please inform me -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Iwata Eiki ARCHITECTURE DEPT. NETWORK DIV. FUJITSU LIMITED email : eiki@hodaka.mfd.cs.fujitsu.co.jp From rem-conf-request@es.net Mon Jul 26 11:57:42 1993 Received: from LL.MIT.EDU by osi-west.es.net with SMTP (PP) id <11286-0@osi-west.es.net>; Mon, 26 Jul 1993 08:47:21 +0000 Received: by ll.mit.edu (4.1/LL-1.3) id AA23108; Mon, 26 Jul 93 11:42:30 EDT From: marquis@ll.mit.edu Return-Path: Message-Id: <9307261142.AA24080@LL.MIT.EDU> Date: Mon, 26 Jul 93 11:42:30 -0400 To: rem-conf@es.net X-Sender: dougm@nearlink.llan Subject: H.320 Does anyone know where I can get a copy of the CCITT H.320 spec? Online preferred, but I'll buy it if I have to. Thanks -- -*- Doug -*- marquis@ll.mit.edu From rem-conf-request@es.net Mon Jul 26 16:58:42 1993 Received: from viipuri.nersc.gov by osi-west.es.net with SMTP (PP) id <14161-0@osi-west.es.net>; Mon, 26 Jul 1993 13:51:06 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA24476; Mon, 26 Jul 93 13:51:04 PDT Date: Mon, 26 Jul 93 13:51:04 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9307262051.AA24476@viipuri.nersc.gov> To: mbone@isi.edu, pirey%sunoco@relay.nswc.navy.mil Subject: Re: Video Cameras Cc: rem-conf@es.net > From pirey%sunoco@relay.nswc.navy.mil Mon Jul 26 13:11:29 1993 > Date: Mon, 26 Jul 93 15:06:11 EST > From: pirey%sunoco@relay.nswc.navy.mil (Phil Irey 703.663.1582) > To: mbone@ISI.EDU > Subject: Video Cameras > Content-Length: 260 > > Does anyone know the name and phone number of the company > which manufactures a CCD camera called a "Color CCD Telecamera - > Model #NCK9103C"? > > Would anyone have any other recommendations for "inexpensive" > video cameras for teleconferencing? > > thanks, > > phil irey > Actually, there is a "better"but not as "inexpensive" model...the NCK9127C/CM from Howard Enterprises (see below) as well as the 2X priced FlexCam from VideoLabs (612 897 1995): ------- >From ari Fri Jun 11 09:10:58 1993 To: rem-conf@es.net Subject: Color CCD camera (NCK9127CM) Cc: dvtf@es.net Content-Length: 2022 As promised, here's the spec sheet for the TeleCamera NCK 9127CM referred to in my previous message: Model NCK 9127CM 1/3" CCD (270k pixels) Solid State Color Camera w/ 6.1mm lens and integrated omni-directional microphone List price $287.00 each + $4.50 each for power adaptor (PN D9300-110)" HOWARD ENTERPRISES INC 3039 Marigold Place Thousand Oaks, CA 91360-6318 805-492-4842 805-492-9973 FAX Specifications Scanning System: NTSC standard 525 lines, 30 frames/second Image Device: Frame transfer method CCD 532(H) x 500(V) pixels; effective picture elements: 510(H) x 492(V) Sync System: Internal sync only Resolution: Horizontal: 330 TV lines Iris System: Electronic Auto Iris Video Output Level: 1.0vp-p (75 ohms) negative. Composite Video 714mvpp + or - 10% Sync 286mvpp + or - 10% Video S/N ratio: 45dB (Measured by VN-30A1 Noise Meter) Minimum Illumination: 10 lux (Measured by T-I Luminance Meter) Gamma Correction: 0.45 fixed Shedding: Less than 200mv Angle view: 33degrees Vertical; 47degrees Horizontal Lens: Fixed glass lens at f2.0 Focal Length: 6.1mm +/- 0.25mm Focal Distance: 600mm Video Output: Composite Video Rear Connector: Video: RCA standard pin jack AC Adaptor Jack: Diameter=6mm; Inside pin=2mm Camera Mount: 1/4" - 4.5 (Bottom) Environmental: Temperature: Operating: 0 to 45 degreesC Storage: -20 to 80 degreesC Power Requirement: 12VDC +/- 1.2V; 165mA maximum Power Consumption: 5 watt maximum with AC adaptor Size: 68.5mm(W) x 43mm(H) x 122mm(D) Weight: 180grams Compliance: FCC Class B -------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ari Ollikainen ari@es.net National Energy Research Supercomputer Center ESnet (Energy Sciences Network) Lawrence Livermore National Laboratory 510-423-5962 FAX:510-423-8744 P.O. BOX 5509, MS L-561, Livermore, CA 94550 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From rem-conf-request@es.net Tue Jul 27 10:01:33 1993 Received: from nsipo.arc.nasa.gov by osi-west.es.net with SMTP (PP) id <19979-0@osi-west.es.net>; Tue, 27 Jul 1993 06:31:52 +0000 Original-Received: Tue, 27 Jul 93 06:31:48 PDT from lupine.nsi.nasa.gov by nsipo.arc.nasa.gov (4.1/1.5) PP-warning: Illegal Received field on preceding line Received: by lupine.nsi.nasa.gov (5.65/SunOS-4.1.3) id AA21905; Tue, 27 Jul 93 09:30:51 -0400 Date: Tue, 27 Jul 93 09:30:51 -0400 From: Mike Newell Message-Id: <9307271330.AA21905@lupine.nsi.nasa.gov> To: mbone@isi.edu, pirey%sunoco@relay.nswc.navy.mil, ari@es.net Subject: Re: Video Cameras Cc: rem-conf@es.net I tried to order a camera from Howard Enterprises; but the guy I talked to told me he'd only accept a corporate PO (no checks, no credit cards.) He didn't explain why. Since I wanted to order one to play with "on the side", I didn't want to deal with the hassles of going through procurement (ever do a federal government procurement???) Does anyone know of any other inexpensive cameras out there? Mike Newell NASA Advanced Network Applications ----- Begin Included Message ----- >From rem-conf-request@es.net Mon Jul 26 18:10:29 1993 > From pirey%sunoco@relay.nswc.navy.mil Mon Jul 26 13:11:29 1993 > > Does anyone know the name and phone number of the company > which manufactures a CCD camera called a "Color CCD Telecamera - > Model #NCK9103C"? > > Would anyone have any other recommendations for "inexpensive" > video cameras for teleconferencing? > > thanks, > > phil irey > Actually, there is a "better"but not as "inexpensive" model...the NCK9127C/CM from Howard Enterprises (see below) as well as the 2X priced FlexCam from VideoLabs (612 897 1995): ------- >From ari Fri Jun 11 09:10:58 1993 To: rem-conf@es.net Subject: Color CCD camera (NCK9127CM) Cc: dvtf@es.net Content-Length: 2022 As promised, here's the spec sheet for the TeleCamera NCK 9127CM referred to in my previous message: Model NCK 9127CM 1/3" CCD (270k pixels) Solid State Color Camera w/ 6.1mm lens and integrated omni-directional microphone List price $287.00 each + $4.50 each for power adaptor (PN D9300-110)" HOWARD ENTERPRISES INC 3039 Marigold Place Thousand Oaks, CA 91360-6318 805-492-4842 805-492-9973 FAX ----- End Included Message ----- From rem-conf-request@es.net Wed Jul 28 20:03:00 1993 Received: from usc.edu by osi-west.es.net with SMTP (PP) id <05995-0@osi-west.es.net>; Wed, 28 Jul 1993 16:49:22 +0000 Received: from caldera.usc.edu by usc.edu (4.1/SMI-3.0DEV3-USC+3.1) id AA17664; Wed, 28 Jul 93 16:49:20 PDT Received: from localhost.usc.edu by caldera.usc.edu (4.1/SMI-4.1+ucs-3.6) id AA25138; Wed, 28 Jul 93 16:49:18 PDT Message-Id: <9307282349.AA25138@caldera.usc.edu> To: rem-conf@es.net Subject: Wanted: info on UH IMM Date: Wed, 28 Jul 1993 16:49:17 -0700 From: "Danny J. Mitzel" I always see the UH GMS conferences, listed in the sd directory, to distribute jpg images. I was wondering if someone could give me any pointers to that work... 1. what do I need to pick up if I'd like to experiment with multicast image/file distribution at my local site? 2. I assume distributing compressed images requires reliable data transport; is UH doing research in reliable multicast transport? any pointers to their work or others on reliable transport over multicast is appreciated. thanks for your time! danny (mitzel@usc.edu) From rem-conf-request@es.net Thu Jul 29 14:12:50 1993 Received: from galaxy.net.Hawaii.Edu by osi-west.es.net with SMTP (PP) id <12179-0@osi-west.es.net>; Thu, 29 Jul 1993 10:44:40 +0000 Received: by galaxy.net.Hawaii.Edu id <119731>; Thu, 29 Jul 1993 07:41:41 -1000 From: Torben Nielsen To: mitzel@usc.edu, rem-conf@es.net Subject: Re: Wanted: info on UH IMM Content-Length: 1171 Message-Id: <93Jul29.074141hst.119731@galaxy.net.Hawaii.Edu> Date: Thu, 29 Jul 1993 07:41:34 -1000 Danny, >I always see the UH GMS conferences, listed in the sd directory, to >distribute jpg images. I was wondering if someone could give me >any pointers to that work... There's nothing published if that's what you mean..... We all seem to suffer from severe allergies to paper.... >1. what do I need to pick up if I'd like to experiment with multicast >image/file distribution at my local site? Look on ftp.Hawaii.Edu in ~ftp/paccom/imm*. That is where the necessary files are. >2. I assume distributing compressed images requires reliable data >transport; is UH doing research in reliable multicast transport? any >pointers to their work or others on reliable transport over multicast >is appreciated. Not necessarily true. For some applications, it is not critical that every image is complete. However, we are moving towards a system that will ensure reliable delivery of images so that we can use this for distribution of research data. However, I have some doubt in my mind as to whether or not regular multicasting is really the way to go. Winston Dang (wkd@Hawaii.Edu) put together all of the code; ask him if you have questions on it. Thanks, Torben From rem-conf-request@es.net Thu Jul 29 16:58:48 1993 Received: from desperado.cc.rochester.edu by osi-west.es.net with SMTP (PP) id <14056-0@osi-west.es.net>; Thu, 29 Jul 1993 13:47:47 +0000 Received: from cookiemonster.cc.rochester.edu. by desperado.cc.rochester.edu (4.1/1.16) id AA03950; Thu, 29 Jul 93 16:47:37 EDT From: Bill Owens Message-Id: <9307292047.AA03950@desperado.cc.rochester.edu> Subject: New Sun sbus video card To: rem-conf@es.net Date: Thu, 29 Jul 1993 16:47:27 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 499 Our local (completely useless) Sun sales rep promised me info three weeks ago, and never delivered. Does anybody have the two most important bits of knowledge, price and availability? I have to decide whether to buy VideoPix now or wait... Thanks very much, Bill. Bill Owens owens@cc.rochester.edu 727 Elmwood Avenue MIME and PEM accepted Rochester, NY 14620 716/275-9120 From rem-conf-request@es.net Fri Jul 30 11:33:03 1993 Received: from research.att.com by osi-west.es.net with SMTP (PP) id <20137-0@osi-west.es.net>; Fri, 30 Jul 1993 08:20:24 +0000 Received: by inet; Fri Jul 30 11:17 EDT 1993 Date: Fri, 30 Jul 93 11:17:10 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: Internet-Drafts@CNRI.Reston.VA.US Subject: New drafts for AVT WG Cc: rem-conf@es.net Dear Internet Drafts editor: I have placed new versions of the AVT internet drafts on gaia.cs.umass.edu:~ftp/pub/rtp Title : Media Encodings Author(s) : H. Schulzrinne Filename : ftp file name: encoding.txt Title : Sample Profile for the Use of RTP for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne Filename : ftp file name: profile.txt Title : RTP: a Real-Time Transport Protocol Author(s) : H. Schulzrinne and S. Casner Filename : ftp file name: rtp.txt Please update the IETF drafts accordingly. Thank you. --- Henning Schulzrinne (hgs@research.att.com) AT&T Bell Laboratories (MH 2A-244) 600 Mountain Ave; Murray Hill, NJ 07974 phone: +1 908 582-2262; fax: +1 908 582-5809 From rem-conf-request@es.net Fri Jul 30 11:49:38 1993 Received: from research.att.com by osi-west.es.net with SMTP (PP) id <20218-0@osi-west.es.net>; Fri, 30 Jul 1993 08:28:46 +0000 Received: by inet; Fri Jul 30 11:27 EDT 1993 Date: Fri, 30 Jul 93 11:27:06 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: rem-conf@es.net Subject: New AVT RTP drafts As indicated by my previous cc'ed message, I have submitted new drafts reflecting the recent discussions to the drafts editor. The profile and encoding drafts are basically unchanged, but needed 'refreshing' as they had expired. *** ALERT: NEXT-TO-LAST CALL within WG As usual, the new draft is meant as the basis for discussion. Unless there are major technical problems, I would like to issue a revised draft reflecting WG/rem-conf comments within two weeks (by August 13). If everything works out, we should be moving to RFC submission after one more round of editorial changes. Below is a summary of the changes (beyond some wordsmithing): Changes for July 30 RTP draft ------------------------------ (compared to the December 15 and May 26 drafts; changes affecting backward compatibility with current implementations are marked with ***) The definition of SSRC and FlowID have been clarified, as per recent e-mail discussion. *** The SDES option has been reorganized to contain a range of well-defined items. This should make it possible to use the SDES information for receiver processing. The QOS option makes use of the SDES information. The current use is not backward compatible with the old usage (called SDESC). I would prefer not to change the option number (that just encourages old versions to stay around). All dependencies on underlying network and transport protocols and their addressing have been removed. Addresses are only carried as globally unique identifiers; domains using different network and transport protocols can be connected through RTP-level translators, including reverse control information. *** The reverse channel mechanism has been revised, integrating it more closely with the rest of RTP. The RAD option and RNA/RTA options are gone. The SDST option allows cross-domain reverse control information. The reverse data flow has been reorganized. The RAD option is no longer needed, but since its number (65) was in the user-definable space, existing implementations using it should be o.k. We may want to rename it and define it officially as part of the H.261 spec. QOS is now part of the multicast option space and has a different option number. The 'reverse' packets now have the same fixed header as regular RTP packets. The interpretation of the fields is not specified at this point. Security options ENC, MIC, MICS, MICK and MICA have been added. FDESC was removed. Open Issues ----------- It has been suggested to change the title to Real-Time Protocol as we are usually placing RTP on top of transport protocols like UDP. Any strong preferences one way or the other? (straw poll, please) --- Henning Schulzrinne (hgs@research.att.com) AT&T Bell Laboratories (MH 2A-244) 600 Mountain Ave; Murray Hill, NJ 07974 phone: +1 908 582-2262; fax: +1 908 582-5809 From rem-conf-request@es.net Fri Jul 30 15:29:02 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <22636-0@osi-west.es.net>; Fri, 30 Jul 1993 12:15:51 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Fri, 30 Jul 1993 12:15:47 -0700 Posted-Date: Fri 30 Jul 93 12:15:09-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 30 Jul 93 12:15:10 PDT Date: Fri 30 Jul 93 12:15:09-PDT From: Stephen Casner Subject: Re: New AVT RTP drafts To: rem-conf@es.net Message-Id: <744059709.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199307301601.AA27738@venera.isi.edu> Mail-System-Version: To the AVT working group: Please note the "next-to-last call" alert in Henning's notice about the new RTP draft and comment. It is important that we move forward and get the RTP specification ready to be submitted as an RFC. (It was my intention to achieve this before the July IETF, hence no meeting this time, but we didn't make it -- through my own delays as much as anyone else's.) I think we have resolved the open issues identified in Columbus. On the other hand, I want to assure you that the changes and additions in this draft are definitely still open for discussion. I think the discussion of the FlowID and SSRC issues was very helpful. Please read the new draft and comment. -- Steve ------- From rem-conf-request@es.net Fri Jul 30 19:31:40 1993 Received: from ocfmail.ocf.llnl.gov by osi-west.es.net with SMTP (PP) id <24971-0@osi-west.es.net>; Fri, 30 Jul 1993 16:18:49 +0000 Received: from [128.115.13.62] (jed219.llnl.gov) by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA00653; Fri, 30 Jul 93 16:18:43 PDT Date: Fri, 30 Jul 93 16:18:42 PDT Message-Id: <9307302318.AA00653@ocfmail.ocf.llnl.gov> To: rem-conf@es.net From: jed@llnl.gov (James E. \(Jed\) Donnelley) X-Sender: jed@ocfmail.llnl.gov Subject: Video capture (for an InterOp mbone demo) Mbone tools for an InterOp demo: I'm helping put together a demonstration of Fibre Channel interoperability for InterOp. We have some other demos, but I have been playing with the mbone occasionally in recent months and thought that running some of the mbone tools (sd, vat, and nv for example) between Sun and SGI (and ...) workstations (over IP) over Fibre Channel as part of the demo would show well if I could pull it off in time. Video input to nv on a Sun Sparc? The slow link has been determining what kind of video input will hook up with nv. I have heard of a "Video Pix" (?) board for a Sun Sparc Station. Is this the definitive choice for Sparcs? Are there other possibilities? Is there anyone that has used this setup that can take a little time to discuss this use with me? Ditto SGI power series? We are getting an SGI power series machine for the demo. Does anyone have experience putting video input from a camera out through nv on this type of machine? If so with what video capture capability? Is there anyone with such experience that has a little time to discuss their experiences with me? People pointers? Any pointers would be appreciated, especially into Sun and SGI. We are dealing with marketing people mostly that know little of this technology. It would be helpful if we could get their marketing people connected to the appropriate technical people at their respective organizations. HP 700 series, IBM RS6000? I could ask the same questions about HP 700 series machines and IBM RS6000s (that we will have in the demo), but I am not familiar with running the mbone over them and would probably not be able to come up to speed in time. Still, input about the video capabilities of these machines would also be useful for future work. Convenient access to such information? It strikes me that it would be helpful to have a file maintained somewhere that lists configurations (machines, boards, cameras, etc.) that have been used successfully with the mbone teleconferencing tools. Is there anything that is currently filling this role? James E. (Jed) Donnelley - Staff Computer Scientist Advanced Telecommunications Program LAWRENCE LIVERMORE NATIONAL LABORATORY P.O. Box 808 L-60 Work Phone: +1 (510) 422-4309 Livermore, California Fax: +1 (510) 423-8534 94551-9900 Internet: jed@llnl.gov From rem-conf-request@es.net Fri Jul 30 22:22:33 1993 Received: from horse.ee.lbl.gov by osi-west.es.net with SMTP (PP) id <26728-0@osi-west.es.net>; Fri, 30 Jul 1993 19:19:16 +0000 Received: by horse.ee.lbl.gov for rem-conf@es.net (5.65/1.41) id AA12037; Fri, 30 Jul 93 18:42:11 -0700 From: mccanne@horse.ee.lbl.gov (Steven McCanne) Message-Id: <9307310142.AA12037@horse.ee.lbl.gov> To: mbone@isi.edu, rem-conf@es.net, bsdi-users@bsdi.com Subject: IP Multicast under BSD/386 Date: Fri, 30 Jul 93 18:42:10 PDT Patches for IP Multicast under BSD/386 1.0 are now available via anonymous ftp to ftp.ee.lbl.gov. The compressed tarchive, bsd386-ipmcast.tar.Z, contains a set of kernel source patches, some new kernel source files, mrouted sources, and patches for netstat (-M & -Ms). Currently, only the "we" and "el" ethernet drivers have been modified for multicast. This port is derived from the IP Multicast port to 4.4BSD done by Craig Leres (leres@ee.lbl.gov) at Lawrence Berkeley Laboratory. Brad Parker (brad@fcr.com) provided the changes needed for the "we" ethernet driver. The tarchive bsd386-mcastbin.tar.Z contains BSD/386 binaries for vat, sd, nv, mrouted, mrinfo, mtest, and netstat. The nv binary was compiled without frame grabbing support (e.g., you can only receive video). If you want to run vat, you'll need a SoundBlaster audio card and will have to install my SoundBlaster driver (bsd386-sb.tar.Z) in your kernel (vat will not work with the standard SoundBlaster driver). [The audio quality with the SoundBlaster is quite poor, and I do not recommend that anyone buy a SoundBlaster just to run vat. I've recently switched to the Pro-Audio Spectrum 16, which has been a dramatic improvement. Even running the PAS-16 in SoundBlaster emulation mode makes a world of difference. The PAS-16 works with a slightly modified version of the soundblaster driver; these changes will be made available soon.] The multicast code seems to be pretty stable, while the soundblaster driver and applications are functional but still under development. See the README's in each of the tarchive's for more information. Steve