From rem-conf-request@es.net Mon Dec 02 13:51:38 1996 Received: from ietf.org by osi-east.es.net with ESnet SMTP (PP); Mon, 2 Dec 1996 10:50:53 -0800 Received: from ietf.ietf.org by ietf.org id aa06513; 2 Dec 96 11:29 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-crtp-01.txt Date: Mon, 02 Dec 1996 11:29:38 -0500 Sender: cclark@ietf.org Message-ID: <9612021129.aa06513@ietf.org> --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 : Compressing IP/UDP/RTP Headers for Low-Speed Serial Links Author(s) : S. Casner, V. Jacobson Filename : draft-ietf-avt-crtp-01.txt Pages : 16 Date : 11/27/1996 This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed to 2-4 bytes. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s). This draft updates draft-casner-jacobson-crtp-00.txt which was sent to the rem-conf list but was never officially posted as an Internet-Draft due to a mail lossage that then left it out of date. At the Montreal IETF meeting in June 1996, this proposal was accepted as a work item of the the Audio/Video Transport working group, hence the draft name change. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-crtp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-crtp-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-crtp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961127164557.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-crtp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-crtp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127164557.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Mon Dec 02 14:53:23 1996 Received: from ietf.org by osi-east.es.net with ESnet SMTP (PP); Mon, 2 Dec 1996 11:52:36 -0800 Received: from ietf.ietf.org by ietf.org id aa23115; 2 Dec 96 14:26 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-avt-rtp-payload-02.txt Date: Mon, 02 Dec 1996 14:26:29 -0500 Sender: cclark@ietf.org Message-ID: <9612021426.aa23115@ietf.org> --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 Payload Format for H.263 Video Stream Author(s) : C. Zhu Filename : draft-ietf-avt-rtp-payload-02.txt Pages : 11 Date : 11/26/1996 This document specifies the RTP payload format for encapsulating H.263 bitstreams in the Real-Time Transport Protocol (RTP). Three modes are defined for RTP H.263 payload header. An RTP packet can use one of the three modes for H.263 video streams depending on the desired performance characteristics and H.263 encoding options employed. The shortest header mode (Mode A) supports fragmentation at Group of Block (GOB) boundaries. The long header modes (Mode B and C) support fragmentation at Macroblock (MB) boundaries. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-payload-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-payload-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-payload-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961202142551.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-payload-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-payload-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961202142551.I-D@ietf.org> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Mon Dec 02 20:04:59 1996 Received: from dfw-ix6.ix.netcom.com by osi-east.es.net with ESnet SMTP (PP); Mon, 2 Dec 1996 17:04:13 -0800 Received: from srf-ca10-42.ix.netcom.com (hermenh@srf-ca10-42.ix.netcom.com [205.186.119.170]) by dfw-ix6.ix.netcom.com (8.6.13/8.6.12) with SMTP id RAA09500 for ; Mon, 2 Dec 1996 17:03:50 -0800 From: hermenh@ix.netcom.com Message-ID: <32A37C34.3264@ix.netcom.com> Date: Mon, 02 Dec 1996 17:02:44 -0800 X-Mailer: Mozilla 2.01E-NC250 (Win16; U) MIME-Version: 1.0 To: rem-conf@es.net Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe From rem-conf-request@es.net Tue Dec 03 10:13:47 1996 Received: from itd.nrl.navy.mil by osi-east.es.net with ESnet SMTP (PP); Tue, 3 Dec 1996 07:13:00 -0800 Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16868; Tue, 3 Dec 96 10:12:51 EST Message-Id: <9612031512.AA16868@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 3 Dec 1996 10:13:16 -0400 To: rem-conf@es.net From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: I-D ACTION:draft-macker-mdp-framework-01.txt FYI: > A Revised Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : The Multicast Dissemination Protocol (MDP) Framework > Author(s) : J. Macker, W. Dang > Filename : draft-macker-mdp-framework-01.txt > Pages : 14 > Date : 11/27/1996 > >This document outlines a simple protocol framework for reliable multicast >dissemination of data files. The general framework was originally developed >and used by the Image Multicaster (IMM) application within the Internet >MBone for dissemination of satellite imagery. This document describes the >potential for more general use of the protocol framework, its operational >modes, some performance issues, and the basic application data units (ADUs) >presently used. This is not intended to be a detailed protocol >specification document, but rather a broad description of the basic >architectural approach. Further detailed description of the protocol >implementation may be provided in future documents. > From rem-conf-request@es.net Tue Dec 03 14:02:17 1996 Received: from bmrc.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Tue, 3 Dec 1996 11:01:35 -0800 Received: from nobozo.CS.Berkeley.EDU (nobozo.CS.Berkeley.EDU [128.32.34.58]) by bmrc.Berkeley.EDU (8.8.2/8.6.9) with SMTP id KAA28745 for <298-list@bmrc.Berkeley.EDU>; Tue, 3 Dec 1996 10:55:03 -0800 (PST) Received: from sockeye (sockeye.CS.Berkeley.EDU [128.32.36.74]) by nobozo.CS.Berkeley.EDU (8.6.10/8.6.3) with SMTP id KAA03457 for <298-list@bmrc>; Tue, 3 Dec 1996 10:55:02 -0800 Date: Tue, 3 Dec 1996 10:55:02 -0800 Message-Id: <199612031855.KAA03457@nobozo.CS.Berkeley.EDU> X-Sender: jerrlyn@nobozo.CS.Berkeley.EDU X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: 298-list@bmrc.Berkeley.EDU From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday December 4, 1996 12:30-2:00 PDT 405 Soda Hall) "The Architecture and Operation of the Berkeley Campus Network" Cliff Frost Data Communications & Network Services U.C. Berkeley The Internet has become an extremely well-known entity, appearing almost routinely on the front pages of such major newspapers as the New York Times, the Wall Street Journal, and the Daily Californian. As the Internet and the campus network become more visible, more and more people are interested in how it is designed and put together. This talk will cover how the Berkeley network has grown up over the last few years, including various design decisions along the way and the current major issues facing us, from technical problems to funding models to hiring woes to logistics. -------------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40PST (GMT - 8 hrs). See sd or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. From rem-conf-request@es.net Tue Dec 03 15:46:29 1996 Received: from bitfield.fi by osi-east.es.net with ESnet SMTP (PP); Tue, 3 Dec 1996 12:45:49 -0800 Received: from le-esa.bitfield.fi (ras-client.bitfield.fi [193.65.109.76]) by bitfield.fi (8.7.5/8.7.3) with SMTP id WAA05164; Tue, 3 Dec 1996 22:48:23 +0200 Message-ID: <32A52BA8.6718@bitfield.fi> Date: Tue, 03 Dec 1996 23:43:36 -0800 From: Esa Vitikainen Organization: Bitfield Oy X-Mailer: Mozilla 2.0 (Win95; I; 16bit) MIME-Version: 1.0 Newsgroups: alt.education.distance,comp.human-factors,comp.multimedia,comp.dcom.videoconf CC: t120-interest@world.std.com, videophone@es.net, vidconf@pulver.com, rem-conf@es.net Subject: Seeking visions/experiences of multipoint data apps Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, as part of my studies I am planning to find out just what are users / developers / service providers / VARs / ... doing / going to do / would like to do with data in multipoint multimedia conferencing context. In other words, I'm chasing visions and experiences of applications adding value to voice/video. There are the apparent chat, file transfer, whiteboard, and application sharing. But how are they really utilized? Where do they fall short? What else is needed out there? Are there studies or something about this available somewhere? Places to ask around? Willing to reveal your own great idea? An example: features I imagine needed for remote presentation: - slideshow operated by the presenter - "hands raised" electronically (with text description?) - slides independently leafed through / edited locally (like having paper copies) - others taking over the slideshow control, with own remarks - dialogs sent to ask for comments / test understanding, with reply statistics shown (for large audience) Regards, Esa From rem-conf-request@es.net Wed Dec 04 08:54:21 1996 Received: from dirty.bell-labs.com (actually dirty.research.bell-labs.com) by osi-east.es.net with ESnet SMTP (PP); Wed, 4 Dec 1996 05:53:31 -0800 Received: from research.bell-labs.com by dirty; Wed Dec 4 08:53:39 EST 1996 Received: from zubin.dnrc.bell-labs.com by research; Wed Dec 4 08:50:56 EST 1996 Received: from arrakis (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id IAA25875 for ; Wed, 4 Dec 1996 08:50:56 -0500 (EST) From: Jonathan Rosenberg Message-Id: <961204085100.ZM10958@arrakis> Date: Wed, 4 Dec 1996 08:50:54 -0700 X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996) To: rem-conf@es.net Subject: draft-rosenberg-itg-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii [I apologize if anyone gets this multiple times - I have been having some problems sending to rem-conf] AVT group: Henning Schulzrinne and I have been investigating the issue of voice aggregation within RTP. The premise is to place voice data from many users within a single RTP session (and packet). Such aggregation is possible in scenarios where you are connecting PBX's, telephone switches, or any other device which handles multiple voice users, via Internet. We have prepared a draft which discusses the advantages of such aggregation, and then looks at defining a new RTP profile for this application. If you are interested, you can find a copy of the draft in html form at http://www.cs.columbia.edu/~hgs/rtp/aggregation. Please feel free to address any comments or questions to the authors. Thanks, Jonathan Rosenberg -- Jonathan Rosenberg Lucent Technologies Member of Technical Staff Bell Laboratories High Speed Networks Research 101 Crawfords Corner Rd. PHONE: (908) 949-6418 Holmdel, NJ 07733 FAX: (908) 949-9118 Rm. 4G-530 EMAIL: jdrosen@bell-labs.com From rem-conf-request@es.net Wed Dec 04 12:00:44 1996 Received: from faui40.informatik.uni-erlangen.de by osi-east.es.net with ESnet SMTP (PP); Wed, 4 Dec 1996 08:59:56 -0800 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id RAA26760 (8.7.6/7.5b-FAU); for ; Wed, 4 Dec 1996 17:59:53 +0100 (MET) From: Toerless Eckert Message-Id: <199612041659.RAA26760@faui40.informatik.uni-erlangen.de> Subject: vic tweaking question To: rem-conf@es.net Date: Wed, 4 Dec 1996 17:59:51 +0100 (MET) Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi I seem to be a tcl ignorant: I am trying to modify the vic startup file so that a the stamp-size window by default is muted. This effectively increases the sender rate by some frames if the stamp-size picture is remote. I only failed to get it done. Any help here ? Thanks Toerless From rem-conf-request@es.net Wed Dec 04 13:53:44 1996 Received: from burdell.cc.gatech.edu by osi-east.es.net with ESnet SMTP (PP); Wed, 4 Dec 1996 10:52:39 -0800 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.8.3/8.6.9) with ESMTP id NAA11094 for ; Wed, 4 Dec 1996 13:52:23 -0500 (EST) Received: (from kevin@localhost) by flora.cc.gatech.edu (8.8.3/8.6.9) id NAA19416 for rem-conf@es.net; Wed, 4 Dec 1996 13:52:06 -0500 (EST) Date: Wed, 4 Dec 1996 13:52:06 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199612041852.NAA19416@flora.cc.gatech.edu> To: rem-conf@es.net Subject: Re: vic tweaking question >>I seem to be a tcl ignorant: >>I am trying to modify the vic startup file so that a the stamp-size >>window by default is muted. This effectively increases the sender rate >>by some frames if the stamp-size picture is remote. Or a more general question... is the Tcl interface designed to this type of thing? For example, I'd like to start a certain instance of vic with the stamp-size window muted but with an automatic 1/4 NTSC window showing. -Kevin Almeroth From rem-conf-request@es.net Wed Dec 04 14:50:03 1996 Received: from bmrc.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Wed, 4 Dec 1996 11:49:00 -0800 Received: from mailsun.aber.ac.uk (mailsun.aber.ac.uk [144.124.16.7]) by bmrc.Berkeley.EDU (8.8.2/8.6.9) with SMTP id LAA05120 for <298-list@bmrc.berkeley.edu>; Wed, 4 Dec 1996 11:35:23 -0800 (PST) Received: from mailhost.aber.ac.uk (actually host saturn.aber.ac.uk) by mailsun.aber.ac.uk with SMTP (XTPPst-c); Wed, 4 Dec 1996 19:34:31 +0000 To: Jerrlyn Iwata cc: 298-list@bmrc.Berkeley.EDU, dap@aber.ac.uk Subject: Re: Berkeley Multimedia & Graphics Seminar In-reply-to: Your message of Tue, 03 Dec 1996 10:55:02 -0800. <199612031855.KAA03457@nobozo.CS.Berkeley.EDU> Date: Wed, 04 Dec 1996 19:32:30 +0000 Message-ID: <22330.849727950@mailhost.aber.ac.uk> From: D E PRICE Dear All, I am sitting hoping to watch the UCB seminar a little later, when I just noticed that the sdr announcement is still referring to the last seminar and my sdr has last seen an announcement on 29nov at 19:34. Do I need to worry ? or is it normally like this with new announcements only being seen just before the broadcast starts? Thanks, Dave Price, UW, Aberystwyth. Wales. UK. From rem-conf-request@es.net Wed Dec 04 17:36:38 1996 Received: from bugs-bunny.CS.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Wed, 4 Dec 1996 14:35:36 -0800 Received: from dilbert.CS.Berkeley.EDU (dilbert.CS.Berkeley.EDU [128.32.32.41]) by bugs-bunny.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id MAA22120 for <298-list@bugs-bunny.CS.Berkeley.EDU>; Wed, 4 Dec 1996 12:12:07 -0800 Received: from dilbert.CS.Berkeley.EDU (localhost [127.0.0.1]) by dilbert.CS.Berkeley.EDU (8.7.6/8.6.9) with ESMTP id MAA16579 for <298-list@bugs-bunny.CS.Berkeley.EDU>; Wed, 4 Dec 1996 12:12:05 -0800 Message-Id: <199612042012.MAA16579@dilbert.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.7 05/05/96 To: 298-list@bugs-bunny.CS.Berkeley.EDU Subject: UCB Multimedia Seminar update From: David Simpson X-url: http://www-plateau.cs.berkeley.edu/people/davesimp/ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Dec 1996 12:12:04 -0800 Sender: davesimp@plateau.CS.Berkeley.EDU I have been getting reports from a few people that they are not receiving the seminar announcement. I'm not sure if this is a problem on their end, on our end, or the fact that I'm using the sapAnnouncer to make the announcements instead of sdr. At any rate, here is the correct address/ports for the seminar: video 224.2.238.31/51900 audio 224.2.142.37/24882 wb 224.2.158.81/48748 And the IPTV Program Guide at Precept seems to be receiving the announcement fine, so if you are not receiving an annoucement try checking http://www.precept.com/cgi-bin/iptv/iptvmain.pl -Dave -- ---------------------------------------------------------------------------- David Simpson, davesimp@cs.berkeley.edu Graduate Student - Computer Science - UC Berkeley http://www-plateau.cs.berkeley.edu/~davesimp From rem-conf-request@es.net Wed Dec 04 21:26:27 1996 Received: from bugs-bunny.CS.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Wed, 4 Dec 1996 18:25:49 -0800 Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by bugs-bunny.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id SAA24295 for <298-list@bugs-bunny.CS.Berkeley.EDU>; Wed, 4 Dec 1996 18:11:34 -0800 Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id VAA16878; Wed, 4 Dec 1996 21:11:29 -0500 X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: David Simpson cc: 298-list@bugs-bunny.CS.Berkeley.EDU Subject: Re: UCB Multimedia Seminar update In-reply-to: Your message of "Wed, 04 Dec 96 12:12:04 PST." <199612042012.MAA16579@dilbert.CS.Berkeley.EDU> Date: Wed, 04 Dec 96 21:11:28 -0500 Message-ID: <16463.849751888@mercury.lcs.mit.edu> Sender: mjh@mercury.lcs.mit.edu X-Mts: smtp >I have been getting reports from a few people that they are not >receiving the seminar announcement. I'm not sure if this is a problem on >their end, on our end, or the fact that I'm using the sapAnnouncer to make >the announcements instead of sdr. At any rate, here is the correct This is probably mrouted rate-limiter overload. For historic reasons sdr announces sessions in the low-priority range, and recently we've seen a lot more mbone traffic than we have historically, so low-priority traffic is often getting lost. Basically 512Kbps is not sufficient anymore and that;'s the default rate-limiter in mrouted. Mark From rem-conf-request@es.net Wed Dec 04 22:08:20 1996 Received: from alpha.xerox.com by osi-east.es.net with ESnet SMTP (PP); Wed, 4 Dec 1996 19:07:41 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16434(2)>; Wed, 4 Dec 1996 19:07:28 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177711>; Wed, 4 Dec 1996 19:07:24 -0800 To: Toerless Eckert cc: rem-conf@es.net Subject: Re: vic tweaking question In-reply-to: Your message of "Wed, 04 Dec 96 08:59:51 PST." <199612041659.RAA26760@faui40.informatik.uni-erlangen.de> Date: Wed, 4 Dec 1996 19:07:23 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <96Dec4.190724pst.177711@crevenia.parc.xerox.com> Have you tried the X resource Vic*muteNewSources: true? Bill From rem-conf-request@es.net Wed Dec 04 22:30:39 1996 Received: from alpha.xerox.com by osi-east.es.net with ESnet SMTP (PP); Wed, 4 Dec 1996 19:29:56 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <18030(2)>; Wed, 4 Dec 1996 19:29:49 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177711>; Wed, 4 Dec 1996 19:29:40 -0800 To: kevin@cc.gatech.edu (Kevin C. Almeroth) cc: rem-conf@es.net Subject: Re: vic tweaking question In-reply-to: Your message of "Wed, 04 Dec 96 10:52:06 PST." <199612041852.NAA19416@flora.cc.gatech.edu> Date: Wed, 4 Dec 1996 19:29:27 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <96Dec4.192940pst.177711@crevenia.parc.xerox.com> In message <199612041852.NAA19416@flora.cc.gatech.edu> you write: >For example, I'd like to start a certain instance of vic with the >stamp-size window muted but with an automatic 1/4 NTSC window showing. Try something like this. I don't know how kosher the detach_window call is, you might prefer to just set the X resource Vic.stampInterval to something high. rename build.src build.src.real proc build.src { w src color } { set r [build.src.real $w $src $color] detach_window $src $w.stamp.video global userwin_x userwin_y userwin_size # Or wherever you want the window to pop up set userwin_x($src) 0 set userwin_y($src) 0 set userwin_size($src) "320x240" open_window $src return $r } If you don't want the main vic window hanging around, you could add something like proc user_hook {} { wm iconify . } Bill From rem-conf-request@es.net Thu Dec 05 05:01:03 1996 Received: from faui40.informatik.uni-erlangen.de by osi-east.es.net with ESnet SMTP (PP); Thu, 5 Dec 1996 02:00:25 -0800 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id LAA16278 (8.7.6/7.5b-FAU); Thu, 5 Dec 1996 11:00:18 +0100 (MET) From: Toerless Eckert Message-Id: <199612051000.LAA16278@faui40.informatik.uni-erlangen.de> Subject: Re: vic tweaking question To: fenner@parc.xerox.com (Bill Fenner) Date: Thu, 5 Dec 1996 11:00:16 +0100 (MET) Cc: Toerless.Eckert@informatik.uni-erlangen.de, rem-conf@es.net In-Reply-To: <96Dec4.190724pst.177711@crevenia.parc.xerox.com> from "Bill Fenner" at Dec 4, 96 07:07:23 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Have you tried the X resource Vic*muteNewSources: true? Yes. But it is my own source, so maybe that's the reason why it's not working.. From rem-conf-request@es.net Thu Dec 05 06:44:05 1996 Received: from mwunix.mitre.org by osi-east.es.net with ESnet SMTP (PP); Thu, 5 Dec 1996 03:43:31 -0800 Return-Path: apiszcz@vector2.mitre.org Received: from vector2. (vector2.mitre.org [128.29.104.208]) by mwunix.mitre.org (8.6.10/8.6.4) with ESMTP id GAA24549 for ; Thu, 5 Dec 1996 06:43:29 -0500 Received: by vector2. (SMI-8.6/SMI-SVR4) id GAA12155; Thu, 5 Dec 1996 06:44:51 -0500 Date: Thu, 5 Dec 1996 06:44:51 -0500 From: apiszcz@vector2.mitre.org (Al Piszcz 'peesh') Message-Id: <199612051144.GAA12155@vector2.> Reply-To: Alan Piszcz To: rem-conf@es.net Subject: VIC/nv file play option X-Sun-Charset: US-ASCII Is there a method available for playing an MPEG file/stream into nv or vic? :-----------------------------------------------------------: : Al Piszcz apiszcz@mitre.org : : MITRE Corporation Distributed Systems and Technologies : : 703.883.7124 FAX 703.883.3308 : :-----------------------------------------------------------: From rem-conf-request@es.net Thu Dec 05 08:48:20 1996 Received: from dirty.bell-labs.com (actually dirty.research.bell-labs.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 5 Dec 1996 05:47:30 -0800 Received: from research.bell-labs.com by dirty; Thu Dec 5 08:47:37 EST 1996 Received: from zubin.dnrc.bell-labs.com by research; Thu Dec 5 08:44:43 EST 1996 Received: from arrakis (arrakis [135.180.130.41]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id IAA03348 for ; Thu, 5 Dec 1996 08:44:44 -0500 (EST) From: Jonathan Rosenberg Message-Id: <961205084449.ZM12558@arrakis> Date: Thu, 5 Dec 1996 08:44:47 -0700 X-Mailer: Z-Mail 4.0.1 (4.0.1 Apr 9 1996) To: rem-conf@es.net Subject: Printing draft-rosenberg-itg-00.ps Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii My apologies to those people who had trouble printing the postscript version of draft-rosenberg-itg.00.ps. For some reason, some 40kB of data was truncated from the files when they were emailed to the ietf. The problem is fixed. A correct ps (and txt) version are now available from the internet-drafts directory (http://www.ietf.org/ids.by.wg/none.html). Thanks, Jonathan Rosenberg -- Jonathan Rosenberg Lucent Technologies Member of Technical Staff Bell Laboratories High Speed Networks Research 101 Crawfords Corner Rd. PHONE: (908) 949-6418 Holmdel, NJ 07733 FAX: (908) 949-9118 Rm. 4G-530 EMAIL: jdrosen@bell-labs.com From rem-conf-request@es.net Thu Dec 05 11:28:45 1996 Received: from gomez.cs.pitt.edu by osi-east.es.net with ESnet SMTP (PP); Thu, 5 Dec 1996 08:27:56 -0800 Received: from ra.cs.pitt.edu (ra.cs.pitt.edu [136.142.79.32]) by gomez.cs.pitt.edu (8.8.3/8.8.3) with ESMTP id LAA07804 for ; Thu, 5 Dec 1996 11:27:54 -0500 (EST) From: Taieb Znati Received: (from znati@localhost) by ra.cs.pitt.edu (8.8.3/8.8.3) id LAA04429 for rem-conf@es.net; Thu, 5 Dec 1996 11:27:53 -0500 (EST) Message-Id: <199612051627.LAA04429@ra.cs.pitt.edu> Subject: DMS97 CFP To: rem-conf@es.net Date: Thu, 5 Dec 1996 11:27:52 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit CALL FOR PAPERS 1997 Pacific Workshop on Distributed Multimedia Systems University of British Columbia, Vancouver, Canada July 24-25, 1997 The last few years have seen an explosive growth of multimedia computing, communication and applications. This revolution is transforming the way people live, work, and interact with each other, and is impacting the way businesses, government services, education, entertainment, and health care are operating. It is safe to say that the multimedia revolution is underway. Yet, several issues related to modeling, specification, analysis and design of distributed multimedia systems and applications are still challenging to both researchers and practitioners. The purpose of this workshop is to serve as a forum for the exchange of ideas among practicing engineers and researchers from around the world, as well as highlight current activities and important topics in the field of distributed multimedia systems and technology. The paper session is designed to promote discussion of concepts, methodologies, and results between the authors and the audience, and provide for a degree of collegiality and continuity in the discussions of these various topics among the participants. In addition, tutorials will be held on June 25 and 26 to provide participants with the opportunity to interact with experts in various fields of distributed multimedia systems. The workshop organizers seek contributions of high quality papers, panels or tutorials, addressing various aspects of distributed multimedia systems and applications, for presentation at the conference and publication in the workshop proceedings. Topics of interest include, but are not limited to: [*] Distributed Multimedia Databases and Computing [*] Multi-paradigmatic Information Retrieval [*] Modeling and Analysis of Distributed multimedia systems [*] OS Support for Distributed Multimedia systems [*] Multimedia Communications and Networking [*] Multimedia Digital Libraries and Mail Systems [*] Multimedia Human-Computer Interaction [*] Visual and Multidimensional Languages for multimedia applications [*] Multimedia Workflows [*] Multimedia Stream Synchronization [*] Virtual Reality, Virtual Environment, and their Applications The use of prototypes and demonstration video for presentations is encouraged. Workshop Site: The workshop will be held at the University of British Columbia, Vancouver, Canaca. Special arrangement will be made with local hotels for a limited number of rooms at the special workshop rate. Information for Authors: Submit four copies of panel or tutorial proposals or manuscripts (maximum of 20 double-spaced pages) including abstract, keywords and complete information of a contact person to one of the following program co-chairs: Professor Taieb Znati Dept. of Computer Science University of Pittsburgh Pittsburgh, PA 15260 USA Tel: +1 412-624-8417 Fax: +1 412-624-8854 Email: znati@cs.pitt.edu Professor An-Chi Liu Dean, College of Engineering Fong-Chia University Tai-Chung, Taiwan Tel: +886-4-252-7110 Fax: +886-4-323-9903 Email: liu@fcusqnt.fcu.edu.tw Papers, tutorials and panels can also be directly deposited by anonymous ftp at ftp.cs.pitt.edu:/pub/DMS97/Paper-Deposit. Submitted files must be in PostScript format with all figures and tables included. Important Dates: * January 15, 1996: Paper\Proposal submission deadline * March 15, 1997: Notification of acceptance * April 15, 1997: Final manuscript due Sponsored by: * Knowledge Systems Institute, USA * University of British Columbia, Canada * University of Pittsburgh, USA * Fong-Chia University, Taiwan Workshop Co-Chairs: * Son T. Vuong, University of British Columbia, Canada * S. K. Chang, University of Pittsburgh, USA Program Committee Co-Chairs: * Taieb Znati Univ. of Pittsburgh, USA * An-Chi Liu Fong-Chia University, Taiwan Local Arrangement Chair: * Panos Nasiopoulos University of British Columbia, Canada Program Committee: * Hong-Mei Chen Univ. of Hawaii, USA * Wen-Tsuen Chen National Tsing Hua University * Yanghee Choi Seoul National University * Jean-Pierre Courtiat Centre National de Recherche Scientifique, France * Gerald Neufeld University of British Columbia * Dieu D. Phan National Program on Information Technology, Vietnam * Anindya Datta University of Arizona, Tucson AZ * David H. C. Du Univ. of Minnesota, USA * Nicolas D. Georganas Depart. of Elec. and Comp. Eng., Univ. of Ottawa * Norm Hutchinson University of British Columbia BC * William Grosky Wayne State Univ., USA * Venkat N. Gudivada University of Missouri-Rolla * Arding Hsu Siemens Corporate Research, USA * Oscar Ibarra Univ. of Cal., Santa Barbara, USA * Stephen Y. Itoga University of Hawaii * Paul Lin CCL, Taiwan * Tom D.C. Little<\b> University of Boston , USA * Ralph Martinez ECE, Radiology, & Pathology Dept. Univ. of Arizona * J. Mizusawa NTT Multi-media Network Laboratories * Ming-Chien Shan Hewlett Packard Labs * Olivia R. Liu Sheng HKUST, Hong Kong * Jaideep Srivastava Univ. of Minnesota, USA * Kazuo Sugihara Univ. of Hawaii, USA * Joseph E. Urban Arizona State Univ., USA * Chun-Chia Wang Tamkang University, Taiwan, R.O.C. * Don-Lin Yang Feng Chia University, Taichung, Taiwan For additional information, please send mail to znati@cs.pitt.edu or liu@fcusqnt.fcu.edu.tw. Updated conference announcement and information are accessible by anonymous ftp at ftp.cs.pitt.edu:/pub/DMS97 or by directly accessing the conference home page at http://www.cs.pitt.edu/DMS97. From rem-conf-request@es.net Thu Dec 05 14:24:38 1996 Received: from bugs-bunny.CS.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Thu, 5 Dec 1996 11:24:04 -0800 Received: from newcs.ucsd.edu (newcs.ucsd.edu [132.239.51.18]) by bugs-bunny.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id LAA26793 for <298-list@bugs-bunny.CS.Berkeley.EDU>; Thu, 5 Dec 1996 11:09:32 -0800 Received: from empyrean.ucsd.edu (empyrean.ucsd.edu [132.239.51.61]) by newcs.ucsd.edu (8.8.3/8.8.3/External-1.4) with ESMTP id LAA24267; Thu, 5 Dec 1996 11:09:28 -0800 (PST) Received: from empyrean.ucsd.edu (localhost [127.0.0.1]) by empyrean.ucsd.edu (8.8.3/8.8.3/Internal-1.1) with ESMTP id LAA15016; Thu, 5 Dec 1996 11:09:27 -0800 (PST) Message-Id: <199612051909.LAA15016@empyrean.ucsd.edu> To: Mark Handley cc: David Simpson , 298-list@bugs-bunny.CS.Berkeley.EDU, hopper@cs.ucsd.edu Subject: Re: UCB Multimedia Seminar update In-reply-to: Your message of "Wed, 04 Dec 1996 21:11:28 EST." <16463.849751888@mercury.lcs.mit.edu> Date: Thu, 05 Dec 1996 11:09:24 -0800 From: Steve Hopper This probably explains why SDR displays fewer entries during the day, which then appear again in the evening. The next day the entries again diminish to ~ half the number. Steve -------- In reply to the following message: -------- > >>I have been getting reports from a few people that they are not >>receiving the seminar announcement. I'm not sure if this is a problem on >>their end, on our end, or the fact that I'm using the sapAnnouncer to make >>the announcements instead of sdr. At any rate, here is the correct > >This is probably mrouted rate-limiter overload. For historic reasons >sdr announces sessions in the low-priority range, and recently we've >seen a lot more mbone traffic than we have historically, so >low-priority traffic is often getting lost. Basically 512Kbps is >not sufficient anymore and that;'s the default rate-limiter in mrouted. > >Mark -------- From rem-conf-request@es.net Thu Dec 05 16:22:22 1996 Received: from cs.nps.navy.mil by osi-east.es.net with ESnet SMTP (PP); Thu, 5 Dec 1996 13:21:49 -0800 Received: from capella.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA16248; Thu, 5 Dec 96 13:16:39 PST From: brutzman@cs.nps.navy.mil (Don Brutzman) Received: by capella.cs.nps.navy.mil (4.1) id AA16144; Thu, 5 Dec 96 13:16:32 PST Message-Id: <9612052116.AA16144@capella.cs.nps.navy.mil> Subject: ANNOUNCE: VRML 97 To: ietf@cnri.reston.va.us (IETF "big Internet" list), mbone@isi.edu (Multicast Backbone mail list), rem-conf@es.net (Remote Conferencing mail list), lsma@gmu.edu (Large Scale Multicast Application WG) Date: Thu, 5 Dec 1996 13:16:31 -0800 (PST) Cc: ljohnson@redshift.com (Lynn Johnson) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Content-Length: 14597 [standard apologies if you receive duplicate copies] You are cordially invited to attend the second annual Virtual Reality Modeling Language (VRML) Symposium. VRML is where 3D graphics meets the Web. Internetworking considerations are thus just as important as interactive 3D in this context. A schedule and list of papers/courses/panels follows the press release. Queries welcome. Thanks! - Don Brutzman FOR MORE INFORMATION CONTACT: Lynn Johnson Evans & Johnson 408 655 9924 408 372 0846 fax ljohnson@redshift.com FOR IMMEDIATE RELEASE VIRTUAL REALITY MODELING LANGUAGE (VRML) SYMPOSIUM SET FOR FEBRUARY 1997 Monterey, California, November 25, 1996 - The Second Annual Virtual Reality Modeling Language (VRML) Symposium is scheduled for February 24-26, 1997 at the Hyatt Regency in Monterey, California. VRML 97 is an academic and technical symposium sponsored by ACM SIGGRAPH and SIGCOMM, in cooperation with the VRML Consortium. This year's VRML Symposium provides a wide range of technical papers, educational opportunities, cutting-edge demonstrations and exhibits featuring the latest in VRML technology. The VRML Symposium home page is http://www.sdsc.edu/vrml97 Who and What. 300-500 attendees from across the globe are expected to attend this powerful 3-day technical symposium. Attendees can attend half-day or full-day tutorials, which are designed for both intermediate and advanced VRML users and developers. The Symposium also includes working groups, panels, academic papers and in-depth exhibitor demonstrations. Topics include 3D graphics, content, behaviors, interfaces, modeling, simulation, multi-user environments, networking and standards. Why. "VRML 97 is the future of 3D on the World Wide Web," says VRML 97 chair Don Brutzman. "All of the most exciting work in internetworked 3D graphics will be shown, discussed and argued over by key players in this fast-moving community. Don't miss it!" Courses. The first day (Monday, Feb 24) will feature both full-day and half-day tutorial courses. The first full-day course is "Introduction to VRML 2.0" presented by Dave Nadeau of the San Diego Supercomputer Center. This course, designed for beginning graphics users, will teach attendees how to use VRML to author their own 3D virtual worlds on the World Wide Web. "Authoring Compelling, Efficient VRML 2.0 Worlds" presented by Dave Story, Delle Maxwell and David Marsland, all of Silicon Graphics, is another full day tutorial course. This course provides authors with a concrete toolset for overcoming the limitations and exploring the unique capabilities of VRML 2.0. Attendees will learn new approaches to solve their creative challenges. More Courses. Half-day tutorials include "The VRML 2.0 Compressed Binary Format" presented by Gabriel Taubin, Bill Horn and Francis Lazarus, all with IBM. This course will familiarize attendees with the fundamentals of the compression technologies proposed for the VRML 2.0 standard. Another half-day tutorial is "Sound Bytes VRML Authoring for Noisy Worlds" presented by Geoff Brown of Silicon Graphics Inc. This course features demonstrations that show effective use of sound in large and small worlds and are presented using both PC and SGI platforms. This tutorial is suitable for beginners and intermediate developers. "Networking Services for Shared Virtual Worlds" presented by Eric Hoffman is offered as a beginning networking tutorial. This course will be extremely helpful for those who are considering the design of distributed virtual worlds, but are unfamiliar with recent work in transport protocols. Exhibitors. More than 30 companies will demonstrate the latest tools, technology and software at the exhibitor's showcase on Tuesday and Wednesday (Feb 25-26). The exhibitor's showcase serves as a primary resource to learn about the latest VRML products. Not an exhaustive trade show, this group includes only the best and brightest VRML developers giving one-on-one demos of new and forthcoming work to the most influential people working in VRML. An exhibitors' planning guide including detailed descriptions of products and services will be distributed to all attendees. Technical Program. Tuesday and Wednesday's program includes paper presentations and panels. A solid and highly select set of academic papers show research work and results that may affect the future of the VRML standard. Industry experts will explain and debate controversial topics from a variety of viewpoints. A complete listing of sessions and panels is available at http://www.sdsc.edu/vrml97/schedule.html Event: Demo SIG. All Symposium attendees are invited to the no-holds-barred Demo SIG hosted by the Virtual Reality Education Foundation (VeRGe). This exciting two-hour presentation, scheduled 5pm Monday (Feb 24), is an intense series of live 5-minute internetworked 3D demonstrations. This event was one of the highlights of SIGGRAPH in New Orleans August 1996. The Demo SIG is followed by a dinner and reception hosted by Microsoft Corporation. Event: Aquarium Dinner. Tuesday evening's activities include dinner in front of the Monterey Bay Aquarium's new 1.2 million gallon Outer Bay exhibit. Attendees will enjoy a strolling dinner in front of the largest viewing window in the world. This spectacular and intense exhibit is 35 feet deep, 90 feet long, holds over 1 million gallons of water and houses animals rarely viewed, such as the giant tunas, ocean sunfish, a green sea turtle and soupfin sharks. Attendees also will have private access to the world's largest exhibit of jellyfish, including transparent crystal jellies and bioluminescent comb jellies. This exciting evening is hosted by Silicon Graphics Inc. VRML Consortium. The long-term future of VRML has always been a key question. AT VRML 97, the newly elected VRML Consortium Board of Directors will report on efforts to make VRML an integral part of the Internet infrastructure. The VRML Consortium is a non-profit group made up of corporate and academic organizations, all working together to promote VRML standards, outreach and education. VRML 97 Committee. Chair Don Brutzman, papers chairs Rikk Carey and Paul Strauss, Mitra, Adrian Scott, Glenn Crocker, Stephen Spencer, Bill Cockayne, Erkan Akyuz, Dan Ancona, Clark Dodsworth, D.J. LeGoff, Kent Watsen, Robert Saint John, Lisa Goldman, Mark Meadows, Mark Pesce, David Nadeau, Timothy Childs, Gray Schlichting, Gavin Bell, Jean-Francis Balaguer, Jan Hardenbergh, David Kerlick, Stephen Matsuba, Tamara Munzner, Tom Meyer, Tony Parisi, Erika Whiteway, Dick Puk and Val Watson. Individual committee positions & e-mail addresses of these expert volunteers are available at http://www.sdsc.edu/vrml97/committee.html Lodging and Registration. The Hyatt Regency Monterey is headquarters hotel for VRML 97. For registration info, please refer to the VRML 97 home page http://www.sdsc.edu/vrml97/register.html or contact Lynn Johnson at 408-655-9924 or ljohnson@redshift.com Early-bird registration discounts are available through December 15 1996, prices jump sharply thereafter. END RELEASE VRML 97 FEBRUARY 24-26, 1997 HYATT REGENCY HOTEL MONTEREY CALIFORNIA USA http://www.sdsc.edu/vrml97/schedule.html SCHEDULE SUNDAY, FEBRUARY 23, 1997 * Working group meetings by request (Hyatt or NPS) * 12:00 PM Exhibitor setup open (prior request only, until 5) * 13:00 PM VRML Consortium Board of Directors (private) * 5:00 PM Registration open (refreshments available) * 6:00 PM Sponsors reception (private) * 9:00 PM Registration closed MONDAY, FEBRUARY 24, 1997 * 7:00 AM Registration opens * 7:30 AM Continental breakfast (if sponsored) * 8:00 AM Exhibitor & AV setup open * 8:30 AM Full-Day Courses + Introduction to VRML 2.0, Dave Nadeau, San Diego Supercomputer Center + Authoring Compelling, Efficient VRML 2.0 Worlds, Dave Story, Delle Maxwell and David Marsland, Silicon Graphics Inc. * 8:30 AM Half-Day Courses + The VRML 2.0 Compressed Binary Format, Gabriel Taubin, Bill Horn and Francis Lazarus, IBM * 8:30 AM Working groups (TBD - to be determined) * 10:00 AM Break * 10:30 AM Courses & working groups resume * 12:00 PM Lunch (box lunch or buffet TBD) * 1:00 PM Half-Day Courses + Networking Services for Shared Virtual Worlds, Eric Hoffman, National Laboratory for Applied Network Research / Ipsilon + Sound Bytes VRML Authoring for Noisy Worlds, Geoff Brown, Silicon Graphics Inc. * 1:00 PM Working groups (TBD) * 2:30 PM Break * 3:00 PM Courses & working groups resume * 4:00 PM Demo SIG and AV rehearsal (ballroom) * 4:30 PM Break * 5:00 PM Demo SIG (ballroom) * 7:00 PM Dinner & Reception at the Hyatt (sponsored) TUESDAY, FEBRUARY 25, 1997 * 7:00 AM Registration opens * 7:15 AM Continental breakfast (if sponsored) * 8:15 AM Welcome * 8:30 AM Papers: Implementation I, Val Watson moderator + Using spatial techniques to decrease message passing in a distributed VE system, Olof Hagsand, Rodger Lea and Marten Stenius, Swedish Institute of Computer Science (SICS) and Sony Computer Science Lab + An Object Oriented Approach to VRML Development, Curtis A. Beeson, Silicon Graphics Inc. + Object-Oriented VRML for Multi-user Environments, Sungwoo Park * 10:00 AM Break * 10:00 AM Exhibits open * 10:30 AM Papers: Multi-user, Dave Nadeau moderator + Populating the Internet: Supporting Multiple Users and Shared Applications with VRML, Wolfgang Broll, German National Institute for Information Technology + Community Place: architecture and performance, Rodger Lea, Yasuaki Honda, Kouichi Matsuda and Satoru Matsuda, Sony Computer Science Lab + SpaceFusion: A multi-server architecture for shared virtual environments, Hiroyasu Sugano, Fujitsu * 12:00 PM Consortium Report: Elected VRML Consortium Inc. Board of Directors * 12:30 PM Lunch * 2:00 PM Papers: Navigation and User Interface, Dave Kerlick moderator + QOTA: A Fast, Multi-Purpose Algorithm For Terrain Following in Virtual Environments, John W. Barrus and Richard Waters, Mitsubishi Electric Research Laboratory + MaPS: Movement and Planning Support for Navigation in an Immersive VRML Browser, John Edwards and Chris Hand, De Montfort University, Leicester UK + Adapting VRML 2.0 for Immersive Use, Randy Stiles, Sandeep Tewari and Mihir Mehta, Lockheed Martin Advanced Technology Center * 3:30 PM Break * 4:00 PM Panel: Avatar and Multi-user Standards, Moderator Bernie Roehl - University of Waterloo, Mitra - ParaGraph, David Anderson - MERL, Yasuaki Honda - Sony Computer Science Lab, et al. * 5:00 PM Panel: Using Java as a VRML development platform, Moderator: Michael Stein - Protozoa, Chris Marrin - SGI, Chris Laurel - Dimension X, Rodger Lea - Sony Computer Research Laboratory, et al. * 6:00 PM Break * 6:00 PM Exhibits close * 6:45 PM Motorcoaches depart for Monterey Bay Aquarium * 7:00 PM Monterey Bay Aquarium Dinner & Entertainment (sponsored) * 11:00 PM Motorcoach shuttle back to hotel WEDNESDAY, FEBRUARY 26, 1997 * 7:00 AM Registration opens * 7:30 AM Continental breakfast (if sponsored) * 8:30 AM Plenary speaker (TBD) * 9:15 AM Working group reports + ISO Standardization and Conformance + Multi-user / Avatars + Databases + TBD * 10:00 AM Break * 10:00 AM Exhibits open * 10:30 AM Papers: Case Studies, Tamara Munzner moderator + The Out of Box Experience: Lessons learned creating compelling VRML 2.0 content, Sam Chen, Rob Myers and Rick Pasetto, Silicon Graphics Inc. + Networked VR System: Kitchen Layout Design for Customers, Tomohiro Fukuda, Ryuichiro Nagahama and Junji Nomura, Matsusita Electric Works Ltd. + Animation for Performance Debugging of Parallel Computing Systems, Noritaka Osawa, Hisaya Morita and Toshitsugu Yuba, The University of Electro-Communications, Japan + Using VRML to Access Manufacturing Data, Sandy Ressler, Qiming Wang, Scott Bodarky, Charles Sheppard and Gregory Seidman, National Institute of Standards and Technology * 12:30 PM Lunch * 2:00 PM Papers: Implementation II, Dick Puk moderator + V-COLLIDE: Accelerated Collision Detection for VRML, Tom Hudson, Ming C. Lin, Jon Cohen, Stefan Gottschalk and Dinesh Manocha, University of North Carolina + Lodestar: An Octree-Based Level of Detail Generator for VRML, Dieter Schmalstieg, Vienna University of Technology, Austria + Wired for Speed: Efficient Routes for VRML 2.0, Daniel Woods, Alan Norton and Gavin Bell, Silicon Graphics Inc. and Wazabi * 3:00 PM Exhibits close, tear down * 3:30 PM Break * 4:00 PM Panel: Dynamic and Personalized Worlds: Database Integration, Daniel Lipkin - Oracle, Clay Graham - Big Book, Adrian Scott - VRMLSite, et al. * 5:00 PM Panel: User Interface Design for Digital Space: 3d Navigation and Manipulation, Moderator: Bernie Roehl - University of Waterloo, Maclen Marvit - Worlds Inc., James Waldrop - Construct, Mark Pesce, et al. * 6:00 PM Symposium complete * 7:00 PM Dinner on own THURSDAY, FEBRUARY 27, 1997 * Working group meetings by request (Hyatt or NPS) Additional questions? Please contact: Lynn Johnson Evans & Johnson P.O. Box 51621 Pacific Grove, California 93950 USA 408.655.9924 voice, 408.372.0846 fax ljohnson@redshift.com all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman From rem-conf-request@es.net Thu Dec 05 17:58:19 1996 Received: from bugs-bunny.CS.Berkeley.EDU by osi-east.es.net with ESnet SMTP (PP); Thu, 5 Dec 1996 14:57:41 -0800 Received: from broon.off.connect.com.au (broon.off.connect.com.au [203.63.69.1]) by bugs-bunny.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id OAA27976 for <298-list@bugs-bunny.cs.berkeley.edu>; Thu, 5 Dec 1996 14:40:40 -0800 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id IAA22918 (8.7.6h/IDA-1.6); Fri, 6 Dec 1996 08:39:08 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs To: Steve Hopper cc: Mark Handley , David Simpson , 298-list@bugs-bunny.CS.Berkeley.EDU Subject: Re: UCB Multimedia Seminar update In-reply-to: Your message of "Thu, 05 Dec 1996 11:09:24 PST." <199612051909.LAA15016@empyrean.ucsd.edu> Date: Fri, 06 Dec 1996 08:39:07 +1000 Message-ID: <22914.849825547@connect.com.au> From: George Michaelson If observable fact is that 512k is saturated, and sdr is using low-priority grade, this introduces a 2x2 matrix of choices. Why should the mbone remain capped at an informal 512k? I think there are good reasons to do this: Its still an appropriate level of b/w for the IETF class of event, and there are still a lot of constrained b/w links in the backbones worldwide. Others might disagree. Why should sdr remain in the low-priority grade? I think this is wrong, and it should be treated as a higher priority packetflow. I've also stated many times that I regard the re-announcement/backoff curve as being inappropriate and I've been told the model encompasses a tiered tree of broadcasts where local horizons might be more frequent, but I think there are still problems in terms of pre-announcing sessions, and the need to increase the announce rate markedly in a window surrounding the start-time of the session when human factors indicate the vast mass of casual users actually start sdr, and need to see sessions announced. I don't see problems with both changing at once, but It seems to me changing SDR now is simpler than changing the 512k rate limit default, and probably more sensible in this specific context. Saturation will exist regardless of bandwidth somewhere, and I think session announcements should have more priority. cheers -George From rem-conf-request@es.net Thu Dec 05 21:07:00 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 5 Dec 1996 18:06:29 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA09187; Thu, 5 Dec 1996 18:06:27 -0800 Date: Thu, 5 Dec 1996 18:06:27 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: AVT Agenda Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII AVT Working Group: Enclosed below is my proposed agenda for the two AVT sessions at IETF next week in San Jose. I think I have included all the requested topics, except for those related to reliable multicast since the Area Directors will be separately addressing that problem in the Open Transport Services Area Directorate meeting (Wednesday at 13:00). Comments on the agenda continue to be welcome. We can also make adjustments at the start of the session as appropriate. -- Steve Casner Audio/Video Transport WG A G E N D A Tuesday, December 10, 15:30-17:30 - Introduction and status 5 - RTCP scaling to large groups 60 - Summary of issues [Aboba] - Simulation results, proposals [Schulzrinne] - Discussion - Changes needed to protocol specs - Experimentation needed - Request for liaison with T1A1.5 [Klenke] 5 - IP/UDP/RTP header compression 30 - Protocol changes since Montreal [Casner] - Implementation results [Leelanivas] - Transport aspects of RTSP Proposal 20 Wednesday, December 11, 19:30-22:00 - RTP payload formats - Redundant encodings to Prop. Std. [Perkins] 5 - Revisions to payload format for G.723 [Zhu] 10 - Problems with MPEG2 payload format [Civanlar] 20 - Adding G.728 to Profile [Casner] 5 - New applications of RTP - RTP and reliable multicast [Casner] 10 (reference to OTSV session) - Payload format for HTTP - Adding SRM to RTP - Using RTP with caching [Kermode] 20 - Aggregation of media streams [Rosenberg] 20 - Status report on RTP MIB [Naudus] 5 - Advancing RTP to Draft Standard [Casner] 15 - Any changes for RTCP scaling? - Changes proposed for layered encodings - Edits to loop/collision algorithm - Proof of interoperability requirements - Advancing RTP Profile to Draft Standard [Casner] 15 - Should A/V profile specify CNAME format? - Future work 10 From rem-conf-request@es.net Fri Dec 06 07:46:01 1996 Received: from fun.inria.fr by osi-east.es.net with ESnet SMTP (PP); Fri, 6 Dec 1996 04:45:27 -0800 Received: by fun.inria.fr (8.8.3/8.6.12) id NAA08965; Fri, 6 Dec 1996 13:44:50 +0100 (MET) Message-Id: <199612061244.NAA08965@fun.inria.fr> X-Mailer: exmh version 1.6.7 5/3/96 To: rem-conf@es.net cc: Colin Perkins Subject: Conference bus X-url: http://www.inria.fr/rodeo/avega.html Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Dec 1996 13:44:49 +0100 From: Andres Vega Garcia Hello, I want to find out if there have being any further work about defining a control bus to allow applications in a given host to exchange control information? The only paper I have is that describing "CCCP: Conference Control Channel Protocol" from Handley and Wakeman, but the trail in CCCP seems to be stoped there. Is somebody else working on this? Is there any technical report/article available from the people at LBL about the multicast bus implemented in vat and vic? : Colin Perkins wrote: >Not sure about the LBL folks, but here at UCL we're working on adding >conference bus support to RAT, with the aim of allowing easy integration >of the tool into a unified user interface (son of the ReLaTe project [1]), >and to allow remote control of the tool. It is our desire to make this >compatible with future versions of vic/vat/etc... Colin, do you have a specification of your "conference bus"? I want to add that kind of capability to Free Phone, and stay compatible with others applications. Thank you. -Andres From rem-conf-request@es.net Fri Dec 06 07:54:34 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Fri, 6 Dec 1996 04:54:06 -0800 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 6 Dec 1996 12:52:05 +0000 To: Andres Vega Garcia cc: rem-conf@es.net, mjh@isi.edu, mccanne@eecs.berkeley.edu Subject: Re: Conference bus In-reply-to: Your message of "Fri, 06 Dec 1996 13:44:49 +0100." <199612061244.NAA08965@fun.inria.fr> Date: Fri, 06 Dec 1996 12:51:59 +0000 Message-ID: <1117.849876719@cs.ucl.ac.uk> From: Colin Perkins --> Andres Vega Garcia writes: > Hello, I want to find out if there have being any further work about >defining a control bus to allow applications in a given host to >exchange control information? There has been some discussion between UCL, Mark Handley and Steve McCanne's group about a successor to CCCP and the LBL conference bus. At present this is in a very preliminary state, and not yet ready for presentation to a wider audience, however I expect further discussion will take place next week, and hopefully we can come up with something more concrete. Colin From rem-conf-request@es.net Fri Dec 06 13:38:49 1996 Received: from alpha.xerox.com by osi-east.es.net with ESnet SMTP (PP); Fri, 6 Dec 1996 10:37:59 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <19377(2)>; Fri, 6 Dec 1996 10:37:38 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177711>; Fri, 6 Dec 1996 10:37:22 -0800 To: Andres Vega Garcia cc: rem-conf@es.net, Colin Perkins Subject: Re: Conference bus In-reply-to: Your message of "Fri, 06 Dec 96 04:44:49 PST." <199612061244.NAA08965@fun.inria.fr> Date: Fri, 6 Dec 1996 10:37:18 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <96Dec6.103722pst.177711@crevenia.parc.xerox.com> I was curious to see what messages got passed on the conference bus, so I wrote the following application. It might help you some (and, of course, reading the vic/vat source code doesn't hurt either). "confbus" by itself will print the messages on the common bus, "confbus N" will print the messages on IPC channel N (e.g. vic -I N) Bill /* * confbus.c * * usage: * confbus * prints out messages on common IPC channel * confbus N * prints out messages on IPC channel #N (e.g. vic -I N) */ #include #include #include #include #include #define GROUP_IPC_ADDR 0xe0ffdeef #define GROUP_IPC_PORT 0xdeaf #define GIPC_MAGIC 0x0ef5ee0a struct gipc { int magic; short type; short pid; char buf[1]; }; int main(argc, argv) int argc; char **argv; { int s; int on = 1; struct ip_mreq mr; struct sockaddr_in sin; char buf[1024]; struct gipc *g = (struct gipc *)buf; int i; if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { perror("socket"); exit(1); } if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)) < 0) { perror("SO_REUSEADDR"); exit(1); } mr.imr_multiaddr.s_addr = htonl(GROUP_IPC_ADDR); mr.imr_interface.s_addr = INADDR_ANY; if (setsockopt(s, IPPROTO_IP, IP_ADD_MEMBERSHIP, &mr, sizeof(mr)) < 0) { perror("IP_ADD_MEMBERSHIP"); exit(1); } sin.sin_family = AF_INET; sin.sin_addr.s_addr = htonl(GROUP_IPC_ADDR); sin.sin_port = GROUP_IPC_PORT; if (argc == 2) { sin.sin_port += atoi(argv[1]); } sin.sin_port = htons(sin.sin_port); if (bind(s, &sin, sizeof(sin)) < 0) { perror("bind to confbus"); exit(1); } while(1) { i = recv(s, buf, sizeof(buf) - 1, 0); if (i < 0) { perror("recv"); exit(1); } if (ntohl(g->magic) != GIPC_MAGIC) { printf("non-GIPC msg\n"); continue; } /* for (j = 0, p = buf; j < i; j++) { printf("%02X ", (unsigned char)*p++); } printf("\n"); */ if (i == 12) { /* backwards compatibility with old vat */ struct in_addr a; a.s_addr = *((int *)(g->buf)); sprintf(g->buf, "focus %s", inet_ntoa(a)); } printf("%d %d %s\n",ntohs(g->type), ntohs(g->pid), g->buf); } } From rem-conf-request@es.net Fri Dec 06 14:01:00 1996 Received: from er5.rutgers.edu by osi-east.es.net with ESnet SMTP (PP); Fri, 6 Dec 1996 11:00:25 -0800 Received: (from pineaple@localhost) by er5.rutgers.edu (8.6.12+bestmx+oldruq+newsunq/8.6.12) id OAA07337 for rem-conf@es.net; Fri, 6 Dec 1996 14:00:18 -0500 Date: Fri, 6 Dec 96 14:00:17 EST From: fruit salad To: rem-conf@es.net Message-ID: subscribe M-BONE Remote Conferencing Rosa Costanzo From rem-conf-request@es.net Sat Dec 07 18:42:36 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Sat, 7 Dec 1996 15:42:06 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA13210; Sat, 7 Dec 1996 15:42:05 -0800 Date: Sat, 7 Dec 1996 15:42:04 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: Updated AVT agenda Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII AVT Working Group: Here's an updated agenda. Due to a brain short I wrote G.723 when I meant H.263, and I've added an item under Draft Standard transition about allowing separate addresses for RTP and RTCP prompted by a question from Deborah Estrin. I also added the associated reading which I forgot the first time. -- Steve Casner Audio/Video Transport WG A G E N D A Tuesday, December 10, 15:30-17:30 - Introduction and status 5 - RTCP scaling to large groups 60 draft-aboba-rtpscale-00.txt & rem-conf list - Summary of issues [Aboba] - Simulation results, proposals [Schulzrinne] - Discussion - Changes needed to protocol specs - Experimentation needed - Request for liaison with T1A1.5 [Klenke] 5 - IP/UDP/RTP header compression 30 draft-ietf-avt-crtp-01.txt - Protocol changes since Montreal [Casner] - Implementation results [Leelanivas] - Transport aspects of RTSP Proposal 20 draft-ietf-mmusic-rtsp-00.txt draft-ietf-mmusic-stream-00.txt,ps Wednesday, December 11, 19:30-22:00 - RTP payload formats - Redundant encodings to Prop. Std. [Perkins] 5 draft-perkins-rtp-redundancy-01.txt - Revisions to payload format for H.263 [Zhu] 10 draft-ietf-avt-rtp-payload-02.txt - Problems with MPEG2 payload format [Civanlar] 20 RFC 2038, draft-civanlar-bmpeg-00.txt - Adding G.728 to Profile [Casner] 5 - New applications of RTP - RTP and reliable multicast [Casner] 10 (reference to OTSV session) - Payload format for HTTP draft-aboba-rtp-http-01.txt - Adding SRM to RTP draft-parnes-rtp-ext-srm-01.txt - Using RTP with caching [Kermode] 20 - Aggregation of media streams [Rosenberg] 20 draft-rosenberg-itg-00.txt,ps - Status report on RTP MIB [Naudus] 5 - Advancing RTP to Draft Standard [Casner] 30 RFC 1889 - Any changes for RTCP scaling? - Changes proposed for layered encodings draft-speer-avt-layered-video-01.txt - Allowing separate addresses for RTP/RTCP - Edits to loop/collision algorithm - Proof of interoperability requirements - Advancing RTP Profile to Draft Standard [Casner] 15 RFC 1890 - Should A/V profile specify CNAME format? - Future work 10 From rem-conf-request@es.net Sun Dec 08 00:54:00 1996 Received: from emout15.mail.aol.com (actually emout15.mx.aol.com) by osi-east.es.net with ESnet SMTP (PP); Sat, 7 Dec 1996 21:53:22 -0800 Received: by emout15.mail.aol.com (8.6.12/8.6.12) id AAA07584; Sun, 8 Dec 1996 00:53:20 -0500 Date: Sun, 8 Dec 1996 00:53:20 -0500 From: MsMegan@aol.com Message-ID: <961208005319_707848430@emout15.mail.aol.com> To: freixg@wwgv.com, Videophone@es.net, rem-conf@es.net Subject: Re: Videoconferencing/Video Telephones Greg, There are two books on videoconferencing that I would highly recommend to anyone that is doing research on videoconferencing: "Videoconferencing the Whole Picture" by Toby Trowt-Bayard " Personal Videoconferencing" by Evan Rosen Both books can be purchased through Global Videoconferencing Solutions at a discount. They can be reached at 1-800-909-4874 or via the internet at GVSI@aol.com. I believe the have a web site somewhere, but I don't have the URL for it. Megan In a message dated 96-12-06 09:01:31 EST, freixg@wwgv.com (Gregory D. Freix) writes: << Subj: Videoconferencing/Video Telephones Date: 96-12-06 09:01:31 EST From: freixg@wwgv.com (Gregory D. Freix) To: Videophone@es.net I am doing some preliminary research on these subjects. I would be most appreciative of any information you might have on them....or related topics, such a various compression technologies, etc. Thanks very much. Greg Freix >> From rem-conf-request@es.net Sun Dec 08 02:34:35 1996 Received: from netra (actually netra.nju.edu.cn) by osi-east.es.net with ESnet SMTP (PP); Sat, 7 Dec 1996 23:33:28 -0800 Received: from 202.119.36.190 ([202.119.36.190]) by netra (5.x/SMI-SVR4) id AA25641; Sun, 8 Dec 1996 15:23:18 -0800 Message-Id: <32AA6D9D.78F1@nju.edu.cn> Date: Sun, 08 Dec 1996 15:26:21 +0800 From: WANG Jian Reply-To: fyzhang@netra.nju.edu.cn Organization: NJU X-Mailer: Mozilla 2.0 (Macintosh; I; PPC) Mime-Version: 1.0 To: GVSI@aol.com Cc: rem-conf@es.net, Videophone@es.net Subject: Videoconferencing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, everyone in this list: I'm a new one, and doing some research work on multipoint videoconferencing. I hope someone help me some technical materials. I want to know how or where(Internet Web) I can get the two book: "Videoconferencing the Whole Picture" by Toby Trowt-Bayard " Personal Videoconferencing" by Evan Rosen Thanks a lot. WANG Jian From rem-conf-request@es.net Sun Dec 08 16:26:56 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Sun, 8 Dec 1996 13:26:26 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA14060; Sun, 8 Dec 1996 13:26:20 -0800 Date: Sun, 8 Dec 1996 13:26:19 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: Questions/issues for AVT discussion Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have a few additional questions/issues to consider for discussion in the AVT working group meeting. First, I have received a few comments regarding the IP/UDP/RTP header compression draft: - I added several references to the IPv6 header compression draft, but I neglected to mention where the RANDOM fields from encapsulating headers would be inserted into the COMPRESSED_RTP and COMPRESSED_UDP headers. It is proposed that these fields should follow immediately after the UDP checksum just as they follow the TCP checksum for TCP header compression with IPv6. - The encoding for number deltas does not include any provision for negative numbers, so out-of-order packets cause the RTP header to be sent uncompressed (IP and UDP can still be compressed). There are some holes in the encoding space where it would be possible to insert encodings for negative numbers, but that would make the code path longer with a traditional implementation. Should this be done? Van Jacobson suggests a table-based implementation, which would allow the encoding to evolve in the future to full entropy encoding, even with dynamically tables downloaded from the compressor. - This compression scheme is targeted primarily at low-bandwidth links for which 256 contexts should be sufficient. It has been suggested, however, that the context ID be changed to a variable length to allow a larger space for high-speed links. Again, this is a complexity/flexibility tradeoff. Comments? Second, in the update to the agenda I added an item under Draft Standard transition about the possibility of changing the RTP spec to allow separate multicast addresses for RTP and RTCP and perhaps even different multicast addresses for RTCP sender and receiver reports. This question was posed by Deborah Estrin. The motivation for using different addresses is to allow source-specific multicast pruning to control delivery of RTP data and the corresponding RTCP sender reports, while allowing RTCP receiver reports to still get through. The RTP spec attempts to be a general-enough framework to allow variations for different applications. This would be a further generalization requiring only a small change to the document. The choice of using one address or multiple addresses would usually be constrained by a Profile since a consistent choice is required for interoperation. So, the question is, are there negative ramifications that outweigh the potential benefits? Third, is question whether the A/V Profile should specify a particular RTCP SDES CNAME format. Again to be general over a variety of applications, the RTP specification only states a set of properties as requirements for the CNAME. The spec suggests that either the fully-qualified domain name or numeric address of the host be used, with the latter preferred because in many environments it is difficult or impossible to reliably get a FQDN all the time. If the CNAME is to be used, for example, to pair up audio and video sources to be synchronized, then the format must be the same for both media. If those media come from separate tools, the CNAMEs may not match, as is the case when the RAT audio tool is paired with the vic video tool. Should the profile constrain the format? -- Steve From rem-conf-request@es.net Mon Dec 09 03:29:25 1996 Received: from relay0.jaring.my by osi-east.es.net with ESnet SMTP (PP); Mon, 9 Dec 1996 00:27:30 -0800 Received: from walsin.UUCP (root@localhost) by relay0.jaring.my (8.6.13/8.6.12) with UUCP id PAA17116; Mon, 9 Dec 1996 15:57:56 +0800 Received: by walsin.com.my (UUPC/extended 1.12p); Mon, 09 Dec 1996 15:52:26 +0200 Message-ID: <32ac199a.walsin@walsin.com.my> From: ShouJen To: GVSI@aol.com, fyzhang@netra.nju.edu.cn Date: Mon, 9 Dec 1996 15:48:12 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Videoconferencing Reply-to: sjn@walsin.com.my CC: rem-conf@es.net, Videophone@es.net X-Confirm-Reading-To: sjn@walsin.com.my X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail for Windows (v2.42a) Hi there, If anyone has anyone any information regarding those two books, I would appreciate if you could copy an email to me. Thanks! > Hi, everyone in this list: > I'm a new one, and doing some research work on multipoint > videoconferencing. I hope someone help me some technical materials. > I want to know how or where(Internet Web) I can get the two book: > > "Videoconferencing the Whole Picture" by Toby Trowt-Bayard > " Personal Videoconferencing" by Evan Rosen > > Thanks a lot. > WANG Jian > -------------------------------------------------------------- Shou-Jen Ng Walsin Technology Corporation (M) Sdn. Bhd. Voice: 603-9857800 Fax : 603-9857011 email : sjn@walsin.com.my From rem-conf-request@es.net Mon Dec 09 06:54:53 1996 Received: from enterprise.pulver.com by osi-east.es.net with ESnet SMTP (PP); Mon, 9 Dec 1996 03:53:58 -0800 Received: (from jeff@localhost) by enterprise.pulver.com (8.6.12/8.6.12) id GAA04475; Mon, 9 Dec 1996 06:53:57 -0500 Date: Mon, 9 Dec 1996 06:53:57 -0500 (EST) From: Jeff Pulver To: rem-conf@es.net Subject: 1996 Vote for Top VON Products of 1996 (www.von.com/vonvote.htm) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi There, I've opened up voting for the top VON products of 1996 at http://www.von.com/vonvote.htm The results will be posted the first week of January, 1997. This year there are two different categories - Internet Telephony and Streaming Audio/Video products. If there is a VON product you would like to vote on which isn't listed - please enter it in the "write-in" section and I will add that product to the general product lists. Best Regards, Jeff Pulver Tel. 516.487.1424 Publisher Fax. 516.487.7269 The Pulver Report http://www.pulver.com From rem-conf-request@es.net Mon Dec 09 19:20:19 1996 Received: from moon (actually moon.bjnet.edu.cn) by osi-east.es.net with ESnet SMTP (PP); Mon, 9 Dec 1996 16:19:44 -0800 Received: by moon (5.x/SMI-SVR4) id AA05752; Tue, 10 Dec 1996 08:19:38 +0800 Date: Tue, 10 Dec 1996 08:19:38 +0800 From: cheng@moon.bjnet.edu.cn (Yan Cheng) Message-Id: <9612100019.AA05752@moon> To: rem-conf@es.net Subject: Why did Voice over Internet boom just now? Hi Friends, During recent weeks I have read some books and other materials about tranmitting voice over packetized networks. After reading, I feel puzzled. From this materials, we can know that the research and experiments related with voice over packet networks or aimed to achieve real-time communication of voice over packet networks has been done since the 70's, while more enough work has been done. But why just now, the late of 90's, this field began to cause researchers to pay serious attention to and to boom? What was short of in the 70's? What was the most crucial question? Regards, 12/10/96 From rem-conf-request@es.net Mon Dec 09 20:19:13 1996 Received: from engr.orst.edu by osi-east.es.net with ESnet SMTP (PP); Mon, 9 Dec 1996 17:18:35 -0800 Received: from ia.ENGR.ORST.EDU (ia.ENGR.ORST.EDU [207.98.118.25]) by engr.orst.edu (8.8.3/8.8.3) with ESMTP id RAA09062; Mon, 9 Dec 1996 17:18:31 -0800 (PST) Received: from localhost by ia.ENGR.ORST.EDU (1.39.111.2/ENGR-Client) id AA038360711; Mon, 9 Dec 1996 17:18:31 -0800 Date: Mon, 9 Dec 1996 17:18:30 -0800 (PST) From: Stephane Chatre To: Yan Cheng Cc: rem-conf@es.net Subject: Re: Why did Voice over Internet boom just now? In-Reply-To: <9612100019.AA05752@moon> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 10 Dec 1996, Yan Cheng wrote: > > During recent weeks I have read some books and other materials about tranmitting > voice over packetized networks. After reading, I feel puzzled. From this > materials, we can know that the research and experiments related with voice > over packet networks or aimed to achieve real-time communication of voice over > packet networks has been done since the 70's, while more enough work has been > done. But why just now, the late of 90's, this field began to cause researchers > to pay serious attention to and to boom? What was short of in the 70's? What > was the most crucial question? My guess is that there is much more money to get out of it, now that the Internet has become so popular, than in the 70's. Traditionally, audio transmission over long distances has been done by phone companies so far. Now, imagine doing long-distance or international calls virtuslly for free with a better quality than phone... This kind of thing can run phone companies out of business faster than anything. We are not talking about a million dollar market. We're talking about a multi-billion dollar market. This itself explains the recent boom you are talking about. ======================== Stephane Chatre Email: chatre@cs.orst.edu Department of Computer Science Phone: (541) 737-5583 (office) Oregon State University (541) 757-3376 (home) Life is what happens to you while you're busy making other plans. - John Lennon From rem-conf-request@es.net Mon Dec 09 22:03:40 1996 Received: from broon.off.connect.com.au by osi-east.es.net with ESnet SMTP (PP); Mon, 9 Dec 1996 19:02:56 -0800 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id NAA26641 (8.7.6h/IDA-1.6); Tue, 10 Dec 1996 13:01:37 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs X-Mailer: exmh version 1.6.9 8/22/96 To: Stephane Chatre cc: Yan Cheng , rem-conf@es.net Subject: Re: Why did Voice over Internet boom just now? In-reply-to: Your message of "Mon, 09 Dec 1996 17:18:30 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Dec 1996 13:01:32 +1000 Message-ID: <26640.850186892@connect.com.au> From: George Michaelson Coding technology caught up with the clueless. this permits people outside the labs to slaver over nice ideas and sell packaged drool to the masses. PS profits in telecoms are very very high. Declining, but still higher than the margins selling PC's or soap. Not for ISP's but for telephone companies you understand... PTT's have come onboard. Its official: real honest-to-god ITU sanctioned national carriers are going to do voice-over-ip as core business. Maybe only 5-15% this year, but its going to grow. No more "my s/w doesn't talk to your s/w" and full bakalite handset compatible 2-way telephone calling. You can't argue with ubiquity. Its compellingly awful. Enough non-IP systems are out there for owners to realize the low-quality issue is a sales trick to con you into things you don't need. Desktop is marginal cost for bums-on-seats. Soundcards are now viable and not noddy. Really nice people are now out there too btw, I don't mean to imply precept or any of the RTP/RTCP/H.xxx aware people are in the slime-sellers regions. Convergeance is a human-factors idea as well as a statement of technology, and for this application, the simplest reason is: Its time. -George From rem-conf-request@es.net Tue Dec 10 02:22:53 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Mon, 9 Dec 1996 23:22:26 -0800 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA17213; Mon, 9 Dec 1996 23:20:29 -0800 Date: Mon, 9 Dec 1996 23:20:29 -0800 (PST) From: Stephen Casner To: George Michaelson Cc: Stephane Chatre , Yan Cheng , rem-conf@es.net Subject: Re: Why did Voice over Internet boom just now? In-Reply-To: <26640.850186892@connect.com.au> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In the early 70's when we sent packet audio over the ARPAnet, we used PDP11 computers with attached array processors to do the compression and network protocols, and we could only fit one or maybe two voice streams over ARPAnet's 50Kb/s links. We just had to wait for technology to catch up. Of course, we have learned a few things about network protocols since then, but there is a lot that is the same, too. -- Steve From rem-conf-request@es.net Tue Dec 10 04:21:11 1996 Received: from merlot.inria.fr by osi-east.es.net with ESnet SMTP (PP); Tue, 10 Dec 1996 01:20:10 -0800 Received: by merlot.inria.fr (8.8.3/8.6.12) id KAA11775; Tue, 10 Dec 1996 10:19:49 +0100 (MET) Message-Id: <199612100919.KAA11775@merlot.inria.fr> X-Mailer: exmh version 1.6.7 5/3/96 To: rem-conf@es.net Subject: IETF retransmission -- very bad audio quality Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Dec 1996 10:19:46 +0100 From: Thierry Turletti Hi, The audio quality is very bad at INRIA. Is it possible to add some redundancy to the audio flow ? Several tools already implement this option (e.g. rat, fphone). It's a pity we cannot take advantage of these improvements for such retransmissions. Thierry PS: my mtrace for the IETF Channel 2 at 10:10am (UTC+1) Results after 10 seconds: Source Response Dest Packet Statistics For Only For Traffic * * * 138.96.24.37 All Multicast Traffic From 205.180.223.4 v __/ rtt 843 ms Lost/Sent = Pct Rate To 224.0.1.14 4.0.20.19 4.0.0.34 sanjose1-mbone1.bbnplanet.net v ^ ttl 0 730/1349 = 54% 134 pps 0/262 = 0% 26 pps 192.203.230.241 mbone.nsi.nasa.gov v ^ ttl 64 274/1305 = 21% 130 pps 1/262 = 0% 26 pps 207.12.55.99 stk-mbone-1.sprintlink.net v ^ ttl 65 36/1027 = 4% 102 pps 10/261 = 4% 26 pps 206.61.106.99 fw-mbone-1.sprintlink.net v ^ ttl 66 12/947 = 1% 94 pps 2/251 = 1% 25 pps 206.229.87.99 dc-mbone-1.sprintlink.net v ^ ttl 67 21/829 = 3% 82 pps 9/249 = 4% 24 pps 207.41.200.99 pen-mbone-1.sprintlink.net v ^ ttl 68 250/1139 = 22% 113 pps 49/240 = 20% 24 pps 192.35.82.97 MBONE.CIT.CORNELL.EDU v ^ ttl 69 126/615 = 20% 0 pps 37/191 = 19% 0 pps 193.51.208.8 138.96.152.17 sobone3.inria.fr v \__ ttl 70 680 68 pps 154 15 pps 138.96.24.37 138.96.24.37 Receiver Query Source From rem-conf-request@es.net Tue Dec 10 10:16:21 1996 Received: from lhc2.nlm.nih.gov by osi-east.es.net with ESnet SMTP (PP); Tue, 10 Dec 1996 07:15:52 -0800 Received: from billings.csb by lhc2.nlm.nih.gov (SMI-8.6/SMI-SVR4) id KAA08809; Tue, 10 Dec 1996 10:17:04 -0500 Received: by billings.csb (SMI-8.6/SMI-SVR4) id KAA03181; Tue, 10 Dec 1996 10:15:22 -0500 Date: Tue, 10 Dec 1996 10:15:22 -0500 From: rodgers@lhc2.nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <199612101515.KAA03181@billings.csb> To: cheng@moon.bjnet.edu.cn, chatre@ENGR.ORST.EDU Subject: Re: Why did Voice over Internet boom just now? Cc: rem-conf@es.net X-Sun-Charset: US-ASCII Woah, wait just a minute here... > From chatre@ENGR.ORST.EDU Mon Dec 9 22:47:19 1996 > Date: Mon, 9 Dec 1996 17:18:30 -0800 (PST) > From: Stephane Chatre > To: Yan Cheng > Cc: rem-conf@es.net > Subject: Re: Why did Voice over Internet boom just now? > Mime-Version: 1.0 > > On Tue, 10 Dec 1996, Yan Cheng wrote: > > > > > During recent weeks I have read some books and other materials about tranmitting > > voice over packetized networks. [...] But why just now, the late of > > 90's, this field began [...] to boom?> What was short of in the 70's? What > > was the most crucial question? > Traditionally, audio transmission over long distances has been done by > phone companies so far. Most of the IP traffic we are talking about is *also* being carried by "phone" companies, one way or another. > Now, imagine doing long-distance or international calls virtuslly for free > with a better quality than phone... This kind of thing can run phone > companies out of business faster than anything. If there is one thing that is clear from developments in the past two years, it is that Internet services are not going to be free. As for putting "phone companies out of business," it's not that simple. There is a reason why some of the big international carriers did not join in the recently squashed consortium trying to compell the U.S. government to prohibit voice communications over the Internet -- as with every technological paradigm shift, there are winners and losers. Some of the telephone carriers concerned with long distance network traffic have every reason to expect that they will *benefit*, other firms will lose out. It certainly seems likely, though, that in the coming few years we will see dramatic drops in the cost to the consumer of long-distance voice service, and continued integration of voice with other information services, in interesting and useful ways. There will be the usual tension between cost and quality, so it may not always be the case that the resulting services will be "better than phone." We should not extrapolate from today's experience with a lightly loaded experimental ATM line and assume that everyone will have such quality of service as firms scale up such services to the mass market. There will also be a fair amount of painful thrashing as the various competitors experiment with different pricing and business models until someone hits the right combination... Cheerio, Rick Rodgers > ======================== > Stephane Chatre Email: chatre@cs.orst.edu > Department of Computer Science Phone: (541) 737-5583 (office) > Oregon State University (541) 757-3376 (home)-------------------------------------------------------------------------------- R. P. C. Rodgers, M.D. * rodgers@nlm.nih.gov * (301)496-9305 (voice, fax) CSB, LHNCBC, National Library of Medicine, NIH 8600 Rockville Pike, Bethesda MD 20894 USA http://www.nlm.nih.gov/about_nlm/organization/lister_hill/ computer_science/roster/rodgers.html From rem-conf-request@es.net Tue Dec 10 10:18:50 1996 Received: from mail.pi.se by osi-east.es.net with ESnet SMTP (PP); Tue, 10 Dec 1996 07:17:50 -0800 Received: from au1042.pi.se (d1103.sth.pi.se [194.132.195.53]) by mail.pi.se (8.8.4/8.7.3) with SMTP id QAA05748; Tue, 10 Dec 1996 16:17:27 +0100 (MET) Message-Id: <1.5.4.32.19961210184539.00676910@mail.pi.se> X-Sender: au1042@mail.pi.se X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Dec 1996 19:45:39 +0100 To: Esa Vitikainen From: Gunnar Hellstrom Subject: Re: Seeking visions/experiences of multipoint data apps Cc: t120-interest@world.std.com, videophone@es.net, vidconf@pulver.com, rem-conf@es.net Data conferencing application. One apparent need is for a written interpretation of the voice part of a videoconference. To be used by hearing impaired people and language minorities (who could also be interested in a second sound channel to get voice interpretation instead.)=20 The requirement is character by character or ord by word display in a window with automatic new line at end of line.=20 The display could be overlaid on video (like subtitling) or separate. The requirements are very similar to chat requirements, but there might be a need for chairman control. Regards Gunnar Hellstr=F6m At 23:43 1996-12-03 -0800, Esa Vitikainen wrote: >Hi all, > >as part of my studies I am planning to find out just what are=20 >users / developers / service providers / VARs / ... >doing / going to do / would like to do=20 >with data in multipoint multimedia conferencing context.=20 >In other words, I'm chasing visions and experiences of=20 >applications adding value to voice/video.=20 > >There are the apparent chat, file transfer, whiteboard,=20 >and application sharing. But how are they really utilized?=20 >Where do they fall short? What else is needed out there?=20 > >Are there studies or something about this available somewhere?=20 >Places to ask around? Willing to reveal your own great idea?=20 > >An example: features I imagine needed for remote presentation: >- slideshow operated by the presenter >- "hands raised" electronically (with text description?) >- slides independently leafed through / edited locally > (like having paper copies) >- others taking over the slideshow control, with own remarks >- dialogs sent to ask for comments / test understanding,=20 > with reply statistics shown (for large audience) > >Regards, >Esa > > _____________________________________ Gunnar Hellstr=F6m Omnitor Alsn=F6gatan 7, 4 tr S-116 41 Stockholm SWEDEN Tel +46 701 100 501 Fax +46 8 448 27 51 e-mail gunnar.hellstrom@omnitor.se www: http://public-www.pi.se/~omnitor ------------------------------------- From rem-conf-request@es.net Tue Dec 10 10:40:54 1996 Received: from fezik.qualcomm.com by osi-east.es.net with ESnet SMTP (PP); Tue, 10 Dec 1996 07:40:12 -0800 Received: from njohnson (njohnson.qualcomm.com [129.46.127.226]) by fezik.qualcomm.com (8.8.3/1.4/8.7.2/1.12) with SMTP id HAA04479; Tue, 10 Dec 1996 07:38:40 -0800 (PST) Message-Id: <2.2.32.19961210153530.003606e8@strange.qualcomm.com> X-Sender: njohnson@strange.qualcomm.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Dec 1996 07:35:30 -0800 To: Stephen Casner From: Norm Johnson Subject: Re: Why did Voice over Internet boom just now? Cc: George Michaelson , Stephane Chatre , Yan Cheng , rem-conf@es.net The number one reason now is the right time for voice over packet networks is simply the big carriers of the 70's didn't have the bandwidth or the computing power. Long distance backbones were microwave with only analog circuits. Digital came along in the late eighties but still no bandwidth. Most transcontental circuits were at best a dozen or so DS-3's and they were maxerd out with analog voice calls. Finally when fiber arrived in the early nineties, the bandwidth got big enough and the number of computers in the world increased demand for digital backbones and broad bandwidth data networks. It wasn't until 1992 that the Internet backbone finally went to a full DS-3. It takes demand from customers to make the big guys gear up and get moving. As was pointed out, the idea that now data networks are cheaper for carrying voice than the old analog circuits has just arrived on the scene in the middle nineties. From here though, things are going to get real crazy and every conceivable communications company is going to be offering every conceivable service and the market will shake out the successful. Voice over data networks is only the beginning. It often takes decades to move an idea or invention into the relm of market-place reality. Fiber was known since the 60's but only deployed large scale in the nineties. Digital modulation was known in the 40's but was only deployed in the 80's. However, a fundamental growth pattern has changed and now it may only be a matter of a few years to see inventions go >from the design stage to the market. Hence, dense WDM fiber was developed in 1993 and is already appearing in the backbones of the major carriers. The pace of deployment has increased so such techno-delays of the past are probably no longer going to be seen. At 11:20 PM 12/9/96 -0800, you wrote: >In the early 70's when we sent packet audio over the ARPAnet, we used >PDP11 computers with attached array processors to do the compression >and network protocols, and we could only fit one or maybe two voice >streams over ARPAnet's 50Kb/s links. We just had to wait for >technology to catch up. > >Of course, we have learned a few things about network protocols since >then, but there is a lot that is the same, too. > -- Steve > > > ----------------------------------------------- Dr. Norman P. Johnson 2727 DeAnza Rd., Box N-14 San Diego, CA. 92109 Phone: Home (619) 581-0447 Ofc (619) 651-1491 Check out my web page: http://www.qualcomm.com/~njohnson ----------------------------------------------- "When the going gets weird, the weird turn Pro" -- Dr. Hunter S. Thompson From rem-conf-request@es.net Tue Dec 10 18:35:27 1996 Received: from coral.llnl.gov by osi-east.es.net with ESnet SMTP (PP); Tue, 10 Dec 1996 11:34:04 -0800 Received: from [128.115.96.72] (jedsmac.llnl.gov [128.115.96.72]) by coral.llnl.gov (8.8.4/8.7.3/LLNL-Jun96) with ESMTP id LAA23747; Tue, 10 Dec 1996 11:33:50 -0800 (PST) Date: Tue, 10 Dec 1996 11:33:50 -0800 (PST) X-Sender: jed@coral.llnl.gov Message-Id: In-Reply-To: <9612100019.AA05752@moon> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: cheng@moon.bjnet.edu.cn (Yan Cheng) From: "James E. [Jed] Donnelley" Subject: Re: Why did Voice over Internet boom just now? Cc: rem-conf@es.net >Hi Friends, > >During recent weeks I have read some books and other materials about >tranmitting >voice over packetized networks. After reading, I feel puzzled. From this >materials, we can know that the research and experiments related with voice >over packet networks or aimed to achieve real-time communication of voice over >packet networks has been done since the 70's, while more enough work has been >done. But why just now, the late of 90's, this field began to cause >researchers > to pay serious attention to and to boom? What was short of in the 70's? What >was the most crucial question? > >Regards, >12/10/96 The answer is the Web. You might say that the growth in the Internet in general eventuly made the Web inevitable, but it was the Web that created the market. Before that voice over packet networks was a research exercise. Now the potential is there to reach essentially everybody. That makes it serious financially. Hence the "boom." That's my opinion. --Jed http://www-atp.llnl.gov/atp/jed-signature.html From rem-conf-request@es.net Tue Dec 10 19:01:45 1996 Received: from mail.boxtop.com (actually dazed.boxtop.com) by osi-east.es.net with ESnet SMTP (PP); Tue, 10 Dec 1996 16:01:14 -0800 Received: (qmail 3963 invoked from network); 11 Dec 1996 00:01:10 -0000 Received: from astatine.boxtop.com (HELO ?204.80.124.85?) (204.80.124.85) by dazed.boxtop.com with SMTP; 11 Dec 1996 00:01:09 -0000 X-Sender: tdorcey@mail.boxtop.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Dec 1996 16:02:57 -0800 To: "James E. [Jed] Donnelley" , cheng@moon.bjnet.edu.cn (Yan Cheng) From: tim@boxtop.com (Tim Dorcey) Subject: Re: Why did Voice over Internet boom just now? Cc: rem-conf@es.net At 11:33 AM 12/10/96, James E. [Jed] Donnelley wrote: >The answer is the Web. You might say that the growth in the Internet >in general eventuly made the Web inevitable, but it was the Web >that created the market. Let's not forget a number of other developments that contributed to the explosion of interest in the Internet: 1. Availability of dial-up IP 2. Commercialization of the ISP business 3. Standardization of e-mail and widespread acceptance of its utility Sure, the www was important, but I think it would be a mistake to over-emphasize it. 5 years ago, Internet access was almost exclusively via LANs at universities and research institutes; commercial activities were expressly forbidden; and you could make a living figuring out how to translate between Bitnet, Decnet, UUCP, JANet, QuickMail, etc. A lot of things happened at once. Of course, The Media find the web most interesting, because the web looks like The Media and The Media loves The Media. From rem-conf-request@es.net Tue Dec 10 19:04:49 1996 Received: from sol (actually sol.genie.uottawa.ca) by osi-east.es.net with ESnet SMTP (PP); Tue, 10 Dec 1996 16:04:07 -0800 Received: by sol (5.0/SMI-SVR4) id AA03213; Tue, 10 Dec 1996 19:03:40 +0500 Date: Tue, 10 Dec 1996 19:03:40 +0500 From: devi@sol.genie.uottawa.ca (Sridevi Palacharla) Message-Id: <9612110003.AA03213@sol> To: rem-conf@es.net Subject: RTP timestamps and inter-media synchronization Content-Length: 663 In the RTP specification, "timestamp" in RTP header corresponds to the media clock and depends on the payload type. 8 Khz for PCM audio, 90 khz for Jpeg video etc. In case of pre-recorded video or audio, tranmitted using RTP at a later time or on-demand, how should the timestamp in RTP header be used? Also RTCP SR has NTP timestamp to associate with "timestamp" in RTP header, if this is to be used for inter-media synchronization? What should be the frequency at which RTCP SR should be generated? If this is so crucial for inter-media sync. should this be sent on TCP rather than over UDP? Any clarifications are most helpful. thanx in advance sridevi From rem-conf-request@es.net Wed Dec 11 13:12:48 1996 Received: from alpha.xerox.com by osi-east.es.net with ESnet SMTP (PP); Wed, 11 Dec 1996 10:12:07 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16551(3)>; Wed, 11 Dec 1996 10:06:29 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177711>; Wed, 11 Dec 1996 10:03:41 -0800 To: Thierry Turletti cc: rem-conf@es.net Subject: Re: IETF retransmission -- very bad audio quality In-reply-to: Your message of "Tue, 10 Dec 96 01:19:46 PST." <199612100919.KAA11775@merlot.inria.fr> Date: Wed, 11 Dec 1996 10:03:37 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <96Dec11.100341pst.177711@crevenia.parc.xerox.com> In message <199612100919.KAA11775@merlot.inria.fr> you write: >207.41.200.99 pen-mbone-1.sprintlink.net > v ^ ttl 68 250/1139 = 22% 113 pps 49/240 = 20% 24 pp >192.35.82.97 MBONE.CIT.CORNELL.EDU It's probably appropriate to ask Sprint or Cornell to try to isolate and fix this loss. >192.35.82.97 MBONE.CIT.CORNELL.EDU > v ^ ttl 69 126/615 = 20% 0 pps 37/191 = 19% 0 pp >193.51.208.8 >138.96.152.17 sobone3.inria.fr This was one of the first pathological tunnels that we found when we started doing the Multicast Planet visualization. I thought that we worked at the time to get it removed, but I can't find any copies of such email so I must be wrong. This appears to be a backup US<>Europe link that made sense a long time ago, but probably doesn't now unless Inria and Cornell have a private line that this tunnel travels over. Bill From rem-conf-request@es.net Wed Dec 11 17:00:31 1996 Received: from gw.navio.com by osi-east.es.net with ESnet SMTP (PP); Wed, 11 Dec 1996 13:59:49 -0800 Received: (from proxy@localhost) by gw.navio.com (8.6.12/8.6.9) id NAA28439 for ; Wed, 11 Dec 1996 13:59:43 -0800 Received: from lulu.navio.com(204.182.38.230) by tvsoft.com via smap (V1.3) id sma028433; Wed Dec 11 13:59:36 1996 Message-Id: <3.0.32.19961211135744.00cabfcc@gw.navio.com> X-Sender: brianb@gw.navio.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 11 Dec 1996 13:57:47 -0800 To: rem-conf@es.net From: Brian Bulkowski Subject: Group size estimation Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hello, It was proposed yesterday that group size could be tracked without keeping each SSRC value. The necessity of keeping every SSRC, or a table large enough to have indexed all SSRC values, is onerous in a million-node receiver group. Just so we know the section we're talking about: 6.2.1 Maintaining the number of session members Calculation of the RTCP packet interval depends upon an estimate of the number of sites participating in the session. New sites are added to the count when they are heard, and an entry for each is created in a table indexed by the SSRC or CSRC identifier (see Section 8.2) to keep track of them. New entries may not be considered valid until multiple packets carrying the new SSRC have been received (see Appendix A.1). Entries may be deleted from the table when an RTCP BYE packet with the corresponding SSRC identifier is received. A participant may mark another site inactive, or delete it if not yet valid, if no RTP or RTCP packet has been received for a small number of RTCP report intervals (5 is suggested). This provides some robustness against packet loss. All sites must calculate roughly the same value for the RTCP report interval in order for this timeout to work properly. Once a site has been validated, then if it is later marked inactive the state for that site should still be retained and the site should continue to be counted in the total number of sites sharing RTCP bandwidth for a period long enough to span typical network partitions. This is to avoid excessive traffic, when the partition heals, due to an RTCP report interval that is too small. A timeout of 30 minutes is suggested. Note that this is still larger than 5 times the largest value to which the RTCP report interval is expected to usefully scale, about 2 to 5 minutes. Notice that there are a large number of "mays" and few "musts". The client is allowed to implement whatever it chooses, however, it is clear what the writers of the RFC intended. One interesting point of the wording is that it assumes an estimate of what the report interval is, but I see nowhere else that suggests a good method for getting that estimate. In most algorythms, you need an estimate of the report interval, including the spec'd algorythm; here's one that comes to mind. Maintain an estimate of the RR interval by tracking a small number of specific SSRC RR timings. Make a table including the last time heard, number of times heard from, and SSRC value. Whenever you receive an SSRC BYE packet, invalidate that timing entry. When you have received a certain number of SSRC packets (5?), add the interval to the running average, then clear the entry. On every RR receipt, check for an empty entry, if you find one, use that SSRC value for estimation. Have a timer run though the interval estimation table to throw out entries that it hasn't heard from for a while. Suggested time is three times the current report interval. Is there another way of estimating the report interval besides watching everyone else? If you have a size-of-group estimate, and a stream size estimate, you can calculate the report interval. This can be used instead, except in initial cases. There was a bit of discussion at the IETF about initial wait intervals before sending RR packets. I haven't figured out the best way to implement the intial case. In the table-driven case it's much easier, since you can just wait until you've got a couple of reports from a particular SSRC, then assume all the estimates you've got are good. In terms of getting group size, once you have a good estimate of the report interval, you need only keep track of the number of RR packets received (say, per second, making sure you use a different timer than all others). Whenever you desire the size of the receiver group, multiply the current report interval by the number of RRs received, and you get the size of the receiver group. This algorythm seems to converge slowly, but has a nice attribute that if you are losing RR packets, you get a larger size estimation, which leads to the sending of fewer RR packets, which means that the algorythm is congestion friendly. Another algorythm is as follows. Keep a hashtable that has only two states (a bitfield would work): received, and not received. Use as a hash algorythm masking out the high bits of the SSRC. Whenever you receive an RR packet, hash the SSRC value, and set the state of the table entry to received. The table is valid only after one report interval. Therefore, the report interval must still be calculated using some method (such as the one above). After one report interval, sum the number of states set to received, and set that as your estimate. Use that estimate until the next report interval has expired. Note that variation in estimates of report interval will cause either undersizing or oversizing. Unfortunatly, I suspect the system doesn't converge. If you have too small of an interval, then you will think the group is smaller than it is, and recalculate an even smaller interval. If you think the interval is larger than it really is you'll be fine, since the algorythm caps out. Note that this algorythm still requires memory dependant on the number of other receivers, but at least it is only one bit. (128K for a million-receiver session). However, if there is a hashtable collision, there will be underreporting, which leads to greater RR sending then there should be, which is bad. The exact frequency of probable collision depends on the exact random number generator used for the SSRC values, the size of the session, the hashtable size chosen, and the hash algorythm. I suspect that there might be a positive feedback cycle if everyone underestimates. On the other hand, if everyone underestimates by a fixed amount, you might just get a constant level of underreporting. In order to dynamically resize the hash table, you could keep track of a few marker buckets, and whenever there is a collision in one of your marker buckets, realloc your table and start again. Or, you could make an estimate at the amount of collision you are getting, and multiply your size estimate by that factor. This allows people to pick certain table sizes and not reallocate. In the "marker buckets" you need to keep track of the exact SSRCs received, so you can detect true collisions vs. bogus collisions due to inaccurate estimation of the report interval. I'm sure that the RTP designers thought over these issues. It is clear that the current set of "mays" in section 6.2.1 will not work with large receiver groups. Would it be better to add suggested algorythms and words for larger groups, or would it be better to spec one of the other estimation algorythms (like the polling one) which doesn't require the receiver's calculation of receiver groupsize? Or would it be better to turn off RRs in large groups? What's the thinking? Regarding what Van said about multicast being the fastest path to convergance, the client side memory must be considered as well. If an algorythm has a particular network charisteric, but takes memory linearly depending on groupsize, it is not scaleable. Which might be OK; the points made in the WG meeting about the initial design goals are well taken. I am working on a list of my specific design requirements. RTP might not be the protocol for me. There must be a suggested implementation which is constant size in memory, and also has good convergance characteristics, or a statement about the limits of scalebility of the protocol. Granted, exact supportable groupsize before scalebility runs out will depend on many things, including the client resources, but a statement needs to be made. In any case, I'd like to have wording suggesting methods for estimating the report interval, since it is required for section 6.2.1. Regards, brianb From rem-conf-request@es.net Thu Dec 12 08:07:22 1996 Received: from eragny.rce.fr (actually rce.rce.fr) by osi-east.es.net with ESnet SMTP (PP); Thu, 12 Dec 1996 05:06:50 -0800 From: ag@eragny.rce.fr To: rem-conf@es.net Date: Thu, 12 Dec 1996 14:06 GMT Subject: packetized voice characteristics Content-Length: 951 Content-Type: text/plain Message-ID: <32b011700.46d5@eragny.rce.fr> Hi, Given the traffic characterisation for real-time data, from TENET at Berkeley University (Zhang, Ferrari), in which a source specifies its characteristics by: (Xmin, Xave, I, P) where: Xmin=minimum packet inter-arrival time over time period I Xave=average packet inter-arrival time over time period I I=time period P=max packet size and ask to the network some performance requirments (e.g. Delay, Delay-Jitter, ...), does anybody knows some typical values of Xmin, Xave, I, P at the ouput of a packetization machine ? In the litterature, we often read: . an uncompressed voice source needs 64kbps of bandwidth and a max delay of 200ms . a compress voice source needs16kbps or 8kbps (depending on algorithm used) and a max delay of 30ms I don't guess it is enough to conclude on the Xmin, Xave, I, P characteritics of the source. Can anybody help ? Thanks. Anouchiravan Gharagozlou Software Development Engineer CS Telecom/RCE anouchg@rce.fr From rem-conf-request@es.net Thu Dec 12 10:29:39 1996 Received: from eragny.rce.fr (actually rce.rce.fr) by osi-east.es.net with ESnet SMTP (PP); Thu, 12 Dec 1996 07:29:00 -0800 From: ag@eragny.rce.fr To: mbc@attitw.attmail.com, rem-conf@es.net, support@bayarea.net, daemon@usenet.ucs.indiana.edu, dec@dfv.rwth-aachen.de, comp.dcom.cell-relay@indiana.edu Date: Thu, 12 Dec 1996 16:28 GMT Subject: voice packet characterizations Content-Length: 1116 Content-Type: text/plain Message-ID: <32b032ab0.48c2@eragny.rce.fr> Hi, Given the traffic characterization modele for real-time data, from TENET at Berkeley University (Zhang, Ferrari), in which a source specifies its characteristic by: (Xmin, Xave, I, P) where: Xmin=minimum packet inter-arrival time over time period I Xave=average packet inter-arrival time over time period I I=time period P=max packet size and asks to the network some performance requirment (e.g. Delay, Delay-Jitter, ...), what are the typical values of these parameters for compressed and uncompressed voice packets ? If it depends on the packetization strategie, please provide some numerical examples. We often read in the litterature that an uncompressed voice source needs 64kbps of bandwidth and a maximum delay of 200ms while a compressed voice source needs 16kbps or 8kbps (depending on the algorithm used) of bandwidth and a maximum delay of 30ms. This doesn't tell how often voice packets are generated by the packetization machine and what are the length of the packets... (i.e. Xmin, Xave, I, P). Thanks, Anouchiravan Gharagozlou Software Development Engineer CS Telecom/RCE anouchg@rce.fr From rem-conf-request@es.net Fri Dec 13 11:31:18 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Fri, 13 Dec 1996 08:30:47 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 13 Dec 1996 16:26:26 +0000 To: Stephen Casner cc: rem-conf@es.net Subject: Re: IP/UDP/RTP header compression In-reply-to: Your message of "Sun, 24 Nov 1996 15:15:44 PST." Date: Fri, 13 Dec 1996 16:26:18 +0000 Message-ID: <2370.850494378@cs.ucl.ac.uk> From: Jon Crowcroft the realy neat thing about cRTP is that you could envisage using RTP+UDP+IP+AAL5+ATM, but the full header would really kill things.... but with cRTP, you can do voice on ATM, with transparent interworking to the Mbone/Internet/H323....as long as people use the right voice sample size, with a single cell (and no echo cacnellors unless the IP on NOT ATM path incurs too much delay...) of course, as usual, this is assuming ATM as a low bandwidth technology.....which it appears usually to be:-) thus we win again.... not entirely joking! cheers jon From rem-conf-request@es.net Fri Dec 13 21:02:48 1996 Received: from mercury.lcs.mit.edu by osi-east.es.net with ESnet SMTP (PP); Fri, 13 Dec 1996 18:02:05 -0800 Received: from localhost (localhost [127.0.0.1]) by mercury.lcs.mit.edu (8.6.12/8.6.12) with SMTP id VAA13175; Fri, 13 Dec 1996 21:01:58 -0500 X-Authentication-Warning: mercury.lcs.mit.edu: Host localhost didn't use HELO protocol From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Jon Crowcroft cc: Stephen Casner , rem-conf@es.net Subject: Re: IP/UDP/RTP header compression In-reply-to: Your message of "Fri, 13 Dec 96 16:26:18 GMT." <2370.850494378@cs.ucl.ac.uk> Date: Fri, 13 Dec 96 21:01:58 -0500 Message-ID: <25389.850528918@mercury.lcs.mit.edu> Sender: mjh@mercury.lcs.mit.edu X-Mts: smtp > > >the realy neat thing about cRTP is that you could envisage using >RTP+UDP+IP+AAL5+ATM, but the full header would really kill things.... > >but with cRTP, you can do voice on ATM, with transparent interworking >to the Mbone/Internet/H323....as long as people use the right voice >sample size, with a single cell (and no echo cacnellors unless the IP >on NOT ATM path incurs too much delay...) Of course then we can apply the header compression techniques to combined ATM/AAL5/IP/UDP/RTP header compression. But the first two parts compress to nothing, so we already have a draft that covers this case... Mark From rem-conf-request@es.net Fri Dec 13 21:49:48 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Fri, 13 Dec 1996 18:49:00 -0800 Received: from little-bear.precept.com by precept.com (SMI-8.6/SMI-SVR4) id SAA04241; Fri, 13 Dec 1996 18:48:56 -0800 Date: Fri, 13 Dec 1996 18:48:56 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: IETF AVT meeting summary Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is the "one paragraph" summary that the WG chair is required to send to the Area Director by the end of IETF week. Full minutes of the meeting will be forthcoming soon. -- Steve The AVT working group met for two sessions at the San Jose '96 IETF. The most significant topic was RTCP scaling for large groups and scenarios beyond those currently described in the RTP spec. Bernard Aboba and Henning Schulzrinne gave presentations on the problems that arise and a variety of possible solutions. In the discussion that followed, there was not one solution that was the clear answer in all cases. However, it was agreed that the wording in the main RTP spec should be modified to allow more flexibility in how RTCP may be used, and that the means by which different modes should be defined and selected is through the specification of (a small number of) additional RTP Profiles. Proposals for additional profiles are solicited. Steve Casner presented an update on the proposal developed with Van Jacobson for hop-by-hop compression of IP/UDP/RTP headers for applications running over low-speed lines that was introduced at the previous meeting in Montreal. The significant changes were to better integrate this compression scheme into the IPv6 header compression scheme (which also supports IPv4 and encapsulation in multiple headers) and to replace the temporary use of the delta encoding scheme from RFC 1144 TCP/IP header compression with one designed to match the deltas encoutered in typical RTP applications. Manoj Leelanivas presented a report on his implementation of the compression algorithm and its performance. The working group agreed that this proposal should go to Last Call. In a related presentation, the authors of the RTSP proposal in the MMUSIC working group reported that the means of specifying the underlying stream transport protocol would be made more flexible, and that the reduced-size variant of RTP included as one transport option in that proposal would be extracted as a non-standards-track interim proposal and would be named CUSH rather than "compressed RTP". The second session began with updates on the RTP Payload Formats for Redundant Audio and H.263 video. Both of these should be ready for Last Call after a few minor edits. Reha Civanlar gave a presentation of a problem with the packet loss resilience mechanism for the Proposed Standard MPEG2 payload format. He proposed a modification to the header to solve that problem, and was asked by the chair to write up that proposed change to be made to the document before its transition to Draft Standard. Several proposals for new applications of RTP have been recently submitted to the working group. Some fall into the general area of reliable multicast which the Transport Area Directors want to organize as a separate IRTF Research Group and later IETF Working Groups. The group discussed this plan and the fit of new work into the AVT charter. Two presentations were made on new applications. The first by Roger Kermode on the idea of layering audio and video streams in time as well as quality, then combining this layering with caching to reduce latency and bandwidth requirements for on-demand playback. The second was by Jonathan Rosenberg on multiplexing several RTP audio sessions into one packet stream. This could be used, for example, to increase packet efficiency substantially between Internet Telephony gateways. Stan Naudus gave a status report on the development of an RTP MIB. The group discussed changes required to advance the RTP and Profile specs to Draft Standard. In addition to the RTCP scaling mentioned earlier, the other significant point of discussion was on generalizing the specification of an RTP session to allow different addresses to be used for RTP and RTCP. This would allow RTCP delivery to be constrained for improved scalability in scenarios. The consensus of the group was that we should take the conservative approach and not make this change at this time. The group also agreed that the RFC 1890 A/V Profile should recommend the use of only the numeric address form of the RTCP SDES CNAME item in common across all tools so that audio and video streams can be matched for synchronization. The Profile will also have added some specifications for simple payload formats such as G.728. The AVT meeting ended with a discussion of how much work remains, since the original charter has been completed. The group agreed to meet again in Memphis, with the intention that work on new Profiles for RTCP scaling and the new Payload Formats currently in progress can be finished then. From rem-conf-request@es.net Sun Dec 15 23:41:08 1996 Received: from USNT2.vocaltec.com (actually 38.250.35.184) by osi-east.es.net with ESnet SMTP (PP); Sun, 15 Dec 1996 20:40:38 -0800 Received: by USNT2.vocaltec.com(Lotus SMTP MTA v1.05b3 (266.7 11-15-1996)) id C2256401.0076DBB2 ; Sun, 15 Dec 1996 23:38:14 +0300 X-Lotus-FromDomain: VOCALTEC From: Scott Petrack To: J.Crowcroft@cs.ucl.ac.uk cc: casner@precept.com, rem-conf@es.net Message-ID: Date: Mon, 16 Dec 1996 06:37:16 +0300 Subject: Re: IP/UDP/RTP header compression Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Scott Petrack 12/16/96 06:37 AM Sorry to break the hilarity, but I can't help but ask a more serious question about C/RTP: It does seem that there is some interest in compressing RTP in a high bandwidth point to point link. Steve pointed out that if the pipe is long or fat there is a problem, because there may not be enough bits for sequence numbers or contexts. We mentioned the possibility of using more bits for more contexts, but not for more sequence numbers. It would be nice if somehow a future hook could be made for allowing an extra byte for long sequence numbers and/or an extra byte for lots of contexts, perhaps as a message to be sent when compression is negotiated. On a related note, it was suggested that it might be more efficient if there could be a compression table per context, rather than a single table for all contexts. Surely on a high bandwidth line, at least a few different tables would be nice to have, even if not one per context. Unless I'm mistaken, it is a pure complexity/bandwidth tradeoff (maybe with memory if there are many tables). In the near future CPU may be VERY cheap compared to bandwidth, and one might like to use RTP compression on a higher speed link. It would be sad it this will be impossible because there are only 4 bits for sequence numbers and no way to negotiate more. This would not be hard to do in a way which preserves backward compatibility with the boxes that Cisco is going to ship next week ;-) Scott -------- On 12/13/96 04:26 PM GMT J.Crowcroft @ cs.ucl.ac.uk wrote: the realy neat thing about cRTP is that you could envisage using RTP+UDP+IP+AAL5+ATM, but the full header would really kill things.... but with cRTP, you can do voice on ATM, with transparent interworking to the Mbone/Internet/H323....as long as people use the right voice sample size, with a single cell (and no echo cacnellors unless the IP on NOT ATM path incurs too much delay...) of course, as usual, this is assuming ATM as a low bandwidth technology.....which it appears usually to be:-) thus we win again.... not entirely joking! cheers jon From rem-conf-request@es.net Mon Dec 16 13:34:28 1996 Received: from cismsun.univ-lyon1.fr by osi-east.es.net with ESnet SMTP (PP); Mon, 16 Dec 1996 10:33:49 -0800 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id TAA13375; Mon, 16 Dec 1996 19:33:34 +0100 Message-Id: <199612161833.TAA13375@cismsun.univ-lyon1.fr> Subject: some strange nt error messages To: mjh@ISI.EDU (Mark Handley) Date: Mon, 16 Dec 1996 19:33:34 +0100 (MET) From: Lucia Gradinariu Cc: rem-conf@es.net In-Reply-To: <2976.849552357@mercury.lcs.mit.edu> from "Mark Handley" at Dec 2, 96 01:45:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 987 hi, while using nt between 4 stations as a shared program editor we've got these error messages (as associated behaviour that is all nt applications blocked) -------------------------------------------------------------- Got a bug in my recent list code Paranoia check in ds_fns.c - got a duplicated block t86d665f433d70006 != t86d665f433d70006 ttl=3 multicast address: 224.5.6.7 port: 8500 -------------------------------------------------------------- on 2SGI+1SS20 we have v1.5a23 and on a PC we have v1.5a20 any idea how can we have two different blocks with the same identifier? thanks, -------------------------------------------------------------------------------- Lucia GRADINARIU, Eng. CISM-Univ. Cl. Bernard Lyon1 voice:(33).72.43.13.69 Bat. 101 Bd. du 11 Novembre 1918 fax:(33).72.44.84.10 69622 Villeurbanne FRANCE email:lucia@univ-lyon1.fr http://www.univ-lyon1.fr/CISM/lucia --------------------------------------------------------------------------------- From rem-conf-request@es.net Mon Dec 16 23:21:08 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Mon, 16 Dec 1996 20:20:32 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id UAA12131; Mon, 16 Dec 1996 20:11:50 -0800 Date: Mon, 16 Dec 1996 20:12:24 -0800 () From: Stephen Casner To: Scott Petrack cc: J.Crowcroft@cs.ucl.ac.uk, rem-conf@es.net Subject: Re: IP/UDP/RTP header compression In-Reply-To: Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > It does seem that there is some interest in compressing RTP in a high > bandwidth point to point link. Steve pointed out that if the pipe is > long or fat there is a problem, because there may not be enough bits > for sequence numbers or contexts. We mentioned the possibility of > using more bits for more contexts, but not for more sequence numbers. I think it would be straightforward to provide the option for two-byte context identifiers using the techniques already defined in the ipv6-hc draft. However, it seems to me that the size of the sequence number is unrelated to the length or obesity of the pipe. The sequence number just needs to allow detection of loss or misordering. If the pipe misorders, then the delta coding is not going to work. If the probability of losing sequence-space-sized groups of packets is high, then the pipe is not a good candidate for compression either. > On a related note, it was suggested that it might be more efficient > if there could be a compression table per context, rather than a > single table for all contexts. Surely on a high bandwidth line, at > least a few different tables would be nice to have, even if not one > per context. Yes, the compression table could be per context. I guess that just requires that the yet-to-be-defined message for negotiating compression tables needs to be able to indicate to which context(s) the table applies, probably with a way to say "all". I'm thinking that this negotiation should be left to PPP rather than making it part of CRTP itself and requiring the definition of more packet types. The negative consequence is that the negotiation scheme would have to be defined by each link protocol. If a full entropy encoding is used, then one might want to reduce the smallest number of bits to less than 8. That would mean we'd probably want to re-align to a byte boundary after the encoded values. Would it be reasonable to just have that re-alignment be implicit? -- Steve From rem-conf-request@es.net Tue Dec 17 00:10:44 1996 Received: from cosmos.kaist.ac.kr (actually maple.kaist.ac.kr) by osi-east.es.net with ESnet SMTP (PP); Mon, 16 Dec 1996 21:10:08 -0800 Received: (from krkang@localhost) by cosmos.kaist.ac.kr (8.6.12h2/8.6.12) id OAA09016; Tue, 17 Dec 1996 14:06:38 +0900 From: Kyungran Kang Message-Id: <199612170506.OAA09016@cosmos.kaist.ac.kr> Subject: (Q) mbone media on demand service To: mbone@isi.edu Date: Tue, 17 Dec 1996 14:06:37 +0900 (KST) Cc: rem-conf@es.net X-Mailer: ELM [version 2.4 PL21-h4] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 377 Hello, everyone. I'm planning to build a mbone archive site. And I'd like to have a sample site. Is anyone operating a mbone media on demand service? I've visited mice server but it seemed to have stopped. If you are oprating a mbone media on demand service or if you are planning to, please let me know. It will be great help to me. Thanks very much in advance. - krkang From rem-conf-request@es.net Tue Dec 17 10:30:59 1996 Received: from aohakobe.ipc.chiba-u.ac.jp by osi-east.es.net with ESnet SMTP (PP); Tue, 17 Dec 1996 07:30:19 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp (localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.7.5/3.4Wbeta3 (-: 95041617) with ESMTP id AAA03622 for ; Wed, 18 Dec 1996 00:30:32 +0900 (JST) Message-Id: <199612171530.AAA03622@aohakobe.ipc.chiba-u.ac.jp> To: rem-conf@es.net Subject: question about CBC session. Date: Wed, 18 Dec 1996 00:30:32 +0900 From: Yozo Toda Hi, I have two questions about "CBC newsworld Online". joining the CBC session, "Incoming Call" window pops up. the window has no buttons, only three lines; Incoming Call You have an incoming call from inviting you to join the following session what's this? I wonder a few lines missed? some message appears to the console; can't read "sip_invite_status(131.211.35.48/850866683)": no such variable while executing "switch $sip_invite_status($id)..." invoked from within bluh bluh bluh I use sdr2.2a23, is it a problem? another question, I tried to join the video session of CBC, but vic2.7a29 core-dumped. is it also old-version problem? btw, vat4.0a2 works fine for audio session. -- yozo. From rem-conf-request@es.net Tue Dec 17 17:11:59 1996 Received: from aruba.lerc.nasa.gov by osi-east.es.net with ESnet SMTP (PP); Tue, 17 Dec 1996 14:11:10 -0800 Received: from captiva.lerc.nasa.gov by aruba.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id RAA06240; Tue, 17 Dec 1996 17:11:07 -0500 (EST) Received: from ideunix1 by captiva.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-local) id RAA11773; Tue, 17 Dec 1996 17:10:58 -0500 (EST) Message-Id: <2.2.32.19961217221104.002c6d4c@popserve.lerc.nasa.gov> X-Info: IDE / NASA Lewis Research Center X-Sender: dpleva@popserve.lerc.nasa.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Dec 1996 17:11:04 -0500 To: rem-conf@es.net From: David P Pleva Subject: Mbone Seminar: "Hybrid Communications Networks" (12/18/96) Cc: M#u#Baldizzi@qmgate.lerc.nasa.gov Mbone Seminar Announcement: The Satellite Networks and Architectures Branch and the Computer Services Division of NASA Lewis Research Center plans to broadcast a seminar on "Hybrid Communications Networks: Architectures, Management and Services" by Professor John S. Baras Director Center for Satellite and Hybrid Communication Networks University of Maryland. Date: Wednesday, December 18, 1996 Time: 10:30am -11:30 AM (EST) About the Topic: Satellite and terrestrial networks are becoming increasingly critical in the hybrid architecture of the NII/GII. Hybrid networks, in our terminology, are seamlessly interoperable terrestrial wireless and wireline and satellite networks. In this seminar, we will describe the research program of the Center in hybrid networking. We will focus on: hybrid network architectures, asymmetric Internet via satellite, network modeling and simulation, broadband satellite constellations, network management and information dissemination over hybrid networks. We will also describe several commercial products in Internet services and network management that have recently resulted from the research of the Center. About the Speaker: Professor John S. Baras is the Director of the NASA Center for Hybrid and Satellite Communication Networks and the Lockheed Martin Chair in Systems Engineering at the University of Maryland. He received his Ph.D. degree from Harvard University. He is a Fellow of the IEEE and has received several awards for his research activities. ---------------------------------------------------------------------------- ---------- David Pleva (Sterling Software) - CSD-7190 Networking and Telecom. NASA/Lewis Research Center MS142-1 (216) 433-9061 email: dpleva@popserve.lerc.nasa.gov FAX: (216) 433-8000 ---------------------------------------------------------------------------- ---------- From rem-conf-request@es.net Wed Dec 18 03:49:20 1996 Received: from viviane.dassault-elec.fr by osi-east.es.net with ESnet SMTP (PP); Wed, 18 Dec 1996 00:48:06 -0800 Received: from localhost (chambet@localhost) by viviane.dassault-elec.fr (8.7.6/SMI-SVR4) with SMTP id JAA03482 for ; Wed, 18 Dec 1996 09:43:14 +0100 (MET) Date: Wed, 18 Dec 1996 09:43:14 +0100 (MET) From: Beatrice Chambet To: REMCONF Subject: Videoconference sofware under windows NT Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, Is there any videoconference software for windows NT 3.51 or 4.00 with the quickcam color camera. Thanks in advance. bye From rem-conf-request@es.net Wed Dec 18 04:45:07 1996 Received: from rumms.uni-mannheim.de by osi-east.es.net with ESnet SMTP (PP); Wed, 18 Dec 1996 01:44:17 -0800 Received: from eratosthenes.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA15487 (5.67a/IDA-1.5 for ); Wed, 18 Dec 1996 10:44:21 +0100 Received: from localhost (whd@localhost) by eratosthenes.informatik.uni-mannheim.de (8.8.2/8.8.2) with SMTP id KAA14619; Wed, 18 Dec 1996 10:43:24 +0100 (MET) X-Authentication-Warning: eratosthenes.informatik.uni-mannheim.de: whd owned process doing -bs Date: Wed, 18 Dec 1996 10:43:23 +0100 (MET) From: Wieland Holfelder X-Sender: whd@eratosthenes To: Kyungran Kang Cc: mbone@isi.edu, rem-conf@es.net Subject: Re: (Q) mbone media on demand service In-Reply-To: <199612170506.OAA09016@cosmos.kaist.ac.kr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 17 Dec 1996, Kyungran Kang wrote: > I'm planning to build a mbone archive site. > And I'd like to have a sample site. Is anyone operating a mbone > media on demand service? Seems as there is quite some development going on in this area... yes, we are also working on a media on demand service for the MBone, we call it MBone VCR on demand service. It is the followup project of the MBone VCR that I implemented some time ago at ICSI. The system will consist of Java based clients (they may run as java application as well as java applets) and multithreaded servers implemented in java and native C++ code. They communicate through ROJ (remote objects for java) which is a Corba compatible implementation of SUN written in Java. Clients can request recordings and playbacks of MBone sessios at the servers, there will be access control and of course, clients have full VCR control during playback and recording. The server has an interface to SAP (Version 0 and 1) and SDP (Version 0 as described in the sdp draft 03.2). The server makes announcments available to clients and announces playbacks over these protocols. We hope to have a first alpha version ready early next year. Stay tuned. -- Wieland --------------------------------------------------------------------- Wieland Holfelder University of Mannheim Praktische Informatik IV Phone: +49-621-292-5679 L 15,16 Fax : +49-621-292-5745 68131 Mannheim whd@pi4.informatik.uni-mannheim.de Germany http://www.informatik.uni-mannheim.de/~whd --------------------------------------------------------------------- From rem-conf-request@es.net Wed Dec 18 06:42:22 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Wed, 18 Dec 1996 03:41:23 -0800 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 18 Dec 1996 11:40:37 +0000 From: Isidor Kouvelas X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3670 To: Beatrice Chambet cc: REMCONF Subject: Re: Videoconference sofware under windows NT In-reply-to: Your message of "Wed, 18 Dec 1996 09:43:14 +0100." Date: Wed, 18 Dec 1996 11:40:25 +0000 Message-ID: <2911.850909225@cs.ucl.ac.uk> Sender: I.Kouvelas@cs.ucl.ac.uk > Is there any videoconference software for windows NT 3.51 or 4.00 with >the quickcam color camera. The VFW vic port will work. For information look at: http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic Isidor From rem-conf-request@es.net Wed Dec 18 10:05:18 1996 Received: from calvin.dgbt.doc.ca by osi-east.es.net with ESnet SMTP (PP); Wed, 18 Dec 1996 07:04:40 -0800 Received: by calvin.dgbt.doc.ca (4.1/SMI-4.1) id AA13348; Wed, 18 Dec 96 10:04:21 EST Date: Wed, 18 Dec 96 10:04:21 EST From: andrew@calvin.dgbt.doc.ca (Andrew Patrick) Message-Id: <9612181504.AA13348@calvin.dgbt.doc.ca> In-Reply-To: Yozo Toda "question about CBC session." (Dec 18, 12:30am) Reply-To: andrew@calvin.dgbt.doc.ca X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Yozo Toda , rem-conf@es.net Subject: Re: question about CBC session. On Dec 18, 12:30am, Yozo Toda wrote: } Subject: question about CBC session. | | Hi, I have two questions about "CBC newsworld Online". | I am the orginator of the CBC Newsworld session. | joining the CBC session, "Incoming Call" window pops up. | the window has no buttons, only three lines; | | Incoming Call | You have an incoming call from inviting you to | join the following session | | what's this? I wonder a few lines missed? | some message appears to the console; | | can't read "sip_invite_status(131.211.35.48/850866683)": no such variable | while executing | "switch $sip_invite_status($id)..." | invoked from within | bluh bluh bluh | | I use sdr2.2a23, is it a problem? This is strange, as there should not be any SIP requests attached to this session. I have not heard of any previous problems like this. | another question, I tried to join the video session of CBC, but | vic2.7a29 core-dumped. is it also old-version problem? I don't know, but that version of vic is out of date so you may want to update it on principle. You did not mention the platform you are running on. -- Andrew Patrick, Ph.D. 1996 Psychic Report Card: http://www.csicop.org/articles/psychic-1996.html From rem-conf-request@es.net Wed Dec 18 10:54:31 1996 Received: from aohakobe.ipc.chiba-u.ac.jp by osi-east.es.net with ESnet SMTP (PP); Wed, 18 Dec 1996 07:53:34 -0800 Received: from aohakobe.ipc.chiba-u.ac.jp (localhost [127.0.0.1]) by aohakobe.ipc.chiba-u.ac.jp (8.7.5/3.4Wbeta3 (-: 95041617) with ESMTP id AAA05400; Thu, 19 Dec 1996 00:52:57 +0900 (JST) Message-Id: <199612181552.AAA05400@aohakobe.ipc.chiba-u.ac.jp> To: andrew@calvin.dgbt.doc.ca cc: rem-conf@es.net Subject: Re: question about CBC session. In-reply-to: Your message of "Wed, 18 Dec 1996 10:04:21 EST." <9612181504.AA13348@calvin.dgbt.doc.ca> Date: Thu, 19 Dec 1996 00:52:57 +0900 From: Yozo Toda thanks for your response, andrew! today I receive no SIP request. > I don't know, but that version of vic is out of date so you may want > to update it on principle. yeah, I'll update it later. I compiled vic with X11R6 library, but today I did "ldd `which vic`" and found that the vic binary uses openwin library. it may be the problem... > You did not mention the platform you are running on. a ha, sorry. SS20, solaris2.4 with X11R6.0. I want to try NetBSD on SS20 someday (-: -- yozo. From rem-conf-request@es.net Wed Dec 18 13:27:44 1996 Received: from tac.inria.fr by osi-west.es.net with ESnet SMTP (PP); Wed, 18 Dec 1996 10:27:13 -0800 Received: by tac.inria.fr (8.8.3/8.6.12) id TAA07222; Wed, 18 Dec 1996 19:17:16 +0100 (MET) Message-Id: <199612181817.TAA07222@tac.inria.fr> X-Mailer: exmh version 1.6.7 5/3/96 To: Isidor Kouvelas cc: Beatrice Chambet , REMCONF Subject: Re: Videoconference sofware under windows NT In-reply-to: Your message of "Wed, 18 Dec 1996 11:40:25 GMT." <2911.850909225@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Dec 1996 19:17:16 +0100 From: Frank Lyonnet > > Is there any videoconference software for windows NT 3.51 or 4.00 with > >the quickcam color camera. > > The VFW vic port will work. For information look at: > http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic > > Isidor Quoted from connectix home page : > Connectix supports Windows 3.1x and Windows 95. WindowsNT is not yet > supported, but we are close to releasing a driver for the grayscale QuickCam > (due in Dec). This would mean that color quickcam cannot be used at all under Windows NT, even with VideoForWindows port of vic. And as far as I know the grayscale driver cannot be used with the color quickcam. So my answer to the question is : there is no videoconference software for NT that can work with color quickcam until connectix release a suitable driver. Cheers, Frank Frank.Lyonnet@inria.fr From rem-conf-request@es.net Wed Dec 18 18:59:18 1996 Received: from INET-01-IMC.microsoft.com (actually mail1.microsoft.com) by osi-east.es.net with ESnet SMTP (PP); Wed, 18 Dec 1996 15:58:43 -0800 Received: by INET-01-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BBECE7.4B02B610@INET-01-IMC.microsoft.com>; Wed, 18 Dec 1996 13:28:02 -0800 Message-ID: From: Max Morris To: 'Beatrice Chambet' , 'Isidor Kouvelas' Cc: 'REMCONF' Subject: RE: Videoconference sofware under windows NT Date: Wed, 18 Dec 1996 13:17:16 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 28 TEXT Are there NT drivers for the color Connectix QuickCam available yet? I didn't think so. Microsoft has just released the second beta of NetMeeting 2.0, with audio and video conferencing support. It works on NT 4.0. No problem using the b/w QuickCam, since there definitely are drivers available for it. If the color drivers are also available, then the color QuickCam should also work. For information on NetMeeting, see http://microsoft.com/netmeeting -Max >---------- >From: Isidor Kouvelas[SMTP:I.Kouvelas@cs.ucl.ac.uk] >Sent: Wednesday, December 18, 1996 3:40 AM >To: Beatrice Chambet >Cc: REMCONF >Subject: Re: Videoconference sofware under windows NT > >> Is there any videoconference software for windows NT 3.51 or 4.00 with >>the quickcam color camera. > >The VFW vic port will work. For information look at: >http://www.cs.ucl.ac.uk/staff/I.Kouvelas/vic > >Isidor > From rem-conf-request@es.net Thu Dec 19 03:33:15 1996 Received: from linus.socs.uts.EDU.AU by osi-east.es.net with ESnet SMTP (PP); Thu, 19 Dec 1996 00:32:31 -0800 Received: from localhost (sanjay@localhost) by linus.socs.uts.EDU.AU (8.8.4/8.8.0) with SMTP id TAA13077 for ; Thu, 19 Dec 1996 19:32:25 +1100 (EST) Date: Thu, 19 Dec 1996 19:32:22 +1100 (EST) From: sanjay X-Sender: sanjay@linus To: rem-conf@es.net Subject: Has someone added MPEG to vic? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, Has someone added MPEG compression/decomp to Vic ? I would appreciate any pointer ? Thx in advance. Sanjay Kumar Jha E-mail: sanjay@socs.uts.edu.au ph: +61 2 9514 1858 Fax: +61 2 9514 1807 From rem-conf-request@es.net Thu Dec 19 11:17:01 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 19 Dec 1996 08:16:30 -0800 Received: from little-bear.precept.com by precept.com (SMI-8.6/SMI-SVR4) id IAA17975; Thu, 19 Dec 1996 08:16:21 -0800 Received: from little-bear by little-bear.precept.com (SMI-8.6/SMI-SVR4) id IAA09362; Thu, 19 Dec 1996 08:16:20 -0800 From: John Cole Message-Id: <961219081655.ZM3646@little-bear> Date: Thu, 19 Dec 1996 08:16:54 -0700 In-Reply-To: sanjay "Has someone added MPEG to vic?" (Dec 19, 7:32pm) References: Reply-To: jcole@precept.com X-Mailer: Z-Mail 4.0 (4.0.0 Aug 21 1995) To: rem-conf@es.net Subject: Re: Has someone added MPEG to vic? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Dec 19, 7:32pm, sanjay wrote: > > Has someone added MPEG compression/decomp to Vic ? I would appreciate > any pointer ? I'm also curious to know if anyone has ever tried adding support for Indeo video to vic? -- John Cole, Systems Engineer Tel: 415.845.5200 Precept Software, Inc. Fax: 415.845.5235 1072 Arastradero Road http://www.precept.com Palo Alto, CA 94304 E-Mail: jcole@precept.com From rem-conf-request@es.net Thu Dec 19 17:50:24 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Thu, 19 Dec 1996 14:49:46 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <17019(7)>; Thu, 19 Dec 1996 14:28:24 PST Received: by crevenia.parc.xerox.com id <177713>; Thu, 19 Dec 1996 14:26:48 -0800 From: Bill Fenner To: mbone@isi.edu, rem-conf@es.net Subject: Announcing the 5.1 release of mtrace, the multicast traceroute client. Message-Id: <96Dec19.142648pst.177713@crevenia.parc.xerox.com> Date: Thu, 19 Dec 1996 14:26:33 PST $Id: README.mtrace,v 5.1 1996/12/19 21:53:24 fenner Exp $ Multicast Traceroute Release 5.1 December 19, 1996 available from ftp.parc.xerox.com, file pub/net-research/ipmulti/mtrace5.1.tar.Z binaries pub/net-research/ipmulti/mtrace5.1-sparc-sunos41x.tar.Z pub/net-research/ipmulti/mtrace5.1-sparc-solaris2.tar.Z pub/net-research/ipmulti/mtrace5.1-alpha-osf1.tar.Z pub/net-research/ipmulti/mtrace5.1-sgi-irix.tar.Z The 5.1 release represents the divorce of the multicast traceroute tool >from the mrouted distribution. To reduce confusion with mrouted, mtrace needed a version number from a completely different space, so I "arbitrarily" chose 5. The 5.1 release fixes the following bugs: o Workaround for "0 pps" printed for little-endian hops. There is a missing parenthesis in mrouted 3.8's mtrace responder, causing half of a calculation to be byte-swapped and half not. mtrace now uses the time the response was received instead of the timestamp in the packet if it detects this bug. o TTL required is now calculated correctly. o Wrong-type packets are properly ignored. If multiple mtrace's are running on a single machine, it's possible that a DVMRP_NEIGHBORS2 ("mrinfo") packet could have been misinterpreted as an mtrace packet, displaying a long trace with lots of "0.0.0.0" entries. o "-m" traces that take less hops than requested are now handled properly. o No longer allows magic address expansion for multicast addresses, so "224.100.102" is now a syntax error instead of a synonym for "224.100.102.0". o If statistics were aborted because the route changed, don't count them as having been printed. o If the last hop forgot to fill in its IP address, fill it in with the source address of the returned packet. o Missing statistics detection is now more robust; it will just print blank lines rather than the confusing "58/58=100%" then "-58/0 = --%". The 5.1 release has the following new features: o Netmask printing (with -v) and default route notification o Traces are no longer restarted from scratch when the route changes; they are continued from the information already known. o The new Watch-Path mode (-P) allows an individual path to be monitored periodically; mtrace will print the path initially and only when it changes. o Default multicast TTL changed from 64 to 127, to better match reality. o Per-hop statistics are normally only printed as a packet-per-second count; there are so many bugs in the collection of these counters that the packet loss that they report is generally misleading. The -T flag may be used to include these numbers anyway. o Don't print statistics if there is no group specified, since the per-group statistics are the only ones that are meaningful. o Change the default destination when using "-g " to if it is a different subnet than the host running mtrace. This elminiates the need to use "mtrace -g foo bar foo". o Print "[reset counters]" on a hop that has reset its counters. o Allow the number of extra hops to be traced after a non-responding router to be specified with the "-e " flag. o Statistics collection in passive mode (slightly buggy) o The -O flag may be used to supress use of the Router Alert IP option. Some versions of Cisco's IOS corrupt multicast traceroute replies when the request is sent with IP options, so if the last hop is a Cisco you may need to use -O. From rem-conf-request@es.net Thu Dec 19 19:56:44 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Thu, 19 Dec 1996 16:56:08 -0800 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14628(8)>; Thu, 19 Dec 1996 16:55:55 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177712>; Thu, 19 Dec 1996 16:55:47 -0800 To: Bill Fenner cc: mbone@isi.edu, rem-conf@es.net Subject: Re: Announcing the 5.1 release of mtrace, the multicast traceroute client. In-reply-to: Your message of "Thu, 19 Dec 96 14:26:33 PST." <96Dec19.142648pst.177713@crevenia.parc.xerox.com> Date: Thu, 19 Dec 1996 16:55:45 PST Sender: Bill Fenner From: Bill Fenner Message-Id: <96Dec19.165547pst.177712@crevenia.parc.xerox.com> I made a last-minute logic error which made the source un-buildable on systems with ANSI compilers and header files that define the __P macro. I have replaced mtrace5.1.tar.Z on ftp.parc.xerox.com with the fixed version (mtrace.c will have version 5.1.1.1 in the fixed version). Those who fetched the source and are having trouble building should fetch the fixed version and try again. Bill (pardon me while I go catch a plane... Happy Holidays, everyone!) From rem-conf-request@es.net Fri Dec 20 02:34:23 1996 Received: from dns.whnet.edu.cn by osi-west.es.net with ESnet SMTP (PP); Thu, 19 Dec 1996 23:33:33 -0800 Received: from ns ([202.197.16.1]) by dns.whnet.edu.cn (5.x/SMI-SVR4) id AA19647; Fri, 20 Dec 1996 15:31:34 +0800 Received: from pdns.nudt.edu.cn ([202.197.6.107]) by ns (4.1/SMI-4.1) id AA24889; Fri, 20 Dec 96 15:33:27 CST Message-Id: <3.0.32.19961220152919.0069f9d8@csit.edu.cn> X-Sender: huiwang@csit.edu.cn X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Dec 1996 15:29:26 +0800 To: rem-conf@es.net From: Wang Hui Subject: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" subscribe --------------------------------------------- Wang Hui Department of Systems Engineering and Applied Mathemathics Changsha Institue of Technology Changsha, Hunan Province 410073, P.R.China Tel: +86(731)455-5601 EXT. 87709,87703(Office) +86(731)421-1364 (Home) E-mail: huiwang@csit.edu.cn From rem-conf-request@es.net Fri Dec 20 02:39:18 1996 Received: from dns.whnet.edu.cn by osi-west.es.net with ESnet SMTP (PP); Thu, 19 Dec 1996 23:35:51 -0800 Received: from ns ([202.197.16.1]) by dns.whnet.edu.cn (5.x/SMI-SVR4) id AA19597; Fri, 20 Dec 1996 15:12:57 +0800 Received: from ns.csit.edu.cn by ns (4.1/SMI-4.1) id AA24854; Fri, 20 Dec 96 15:14:49 CST Date: Fri, 20 Dec 1996 15:14:44 +0800 (CST) From: "Mr. Hui Wang" To: VideoConf Mailing list Subject: subscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe ------------------------------------------------------------------- King Wang Multimedia Lab. Changsha Institue of Technology Changsha, Hunan Province 410073, P.R.China Tel: +86(731)455-2914 (Office) +86(731)421-1364 (Home) E-mail: huiwang@csit.edu.cn From rem-conf-request@es.net Fri Dec 20 10:10:06 1996 Received: from video.ecn.purdue.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 20 Dec 1996 07:09:32 -0800 Received: from video.ecn.purdue.edu (ghafoor@localhost) by video.ecn.purdue.edu (8.8.4/3.8.2moyman) id JAA16545; Fri, 20 Dec 1996 09:53:43 -0500 (EST) Message-Id: <199612201453.JAA16545@video.ecn.purdue.edu> Date: Fri, 20 Dec 1996 09:53:43 -0500 (EST) From: Arif Ghafoor To: cellular@dfv.rwth-aachen.de, perform@tay1.dec.com, tccc@cs.umass.edu Cc: announcements.chi@xerox.com, arl@arl1.wustl.edu, atm@bbn.com, ccrc@dworkin.wustl.edu, cip@bbn.com, cnom@maestro.bellcore.com, end2end-interest@isi.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, ietf@isi.edu, rem-conf@es.net Subject: Call for paper on multimedia for IEEE COMPSAC97 IEEE 25-th Annual International Computer Software and Application Conference (COMPSAC97) will be held in Washington D.C. (August 13 - 15, 1997) Papers on various topics, including multimedia, can be submitted. The detailed Call for Papers can be found at the following web site: http://www.cs.umn.edu/~tsai/compsac/compsac.html The deadline for the paper and panel proposal submission is January 15, 1997. From rem-conf-request@es.net Fri Dec 20 21:20:31 1996 Received: from email.kaiserslautern.army.mil by osi-west.es.net with ESnet SMTP (PP); Fri, 20 Dec 1996 18:20:02 -0800 Received: from sdn-ts-015txfworp05.dialsprint.net by email.kaiserslautern.army.mil id aa26011; 21 Dec 96 3:19 CET Message-ID: <32BB647E.4323@email.kaiserslautern.army.mil> Date: Fri, 20 Dec 1996 20:15:58 -0800 From: Scott Gomer Organization: AFN Kaiserslautern X-Mailer: Mozilla 2.0 (Win95; I; 16bit) MIME-Version: 1.0 To: rem-conf@es.net Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe From rem-conf-request@es.net Wed Dec 25 08:32:32 1996 Received: from dfw-ix9.ix.netcom.com by osi-west.es.net with ESnet SMTP (PP); Wed, 25 Dec 1996 05:31:54 -0800 Received: from laptop--2 (min-mn3-01.ix.netcom.com [204.30.69.97]) by dfw-ix9.ix.netcom.com (8.6.13/8.6.12) with SMTP id FAA25543 for ; Wed, 25 Dec 1996 05:31:49 -0800 Message-ID: <32C12C76.2C0E@dascom-systems.com> Date: Wed, 25 Dec 1996 07:30:30 -0600 From: Dan Takkunen Organization: Dascom Systems, Inc. X-Mailer: Mozilla 2.01 (Win95; U) MIME-Version: 1.0 To: rem-conf@es.net Subject: (no subject) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit help subscribe From rem-conf-request@es.net Wed Dec 25 20:12:38 1996 Received: from galaxy (actually galaxy.net.edu.cn) by osi-west.es.net with ESnet SMTP (PP); Wed, 25 Dec 1996 17:12:04 -0800 Received: from synet.edu.cn (saint.synet.edu.cn) by galaxy (5.x/SMI-SVR4) id AA22402; Thu, 26 Dec 1996 09:12:53 +0800 Received: from neu.edu.cn (bengal.neu.edu.cn) by synet.edu.cn (5.x/SMI-SVR4) id AA18271; Thu, 26 Dec 1996 08:12:46 +0800 Received: from ncsc.neu.edu.cn (conger.neu.edu.cn) by neu.edu.cn (4.1/SMI-4.1) id AA17751; Thu, 26 Dec 96 09:09:32 CST Received: by ncsc.neu.edu.cn (5.x/SMI-SVR4) id AA05203; Thu, 26 Dec 1996 09:12:28 +0800 Date: Thu, 26 Dec 1996 09:12:27 +0800 (CST) From: Niu Junyu Subject: Re: (no subject) To: Dan Takkunen Cc: rem-conf@es.net In-Reply-To: <32C12C76.2C0E@dascom-systems.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, send your reguest to mbone-request@zephyr.isi.edu dora. From rem-conf-request@es.net Wed Dec 25 20:52:58 1996 Received: from moon (actually moon.bjnet.edu.cn) by osi-west.es.net with ESnet SMTP (PP); Wed, 25 Dec 1996 17:51:49 -0800 Received: by moon (5.x/SMI-SVR4) id AA29433; Thu, 26 Dec 1996 09:50:56 +0800 Date: Thu, 26 Dec 1996 09:50:56 +0800 From: haitao@moon.bjnet.edu.cn (Zhang Haitao) Message-Id: <9612260150.AA29433@moon> Apparently-To: rem-conf@es.net hi, now i am using an receiver-oriented multicast file transfer application, and the sender sends data packet periodly(eg. 100ms/frame), then how can i calculate the total thoroughput of the data transfer rate? just the data amount divide elasped time? thanks , ----------------------------------------------------------------------- Zhang haitao, Email:haitao@moon.bjnet.edu.cn Lab of Multimedia and Networking, http://koala.ee.tsinghua.edu.cn Dept. of Electronic Engineering, Tsinghua University, Beijing, P.R.China ----------------------------------------------------------------------- From rem-conf-request@es.net Thu Dec 26 19:52:50 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 26 Dec 1996 16:52:13 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id QAA29290; Thu, 26 Dec 1996 16:43:47 -0800 Date: Thu, 26 Dec 1996 16:44:27 -0800 () From: Stephen Casner To: Niu Junyu cc: Dan Takkunen , rem-conf@es.net Subject: Re: (no subject) In-Reply-To: Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is wrong. The rem-conf and mbone lists are entirely separate. To subscribe to the rem-conf list, send a message to rem-conf-request@es.net. On Thu, 26 Dec 1996, Niu Junyu wrote: > Hi, > > > send your reguest to > > mbone-request@zephyr.isi.edu > > > > dora. > -- Steve From rem-conf-request@es.net Sun Dec 29 03:39:54 1996 Received: from hofmann.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Sun, 29 Dec 1996 00:39:06 -0800 Received: from internaut.com (Cust97.Max15.Seattle.WA.MS.UU.NET [153.34.42.97]) by hofmann.CS.Berkeley.EDU (8.6.11/8.6.6.Beta11) with SMTP id AAA23782; Sun, 29 Dec 1996 00:38:51 -0800 Received: from [204.57.137.9] by internaut.com (NX5.67c/NeXT-3.0) id AA24583; Sun, 29 Dec 96 00:31:53 -0800 Received: by multi with Microsoft Mail id <01BBF520.472E5D00@multi>; Sun, 29 Dec 1996 00:36:06 -0800 Message-Id: <01BBF520.472E5D00@multi> From: Bernard Aboba To: "'rem-conf@es.net'" Cc: "'casner@precept.com'" , "'louie@uu.net'" , "'thalerd@eecs.umich.edu'" Subject: RTP/RTCP scaling Date: Sun, 29 Dec 1996 00:36:05 -0800 Encoding: 134 TEXT >> On Tue, 17 Dec 1996, Louis A. Mamakos wrote: >> >> > On one particular network using IP multicast technology, we restrict (using >> > filters and other mechanisms) the ability to source to particular groups from >> > the vast majority of multicast participants whose role is generally described >> > as "receiver". This also handily solves the RTCP scaling problem :-) >> >> Yes, but it also handily precludes the feedback that RTCP was >> intended to provide. I would agree with Steve that RTCP feedback is potentially a useful thing; the data provided by RTCP is essential not only for engineering but also for business reasons. However, I would also agree with Louie that RTCP is not currently deployable at large scale. This is somewhat distressing, since I believe that we are likely to see large scale deployment of RTP over the next year, and network providers are making judgements based on current technology, that could have the potential to shape the future of internet multcast for some time to come. The problem is serious enough to warrant both a short term and a long term approach. In the short term, definition of new RTP profiles can probably get us through the next 12-18 months, by which time we may have come up with a better long term solution. I would suggest that dealing with both short and long term aspects of the problem is an appropriate agenda item for AVT. >In a "radio broadcast" type environment, it's just not at all clear to >me that the feedback which RTCP supplies is most appropriately >multicast to the same group as the content. As we discussed in the last AVT meeting, there are some cases in which it is helpful to have the RTCP feedback end up on a *different* group than RTP. For example, in a sparse mode PIM environment, putting RTP and RTCP on different groups will result in the RTCP group ending up on the shared tree, whereas if they were both on the same group, then if the RTP source rate were high enough, the RTP/RTCP group would be on to the source-based tree with a potentially high number of forwarding cache entries. However, unless you believe that DVMRP will go away sometime soon (and I don't see evidence of this), then such schemes will probably merely result in deployable islands of multicast connectivity unable to connect to the MBONE for fear of the problems that would result from doing so. Ultimately, I fear there only one solution: reducing the effective number of RTCP senders dramatically, via summarization. >There a a bunch of >issues, (including but not limited to privacy) to be considered. >Having this data be unicast back to some designated monitoring >device(s), perhaps sampled statistically, may be more appropriate. While unicasting addresses the issue of multicast forwarding table explosion, as well as some privacy concerns, it does not address the problem of RTCP rate control and population estimate convergence. Thus with unicasting, it is still possible for the sender to be overwhelmed with RTCP feedback. >> I am concerned about implementation of policy at the wrong level or >> by inflexible means. For now, it may well be that the policy must be >> imposed by the network operator administratively rather than by the >> applications. However, if the network devices are incapable of >> sending multicast in the direction from the "receivers", then >> applications can't make use of RTCP's functionality even when >> operating at a small scale. Assuming that RTP and RTCP are placed on separate groups, and that things work as we believe they will, then I believe that use of local filters blocking RTCP feedback should not be necessary; however, the need for administrative scoping or boundary-level filtering will remain until the RTCP sender proliferation problem can be addressed. >I don't seem to have very many policy choices to make right now. I >can do what I've done (prohibit the "receivers" from generating >multicast traffic), and have it work. Or I can try to replicate the >environment on the MBONE and hope it scales to the 100000 or more >customers on my network. Having the network work less and less well >as more and more participants use it is to be avoided at *all* costs. >Especially when my control (as a network operator) over the protocol >implementations on the end devices is limited. I think that there is an important lesson embedded in this problem. This is that Internet growth has reached the point where the time between deployment of "experimental" services and commercial implementations is growing smaller and smaller. This means that it is increasingly difficult to conduct field pilot programs in which early versions can be debugged and modified based on experimental results. In such environments, it is typical to see increasing emphasis on simulation techniques, with simulations validated based on limited trials. >Having the state in the network scale anything approaching linearally >with the number of users of the network is broken. This is my >reality. The only problem is scale. If it doesn't scale, it's >broken. Rest assured, there is a good level of agreement that improvements in RTCP scaling are needed. Where do not perhaps have as good agreement is in understanding what requirements a solution will need to fulfill. Your input is solicited. > I would rather see this filtering done by source-specific pruning > where the receivers, following directions from the session > originator, ask for pruning of all sources other than the intended > data sender. Since not all the mechanisms required to implement this > are in place yet, we'll have to use other means. But I hope that the > alternatives are implemented such that they can be turned off when > source pruning is ready. For source-specific pruning to help, RTP receivers would need to not listen to the RTCP feedback. Is this what is being suggested? Assuming that the RTP and RTCP groups were separated, and the RTCP group moved to the shared tree, how could source-specific pruning be employed? I'm unclear on this. >I am deploying a production network, with technology that is available >today. When and if these other technologies become available, they >may be deployed in the network. I don't see any source specific >pruning capability available in either "production quality" multicast >routers or in stacks running in the end systems. When and if these >additional features appear in the future, they'll be considered for >deployment into a production service; but they'll need to make sense >both from a business, operations and technology perspective. >Though I hope there's serious progress in a multicast interdomain >routing infrastructure and a way to specify and enforce policy between >multicast routing domains. The fact that the MBONE operates as one >big, happy "family" is reminiscent of the days when we ran EGP, except >there's even fewer tools available. >From where I sit, this looks like an accurate assessment of current technology. However, Dave Thaler has recently done some very interesting work on how to interconnect multicast routing domains. Care to comment, Dave? Bernard Aboba Microsoft From rem-conf-request@es.net Mon Dec 30 15:10:37 1996 Received: from matilda.wpine.com by osi-west.es.net with ESnet SMTP (PP); Mon, 30 Dec 1996 12:09:58 -0800 Received: from visual.wpine.com ([192.80.72.33]) by matilda.wpine.com (post.office MTA v2.0 0813 ID# 0-13495) with SMTP id AAA21509 for ; Mon, 30 Dec 1996 15:08:16 -0500 Received: from boggs.wpine.com.wpine.com by visual.wpine.com (8.6.9/VM-941107.1) id PAA10008; Mon, 30 Dec 1996 15:12:38 -0500 Received: by boggs.wpine.com.wpine.com (4.1/VN941029.1) id AA02111; Mon, 30 Dec 96 15:06:43 EST Message-Id: <9612302006.AA02111@boggs.wpine.com.wpine.com> To: rem-conf@es.net Cc: rkennerly@wpine.com Subject: Is there an "official" UDP port range for A/V data. Date: Mon, 30 Dec 1996 15:06:42 -0500 From: Brian O'Shea A while back there was mail discussing the ranges of UDP ports to use for audio, video and whiteboard data: [0, 16384) - lowest priority, unclassified [16384, 32768) - highest priority, i.e. audio [32768, 49152) - medium priority, i.e. whiteboard [49152, 65536) - low priority, i.e. video A quick grep of my RFC's and internet drafts reveals no "official" policy on this. Is this published anywhere, or is it simply "tribal knowledge"? Are the firewall vendors members of the tribe? TIA -bos +***********************************************************************+ + Brian O'Shea White Pine Software + + Reflector Group Leader 542 Amherst St + + bos@wpine.com Nashua NH, 03063 + + Phone: 603-886-9050 Fax: 603-886-9051 + + All it takes is all you've got. + +***********************************************************************+ From rem-conf-request@es.net Mon Dec 30 20:58:41 1996 Received: from proxy3.ba.best.com by osi-west.es.net with ESnet SMTP (PP); Mon, 30 Dec 1996 17:58:04 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy3.ba.best.com (8.8.4/8.8.3) with SMTP id RAA18971 for ; Mon, 30 Dec 1996 17:55:56 -0800 (PST) Date: Mon, 30 Dec 1996 17:55:56 -0800 (PST) Message-Id: <1.5.4.16.19961230184430.13ff024e@pop.best.com> X-Sender: rsf@pop.best.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Ross Finlayson Subject: Re: Is there an "official" UDP port range for A/V data. >A while back there was mail discussing the ranges of UDP ports to use for >audio, video and whiteboard data: > > [0, 16384) - lowest priority, unclassified > [16384, 32768) - highest priority, i.e. audio > [32768, 49152) - medium priority, i.e. whiteboard > [49152, 65536) - low priority, i.e. video > >A quick grep of my RFC's and internet drafts reveals no "official" policy on >this. This reminds me of something that I forgot to bring up when we were discussing this last: According to the IANA document "ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers", the "dynamic and/or private" ports are those in the range 49152 through 65535; ports lower than 49152 are in the "well-known" or "registered" ranges. This suggests (to me anyway) that transient multimedia sessions, such as those created by SDP browsers, should really be using only the range 49152 through 65535: the range that mrouted currently treats as "low priority, i.e., video". Perhaps it's *this* port range that we should really be partitioning and prioritizing? Ross. From rem-conf-request@es.net Tue Dec 31 19:52:47 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 31 Dec 1996 16:52:09 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id QAA06426; Tue, 31 Dec 1996 16:22:49 -0800 Date: Tue, 31 Dec 1996 16:24:14 -0800 () From: Stephen Casner To: Brian Bulkowski cc: rem-conf@es.net Subject: Re: Group size estimation In-Reply-To: <3.0.32.19961211135744.00cabfcc@gw.navio.com> Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII During the IETF meeting, Brian Bulkowski sent the subject message describing some algorithms that might be used to calculate the RTCP interval without having to keep track of all participants when the number gets very large. I'll reply to some specific points in Brian's message below, but I'd like to first comment on the discussions in the meeting and on the history of the RTCP interval algorithm. There was some confusion in the meeting because Henning Schulzrinne had misinterpreted the RTP spec regarding the initial RTCP interval being randomized over [0,2.5] seconds rather than [1.25,3.75]. Van Jacobson pointed out that this difference is important so the receiver can listen to the incoming report rate before sending its first report. However, the RTCP interval calculation algorithm as currently specified does NOT include the "reconsideration" idea that Henning was describing. That is, when the interval expires, calculate a new estimate of the group size and skip sending the report if the previous interval was too short. Without this reconsideration, waiting doesn't help: if a million receivers were to auto-start in perfect synchrony for a scheduled event, there would be a million packets sent over a 2.5 second interval. To allow enough time to hear other's reports at low bandwiths so that reconsideration work properly, I believe we should also make the minimum RTCP interval scale upward from the current 5 second value for low bandwidths. The 5 second value is appropriate for on the order of 100 kb/s. This notion of reconsideration is particularly important for very large groups and ties in with Brian's question about algorithms for estimating group size without keeping track of all the participants. I don't remember a discussion of the reconsideration idea in past AVT meetings (I didn't find it in the transcripts or minutes), but we did talk about estimating group size via sampling, as did Christian Huitema in the recent meeting. That brings me to a few specific responses to Brian's message: Regarding RFC 1889 section 6.2.1 on estimating the number of participants in order to calculate the RTCP interval: > One interesting point of the wording is that > it assumes an estimate of what the report interval is, but I see nowhere > else that suggests a good method for getting that estimate. This may appear recursive, but it's not really a problem. Timeouts for maintaining the membership table are based on the current value of the RTCP interval, and the interval will change to converge to the right value as the membership table grows. The initial estimate for the RTCP interval is the minimim value (5 seconds). > In most algorythms, you need an estimate of the report interval, including > the spec'd algorythm; here's one that comes to mind. Maintain an estimate > of the RR interval by tracking a small number of specific SSRC RR timings. > Make a table including the last time heard, number of times heard from, and > SSRC value. Whenever you receive an SSRC BYE packet, invalidate that timing > entry. When you have received a certain number of SSRC packets (5?), add > the interval to the running average, then clear the entry. On every RR > receipt, check for an empty entry, if you find one, use that SSRC value for > estimation. Have a timer run though the interval estimation table to throw > out entries that it hasn't heard from for a while. Suggested time is three > times the current report interval. One problem here is that it would take 5 intervals before one could send a report. I think the algorithm needs to be able to respond after a time on the order of one interval. A more serious problem is that if everyone is using this algorithm, you'll either get deadlock with everyone waiting for someone else to send first so they can estimate the interval, or one guy will send at the minimum 5 seconds and everyone else will follow. > Is there another way of estimating the report interval besides watching > everyone else? If you have a size-of-group estimate, and a stream size > estimate, you can calculate the report interval. This can be used instead, > except in initial cases. There was a bit of discussion at the IETF about > initial wait intervals before sending RR packets. As Christian pointed out, you can estimate the group size through sampling. You keep track of only a subset of the SSRC id's you hear by accepting only those that match some criterion with a probability of 1/(2^n). Then you multiply the number you count by 2^n to get your estimate. As Henning and I have been discussing in some private email, you may want to start with n=0 for the normal small-scale case, and then increase n (discarding those SSRCs that don't match the new lower probability criterion) when you reach the max number you want to save. > In terms of getting group size, once you have a good estimate of the report > interval, you need only keep track of the number of RR packets received > (say, per second, making sure you use a different timer than all others). > Whenever you desire the size of the receiver group, multiply the current > report interval by the number of RRs received, and you get the size of the > receiver group. I don't think you would do this; it would be the other way around as in the previous paragraph. > This algorythm seems to converge slowly, but has a nice attribute that if > you are losing RR packets, you get a larger size estimation, which leads to > the sending of fewer RR packets, which means that the algorythm is > congestion friendly. The sampling technique is subject to under-estimation if RR packets are lost. However, assuming that the bandwidth is sufficient to allow 5% for RTCP, then with the reconsideration the rate should be close to the target value and you should not be losing lots of RR packets. If packets arrive faster than the session bandwidth should allow, this should insure that the reconsideration backs off. > In order to dynamically resize the hash table, you could keep track of a > few marker buckets, and whenever there is a collision in one of your marker > buckets, realloc your table and start again. Or, you could make an estimate > at the amount of collision you are getting, and multiply your size estimate > by that factor. This allows people to pick certain table sizes and not > reallocate. In the "marker buckets" you need to keep track of the exact > SSRCs received, so you can detect true collisions vs. bogus collisions due > to inaccurate estimation of the report interval. This is approaching the sampling algorithm described above. > I'm sure that the RTP designers thought over these issues. It is clear that > the current set of "mays" in section 6.2.1 will not work with large > receiver groups. Would it be better to add suggested algorythms and words > for larger groups, or would it be better to spec one of the other > estimation algorythms (like the polling one) which doesn't require the > receiver's calculation of receiver groupsize? Or would it be better to turn > off RRs in large groups? What's the thinking? We deliberately chose to keep the example algorithm in the RTP spec simple in the hope that we could avoid having implementers decide that it was too complicated and just put in a fixed number instead. Or even worse, to abandon RTP entirely. This is a very real concern since there is not really any way to "enforce" a standard. On the other hand, after more time has elapsed and RTP has gained some level of acceptance, it is appropriate now to consider specifying a more complete algorithm. -- Steve