From rem-conf-request@es.net Sun Aug 01 21:16:34 1993 Received: from rena.dit.co.jp by osi-west.es.net with SMTP (PP) id <03205-0@osi-west.es.net>; Sun, 1 Aug 1993 18:02:00 +0000 Received: from aner.dit.co.jp (root@aner.dit.co.jp [133.156.1.11]) by rena.dit.co.jp (8.3+2.0Wb/rena-3.03) with ESMTP id KAA26567; Mon, 2 Aug 1993 10:00:30 +0900 Received: from localhost (toku@localhost) by aner.dit.co.jp (8.3+2.0Wb/aner-3.0) id KAA12281; Mon, 2 Aug 1993 10:00:28 +0900 Message-Id: <199308020100.KAA12281@aner.dit.co.jp> To: mccanne@horse.ee.lbl.gov (Steven McCanne) Cc: mbone@ISI.EDU, rem-conf@es.net, bsdi-users@bsdi.com Subject: Re: IP Multicast under BSD/386 In-reply-to: Your message of "Fri, 30 Jul 1993 18:42:10 PDT." <9307310142.AA12037@horse.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain;charset="US-ASCII" Date: Mon, 02 Aug 1993 10:00:27 JST From: Yoshitaka Tokugawa > 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. Steven, You forget to apply my fix for netinet/igmp.c. Following patch will fix the igmp checksum calculation problem. *** ./netinet/igmp.c- Fri Jul 23 15:30:21 1993 --- ./netinet/igmp.c Mon Aug 2 09:38:14 1993 *************** *** 276,285 **** * Assume max_linkhdr + sizeof(struct ip) + IGMP_MINLEN * is smaller than mbuf size returned by MGETHDR. */ ! m->m_data += max_linkhdr; ! m->m_len = sizeof(struct ip) + IGMP_MINLEN; m->m_pkthdr.len = sizeof(struct ip) + IGMP_MINLEN; ip = mtod(m, struct ip *); ip->ip_tos = 0; ip->ip_len = sizeof(struct ip) + IGMP_MINLEN; --- 276,294 ---- * Assume max_linkhdr + sizeof(struct ip) + IGMP_MINLEN * is smaller than mbuf size returned by MGETHDR. */ ! m->m_data += max_linkhdr + sizeof(struct ip); ! m->m_len = IGMP_MINLEN; m->m_pkthdr.len = sizeof(struct ip) + IGMP_MINLEN; + igmp = mtod(m, struct igmp *); + igmp->igmp_type = IGMP_HOST_MEMBERSHIP_REPORT; + igmp->igmp_code = 0; + igmp->igmp_group = inm->inm_addr; + igmp->igmp_cksum = 0; + igmp->igmp_cksum = in_cksum(m, IGMP_MINLEN); + m->m_data -= sizeof(struct ip); + m->m_len += sizeof(struct ip); + ip = mtod(m, struct ip *); ip->ip_tos = 0; ip->ip_len = sizeof(struct ip) + IGMP_MINLEN; *************** *** 287,299 **** ip->ip_p = IPPROTO_IGMP; ip->ip_src.s_addr = INADDR_ANY; ip->ip_dst = inm->inm_addr; - - igmp = (struct igmp *)(ip + 1); - igmp->igmp_type = IGMP_HOST_MEMBERSHIP_REPORT; - igmp->igmp_code = 0; - igmp->igmp_group = inm->inm_addr; - igmp->igmp_cksum = 0; - igmp->igmp_cksum = in_cksum(m, IGMP_MINLEN); imo = &simo; bzero((caddr_t)imo, sizeof(*imo)); --- 296,301 ---- -- toku -- Yoshitaka Tokugawa Internet: toku@dit.co.jp dit Co., Ltd. Ishihara Bldg. 3F, 3-3-12 Iidabashi Phone +813-3239-7240 Chiyoda-ku, Tokyo, 102 Japan From rem-conf-request@es.net Sun Aug 01 21:34:45 1993 Received: from horse.ee.lbl.gov by osi-west.es.net with SMTP (PP) id <03332-0@osi-west.es.net>; Sun, 1 Aug 1993 18:22:59 +0000 Received: by horse.ee.lbl.gov for rem-conf@es.net (5.65/1.41) id AA15678; Sun, 1 Aug 93 18:18:52 -0700 From: mccanne@horse.ee.lbl.gov (Steven McCanne) Message-Id: <9308020118.AA15678@horse.ee.lbl.gov> To: rem-conf@es.net, mbone@isi.edu, bsdi-users@bsdi.com Subject: Re: IP Multicast under BSD/386 In-Reply-To: Your message of Fri, 30 Jul 93 18:42:10 -0700. <9307310142.AA12037@horse.ee.lbl.gov> Date: Sun, 01 Aug 93 18:18:52 PDT There was a bug in netinet/igmp.c from the tarfile bsd386-ipmcast.tar.Z before I had a chance to update it on Sun Aug 1 18:11:06 PDT 1993. If you grabbed the tar before this time, you'll need to apply the patch below (or retrieve the updated tar). Thanks to Yoshitaka Tokugawa for the original bug fix, and for pointing out that it didn't make it into the tar. Sorry for the inconvenience. Steve ----- *** /tmp/RCSA000786 Sun Aug 1 18:17:10 1993 --- igmp.c Tue Jul 27 14:00:07 1993 *************** *** 288,299 **** ip->ip_src.s_addr = INADDR_ANY; ip->ip_dst = inm->inm_addr; ! igmp = (struct igmp *)(ip + 1); igmp->igmp_type = IGMP_HOST_MEMBERSHIP_REPORT; igmp->igmp_code = 0; igmp->igmp_group = inm->inm_addr; igmp->igmp_cksum = 0; igmp->igmp_cksum = in_cksum(m, IGMP_MINLEN); imo = &simo; bzero((caddr_t)imo, sizeof(*imo)); --- 288,303 ---- ip->ip_src.s_addr = INADDR_ANY; ip->ip_dst = inm->inm_addr; ! m->m_data += sizeof(struct ip); ! m->m_len -= sizeof(struct ip); ! igmp = mtod(m, struct igmp *); igmp->igmp_type = IGMP_HOST_MEMBERSHIP_REPORT; igmp->igmp_code = 0; igmp->igmp_group = inm->inm_addr; igmp->igmp_cksum = 0; igmp->igmp_cksum = in_cksum(m, IGMP_MINLEN); + m->m_data -= sizeof(struct ip); + m->m_len += sizeof(struct ip); imo = &simo; bzero((caddr_t)imo, sizeof(*imo)); From rem-conf-request@es.net Mon Aug 02 12:00:01 1993 Received: from ietf.cnri.reston.va.us by osi-west.es.net with SMTP (PP) id <07228-0@osi-west.es.net>; Mon, 2 Aug 1993 08:49:39 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04581; 2 Aug 93 11:41 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-avt-profile-01.txt Date: Mon, 02 Aug 93 11:41:51 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9308021141.aa04581@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Sample Profile for the Use of RTP for Audio and Video Conferences with Minimal Control Author(s) : H. Schulzrinne Filename : draft-ietf-avt-profile-01.txt Pages : 5 This note describes a profile for the use of the real-time transport protocol (RTP) and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from content index to encodings. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-avt-profile-01.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-avt-profile-01.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-avt-profile-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-profile-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From rem-conf-request@es.net Mon Aug 02 12:05:40 1993 Received: from ietf.cnri.reston.va.us by osi-west.es.net with SMTP (PP) id <07224-0@osi-west.es.net>; Mon, 2 Aug 1993 08:49:34 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04553; 2 Aug 93 11:41 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-avt-encodings-01.txt Date: Mon, 02 Aug 93 11:41:29 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9308021141.aa04553@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : Media Encodings Author(s) : H. Schulzrinne Filename : draft-ietf-avt-encodings-01.txt Pages : 7 This document describes a possible structure of the media content for audio and video for Internet applications. The definitions are independent of the particular transport mechanism used. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-avt-encodings-01.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-avt-encodings-01.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-avt-encodings-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-encodings-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From rem-conf-request@es.net Mon Aug 02 12:07:38 1993 Received: from ietf.cnri.reston.va.us by osi-west.es.net with SMTP (PP) id <07267-0@osi-west.es.net>; Mon, 2 Aug 1993 08:52:31 +0000 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa04633; 2 Aug 93 11:42 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: ID ACTION:draft-ietf-avt-rtp-02.txt Date: Mon, 02 Aug 93 11:42:25 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9308021142.aa04633@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP: A Real-Time Transport Protocol Author(s) : H. Schulzrinne, S. Casner Filename : draft-ietf-avt-rtp-02.txt Pages : 28 This draft describes a real-time transport protocol (RTP) suitable for the network transport of real-time data, such as audio, video or simulation data for both multicast and unicast transport services. The data transport is enhanced by a control protocol (RTCP) designed to provide minimal control and identification functionality particularly in multicast networks. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and bridges. Within multicast associations, sites can direct control messages to individual sites. This specification is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-avt-rtp-02.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-avt-rtp-02.txt". For questions, please mail to internet-drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mail-server@nisc.sri.com" Content-Type: text/plain SEND draft-ietf-avt-rtp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Aug 03 20:53:43 1993 Received: from viipuri.nersc.gov by osi-west.es.net with SMTP (PP) id <24436-0@osi-west.es.net>; Tue, 3 Aug 1993 17:42:40 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA28948; Tue, 3 Aug 93 17:42:38 PDT Date: Tue, 3 Aug 93 17:42:38 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9308040042.AA28948@viipuri.nersc.gov> To: rem-conf@es.net Subject: SGI announces InPerson desktop conferencing Cc: dvtf@es.net, rcwg@nic.hep.net forwarded from comp.sys.sgi.announce: SILICON GRAPHICS DELIVERS REAL-TIME COLLABORATIVE COMPUTING WITH INPERSON(tm) DESKTOP CONFERENCING [This press release has been slightly edited to remove any blatant commerical aspects. MJW:moderator] MOUNTAIN VIEW, California (August 3, 1993) -- Silicon Graphics, Inc. (NYSE: SGI) today introduced the InPerson(tm) desktop conferencing software. Designed for Silicon Graphics' workstations -- including the new Indy(tm) desktop system -- InPerson takes advantage of Silicon Graphics' digital media hardware and the new Indigo Magic(tm) user environment. Combined with Indy, which comes with a color digital video camera, InPerson requires no additional hardware for professional-quality audio and video capabilities. It enables users to share high-quality audio, video, text, images and 3D modele in real-time over standard network connections. InPerson exploits Indigo Magic, the industry's first media user interface, which combines the most extensive use of drag and drop icons with full access to the digital media power of Silicon Graphics systems. With the Indigo Magic environment and the InPerson software, users can interact with multiple conference participants using live video and audio. A shared media board lets conference participants share, view, mark-up and interact with conference data on an unlimited number of media board pages. Cursors unique to each participant enable tracking of edits and comments. The entire media board can be saved as a file for later reference or for broad distribution. The InPerson software is application independent, allowing users to import an image for review and mark-up from any application window. Multiple applications can be used to review, capture and include data in the conference. It is also fully equipped with multi-way conferencing and messaging indicators enabling users to receive notification of calls missed, to place a current call on hold for incoming calls and to easily join active conferences. The InPerson software is designed for the most efficient use of the system and network. InPerson works easily over standard UNIX(r) networking protocols, eliminating the need for special networks. The InPerson software supports a range of video resolutions and frame rates, including a high resolution mode for display of real-world objects such as design prototypes. Combined with Indy, the newest member of the Indigo(tm) family of desktop workstations, the InPerson software delivers a complete desktop conferencing environment -- receiving and sending video and audio, and enabling real-time interaction through the media board. The Indy desktop system comes standard with video-in, high-quality audio, graphics and network connections. InPerson software also enables viewing of transmitted video and interaction with the media board regardless of the video-in capabilities of a participant's system. The InPerson software will first be available for the Indy and Indigo2 desktop systems in December 1993, and across other Silicon Graphics workstations by year-end 1994. A single-user license will be available for $495 which includes full color video capabilities, shared media board and call management tools. Volume discounts and multi-unit pricing will be available. The InPerson software will support the English, French, German and Japanese languages. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Aug 03 22:36:43 1993 Received: from uhunix.uhcc.Hawaii.Edu by osi-west.es.net with SMTP (PP) id <25077-0@osi-west.es.net>; Tue, 3 Aug 1993 19:23:48 +0000 Received: from (uhunix3.uhcc.Hawaii.Edu) by uhunix.uhcc.Hawaii.Edu (4.1/Sun690) id AA28283; Tue, 3 Aug 93 16:23:41 HST Received: by (4.1/uhunix3) id AA23032; Tue, 3 Aug 93 16:23:40 HST From: newsham@uhunix.uhcc.Hawaii.Edu Message-Id: <9308040223.AA23032@> Subject: FAQ ? To: rem-conf@es.net Date: Tue, 3 Aug 93 16:23:39 HST X-Mailer: ELM [version 2.3 PL11] Is there an FAQ or a resource list stating where one can find specific software tools relating to multicasting? If so, could someone forward me a copy. Thanx. Tim N. From rem-conf-request@es.net Wed Aug 04 07:08:55 1993 Received: from leon.cti.gr by osi-west.es.net with SMTP (PP) id <27441-0@osi-west.es.net>; Wed, 4 Aug 1993 04:05:56 +0000 Date: Wed, 4 Aug 1993 14:05:37 +0200 From: BALAOURA@cti.gr (Pantelis E. Balaouras - Network Group) Message-Id: <930804140537.2020362b@cti.gr> Subject: How can I get information about XTP ? To: rem-conf@es.net X-Vmsmail-To: SMTP%"rem-conf@es.net" Hi, I am very interested in getting the XTP Protocol Definition which according to the book "XTP: The Xpress Transfer Protocol" is in the public domain. The book says that this is electronically available on request by e-mail to the address xtp-request@pei.com. I sent a message to the above address but the mailer responded that there was no such user name. Does anyone know from where I can get the XTP Protocol Definition or how can I get in touch with the the XTP Forum or Protocol Engines Inc. in order to get information about XTP ordering? Also I am very interested in purchasing some XTP implementation (including source code if available). Although I am interested in running the XTP protocol stack on SPARCstations (SunOS 4.1.3 and Solaris 2.1), could anyone inform me about: 1. and if there are any other supported platforms. 2. who else is providing XTP Thanks you in advance Pantelis ========================================================================= Pantelis Balaouras Computer Technology Institute (C.T.I) University of Patras Kolokotroni 3, 262 21 Patras P.O 1122, 261 10 Patras Greece E-mail: balaoura@cti.gr Tel: +30-61-994.317, 994.318, 992.061 Fax: +30-61-993.973 ========================================================================= From rem-conf-request@es.net Thu Aug 05 13:31:20 1993 Received: from cc.lut.fi by osi-west.es.net with SMTP (PP) id <10012-0@osi-west.es.net>; Thu, 5 Aug 1993 10:23:03 +0000 Received: by cc.lut.fi (5.65c/IDA-1.4.4/Kim-2.2) id AA05097; Thu, 5 Aug 1993 20:22:44 +0300 From: Vesa Ruokonen Message-Id: <199308051722.AA05097@cc.lut.fi> Subject: Summer School on Telecommunications in MBone To: rem-conf@es.net Date: Thu, 5 Aug 93 20:22:43 EETDST Reply-To: Vesa.Ruokonen@lut.fi X-Mailer: ELM [version 2.3 PL11] Hi, Like some of you might already have noticed on your SD tool we are going to multicast Summer School on Telecommunications from Lappeenranta University of Technology next week, 9.-13.8. There's International Workshop on Intelligent Networks in tuesday 10th August, and other seminars for the rest of the week. For more information about seminars use anonymous ftp lut.fi:/pub/mbone/*.8 We are trying to watch #mbone channel on IRC during seminar, thus using it as external control channel. Please use it if you want quick response. Sorry for late warning, but we got the network to the main lecture hall today morning and it looks like we can make it.. -- Vesa.Ruokonen@lut.fi HELLO! I'm a .signature virus! Join in and copy me into yours! From rem-conf-request@es.net Thu Aug 05 13:40:19 1993 Received: from CNRI.Reston.VA.US by osi-west.es.net with SMTP (PP) id <08578-0@osi-west.es.net>; Thu, 5 Aug 1993 08:21:40 +0000 Received: from CNRI.Reston.VA.US by CNRI.Reston.VA.US id aa11078; 5 Aug 93 11:17 EDT To: " (Ari Ollikainen)" cc: dvtf@es.net, "/RFC-822=rcwg(a)nic.hep.net/"@cosine-gw.infn.it, rem-conf@es.net, topolcic@CNRI.Reston.VA.US Subject: Re: Connect918 In-reply-to: Your message of "Tue, 29 Jun 93 20:00:48 -0000." <9307020100.AA08333@viipuri.nersc.gov> Date: Thu, 05 Aug 93 11:17:22 -0400 From: Claudio Topolcic Message-ID: <9308051117.aa11078@CNRI.Reston.VA.US> Ari, Well, I went to Macworld yesterday to look at the NUTS Connect 918. Other than the price, I was not impressed. They had several demos going, and I went to look at the LAN demo, running at 128Kbps, supposedly at QCIF, and "almost" full motion. The other demos were not much better quality. The resolution was not QCIF. Even on a 2" window, you could really see a lot of grainyness. The images were significantly worse than Bonny's and Todd's on their glossy brochure. The frame rate was at best 15fps, though their brochure says that at QCIF it will do 30fps. This wasn't bothersome on the talking heads, but the people walking through the background were definitely not at full motion. Furthermore, they had some sort of color quantization problems (big greenish and blueish patches on people's cheeks). Although this may have been a problem with lousy lighting and a camera that does not do well in low lighting, it was typical lighting for a trade show, which I would consider typical for an office environment. The only explanation I can come up with is that the people they sent to Macworld didn't seem to know very much about their product (they couldn't tell me anything about how they were sending the data across the LAN, and they said that their system had not been tested for interoperability with other H.261 codecs, while you said it had been tested with Picture Tel) and so may not have set the demo up very well. They didn't end up with a very impressive demo. How does this compare with the demo you saw? Claudio From rem-conf-request@es.net Thu Aug 05 17:48:57 1993 Received: from galaxy.net.Hawaii.Edu by osi-west.es.net with SMTP (PP) id <13554-0@osi-west.es.net>; Thu, 5 Aug 1993 14:36:49 +0000 Received: from dorsai.net.Hawaii.Edu ([132.160.3.4]) by galaxy.net.Hawaii.Edu with SMTP id <119676>; Thu, 5 Aug 1993 11:33:52 -1000 Date: Thu, 5 Aug 1993 11:05:49 -1000 From: Winston KC Dang Subject: New IMM ver 2.5 To: rem-conf@es.net, mbone@isi.edu cc: torben@Hawaii.Edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Everyone, I'd like to invite you all to try out the IMM beta session in SD. To participate, grab the new IMM version from ftp.hawaii.edu in the subdir /ftp/paccom/imm-2.5. Folow the README. If you have the old version of IMM you simply need to replace the old IMM with the new version. I promise you nice colorful background pictures on your root window. Plus you will help me in my study of reliable file transport in the multicast domain. To those of you with SGI and DEC machines. Sorry I am still looking for someone to help me port this. Any takers? Thanks, Winston From rem-conf-request@es.net Mon Aug 09 22:24:16 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <11322-0@osi-west.es.net>; Mon, 9 Aug 1993 19:15:04 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Mon, 9 Aug 1993 19:15:01 -0700 Posted-Date: Mon 9 Aug 93 19:14:22-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Mon, 9 Aug 93 19:14:23 PDT Date: Mon 9 Aug 93 19:14:22-PDT From: Stephen Casner Subject: Re: New AVT RTP drafts (protocol name) To: hgs@research.att.com, rem-conf@es.net Message-Id: <744948862.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199307301601.AA27738@venera.isi.edu> Mail-System-Version: > 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) I was hoping there might be some other responses while I was attending MM'93 last week, before I jump in with my position, but I didn't see any. Shall we have a teleconference meeting of the AVT WG to discuss the new RTP drafts? I'm NOT in favor of dropping "Transport" from the title. Yes, there have been statements made that RTP isn't really a transport protocol, but I still think that is the best classification, particularly in the IP stack if not the ISO stack. We talk about RTP being carried over an underlying transport layer, but consider the two cases: UDP: Really, it takes UDP and RTP together to provide a "transport" service. UDP is really just a transport-layer demultiplexing service and error detection. RTP provides sequencing, loss detection, and (sort of) flow control. TCP: If RTP is used over TCP, RTP's sequencing and loss detection functions are totally redundant. My primary concern is that reducing the name to "Real-Time Protocol" may imply a function like NTP instead of data transfer. Another possibility would be "Realtime Transfer Protocol", but I still prefer to keep the name as it is. One last small point is that "transport" is the IETF Area we are in. -- Steve ------- From rem-conf-request@es.net Tue Aug 10 04:14:17 1993 Received: from sics.se by osi-west.es.net with SMTP (PP) id <12849-0@osi-west.es.net>; Tue, 10 Aug 1993 00:48:15 +0000 Received: from hans.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA16479; Tue, 10 Aug 93 09:47:58 +0200 Message-Id: <9308100747.AA16479@sics.se> Date: Tue, 10 Aug 1993 09:48:04 +0100 To: rcaslis@sirius.acs.uci.edu From: hans@sics.se (Hans Eriksson) X-Sender: hans@sics.se (Unverified) Subject: Flooding MBone Cc: rem-conf@es.net, mbone@isi.edu Dear rcaslis, Please, please, do _not_ start a video test like to one you have started. You are sending a black picture at about 300kb/s. I do not mind or care if you do that locally (i.e. ttl<16) but doing that with globally (ttl>64) is something I do care about. Please, use a lower ttl or limit nv bandwidth! Hmm, I would say that these 300kbps of waste justifies a temporary cut-off from MBone until it is stopped or motivated. May I ask someone close by to do just that, disconnect that tunnel to uci.edu. In comparison the black picture with a streetlight from BellCore is using only 10kbps which is almost like any background noise. cheers /hans Hans Eriksson, SICS, Box 1263, 164 28 Kista, Sweden Tel: +46 8 752 1527 Fax: +46 8 751 7230 email: hans@sics.se From rem-conf-request@es.net Tue Aug 10 06:18:01 1993 Received: from rx7.ee.lbl.gov by osi-west.es.net with SMTP (PP) id <13168-0@osi-west.es.net>; Tue, 10 Aug 1993 02:24:56 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA07282; Tue, 10 Aug 93 02:24:17 -0700 Message-Id: <9308100924.AA07282@rx7.ee.lbl.gov> To: rcaslis@sirius.acs.uci.edu Cc: rem-conf@es.net, mbone@isi.edu Subject: rcaslis@sirius.acs.uci.edu flooding MBone with high rate video Date: Tue, 10 Aug 93 02:24:17 PDT From: Van Jacobson Why are you sending 350-450Kb/s video at multicast TTL of 127? Even if the subject matter had been interesting (it's a totally dark room), this is a completely unreasonable bandwidth for such a large ttl -- You are totally saturating most of the international links and have completely destroyed the audiocast of the Summer School on Telecomm being broadcast from Lappeenranta University in Finland. Some of us are coming in in the middle of the night to watch this & weren't terribly pleased to learn that you had knocked it off the air. Last week you did essentially the same thing and wiped out the SigKids feed from SigGraph. This is very antisocial behavior. - Van Jacobson From rem-conf-request@es.net Tue Aug 10 12:59:00 1993 Received: from mothra.nts.uci.edu by osi-west.es.net with SMTP (PP) id <16194-0@osi-west.es.net>; Tue, 10 Aug 1993 09:36:12 +0000 Received: by mothra.nts.uci.edu id AA15645 (5.65c/IDA-1.4.4 for rem-conf@es.net); Tue, 10 Aug 1993 09:36:07 -0700 Received: from [128.200.132.104] (godzilla.nts.uci.edu) by mothra.nts.uci.edu with SMTP id AA15623 (5.65c/IDA-1.4.4 for rem-conf@es.net); Tue, 10 Aug 1993 09:35:48 -0700 Message-Id: <199308101635.AA15623@mothra.nts.uci.edu> Date: Tue, 10 Aug 1993 09:37:21 -0800 To: hans@sics.se (Hans Eriksson), rcaslis@sirius.acs.uci.edu From: David Walker X-Sender: dhwalker@mothra.nts.uci.edu Subject: Re: Flooding MBone Cc: rem-conf@es.net, mbone@isi.edu I want to apologize on UCI's behalf for what happened here. The person who did this is not part of our packet video project, but he had (valid) access to a workstation running the software. I will take steps to see that it doesn't happen again. David At 9:48 AM 8/10/93 +0100, Hans Eriksson wrote: >Dear rcaslis, > >Please, please, > >do _not_ start a video test like to one you have started. You are sending a >black picture at about 300kb/s. I do not mind or care if you do that >locally (i.e. ttl<16) but doing that with globally (ttl>64) is something I >do care about. > >Please, use a lower ttl or limit nv bandwidth! > >Hmm, I would say that these 300kbps of waste justifies a temporary cut-off >from MBone until it is stopped or motivated. May I ask someone close by to >do just that, disconnect that tunnel to uci.edu. > >In comparison the black picture with a streetlight from BellCore is using >only 10kbps which is almost like any background noise. > > >cheers > > >/hans > >Hans Eriksson, SICS, Box 1263, 164 28 Kista, Sweden >Tel: +46 8 752 1527 Fax: +46 8 751 7230 email: hans@sics.se From rem-conf-request@es.net Tue Aug 10 14:07:54 1993 Received: from tesla.psc.edu by osi-west.es.net with SMTP (PP) id <17491-0@osi-west.es.net>; Tue, 10 Aug 1993 10:56:17 +0000 Received: by tesla.psc.edu (5.57/Ultrix2.4-C cf:ab 9/11/90 --MM--) id AA18553; Tue, 10 Aug 93 13:56:13 -0400 Message-Id: <9308101756.AA18553@tesla.psc.edu> To: rem-conf@es.net, mbone@isi.edu Subject: Re: Flooding MBone In-Reply-To: Your message of "Tue, 10 Aug 93 09:37:21 -0800." <199308101635.AA15623@mothra.nts.uci.edu> Date: Tue, 10 Aug 93 13:56:12 -0400 From: mahdavi@tesla.psc.edu X-Mts: smtp There is going to be more danger of this sort of thing happening as time goes on. SGI, for example, ships with multicast in the kernel; I expect other vendors won't be far behind in that department. All it takes is an mrouter on a campus LAN (unless special precautions are taken) and any student on campus will meet the description below. (This is not to say we should get rid of the students :-) > The person who > did this is not part of our packet video project, but he had (valid) access > to a workstation running the software. Has anyone thought about ways to "defend" the mbone from this type of use? One simple thing that I can think of is to ship the applications with a default TTL of 32 or less, and a big warning along the lines of "don't change this unless you know what you are doing!". Ultimately, though, I suspect we'll need bandwidth limitting to be really safe... --Jamshid From rem-conf-request@es.net Tue Aug 10 14:46:10 1993 Received: from tadpole.Tadpole.COM by osi-west.es.net with SMTP (PP) id <18018-0@osi-west.es.net>; Tue, 10 Aug 1993 11:33:58 +0000 Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA21992; Tue, 10 Aug 93 13:33:53 CDT Date: Tue, 10 Aug 93 13:33:53 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9308101833.AA21992@tadpole.tadpole.com> To: rem-conf@es.net, mbone@ISI.EDU, mahdavi@tesla.psc.edu Subject: Re: Flooding MBone > There is going to be more danger of this sort of thing happening as > time goes on. SGI, for example, ships with multicast in the kernel; Not only that, but the newest (and least expensive) SGI comes with a video camera. Solaris also ships with multicast IP. Jim From rem-conf-request@es.net Tue Aug 10 15:26:58 1993 Received: from research.att.com by osi-west.es.net with SMTP (PP) id <18533-0@osi-west.es.net>; Tue, 10 Aug 1993 12:14:49 +0000 Received: by inet; Tue Aug 10 15:12 EDT 1993 Date: Tue, 10 Aug 93 15:12:05 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: jim@tadpole.com Subject: Re: Flooding MBone Cc: rem-conf@es.net, mbone@ISI.EDU The solution is easy: just implement true multicast rather than truncated broadcast. As long as nobody is listening to the multicast group of that ignorant student, the traffic wouldn't leave the local network, regardless of ttl setting (after the appropriate pruning has taken place). This episode again emphasizes the extreme urgency of getting true multicast developed and deployed. Bandwidth limits, unless they are source/group specific, don't help except in protecting non-realtime traffic. --- 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 Tue Aug 10 15:58:42 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <18937-0@osi-west.es.net>; Tue, 10 Aug 1993 12:47:21 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12968>; Tue, 10 Aug 1993 12:46:50 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 10 Aug 1993 12:46:39 -0700 To: rem-conf@es.net, mbone@isi.edu Subject: Re: Flooding MBone In-reply-to: Your message of "Tue, 10 Aug 93 10:56:12 PDT." <9308101756.AA18553@tesla.psc.edu> Date: Tue, 10 Aug 1993 12:46:37 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Aug10.124639pdt.12171@skylark.parc.xerox.com> As I reported a while ago, at Xerox PARC we are working on a new release of the IP multicast software that does true multicast routing (i.e., not just truncated-broadcast routing), supports configurable bandwidth limits on tunnels and physical links, and supports prioritized packet dropping when the load exceeds the configured limits. All of that has now been implemented and tested here at PARC and on DARTnet by Ajit Thyagarajan, a summer intern working with me. We are now ready to distribute the code to a *limited* number of beta-test sites who would be willing to help us find bugs and to subject their mrouted machines to a higher-than-normal probability of crashes. If you would like to be a guinea pig for the new code, please drop me a note. Steve From rem-conf-request@es.net Tue Aug 10 16:25:38 1993 Received: from faui45.informatik.uni-erlangen.de by osi-west.es.net with SMTP (PP) id <19344-0@osi-west.es.net>; Tue, 10 Aug 1993 13:10:41 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA24744 (5.65c-5/7.3v-FAU); Tue, 10 Aug 1993 22:09:55 +0200 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA05406 (5.65c-5/7.3m-FAU); Tue, 10 Aug 1993 22:09:58 +0200 From: Toerless Eckert Message-Id: <199308102009.AA05406@faui43.informatik.uni-erlangen.de> Subject: Re: Flooding MBone To: "Henning G. Schulzrinne" Date: Tue, 10 Aug 93 22:07:10 MET DST Cc: jim@tadpole.com, rem-conf@es.net, mbone@ISI.EDU In-Reply-To: <199308101915.AA15667@venera.isi.edu>; from "Henning G. Schulzrinne" at Aug 10, 93 3:12 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] > The solution is easy: just implement true multicast rather than > truncated broadcast. As long as nobody is listening to the multicast > group of that ignorant student, the traffic wouldn't leave the local > network, regardless of ttl setting (after the appropriate pruning > has taken place). This episode again emphasizes the extreme urgency > of getting true multicast developed and deployed. Bandwidth limits, > unless they are source/group specific, don't help except in protecting > non-realtime traffic. Sure. Top priority. Would like to find a spare machine to help debug it. On the other hand: What about a student sending on an existing multicast group, even more disturbing operations - like blasting white audio noise into a vat sesseion ? People could click him off in vat, but his data would - as far as i understand it - be passed through the net by the same traffic shaping/limiting factors as the other important data on that multicast group. Would something like an access authorisation key within each sourced packet not be an easy solution for the short term ? Encode some key anyhow in an ip header (don't ask me how), and then at least in the mrouter connecting your institution with the rest of mbone all multicast packets going out to the world could be checked against existence of a valid key, and if not valid be dropped. Add a setsockopt to set the key on a socket etc.. pp. Toerless From rem-conf-request@es.net Tue Aug 10 16:36:28 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <19563-0@osi-west.es.net>; Tue, 10 Aug 1993 13:22:54 +0000 Received: from blackbird.parc.xerox.com ([13.2.116.118]) by alpha.xerox.com with SMTP id <12960>; Tue, 10 Aug 1993 13:22:40 PDT Received: from localhost by blackbird.parc.xerox.com with SMTP id <2610>; Tue, 10 Aug 1993 13:22:35 -0700 To: rem-conf@es.net, mbone@isi.edu cc: Ajit Thyagarajan Subject: Re: Flooding MBone In-reply-to: Your message of "Tue, 10 Aug 93 10:56:12 PDT." <9308101756.AA18553@tesla.psc.edu> Date: Tue, 10 Aug 1993 13:22:24 PDT Sender: Ajit Thyagarajan From: Ajit Thyagarajan Message-Id: <93Aug10.132235pdt.2610@blackbird.parc.xerox.com> In a couple of weeks, we will be ready to release the DVMRP version of mrouted. Links that do not have members of a particular multicast group will not forward traffic along that link. This way, traffic from sources which have no members anywhere, will be contained only to the subnet where it originates. This will prevent flooding of the Mbone with unwanted traffic. Also incorporated are user-configurable bandwidth limits on multicast traffic on any interface. This should be particularly useful for tunnels having low bandwidth capability. A suitable priority encoding scheme is being worked on currently. Ajit From rem-conf-request@es.net Tue Aug 10 16:48:09 1993 Received: from mothra.nts.uci.edu by osi-west.es.net with SMTP (PP) id <19761-0@osi-west.es.net>; Tue, 10 Aug 1993 13:34:21 +0000 Received: by mothra.nts.uci.edu id AA21607 (5.65c/IDA-1.4.4 for rem-conf@es.net); Tue, 10 Aug 1993 13:34:18 -0700 Received: from [128.200.132.104] (godzilla.nts.uci.edu) by mothra.nts.uci.edu with SMTP id AA21598 (5.65c/IDA-1.4.4 for rem-conf@es.net); Tue, 10 Aug 1993 13:34:11 -0700 Message-Id: <199308102034.AA21598@mothra.nts.uci.edu> Date: Tue, 10 Aug 1993 13:35:44 -0800 To: mahdavi@tesla.psc.edu, rem-conf@es.net, mbone@isi.edu From: David Walker X-Sender: dhwalker@mothra.nts.uci.edu Subject: Re: Flooding MBone Cc: DRoode@uci.edu, Mangrich@uci.edu I would also like to see a warning in the applications when TTL (or bandwidth) is set above a certain threshold, much as many network news readers print a warning message before posting an article. This is, by the way, precisely what was suggested to me when I talked to the people responsible for our recent debacle; they didn't realize that they were doing anything out of the ordinary. A simple warning message would have prevented this from occurring. David Walker Assistant Director, NTS Office of Academic Computing Addresses: NTS University of California Irvine, CA 92717-5475 (714) 856-7037 DHWalker@uci.edu At 1:56 PM 8/10/93 -0400, mahdavi@tesla.psc.edu wrote: >There is going to be more danger of this sort of thing happening as >time goes on. SGI, for example, ships with multicast in the kernel; >I expect other vendors won't be far behind in that department. All it >takes is an mrouter on a campus LAN (unless special precautions are >taken) and any student on campus will meet the description below. >(This is not to say we should get rid of the students :-) > >> The person who >> did this is not part of our packet video project, but he had (valid) access >> to a workstation running the software. > >Has anyone thought about ways to "defend" the mbone from this type of >use? One simple thing that I can think of is to ship the applications >with a default TTL of 32 or less, and a big warning along the lines of >"don't change this unless you know what you are doing!". > >Ultimately, though, I suspect we'll need bandwidth limitting to be >really safe... > >--Jamshid From rem-conf-request@es.net Tue Aug 10 18:21:49 1993 Received: from itd.nrl.navy.mil by osi-west.es.net with SMTP (PP) id <21005-0@osi-west.es.net>; Tue, 10 Aug 1993 15:11:05 +0000 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10825; Tue, 10 Aug 93 18:11:02 EDT Date: Tue, 10 Aug 93 18:11:02 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9308102211.AA10825@itd.nrl.navy.mil> To: rem-conf@es.net Subject: MBONE flooding Regarding the suggestion of an access key like mechanism to prevent unauthorised folks from flooding the net, I'd like to gently suggest that such is a non-trivial problem to solve in a dependable way. While there are known techniques in the public literature for multicast key distribution. I don't know of any Really Good multicast key distribution algorithms in the public literature. Such would be a good PhD disseration topic, IMHO. In short, we'd better start working now on public education of what constitutes "civilised behaviour". Ran atkinson@itd.nrl.navy.mil From rem-conf-request@es.net Tue Aug 10 20:06:56 1993 Received: from sadye.emba.uvm.edu by osi-west.es.net with SMTP (PP) id <22198-0@osi-west.es.net>; Tue, 10 Aug 1993 16:58:25 +0000 Received: by sadye.emba.uvm.edu id AA01356 (5.65/1.23); Tue, 10 Aug 93 19:57:08 -0400 Date: Tue, 10 Aug 93 19:57:08 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9308102357.AA01356@sadye.emba.uvm.edu> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: rem-conf@es.net Subject: MBONE flooding In-Reply-To: <9308102211.AA10825@itd.nrl.navy.mil> References: <9308102211.AA10825@itd.nrl.navy.mil> < Regarding the suggestion of an access key like mechanism to prevent > unauthorised folks from flooding the net, I'd like to gently suggest > that such is a non-trivial problem to solve in a dependable way. I agree with Ran. Here's a quote that I extracted from Doug Gwyn a few years ago; I hope he doesn't mind me dredging it up in an unrelated context: # [I]t is necessary and sufficient to protect computing systems from # outside attack; if you have granted legitimate access to somebody, a # certain amount of trust in his good faith is implied, since it is # virtually impossible to impose enough controls on an authorized user # to prevent his abusing resources while simultaneously not impeding his # productivity. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From rem-conf-request@es.net Tue Aug 10 21:10:36 1993 Received: from netcom5.netcom.com by osi-west.es.net with SMTP (PP) id <22682-0@osi-west.es.net>; Tue, 10 Aug 1993 18:01:05 +0000 Received: by netcom5.netcom.com (5.65/SMI-4.1/Netcom) id AA21694; Tue, 10 Aug 93 18:01:56 -0700 From: tharenos@netcom.com (Michael Tharenos) Message-Id: <9308110101.AA21694@netcom5.netcom.com> To: rem-conf@es.net Subject: Desktop Video Communications Showcase at Telecon XIII Date: Tue, 10 Aug 93 18:01:55 -0700 All, In case you all missed the press release (and I suspect most of us did) I thought I would forward it to this list. I am organizing a showcase at the upcoming Telecon XIII trade show in November for Desktop Video based products. The showcase will feature live demonstrations of packet and circuit switched video solutions to the desktop from a number of companies. Both digital and analog systems will be on display. I wanted to formally extend a Call for Participation to this group for companies/organizations wishing to show off their technology and to individuals who may wish to speak during the conference about this subject. The following companies are in the showcase and I hope many more will join over the coming weeks: Hitachi Sun Solutions Datapoint Universal Four Pair Worldlinx Network Video Technologies AT&T VTEL Northern Telecom Sharevision Intervision Systems Corp. Intel Viewpoint Microsoft Scientific Atlanta Protocalls PictureTel We will be putting together a VideoNet to interconnect all of these companies and if all goes well, it should be an exciting demonstration of things today and things to come. More importantly we want it to be another venue for people to learn more about the technology, the issues, and the solutions. Of course not all of the solutions being shown are packet switched but I thought it would still be of interest to everyone.... I have enclosed the press release below. Best regards, Michael Michael Tharenos Pangea Consulting 408-578-5130 "Seamless Integration on a Global Scale" ============================================================================== April 29, 1993 Contact:Michael Tharenos Pangea Consulting 408/578-5130 or For Immediate Release Jennifer Loccarini Applied Business teleComm. 510/820-5563 Desktop Video Communications Showcased at TeleCon XIII Applied Business teleCommunications and Pangea Consulting, an organization specializing in desktop videoconferencing, system integration and trade show demonstrations, have created the first "Desktop Video Communications Showcase" to be displayed at Telecon XIII, November 8, 9 and 10, 1993 in San Jose, Calif. The two companies are organizing a display of desktop videoconferencing units for the public to view and learn about the features of each product. The demonstration in the exhibit hall at TeleCon XIII will further enlighten the public on the new world of videoconferencing and desktop video. "The future of videoconferencing is on the screen of desktop computers," said Patrick S. Portway, president, Applied Business teleCommunications. TeleCon XIII is the first time this type of showcase will be presented to the public. The showcase will be a starting point for attendees to learn about the issues and be introduced to the applications of desktop video communications. "We are planning a showcase area that will allow people to compare the features of numerous desktop video products side by side on the exhibit floor in a live demonstration" said Michael Tharenos, president, Pangea Consulting. The showcase will serve to educate potential buyers on such issues as synchronization techniques, bandwidth management, and compression alternatives. Applications such as corporate training, video libraries, messaging and video conferencing will be shown across a live network interconnecting participating vendors' booths to the showcase. Once attendees identify a product that seems to meet their needs they can simply follow the network, an electronic path, to the developer's booth to obtain additional information. The opportunity to easily compare the products in a live demonstration should enable attendees to make more efficient and informed buying decisions. From rem-conf-request@es.net Wed Aug 11 08:24:24 1993 Received: from charon.cwi.nl by osi-west.es.net with SMTP (PP) id <25373-0@osi-west.es.net>; Wed, 11 Aug 1993 03:49:32 +0000 Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP id AA23845 (5.65b/3.9/CWI-Amsterdam); Wed, 11 Aug 1993 12:43:21 +0200 Received: by schelvis.cwi.nl with SMTP id AA20377 (5.65b/3.8/CWI-Amsterdam); Wed, 11 Aug 1993 12:43:18 +0200 Message-Id: <9308111043.AA20377=jack@schelvis.cwi.nl> To: Ajit Thyagarajan Cc: rem-conf@es.net, mbone@ISI.EDU Subject: Re: Flooding MBone In-Reply-To: Message by Ajit Thyagarajan , Tue, 10 Aug 1993 13:22:24 PDT , <93Aug10.132235pdt.2610@blackbird.parc.xerox.com> 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: Beat Busters, Desmond Dekker (Paradiso, 24-7) X-Mini-Review: Uptown top skanking! Date: Wed, 11 Aug 1993 12:43:17 +0200 From: Jack Jansen Recently, Ajit Thyagarajan said: > > In a couple of weeks, we will be ready to release the DVMRP version of > mrouted. What is the algorithm used to prune the tree? Will transmissions start in broadcast mode with links slowly being taken out if no-one on the other end is interested, or is it some sort of rendezvous mechanism with listeners advertising their interest? -- 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 Aug 11 08:42:23 1993 Received: from faui45.informatik.uni-erlangen.de by osi-west.es.net with SMTP (PP) id <25571-0@osi-west.es.net>; Wed, 11 Aug 1993 04:12:47 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA00377 (5.65c-5/7.3v-FAU); Wed, 11 Aug 1993 13:12:19 +0200 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA21634 (5.65c-5/7.3m-FAU); Wed, 11 Aug 1993 13:12:22 +0200 From: Toerless Eckert Message-Id: <199308111112.AA21634@faui43.informatik.uni-erlangen.de> Subject: Re: MBONE flooding To: wollman@uvm-gen.EMBA.UVM.EDU Date: Wed, 11 Aug 93 13:09:30 MET DST Cc: atkinson@itd.nrl.navy.mil, rem-conf@es.net In-Reply-To: <9308102357.AA01356@sadye.emba.uvm.edu>; from "wollman@uvm-gen.EMBA.UVM.EDU" at Aug 11, 93 1:57 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] > > Regarding the suggestion of an access key like mechanism to prevent > > unauthorised folks from flooding the net, I'd like to gently suggest > > that such is a non-trivial problem to solve in a dependable way. Sure, this was not part of the approach. How the users and the mrouted in an organisation agree upon a key is up to them. The key should have only institution local acceptance. It's no idea for a general solution but just a hack to cope with the problem we encounter. > I agree with Ran. Here's a quote that I extracted from Doug Gwyn a > few years ago; I hope he doesn't mind me dredging it up in an > unrelated context: > > # [I]t is necessary and sufficient to protect computing systems from > # outside attack; if you have granted legitimate access to somebody, a > # certain amount of trust in his good faith is implied, since it is > # virtually impossible to impose enough controls on an authorized user > # to prevent his abusing resources while simultaneously not impeding his > # productivity. Totally agreed. The problem is that us admins are responsible to the rest of the net against packet storms generated by our users. Thus if i for example see no workable way to keep abusage to an acceptable minimum, i would have to stop mutlicasting to the mbone at all, or limit it to a small number of well protected machines (i.e.: very few users there). This is certainly not in my interest. This mean: as long as a control mechanism serves to enable MORE productivity to the common user, i accept it. In this way i would vote for a very limited very simple to implement access key. Regards Toerless From rem-conf-request@es.net Wed Aug 11 09:44:32 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <26287-0@osi-west.es.net>; Wed, 11 Aug 1993 06:33:36 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12894>; Wed, 11 Aug 1993 06:32:26 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 11 Aug 1993 06:32:15 -0700 To: Jack Jansen Cc: rem-conf@es.net, mbone@isi.edu Subject: Re: Flooding MBone In-reply-to: Your message of "Wed, 11 Aug 93 03:43:17 PDT." <9308111043.AA20377=jack@schelvis.cwi.nl> Date: Wed, 11 Aug 1993 06:32:11 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Aug11.063215pdt.12171@skylark.parc.xerox.com> > What is the algorithm used to prune the tree? Will transmissions start > in broadcast mode with links slowly being taken out if no-one on the > other end is interested, or is it some sort of rendezvous mechanism > with listeners advertising their interest? The former -- initial broadcast, triggering "prune" messages from all branches where there are no listeners. The pruning happens within less than one round-trip time, which I wouldn't call "slowly". The algorithm is described in my thesis as the Distance-Vector Multicast Routing Algorithm. (You can fetch the PostScript from gregorio.stanford.edu:vmtp-ip/sdthesis*.) Steve From rem-conf-request@es.net Wed Aug 11 13:37:39 1993 Received: from mail.tc.umn.edu by osi-west.es.net with SMTP (PP) id <28254-0@osi-west.es.net>; Wed, 11 Aug 1993 09:48:20 +0000 Received: from mailbox.mail.umn.edu by mail.tc.umn.edu id SMTP-0012c691123013775; Wed, 11 Aug 93 10:32:52 -0500 Date: Wed, 11 Aug 93 10:36:18 CDT Message-Id: <9308111536.AA18036@mailbox.mail.umn.edu> Received: from dialup-slip-1-34.gw.umn.edu by mailbox.mail.umn.edu; Wed, 11 Aug 93 10:36:18 CDT From: Billie Wahlstrom To: rem-conf@es.net Subject: Forwarded Message... ------------ Forwarded Message begins here ------------ From: "Don Riley" Date: Sun, 8 Aug 93 22:09:37 CDT To: du@umn-cs.cs.umn.edu, c-hale@vm1.spcs.umn.edu, gcsales@ux.cis.umn.edu, gva6008@vx.cis.umn.edu, ljorn@staff.tc.umn.edu, LJorn@vm1.spcs.umn.edu, rwpeifer@staff.tc.umn.edu, simon@staff.tc.umn.edu, rosex002@staff.tc.umn.edu, lwanning@vx.cis.umn.edu, bwahlstr, mh@staff.tc.umn.edu, carrier, garlofd@nve.hscs.umn.edu, mmfaculty@cs.umn.edu, schnepf@cs.umn.edu Cc: ernest@lenti.med.umn.edu, george@lenti.med.umn.edu Subject: SGI announces InPerson desktop conferencing ------------ Forwarded Message begins here ------------ From: ari@es.net (Ari Ollikainen) Date: Tue, 3 Aug 93 17:42:38 PDT To: rem-conf@es.net Cc: dvtf@es.net, rcwg@nic.hep.net Subject: SGI announces InPerson desktop conferencing forwarded from comp.sys.sgi.announce: SILICON GRAPHICS DELIVERS REAL-TIME COLLABORATIVE COMPUTING WITH INPERSON(tm) DESKTOP CONFERENCING [This press release has been slightly edited to remove any blatant commerical aspects. MJW:moderator] MOUNTAIN VIEW, California (August 3, 1993) -- Silicon Graphics, Inc. (NYSE: SGI) today introduced the InPerson(tm) desktop conferencing software. Designed for Silicon Graphics' workstations -- including the new Indy(tm) desktop system -- InPerson takes advantage of Silicon Graphics' digital media hardware and the new Indigo Magic(tm) user environment. Combined with Indy, which comes with a color digital video camera, InPerson requires no additional hardware for professional-quality audio and video capabilities. It enables users to share high-quality audio, video, text, images and 3D modele in real-time over standard network connections. InPerson exploits Indigo Magic, the industry's first media user interface, which combines the most extensive use of drag and drop icons with full access to the digital media power of Silicon Graphics systems. With the Indigo Magic environment and the InPerson software, users can interact with multiple conference participants using live video and audio. A shared media board lets conference participants share, view, mark-up and interact with conference data on an unlimited number of media board pages. Cursors unique to each participant enable tracking of edits and comments. The entire media board can be saved as a file for later reference or for broad distribution. The InPerson software is application independent, allowing users to import an image for review and mark-up from any application window. Multiple applications can be used to review, capture and include data in the conference. It is also fully equipped with multi-way conferencing and messaging indicators enabling users to receive notification of calls missed, to place a current call on hold for incoming calls and to easily join active conferences. The InPerson software is designed for the most efficient use of the system and network. InPerson works easily over standard UNIX(r) networking protocols, eliminating the need for special networks. The InPerson software supports a range of video resolutions and frame rates, including a high resolution mode for display of real-world objects such as design prototypes. Combined with Indy, the newest member of the Indigo(tm) family of desktop workstations, the InPerson software delivers a complete desktop conferencing environment -- receiving and sending video and audio, and enabling real-time interaction through the media board. The Indy desktop system comes standard with video-in, high-quality audio, graphics and network connections. InPerson software also enables viewing of transmitted video and interaction with the media board regardless of the video-in capabilities of a participant's system. The InPerson software will first be available for the Indy and Indigo2 desktop systems in December 1993, and across other Silicon Graphics workstations by year-end 1994. A single-user license will be available for $495 which includes full color video capabilities, shared media board and call management tools. Volume discounts and multi-unit pricing will be available. The InPerson software will support the English, French, German and Japanese languages. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------ Forwarded Message ends here ------------ ___________________________________________________________________________ Don Riley Ph:(612) 626-9816 FAX:624-3814 Acting Assoc. Provost for Academic Affairs, Computer & Information Svcs Univ. of Minnesota, 8 Morrill Hall, 100 Church St. SE, Mpls, MN 55455 ------------ Forwarded Message ends here ------------ Billie Wahlstrom Professor and Head Rhetoric Department University of Minnesota St. Paul, MN 55105 bwahlstr@mailbox.mail.umn.edu From rem-conf-request@es.net Thu Aug 12 10:22:59 1993 Received: from rx7.ee.lbl.gov by osi-west.es.net with SMTP (PP) id <07839-0@osi-west.es.net>; Thu, 12 Aug 1993 06:12:40 +0000 Received: by rx7.ee.lbl.gov for rem-conf@es.net (5.65/1.44r) id AA09365; Thu, 12 Aug 93 06:11:29 -0700 Message-Id: <9308121311.AA09365@rx7.ee.lbl.gov> To: rem-conf@es.net, mbone@isi.edu Subject: LBL wb (v1.53) available for anonymous ftp Date: Thu, 12 Aug 93 06:11:27 PDT From: Van Jacobson A beta release of the LBL shared network `whiteboard' tool, wb, is available for anonymous ftp from ftp.ee.lbl.gov in directory `wb'. The directory contains tars for Sparcstations running Sun OS 4.x & Solaris 2.2, DECstations running Ultrix 4.x, and SGI machines running IRIX 4.x. Attached is a copy of the distribution README file. This is the first public release of wb. If you somehow got a copy of an earlier alpha release, please destroy it and upgrade to this release. Earlier versions of wb are not protocol compatible with this version and contain a number of serious bugs. You will cause yourself & others much grief if you run an older version of wb. We'd like to take this opportunity to thank the alpha testers who contributed enormously to the reliability and usability of wb (that's not to say that the current version of wb is remarkably reliable or usable but you should have seen what the alpha testers had to endure). In particular we'd like to thank Steve Deering & Ron Frederick of Xerox PARC, George Michaelson of the University of Queensland, Australia, Robert Elz of the University of Melbourne, Australia, Jim Martin of Rutgers University, and Jon Crowcroft, Mark Handley and others of the MICE project at University College London. Note that this is a *beta* version. Only about 20% of what we plan for wb has been implemented. We believe the tool is usable in its current form but expect some annoying holes and expect what's there to be buggy. We would like to hear about bugs, problems, suggestions, etc. You can reach us via email to wb@ee.lbl.gov. Thanks. Good luck. - Van Jacobson & Steve McCanne -------------------------------------- Thu Aug 12 04:19:23 PDT 1993 This is a beta-release of the LBL 'whiteboard' for Sparcstations running Sun OS 4.x & Solaris 2.2, DECstations running Ultrix 4.x, and SGI machines running IRIX 4.x. However you got it, the original came via anonymous ftp from ftp.ee.lbl.gov, directory wb. Since this is an early beta, we expect it change frequently as users find bugs & we make our fumbling attempts to fix them. If you got wb from somewhere other than LBL, check LBL to see if there's a more recent version. Before using wb, read the file NOTES from the distribution (note especially the .sd.tcl change needed if you are running sd v1.14 or earlier) and print and read the postscript file lblwb.ps. If you simply want a shared "whiteboard" drawing surface, you don't need to do anything but install wb. But wb can also be used to export, view and annotate arbitrary PostScript files. If you want to include PostScript images in your wb conference, either your X server has to support Display PostScript (the DEC & SGI X servers do) or wb has to be able to exec the public domain postscript renderer `GhostScript'. If you want to render postscript with Ghostscript, it has to be installed on your machine and has to be in your shell search path with the name "gs". (If you don't have Ghostscript it can be ftp'd from prep.ai.mit.edu, file pub/gnu/ghostscript-*.tar.Z.). While the normal version of gs will work with wb, you might want to grab {sun,dec,sgi}-gs.Z from ftp.ee.lbl.gov. This is a version of gs 2.6.1 (patchlevel 4) with a change to limit the number of colors allocated and to not allocate 'dynamic' colors. If you don't have these changes then (1) wb/gs will not co-exist well with nv and (2) previously rendered color postscript pages will change color in strange ways when new color pages are rendered. The LBL version of gs also includes some bug fixes for rendering in rotated coordinate systems and caching of font glyphs at large point sizes (such as those used for viewgraphs). If you would rather build your own gs from source, the patch file LBL_GS.DIFFS can be applied to a gs 2.6.1pl4 source. If you want to use wb for giving seminars or lectures over a network, you might also want to grab wbimport.tar.Z. This is a tool that works together with wb to sequence through a set of slides & import scanned images or X window dumps into a wb session. The whiteboard tool is intended to work in conjunction with the LBL "Session Directory" tool, sd, and the LBL audio tool, vat. Both are available for anonymous ftp from ftp.ee.lbl.gov, files *-sd.tar.Z and *-vat.tar.Z. You might also want to get the network video tool, nv, developed by Ron Frederick at Xerox PARC. It is available for ftp from parcftp.xerox.com, file pub/net-research/nv*.tar.Z. These tools will work for point-to-point communication but they will be most useful in an environment that supports IP multicast. The SGI and Solaris 2.2 kernels come from the vendor with multicast support. Ultrix and SunOS 4.x do not. If your kernel doesn't support IP multicast, you can ftp the necessary support from host gregorio.stanford.edu, files vmtp-ip/ipmult-*. You might find it useful to get connected to the Internet's multicast backbone, the MBone (ftp mbone.faq from venera.isi.edu for information). Please let us know of any problems, bugs or suggestions for improvement via email to wb@ee.lbl.gov. Thanks. Van Jacobson (van@ee.lbl.gov) Steve McCanne (mccanne@ee.lbl.gov) ----------------- The development of `wb', `vat', and `sd' were supported by the Director, Office of Energy Research, Scientific Computing Staff, of the U.S. Department of Energy under Contract No. DE-AC03-76SF00098. From rem-conf-request@es.net Thu Aug 12 12:46:55 1993 Received: from nps.navy.mil by osi-west.es.net with SMTP (PP) id <09692-0@osi-west.es.net>; Thu, 12 Aug 1993 09:34:57 +0000 Received: from in50217.cc.nps.navy.mil.cc.nps.navy.mil ([131.120.50.217]) by nps.navy.mil (4.1/SMI-4.1) id AA13249; Thu, 12 Aug 93 09:30:24 PDT Date: Thu, 12 Aug 93 09:30:24 PDT From: tmconroy@nps.navy.mil (Tracy M. Conroy) Message-Id: <9308121630.AA13249@nps.navy.mil> To: rem-conf@es.net Subject: subscribe/join Please add me to your mailing list. Thanks tmconroy@131.120.50.201 From rem-conf-request@es.net Thu Aug 12 13:17:51 1993 Received: from tenet.ICSI.Berkeley.EDU by osi-west.es.net with SMTP (PP) id <09995-0@osi-west.es.net>; Thu, 12 Aug 1993 10:03:06 +0000 Received: from faith.CS.Berkeley.EDU by tenet.ICSI.Berkeley.EDU (5.63/1.42) id AA23694; Thu, 12 Aug 93 10:02:48 -0700 From: digenova@tenet.ICSI.Berkeley.EDU (Pasquale Digenova) Received: by faith (Sun-5.57/CLIENT$Revision: 1.4 $) id AA13000; Thu, 12 Aug 93 10:02:36 -0700 Date: Thu, 12 Aug 93 10:02:36 -0700 Message-Id: <9308121702.AA13000@faith> To: rem-conf@es.net Subject: subscribe/join Please add me to your mailing list. Thanks, pasquale From rem-conf-request@es.net Thu Aug 12 20:03:18 1993 Received: from Xenon.Stanford.EDU by osi-west.es.net with SMTP (PP) id <16815-0@osi-west.es.net>; Thu, 12 Aug 1993 16:30:33 +0000 Received: by Xenon.Stanford.EDU (5.61+IDA/25-CS-eef) id AA16423; Thu, 12 Aug 93 16:30:30 -0700 From: Avneesh Agrawal Message-Id: <9308122330.AA16423@Xenon.Stanford.EDU> Subject: test To: rem-conf@es.net Date: Thu, 12 Aug 1993 16:30:30 -0700 (PDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 62 Hi, I'd like to joing the rem-conf newslist. Thanks Avneesh From rem-conf-request@es.net Fri Aug 13 13:06:03 1993 Received: from picard.cmf.nrl.navy.mil by osi-west.es.net with SMTP (PP) id <22092-0@osi-west.es.net>; Fri, 13 Aug 1993 07:52:22 +0000 Received: from sparky.cmf.nrl.navy.mil by picard (4.1/SMI-4.1) id AA04446; Fri, 13 Aug 93 10:52:12 EDT Received: from localhost by sparky.cmf.nrl.navy.mil (4.1/client-1.3) id AA13139; Fri, 13 Aug 93 10:52:12 EDT Message-Id: <9308131452.AA13139@sparky.cmf.nrl.navy.mil> To: Stephen Casner Subject: Re: New AVT RTP drafts (protocol name) Cc: rem-conf@es.net, mankin@sparky.cmf.nrl.navy.mil In-Reply-To: Your message of "Mon, 09 Aug 93 19:14:22 PDT." <744948862.0.CASNER@XFR.ISI.EDU> Date: Fri, 13 Aug 1993 10:52:09 -0400 From: Allison J Mankin >> I'm NOT in favor of dropping "Transport" from the title. Steve, I agree with you on this, and not just because AVT is in the Transport Area that I direct. The protocol provides the services needed for the end-to-end delivery (i.e. the transport) of video and audio. I know it has come up before, but Real Time could be a bit confusing in the name. Not Transport. Final point, you ask if people would be interested in an interim, over-the-net meeting to discuss the newest drafts: I vote yes. Allison / mankin@cmf.nrl.navy.mil From rem-conf-request@es.net Fri Aug 13 15:32:23 1993 Received: from ucdavis.ucdavis.edu by osi-west.es.net with SMTP (PP) id <26081-0@osi-west.es.net>; Fri, 13 Aug 1993 12:23:43 +0000 Received: by ucdavis.ucdavis.edu (4.1/UCD2.05) id AA13959; Fri, 13 Aug 93 12:09:08 PDT From: rdhobby@ucdavis.edu (Russ Hobby) Date: Fri, 13 Aug 93 12:09:08 PDT Message-Id: <9308131909.AA13959@ucdavis.ucdavis.edu> To: Internauts: isoc.org, IETF-Announce: ietf.cnri.reston.va.us, rem-conf@es.net PP-Warning: Parse error in original version of preceding line Original-To: Internauts:;@isoc.org, IETF-Announce:;@ietf.cnri.reston.va.us, rem-conf@es.net Subject: INET 93 MBONE Broadcast I am pleased to announce that there will be a broadcast of the INET 93 presentations that will be in Ballroon A. For those of you on the MBONE, we will announce it on sd as soon we get the network connection into the hotel. The schedule of sessions is listed below. Russ Hobby 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 ----------------------------------------------------------------------- INET 93 Sessions on the MBONE Aug 18, 1993: 08:30 to 10:00 Opening Session Aug 18, 1993: 10:30 to 12:00 Tools for Networked Information Discovery and Retrieval Aug 18, 1993: 14:00 to 15:30 Building Applications Aug 18, 1993: 16:00 to 17:30 Panel: Virtual Culture and Community Aug 19, 1993: 08:30 to 10:00 Global Networks and K12 Education Aug 19, 1993: 10:30 to 12:00 Panel: Helping Users Help Themselves Aug 19, 1993: 14:00 to 15:30 Supporting Global Emergency Management Aug 19, 1993: 16:00 to 17:30 Plenary Panel: Industry View of the Internet Aug 20, 1993: 08:30 to 10:00 Cyber-Knowledge and Information-Space Aug 20, 1993: 10:30 to 12:00 Closing Session From rem-conf-request@es.net Fri Aug 13 15:36:57 1993 Received: from tadpole.Tadpole.COM by osi-west.es.net with SMTP (PP) id <26100-0@osi-west.es.net>; Fri, 13 Aug 1993 12:27:14 +0000 Received: from ono-sendai (ono-sendai.Tadpole.COM) by tadpole.tadpole.com (4.1/SMI-4.1) id AA27677; Fri, 13 Aug 93 14:27:06 CDT Received: by ono-sendai (4.1/SPARCbook_POP1.3) id AA01116; Fri, 13 Aug 93 14:26:21 CDT Date: Fri, 13 Aug 93 14:26:21 CDT From: jim@tadpole.com Message-Id: <9308131926.AA01116@ono-sendai> To: mbone@isi.edu, rem-conf@es.net Subject: Multicast for SPARCbook machines Cc: dms@tadpole.com, mr@tadpole.com Several months ago, I saw a query on either mbone or rem-conf about the availability of multicast IP for the SPARCbook. I've ported the June 23 release of ipmulti-sunos41x.tar.Z to the SPARCbook 1 and 2, and put the results up for anonymous ftp. I've only been able to perform limited testing. We don't have an mbone tunnel to this site (as yet), and are unlikely to get one, given that we run a uniquely braindamaged method of connection to the Internet. If someone who has a SPARCbook *and* an mbone drop could ensure that this stuff could test it, I'd appreciate it. wb and vat work on the local ethernet. You can find the distribution at tadpole.com:~ftp/pub/multicast/ipmulti-tadpole.tar.Z Jim (Thanks to those of you who participated or otherwise helped with SIGkids last week.) From rem-conf-request@es.net Fri Aug 13 17:00:40 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <26766-0@osi-west.es.net>; Fri, 13 Aug 1993 13:21:38 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Fri, 13 Aug 1993 13:21:35 -0700 Posted-Date: Fri 13 Aug 93 13:20:55-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 13 Aug 93 13:20:56 PDT Date: Fri 13 Aug 93 13:20:55-PDT From: Stephen Casner Subject: Teleconference on RTP spec draft To: rem-conf@es.net Message-Id: <745273255.0.CASNER@XFR.ISI.EDU> Mail-System-Version: To: Audio/Video Transport Working Group and interested listeners Re: Review of RTP spec draft TELECONFERENCE: Allison Mankin votes for a teleconference meeting, and I think it's a good idea. We need to avoid the INET conference next week Wed-Fri, so I suggest next Tuesday, 17-Aug-93, at 9:00 PDT (1600 UTC). That may be early enough for Europeans to tune in. Who can participate at that time? Later on Tuesday is OK for me also. REVIEW PERIOD: Today marks the end of the requested comment period for the RTP spec draft posted two weeks ago, yet there have been no comments. Even if you think the draft is perfect, I'd appreciate a note saying so. I would like to get comments from those who have been active in the development of the protocol, but it is equally important that the spec be reviewed by some of the folks who understand the basic idea but have not been involved in the details. You can tell us if there are places where the text is confusing or where additional explanation is required for a person who doesn't already know the protocol. The RTP Internet-Draft is available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-ietf-avt-rtp-02.txt". Internet-Drafts directories are located at: o East Coast (US) Address: ds.internic.net (198.49.45.10) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-ietf-avt-rtp-02.txt". Thanks. -- Steve ------- From rem-conf-request@es.net Fri Aug 13 21:54:00 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <29621-0@osi-west.es.net>; Fri, 13 Aug 1993 18:45:50 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Fri, 13 Aug 1993 18:45:46 -0700 Posted-Date: Fri 13 Aug 93 18:45:06-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 13 Aug 93 18:45:07 PDT Date: Fri 13 Aug 93 18:45:06-PDT From: Stephen Casner Subject: Re: New AVT RTP drafts (protocol name) To: mankin@sparky.cmf.nrl.navy.mil Cc: rem-conf@es.net Message-Id: <745292706.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9308131452.AA13139@sparky.cmf.nrl.navy.mil> Mail-System-Version: Allison, Thanks for your comments on the Realtime Transport Protocol name. > I know it has come up before, but Real Time could be a > bit confusing in the name. Could you please explain the potential confusion? Others have questioned whether the protocol applies in general to "real-time applications" or is specific to audio and video, but this is a matter of justification rather than confusion. To me, the idea of real-time seems fairly strong in this protocol (with the presence of timestamps, for example). I also oppose the idea of restricting the protocol by its name to audio and video only. -- Steve ------- From rem-conf-request@es.net Mon Aug 16 12:36:27 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <06067-0@osi-west.es.net>; Sun, 15 Aug 1993 12:03:22 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12232>; Sun, 15 Aug 1993 12:03:05 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Sun, 15 Aug 1993 12:03:03 -0700 To: rem-conf@es.net cc: deering@parc.xerox.com Subject: Xerox PARC Forum, August 19 -- Dave Clark, Network Security Date: Sun, 15 Aug 1993 12:02:59 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Aug15.120303pdt.12171@skylark.parc.xerox.com> The following seminar will be 'cast on the MBone, using the same TTL scope as IETF Channel 2. It is advertised in 'sd' with the following parameters: Xerox PARC Forum - Audio pcm 224.2.199.198, port 49373, id 0, ttl 159 Xerox PARC Forum - Video nv 224.2.199.199, port 49375, id 0, ttl 95 Thursday, August 19, 1993 4:00 PM, Pacific Time SECURITY AND THE OPEN DATA NETWORK: HOW DO WE GET THERE? Dave Clark MIT Laboratory for Computer Science Telecommunications and data networking have worked a fundamental change on the nature of computer security. Old security models do not seem to address the core problems, and we lack new models to guide us. Lacking effective approaches to network security, open data networks such as the Internet cannot come into being, since the risks of penetration and data corruption will deter users from open connection. This talk will briefly report on a NRC study of computer and communications security, now about two years old, and will present two perspectives on the network security problem, slanted towards network and security specialists respectively. It will speculate on some approaches to network security, and argue why they can be effective in supporting the open network. From rem-conf-request@es.net Mon Aug 16 12:36:32 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <07491-0@osi-west.es.net>; Sun, 15 Aug 1993 21:32:59 +0000 Received: from blackbird.parc.xerox.com ([13.2.116.118]) by alpha.xerox.com with SMTP id <12261>; Sun, 15 Aug 1993 21:32:40 PDT Received: from localhost by blackbird.parc.xerox.com with SMTP id <2617>; Sun, 15 Aug 1993 21:32:29 -0700 To: mbone@isi.edu, rem-conf@es.net cc: Ajit Thyagarajan Subject: Beta release of mrouted supporting pruning/grafting Date: Sun, 15 Aug 1993 21:32:14 PDT Sender: Ajit Thyagarajan From: Ajit Thyagarajan Message-Id: <93Aug15.213229pdt.2617@blackbird.parc.xerox.com> I would like to thank all of you who responded to the beta-testing note sent out by Steve Deering earlier. I have come across a couple of bugs that I would like to fix and test on Dartnet before making it available. There will be a delay of a couple of days due to this. Sorry for any inconveniences caused. Thanks Ajit From rem-conf-request@es.net Mon Aug 16 16:19:29 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <14363-0@osi-west.es.net>; Mon, 16 Aug 1993 13:10:49 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Mon, 16 Aug 1993 13:10:46 -0700 Posted-Date: Mon 16 Aug 93 13:10:06-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Mon, 16 Aug 93 13:10:07 PDT Date: Mon 16 Aug 93 13:10:06-PDT From: Stephen Casner Subject: AVT Working Group Teleconference To: rem-conf@es.net Message-Id: <745531806.0.CASNER@XFR.ISI.EDU> Mail-System-Version: AVT Working Group Teleconference TIME CHANGE: Tomorrow, Tuesday, 17-Aug-93 10:00 PDT (1700 UTC) Since I did not get any responses from Europeans wanting to participate, I have set the meeting time one hour later than originally proposed. This allows EDT folks to get lunch first, and is more convenient for some PDT folks. You should see a session advertisement in sd under "IETF AVT Working Group Mtg". The purpose of this meeting is to discuss comments on the the Realtime Transport Protocol (RTP) spec draft in preparation for going to RFC. Comments still solicited by e-mail. I will send another message later today with a list of topics. -- Steve Casner ------- From rem-conf-request@es.net Mon Aug 16 19:13:39 1993 Received: from galaxy.net.Hawaii.Edu by osi-west.es.net with SMTP (PP) id <16432-0@osi-west.es.net>; Mon, 16 Aug 1993 16:06:13 +0000 Received: from dorsai.net.Hawaii.Edu ([132.160.3.4]) by galaxy.net.Hawaii.Edu with SMTP id <119740>; Mon, 16 Aug 1993 13:03:05 -1000 Date: Mon, 16 Aug 1993 12:55:04 -1000 From: Winston KC Dang Sender: Winston KC Dang Reply-To: Winston KC Dang Subject: IMM version 2.6 for SGI, server & sources available To: rem-conf@es.net, mbone@isi.edu cc: torben@Hawaii.Edu, Craig Ruff , Andrew Cherenson Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII An SGI version of IMM 2.6 is now available at ftp.hawaii.edu:/ftp/paccom/imm-2.6/bin. Many thanks to Craig Ruff who ported it and Andrew Cherenson who helped. The SGI version built uses TCL 7.0b2 and TK 3.3b2 and the shared libraries for Irix 4.0.5F. Also The sources and server code is now available at ftp.hawaii.edu:/ftp/paccom/imm-2.6/src. Winston Dang From rem-conf-request@es.net Tue Aug 17 04:52:37 1993 Received: from venera.isi.edu by osi-west.es.net with SMTP (PP) id <19224-0@osi-west.es.net>; Tue, 17 Aug 1993 01:44:48 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Tue, 17 Aug 1993 01:44:45 -0700 Posted-Date: Tue 17 Aug 93 01:44:05-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Tue, 17 Aug 93 01:44:07 PDT Date: Tue 17 Aug 93 01:44:05-PDT From: Stephen Casner Subject: Discussion topics for AVT WG review of RTP spec To: rem-conf@es.net Message-Id: <745577045.0.CASNER@XFR.ISI.EDU> Mail-System-Version: Enclosed below are some topics I'd like to discuss during the AVT WG teleconference. Participants may suggest others. -- Steve Discussion topics for AVT WG review of RTP spec =============================================== - Review the new formats of SDES and QOS options. - If QOS reports statistics of a synchronization source, then wouldn't the source identifier in the corresponding SDES option should always be zero? - Review new SDST Reverse Path Option - should it be in the RTCP section? - when is use of the reverse path reasonable? (need ACK-implosion warning) - not all options would be legal or make sense in the reverse path - how should the header fields be defined? - FlowID is the same as the forward direction, per the recent discussions. - Does the sequence number mean anything? - Review new security options. - Can all sources within the same channel share the same encryption descriptor table? Don't sources independently control key switching? - Impact on implementations of the removal of the RAD option. (e.g., H.261 can define RAD for itself, or its own two options) - Grouping of channels for sharing of SDES information might be specified in a profile, or may be arbitrary under the control of a higher-layer protocol. - Andy Cherenson's request for an option to indicate "mute" status. - How does an application determine whether or not it's time source is synchronized to absolute time? On UNIX, contact xntpd? - Are there any areas in the text that need clarification or further explanation? - Should the protocol name be changed from "Realtime Transport Protocol" to "Real-Time Protocol"? - Should this protocol be submitted as "Experimental", "Prototype", or "Proposed Standard"? - "Encoding" draft: comments on preferred sampling frequencies. - "Profile" draft: any problem with the proposed port numbers? What should be said about the choice of using randomly-assigned port numbers with this profile? - We may not be able to get two IP protocol numbers for RTP (with and without the checksum encapsulation). Could the presence of this encapsulation be specified by the choice of profile? How would this choice be indicated? ------- From rem-conf-request@es.net Tue Aug 17 05:42:34 1993 Received: from domen.uninett.no by osi-west.es.net with SMTP (PP) id <19451-0@osi-west.es.net>; Tue, 17 Aug 1993 02:34:43 +0000 Received: from localhost by domen.uninett.no with SMTP (PP) id <20300-0@domen.uninett.no>; Tue, 17 Aug 1993 11:34:37 +0200 To: rem-conf@es.net Subject: NCD terminals and VAT+friends Date: Tue, 17 Aug 1993 11:34:36 +0200 From: "Harald T. Alvestrand" Hello, apologies for disturbing anything, but if anyone knows, you know... We (the secretariat of the Norwegian university network) want to do some experiments using the MBONE and vat/nevot and friends. Unfortunately, we don't have SUNs for all the people, but NCD MX terminals. These terminals seem to be equipped with adequate sound capabilities, but these capabilities cannot be realized by opening /dev/audio on the server (naturally). So, does anyone have source/binaries/hints/failures for using the main multimedia applications on NCD terminals? Any hints are appreciated! Regards, Harald Tveit Alvestrand From rem-conf-request@es.net Tue Aug 17 07:37:34 1993 Received: from charon.cwi.nl by osi-west.es.net with SMTP (PP) id <19816-0@osi-west.es.net>; Tue, 17 Aug 1993 04:10:51 +0000 Received: from schelvis.cwi.nl by charon.cwi.nl with SMTP id AA24299 (5.65b/3.9/CWI-Amsterdam); Tue, 17 Aug 1993 13:10:41 +0200 Received: by schelvis.cwi.nl with SMTP id AA03261 (5.65b/3.8/CWI-Amsterdam); Tue, 17 Aug 1993 13:10:39 +0200 Message-Id: <9308171110.AA03261=jack@schelvis.cwi.nl> To: rem-conf@es.net Subject: Video over slip 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: Manic Street Preachers (Melkweg, 15-8), Windmills (Kroeg) X-Mini-Review: MSP: uneventful. Windmills: Great! Date: Tue, 17 Aug 1993 13:10:39 +0200 From: Jack Jansen A local TV station wants to do an item on video-over-the-net, and the current plan is to do a combination of some prerecorded footage with something live. Now, the prerecorded stuff is no problem, but for the live stuff we'll have to bring an Indigo to the studio, and somehow connect it to the net. Has anyone tried using nv over a slip link? The result needn't be too fancy (how fancy can you expect it to be at 19k2:-), but does it work at all? -- 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 Tue Aug 17 07:43:40 1993 Received: from faui45.informatik.uni-erlangen.de by osi-west.es.net with SMTP (PP) id <19858-0@osi-west.es.net>; Tue, 17 Aug 1993 04:27:22 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA21753 (5.65c-5/7.3v-FAU); Tue, 17 Aug 1993 13:27:06 +0200 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA04481 (5.65c-5/7.3m-FAU); Tue, 17 Aug 1993 13:27:16 +0200 From: Toerless Eckert Message-Id: <199308171127.AA04481@faui43.informatik.uni-erlangen.de> Subject: Re: Video over slip To: Jack Jansen Date: Tue, 17 Aug 93 13:23:50 MET DST Cc: rem-conf@es.net In-Reply-To: <9308171110.AA03261=jack@schelvis.cwi.nl>; from "Jack Jansen" at Aug 17, 93 1:10 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] > A local TV station wants to do an item on video-over-the-net, and the > current plan is to do a combination of some prerecorded footage with > something live. Now, the prerecorded stuff is no problem, but for the > live stuff we'll have to bring an Indigo to the studio, and somehow > connect it to the net. Has anyone tried using nv over a slip link? The > result needn't be too fancy (how fancy can you expect it to be at > 19k2:-), but does it work at all? At 19k2 you should only send non moving video by nv i think. You may want to try ivs with QCIF resolution and bandwith limiting, that could work at this speed, but don't expect real time video ;-)) Toerless From rem-conf-request@es.net Tue Aug 17 08:22:34 1993 Received: from research.att.com by osi-west.es.net with SMTP (PP) id <19970-0@osi-west.es.net>; Tue, 17 Aug 1993 04:54:09 +0000 Received: by inet; Tue Aug 17 07:53 EDT 1993 Date: Tue, 17 Aug 93 07:53:29 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: rem-conf@es.net, CASNER@ISI.EDU Subject: Re: Discussion topics for AVT WG review of RTP spec > From research!es.net!rem-conf-request Tue Aug 17 06:13:26 1993 > > Discussion topics for AVT WG review of RTP spec > =============================================== > > - Review the new formats of SDES and QOS options. > - If QOS reports statistics of a synchronization source, then > wouldn't the source identifier in the corresponding SDES > option should always be zero? The 'synch. source' field in the QOS option is an editorial remnant that is no longer needed (as far as I can tell). It should be changed to 'reserved'. (The SSRC is meaningless to other sites not served by the same translator.) I propose to use byte four as the length of the QOS part (without ADDR and TSEL parts), so that we can easily extend the QOS information. ---- Henning From rem-conf-request@es.net Tue Aug 17 09:56:08 1993 Received: from rads.dnd.ca by osi-west.es.net with SMTP (PP) id <20400-0@osi-west.es.net>; Tue, 17 Aug 1993 06:38:39 +0000 Received: from radp.dnd.ca by nrnsinc.on.ca with SMTP (PP) id <22215-0@nrnsinc.on.ca>; Tue, 17 Aug 1993 09:47:22 -0400 Received: by radp.dnd.ca (4.1/SMI-4.1) id AA12238; Tue, 17 Aug 93 09:39:17 EDT From: spagnolo@radp.dnd.ca (Joe Spagnolo) Message-Id: <9308171339.AA12238@radp.dnd.ca> Subject: wb, gs and libXext.so.4 To: rem-conf@es.net Date: Tue, 17 Aug 93 9:39:16 EDT Cc: spagnolo (Joe Spagnolo)@radp.dnd.ca Reply-To: spagnolo@radp.dnd.ca Organization: NR/NS Inc., 1-613-599-7860 X-Mailer: ELM [version 2.3 PL11] Hello, When I execute gs (sun-gs) or the dynamically linked version of wb, I get: ld.so: libXext.so.4: not found I am using a Sparc IPC running SunOS 4.1.2 with OpenWindows 3. I have a libXext.a static library but not libXext.so.4. What am I missing? -- Joe Spagnolo From rem-conf-request@es.net Tue Aug 17 10:54:38 1993 Received: from munin.fnal.gov by osi-west.es.net with SMTP (PP) id <20721-0@osi-west.es.net>; Tue, 17 Aug 1993 07:41:47 +0000 Received: from LOCALHOST.fnal.gov by munin.fnal.gov with SMTP id AA27801 (5.65c+/IDA-1.4.4 for rem-conf@es.net); Tue, 17 Aug 1993 09:41:24 -0500 Message-Id: <199308171441.AA27801@munin.fnal.gov> To: spagnolo@radp.dnd.ca Cc: rem-conf@es.net Subject: Re: wb, gs and libXext.so.4 In-Reply-To: Your message of Tue, 17 Aug 93 09:39:16 EDT. <9308171339.AA12238@radp.dnd.ca> Date: Tue, 17 Aug 93 09:41:24 -0500 From: Matt Crawford > When I execute gs (sun-gs) ... I get: > ld.so: libXext.so.4: not found Same here, so I built ghostscript from source. Neither my 4.1.2 nor my 4.1.3 system (both with OW version 3) have a shared Xext library. The statically-linked wb is happy with this gs. _________________________________________________________ Matt Crawford crawdad@munin.fnal.gov Fermilab From rem-conf-request@es.net Tue Aug 17 12:26:45 1993 Received: from alpha.Xerox.COM by osi-west.es.net with SMTP (PP) id <21364-0@osi-west.es.net>; Tue, 17 Aug 1993 09:18:00 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11962>; Tue, 17 Aug 1993 09:17:24 PDT Received: by ecco.parc.xerox.com id <16136>; Tue, 17 Aug 1993 09:17:15 -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, 17 Aug 1993 09:17:07 -0700 (PDT) Message-ID: Date: Tue, 17 Aug 1993 09:17:07 PDT Sender: Ron Frederick From: Ron Frederick To: Jack Jansen Subject: Re: Video over slip CC: rem-conf@es.net In-Reply-To: <9308171110.AA03261=jack@schelvis.cwi.nl> References: <9308171110.AA03261=jack@schelvis.cwi.nl> > A local TV station wants to do an item on video-over-the-net, and the > current plan is to do a combination of some prerecorded footage with > something live. Now, the prerecorded stuff is no problem, but for the > live stuff we'll have to bring an Indigo to the studio, and somehow > connect it to the net. Has anyone tried using nv over a slip link? The > result needn't be too fancy (how fancy can you expect it to be at > 19k2:-), but does it work at all? I'm not sure it really makes sense to try and demonstrate "video" over this sort of link. It isn't a fair picture of what Internet video really is, for one thing. While nv will certainly run fine at this bandwidth, what you get isn't video but a series of still frames, spaced seconds apart. I know that ivs is lower bandwidth, but I suspect even it will be less than a frame a second at this speed, and this just doesn't seem like it will serve the purpose. Is there any chance you can convince them to do the taping of the demo outside of the studio, at some place which has a reasonable net connection? After all, you're trying to demo video over the Internet, not video over phone lines... (For that, they can buy an AT&T picturephone! ) -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Tue Aug 17 14:48:43 1993 Received: from cs.tut.fi by osi-east.es.net with SMTP (PP) id <16950-0@osi-east.es.net>; Tue, 17 Aug 1993 10:07:50 +0000 Received: from kaarne.cs.tut.fi by cs.tut.fi with SMTP id AA19568 (5.65c/IDA-1.4.4 for ); Tue, 17 Aug 1993 20:02:54 +0300 Received: by kaarne.cs.tut.fi id AA09841 (5.65c/IDA-1.4.4 for rem-conf@es.net); Tue, 17 Aug 1993 20:01:06 +0300 Date: Tue, 17 Aug 1993 20:01:06 +0300 From: Mikko Tsokkinen Message-Id: <199308171701.AA09841@kaarne.cs.tut.fi> To: rem-conf@es.net Subject: fmt: jpg Hello Which program is used to view "fmt: jpg" streams? Where can it be obtained? Thanks. Mikko Tsokkinen xxxxx Mit Email: mit@cs.tut.fi,mit@cc.tut.fi,mit@modeemi.cs.tut.fi,mt87692@ee.tut.fi "Any sufficiently advanced technology is indistinguishable from magic." From rem-conf-request@es.net Tue Aug 17 15:17:02 1993 Received: from cs.tut.fi by osi-west.es.net with SMTP (PP) id <23938-0@osi-west.es.net>; Tue, 17 Aug 1993 11:58:38 +0000 Received: from kaarne.cs.tut.fi by cs.tut.fi with SMTP id AA21026 (5.65c/IDA-1.4.4 for ); Tue, 17 Aug 1993 21:58:31 +0300 Received: by kaarne.cs.tut.fi id AA12296 (5.65c/IDA-1.4.4 for rem-conf@es.net); Tue, 17 Aug 1993 21:58:09 +0300 Date: Tue, 17 Aug 1993 21:58:09 +0300 From: Mikko Tsokkinen Message-Id: <199308171858.AA12296@kaarne.cs.tut.fi> To: rem-conf@es.net Subject: fmt: jpg Hello In case there are others who don't know this either: The program in case is IMM. It is available from ftp.hawaii.edu:/ftp/paccom/imm-2.6/ Thanks to Winston KC Dang & Bill Owens for quick answer. Mikko Tsokkinen xxxxx Mit Email: mit@cs.tut.fi,mit@cc.tut.fi,mit@modeemi.cs.tut.fi,mt87692@ee.tut.fi "Any sufficiently advanced technology is indistinguishable from magic." From rem-conf-request@es.net Tue Aug 17 21:12:36 1993 Received: from bochap.iss.nus.sg by osi-east.es.net with SMTP (PP) id <18331-0@osi-east.es.net>; Tue, 17 Aug 1993 18:07:18 +0000 Received: from ferret.iss.nus.sg by bochap.iss.nus.sg (4.1/SMI-4.1) id AA17544; Wed, 18 Aug 93 09:10:50+080 From: asahai@iss.nus.sg (Anupam Sahai) Message-Id: <9308180110.AA17544@bochap.iss.nus.sg> Subject: Subscribe To: rem-conf@es.net Date: Wed, 18 Aug 1993 09:10:50 +0800 (WST) Cc: asahai@iss.nus.sg (Anupam Sahai) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 458 Subscribe asahai@iss.nus.sg (Anupam Sahai) ==================================================================== Anupam Sahai * E-mail : asahai@iss.nus.sg Broadband Networking Group * Inst. of Systems Science * Phone : +65 7726642 National Univ. of S'pore * Heng Mui Keng Terrace * Fax : +65 7782571 Singapore 0511 * ==================================================================== From rem-conf-request@es.net Tue Aug 17 22:11:59 1993 Received: from research.att.com by osi-east.es.net with SMTP (PP) id <18554-0@osi-east.es.net>; Tue, 17 Aug 1993 19:06:05 +0000 Received: by inet; Tue Aug 17 22:05 EDT 1993 Date: Tue, 17 Aug 93 22:05:04 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: rem-conf@es.net Subject: Open issue: port number assignment The profile suggests ports 4443 and 4444 for audio and video. Fixed assignments have two advantages: - we can get traffic statistics, giving some indication of RTP usage - firewall implementations are simplified Any negative consequences? Other ports more appropriate? Henning Schulzrinne From rem-conf-request@es.net Tue Aug 17 22:38:56 1993 Received: from brolga.cc.uq.oz.au by osi-east.es.net with SMTP (PP) id <18600-0@osi-east.es.net>; Tue, 17 Aug 1993 19:32:56 +0000 Received: from cc.uq.oz.au by brolga.cc.uq.oz.au id <05827-0@brolga.cc.uq.oz.au>; Wed, 18 Aug 1993 12:32:44 +1000 To: rem-conf@es.net Subject: Picturetel/H.261 and the multicast Date: Wed, 18 Aug 1993 12:32:44 +1000 From: George Michaelson Sender: G.Michaelson@cc.uq.oz.au Is there a catalogue of hacks to get this kind of stuff tied into the multicast? What are the options for interfacing deployed systems like picturetel which assume ISDN back-ends pt-to-pt tunnels through IP band-split in routers sun/dec/sgi/pc codecs which can emit suitably IP/RTP encoded H.261 bridges/gateways between systems So far I know of a local source for a german 3-card EISA setup for Windows which has an ABI so we could cut something given suitable IP capabilities on the box. I'd love to not have to do that. Many travelled road? -George From rem-conf-request@es.net Wed Aug 18 11:09:14 1993 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with SMTP (PP) id <01638-0@osi-west.es.net>; Sat, 14 Aug 1993 04:11:38 +0000 Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 14 Aug 1993 12:10:05 +0100 From: Mark Handley Organisation: University College London, CS Dept. Phone: +44 71 380 7777 ext 3666 To: jim@tadpole.com cc: mbone@ISI.EDU, rem-conf@es.net, dms@tadpole.com, mr@tadpole.com Subject: Re: Multicast for SPARCbook machines In-reply-to: Your message of "Fri, 13 Aug 93 14:26:21 CDT." <9308131926.AA01116@ono-sendai> Date: Sat, 14 Aug 93 12:09:57 +0100 Sender: M.Handley@cs.ucl.ac.uk >I've only been able to perform limited testing. We don't have an >mbone tunnel to this site (as yet), and are unlikely to get one, >given that we run a uniquely braindamaged method of connection to >the Internet. If someone who has a SPARCbook *and* an mbone drop >could ensure that this stuff could test it, I'd appreciate it. wb >and vat work on the local ethernet. I've just pulled this, and ran up the compiled kernel on a SparcBook 2. I'm currently running vat, ivs, and an mrouted to bridge between two of our nets here at UCL, and it all appears to be running perfectly. Both the Sparcbook and the other machines on the MICE net are hearing Mbone Audio (just had a quick chat to prove it works with Van - thanks Van) I've got some colour map problem with nv, but the other machines on it's net are seeing Mbone video. I'll look into why nv won't run on it later, but IVS colour video looks great. B&W isn't so good due to the limited frame buffer depth. >Jim Thanks for the kernel - looks great. Mark From rem-conf-request@es.net Wed Aug 18 14:47:10 1993 Received: from babyoil.ftp.com by osi-east.es.net with SMTP (PP) id <21644-0@osi-east.es.net>; Wed, 18 Aug 1993 11:40:21 +0000 Received: from solensky.fenway.ftp.com by ftp.com via PCMAIL with DMSP id AA29353; Wed, 18 Aug 93 14:40:29 -0400 Date: Wed, 18 Aug 93 14:40:29 -0400 Message-Id: <9308181840.AA29353@ftp.com> To: CASNER@ISI.EDU Subject: Re: New AVT RTP drafts (protocol name) From: solensky@ftp.com (Frank T Solensky) Cc: rem-conf@es.net Sender: solensky@ftp.com Repository: babyoil.ftp.com Originating-Client: fenway.ftp.com > Date: Fri 13 Aug 93 18:45:06-PDT > From: Stephen Casner > Subject: Re: New AVT RTP drafts (protocol name) > To: mankin@sparky.cmf.nrl.navy.mil > Cc: rem-conf@es.net > > > I know it has come up before, but Real Time could be a > > bit confusing in the name. > > Could you please explain the potential confusion?... I could see where "Real Time" could be a misnomer: it could suggest the absence of queueing between source and destination. While UDP generally drops things when there isn't enough resources, there could be delays introduced when packets are queued at the MAC layer in either the sending host or a propagation delay at the intermediate routers. > I also oppose the idea of restricting the protocol by > its name to audio and video only. Agreed.. -- Frank From rem-conf-request@es.net Wed Aug 18 15:53:18 1993 Received: from zephyr.isi.edu by osi-east.es.net with SMTP (PP) id <22259-0@osi-east.es.net>; Wed, 18 Aug 1993 12:48:04 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Wed, 18 Aug 1993 12:47:52 -0700 Date: Wed, 18 Aug 1993 12:47:52 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199308181947.AA18231@zephyr.isi.edu> To: CASNER@ISI.EDU, solensky@ftp.com Subject: Re: New AVT RTP drafts (protocol name) Cc: rem-conf@es.net *> I could see where "Real Time" could be a misnomer: it could suggest the *> absence of queueing between source and destination. While UDP generally *> drops things when there isn't enough resources, there could be delays *> introduced when packets are queued at the MAC layer in either the sending *> host or a propagation delay at the intermediate routers. *> Frank, The research community has adopted the term "realtime" to mean that an application is fundamentally sensitive to delay; if the packets arrive too late, for some value of "too late", they might as well not have arrived at all. This does NOT mean NO queueing, it means that any queueing must be carefully controlled. Bob From rem-conf-request@es.net Wed Aug 18 15:57:29 1993 Received: from picard.cmf.nrl.navy.mil by osi-east.es.net with SMTP (PP) id <22304-0@osi-east.es.net>; Wed, 18 Aug 1993 12:56:57 +0000 Received: from sparky.cmf.nrl.navy.mil by picard (4.1/SMI-4.1) id AA08131; Wed, 18 Aug 93 15:56:55 EDT Received: from localhost by sparky.cmf.nrl.navy.mil (4.1/client-1.3) id AA23912; Wed, 18 Aug 93 15:56:54 EDT Message-Id: <9308181956.AA23912@sparky.cmf.nrl.navy.mil> To: casner@isi.edu Cc: rem-conf@es.net Subject: Re: New AVT RTP drafts (protocol name) Date: Wed, 18 Aug 1993 15:56:52 -0400 From: Allison J Mankin Steve asked why I thought Realtime might be questionable in the name RTP. I've just noticed a phrase in the spec draft, realtime properties. That strikes me as capturing the protocol better than the term realtime alone. The reason is that the protocol does not by itself make possible deliveries within either specific or loose delay bounds. It offers timing recovery. Other mechanisms in place in the network (RSVP, supported by ISIP...) and in applications (the user of the playback) are involved in making the service "realtime." The protocol serves to convey the realtime properties going along with data, but doesn't itself effect the realtime service. Name thoughts: Time Recovering Transport Protocol (TRTP) Playback-oriented Transport Protocol (POTP) Realtime-propertied Transport Protocol (RPTP) But I'm not strongly asserting that it'd be useful to rename the protocol. In yesterday's WG meeting, it was concluded that we keep the term Transport, and we didn't discuss Realtime at all. Allison From rem-conf-request@es.net Wed Aug 18 17:40:08 1993 Received: from cs.uml.edu by osi-east.es.net with SMTP (PP) id <23096-0@osi-east.es.net>; Wed, 18 Aug 1993 14:34:16 +0000 Received: by cs.uml.edu id AA09901 (5.65c+/IDA-1.4.4 for rem-conf@es.net); Wed, 18 Aug 1993 17:28:05 -0400 From: "John F. Buford" Message-Id: <199308182128.AA09901@cs.uml.edu> Subject: Preliminary CFP: 1993 Intl Conf on MM Computing and Systems To: confctrl@isi.edu, rem-conf@es.net Date: Wed, 18 Aug 1993 17:28:04 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 4540 PRELIMINARY CALL FOR PAPERS 1994 International Conference on Multimedia Computing and Systems Sponsored by The IEEE Computer Society's Task Force on Multimedia Computing May 1994 Boston, Massachusetts, USA PLEASE NOTE CHANGE OF DATE AND LOCATION FROM PREVIOUS ANNOUNCMENTS Conference Chair: Laszlo A. Belady, Mitsubishi Electric Research, USA Program Co-Chairs: Scott M. Stevens, Carnegie Mellon University, USA and Ralf Steinmetz, IBM European Network Center, Germany Multimedia systems are expected to result in the convergence of consumer electronics, computers and communications. Their applications will transform how people work, learn and play. This conference, sponsored by the IEEE Computer Society and its Task Force on Multimedia Computing, offers a world class forum for practicing engineers and researchers to report on and exchange the latest ideas in this exciting field. Immediately preceding the conference, tutorials will provide opportunities for interaction with experts in the related fields. Through this call for papers, the organizers seek contributions of high quality papers and proposals for panels or tutorials. The field of multimedia is still evolving, hence the scope of the conference is broad. We anticipate papers covering many aspects of the transmission, processing, and use of multimedia information. We encourage submissions which describe work--finished or in progress, practical development or theory--on the following or related subjects: Systems Network architecture Hardware architecture Operating systems Distributed systems Database and information systems Techniques Video compression and processing Real time scheduling Human-computer interaction Programming paradigms Content-based retrieval Applications Capture and creation of content Synthetic information and video generation Modeling and simulation Human learning Mobile computing Group collaboration Video dialtone PAPERS AND PANEL PROPOSALS Authors are requested to submit six copies of the manuscript (maximum of 20 pages) including abstract and keywords by Nov. 15, 1993. Final papers are restricted to eight IEEE model pages. The use of prototypes and demonstration video for final presentations is encouraged. Each paper must be accompanied by a submission letter that indicates the most relevant one or two conference areas and primary author contact information including: postal address, email address, telephone and Fax numbers. Important Dates: Nov. 15, 1993: All submissions due Jan. 15, 1994: Notification of acceptance Feb. 15, 1994: Final manuscripts due Submit all papers and panel proposals to: Scott M. Stevens Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15313 USA email: sms@sei.cmu.edu Phone: 412 268-7796 Fax : 412 268-5758 TUTORIALS In addition to papers, proposals for one and two day tutorials are solicited in any of the conference areas. Proposals should include the topic area, a brief summary of the content, a schedule, and information about the instructors. Include the following information for the instructor who will handle conference correspondence: postal address, email address, telephone and fax numbers. Proposals should be submitted by November 15. 1993. Responses and instructors' kits will be sent by Jan 15, 1994. Final course notes should be submitted by Feb 15. Submit proposals for tutorials to: Erich J. Neuhold GMD-IPSI / Technische Hochschule Darmstadt Dolivostr. 15 P.O. Box 10 43 26 6100 Darmstadt Germany email: neuhold@darmstadt.gmd.de Phone: +49 6151 869-802 Fax : +49 6151 869-818 ORGANIZING AND PROGRAM COMMITTEES Conference Chair: Laszlo A. Belady, Mitsubishi Electric Research, USA Program Co-Chairs: Scott M. Stevens, Carnegie Mellon University, USA and Ralf Steinmetz, IBM European Network Center, Germany Tutorial Chair: Erich Neuhold, T.H. Darmstadt, Germany Publicity Chair: John Buford, UMass Lowell, USA Exhibits Chair: William Lambert, Horizon Research, USA Publication Chair: Tibor Vais, Compuserve, USA Reg. & Finance Chair: Joseph Boykin, GTE Laboratories, USA Local Arr. Chair: Michael Bove, MIT Media Lab, USA SPONSORED BY IEEE COMPUTER SOCIETY (final approval pending) From rem-conf-request@es.net Wed Aug 18 18:26:21 1993 Received: from alpha.Xerox.COM by osi-east.es.net with SMTP (PP) id <23377-0@osi-east.es.net>; Wed, 18 Aug 1993 15:20:43 +0000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11886>; Wed, 18 Aug 1993 15:20:11 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 18 Aug 1993 15:20:08 -0700 To: rem-conf@es.net, mbone@isi.edu Subject: Reminder: Xerox PARC Forum, August 19 -- Dave Clark, Network Security Date: Wed, 18 Aug 1993 15:20:04 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Aug18.152008pdt.12171@skylark.parc.xerox.com> The following seminar will be 'cast on the MBone, using the same TTL scope as IETF Channel 2. It is advertised in 'sd' with the following parameters: Xerox PARC Forum - Audio vat 224.2.199.198, port 49373, id 0, ttl 159 Xerox PARC Forum - Video nv 224.2.199.199, port 49375, id 0, ttl 95 Thursday, August 19, 1993 4:00 PM, Pacific Time SECURITY AND THE OPEN DATA NETWORK: HOW DO WE GET THERE? Dave Clark MIT Laboratory for Computer Science Telecommunications and data networking have worked a fundamental change on the nature of computer security. Old security models do not seem to address the core problems, and we lack new models to guide us. Lacking effective approaches to network security, open data networks such as the Internet cannot come into being, since the risks of penetration and data corruption will deter users from open connection. This talk will briefly report on a NRC study of computer and communications security, now about two years old, and will present two perspectives on the network security problem, slanted towards network and security specialists respectively. It will speculate on some approaches to network security, and argue why they can be effective in supporting the open network. From rem-conf-request@es.net Thu Aug 19 14:14:57 1993 Received: from HALITE.BBN.COM by osi-east.es.net with SMTP (PP) id <28255-0@osi-east.es.net>; Thu, 19 Aug 1993 11:09:22 +0000 Received: by halite.bbn.com (AA19382); Thu, 19 Aug 93 14:09:18 EDT Date: Thu, 19 Aug 93 14:08:31 EDT From: Paul Milazzo Subject: Re: Open issue: port number assignment To: "Henning G. Schulzrinne" Cc: rem-conf@es.net Message-Id: <1993.08.19.14.08.31.milazzo.19038@halite.bbn.com> In-Reply-To: <9308180241.AA00297@diamond.bbn.com> A more official (and lower-numbered) port assignment would be nice. Paul From rem-conf-request@es.net Thu Aug 19 15:49:45 1993 Received: from alpha.Xerox.COM by osi-east.es.net with SMTP (PP) id <29077-0@osi-east.es.net>; Thu, 19 Aug 1993 12:49:13 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11639>; Thu, 19 Aug 1993 12:48:52 PDT Received: by ecco.parc.xerox.com id <16136>; Thu, 19 Aug 1993 12:48:44 -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, 19 Aug 1993 12:48:38 -0700 (PDT) Message-ID: Date: Thu, 19 Aug 1993 12:48:38 PDT Sender: Ron Frederick From: Ron Frederick To: Paul Milazzo Subject: Re: Open issue: port number assignment CC: rem-conf@es.net In-Reply-To: <1993.08.19.14.08.31.milazzo.19038@halite.bbn.com> References: <1993.08.19.14.08.31.milazzo.19038@halite.bbn.com> > A more official (and lower-numbered) port assignment would be nice. I kind of agree with the "official" part, but we don't want port numbers less than 1024 here, as that would require the applications to all run setuid root on most UNIX machines. Does IANA allow you to register well known ports above 1024? If we can register a port over 1024, it would actually be worth considering a _larger_ port number, because most UNIX machines choose transient port numbers in the range 1024..5000. While both vat and nv currently use port numbers in this range, they only do so as a default. If you're going to _require_ them to use a particular port, you should pick something that another application might not have accidently grabbed as a transient port. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Thu Aug 19 18:41:51 1993 Received: from gumby.dsd.TRW.COM by osi-east.es.net with SMTP (PP) id <00277-0@osi-east.es.net>; Thu, 19 Aug 1993 15:30:46 +0000 Received: from localhost.sp.TRW.COM by gumby.dsd.TRW.COM (4.1/SMI-4.1) id AA11476; Thu, 19 Aug 93 15:30:44 PDT Message-Id: <9308192230.AA11476@gumby.dsd.TRW.COM> To: rem-conf@es.net Subject: IMM 2.6 Date: Thu, 19 Aug 93 15:30:43 -0700 From: Dan Molinelli hi i'm trying to get IMM to view IMM beta 2.6 images via MBONE. when i receive the files, i cannot seem to get xli/xv to display. get the error: tkerror failed to handle background error. Original error: no more colors left in colormap; changing screen's color model to monochrome Error in tkerror: invalid command name: "tkerror" missing alarm ans id 0 67 sec hmm!! can anyone help! thanks dan From rem-conf-request@es.net Thu Aug 19 19:58:42 1993 Received: from relay2.UU.NET by osi-east.es.net with SMTP (PP) id <00624-0@osi-east.es.net>; Thu, 19 Aug 1993 16:48:26 +0000 Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11808; Thu, 19 Aug 93 19:48:18 -0400 Received: from lurnix.UUCP by uucp6.uu.net with UUCP/RMAIL (queueing-rmail) id 194623.22263; Thu, 19 Aug 1993 19:46:23 EDT Received: from krupke.lurnix.com by lurnix.COM (4.0/SMI-4.1) id AA06226; Thu, 19 Aug 93 14:55:51 PDT Received: from localhost by krupke.lurnix.com (4.0/SMI-4.1) id AA14963; Thu, 19 Aug 93 14:46:27 PDT Message-Id: <9308192146.AA14963@krupke.lurnix.com> To: Ron Frederick Cc: Paul Milazzo , rem-conf@es.net, gwh@lurnix.COM Subject: Re: Open issue: port number assignment In-Reply-To: Your message of "Thu, 19 Aug 93 12:48:38 PDT." Date: Thu, 19 Aug 93 14:46:26 -0700 From: gwh@lurnix.COM One good reason to use a sub-1024 port is that it'll get tracked by Merit as part of their backbone-usage statistics generation work... Though with mbone tunnels around the backbone being prevalent, it may not make a difference. You never know, though; if that sitation changes, it may make more sense to have it a low port number for tracking purposes. -george william herbert Lurnix From rem-conf-request@es.net Thu Aug 19 22:34:56 1993 Received: from viipuri.nersc.gov by osi-west.es.net with SMTP (PP) id <10543-0@osi-west.es.net>; Thu, 19 Aug 1993 19:21:00 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA08336; Thu, 19 Aug 93 19:20:58 PDT Date: Thu, 19 Aug 93 19:20:58 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9308200220.AA08336@viipuri.nersc.gov> To: rem-conf@es.net Subject: InVision Video Conf. for Windows Interop Press Release Cc: dvtf@es.net Forwarded without comment. --Ari. ----- Begin Included Message ----- >From wk05020@worldlink.com Wed Aug 18 06:02:22 1993 Date: Wed, 18 Aug 93 09:02:07 -0400 From: James Geddes To: ari@es.net, brian@lloyd.com, clint@intercon.com, drp@frontiertech.com, 100274.77@compuserve.com Cc: brian@intercon.com, bdp@cix.compulink.co.uk, wblackst@cisco.com, KUNIRSRC.DVJ@applelink.apple.com, kevine@microsoft.com, banker@hprnls1.rose.hp.com, les@lancity.com, llynnr@wco.ftp.com, maria@netmanage.com, martinh@jsbus.com, mickey@wrs.com, mpl@SATURN.SYS.ACC.COM, rouzbeh@lancity.com, h2j2@twg.com Subject: InVision Video Conf. for Windows - Interop Press Release 1 of 2 Content-Length: 3497 FOR IMMEDIATE RELEASE August 25, 1993 Contact: James Geddes InVision Systems Corp. (703) 506-0094 Tom Woolf Woolf Media Relations (415) 508-1554 InterOp Show Demonstration Highlights Versatility of InVision Windows Conferencing Technology Network Hardware, Software, and LAN/WAN Providers to Jointly Demonstrate New Windows Conferencing Technology Using InterOp Show Network SAN FRANCISCO -- At this year's InterOp 93 August exhibition, InVision Systems Corporation (formerly InterVision Systems) will be demonstrating InVision, Video Conferencing for Windows, at various sites around the show floor using the show network. Companies expected to participate in the demonstration include Beame & Whiteside Software, Ltd., LANNET, Inc., Optical Data Systems (ODS), Kalpana Inc., ALANTEC, Network Express, Inc., MFS Datanet, Inc., and Performance Systems International (PSI). The demonstration is designed to show that InVision's audio and video conferencing technology has the versatility to support virtually any standards-based networking infrastructure. InVision, Video Conferencing for Windows, consists of a CODEC (compression/ decompression) interface card, a miniature video camera, an audio accessory module, and software to add video teleconferencing capabilities to any PC workstation. Using Microsoft Windows 3.1 as the interface, InVision supports full-motion bidirectional audio-video audio signals across any conventional computer network architecture, including Ethernet, Token Ring, FDDI, and ISDN. And InVision can take full advantage of Windows's scalable images and multitasking so users can access files and data while conducting a teleconference. "InVision is the first company to get it," said Paul Callahan, Senior Analyst for Forrester Research of Cambridge, Mass. "At the desktop, video conferencing has to rely on PC LAN technology as the distribution mechanism. It's not an easy problem to solve, but that's the reality." "What InVision offers is a low-cost video conferencing solution that takes advantage of the existing LAN architecture," said Jim Geddes, President of InVision. "In all the demonstrations at this year's InterOp show, the interconnecting infrastructures may vary, but the two most important elements remain the same: PC workstations running off-the-shelf TCP/IP. These common denominators make video conferencing a cost-effective technology that is accessible to everyone, regardless of their network or their budget." Standards-based Technology To demonstrate InVision's compatibility with off-the-shelf TCP/IP implementations for the PC, Beame & Whiteside Software Ltd. will be showing InVision running over BW-TCP and BW-NFS, Beame & Whiteside's TCP/IP and NFS client software for Windows, in Booth 1814. While InVision will be conducting a Windows-based video teleconference across the show network, Beame & Whiteside will be using the same workstation to highlight new features in the latest release of its TCP/IP software, such as a new electronic mail handler that supports UNIX mail from Windows, new SL/IP functions for serial link network access, and new CD-ROM drive support. Since InVision uses TCP/IP as the transport protocol, Windows workstation users can simultaneously transfer data using the File Transfer Protocol, send electronic mail using the Simple Mail Transfer Protocol, and access other TCP/IP services at the same time they are using InVision's teleconferencing capabilities. Infrastructure Independent Other InterOp demonstrations are designed to show that InVision is compatible with any wiring infrastructure, including the new high-bandwidth switching hub systems. For example, LANNET, Inc., will be demonstrating InVision with its newly introduced LANswitch intelligent switching hub system in InterOp Booth 1310. LANswitch provides dynamically allocated bandwidth for a virtually unlimited number of video conferencing sessions with a 1.28-Gbps, ATM-ready, cell-switching backplane and dynamic switching 10BaseTV Ethernet modules. LANswitch's ASIC-based 10BaseTV modules utilize adaptation layers and congestion control techniques to prioritize audio and full-motion video data transmissions so that no packets are dropped and video is delivered smoothly to the desktop over standard Ethernet. LANswitch is an ideal technology to support a product such as InVision. In Booth 0000 InVision will be demonstrated running over ODS's Infinity Intelligent Switchable Hub system, a chassis-based connectivity solution with modular backplanes to support FDDI, Ethernet, and Token-Ring, and even the new Asynchronous Transfer Mode (ATM) technology. ODS's Infinity hub is designed to support scalable, easy-to-create network and workgroup configurations that can be integrated into a single network. These high- bandwidth network devices will show how easy it is to set up an InVision teleconference over Ethernet, FDDI, or Token-Ring architectures. ALANTEC will also be demonstrating InVision in Booth 0000 in conjunction with its PowerHub, which incorporates a new technology, IP multicast routing which was specifically developed to support multimedia applications. The IP multicast routing capability in the PowerHub makes it possible to set up point-to-multipoint data transmissions without degrading network performance by broadcasting data packets to every device on the network. One user sends traffic to the PowerHub, which in turn forwards that traffic to selected groups of users for interactive desktop applications, such as video teleconferencing. By combining InVision with IP multicast routing, it's possible to connect multiple users in a single video teleconference. In Booth 0000, InVision will also be demonstrated running over Kalpana's EtherSwitch, a high-performance Ethernet switch that creates a parallel LAN architecture to increase data throughput up to 600 times. Unlike conventional store-and-forward router systems, the EtherSwitch sets up parallel data paths that filter and forward all network traffic without losing packets. Since InVision's audio and video information are sent as conventional network packet traffic, systems such as the EtherSwitch will make it easier to set up video teleconferences without worrying about any potential impact on network bandwidth or data throughput. Wide Area Teleconferencing InVision is also compatible with wide area networking systems. In Booth 0000, for example, Network Express will be demonstrating InVision using its ISDN routing system. A PC workstation running TCP/IP and equipped with the InVision video conferencing system will be connected to an NE ISDN router, which then routes packets from LAN to LAN to set up an InVision teleconference with a remote PC workstation. A single NE ISDN Router can support up to eight simultaneous video teleconferencing sessions (at 256 Kbps each), or can provide higher quality point-to-point connections using a wider bandwidth. In Booth 0000, MFS Datanet will be demonstrating InVision with its national ATM network which currently links fourteen cities. ATM technology is hundreds of times faster than conventional communications systems since it uses a small, fixed cell size for data and high-throughput switching systems to achieve higher bandwidth connectivity. MFS executives predict that ATM infrastructures such as MFS Datanet will be ideal for graphics applications such as print media production and interactive CAD/CAM applications, and will revolutionize applications such as video teleconferencing because the infrastructure can support a greater bandwidth and faster data throughput which makes it easier to support real-time video and audio. In Booth 5776, PSI will be demonstrating InVision running over its InterFrame Service, which delivers dedicated access to the Internet at 56, 256, 384, and 512 Kbps. Among other applications, InterFrame can support Internet packet video technology. PSI's InterFrame is supported by a new multi-tier backbone that integrates cell-based switching, Frame Relay link-level access, and state-of-the-art router technology. Using InterFrame as a network infrastructure, InVision can be used to set up Windows-based teleconference sessions between any two users on the Internet. "InterOp is the ideal forum to showcase the power and compatibility of InVision," said Geddes. "InterOp has traditionally been used to showcase how new standards-based technologies work together, and it gives us an opportunity to show that there are still new applications for established standards such as TCP/IP protocols. It also lets us demonstrate how different local and wide area network technologies can readily support PC-based teleconferencing. Attendees know that if new technology will run on the InterOp show network, it will certainly work on their own networks." InVision is compatible with all off-the-shelf network adapters and a wide variety of network drivers. As part of its interface, InVision includes an on- screen "mute" button and adjustable volume, contrast, brightness, and tint controls. It also has a Video Capture function to capture single image frames and multiple frames to disk. InVision is also compatible with any TCP/IP networking system for the PC, and has been thoroughly tested with TCP/IP solutions from Beame & Whiteside, NetManage, Microsoft, The Wollongong Group, FTP Software, Frontier Technology, and other vendors.It has an adjustable transmission rate so information can be sent at 256, 384, or 512 Kbps, to optimize the network load. InVision can also generate from 10-22 frames-per-second. The InVision Performance System Kit is also available with Intel's more powerful Codec board, the Action-Media 2, and is priced at $3,395. The product first began shipping to customers in June. InVision Systems Corporation specializes in developing and marketing video teleconferencing technology for computer networks. InVision Systems is located at 8500 Leesburg Pike, Suite 300, Vienna, VA 22182; telephone (703) 506-0094; FAX: (703) 506-0098; electronic mail: CompuServe 72002,1677; Internet WK05020@worldlink.com. -30- InVision, Video Teleconferencing for Windows is a trademark of InVision Systems Corporation. All other trademarks are the property of their respective owners. ----- End Included Message ----- From rem-conf-request@es.net Fri Aug 20 05:01:52 1993 Received: from venera.isi.edu by osi-east.es.net with SMTP (PP) id <02602-0@osi-east.es.net>; Fri, 20 Aug 1993 01:54:29 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Fri, 20 Aug 1993 01:54:25 -0700 Posted-Date: Fri 20 Aug 93 01:53:45-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 20 Aug 93 01:53:46 PDT Date: Fri 20 Aug 93 01:53:45-PDT From: Stephen Casner Subject: Re: New AVT RTP drafts (protocol name) To: mankin@sparky.cmf.nrl.navy.mil, casner@ISI.EDU Cc: rem-conf@es.net Message-Id: <745836825.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9308181956.AA23912@sparky.cmf.nrl.navy.mil> Mail-System-Version: Allison, You make a good point that RTP does not by itself implement "real-time delivery". It is more that the protocol is intended for applications that want real-time delivery. So, it could be named "Transport Protocol for Realtime Applications (TPRA). But I think all of these alternative suggestions are quite a bit more clumsy than RTP. I guess I'd be inclined not to change the name. -- Steve ------- From rem-conf-request@es.net Fri Aug 20 05:25:15 1993 Received: from venera.isi.edu by osi-east.es.net with SMTP (PP) id <02659-0@osi-east.es.net>; Fri, 20 Aug 1993 02:18:24 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Fri, 20 Aug 1993 02:18:21 -0700 Posted-Date: Fri 20 Aug 93 02:17:41-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 20 Aug 93 02:17:42 PDT Date: Fri 20 Aug 93 02:17:41-PDT From: Stephen Casner Subject: Re: Open issue: port number assignment To: rem-conf@es.net Message-Id: <745838261.0.CASNER@XFR.ISI.EDU> In-Reply-To: Mail-System-Version: Henning cited two advantages for fixed assignments of port numbers: - we can get traffic statistics, giving some indication of RTP usage - firewall implementations are simplified There are a couple of other reasons one might want fixed assignments, if they could be registered: - A problem with dynamic assignments is that there might already be some other process on your machine that has taken the port number for another purpose, preventing you from participating in a session. This would even be true for randomly assigned ports in the 5-digit part of the space. Unfortunately, the only range over which there is some assurance that ports won't be otherwise used is in the "priviledged" range, and as Ron says, we don't want the programs to have to run as root which would be required on UNIX machines to use those ports. - If we could always use a fixed port, then each profile could be assigned a different port number, allowing programs that can operate under multiple profiles to know which profile to use. But there are also problems with a fixed port assignment. In addition to those already mentioned: - When using unicast addressing, one needs to use different port numbers for to allow multiple copies of the application. [One could use the same port and different FlowIDs (channel IDs), but then all copies of the application would receive all packets and have to throw away the ones that didn't belong.] - If your kernel doesn't have the in_pcb fix, you can't bind to multicast addresses which creates the same problem as for unicast. - IANA is reluctant to register too many port numbers. I don't know how many profiles there might be. So, it looks like a port number assignment that we might make in the profile can only be a suggestion. -- Steve ------- From rem-conf-request@es.net Fri Aug 20 06:50:44 1993 Received: from itd.nrl.navy.mil by osi-east.es.net with SMTP (PP) id <02871-0@osi-east.es.net>; Fri, 20 Aug 1993 03:44:02 +0000 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA25166; Fri, 20 Aug 93 06:44:00 EDT Date: Fri, 20 Aug 93 06:44:00 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9308201044.AA25166@itd.nrl.navy.mil> To: rem-conf@es.net Subject: port number assignments I must be missing something here. I understand about the issue of "privileged" ports on many systems, but why couldn't there be a tiny trusted daemon that listens on the privileged port(s) and then lets any old person connect to the RTP-based service via this tiny trusted daemon process ?? It should be straight-forward to write such a tiny trusted daemon and it would be very worthwhile to be able to use a registered low-order port number. I'm probably more security conscious than the average person on the Internet and I really don't see this as a security problem. The other, slightly more radical suggestion, would be to change RTP slightly to run directly over IP and have its own port number space. This would have the disadvantage of being slightly harder to get widely deployed, but would have the advantage of no port conflicts with existing services and the decoupling of transport protocols might be nice to have in the future. Regards, Ran atkinson@itd.nrl.navy.mil From rem-conf-request@es.net Fri Aug 20 13:08:42 1993 Received: from sics.se by osi-east.es.net with SMTP (PP) id <04703-0@osi-east.es.net>; Fri, 20 Aug 1993 10:02:54 +0000 Received: from inetmacip4.inet93.net by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA10227; Fri, 20 Aug 93 19:02:42 +0200 Message-Id: <9308201702.AA10227@sics.se> Date: Fri, 20 Aug 1993 10:03:31 -0700 To: Stephen Casner , rem-conf@es.net From: hans@sics.se (Hans Eriksson) X-Sender: hans@sics.se (Unverified) Subject: Re: Open issue: port number assignment Maybe I am missing something (and should re-read the profile spec again), but whatabout when you participate in several conferences. Will they only have separate flowIDs? In my world I saw also different ports for different conferences, so I do not see the need for any "default" port. Maybe a default for the MBone Audio, but not for a specific flowID. Going back to Hennings reasons, I see firewalls for specific _conferences_, not for all RTP traffic. Or am I confusing profiles and flowIDs? /hans From rem-conf-request@es.net Fri Aug 20 13:15:04 1993 Received: from venera.isi.edu by osi-east.es.net with SMTP (PP) id <04736-0@osi-east.es.net>; Fri, 20 Aug 1993 10:09:00 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Fri, 20 Aug 1993 10:08:57 -0700 Posted-Date: Fri 20 Aug 93 10:08:17-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Fri, 20 Aug 93 10:08:18 PDT Date: Fri 20 Aug 93 10:08:17-PDT From: Stephen Casner Subject: Re: Open issue: port number assignment To: hans@sics.se, CASNER@ISI.EDU, rem-conf@es.net Message-Id: <745866497.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9308201702.AA10227@sics.se> Mail-System-Version: Hans, The port number can only be constant if we assume that the conferences are differentiated by different multicast addresses. (The flowID might be used for multiplexing within a conference.) Hence, when unicast addresses are used, we can't assume the constant port number. -- Steve ------- From rem-conf-request@es.net Fri Aug 20 13:28:30 1993 Received: from alpha.Xerox.COM by osi-east.es.net with SMTP (PP) id <04867-0@osi-east.es.net>; Fri, 20 Aug 1993 10:27:52 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11669>; Fri, 20 Aug 1993 10:27:32 PDT Received: by ecco.parc.xerox.com id <16136>; Fri, 20 Aug 1993 10:27:25 -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; Fri, 20 Aug 1993 10:27:19 -0700 (PDT) Message-ID: Date: Fri, 20 Aug 1993 10:27:19 PDT Sender: Ron Frederick From: Ron Frederick To: Stephen Casner Subject: Re: Open issue: port number assignment CC: rem-conf@es.net In-Reply-To: <745838261.0.CASNER@XFR.ISI.EDU> References: <745838261.0.CASNER@XFR.ISI.EDU> Steve Casner writes: > - A problem with dynamic assignments is that there might already be > some other process on your machine that has taken the port number > for another purpose, preventing you from participating in a session. > This would even be true for randomly assigned ports in the 5-digit > part of the space. While technically this is true, the only way that a port number would already be in use for ports >5000 on UNIX machines is if some other application had hardcoded it, or had its own random selection algorithm and didn't rely on the kernel. I'm sure there _are_ such applications out there, but it has become pretty common practice to ignore this. X11, for example, uses port 6000 (or 6000+x, for small x). > - When using unicast addressing, one needs to use different port > numbers for to allow multiple copies of the application. [One could > use the same port and different FlowIDs (channel IDs), but then all > copies of the application would receive all packets and have to > throw away the ones that didn't belong.] If we do the general unicast case the way we do unicast backchannel in the multicast case, then this is less of a problem. The real reason for wanting a well known port is mostly that multicast applications REQUIRE one to work at all, and assuming that you can randomly pick a port number for a conference and get it on ALL the machines you might want to participate from at any given moment is a dangerous assumption. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Fri Aug 20 13:41:28 1993 Received: from sadye.emba.uvm.edu by osi-east.es.net with SMTP (PP) id <04981-0@osi-east.es.net>; Fri, 20 Aug 1993 10:40:13 +0000 Received: by sadye.emba.uvm.edu id AA02439 (5.65/1.23); Fri, 20 Aug 93 13:39:50 -0400 Date: Fri, 20 Aug 93 13:39:50 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9308201739.AA02439@sadye.emba.uvm.edu> To: Stephen Casner Cc: casner@ISI.EDU, mankin@sparky.cmf.nrl.navy.mil, rem-conf@es.net Subject: Re: New AVT RTP drafts (protocol name) In-Reply-To: <745836825.0.CASNER@XFR.ISI.EDU> References: <745836825.0.CASNER@XFR.ISI.EDU> <9308181956.AA23912@sparky.cmf.nrl.navy.mil> < said: > So, it could be named "Transport Protocol for Realtime Applications > (TPRA). But I think all of these alternative suggestions are quite > a bit more clumsy than RTP. I guess I'd be inclined not to change > the name. So keep the acronym and change the expansion. If INTERCAL stands for ``Compiler Language with No Pronounceable Acronym'', certainly RTP can stand for ``Transport Protocol for Realtime Applications''... Only half a :-) . -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From rem-conf-request@es.net Fri Aug 20 17:15:47 1993 Received: from zephyr.isi.edu by osi-east.es.net with SMTP (PP) id <06751-0@osi-east.es.net>; Fri, 20 Aug 1993 14:09:54 +0000 Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Fri, 20 Aug 1993 14:09:52 -0700 Date: Fri, 20 Aug 1993 14:09:52 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199308202109.AA21423@zephyr.isi.edu> To: rem-conf@es.net Subject: query about nv_recrod Cc: braden@ISI.EDU Yesterday I tried using Anders Klements' programs to record nv and vat from the PARC Forum. The vat stream plays back fine, but the nv playback dies almost immediately with the message "wrong version of recording". Can someone shed some light on this for me? Thanks, Bob Braden From rem-conf-request@es.net Fri Aug 20 22:57:09 1993 Received: from research.att.com by osi-east.es.net with SMTP (PP) id <08099-0@osi-east.es.net>; Fri, 20 Aug 1993 19:52:07 +0000 Received: by inet; Fri Aug 20 22:51 EDT 1993 Date: Fri, 20 Aug 93 22:51:37 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: rem-conf@es.net Subject: RTP use scenario As suggested by Ross Finlayson, I have written up a section on some RTP use scenarios, covering the basic operation and the more confusing aspects such as bridges and translators. Since this is meant for a general audience, I'm posting a first rough draft here for review. Please suggest additions, changes and clarifications. The intention is to give a general flavor, ie., some view of the forest before the describing the bark on the trees. \section{RTP Protocol Use Scenarios} The following sections describe some aspect of the use of RTP. The examples were chosen to illustrate the basic operation of applications using RTP, not to circumscribe what RTP may be used for. \subsection{Simple Multicast Audio Conference} A working group of the IETF meets to discuss the latest protocol draft, using the multicasting services of the Internet for voice communications. Through some allocation mechanism, the working group chair obtains a multicast group address and decides on a common UDP port. The multicast address and port are distributed, say, by electronic mail, to all intended participants. (The mechanisms for discovering available multicast addresses and distributing the information to participants are beyond the scope of RTP.) By virtue of being a datagram network, the Internet can reorder packets and delays them be variable amounts. The audio conferencing application at each conference participant sends audio data in small chunks of about 20 ms duration, each in one UDP packet, wrapped into the RTP header. The RTP header contains timing information and a sequence number that allows the receivers to reconstruct the timing seen by the source. The sequence number can also be used by the receiver to estimate how many packets are being lost. Since RTP is an end-to-end protocol and resides ``above'' IP and UDP, it does not affect datagram processing at intermediate nodes and thus cannot improve how these intermediate nodes treat voice packets. Each RTP packet also indicates what type of audio encoding (such as PCM, ADPCM or GSM) is being used, so that the encoding can be changed on the fly, for example, to accomodate a new participant that is connected through a low-bandwidth link. Since members of the working group join and leave the conference, it is useful to know who is participating at any moment. For that purpose, each audio application periodically multicasts the name, email address and other information. Such control information is carried as options within RTP messages, with or without audio data. The site information such as name is contained in SDES options. This control information is called the real-time control protocol (RTCP). These periodic messages also provide some indication as to whether the network connection is still functioning. A site sends the RTCP BYE message when it is leaving a conference. The QOS message indicates how well the current speaker is being received. \subsection{Bridges} So far, the example has assumed that all sites want to receive audio data in the same format. However, this may not always be appropriate. Consider the case where some listeners are connected through a low-speed link, but the majority of conference participants have high-speed links available to them. Consider a conference held in the United States, with some European participants as an example. Instead of forcing everybody to use a lower-bandwidth, reduced-quality encoding, a ``bridge'' is placed near the Atlantic crossing. The bridge mixes all incoming audio packets, translates the audio encoding and forwards the new packet to the European sites. After the mixing, the identity of a US site speaking can no longer be determined from the network origin of the packet. Thus, the bridge inserts a list of short site identifiers into the packet indicating which sites ``contributed'' to that mixed packet (CSRC option). Through SDES options, the bridge periodically provides a mapping from the short identifiers to more meaningful identifiers, such as name and location, as received from the SDES messages of the US sites. \subsection{Translators} Not all sites are directly accessible through Internet multicast or, indeed, the Internet. For these sites, mixing is not necessary, but a translation of the underlying transport protocol. Application gateways that do not restore timing or mix packets from different sources are called {\em translators} in this document. Application-level firewalls, for example, will not let IP packets pass, only UDP packets with a given port number. Two translators are installed, one on either side of the firewall, the outside one funneling all multicast packets received through a single UDP port, the inside one sending them again as multicast packets. After RTP packets have passed through a translator, they all, naturally, have the same network source address, making it impossible for the receiver to distinguish packets from different speakers. Since each sending site has its own sequence number space and slightly offset timestamp space, the receiver could not properly mix the audio packets. (For video, it could not properly separate them into distinct displays.) Instead of forcing all senders to include some globally unique identifier in each packet, a translator inserts a short synchronization source (SSRC) identifier that uniquely identifies each source. This also works if an RTP packet has to travel through several translators, with the SSRC value being mapped into a new unique value at each translator. An example is shown in Fig.~\ref{fig:map}, where hosts palm and teak are translators. For example, the RTP packets from host date are identified with SSRC value 2, while those coming from bridge coca are labeled with SSRC value one. Similarly, translator teak labels packets from elm, palm, coca and pine with SSRC values 6, 5, 3 and 4, respectively (or some other unique values). \subsection{Security} Conference participants would often like to ensure that nobody else can listen to their deliberations. Encryption, indicated by the presence of the ENC option, provides that privacy. The encryption method and key can be changed during the conference by indexing into a table. For authentication, a number of methods are provided, depending on needs and computational capabilities. All compute cryptographic checksums over the RTP data. (MIC* options) [ash] | ash/17 | teak/63/6 V coca/48 (1,2) palm/28/1 (1,2) teak/63/5 (1,2) (coca)-------------->----------------->-------------->[oak] I I palm/28/2 I teak/63/3 bay/1 | date/47 | | teak/63/4 (1,4) | | | [bay] [date] | | [fir] --------->(mate)---------->(pine)------------| fir/64 mate/12 (3) I | bee/45 | [bee] [end system] source host/source port/SSRC (CSRC, ...) (bridge) ---------------------------------------> From rem-conf-request@es.net Sat Aug 21 13:47:19 1993 Received: from faui45.informatik.uni-erlangen.de by osi-east.es.net with SMTP (PP) id <09545-0@osi-east.es.net>; Sat, 21 Aug 1993 10:42:14 +0000 Received: from faui43.informatik.uni-erlangen.de by uni-erlangen.de with SMTP; id AA27649 (5.65c-5/7.3v-FAU); Sat, 21 Aug 1993 19:42:02 +0200 Received: from faui45r.informatik.uni-erlangen.de by immd4.informatik.uni-erlangen.de with SMTP; id AA03364 (5.65c-5/7.3m-FAU); Sat, 21 Aug 1993 19:42:17 +0200 From: Toerless Eckert Message-Id: <199308211742.AA03364@faui43.informatik.uni-erlangen.de> Subject: Re: query about nv_recrod To: braden@ISI.EDU Date: Sat, 21 Aug 93 19:38:22 MET DST Cc: rem-conf@es.net In-Reply-To: <199308202109.AA21423@zephyr.isi.edu>; from "rem-conf-request@es.net" at Aug 20, 93 11:09 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.3 PL11] > Yesterday I tried using Anders Klements' programs to record nv and vat > from the PARC Forum. The vat stream plays back fine, but the nv playback > dies almost immediately with the message "wrong version of recording". > Can someone shed some light on this for me? No idea. Yust delete the "if" statement leading to this error message and it plays fine (at least it did play fine for me ;-)). On he other hand: Is it a local problem with me, or was the audio part of the transmission, especially in the second half mixed with a loud buzz ? i.e.: It was often very difficult to understand the speaker. Toerless From rem-conf-request@es.net Sat Aug 21 15:10:16 1993 Received: from odin.ucsd.edu by osi-east.es.net with SMTP (PP) id <09651-0@osi-east.es.net>; Sat, 21 Aug 1993 12:04:35 +0000 Received: from kailas.ucsd.edu by odin.ucsd.edu; id AA12490 sendmail 5.67/UCSDPSEUDO.4-CS via SMTP Sat, 21 Aug 93 09:28:22 -0700 for rem-conf@es.net Received: by kailas (5.67/UCSDPSEUDO.4) id AA17512 for vin@cs.utexas.edu; Sat, 21 Aug 93 07:58:35 -0700 Date: Sat, 21 Aug 93 07:58:35 -0700 From: mm@cs.ucsd.edu (Multimedia Project) Message-Id: <9308211458.AA17512@kailas> To: mm-announcement-list@cs.ucsd.edu Subject: Call for Papers ***************************************************************** * CALL FOR PAPERS for a special issue of * * ACM/Springer-Verlag MULTIMEDIA SYSTEMS journal * ***************************************************************** Content analysis and understanding is an emerging area of multimedia research. Multimedia database applications are ready to leapfrog from handling simple BLOBS to retrieving information based on content understanding. The Multimedia Systems journal identifies this area to be of significant research topic and invites original, unpublished contributions highlighting the issues, research results or applications in the area of CONTENT BASED RETRIEVAL. Papers should be submitted by February 1, 1994 to the special issue editor at the following address; A. Desai Narasimhalu Institute of Systems Science National University of Singapore Heng Mui Keng Terrace Singapore 0511 email: desai@iss.nus.sg fax: +65 7782571 The special issue will come out towards the 3Q of 1994. From rem-conf-request@es.net Sat Aug 21 16:17:27 1993 Received: from venera.isi.edu by osi-east.es.net with SMTP (PP) id <09725-0@osi-east.es.net>; Sat, 21 Aug 1993 13:12:26 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Sat, 21 Aug 1993 13:12:20 -0700 Posted-Date: Sat 21 Aug 93 13:11:39-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sat, 21 Aug 93 13:11:40 PDT Date: Sat 21 Aug 93 13:11:39-PDT From: Stephen Casner Subject: Re: query about nv_recrod To: Toerless.Eckert@informatik.uni-erlangen.de, braden@ISI.EDU Cc: rem-conf@es.net Message-Id: <745963899.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199308211742.AA03364@faui43.informatik.uni-erlangen.de> Mail-System-Version: Toerless, The loud buzz was a local (analog) audio problem. We all heard it live as well. -- Steve ------- From rem-conf-request@es.net Mon Aug 23 07:03:06 1993 Received: from venera.isi.edu by osi-east.es.net with SMTP (PP) id <13989-0@osi-east.es.net>; Mon, 23 Aug 1993 03:49:49 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Sun, 22 Aug 1993 23:52:28 -0700 Posted-Date: Sun 22 Aug 93 23:49:00-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Sun, 22 Aug 93 23:49:02 PDT Date: Sun 22 Aug 93 23:49:00-PDT From: Stephen Casner Subject: Re: New AVT RTP drafts (protocol name) To: wollman@uvm-gen.emba.uvm.edu Cc: rem-conf@es.net Message-Id: <746088540.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9308201739.AA02439@sadye.emba.uvm.edu> Mail-System-Version: > So keep the acronym and change the expansion. If INTERCAL stands for > ``Compiler Language with No Pronounceable Acronym'', certainly RTP can > stand for ``Transport Protocol for Realtime Applications''... > Only half a :-) . In fact, that was the title on several drafts July 14 and earlier. -- Steve ------- From rem-conf-request@es.net Tue Aug 24 13:37:22 1993 Received: from alpha.Xerox.COM by osi-east.es.net with SMTP (PP) id <23459-0@osi-east.es.net>; Tue, 24 Aug 1993 10:30:32 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11733>; Tue, 24 Aug 1993 10:30:07 PDT Received: by ecco.parc.xerox.com id <16136>; Tue, 24 Aug 1993 10:29:56 -0700 Received: from Messages.7.15.N.CUILIB.3.45.SNAP.NOT.LINKED.ecco.parc.xerox.com.sun4.41 via MS.5.6.ecco.parc.xerox.com.sun4_41; Tue, 24 Aug 1993 10:29:43 -0700 (PDT) Message-ID: Date: Tue, 24 Aug 1993 10:29:43 PDT Sender: Ron Frederick From: Ron Frederick To: "Larry J. Blunk" Subject: Re: a strange problem with nv 3.2 CC: rem-conf@es.net In-Reply-To: <9308241506.AA07977@merit.edu> References: <9308241506.AA07977@merit.edu> > Unfortunately, nv is statically linked. So if you have a modified > lib.c.so which uses DNS, nv won't make use of it. You'll have to > add the host to /etc/hosts. It's true that nv is statically linked and won't use a modified libc.so... This is one of those obnoxious problems where dynamically linking breaks half the people in the world, and statically linking breaks the other half. In the future, I'll probably do what vat has started to do and provide two different binaries (sigh)... It is _not_ true that you need to add things to /etc/hosts. I linked against the standard SunOS libc, which expects you to be using NIS. If you have a NIS server, that server can be configured to do DNS for you, and in that case everything works nicely. It's only when you are not running NIS that this statically linked nv will have problems. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Tue Aug 24 16:32:58 1993 Received: from SKIGO.GRAPHICS.CORNELL.EDU by osi-east.es.net with SMTP (PP) id <25518-0@osi-east.es.net>; Tue, 24 Aug 1993 13:26:23 +0000 Received: by skigo.graphics.cornell.edu (5.65/DEC-Ultrix/4.3) id AA10633; Tue, 24 Aug 1993 16:26:04 -0400 Message-Id: <9308242026.AA10633@skigo.graphics.cornell.edu> To: Ron Frederick Cc: rem-conf@es.net, mkc@graphics.cornell.edu Subject: Re: a strange problem with nv 3.2 In-Reply-To: Your message of "Tue, 24 Aug 93 10:29:43 PDT." Date: Tue, 24 Aug 93 16:26:04 -0400 From: Mitch Collinsworth X-Mts: smtp >It is _not_ true that you need to add things to /etc/hosts. I linked against >the standard SunOS libc, which expects you to be using NIS. If you have >a NIS server, that server can be configured to do DNS for you, and in that >case everything works nicely. It's only when you are not running NIS >that this statically linked nv will have problems. Well, correct me if I'm wrong (read: I think I know what I'm talking about but can never be quite sure if computers are involved), but I am under the impression that a NIS server can be configured to do DNS for you *only* if it is a Sun. If this is not the case I would really like to know because my NIS servers are Ultrix and I've been under the impression that I have to build a new shared C library on the Suns I recently added as NIS clients so they can do DNS resolution with a local resolver. -Mitch Collinsworth mitch@graphics.cornell.edu From rem-conf-request@es.net Wed Aug 25 13:18:27 1993 Received: from bnl.gov by osi-east.es.net with SMTP (PP) id <02261-0@osi-east.es.net>; Wed, 25 Aug 1993 10:11:09 +0000 Received: by bnl.gov (5.57/Ultrix3.0-C) id AA14638; Wed, 25 Aug 93 13:11:06 -0400 Received: by maeva.ccd.bnl.gov.ccd.bnl.gov (5.0/SMI-SVR4) id AA02297; Wed, 25 Aug 93 13:10:59 EDT Date: Wed, 25 Aug 93 13:10:59 EDT From: gc@maeva.ccd.bnl.gov (Graham Campbell) Message-Id: <9308251710.AA02297@maeva.ccd.bnl.gov.ccd.bnl.gov> To: rem-conf@es.net Subject: Color reproduction X-Sun-Charset: US-ASCII Content-Length: 688 I have just installed nv et al. on a colleague's workstation. In the process of doing this I displayed his windows on my workstation so I had a side by side comparison of the video image. The image from his workstation had a definite greenish hue that was not present in the local image. I then displayed the image from yet another system and it was essentially indistinguishable from the local image. Anyone have any ideas why? Details: The local system is an IPC with a Videopix board and NCK camera, running Solaris 2.2. The other system with a comparable image is an LX system also running Solaris 2.2. The system with the greenish image is an IPC running SunOS 4.1.2. Graham From rem-conf-request@es.net Wed Aug 25 14:58:51 1993 Received: from alpha.Xerox.COM by osi-east.es.net with SMTP (PP) id <03495-0@osi-east.es.net>; Wed, 25 Aug 1993 11:52:20 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <11964>; Wed, 25 Aug 1993 11:51:33 PDT Received: by ecco.parc.xerox.com id <16136>; Wed, 25 Aug 1993 11:51:23 -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, 25 Aug 1993 11:51:16 -0700 (PDT) Message-ID: <4gSvGYwB0bH403mWkE@ecco.parc.xerox.com> Date: Wed, 25 Aug 1993 11:51:16 PDT Sender: Ron Frederick From: Ron Frederick To: gc@maeva.ccd.bnl.gov (Graham Campbell) Subject: Re: Color reproduction CC: rem-conf@es.net In-Reply-To: <9308251710.AA02297@maeva.ccd.bnl.gov.ccd.bnl.gov> References: <9308251710.AA02297@maeva.ccd.bnl.gov.ccd.bnl.gov> > I have just installed nv et al. on a colleague's workstation. In the > process of doing this I displayed his windows on my workstation so I > had a side by side comparison of the video image. The image from his > workstation had a definite greenish hue that was not present in the > local image. I then displayed the image from yet another system and it > was essentially indistinguishable from the local image. Anyone have > any ideas why? For about a week, there was a version of nv 3.2 for the SPARCs on the ftp site which did have a bug in the dithering, causing it to add too much green. Try grabbing a new copy, and seeing if that makes the problem go away... I should have changed the version number, but it was a minor enough bug that I didn't bother... -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Aug 25 19:46:44 1993 Received: from alpha.Xerox.COM by osi-east.es.net with SMTP (PP) id <05982-0@osi-east.es.net>; Wed, 25 Aug 1993 16:39:49 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <12353>; Wed, 25 Aug 1993 16:39:25 PDT Received: by ecco.parc.xerox.com id <16136>; Wed, 25 Aug 1993 16:39:18 -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, 25 Aug 1993 16:39:16 -0700 (PDT) Message-ID: Date: Wed, 25 Aug 1993 16:39:16 PDT Sender: Ron Frederick From: Ron Frederick To: Mitch Collinsworth Subject: Re: a strange problem with nv 3.2 CC: rem-conf@es.net In-Reply-To: <9308242026.AA10633@skigo.graphics.cornell.edu> References: <9308242026.AA10633@skigo.graphics.cornell.edu> > Well, correct me if I'm wrong (read: I think I know what I'm talking > about but can never be quite sure if computers are involved), but I am > under the impression that a NIS server can be configured to do DNS for > you *only* if it is a Sun. If this is not the case I would really like to > know because my NIS servers are Ultrix and I've been under the > impression that I have to build a new shared C library on the Suns I > recently added as NIS clients so they can do DNS resolution with a local > resolver. I must admit that I'm not familiar with the NIS server on other platforms like Ultrix, so I don't know how they address this issue. It would certainly be pretty trivial to have the NIS server do DNS, but I'm not sure if that's how they are shipped or not. -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Aug 25 19:52:50 1993 Received: from alpha.Xerox.COM by osi-east.es.net with SMTP (PP) id <06013-0@osi-east.es.net>; Wed, 25 Aug 1993 16:46:34 +0000 Received: from ecco.parc.xerox.com ([13.2.116.196]) by alpha.xerox.com with SMTP id <12273>; Wed, 25 Aug 1993 16:46:17 PDT Received: by ecco.parc.xerox.com id <16136>; Wed, 25 Aug 1993 16:46:10 -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, 25 Aug 1993 16:46:04 -0700 (PDT) Message-ID: Date: Wed, 25 Aug 1993 16:46:04 PDT Sender: Ron Frederick From: Ron Frederick To: rem-conf@es.net Subject: Clarification on port number issue My previous message to about the port number issue might have been a bit confusing, so here's a short clarification: The point I was really making was that the notion of choosing a _well known_ port number in the >1024 space, as long as we pick something in the >5000 space, is not all that difficult. We can get other applications in the world to pretty much stay out of our way, as X has with port 6000. This is _very_ different than saying that we can get away with sd picking a random port number for every new session and expecting at that moment in time all the hosts in the world which might want to join the session will have that port free... -- Ron Frederick frederick@parc.xerox.com From rem-conf-request@es.net Wed Aug 25 20:43:36 1993 Received: from tadpole.Tadpole.COM by osi-east.es.net with SMTP (PP) id <06556-0@osi-east.es.net>; Wed, 25 Aug 1993 17:36:40 +0000 Received: by tadpole.Tadpole.COM (4.1/SMI-4.1) id AA01065; Wed, 25 Aug 93 19:36:15 CDT Date: Wed, 25 Aug 93 19:36:15 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9308260036.AA01065@tadpole.Tadpole.COM> To: frederic@parc.xerox.com, mkc@graphics.cornell.edu Subject: Re: a strange problem with nv 3.2 Cc: rem-conf@es.net Ultrix deals with the DNS in much the same way that resolve-2.1 and Solaris 2 do. They call the appropriate routine (NIS/DNS/...) from within the gethostby*() routine. Jim From rem-conf-request@es.net Wed Aug 25 21:43:08 1993 Received: from brolga.cc.uq.oz.au by osi-east.es.net with SMTP (PP) id <06858-0@osi-east.es.net>; Wed, 25 Aug 1993 18:34:36 +0000 Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Thu, 26 Aug 1993 11:34:04 +1000 To: jim@tadpole.com (Jim Thompson) cc: frederic@parc.xerox.com, mkc@graphics.cornell.edu, rem-conf@es.net Subject: Re: a strange problem with nv 3.2 In-reply-to: Your message of "Wed, 25 Aug 1993 19:36:15 CDT." <9308260036.AA01065@tadpole.Tadpole.COM> Date: Thu, 26 Aug 1993 11:34:01 +1000 Message-ID: <11759.746328841@brolga.cc.uq.oz.au> From: George Michaelson Ultrix system config defines a switcher to pick the order of lookup from DNS, NIS and /etc/hosts which applies system-wide to all (statically linked of course, you have no choice!) binaries. Since the libc.a you link against does this embedded under the gethost/getsrv calls, its just not a problem. This is only an issue on Suns since so many of us don't run NIS and munging NIS makefiles to enable DNS seems a waste when a modified shared lib gets you direct DNS. -George From rem-conf-request@es.net Wed Aug 25 22:23:02 1993 Received: from research.att.com by osi-east.es.net with SMTP (PP) id <07012-0@osi-east.es.net>; Wed, 25 Aug 1993 19:14:04 +0000 Received: by inet; Wed Aug 25 22:13 EDT 1993 Date: Wed, 25 Aug 93 22:13:22 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: rem-conf@es.net Subject: Port assignment Cc: casner@isi.edu, frederic@parc.xerox.com As far as I can tell, we seem to have reached general agreement on the issue of port assignment for MULTICAST RTP use. (For unicast, a fixed assignment can only work as long as only, say, one audio and video connection is in use concurrently.) Several reasons have been put forth, roughly in order of importance: 1) random assignment risks choosing a number that is already in use by another application on a potential conference participant 2) random assignment makes it more difficult to detect if a host is the unwitting receiver of unsolicited multicast traffic (with the same multicast group, but different port number) 3) a fixed port number eases the keeping of service statistics by Merit and gateways; right now, IP-over-IP serves as a rough indicator, but this ceases to work as native multicast becomes popular and/or IP-over-IP is used for other purposes (e.g., tunneling IPng) 4) fixed port numbers may simplify carrying RTP through firewalls (not too convinced of that, though, except for unicast) There remains the issue of which number to choose. Only the range above 1024 is feasible if we want to avoid using a privileged Unix port (a stub server relaying packets to the user-level process appears to create too much host overhead for real-time applications). The range through 5000 is subject to random assignment, leaving the range above 5000. (It is curious to note, btw, that port 6000+ for X11 does not show up in RFC 1340.) Merit does track selected services with numbers above 5000 (X11, in particular), so that choice does not threaten advantage 3, assuming RTP-directly-over IP does contribute a significant fraction of the traffic. My suggestion would be to follow the X11 example and use a small range of numbers, for example 5003 and up (only because 5002 is radio free ethernet). Other services seem to have no problems grabbing ten or so portnumbers (see afs3 from 7000 on up). If we assume that by the time RTP goes to standard, we can get system vendors to support multicast-specific bind (there is enough participation by the major workstation manufacturers in this group, it seems), a single port number would suffice and would offer the distinct advantage of very easy collision detection, statistics and configuration. Thus, my suggestion: 'claim' a range of numbers, with preference to the lowest one and others to be used for unicast or special circumstances. Possible ranges: 5003+ (since Radio Free Ethernet, another multimedia application, has 5002) or 8000+ (the first real round port number not yet taken). Comments? Henning Schulzrinne AT&T Bell Laboratories From rem-conf-request@es.net Wed Aug 25 23:05:16 1993 Received: from dmssyd.syd.dms.CSIRO.AU by osi-east.es.net with SMTP (PP) id <07082-0@osi-east.es.net>; Wed, 25 Aug 1993 19:55:57 +0000 Received: from drugs.syd.dms.CSIRO.AU by dmssyd.syd.dms.CSIRO.AU (4.1/5.17) id AA29462; Thu, 26 Aug 93 12:53:07 EST (from marka@syd.dms.csiro.au (Mark Andrews)) Message-Id: <9308260253.AA29462@dmssyd.syd.dms.CSIRO.AU> To: George Michaelson Cc: jim@tadpole.com (Jim Thompson), frederic@parc.xerox.com, mkc@graphics.cornell.edu, rem-conf@es.net Subject: Re: a strange problem with nv 3.2 In-Reply-To: Your message of "Thu, 26 Aug 1993 11:34:01 +1000." <11759.746328841@brolga.cc.uq.oz.au> Date: Thu, 26 Aug 1993 12:52:42 +1000 From: Mark Andrews > > Ultrix system config defines a switcher to pick the order of lookup from > DNS, NIS and /etc/hosts which applies system-wide to all (statically linked > of course, you have no choice!) binaries. Since the libc.a you link against > does this embedded under the gethost/getsrv calls, its just not a problem. > > This is only an issue on Suns since so many of us don't run NIS and munging > NIS makefiles to enable DNS seems a waste when a modified shared lib gets you > > direct DNS. > > -George > And it is easy enough to get a binary that only has the libc shared. e.g. cc -o foo foo.c -Bstatic -lXt -lX11 -Bdynamic Mark. -- Mark Andrews, CSIRO Div Maths & Stats Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au UUCP: ....!uunet!syd.dms.csiro.au!marka From rem-conf-request@es.net Thu Aug 26 04:26:40 1993 Received: from venera.isi.edu by osi-east.es.net with SMTP (PP) id <07902-0@osi-east.es.net>; Thu, 26 Aug 1993 01:25:49 +0000 Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-13) id ; Thu, 26 Aug 1993 01:25:14 -0700 Posted-Date: Thu 26 Aug 93 01:24:33-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Thu, 26 Aug 93 01:24:34 PDT Date: Thu 26 Aug 93 01:24:33-PDT From: Stephen Casner Subject: Re: Port assignment To: hgs@research.att.com, rem-conf@es.net Cc: casner@ISI.EDU, frederic@parc.xerox.com Message-Id: <746353473.0.CASNER@XFR.ISI.EDU> In-Reply-To: <199308260214.AA06890@venera.isi.edu> Mail-System-Version: Henning, > The range through 5000 is subject to random assignment, leaving the > range above 5000. Another implementation-specific detail, but still I agree it makes sense to follow it. > (It is curious to note, btw, that port 6000+ for X11 does not > show up in RFC 1340.) These numbers do appear in the online version for the next Assigned Numbers RFC. > Merit does track selected services with numbers above 5000 (X11, in > particular), so that choice does not threaten advantage 3, assuming > RTP-directly-over IP does contribute a significant fraction of the > traffic. ^^^ not (?) > My suggestion would be to follow the X11 example and use a small range > of numbers I talked to IANA today, before I saw Henning's message, and coincidentally he mentioned that the allocation of a block of numbers by X11 was irksome. He said they should have taken one for a port-mapping function, then used dynamically allocated ports as needed. So, we might have to justify taking a block of numbers. > for example 5003 and up (only because 5002 is radio free > ethernet). Actually, there are several others in the 5000-5500 range. I don't remember the details, but I should be able to get a copy of that section of the assignments. What hasn't been discussed much yet is what the port number or small block of numbers would indicate. The profile draft suggests one for audio and one for video. I've wondered in the past whether the port number should indicate the profile, so that an application can support multiple profiles. > Possible ranges: 5003+ (since Radio Free > Ethernet, another multimedia application, has 5002) or 8000+ (the > first real round port number not yet taken). I think staying between 5000 and 6000 my help keep away from random allocators, but we would need to avoid some existing assignments. -- Steve ------- From rem-conf-request@es.net Thu Aug 26 06:06:35 1993 Received: from itd.nrl.navy.mil by osi-east.es.net with SMTP (PP) id <08022-0@osi-east.es.net>; Thu, 26 Aug 1993 02:59:15 +0000 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA08462; Thu, 26 Aug 93 05:59:12 EDT Date: Thu, 26 Aug 93 05:59:12 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9308260959.AA08462@itd.nrl.navy.mil> To: rem-conf@es.net Subject: port numbers Steve, How would IANA feel about having one port per application-type ? This would keep the number of reserved ports small and yet preserve the advantage of fixed port assignments and eliminate the need for a port-mapper function. For unicast, couldn't these same port numbers be used by the side of the conversation that did not initiate the connection, with other pseudo-random ports being used by the initiator ? For example, Port# Application Type ------ ----------------- 5xxx Session Directory 5yyy Audio 5zzz Video 5www Whiteboard Most of the current applications (e.g. vat) can handle multiple kinds of encodings for their application type. So one lets one's application always use the same port number and the application figures out how to handle the particular encoding. This also would let the backbone track multicast RTP traffic by application type, which would perhaps be useful. It isn't clear to me that having a small privileged daemon is in fact an obstacle to use of the RTP applications, as someone else asserted overnight. Particularly since the daemon would be quite small and just pass traffic through the moral equivalent of a pipe. As a minority of one, I'd still rather use port numbers below 1024, though I'm not objecting to using the higher port numbers. :-) Ran atkinson@itd.nrl.navy.mil From rem-conf-request@es.net Thu Aug 26 11:05:34 1993 Received: from CORNELLC.CIT.CORNELL.EDU by osi-east.es.net with SMTP (PP) id <08864-0@osi-east.es.net>; Thu, 26 Aug 1993 07:56:33 +0000 Received: from CORNELLC by CORNELLC.cit.cornell.edu (IBM VM SMTP V2R2) with BSMTP id 4750; Thu, 26 Aug 93 10:56:33 EDT Received: from CORNELLC (TCD) by CORNELLC (Mailer R2.08A) with BSMTP id 9966; Thu, 26 Aug 93 10:56:32 EDT Date: Thu, 26 Aug 93 10:39:11 EDT From: Tim Dorcey Subject: Port assignment To: rem-conf@es.net How about using port 7648 for v1DE0 transmission? Just a thought; I'm certainly not familiar with the real issues under consideration here.... Tim Dorcey Cornell Information Technologies t.dorcey@cornell.edu From rem-conf-request@es.net Thu Aug 26 11:41:40 1993 Received: from sirius.ctr.columbia.edu by osi-east.es.net with SMTP (PP) id <09106-0@osi-east.es.net>; Thu, 26 Aug 1993 08:32:41 +0000 Received: from micmac.ctr.columbia.edu by sirius.ctr.columbia.edu (5.67/5.10) with SMTP id AA22341; Thu, 26 Aug 93 11:32:27 -0400 From: (Sassan Pejhan) sassan Received: by micmac.ctr.columbia.edu (5.67/SMI-4.1) id AA09651; Thu, 26 Aug 93 11:32:25 -0400 Date: Thu, 26 Aug 93 11:32:25 -0400 Message-Id: <9308261532.AA09651@micmac.ctr.columbia.edu> To: rem-conf@es.net Subject: Port Assignments Cc: eleft@ctr.columbia.edu There has recently been a lot of discussion on the subject of Port Assignments for multicast communications. Last April, a group of us at Columbia University submitted a paper to IEEE/ACM Trans. on Networking on the subject of Multicast Address Management, with a Section (pp.17-22) dealing with the port assignment problem. Three different solutions, including use of virtual port numbers (Section 5.2) and a port resolution protocol (Section 5.3) were suggested. The paper is available through anonymous ftp, and we would wellcome your comments on the subject matter. ftp to ftp.ctr.columbia.edu cd CTR-Research/advent/public/papers/93 The file is eleft93b.ps.Z (compressed, postscript file) Sassan Pejhan Columbia University sassan@ctr.columbia.edu From rem-conf-request@es.net Thu Aug 26 13:17:39 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with SMTP (PP) id <09802-0@osi-east.es.net>; Thu, 26 Aug 1993 10:11:22 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 26 Aug 1993 18:11:14 +0100 To: mbone@isi.edu, rem-conf@es.net Subject: Re: misuse of ttl: Time to Die! Date: Thu, 26 Aug 93 18:11:12 +0100 From: Jon Crowcroft the unmentionab;le being that left the simulation running across the mbone all today should be more careful next time, plz. mbone video sesh advertised in sd is not for a simulation ... spesh not one that advertised mob*l oil... j. From rem-conf-request@es.net Thu Aug 26 16:23:41 1993 Received: from cad.gatech.edu by osi-east.es.net with SMTP (PP) id <12788-0@osi-east.es.net>; Thu, 26 Aug 1993 13:17:12 +0000 Received: from whosnext.cad.gatech.edu by cad.gatech.edu with SMTP id AA05217 (5.65c/IDA-1.4.4 for ); Thu, 26 Aug 1993 16:21:24 -0400 Received: by whosnext.cad.gatech.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0) id AA18612; Thu, 26 Aug 93 16:18:01 EDT Date: Thu, 26 Aug 93 16:18:01 EDT From: estephen@whosnext.cad.gatech.edu (Eric R Stephens) Message-Id: <9308262018.AA18612@whosnext.cad.gatech.edu> Original-Received: by NeXT Mailer (1.63) PP-warning: Illegal Received field on preceding line To: rem-conf@es.net Subject: looking for nv subscribe estephen@whosnext.cad.gatech.edu I'm looking for nv and this email address was suggested as a starting point. Eric Stephens From rem-conf-request@es.net Thu Aug 26 16:57:13 1993 Received: from yonge.csri.toronto.edu by osi-east.es.net with SMTP (PP) id <13566-0@osi-east.es.net>; Thu, 26 Aug 1993 13:50:05 +0000 Received: from alias by yonge.csri.toronto.edu with UUCP id <14701>; Thu, 26 Aug 1993 16:49:53 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA01824 (5.65a/IDA-1.4.2 for J.Crowcroft@cs.ucl.ac.uk); Thu, 26 Aug 93 16:46:16 -0400 Received: by dino.alias.com id AA29186 (5.65a/IDA-1.4.2 for rem-conf@es.net); Thu, 26 Aug 93 16:46:16 -0400 From: chk@alias.com (C. Harald Koch) Message-Id: <9308262046.AA29186@dino.alias.com> Subject: Re: misuse of ttl: Time to Die! To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Thu, 26 Aug 1993 17:46:15 -0400 Cc: mbone@isi.edu, rem-conf@es.net In-Reply-To: <93Aug26.141851edt.14694@yonge.csri.toronto.edu> from "Jon Crowcroft" at Aug 26, 93 01:11:12 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 993 UNIX implements a simple, 'security' system based on file access permissions. The most common use for this, especially in research environments, is to protect us from ourselves (particularly our own silly mistakes). Internet systems should be designed with similar 'security' systems in mind. Here, I am not talking about 'security' in the sense of confidentiality, or of protecting from break-ins, but rather, 'security' in the sense of protecting us from our own silly mistakes. The fact that the MBone is wide open seems to be foolish optimism. This problem is going to get worse, not better; witness UseNet as a prime example... [ My random .sig generator has once again picked a timely message... >:] -- C. Harald Koch, Network Analyst | "It is fruitless to attempt to indoctrinate Alias Research Inc. Toronto, ON | a super-annuated canine with innovative chk@alias.com | maneuvers." chk@gpu.utcc.utoronto.ca | -Dr. SNMP, The Simple Times, v2n3 From rem-conf-request@es.net Thu Aug 26 21:24:23 1993 Received: from nutmeg-gw.NTU.EDU.AU by osi-east.es.net with SMTP (PP) id <16186-0@osi-east.es.net>; Thu, 26 Aug 1993 18:23:50 +0000 Received: from localhost (malcolm@localhost) by nutmeg (8.3/8.3) id KAA19821; Fri, 27 Aug 1993 10:53:41 +0930 From: Malcolm Caldwell Message-Id: <199308270123.KAA19821@nutmeg> Subject: ttl / threshold To: G.Michaelson@cc.uq.oz.au Date: Fri, 27 Aug 1993 10:53:40 +0930 (CST) Cc: rem-conf@es.net X-Mailer: ELM [version 2.4 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1724 George, There is a good reason why I don't see everyone in the vat session. I currently have my threshold set to 160. From the faq: TTL thresh --- ------ IETF chan 1 low-rate GSM audio 255 224 IETF chan 2 low-rate GSM audio 223 192 IETF chan 1 PCM audio 191 160 IETF chan 2 PCM audio 159 128 IETF chan 1 video 127 96 IETF chan 2 video 95 64 local event audio 63 32 local event video 31 1 According to sd (and my understanding of things) the MBone Audio conference is 224.2.0.1 ttl 191. Now, some people are running vat using its defaults, which is the MBONE audio multicast address (224.2.0.1) and a ttl of 127. This is wrong - I can't see any of these people. Others do as their thresholds are much lower (128, 96 or 64). We also discussed the AARNet wb. You said it had a TTL to keep it in Australia. Unfortunately that means it can't get to me. This is the problem of using TTLs/Thresholds for both bandwidth limitation and geographic limitation. It was mentioned that there is a release of the new multicast code. Is this stable enough that I can convince Richard @ rmit to change over? -- 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 Fri Aug 27 04:03:46 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with SMTP (PP) id <17788-0@osi-east.es.net>; Fri, 27 Aug 1993 00:57:56 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Aug 1993 08:57:44 +0100 To: chk@alias.com (C. Harald Koch) cc: mbone@isi.edu, rem-conf@es.net Subject: Re: misuse of ttl: Time to Die! In-reply-to: Your message of "Thu, 26 Aug 93 17:46:15 EDT." <9308262046.AA29186@dino.alias.com> Date: Fri, 27 Aug 93 08:57:44 +0100 From: Jon Crowcroft >The fact that the MBone is wide open seems to be foolish optimism. This >problem is going to get worse, not better; witness UseNet as a prime >example... anone could flood the internet with random useless udp packets it is NOT a mis-function of the mbone that lets people clober the net - it is a lack of feature of call admission or traffic policing in the internet for any traffic it is only van jacobson's fixes to tcp that let most applications work because implicit cooperation is built into their access by tcp's congestion avoidance.... but most udp based applications do NOT have this multicast just multipleis this by the number of sites (or at best number of listeners when pruing is finished beta testing...) jon From rem-conf-request@es.net Fri Aug 27 12:45:58 1993 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with SMTP (PP) id <20325-0@osi-east.es.net>; Fri, 27 Aug 1993 09:36:49 +0000 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 27 Aug 1993 17:36:32 +0100 To: mbone@isi.edu, rem-conf@es.net Subject: multicast congestion control Date: Fri, 27 Aug 93 17:36:31 +0100 From: Jon Crowcroft Date: Fri, 27 Aug 93 17:30:33 +0100 From: I.Wakeman@uk.ac.ucl.cs As jon has alluded to before, we have an approach to multicast congestion control. We have a very drafty paper describing it available on cs.ucl.ac.uk:darpa/multicast-video.ps.Z. This is being put up in its current unpolished state to solicit suggestions as to its suitability for protecting the mbone, and because I am just about to try converting the code to sit as an option on top of rtp, and then put the code into any tools I can get my hands on. Therefore I'd like to discover the opinions of the various owners of RTP using tools, as whether this would be a good or a bad thing, and what technical improvements could be made. The current test rig has both a loss based congestion meter and a delay based congestion meter - it would be fun to try out both in the wider context to determine their relative sensitivities. I'm out of here now till Tuesday up a mountain, and I'll happily receive the various brickbats thrown my way then. cheers ian ------- End of Forwarded Message From rem-conf-request@es.net Fri Aug 27 14:56:07 1993 Received: from relay.nswc.navy.mil by osi-east.es.net with SMTP (PP) id <21438-0@osi-east.es.net>; Fri, 27 Aug 1993 11:50:08 +0000 Received: from sunoco.nswc.navy.mil by relay.nswc.navy.mil (4.1/SMI-4.1) id AA08942; Fri, 27 Aug 93 14:49:28 EDT Received: from vaxless.sunoco by sunoco.nswc.navy.mil (4.1/SMI-4.1) id AA02618; Fri, 27 Aug 93 13:50:01 EST Date: Fri, 27 Aug 93 13:50:01 EST From: pirey%sunoco@relay.nswc.navy.mil (Phil Irey 703.663.1582) Message-Id: <9308271850.AA02618@sunoco.nswc.navy.mil> To: rem-conf@es.net Subject: Problems with Sun FDDI/S and IP Multicast I have added the code writen by Anders Klemets to allow the IP multicast code to work with Sun's FDDI/S card. Everything compiled fine and I built the kernel with no problem. Some problems did crop up, however. When I try to run mrouted, I get the following error: sparhawk_fddi #mrouted -d 3 debug level 3 mrouted version 2.0 installing le0 (128.38.42.73 on subnet 128.38.42.64) as vif #0 installing bf0 (128.38.42.201 on subnet 128.38.42.192) as vif #1 SENT membership query from 128.38.42.73 to 224.0.0.1 SENT neighbor probe from 128.38.42.73 to 224.0.0.4 setsockopt DVMRP_ADD_VIF: Can't assign requested address Also, I can't join groups that other ethernet only machines can even though they are advertised with sd. For example, when I try to start the GMS-4 IR session, I get the following message: Cannot join group 224.2.170.143 I can join Mbone Audio and Mbone Video, however. Any ideas? thanks, phil irey (pirey@relay.nswc.navy.mil) From rem-conf-request@es.net Fri Aug 27 22:31:47 1993 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <24794-0@osi-east.es.net>; Fri, 27 Aug 1993 19:24:18 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA12686; Fri, 27 Aug 93 19:24:16 PDT Date: Fri, 27 Aug 93 19:24:16 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9308280224.AA12686@viipuri.nersc.gov> To: rem-conf@es.net Subject: Request for Info Cc: kasera@freya.cs.umass.edu ----- Begin Included Message ----- >From kasera@freya.cs.umass.edu Mon Aug 23 10:42:27 1993 Date: Mon, 23 Aug 93 13:41:32 -0400 From: kasera@freya.cs.umass.edu To: rem-conf-request@es.net Subject: Request for Info Content-Length: 134 Could somebody please tell me how I can obtain the design document of LBL's whiteboard tool ? Thanks in advance, Sneha Kumar Kasera ----- End Included Message ----- From rem-conf-request@es.net Sat Aug 28 03:00:48 1993 Received: from viipuri.nersc.gov by osi-east.es.net via ESnet SMTP service id <25224-0@osi-east.es.net>; Fri, 27 Aug 1993 22:48:21 +0000 Received: by viipuri.nersc.gov (4.1/ESnet-1.2) id AA12800; Fri, 27 Aug 93 22:48:19 PDT Date: Fri, 27 Aug 93 22:48:19 PDT From: ari@es.net (Ari Ollikainen) Message-Id: <9308280548.AA12800@viipuri.nersc.gov> To: dmk@allegra.att.com Subject: Re: updated rem-conf archives? Cc: rem-conf@es.net > From dmk@allegra.att.com Thu Aug 26 13:13:07 1993 > Date: Thu, 26 Aug 93 16:11:57 EDT > From: dmk@allegra.att.com (Dave Kristol) > To: ari@es.net > Subject: updated rem-conf archives? > Content-Length: 198 > > The current rem-conf archive on nic.es.net dates from 11/92. Henning > Schulzrinne here said you might be able to help me get a more > up-to-date version. Would that be possible? > > Thanks > Dave Kristol > YES INDEED!! The archives for rem-conf (from 11/92 on) are in a different directory: pub/mailing-lists/mail-archive/rem-conf Here is a current directory listing: total 1934 -rw-r--r-- 1 0 37 117 Jul 19 16:31 .IndexLink -rwxr-xr-x 1 0 22 382 Aug 25 00:11 .cache -rw-r--r-- 1 7377 22 308028 Aug 27 22:15 rem-conf-1992-11 -rw-r--r-- 1 7377 22 260433 Aug 27 22:14 rem-conf-1992-12 -rw-r--r-- 1 7377 22 96338 Aug 27 22:14 rem-conf-1993-01 -rw-r--r-- 1 7377 22 125222 Aug 27 22:14 rem-conf-1993-02 -rw-r--r-- 1 7377 22 240714 Aug 27 22:14 rem-conf-1993-03 -rw-r--r-- 1 7377 22 117390 Aug 27 22:14 rem-conf-1993-04 -rw-r--r-- 1 7377 22 78700 Aug 27 22:14 rem-conf-1993-05 -rw-rw-r-- 1 210 22 152800 Jun 30 20:27 rem-conf-1993-06 -rw-r--r-- 1 210 22 311141 Jul 30 19:22 rem-conf-1993-07 -rw-r--r-- 1 210 22 194705 Aug 27 19:31 rem-conf-1993-08 The earlier archive is in pub/ietf/rem-conf and contains: -rwxr-xr-x 1 0 37 250 Aug 25 00:10 .cache drwxrwx--- 2 0 37 512 Aug 12 17:49 .cap -rw-rw-r-- 1 0 37 660 Jun 14 10:21 INDEX -rw-rw-r-- 1 0 37 1103736 Nov 13 1992 av-transport-archive -rw-rw-r-- 1 0 37 843992 Nov 13 1992 rem-conf-archive ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Sat Aug 28 16:55:39 1993 Received: from noc.sura.net by osi-east.es.net via ESnet SMTP service id <27517-0@osi-east.es.net>; Sat, 28 Aug 1993 13:50:36 +0000 Received: by noc.sura.net with SMTP for rem-conf@es.net (5.65b/(SURAnet $Revision: 1.29 $)) id AA03107; Sat, 28 Aug 93 16:50:31 -0400 Message-Id: <9308282050.AA03107@noc.sura.net> To: estephen@whosnext.cad.gatech.edu (Eric R Stephens) Cc: rem-conf@es.net Subject: Re: looking for nv In-Reply-To: Your message of "Thu, 26 Aug 93 16:18:01 EDT." <9308262018.AA18612@whosnext.cad.gatech.edu> Date: Sat, 28 Aug 93 16:50:28 -0400 From: Nicholas Vargish > subscribe estephen@whosnext.cad.gatech.edu ?? > I'm looking for nv and this email address was suggested as a starting point. Well, my initials are nv. Are you looking for a person? > Eric Stephens Have we met? Nick From rem-conf-request@es.net Mon Aug 30 07:13:00 1993 Received: from sics.se by osi-east.es.net via ESnet SMTP service id <01326-0@osi-east.es.net>; Mon, 30 Aug 1993 04:12:22 +0000 Received: from bugs.sics.se by sics.se (5.65+bind 1.7+ida 1.4.2/SICS-1.4) with SMTP id AA25276; Mon, 30 Aug 93 13:12:15 +0200 Message-Id: <9308301112.AA25276@sics.se> To: "pirey (Phil Irey 703.663.1582)" Cc: rem-conf@es.net Subject: Re: Problems with Sun FDDI/S and IP Multicast In-Reply-To: Your message of "Fri, 27 Aug 1993 20:50:01 +0200." <9308271850.AA02618@sunoco.nswc.navy.mil> Date: Mon, 30 Aug 1993 13:12:13 +0200 From: Anders Klemets Possible solutions to your problems 1. Make sure that the FDDI interface is disabled in the mrouted.conf file by using the command phyint x.x.x.x disable 2. Some programs (most notably nv) may not work properly if the primary hostname maps onto a non-multicast capable interface. If the hostnames of your two interfaces are specified in the files /etc/hostname.bf0 and /etc/hostname.le0 the name of the bf0 interface will be used as the primary hostname because the rc.boot script uses lexical ordering. You can avoid this by removing the /etc/hostname.bf0 file and adding an explicit ifconfig statement to your rc.local file. Anders From rem-conf-request@es.net Tue Aug 31 15:33:02 1993 Received: from taurus.cs.nps.navy.mil by osi-east.es.net via ESnet SMTP service id <15165-0@osi-east.es.net>; Tue, 31 Aug 1993 12:26:57 +0000 Received: by taurus.cs.nps.navy.mil (4.1/SMI-4.1) id AA20481; Tue, 31 Aug 93 12:27:49 PDT Date: Tue, 31 Aug 93 12:27:49 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9308311927.AA20481@taurus.cs.nps.navy.mil> To: rem-conf-request@es.net, rem-conf@es.net Subject: rem-conf request I am interested in subscribing, and I would like to announce a scientific visualization workshop SEP 15-16 that we are hoping to broadcast over MBONE. Any info on rem-conf (or redirection to more appropriate list) is appreciated. Thanks in advance. Donald P. Brutzman LCDR USN work (408) 656-2149 Code OR/Br Naval Postgraduate School [Glasgow 204] fax (408) 656-2595 Monterey California 93943-5000 USA home (408) 372-0190 From rem-conf-request@es.net Tue Aug 31 16:31:13 1993 Received: from Sun.COM by osi-east.es.net via ESnet SMTP service id <15666-0@osi-east.es.net>; Tue, 31 Aug 1993 13:27:50 +0000 Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA03675; Tue, 31 Aug 93 13:27:49 PDT Received: from amber.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA28022; Tue, 31 Aug 93 13:28:56 PDT Received: by amber.Eng.Sun.COM (5.0/SMI-SVR4) id AA19395; Tue, 31 Aug 93 13:27:35 PDT Date: Tue, 31 Aug 93 13:27:35 PDT From: Don.Hoffman@Eng.Sun.COM (Don Hoffman) Message-Id: <9308312027.AA19395@amber.Eng.Sun.COM> To: rem-conf@es.net Subject: Call for Participation - IMA Network Focus Group X-Sun-Charset: US-ASCII Content-Length: 2621 Call for Participation - IMA Network Focus Group A new Focus Group (FoG) has recently been formed within the Architecture Technical Working Group (ATWG) of IMA to deal with the networking and protocol issues relating to the multimedia system services (MSS) framework being defined by the ATWG. The goal of this group is to specify the network service interfaces and protocols used within the MSS sufficiently to allow inter-operation between compatible end-systems. Specific items on the agenda of the group are: - To clarify the network transport requirements from the ATWG RFT and associated submissions in areas such as quality of service, network resource management, graceful degradation, synchronization, etc.. - To define a reference interface to the network transport within the MSS framework that supports the above requirements. - To define the set of target network environments within which the group's work applies. - To define a set of protocol profiles that support the above requirements and interfaces. Where possible, these protocols will be selected from the work of existing standardization bodies. - To work with existing standardization bodies to define new protocols where current or foreseen requirements are not being met, and to ensure a high level of compatibility with the ongoing efforts of other groups. How to participate: If you are interested in participating in the work of this group, contact the Network FoG chair: Don Hoffman Sun Microsystems Computer Corporation 2550 Garcia Ave, MS MTV19-02 Mountain View, CA 94043-1100 email: hoffman@eng.sun.com phone: +415-336-4339 fax: +415-336-6315 What is the IMA? The Interactive Multimedia Association (IMA) is an international, not-for-profit trade association with over 200 members representing the full spectrum of the multimedia: applications developers, suppliers of hardware and software, systems integrators, publishers and distributors, educators and users. The IMA seeks to serve as a catalyst for all segments of the multimedia industry and welcomes participation of individuals and organizations. What is the ATWG? Technical working groups are established by the IMA steering committee to create and review existing specifications and proposals. The Architectural Technical Working Group (ATWG) is in the process of developing a technical description and framework definition for multimedia based on on open submission process. The scope of this group's activities includes APIs, protocols, class hierarchies and reference implementations.