From rem-conf-request@es.net Wed Jan 01 11:10:53 1997 Received: from proxy2.ba.best.com by osi-west.es.net with ESnet SMTP (PP); Wed, 1 Jan 1997 08:10:22 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy2.ba.best.com (8.8.4/8.8.3) with SMTP id IAA09555; Wed, 1 Jan 1997 08:07:38 -0800 (PST) Date: Wed, 1 Jan 1997 08:07:38 -0800 (PST) Message-Id: <1.5.4.16.19970101085641.241f179c@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: New multicast session browser available for testing Cc: multimedia@freebsd.org, karl@best.com Happy New Year. I'm pleased to announce the availability (for 'alpha testing') of "multikit": a new multicast session browser. As a special case, multikit implements a SDP browser; this can be used as an alternative to "sdr". (This is analogous to the way that Web browsers can also be used as FTP clients.) However, multikit also extends the SDP/SAP model in several ways - most notably: - directories are 'first-class' objects, and can be 'announced' just like any other session - sessions can have arbitrary attributes (not just the fixed set of attributes that were defined for SDP) - SDP's session bundling mechanism is generalized: Any arbitrary collection of sessions can be combined and announced as a single 'bundle' - a variety of 'announcement' protocols are possible. Different directories can use different protocols to share information. (The protocol for each directory is specified as an attribute of the directory.) multikit provides an extensible framework that can be used for experimenting with new multicast-based protocols (e.g., with differing degrees of reliability). It will, I hope, help to motivate new uses for the MBone, beyond the traditional audio/video applications. multikit is currently available for two platforms: Windows 95 (and NT), and FreeBSD Unix. (I can port the system to other versions of Unix if anyone wants to give me a guest account.) Note: This is free software, but please be aware that the current version is 'alpha' software. (However, I anticipate that future versions of multikit will also remain free for experimental and non-commercial use.) For more information about multikit - including downloading instructions - please see: http://www.lvn.com/multikit Ross. From rem-conf-request@es.net Thu Jan 02 18:23:50 1997 Received: from rizzo.infobahnos.com by osi-west.es.net with ESnet SMTP (PP); Thu, 2 Jan 1997 15:23:01 -0800 Received: from 204.19.114.90 (ppp-0240.infobahnos.com [204.19.114.90]) by rizzo.infobahnos.com (8.7.6/A/UX 3.1) with SMTP id SAA15676 for ; Thu, 2 Jan 1997 18:23:15 -0500 (EST) Message-ID: <32CBFE9A.117B@infobahnos.com> Date: Thu, 02 Jan 1997 18:29:57 +0000 From: sprinter@infobahnos.com X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) MIME-Version: 1.0 To: rem-conf@es.net References: <199701022318.SAA15478@rizzo.infobahnos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe From rem-conf-request@es.net Mon Jan 06 05:58:21 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 6 Jan 1997 02:57:38 -0800 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 6 Jan 1997 10:57:11 +0000 To: rem-conf@es.net Subject: New RTP audio redundancy draft available Date: Mon, 06 Jan 1997 10:57:06 +0000 Message-ID: <847.852548226@cs.ucl.ac.uk> From: Colin Perkins A revised draft of the RTP payload type for redundant audio is now available as draft-perkins-rtp-redundancy-02.txt and is enclosed below. There are no protocol changes in this revision, but a number of clarifications have been made based on comments received,. The major outstanding issue is the choice of RTP payload type. Currently, RAT and FreePhone use a dynamic payload type for redundant audio, yet as the number of tools implementing redundancy increases, it may make sense to assign a static payload type, to ease interoperability. I'm interested in hearing opinions on this matter... Colin ------------------------------------------------------------------------------- INTERNET-DRAFT 3 January 1997 Colin Perkins Isidor Kouvelas Vicky Hardman University College London Mark Handley ISI Jean-Chrysostome Bolot Andres Vega-Garcia Sacha Fosse-Parisis INRIA Sophia Antipolis RTP Payload for Redundant Audio Data draft-perkins-rtp-redundancy-02.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Comments are solicited and should be addressed to the authors and/or the AVT working group's mailing list at rem-conf@es.net. Abstract This document describes a payload type for use with the real-time transport protocol (RTP), version 2, for encoding redundant data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications. Perkins et al Page 1 INTERNET-DRAFT 3 January 1997 1 Introduction If multimedia conferencing is to become widely used by the Internet Mbone community, users must perceive the quality to be sufficiently good for most applications. We have identified a number of problems which impair the quality of conferences, the most significant of which is packet loss over the Internet Mbone. Packet loss is a persistent problem, particularly given the increasing popularity, and therefore increasing load, of the Internet. The disruption of speech intelligibility even at low loss rates which is currently experienced may convince a whole generation of users that multimedia conferencing over the Internet is not viable. The addition of redundancy to the data stream is offered as a solution [1]. If a packet is lost then the missing information may be reconstructed at the receiver >from the redundant data that arrives in the following packet(s), provided that the average number of consequutively lost packet is small. Recent work [4,5] shows that packet loss patterns in the Internet are such that this scheme typically functions well. This document proposes an RTP payload format for the transmission of data encoded in such a redundant fashion. 2 Requirements The requirements for a redundant encoding scheme under RTP are as follows: o Packets have to carry a primary encoding and one or more redundant encodings. o As a multitude of encodings may be used for redundant information, each block of redundant encoding has to have an encoding type identifier. o As the use of variable size encodings is desirable, each encoded block in the packet has to have a length indicator. o The RTP header provides a timestamp field that corresponds to the time of creation of the encoded data. When redundant encodings are used this timestamp field can refer to the time of creation of the primary encoding data. Redundant blocks of data will correspond to different time intervals than the primary data, and hence each block of redundant encoding will require its own timestamp. To reduce the number of bytes needed to carry the timestamp, it can be encoded as the difference of the timestamp for the redundant encoding and the timestamp ofthe primary. There are two essential means by which redundant audio may be added to the standard RTP specification: a header extension may hold the Perkins et al Page 2 INTERNET-DRAFT 3 January 1997 redundancy, or one, or more, additional payload types may be defined. These are now discussed in turn. 3 Use of RTP Header Extension The RTP specification [2] states that applications should be prepared to ignore a header extension. Including all the redundancy information for a packet in a header extension would make it easy for applications that do not implement redundancy to discard it and just process the primary encoding data. There are, however, a number of disadvantages with this scheme: o There is a large overhead from the number of bytes needed for the extension header (4) and the possible padding that is needed at the end of the extension to round up to a four byte boundary (up to 3 bytes). For many applications this overhead is unacceptable. o Use of the header extension limits applications to a single redundant encoding, unless further structure is introduced into the extension. This would result in further overhead. For these reasons, the use of RTP header extension to hold redundant audio encodings is disregarded. 4 Use Of Additional RTP Payload Types The RTP profile for audio and video conferences [3] lists a set of payload types and provides for a dynamic range of 32 encodings that may be defined through a conference control protocol. This leads to two possible schemes for assigning additional RTP payload types for redundant audio applications: 1.A dynamic encoding scheme maybe defined, for each combination of primary/redundant payload types, using the RTP dynamic payload type range. 2.A single fixed payload type may be defined to represent a packet with redundancy. This may then be assigned to either a static RTP payload type, or the payload type for this may be assigned dynamically. 4.1 Dynamic Encoding Schemes It is possible to define a set of payload types that signify a particular combination of primary and secondary encodings for each of the 32 dynamic payload types provided. This would be a slightly restrictive yet feasible Perkins et al Page 3 INTERNET-DRAFT 3 January 1997 solution for packets with a single block of redundancy as the number of possible combinations is not too large. However the need for multiple blocks of redundancy greatly increases the number of encoding combinations and makes this solution not viable. A modified version of the above solution could be to decide prior to the beginning of a conference on a set a 32 encoding combinations that will be used for the duration of the conference. All tools in the conference can be initialized with this working set of encoding combinations. Communication of the working set can be made through the use of an external, out of band, mechanism. Setup is complicated as great care needs to be taken in starting tools with identical parameters. This scheme is more efficient as only one byte is used to identify combinations of encodings. It is felt that the complication inherent in distributing the mapping of payload types onto combinations of redundant data preclude the use of this mechanism. 4.2 Payload Type to Mean ``Packet-With-Redundancy'' A more flexible solution is to have a single payload type which signifies a packet with redundancy and have each of the encoding blocks in the packet contain it's own payload type field: such a packet acts as a container, encapsulating multiple packets into one. Such a scheme is flexible, since any number of redundant encodings may be enclosed within a single packet. There is, however, a small overhead since each encapsulated packet must be preceded by a header indicating the type of data enclosed. This is the preferred solution, since it is both flexible, extensible, and has a relatively low overhead. The remainder of this document describes this solution. 5 RTP payload type for redundant data The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done then a payload type in the dynamic range shall be chosen. An RTP packet containing redundant data shall have a standard RTP header, with payload type indicating redundancy. The other fields of the RTP header relate to the primary data block of the redundant data. Following the RTP header are a number of additional headers, defined in the figure below, which specify the contents of each of the encodings carried by the packet. Following these additional headers are a number of data blocks, which contain the standard RTP payload data for these Perkins et al Page 4 INTERNET-DRAFT 3 January 1997 encodings. It is noted that all the headers are aligned to a 32 bit boundary, but that the payload data will typically not be aligned. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | timestamp offset | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The bits in the header are specified as follows: F: 1 bit First bit in header indicates whether another header block follows. If 1 further header blocks follow, if 0 this is the last header block. block PT: 7 bits RTP payload type for this block. timestamp offset: 14 bits Unsigned offset of timestamp of this block relative to timestamp given in RTP header. This uses the same clock as the primary encoding. The use of an unsigned offset implies that redundant data must be sent after the primary data, and is hence a time to be subtracted from the current timestamp to determine the timestamp of the data for which this block is the redundancy. block length: 10 bits Length in bytes of the corresponding data block excluding header. It is noted that the use of an unsigned timestamp offest limits the use of redundant data slightly: it is not possible to send redundancy before the primary encoding. This may affect schemes where a low bandwidth coding suitable for redundancy is produced early in the encoding process, and hence could feasibly be transmitted early. However, the addition of a sign bit would unacceptably reduce the range of the timestamp offset, and increasing the size of the field above 14 bits limits the block length field. It seems that limiting redundancy to be transmitted after the primary will cause fewer problems than limiting the size of the other fields. It is further noted that the block length and timestamp offset are 10 bits, and 14 bits respectively; rather than the more obvious 8 and 16 bits. Whilst such an encoding complicates parsing the header information slightly, and adds some additional processing overhead, there are a number of problems involved with the more obvious choice: An 8 bit block length field is sufficient for most, but not all, possible encodings: for example 80ms PCM and DVI audio packets comprise more than 256 bytes, and cannot be encoded with a single byte length field. It is possible to impose additional structure on the block length field (for example the high bit set could imply the lower 7 bits code a length in words, rather than bytes), however such schemes are complex. The use of a Perkins et al Page 5 INTERNET-DRAFT 3 January 1997 10 bit block length field retains simplicity and provides an enlarged range, at the expense of a reduced range of timestamp values. A 14 bit timestamp value does, however, allow for 4.5 complete packets delay with 48KHz audio, more at lower sampling rates, and it is felt that this is sufficient. The primary encoding block header is placed last in the packet. It is therefore possible to omit the timestamp and block-length fields >from the header of this block, since they may be determined from the RTP header and overall packet length. The header for the primary (final) block comprises only a zero marker bit, and the block payload type information, a total of 8 bits. This is illustrated in the figure below: Perkins et al Page 6 INTERNET-DRAFT 3 January 1997 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0| BlockPT | +-+-+-+-+-+-+-+-+ The final header is followed, immediately, by the data blocks, stored in the same order as the headers. There is no padding or other delimiter between the data blocks, and they are typically not 32 bit aligned. Again, this choice was made to reduce bandwidth overheads, at the expense of additional decoding time. 6 Limitations The RTP marker bit is not preserved for redundant data blocks. Hence if the primary (containing this marker) is lost, the marker is lost. It is believed that this will not cause undue problems: even if the marker bit was transmitted with the redundant information, there would still be the possibility of its loss, so applications would still have to be written with this in mind. In addition, CSRC information is not preserved for redundant data. The CSRC data in the RTP header of a redundant audio packet relates to the primary only. Since CSRC data in an audio stream is expected to change relatively infrequently, it is recommended that applications which require this information assume that the CSRC data in the RTP header may be applied to the reconstructed redundant data. 7 Security Considerations RTP packets containing redundant information are subject to the security considerations discussed in the RTP specification [2], and any appropriate RTP profile (for example[3]). This implies that confidentiality of the media streams is achieved by encryption. Encryption of a redundant data-stream may occur in two ways: 1.The entire stream is to be secured, and all participants are expected to have keys to decode the entire stream. In this case, nothing special need be done, and encryption is performed in the usual manner. 2.A portion of the stream is to be encrypted with a different key to the remainder. In this case a redundant copy of the last packet of that portion cannot be sent, since there is no following packet which is encrypted with the correct key in which to send it. Similar limitations may occur when enabling/disabling encryption. Perkins et al Page 7 INTERNET-DRAFT 3 January 1997 The choice between these two is a matter for the encoder only. Decoders can decrypt either form without modification. 8 Example Packet An RTP audio data packet containing a DVI4 (8KHz) primary, and a single block of redundancy encoded using 8KHz LPC is illustrated: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC=0 |M| PT | sequence number of primary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp of primary encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| block PT=7 | timestamp offset | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| block PT=5 | | +-+-+-+-+-+-+-+-+ + | | + LPC encoded redundant data (PT=7) + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | DVI4 encoded primary data (PT=5) | + +---------+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Perkins et al Page 8 INTERNET-DRAFT 3 January 1997 9 Author's Addresses Colin Perkins/Isidor Kouvelas/Vicky Hardman Department of Computer Science University College London London WC1E 6BT United Kingdom Email: {c.perkins|i.kouvelas|v.hardman}@cs.ucl.ac.uk Mark Handley USC Information Sciences Institute c/o MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA Email: mjh@isi.edu Jean-Chrysostome Bolot/Andres Vega-Garcia/Sacha Fosse-Parisis INRIA Sophia Antipolis 2004 Route des Lucioles, BP 93 06902 Sophia Antipolis France Email: {bolot|avega}@sophia.inria.fr 10 References [1] V.J. Hardman, M.A.Sasse, M. Handley and A. Watson; Reliable Audio for Use over the Internet; Proceedings INET'95, Honalulu, Oahu, Hawaii, September 1995. http://www.isoc.org/in95prc/ [2] H. Schulzrinne, S.Casner, R. Frederick and V. Jacobson; RTP: A Transport Protocol for Real-Time Applications; RFC 1889, January 1996 [3] H. Schulzrinne; RTP Profile for Audio and Video Conferences with Minimal Control; RFC 1890, January 1996 [4] M. Yajnik, J.Kurose and D. Towsley; Packet loss correlation in the MBone multicast network; IEEE Globecom Internet workshop, London, November 1996 [5] J.-C. Bolot and A. Vega-Garcia; The case for FEC-based error control for packet audio in the Internet; Multimedia Systems, 1997 Perkins et al Page 9 ------------------------------------------------------------------------------- From rem-conf-request@es.net Mon Jan 06 10:20:40 1997 Received: from max.fys.ruu.nl by osi-west.es.net with ESnet SMTP (PP); Mon, 6 Jan 1997 07:16:54 -0800 Received: from fysav (fysav.fys.ruu.nl [131.211.32.53]) by max.fys.ruu.nl (8.7.5/8.7.3/hjm) with SMTP id QAA27694 for ; Mon, 6 Jan 1997 16:15:42 +0100 (MET) Sender: A.C.Balke@fys.ruu.nl Message-ID: <32D1171E.5902@fys.ruu.nl> Date: Mon, 06 Jan 1997 16:15:42 +0100 From: Christiaan Balke X-Mailer: Mozilla 3.0Gold (X11; I; HP-UX B.10.10 9000/710) MIME-Version: 1.0 To: rem-conf@es.net Subject: What RFC-number for Session Description Protocol Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo people, And the best wishes for 1997. My wish at the moment is to know the RFC number in which SDPv2 is described, if such a rfc is not obsoleted. And if you also have an URL, please mail me so. -- Hartelijke groeten Christiaan -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- A.C. Balke | E-mail : a.c.balke@fys.ruu.nl =-=-=-=-=--=-=-=- Tel : +31-030-2534504 FAX : +31-302537555 WWW : http://www.fys.ruu.nl/~balke/chris_home_pers.html Department of Physics & Astronomy, Utrecht University Post box 80.000, 3508 TA Utrecht, The Netherlands. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ><> =- From rem-conf-request@es.net Mon Jan 06 10:45:41 1997 Received: from buttle. (actually buttle.lcs.mit.edu) by osi-west.es.net with ESnet SMTP (PP); Mon, 6 Jan 1997 07:45:11 -0800 Received: from buttle.lcs.mit.edu by buttle. (SMI-8.6/SMI-SVR4) id KAA18561; Mon, 6 Jan 1997 10:44:23 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Christiaan Balke cc: rem-conf@es.net Subject: Re: What RFC-number for Session Description Protocol In-reply-to: Your message of "Mon, 06 Jan 1997 16:15:42 +0100." <32D1171E.5902@fys.ruu.nl> Date: Mon, 06 Jan 1997 10:44:22 -0500 Message-ID: <18559.852565462@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu >And the best wishes for 1997. My wish at the moment is to >know the RFC number in which SDPv2 is described, if such a >rfc is not obsoleted. It's still an internet-draft right now. draft-ietf-mmusic-sdp-02.{txt,ps} Mark From rem-conf-request@es.net Mon Jan 06 22:16:28 1997 Received: from research.apple.com by osi-west.es.net with ESnet SMTP (PP); Mon, 6 Jan 1997 19:15:55 -0800 Received: from [17.255.9.143] (jpallas.research.apple.com [17.255.9.143]) by research.apple.com (8.7.2/8.6.12) with ESMTP id TAA02234 for ; Mon, 6 Jan 1997 19:09:06 -0800 (PST) X-Sender: pallas@mail.apple.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 6 Jan 1997 19:15:35 -0800 To: rem-conf@es.net From: Joe Pallas Subject: Event: MacWorld Expo keynote - Jan. 7 Technology willing, the MacWorld Expo keynote speech by Apple CEO Dr. Gil Amelio will be transmitted via multicast RTP tomorrow (Tuesday), Jan. 7, 1200 PST. Dr. Amelio is expected to talk about how Apple's future Macintosh operating systems will take advantage of NeXT's software. The session is advertised with sdr. joe -- Joe Pallas Apple Research Labs When your only problem is a nail, every tool looks like a hammer. From rem-conf-request@es.net Tue Jan 07 02:36:54 1997 Received: from naveen.ncst.ernet.in by osi-west.es.net with ESnet SMTP (PP); Mon, 6 Jan 1997 23:36:14 -0800 Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3]) by naveen.ncst.ernet.in (8.6.12/8.6.6) with ESMTP id NAA11732 for ; Tue, 7 Jan 1997 13:09:28 +0530 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-8.6.5) id NAA26527; Tue, 7 Jan 1997 13:05:13 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA06964; Tue, 7 Jan 97 13:04:23+0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9701070734.AA06964@ece.iisc.ernet.in> Subject: RTP timestamps and devices To: rem-conf@es.net Date: Tue, 7 Jan 97 13:04:22 GMT+5:30 Cc: anand@ece.iisc.ernet.in (SVR Anand) X-Mailer: ELM [version 2.3 PL11] Hi, I would like to know the mechanism(s) for getting the sampling instants from the audio device for RTP timestamping. How can I implement the monotonically increasing clock using the audio device ? My development platform is MSWindows, and I am using the multimedia library for recording, and playback audio samples. It would be of great help to me, if you can let me know how to go about realising the clock. Since RTP is not tied to any particular operating environment, I am sure there will be a way of getting around my problem. Thanks. Regards Anand. From rem-conf-request@es.net Tue Jan 07 05:22:25 1997 Received: from proxy1.ba.best.com by osi-west.es.net with ESnet SMTP (PP); Tue, 7 Jan 1997 02:21:31 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy1.ba.best.com (8.8.4/8.8.3) with SMTP id CAA27110; Tue, 7 Jan 1997 02:19:05 -0800 (PST) Date: Tue, 7 Jan 1997 02:19:05 -0800 (PST) Message-Id: <1.5.4.16.19970107030716.3c3f67be@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, mbone@isi.edu From: Ross Finlayson Subject: multikit update: corrected URL; new mailing list; guest account(s) desired Cc: multimedia@freebsd.org Thanks to those of you so far who have tested the "multikit" enhanced multicast session browser. More testers are always welcome; for more information, please see "http://www.lvn.com/multikit/". ^ | NOTE: For now you apparently need to include the trailing "/" (my web provider's site is misconfigured; I'll see if I can get this fixed). My apologies to those of you who got tripped up over this. I hope to port the software to more Unix variants - especially SunOS, Solaris and Linux. Would anyone like to set up a guest account for me on one or more of these platforms? In other news, I've set up a new mailing list - "multikit@lists.best.com" - as an open forum for discussion of multikit - e.g., - Comments and discussions on various features of multikit, including bug reports and suggestions for improvements - Announcements of new versions of multikit (or related software) - Announcements of new "invoked command" implementations, or of new public services accessible from a multikit directory To subscribe to the mailing list, send a message to "multikit-request@lists.best.com", with the word subscribe in the BODY of the message. Ross. From rem-conf-request@es.net Tue Jan 07 15:03:23 1997 Received: from dworkin.wustl.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 7 Jan 1997 12:02:42 -0800 Received: (from milind@localhost) by dworkin.wustl.edu (8.6.10/8.6.6.yuck) id OAA10950 for rem-conf@es.net; Tue, 7 Jan 1997 14:02:56 -0600 Date: Tue, 7 Jan 1997 14:02:56 -0600 From: "Milind M. Buddhikot" Message-Id: <199701072002.OAA10950@dworkin.wustl.edu> To: rem-conf@es.net Subject: CFP for NOSSDAV97 (Submission Deadline: Jan 15) Hi: Enclosed please find a Call-for-Papers (CFP) for the 7th International Workshop on Network and Operating Systems Support for Digital Audio and Video to be held in St. Louis, Missouri (USA) from May 19-21, 1997. Please feel free to circulate the CFP by any means you deem appropriate. Also, please excuse any multiple copies of this CFP you may receive due to your memberships in multiple mailing lists. Please note that the deadline for submissions is Jan 15, 1997 (fast approaching) Thanks and regards. Milind ***************************************************************************** * * * NOSSDAV'97 * * * * Call-for-Papers * * * * * * The 7th International Workshop on Network and Operating System * * Support for Digital Audio and Video (NOSSDAV 97) * * * * URL: http://www.arl.wustl.edu/NOSSDAV97/nossdav.html * * * * May 19 - 21 1997 * * * * Hosted by: * * The Applied Research Laboratory * * Department of Computer Science * * Washington University in St. Louis, Missouri * * * * Sponsored by IEEE Communications Society * * In cooperation with ACM SIGCOMM and SIGMM * ****************************************************************************** Objectives The 7th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 97) is the international workshop concerned with state of the art technology in networking and operating system support for multimedia systems. For seven years, NOSSDAV has proven to be an outstanding forum for researchers involved in building innovative multimedia systems, networks and applications on both the research and industrial front. Other topics that will be examined include "middleware" for multimedia, media toolkits, mobile communications, Virtual Reality (VR), real-time systems, software agents, digital libraries, and other digital media besides audio and video. A key aspect of the workshop is that it provides extensive discussion periods during which attendees can informally discuss their current work and future research directions. Traditionally, NOSSDAV has emphasized on high quality experimental research that prototypes systems to explore innovative solutions to the problems in the diverse areas of multimedia computing. NOSSDAV97 will continue this tradition. Relevant topics for the workshop include: * APIs and Continuous Media (CM) programming abstractions for multimedia * Cell-based system architectures * Communication protocols for multimedia * Distributed multimedia systems * End-to-end admission control * High-speed/ATM networks * Micro-kernel and OS support for real-time communications * Mobile multimedia systems * Multicast protocols and media scaling * Multimedia network interfaces * Multimedia-oriented desk, local and wide area networks * Multimedia and the Internet * Multimedia storage, server, and I/O architectures * Quality of service and synchronization frameworks * Resource management and reservation in the OS and network * Software agents for multimedia systems * TV set-top device communication * VOD system architecture * VR systems * Workstation and PDA architectures for multimedia Submissions Two types of submissions are solicited: position papers and research papers. For the purpose of paper review, position papers are restricted to three single-spaced pages. Research papers are restricted to an extended abstract no longer than five formatted postscript pages. To complete your submission, please send the following items by electronic mail to NOSSDAV97@arl.wustl.edu (1) The research or position paper in POSTSCRIPT form. (2) The title of the paper, a list of authors with complete contact information in the form of email address and phone number, and an abstract summarizing the paper in PLAIN TEXT. Only if electronic submission is impossible, papers may be sent to the following mailing address. Dr. Gurudatta M. Parulkar ATTN: NOSSDAV 97 Washington University Department of Computer Science Applied Research Laboratory Campus Box 1045 St. Louis, Missouri 63130 USA The paper abstracts will be circulated among the NOSSDAV97 program committee members to solicit reviewers. Please note that the proceedings of the workshop will be published as a book by Springer-Verlag and the best papers will be forwarded to selected journals for publication. Important Dates Submission Deadline: 15 January 1997 (A FIRM DEADLINE) Acceptance Notification: 15 March 1997 Final Paper Due: 15 April 1997 (A FIRM DEADLINE) Workshop: 19 - 21 May 1997 Program Chair Dr. Gurudatta M. Parulkar Director, Applied Research Lab Department of Computer Science Washington University, St. Louis MO. USA guru@arl.wustl.edu, TEL: (314) 935-7534 Local Arrangements Chair John D. DeHart Senior Research Associate, Applied Research Lab Department of Computer Science Washington University, St. Louis MO. USA jdd@arl.wustl.edu, TEL: (314) 935-7534 Other Correspondance: NOSSDAV97@arl.wustl.edu TEL: (314) 935-7534 Program Committee Andrew T. Campbell, Columbia University Domenico Ferrari, Universita` Cattolica, Italy Kevin Jeffay, Univ of North Carolina Mike Jones, Microsoft, Inc. Chuck Kalmanek, AT&T Research Dilip Kandlur, IBM, TJ Watson Research S. Keshav, Cornell University Jim Kurose, University of Masachusetts Monica Lam, Stanford University Ian Leslie, Cambridge University, UK Tom Little, Boston University Derek McAuley, University of Glasgow, UK Steve McCanne, Univ of California, Berkeley A. Desai Narasimhalu, National University of Singapore Gerald Neufeld, Univ of British Columbia, Canada Duane Northcutt, Sun Microsystems Joe Pasquale, Univ of California, San Diego Bernhard Plattner, ETH, Zurich Steve Pink, SICS, Sweden P Venkat Rangan, Univ of California, San Diego KK Ramakrishnan, AT&T Research Henning Schulzrinne, Columbia University Brian Smith, Cornell University Doug Shepherd, University of Lancaster, UK Ralf Steinmetz, University of Darmstadt, Germany James Sterbenz, GTE Dan Swinehart, Xerox PARC Hideyuki Tokuda, Keio University, Japan Harrick Vin, Univ of Texas, Austin Raj Yavatkar, Intel Radu Popescue-Zeletin, GMD FOKUS, Germany Hui Zhang, CMU Publicity Chair Milind M. Buddhikot Graduate Research Assistant Department of Computer Science Washington University, St. Louis MO, USA milind@dworkin.wustl.edu TELE (314) 935 4302 Publications Chair Vykky A. Klingenberg Technical Assistant, Applied Research Laboratory Department of Computer Science Washington University, St. Louis MO, USA vykky@arl.wustl.edu TELE (314) 935 7534 LOCATION As is traditional, the workshop will take place at an elite resort, away from the hustle and bustle of daily life. Innsbrook Estates Executive Conference Center is located on 3,200 acres of the most gorgeous rolling Missouri woodland, dotted by crystal clear lakes. For accommodations, there are 1, 2, and 3-bedroom condominiums which are fully equipped with living and dining areas, fireplaces, cable television and kitchens to offer conferees all the comforts of home in a lakeside or wooded hideaway. You want to relax after a day of lectures? There is an eighteen hole golf-course, a junior-olympic swimming pool, lighted tennis courts, mini-fitness center with a sauna and hot tub, softball, volleyball, horseback riding, miniature golf course, fishing, lake swimming, canoeing, and sailing, just to name a few of the amenities. A relaxing excursion to a scenic location away >from the conference site is also being planned. From rem-conf-request@es.net Wed Jan 08 04:28:54 1997 Received: from rupertsberg.cs.colorado.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 8 Jan 1997 01:28:16 -0800 Received: (from evi@localhost) by rupertsberg.cs.colorado.edu (8.7.6/8.7.3) id CAA15785 for rem-conf@es.net; Wed, 8 Jan 1997 02:28:12 -0700 (MST) Date: Wed, 8 Jan 1997 02:28:12 -0700 (MST) From: Evi Nemeth Message-Id: <199701080928.CAA15785@rupertsberg.cs.colorado.edu> To: rem-conf@es.net Subject: USENIX Technical Conference Wednesday - Friday, January 8 -10, 1997, vat/vic/wb The keynote address (James Gosling on Developing in "Internet Time") and selected refereed sessions (performance, caching, client tricks, user tools) and invited talks (matt blaze on cyrptography, rob pike on inferno, bill cheswick on stupid net tricks, louis monier on altavista and steve deering on ipv6 will be broadcast. See http://www.usenix.org/ana97/index.html#TECHNICAL for details. -evi evi nemeth computer science dept univ of colorado boulder, colorado From rem-conf-request@es.net Wed Jan 08 08:55:35 1997 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 8 Jan 1997 05:54:51 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.3/8.6.6) with ESMTP id IAA16910 for ; Wed, 8 Jan 1997 08:54:40 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.3/8.6.6) with SMTP id IAA00697 for ; Wed, 8 Jan 1997 08:54:35 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <32D3A71B.7930@cs.columbia.edu> Date: Wed, 08 Jan 1997 08:54:35 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: rem-conf@es.net Subject: Headphone/microphone combinations? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'd like to update my A/V hardware page at http://www.cs.columbia.edu/~hgs/rtp/hardware.html. Any suggestions for, say, good headphone/microphone combinations are appreciated. -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Wed Jan 08 09:18:18 1997 Received: from matilda.wpine.com by osi-west.es.net with ESnet SMTP (PP); Wed, 8 Jan 1997 06:17:13 -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 AAA18181 for ; Wed, 8 Jan 1997 09:15:39 -0500 Received: from boggs.wpine.com.wpine.com by visual.wpine.com (8.6.9/VM-941107.1) id JAA07619; Wed, 8 Jan 1997 09:20:14 -0500 Received: by boggs.wpine.com.wpine.com (4.1/VN941029.1) id AA01417; Wed, 8 Jan 97 09:13:53 EST Message-Id: <9701081413.AA01417@boggs.wpine.com.wpine.com> To: rem-conf@es.net Subject: RTCP Scalability problem. Date: Wed, 08 Jan 1997 09:13:52 -0500 From: Brian O'Shea This is not a solution, only some thoughts about another possible approach to solving the problem. There may be significant holes in the idea, and I invite those more knowledgable then I to point them out, since I can't think of them at the moment. During a sleepless night it occured to me that nobody had proposed using the IP address of the sender of a multicast RTCP message to determine whether they should send one. We could have a scheme whereby the RTCP message is sent only after a random timer expires. If, sometime before that timer expires you receive an RTCP message with a recvfrom address that matches your subnet, then you reset the timer. That way RTCP messages would only be sent from a subnet, not from everyone in the subnet. So, what's wrong with this, and why won't it work? -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 Wed Jan 08 09:53:28 1997 Received: from tis-mail.thepoint.net (actually tis-backup.thepoint.net) by osi-west.es.net with ESnet SMTP (PP); Wed, 8 Jan 1997 06:52:22 -0800 Received: by tis-mail.thepoint.net with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BBFD49.9FF516A0@tis-mail.thepoint.net>; Wed, 8 Jan 1997 09:52:14 -0500 Message-ID: From: Arlie Davis To: "'rem-conf@es.net'" , 'Brian O'Shea' Subject: RE: RTCP Scalability problem. Date: Wed, 8 Jan 1997 09:52:12 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In other words, you wan to make RTCP participants (can't really call them clients) sensitive to nearby neighbors, so that they reduce the frequency of their updates. A good, scalable idea. The problem is, how do you define who is a close neighbor? Your first shot at it, "is peer on the same subnet?" works for one specific scenario -- machines on LANs, watching for peers on the exact same LAN. This will work, and it's a good first step toward _localized_ reduction of RTCP traffic, but it doesn't seem general enough. Here's a scenario that _should_ benefit from localized reduction of RTCP traffic (I'll just call it Localized Back-off or LB to avoid typing all morning): Several machines on different LAN segments very "near" each other. For example, a college campus might have 40 different segments, 15 of which have people watching a popular multicast session. If there are only 2-3 people per segment watching, then each participant backs off a little bit, but not nearly as much as they would if they all realized they were "near" each other. Also, how do you define "subnet" in a meaningful way when you have, say, 256 people dialed into modem- or ISDN-based access servers? The idea of subnet is a rather squishy one when you are dealing with point-to-point links. Here's an idea that might improve the situation a little bit: Include in the RTCP packet the original MTTL. When the packet is received, find the difference between the original TTL (in the RTCP payload) and the actual TTL (in the IP header). The difference is the number of hops that the packet had to traverse. That number is a much more interesting metric of how close a participant is than my-subnet-or-not. You can use that to scale how frequently you multicast your own presence. Has anyone ever considered having an RTP statistics monitor? You could have all of the RTCP participants _unicast_ their reports to the statistics monitor, which would save on bandwidth and on processor time on zillions of machines. The stats monitor could then summarize and periodically multicast the results. How do you decide who runs the statistics monitor? I dunno. Just an idea. You could have the statistics monitor periodically multicast an RTCP datagram that says "I'm the statistics monitor -- send your information to me, instead of the group". RTCP participants could run in "compatability" mode (old way) until they saw a statistics monitor announcing its presence. The RTCP monitor could also support a TCP protocol (to be used infrequently) that could be used to browse the members (past and present) of the multicast session, session statistics, multicast traffic analysis, and so on. It just seems goofy for every single client to talk to every other client all the time. I know there are some good reasons for it, but it seems there are some bad reasons, too. Again, just some ideas. I welcome (intelligent and constructive) criticism. -- arlie >---------- >From: Brian O'Shea[SMTP:boshea@wpine.com] >Sent: Wednesday, January 08, 1997 9:13 AM >To: rem-conf@es.net >Subject: RTCP Scalability problem. > > >This is not a solution, only some thoughts about another possible approach to >solving the problem. There may be significant holes in the idea, and I >invite >those more knowledgable then I to point them out, since I can't think of them >at the moment. > >During a sleepless night it occured to me that nobody had proposed using the >IP address of the sender of a multicast RTCP message to determine whether >they >should send one. > >We could have a scheme whereby the RTCP message is sent only after a random >timer expires. If, sometime before that timer expires you receive an RTCP >message with a recvfrom address that matches your subnet, then you reset the >timer. That way RTCP messages would only be sent from a subnet, not from >everyone in the subnet. > >So, what's wrong with this, and why won't it work? > >-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 Wed Jan 08 10:24:04 1997 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 8 Jan 1997 07:23:08 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.3/8.6.6) with ESMTP id KAA19709; Wed, 8 Jan 1997 10:23:05 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.3/8.6.6) with SMTP id KAA00867; Wed, 8 Jan 1997 10:22:50 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <32D3BBC9.6073@cs.columbia.edu> Date: Wed, 08 Jan 1997 10:22:49 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Brian O'Shea CC: rem-conf@es.net Subject: Re: RTCP Scalability problem. References: <9701081413.AA01417@boggs.wpine.com.wpine.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian O'Shea wrote: > > > We could have a scheme whereby the RTCP message is sent only after a random > timer expires. If, sometime before that timer expires you receive an RTCP > message with a recvfrom address that matches your subnet, then you reset the > timer. That way RTCP messages would only be sent from a subnet, not from > everyone in the subnet. > > So, what's wrong with this, and why won't it work? This was discussed earlier, I believe. However: - Gives inaccurate receiver count. - Fails for small groups where you want to know *all* the people participating, not just the subnet. - Doesn't help much with groups where every subnet has, on average, close to one listener. - The application has to know the definition of "subnet" if the subnet mask is not "classical". Subnet mask information may or may not be readily available to the *application* (obviously, the kernel or equivalent knows it). - A remote monitor can't easily know (because it certainly does not know the subnet mask) as to whether two reports from different SSRCs reflect basically the same QOS conditions (even assuming that all receivers on the subnet indeed share the same QOS, which may be true for yellow-cable Ethernet, but may not be true for more switched environments) - Since the interval between transmissions for a single member will be larger than given by the nominal RTCP interval, stations will time out at the other group members if there are more than just a few in a subnet. Note that there are other mechanisms that alleviate (but don't completely solve) the problem of excessive RTCP traffic during start-up. In steady-state, the rate is not the problem for any group size; you may just never hear from a large part of your audience... The one-report-per-subnet proposal makes somewhat more economical use of the RTCP bandwidth to distribute "interesting" feedback. > > -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. + > +***********************************************************************+ -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Wed Jan 08 12:29:28 1997 Received: from itd.nrl.navy.mil by osi-west.es.net with ESnet SMTP (PP); Wed, 8 Jan 1997 09:28:49 -0800 Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA19823; Wed, 8 Jan 97 12:28:41 EST Message-Id: <9701081728.AA19823@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jan 1997 12:29:26 -0400 To: Henning Schulzrinne , rem-conf@es.net From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: Re: Headphone/microphone combinations? Henning: FYI, for 3-4 years we have had workable results with low rate LPC-10 based network phone applications using, speaker & headset mic combination. Most of our low rate 2400 bps LPC-10 code and vector quantized 1200,800 bps code is quite sensitive to any background noise and microphone reproduction quality. The headset mics we have used on a number of workstations are Audio-Technica ATV-75, ATM-73a and others in that series (profession music, audio outlets carry these in typical ranges from $100-250). Some models have proximity effect compensation. We used these headset mics with most apps (e.g., vat,nevot,rat,ivox) with excellent results. A reasonable compromise for those desiring a speaker/mic combo rather than headphones. These model types are relatively inexpensive for the quality audio produced and IMHO are non-intrusive and comfortable. I assume there are also good wireless versions of these mic types, but I have had the opportunity to try these (i'd love to try these out). Early on we did try quality aviation headsets with a number of workstations, but found them ackward for many casual AVT situations (for extreme noise environments ..helicopters,etc...this is the only sane way to go). -joe _/ _/ _/_/_/_/ _/ Joseph P. Macker, Code 5544 _/_/ _/ _/ _/ _/ Center for High Assurance Computer Systems _/ _/ _/ _/_/_/_/ _/ (202)-767-2001 _/ _/_/ _/ _/ _/ macker@itd.nrl.navy.mil _/ _/ _/ _/ _/_/_/_/ http://tonnant.itd.nrl.navy.mil/macker.html From rem-conf-request@es.net Wed Jan 08 13:53:36 1997 Received: from mail12.digital.com by osi-west.es.net with ESnet SMTP (PP); Wed, 8 Jan 1997 10:52:07 -0800 Received: from ilonet.ilo.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA00956; Wed, 8 Jan 1997 13:41:18 -0500 (EST) Received: by ilonet.ilo.dec.com (5.65/MS-012594); id AA02539; Wed, 8 Jan 1997 18:48:02 GMT Received: from fwsrtr.fws.ilo.dec.com by morse.ilo.dec.com; (5.65/1.1.8.2/22Jan96-8.2MPM) id AA16379; Wed, 8 Jan 1997 18:40:35 GMT Received: by fwsrtr.fws.ilo.dec.com; (5.65v3.2/1.3/10May95) id AA23770; Wed, 8 Jan 1997 18:40:33 GMT From: Dermot Tynan Message-Id: <9701081840.AA11003@karpov.fws.ilo.dec.com> Subject: Re: RTCP Scalability problem. To: arlie@thepoint.net (Arlie Davis) Date: Wed, 8 Jan 1997 18:40:27 +0000 (GMT) Cc: rem-conf@es.net, boshea@wpine.com In-Reply-To: from "Arlie Davis" at Jan 8, 97 09:52:12 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Arlie Davis wrote: > > Has anyone ever considered having an RTP statistics monitor? You could > have all of the RTCP participants _unicast_ their reports to the > statistics monitor, which would save on bandwidth and on processor time > on zillions of machines. I believe this is mentioned in the Aboba paper as a workable method, although I may be a bit confused. He certainly covered a lot of the ins and outs of various schemes. One thing that occurs to me is that in the case of a large multicast, say, for example, some sort of broadcast like a Presidents Address or a lecture or something, what is of interest isn't the names and addresses of the receivers, but just simply the count. The Aboba paper talks in terms of monitoring counts for administrative and business reasons. In this particular case, reception reports are of little interest to the main server, nor are the names of the listeners. Intermediate translators and mixers will want the reception reports, but I can't see the main server doing anything with say, a million RRs. In terms of a large audio conference with several mixers and translators, then any given translator could take the various RRs and NAME types and save them, only releasing basic stats such as the number of listeners. It would retain the NAME information in case one of the listeners transmits data. In which case, it would make sure that the appropriate RTCP packet for that listener was broadcast back up the stream, using the standard algorithm for transmission. RRs would be sent only on behalf of the translator/mixer. Does this seem reasonable? - Der -- Dermot Tynan +353 91 754608 dtynan@ilo.dec.com DTN: 822-4608 AltaVista Internet Software, Galway, Ireland From rem-conf-request@es.net Wed Jan 08 15:58:34 1997 Received: from mail2.digital.com by osi-west.es.net with ESnet SMTP (PP); Wed, 8 Jan 1997 12:57:51 -0800 Received: from bigpink.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA11805; Wed, 8 Jan 1997 12:51:22 -0800 Received: by bigpink.pa.dec.com; id AA17542; Wed, 8 Jan 1997 12:51:21 -0800 Message-Id: <9701082051.AA17542@bigpink.pa.dec.com> To: macker@itd.nrl.navy.mil (Joseph P. Macker) Cc: Henning Schulzrinne , rem-conf@es.net Subject: Re: Headphone/microphone combinations? In-Reply-To: Message of Wed, 8 Jan 1997 12:29:26 -0400 from macker@itd.nrl.navy.mil (Joseph P. Macker) <9701081728.AA19823@itd.nrl.navy.mil> Date: Wed, 08 Jan 97 12:51:21 -0800 From: berc@pa.dec.com X-Mts: smtp Besides Plantronics Mirage headsets (you already have a pointer to Plantronics), I sometimes use a Sony WRT-27A/WRR-27 (957MHz) wireless setup. It works fine in my office and around our floor, but anyone going wireless should try before they buy since local physical can have a large affect on performance and noise. When going wireless I use a Shure ST4300 echo canceller, which helps but doesn't get rid of everything. lance From rem-conf-request@es.net Thu Jan 09 05:21:32 1997 Received: from dxmint.cern.ch by osi-west.es.net with ESnet SMTP (PP); Thu, 9 Jan 1997 02:20:51 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id LAA22985; Thu, 9 Jan 1997 11:20:15 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA23002; Thu, 9 Jan 1997 11:20:13 +0100 Message-Id: <9701091020.AA23002@dxcoms.cern.ch> Subject: MBONE announcement for CERN LHCC meeting To: rem-conf@es.net, hepnet-l@slacvm.slac.stanford.edu, hrc@frcpn11.in2p3.fr, htasc@listbox.cern.ch, net-teleconferencing@listbox.cern.ch Date: Thu, 9 Jan 1997 11:20:13 +0100 (MET) From: Martin Fluckiger - CERN/CN/CS Cc: fle@dxcoms.cern.ch (Martin Fluckiger) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit CERN is pleased to announce the MBONE broadcast of the Large Hadron Collider Committee meeting --------------------------------------- on Thursday 23 January 1997 from the CERN Auditorium Provisional Agenda: ------------------- >>> Times are UTC+2 <<< 9.00 - 9.10 Status of the LHC project (C. Llewellyn Smith) 9.15 - 9.40 ATLAS status report (P. Jenni) 9.45 - 10.35 ATLAS calorimeter Technical Design Report 10.45 - 11.15 COFFEE BREAK 11.15 - 12.05 ATLAS calorimeter Technical Design Report continued 12.15 - 12.30 RD42 status report (P. Weilhammer) 14.00 - 14.50 ATLAS Computing Technical Proposal 15.00 - 15.50 CMS Computing Technical Proposal The broadcast is announced via sdr as "CERN LHCC meeting". vat and vic applications will be used with a ttl of 127. In case of questions or problems please contact . This message is sent to distribution lists, sorry if you receive multiple copies of it. Best regards, -------------------------------------------------------------------- Martin Fluckiger & Christian Isnard CERN - CN/CS/EN multicast@noc.cern.ch European Laboratory for Particle Physics Computers and Networks division CH-1211 Geneva 23 - Switzerland From rem-conf-request@es.net Fri Jan 10 13:41:51 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Fri, 10 Jan 1997 10:41:06 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id KAA06010 for ; Fri, 10 Jan 1997 10:41:15 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma005995; Fri Jan 10 10:40:17 1997 Received: by hille.msri.org (8.7/MSRI) id KAA16515; Fri, 10 Jan 1997 10:38:41 -0800 (PST) Date: Fri, 10 Jan 1997 10:38:41 -0800 (PST) Message-Id: <199701101838.KAA16515@hille.msri.org> To: rem-conf@es.net From: lee Reply-to: lee@math.washington.edu Subject: Pacific Northwest Geometry Seminar MBone Broadcast Announcement ---------------------------- Title: Pacific Northwest Geometry Seminar Date: Jan 10, 1996 Time: 08:00 GMT 2 hours Contact: lee@math.washington.edu URL: http://www.math.washington.edu/~lee/PNGS Description: Quarterly regional meeting for geometers. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Fri Jan 10 13:43:16 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Fri, 10 Jan 1997 10:42:43 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id KAA06083 for ; Fri, 10 Jan 1997 10:42:51 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma006076; Fri Jan 10 10:42:09 1997 Received: by hille.msri.org (8.7/MSRI) id KAA16544; Fri, 10 Jan 1997 10:40:34 -0800 (PST) Date: Fri, 10 Jan 1997 10:40:34 -0800 (PST) Message-Id: <199701101840.KAA16544@hille.msri.org> To: rem-conf@es.net From: lee Reply-to: lee@math.washington.edu Subject: Pacific Northwest Geometry Seminar MBone Broadcast Announcement ---------------------------- Title: Pacific Northwest Geometry Seminar Date: Feb 08, 1997 Time: 09:00 PST8PDT 8 hours Contact: lee@math.washington.edu URL: http://www.math.washington.edu/~lee/PNGS Description: Quarterly regional meeting for geometers. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Fri Jan 10 18:21:40 1997 Received: from proxy2.ba.best.com by osi-west.es.net with ESnet SMTP (PP); Fri, 10 Jan 1997 15:21:02 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy2.ba.best.com (8.8.4/8.8.3) with SMTP id PAA29079 for ; Fri, 10 Jan 1997 15:18:59 -0800 (PST) Date: Fri, 10 Jan 1997 15:18:59 -0800 (PST) Message-Id: <1.5.4.16.19970110160658.5e9f7cc0@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: New multikit ports (SunOS, Solaris) now available SunOS and Solaris/SPARC versions of the "multikit" enhanced multicast session browser are now available. (Thanks to Kalyan Kidambi and Mark Handley for providing guest accounts.) For downloading instructions, please see http://www.lvn.com/multikit/ Ross. From rem-conf-request@es.net Fri Jan 10 18:48:35 1997 Received: from mbone. (actually mbone.conference.usenix.org) by osi-west.es.net with ESnet SMTP (PP); Fri, 10 Jan 1997 15:47:39 -0800 Received: by mbone. (SMI-8.6/SMI-SVR4) id PAA00776; Fri, 10 Jan 1997 15:42:07 -0800 Date: Fri, 10 Jan 1997 15:42:07 -0800 From: mbone@mbone (Mbone) Message-Id: <199701102342.PAA00776@mbone.> To: rem-conf@es.net Subject: last minute reminder -- USENIX closing session mbone event, USENIX closing session: severe tire damage - music and tricks. 16:15 PST (GMT -9 i think). -evi From rem-conf-request@es.net Fri Jan 10 19:01:59 1997 Received: from mail.arc.nasa.gov (actually nick.arc.nasa.gov) by osi-west.es.net with ESnet SMTP (PP); Fri, 10 Jan 1997 16:01:11 -0800 Received: from [128.102.80.28] by mail.arc.nasa.gov (8.7.6/1.35) id PAA06432; Fri, 10 Jan 1997 15:59:24 -0800 (PST) Date: Fri, 10 Jan 1997 15:59:24 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 1 (Highest) To: rem-conf@es.net From: mallard@mail.arc.nasa.gov (Mark Allard) Subject: NASA STS-81 Shuttle MBone Session NASA-Ames Research Center is pleased to provide MBone coverage of the STS-81 Shuttle Mission. This will be the fifth docking between the Space Shuttle and the Russian Space Station MIR, the second mission involving an exchange of US Astronauts. Liftoff is currently anticipated for January 12, 1997 at 4:27AM(EST) with an anticipated mission duration of just over 10 days. There is an updated Shuttle Web Page available at that will carry mission information and links of related interest; the MBone session will carry the link. Contact Mark Allard with any issues pertaining to this broadcast being supplied as a public service to the MBone community by NASA-Ames Research Center. Enjoy, M From rem-conf-request@es.net Mon Jan 13 11:31:24 1997 Received: from snmpmgr.state.tn.us by osi-west.es.net with ESnet SMTP (PP); Mon, 13 Jan 1997 08:30:07 -0800 Received: from langate.tnet.state.tn.us by snmpmgr.state.tn.us with SMTP id AA16036 (5.67b/IDA-1.5 for ); Mon, 13 Jan 1997 10:25:43 -0600 Received: from tn01-Message_Server by langate.tnet.state.tn.us with Novell_GroupWise; Mon, 13 Jan 1997 10:26:29 -0600 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Mon, 13 Jan 1997 10:26:35 -0600 From: Eric Hauch To: rem-conf@es.net Cc: ehauch@mail.state.tn.us Subject: ANSI Standards WG T1A1.5 - Multimedia Communications Coding & Performance Mime-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Greetings to the members of the IETF-AVT Working Group, As chairman of WG T1A1.5, I have had recent discussions with Stephen Casner to explore areas of mutual interest between our groups. Dan Klenke (a recent T1A1.5 vice-chair) attended part of your December meeting in San Jose to gain further insight. Based on Dan's observations at your meeting, it looks very much like there would be benefit to our groups in aligning our activities and supporting each other - some of Dan's thoughts on this follow. I will be continuing a dialogue with Stephen - and will foster a discussion on the activities of your group at our meeting next week in Orlando. I may also be able to attend part of your April meeting in Memphis. In the meantime, both Stephen and I encourage anyone interested to look through the T1 Web Page (www.t1.org). I am also attaching the meeting notice for our upcoming meeting - anyone who is able to attend on such short notice is more than welcome. Please feel free to contact me if you need any further information. Eric Hauch WG T1A1.5 Chair ehauch@mail.state.tn.us 615-532-2365 Dan Klenke's Thoughts As Follows: This message is an introduction to T1A1, an ANSI-accredited telecommunication standards body. It has become clear that the work of T1A1.5 and the IETF (especially the AVT WG) have much in common. We propose the following questions: . How should we work together? . How should we communicate our work results to each other? . Are there opportunities for joint activity? . How can the IETF take advantage of this US channel into the ITU? Following is a high-level description of T1A1, and an invitation to IETF members to attend the upcoming meeting of T1A1 in Orlando, Florida during the week of January 20, 1997. Technical Sub-Committee T1A1 Performance and Signal Processing ========================== Working Groups: T1A1.2 - Network Survivability T1A1.3 - Performance of Digital Networks and Services ** T1A1.5 - Multimedia Communications Coding and Performance T1A1.7 - Signal Processing and Network Performance for Voiceband Services ---------------------------------------------------------- T1A1.5 is (roughly) the equivalent of what was ITU-T Study Group 15, Working Party 1. It has responsibility for the North American versions of the H.3xx set of multimedia terminal definitions. It serves as a "clearing house" for US contributions to SG 15 (now SG 16). T1A1 typically meets four times a year. Attendance and participation is open to all interested parties without charge. Membership in T1A1 is required for voting privleges. For more information about T1 and T1A1, try the T1 Web Site at www.t1.org For more information about the activities of T1A1.5, contact the Working Group Chairman at Eric Hauch (ehauch@mail.state.tn.us) ----------------------------------------------------------- Orlando Meeting Notice Follows: T1A1 ADVANCED MEETING LOCATION ANNOUNCEMENT Orlando, Florida January 20 through 24, 1997 HOSTED BY: ECI Telecom, Inc. and AT&T MEETING PLACE: Sheraton Orlando North Hotel 600 North Lake Destiny Drive Maitland, FL 32751 Phone: (407) 660-9000 or 1~-800/ 628-6660 FAX: (407) 660-9008 CONTACT: Dan Etz-Hadar/Elayna Monts ECI Telecom, Inc. (407) 830~-2544 ACCOMMODATIONS: For reservations, call the Sheraton Orlando North Hotel at the number listed above. A block of rooms has been set aside in the name of T1A1/ECI TELECOM at the rate of $109.00 per night (plus tax). This rate applies for single or double occupancy. The block of rooms will be released by January 5, 1997. After that date, reservations will be accepted on a space available basis only. PLEASE MENTION THE GROUP NAME WHEN MAKING RESERVATIONS TO QUALIFY FOR THE RATE. LOCAL TRANSPORTATION: Public transportation is not convenient in Central Florida. We recommend a rental car. Rates are very competitive. If you prefer, a shuttle service is available from the airport to the hotel and Avis Rental Car has a desk located in the hotel lobby for short or long-term rentals. Transtar provides regularly scheduled shuttle service to the hotel at a cost of $19 one way or $35 round-trip. Cab fare from the airport to the Sheraton North Hotel is approximately $50. DIRECTIONS: Departing the airport, take Semoran Blvd (State Road 436 North). Stay on 436 for six miles, to the East/West Expressway. Go west on the Expressway five miles to I-4, then seven miles to Maitland Blvd, West (Exit 47B). The hotel is located on Lake Destiny Drive (First right off of Maitland Blvd, West). MAILING INSTRUCTIONS: Documents should be shipped to hotel no earlier than 3 days in advance. No charge for receipt of boxes. The mailing address should read as follows: Sheraton Orlando North Hotel & Towers 600 North Lake Destiny Drive Maitland, FL 32751 ATTEN: (RECIPIENT'S NAME) GUEST T1A1 /ECI Telecom Inc. c/o Convention Services WEATHER: Florida in January cool, jacket weather. Temperatures range from 40 to 70 degrees. ################################################## NEXT T1A1 MEETING Jan 20 - 24, 1997 SCHEDULE FOR THE WEEK TIME KEY (except Plenary) AM = 8:30 a.m. to noon PM = 1:30 to 5:00 p.m. ACTIVITY Meeting Days & Times ---------------------- ---------------------- T1A1.2 Working Group: Mon AM thru Tue PM (Network Survivability) Editing Group: Wed AM thru Thurs PM T1A1.3 Working Group: Mon PM thru Thurs PM (Perf. of Dig. Serv. & Netw.) T1A1.5 Working Group: Tue AM thru Thurs PM (Multimedia Comm. & Coding) T1A1.7 Working Group: Weds AM thru Thurs PM (Sig. Proc.+Netw. Perf. VB Serv.) ATM Editing Mtg: Tues AM Access Model Tues PM T1A1 Plenary Friday 8:00 a.m. From rem-conf-request@es.net Mon Jan 13 14:40:10 1997 Received: from cs.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 13 Jan 1997 11:39:26 -0800 Received: from erlang.cs.columbia.edu (erlang.cs.columbia.edu [128.59.27.35]) by cs.columbia.edu (8.8.3/8.6.6) with ESMTP id OAA07375 for ; Mon, 13 Jan 1997 14:39:22 -0500 (EST) Received: from erlang.cs.columbia.edu (localhost [127.0.0.1]) by erlang.cs.columbia.edu (8.8.3/8.6.6) with SMTP id OAA11963 for ; Mon, 13 Jan 1997 14:39:09 -0500 (EST) Sender: hgs@cs.columbia.edu Message-ID: <32DA8F5C.934@cs.columbia.edu> Date: Mon, 13 Jan 1997 14:39:08 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: rem-conf@es.net Subject: Packet audio patent Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There was some discussion a while back on a recent packet audio patent. This patent is now available on-line for inspection. http://patent.womplex.ibm.com/details?patent_number=5526353 -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs From rem-conf-request@es.net Mon Jan 13 15:33:24 1997 Received: from cyclops.ece.ncsu.edu by osi-east.es.net with ESnet SMTP (PP); Mon, 13 Jan 1997 12:32:51 -0800 Received: (from klhewitt@localhost) by cyclops.ece.ncsu.edu (8.8.4/EC02Jan97) id PAA27495 for rem-conf@es.net; Mon, 13 Jan 1997 15:32:48 -0500 (EST) From: Kathy Lynn Hewitt Message-Id: <9701131532.ZM27493@eos.ncsu.edu> Date: Mon, 13 Jan 1997 15:32:44 -0500 X-Mailer: Z-Mail (3.2.1 10oct95) To: rem-conf@es.net Subject: Importing Powerpoint 7.0 slides into wb Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi! I'm trying to import Powerpoint 7.0 slides into wb by converting them to ps. But I can't seem to convert it into proper format. I've tried using distill from Adobe. I've tried different ps print drivers like Digital LN0R3 and then setting the postscript option to optimize for portabiltiy. But nothing seems to work. I'm trying to get this by 7pm tonight so any help would be greatly appreciated. Thank you!! --Kathy Hewitt -- ------------------------------------------------- Kathy Hewitt Dept. of Electrical and Computer Engineering North Carolina State University 919-515-5604 ------------------------------------------------- From rem-conf-request@es.net Mon Jan 13 18:32:13 1997 Received: from itd.nrl.navy.mil by osi-west.es.net with ESnet SMTP (PP); Mon, 13 Jan 1997 15:31:39 -0800 Received: from [132.250.92.68] (gumbo.itd.nrl.navy.mil) by itd.nrl.navy.mil (4.1/SMI-4.1) id AA21461; Mon, 13 Jan 97 18:31:36 EST Message-Id: <9701132331.AA21461@itd.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Jan 1997 18:32:30 -0400 To: Kathy Lynn Hewitt , rem-conf@es.net From: macker@itd.nrl.navy.mil (Joseph P. Macker) Subject: Re: Importing Powerpoint 7.0 slides into wb At 3:32 PM 1/13/97 -0500, Kathy Lynn Hewitt wrote: >Hi! I'm trying to import Powerpoint 7.0 slides into wb by converting them to >ps. But I can't seem to convert it into proper format. I've tried using >distill from Adobe. I've tried different ps print drivers like Digital LN0R3 >and then setting the postscript option to optimize for portabiltiy. But >nothing seems to work. Kathy: There used to be a limit on the size of imported ps in wb (~32K per page). This might make things a little tight with "busy", converted Powerpoint slides. Just thought this might be what you are running into at present. -joe From rem-conf-request@es.net Mon Jan 13 20:01:47 1997 Received: from buttle.lcs.mit.edu. (actually buttle.lcs.mit.edu) by osi-west.es.net with ESnet SMTP (PP); Mon, 13 Jan 1997 17:01:13 -0800 Received: from buttle.lcs.mit.edu by buttle.lcs.mit.edu. (SMI-8.6/SMI-SVR4) id UAA19633; Mon, 13 Jan 1997 20:00:20 -0500 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Henning Schulzrinne cc: rem-conf@es.net Subject: Re: Headphone/microphone combinations? In-reply-to: Your message of "Wed, 08 Jan 1997 08:54:35 EST." <32D3A71B.7930@cs.columbia.edu> Date: Mon, 13 Jan 1997 20:00:20 -0500 Message-ID: <19631.853203620@buttle.lcs.mit.edu> Sender: mjh@buttle.lcs.mit.edu >I'd like to update my A/V hardware page at >http://www.cs.columbia.edu/~hgs/rtp/hardware.html. Any suggestions for, >say, good headphone/microphone combinations are appreciated. Having never been very satisfied with any of the headsets I've tried (and we had a pretty good selection at UCL), I finally resorted to building my own. My requirements were to have headphones that go over my ears rather than press on them because this puts the drivers a little further from my ears meaning load sounds hurt less (and MBone sessions often have loud sounds) and because I find them more comfortable for wearing for long periods of time. I spent some time wandering around audio shops till I found a set of headphones that were suitably comfortable without really caring too much about the quality because, lets face it, good high frequency response is actually a liability with workstations - the high frequency hiss from SparcStations on walkman type headsets always annoys me. What I got were a pair of $30 Aiwa headphones - I was prepared to spend a lot more, but these were more comfortable. I also got a tiny ( < 10mm) $2 condenser microphone from Radio Shack, assorted cables and plugs, a 10uF capacitor and a wire coathanger. Assorted soldering, bending of coathanger and insulating tape later I now have the headset I wanted. The SparcStation supplies the 5V bias voltage for the mike just perfectly. This is on an SS20 - don't know how universal it is, but I think SS10s and SS5s are the same. +------+ +---+ | |-------------- bias (+5V) ---------------------| | | | \ / | mike | || +===+ | |------||--------- output ----------------------| | 3.5mm plug | | || 10 uF |===| | | | | | |---------------- ground -----------------------| | +------+ | | +=======+ | | I have to admit I was surprised that the bias and the output were the opposite way round from what I expected. You need a good breathshield over the mike when it's only 2-3cm from your mouth, but Radio Shack sell those too. Anyway, this setup works pretty well. Total cost: about $40. See http://buttle.lcs.mit.edu/~mjh/headphones.gif for a not terribly good GIF. Mark From rem-conf-request@es.net Mon Jan 13 23:54:29 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 13 Jan 1997 20:53:55 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id UAA02140; Mon, 13 Jan 1997 20:32:33 -0800 Date: Mon, 13 Jan 1997 20:33:51 -0800 () From: Stephen Casner To: Henning Schulzrinne cc: rem-conf@es.net Subject: Re: Packet audio patent In-Reply-To: <32DA8F5C.934@cs.columbia.edu> Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 13 Jan 1997, Henning Schulzrinne wrote: > There was some discussion a while back on a recent packet audio patent. > This patent is now available on-line for inspection. > > http://patent.womplex.ibm.com/details?patent_number=5526353 See also patent 4,100,377, "Packet transmission of speech", from 1978, and 4,748,620, "Time stamp and packet virtual sequence numbering for reconstructing information signals from packets", from 1988. And probably others... -- Steve From rem-conf-request@es.net Tue Jan 14 13:02:48 1997 Received: from proxy3.ba.best.com by osi-west.es.net with ESnet SMTP (PP); Tue, 14 Jan 1997 10:02:18 -0800 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy3.ba.best.com (8.8.4/8.8.3) with ESMTP id JAA29626; Tue, 14 Jan 1997 09:51:20 -0800 (PST) Received: from prince.vip.best.com (prince.vip.best.com [204.156.152.199]) by shellx.best.com (8.8.4/8.8.3) with SMTP id JAA23798; Tue, 14 Jan 1997 09:48:08 -0800 (PST) Message-ID: <32DB983D.4BF9@mbone.com> Date: Tue, 14 Jan 1997 10:29:17 -0400 From: Vinay Kumar Organization: ICAST Communications, Inc. X-Mailer: Mozilla 2.02 (Win16; I) MIME-Version: 1.0 To: mbone@isi.edu CC: rem-conf@es.net Subject: mbone website update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit the mbone website at http://www.mbone.com/ now maintains html hyperlinked archives of the 'rem-conf' and 'mbone' mailing lists. The archives are also indexed and keyword searchable. please feel free to send suggestions, feedback, bug reports. also, parts of the site are either slow or under construction/update, so please bear with me on that one. this will be fixed real soon now. happiness. --- vinay kumar vinay@mbone.com http://www.mbone.com/ From rem-conf-request@es.net Tue Jan 14 13:32:58 1997 Received: from mgate.uni-hannover.de by osi-west.es.net with ESnet SMTP (PP); Tue, 14 Jan 1997 10:32:13 -0800 Received: from helios (actually helios.tnt.uni-hannover.de) by mgate with SMTP (PP); Tue, 14 Jan 1997 19:31:55 +0100 Received: from ikarus.tnt.uni-hannover.de by helios (SMI-8.6/SMI-SVR4) id TAA05205; Tue, 14 Jan 1997 19:31:17 +0100 Received: from ikarus (localhost) by ikarus.tnt.uni-hannover.de (4.1/SMI-4.1) id AA05696; Tue, 14 Jan 97 19:31:17 +0100 Sender: mech@tnt.uni-hannover.de Message-Id: <32DBD0F4.FF6D5DF@tnt.uni-hannover.de> Date: Tue, 14 Jan 1997 19:31:16 +0100 From: Roland Mech Organization: Universitaet Hannover, Theoretische Nachrichtentechnik X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3 sun4m) Mime-Version: 1.0 To: rem-conf@es.net Subject: running wb on Windows95 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I am trying to run the whiteboard-tool wb on a PC using Windows 95, and I have the problem that Windows gives the error message "No 32 Bit application!" I downloaded the wb-tool from ftp.ee.lbl.gov/conferencing/wb/i386-wb-1.59. Many thanks in advance for helpful answers. Roland ________________________________________________________________________________ Dipl.-Inform. Roland Mech Universitaet Hannover Institut fuer Theoretische Nachrichtentechnik und Informationsverarbeitung phone: +49-511-762-5308 Appelstrasse 9A fax: +49-511-762-5333 30167 Hannover, Germany email: mech@tnt.uni-hannover.de www: http://www.tnt.uni-hannover.de/wiss/mech.html ________________________________________________________________________________ From rem-conf-request@es.net Tue Jan 14 14:31:24 1997 Received: from hplms26.hpl.hp.com by osi-west.es.net with ESnet SMTP (PP); Tue, 14 Jan 1997 11:30:41 -0800 Received: from hplabsz.hpl.hp.com by hplms26.hpl.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA051620237; Tue, 14 Jan 1997 11:30:38 -0800 Received: by hplabsz.hpl.hp.com (1.37.109.20/15.5+ECS 3.3+HPL1.1) id AA069910238; Tue, 14 Jan 1997 11:30:38 -0800 From: deleon@hplabsz.hpl.hp.com (Laura de Leon) Message-Id: <9701141130.ZM6989@hplabsz.hpl.hp.com> Date: Tue, 14 Jan 1997 11:30:38 -0800 X-Mailer: Z-Mail (3.0.0 15dec93) To: sage-members@usenix.org, baylisa@baylisa.org, rem-conf@es.net Subject: BayLISA: Brent Chapman on Containment Zones Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 The BayLISA group meets monthly to discuss topics of interest to systems and network administrators. The meetings are free and open to the public. BayLISA holds monthly meetings on the third Thursday of each month at 7:30 PM PST. We meet at Cisco building J in San Jose, on Tasman Drive near First street. (This is across the street from the room we met in at Cisco in November). See www.baylisa.org for more information. The meetings are also broadcast via MBONE. Schedule -------- January 16 Containment Fields: An Intranet Application of Internet Firewalls Technology Brent Chapman Great Circle Associates, Inc. Brent@GreatCircle.COM +1 415 962 0841 or 800/270-2562 Many organizations require different security models for different parts of their networks; for instance, they may have classrooms and demonstration facilities which customers are allowed access to, as well as internal development networks where outsiders are strictly prohibited. Containment fields are a way of using standard Internet firewall technologies (packet filters and IP tunnels) to establish and link pieces of a network that have special security requirements without compromising the security of the larger network they are a part of. The containment field concept was developed as part of the SGI/Cray merger, in order to reconcile the significantly different security models of those two organizations as they merged their existing wide area networks. This talk will describe containment fields in the context of the SGI/Cray merger, including why and how we developed them, what we expect to do with them, and how we plan to build them. February 20 Nick Stoughton Standards efforts and how they will effect you March 20 Paul Vixie [Schedule subject to change] For further information on BayLISA, check out our web site: http://www.baylisa.org/ To get further information on the meeting location, you can also ftp it from ftp.baylisa.org:/location For any other information, please send email to: info@baylisa.org If you have any questions, please contact me or the info alias listed above. From rem-conf-request@es.net Tue Jan 14 23:39:57 1997 Received: from mail.gmd.de by osi-west.es.net with ESnet SMTP (PP); Tue, 14 Jan 1997 20:39:26 -0800 Received: by mail.gmd.de id AA20841 (5.67b8/IDA-1.5 for rem-conf@es.net); Wed, 15 Jan 1997 05:39:22 +0100 Date: Wed, 15 Jan 1997 05:39:22 +0100 From: Hans Mayer Message-Id: <199701150439.AA20841@mail.gmd.de> To: mech@tnt.uni-hannover.de, rem-conf@es.net Subject: Re: running wb on Windows95 >I downloaded the wb-tool from > ftp.ee.lbl.gov/conferencing/wb/i386-wb-1.59. I'm not shure this executable is a W'95 one. As far as I know wb is Interviews based and this is so X'centric I would guess it's impossible to port to any- thing else. Hans From rem-conf-request@es.net Wed Jan 15 03:58:21 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 15 Jan 1997 00:57:47 -0800 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 15 Jan 1997 08:26:22 +0000 To: Hans Mayer cc: mech@tnt.uni-hannover.de, rem-conf@es.net Subject: Re: running wb on Windows95 In-reply-to: Your message of "Wed, 15 Jan 1997 05:39:22 +0100." <199701150439.AA20841@mail.gmd.de> Date: Wed, 15 Jan 1997 08:26:20 +0000 Message-ID: <660.853316780@cs.ucl.ac.uk> From: Jon Crowcroft >>I downloaded the wb-tool from >> ftp.ee.lbl.gov/conferencing/wb/i386-wb-1.59. >I'm not shure this executable is a W'95 one. As far as I know wb is Interviews >based and this is so X'centric I would guess it's impossible to port to any- >thing else. right the best freebie shared media tool for windows right now is probasbly mark handley's nte (network text editor) from a MICE FTP site near you.... jon From rem-conf-request@es.net Wed Jan 15 17:02:30 1997 Received: from mail1.digital.com by osi-west.es.net with ESnet SMTP (PP); Wed, 15 Jan 1997 14:02:01 -0800 Received: from bigpink.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA11135; Wed, 15 Jan 1997 13:55:43 -0800 Received: by bigpink.pa.dec.com; id AA21792; Wed, 15 Jan 1997 13:55:42 -0800 Message-Id: <9701152155.AA21792@bigpink.pa.dec.com> To: rem-conf@es.net Cc: band@srd.com Subject: The Triumph of Severe Tire Damage Date: Wed, 15 Jan 97 13:55:41 -0800 From: berc@pa.dec.com X-Mts: smtp If you weren't at Usenix, this is your chance to experience the 8KHz monaural audio splendor of Severe Tire Damage accompanied by a blazing 128Kb of H.261 video. What: Severe Tire Damage When: January 15th, 8pm PST From: The Fabulous SubForum, in Palo Alto California Why: Because rock & roll will keep South Korea free Remote camera control will be present, and maybe the remote mixer. We're still working on the software for the remote fog machine. lance From rem-conf-request@es.net Thu Jan 16 09:21:52 1997 Received: from orion.lrg.ufsc.br by osi-west.es.net with ESnet SMTP (PP); Thu, 16 Jan 1997 06:21:18 -0800 Received: (from westphal@localhost) by orion.lrg.ufsc.br (8.6.8.1/8.6.6) id LAA23550; Thu, 16 Jan 1997 11:53:03 -0200 Date: Thu, 16 Jan 1997 11:53:03 -0200 From: Carlos Becker Westphall Message-Id: <199701161353.LAA23550@orion.lrg.ufsc.br> To: sarikaya@u-aizu.ac.jp, cellular@dfv.rwth-aachen.de, perform@tay1.dec.com, tccc@cs.umass.edu, ghafoor@ecn.purdue.edu Subject: Please distribute widely Cc: announcements.chi@xerox.com, arl@arl.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 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: Vy9AUIPdCSU3/rJ8KFg1JQ== >From sarikaya@u-aizu.ac.jp Wed Jan 8 05:36 EDT 1997 Date: Wed, 08 Jan 1997 16:24:37 +0900 From: Behcet Sarikaya Subject: Please distribute widely PRELIMINARY CALL FOR PAPERS - PROMSMmNet'97 International Conference on Protocols for Multimedia Systems - Multimedia Networking Santiago, Chile, November 24-26, 1997 IMPORTANT DATES: Deadline for Receipt of Papers June 2, 1997 Notification of Acceptance Mailed July 14, 1997 Final Camera Ready Papers Due to IEEE CS Press September 4, 1997 Please visit our Web page for submission information: http://cc-lab.u-aizu.ac.jp/promsmmnet97/ From rem-conf-request@es.net Thu Jan 16 19:00:14 1997 Received: from cbgw1.lucent.com by osi-west.es.net with ESnet SMTP (PP); Thu, 16 Jan 1997 15:59:44 -0800 To: IP@hoserve.ho.lucent.com, Mobile@hoserve.ho.lucent.com, list@hoserve.ho.lucent.com, rem-conf@es.net Received: from hoserve.ho.lucent.com by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id SAA24116; Thu, 16 Jan 1997 18:52:42 -0500 Received: by hoserve.ho.lucent.com (4.1/EMS-L SunOS) id AA21938; Thu, 16 Jan 97 19:01:09 EST From: rameshn@lucent.com Original-To: IP@hoserve.ho.lucent.com, Mobile@hoserve.ho.lucent.com, list@hoserve.ho.lucent.com, rem-conf@es.net Received: from hopaw33 (hopaw33.ho.lucent.com) by hoserve.ho.lucent.com (4.1/EMS-L SunOS) id AA21853; Thu, 16 Jan 97 18:59:45 EST Received: by hopaw33 (4.1/EMS-L SunOS) id AA05020; Thu, 16 Jan 97 19:00:02 EST Date: Thu, 16 Jan 97 19:00:02 EST Original-From: ramesh@hoserve.ho.lucent.com Message-Id: <9701170000.AA05020@hopaw33> Original-To: IP@hoserve.ho.lucent.com, Mobile@hoserve.ho.lucent.com, list@hoserve.ho.lucent.com, rem-conf@es.net Subject: INFOCOM'98 - Preliminary Call for Papers ------------------------------------------------------------------ | SEVENTEENTH IEEE INTERNATIONAL CONFERENCE | | ON | | COMPUTER COMMUNICATIONS | | | | INFOCOM'98 - Gateway to the 21st Century | | March 29 - April 2, 1998 | | Hotel Nikko, San Francisco, USA | | | | Sponsored by: | | | | Computer Communications Technical Committees of the | | IEEE Computer and Communications Societies | | | ------------------------------------------------------------------ CALL FOR PAPERS: Authors are invited to submit full papers reporting results, strongly substantiated by mathematical analysis, experiment, implementation, or simulation, in all areas of computer communications and networks; however, more qualitative exploration of important architectural issues is also encouraged. A more detailed list of specific areas of interest can be obtained from the INFOCOM'98 WWW site. SCHEDULE AND IMPORTANT DATES: Full Paper Due - July 15, 1997 Notification of Acceptance - October 31, 1997 Camera Ready Version of Accepted Paper Due - January 5, 1998 Conference - March 31-April 2, 1998 Tutorials - March 29-30, 1998 SUBMISSION INSTRUCTIONS: The first page of your paper should contain paper title, author name(s), complete address (telephone, fax, email) for all authors, indication of who is the corresponding author, abstract, followed by key words and optionally one or more areas of interest from the list on the WWW site. The paper should be limited to 20 pages excluding illustrations and 30 pages overall. We strongly encourage electronic submission of manuscripts in Postscript format. Please consult the INFOCOM '98 WWW site for electronic submission instructions. Hard copy submissions will still be handled on an exception basis, but require explicit permission from the Infocom'98 Technical Program Chair who can be reached at: Professor Ian Akyildiz Technical Program Chair, IEEE INFOCOM '98 School of ECE Georgia Tech, Atlanta, Georgia 30332. (email) infocom98@ee.gatech.edu (phone) +1 404-894-5141 (fax) +1 404-894-0035 STUDENT GRANTS: You may qualify for a Student Travel Grant to defray some of your costs for presenting a paper at this conference. IEEE Communications Society will award a limited number of Student Travel Grants to full-time students who represent their accepted papers at INFOCOM '98. Please refer to the INFOCOM'98 WWW site for further details. WORLD-WIDE WEB: Information on Infocom'98 is available through the World Wide Web at USA: http://www.comsoc.org/~infocom98 Europe: http://www.cs.ucl.ac.uk/research/infocom98 Asia/Pacific: http://www.iss.nus.sg/INFOCOM +------------------------------------------------------------------+ INFOCOM'98 EXECUTIVE COMMITTEE: GENERAL CHAIR VICE GENERAL CHAIR Roch Guerin Henning Schulzrinne IBM T.J. Watson Research Center Columbia Univ. Yorktown Heights, NY, USA. New York, NY, USA. TECHNICAL CHAIR Ian Akyildiz Georgia Institute of Technology Atlanta, Georgia, USA. PUBLICITY CHAIR PUBLICATIONS CHAIR Ramesh Nagarajan, Bell labs, USA. Abhijit Choudhury, Bell labs, USA. TUTORIAL CO-CHAIRS PANELS CO-CHAIRS Arvind Krishna, IBM, USA. David Tipper, Univ. of Pittsburgh, USA. Catherine Rosenberg, Nortel, UK. Vittorio Trecordi, CEFRIEL, Italy. LOCAL ARRANGEMENTS CHAIR FINANCIAL CO-CHAIRS Fred Bauer, SRI, USA. Ariel Orda, Technion, Israel. Ioannis Korilis, Bell labs, USA. INFOCOM STANDING COMMITTEE CHAIR: Harvey Freeman, LANWORKS, Inc., U.S.A. +----------------------------------------------------------------+ From rem-conf-request@es.net Fri Jan 17 13:19:31 1997 Received: from dfw-ix2.ix.netcom.com by osi-west.es.net with ESnet SMTP (PP); Fri, 17 Jan 1997 10:18:43 -0800 Received: from srf-ca9-40.ix.netcom.com (srf-ca9-40.ix.netcom.com [205.186.119.104]) by dfw-ix2.ix.netcom.com (8.6.13/8.6.12) with SMTP id KAA01951; Fri, 17 Jan 1997 10:18:30 -0800 Date: Fri, 17 Jan 1997 10:18:30 -0800 From: hermenh@ix.netcom.com To: rem-conf@es.net To: videophone@es.net To: CU-SeeMe-L@cornell.edu To: mbone@isi.edu Message-Id: <1997117101858641@ix.netcom.com> Subject: earn $75 X-Mailer: NETCOMplete v3.20, from NETCOM On-Line Communications, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hello, As an independent researcher I will be conducting one-on-one, face-to-face interviews with people that use desktop videoconferencing systems for personal purposes. The interviews will be conducted either in San Jose, CA or in Sacramento, CA. If you have a videoconferenicing system in your home, and if you are willing to be interviewed for approximately 20 minutes (I can pay you a $75 cash incentive for your time) please contact me and tell me: 1) what system you use 2) which of the above mentioned cities is more convenient for you to come to. Hermen From rem-conf-request@es.net Fri Jan 17 13:55:44 1997 Received: from natsemi-bh.nsc.com by osi-west.es.net with ESnet SMTP (PP); Fri, 17 Jan 1997 10:54:55 -0800 Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id KAA21390; Fri, 17 Jan 1997 10:55:52 -0800 Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3) id sma020817; Fri Jan 17 10:55:11 1997 Received: from lan170.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA01661 for rem-conf@es.net; Fri, 17 Jan 97 10:54:06 -0800 Received: from dawg.nsc.com by lan.nsc.com (4.1/SMI-4.1) id AA14871; Fri, 17 Jan 97 10:54:03 PST Date: Fri, 17 Jan 97 10:54:03 PST From: deby@lan.nsc.com (Deby Worsley) Message-Id: <9701171854.AA14871@lan.nsc.com> To: rem-conf@es.net, videophone@es.net, CU-SeeMe-L@cornell.edu, mbone@isi.edu, hermenh@ix.netcom.com Subject: Re: earn $75 Please provide your contact details on this. > From videophone-request@es.net Fri Jan 17 10:43:01 1997 > To: rem-conf@es.net > To: videophone@es.net > To: CU-SeeMe-L@cornell.edu > To: mbone@isi.edu > Subject: earn $75 > X-Mailer: NETCOMplete v3.20, from NETCOM On-Line Communications, Inc. > Mime-Version: 1.0 > Content-Type> : > text/plain> ; > charset=us-ascii> > Content-Length: 569 > X-Lines: 10 > > Hello, > > As an independent researcher I will be conducting one-on-one, face-to-face interviews with people that use desktop videoconferencing systems for personal purposes. The interviews will be conducted either in San Jose, CA or in Sacramento, CA. > > If you have a videoconferenicing system in your home, and if you are willing to be interviewed for approximately 20 minutes (I can pay you a $75 cash incentive for your time) please contact me and tell me: > 1) what system you use > 2) which of the above mentioned cities is more convenient for you to come to. > > Hermen > > From rem-conf-request@es.net Sun Jan 19 13:44:04 1997 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Sun, 19 Jan 1997 10:43:34 -0800 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <10389-0@ceres.fokus.gmd.de>; Sun, 19 Jan 1997 19:41:57 +0100 X-Mailer: exmh version 1.6.1 5/23/95 To: rem-conf@es.net Cc: Subject: Some comments on current SDP usage Mime-Version: 1.0 Content-Type: text/plain Date: Sun, 19 Jan 1997 19:41:57 +0000 From: Christian Zahl Sender: zahl@fokus.gmd.de Hello, I'm currently working the interpretation of SDP announcements currently send on the mbone. It seems that currently many tools generate SDP packets, which does NOT conform to the (still ID) specifiaction! It seems that also sdr v2.3a1 violates this spec. The major problem is the order of the various attribute lines. E.g. the order of the email (e=) and phone (p=) attributes is often wrong. Is there any chance that this will be changed in the near future? One aim of the SDP spec (to my understanding) was to allow to write a simple parser and to give some hints on corrupt packets (from the ID: "... but all must appear in exactly the order given here (the fixed order greately enhances error detection and allows for a simple parser).") I'm currently trying to compress the SDP packets, and for doing so I rely on the strict order. So for the moment it seems to be necessary to reoder the fields prior to compression... :-( Any comments are welcome, Chris From rem-conf-request@es.net Sun Jan 19 13:53:50 1997 Received: from basil.cdt.luth.se by osi-west.es.net with ESnet SMTP (PP); Sun, 19 Jan 1997 10:53:11 -0800 Received: from salt.cdt.luth.se (salt.cdt.luth.se [130.240.193.242]) by basil.cdt.luth.se (8.7.5/8.7.3) with ESMTP id TAA03954; Sun, 19 Jan 1997 19:48:21 +0100 (MET) Received: from salt (localhost [127.0.0.1]) by salt.cdt.luth.se (8.6.12/8.6.12) with ESMTP id TAA08743; Sun, 19 Jan 1997 19:52:45 +0100 Message-Id: <199701191852.TAA08743@salt.cdt.luth.se> X-Mailer: exmh version 2.0beta 12/23/96 To: Christian Zahl cc: rem-conf@es.net Subject: Re: Some comments on current SDP usage In-reply-to: Your message of "Sun, 19 Jan 1997 19:41:57 GMT." <199701191849.AA00884@goliat.dc.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Jan 1997 19:52:45 +0100 From: Peter Parnes Where does the specs say that fields must be in any strict order? /P From rem-conf-request@es.net Mon Jan 20 02:52:36 1997 Received: from proxy3.ba.best.com by osi-west.es.net with ESnet SMTP (PP); Sun, 19 Jan 1997 23:51:34 -0800 Received: from mg128-236.ricochet.net (mg128-236.ricochet.net [204.179.128.236]) by proxy3.ba.best.com (8.8.4/8.8.3) with SMTP id RAA14018; Sun, 19 Jan 1997 17:21:15 -0800 (PST) Date: Sun, 19 Jan 1997 17:21:15 -0800 (PST) Message-Id: <1.5.4.16.19970119180851.088fc3ec@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: Christian Zahl From: Ross Finlayson Subject: Re: Some comments on current SDP usage Cc: rem-conf@es.net As I have commented to Mark (Handley) on more than one occasion, I just don't believe the claim that requiring the various "=" tags in SDP to appear in a fixed order "allows for a simpler parser". If you allow the tags to appear in any order, then your parser can simply be a "switch" statement inside of a "while" loop. (Then, having completed the parsing, you then check that all of the manditory tags are present.) I defy anyone to come up with a simpler parser that assumes that the tags appear in a fixed order, while still allowing for the fact that some of them are optional. In any case, it's generally a good idea for SDP receivers to follow the "be liberal in what you accept" philosophy, and accept SDP descriptions that make sense, even if their "=" tags don't appear in the exact prescribed order. multikit's SDP parser does this, and I assume that many SDP receivers do as well. With this in mind, the SDP spec should not be so restrictive. While there are good reasons for requiring the "v=" (version) tag to be first, and perhaps for requiring that all of the 'session-global' tags appear before the 'media-specific' tags, there seems no reason for the spec to be so anal-retentive about the order of these tags. Ross. From rem-conf-request@es.net Mon Jan 20 03:03:47 1997 Received: from rumms.uni-mannheim.de by osi-west.es.net with ESnet SMTP (PP); Mon, 20 Jan 1997 00:03:13 -0800 Received: from eratosthenes.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA00592 (5.67a/IDA-1.5 for ); Mon, 20 Jan 1997 09:03:09 +0100 Received: from localhost (stein@localhost) by eratosthenes.informatik.uni-mannheim.de (8.8.2/8.8.2) with SMTP id JAA17101 for ; Mon, 20 Jan 1997 09:02:34 +0100 (MET) X-Authentication-Warning: eratosthenes.informatik.uni-mannheim.de: stein owned process doing -bs Date: Mon, 20 Jan 1997 09:02:34 +0100 (MET) From: Achim Steinacker X-Sender: stein@eratosthenes To: rem-conf@es.net Subject: Re: Some comments on current SDP usage In-Reply-To: <199701191852.TAA08743@salt.cdt.luth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 19 Jan 1997, Peter Parnes wrote: > Where does the specs say that fields must be in any strict order? > > /P SDP draft 03.2 Page 5: ".. Some lines in each description are required and some are optional but all must appear in exactly the order given here...." Sdr violates not only the order of the 'e'- and 'p'-fields. It also doesn't include a 'c'-field in each session-description if there is one in each media-description, although it is not marked optional in the spec. From rem-conf-request@es.net Mon Jan 20 14:15:07 1997 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Mon, 20 Jan 1997 11:14:34 -0800 Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.8.4/8.8.4) with SMTP id LAA07077 for ; Mon, 20 Jan 1997 11:14:21 -0800 (PST) Received: from quasar by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0vmPDD-000S8vC; Mon, 20 Jan 97 11:16 PST Message-Id: <1.5.4.32.19970120191426.00906ae0@ibeam.intel.com> X-Sender: czhu@ibeam.intel.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_853816466==_" Date: Mon, 20 Jan 1997 11:14:26 -0800 To: rem-conf@es.net From: Chunrong Chad Zhu Subject: revison of RTP payload format for H.263 Cc: czhu@ibeam.jf.intel.com X-Attachments: D:\doc\ietf\rtp\rtp263id.txt; --=====================_853816466==_ Content-Type: text/plain; charset="us-ascii" Hi all, Attached please find the revision of "RTP Payload Format for H.263 Video Streams". This revision reflected feedback from last meeting in San Jose. I removed the version field in RTP H.263 header added in the previous version. If you any comments or questions, please send it to this mailing list or to czhu@ibeam.intel.com. --Chad --=====================_853816466==_ Content-Type: text/plain; charset="us-ascii" Internet Engineering Task Force Audio-Video Transport WG INTERNET-DRAFT C. Zhu Intel Corp. January 10, 1997 Expires: July 10, 1997 RTP Payload Format for H.263 Video Streams Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document 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. Zhu [Page 1] Internet Draft draft-ietf-avt-payload-03.txt January 10, 1997 1. Introduction This document describes a scheme to packetize an H.263 video stream for transport using RTP [1]. H.263 video stream is defined by ITU-T Recommendation H.263 (referred to as H.263 in this document) [4] for video coding at very low bit rate. RTP is defined by the Internet Engineering Task Force (IETF) to provide end-to-end network transport functions suitable for applications transmitting real-time data over multicast or unicast network services. The complete specification of RTP for a particular application will require a profile specification document [3], a payload format specification, and an RTP protocol document [1]. This document is intended to serve as the payload format specification for H.263 video streams. 2. Definitions For the purpose of this document, the following definitions apply: CIF: Common Intermediate Format. For H.263, a CIF picture has 352 x 288 pixels for luminance, and 176 x 144 pixels for chrominance. QCIF: Quarter CIF source format with 176 x 144 pixels for luminance and 88 x 72 pixels for chrominance. sub-QCIF: picture source format with 128 x 96 pixels for luminance and 64 x 48 pixels for chrominance. 4CIF: picture source format with 704 x 576 pixels for luminance and 352 x 288 pixels for chrominance. 16CIF: picture source format with 1408 x 1152 pixels for luminance and 704 x 576 pixels for chrominance. GOB: for H.263, a Group of Blocks (GOB) comprises of k*16 lines, depending on the picture format (k=1 for QCIF, CIF and sub-QCIF, k=2 for 4CIF and k=4 for 16CIF). MB: a macroblock (MB) relates to four blocks of luminance and the spatially corresponding two blocks of chrominance. Each block consists of 8x8 pixels. 3. Design Issues for Packetizing H.263 Bitstream H.263 is based on the ITU-T Recommendation H.261 [2] (referred to as H.261 in this document). Although it employs similar techniques to reduce both temporal and spatial redundancy, there are several major differences between the two algorithms that impact the design of packetization schemes significantly. This section summarizes those differences. Zhu [Page 2] Internet Draft draft-ietf-avt-payload-03.txt January 10, 1997 3.1 Optional Features of H.263 In addition to the basic source coding algorithms, H.263 supports four negotiable features to improve performance: Advanced Prediction, PB frames, Syntax-based Arithmetic Coding, and Unrestricted Motion Vectors. They can be used in any combination. Advanced Prediction(AP): four motion vectors instead of one can be used for some macroblocks in the frame. This feature makes recovery from packet loss harder, because more redundant information has to be preserved at the beginning of the packet when fragmenting at macroblock boundaries. PB frames: two frames ( P frame and B frame) are coded into one bitstream with macroblocks from the two frames interleaved. From a packetization point of view, a MB from the P frame and a MB from the B frame must be treated together because each MB for the B frame are coded based on the corresponding MB for the P frame. A means must be provided to ensure proper rendering of two frames in the right order. Also if part of this combined bitstream is lost, it will affect the two frames, and possibly more. Syntax-based Arithmetic Coding (SAC): Huffman codes are not the only choice for variable length coding. When the SAC option is on, the resultant run value pair after quantization of Discrete Cosine Transform (DCT) coefficients will be coded differently from Huffman codes, but the macroblock hierarchy will be preserved. Since context variables are only synchronized before fixed length codes in the bitstream, any fragmentation at variable length codes will result in difficulty in decoding in the presence of packet loss without carrying the values of all the context variables in each packet header. Unrestricted motion vector feature also has impact on packetization because of larger range of motion vector than normal. To enable proper decoding of packets received without dependency on previous packets, the use of these optional features is signaled in the H.263 payload header, as described in section 5. 3.2 GOB Numbering In H.263, each picture is divided into groups of blocks (GOB). GOBs are numbered by vertical scan of the GOBs, starting with the upper GOB and ending with the lower GOB. In contrast, a GOB in H.261 is composed of three rows of 16x16 MB for QCIF, and three half rows of MB for CIF format. Like H.261, a GOB is divided into macroblocks in H.263. The definition of a macroblock in H.263 is the same as in H.261. Each GOB in H.263 can have a fixed GOB header, but unlike H.261 the use of the header is optional. If the GOB header is present, it may or may not start on a byte boundary. Byte alignment can be achieved by proper bit stuffing by the encoder, but it is not required. Zhu [Page 3] Internet Draft draft-ietf-avt-payload-03.txt January 10, 1997 In summary, a GOB in H.263 is defined and coded with finer granularity with the same source format, thus resulting in more flexibility for packetization than with H.261. 3.3 Motion Vectors Encoding Differential coding is used to code motion vectors as variable length codes. Unlike in H.261, where each motion vector is predicted from the previous MB in the GOB, H.263 employs a more flexible prediction scheme, where three candidate predictors are used instead of one. It is done differently depending on the presence of GOB header. If the GOB header is included for a GOB, motion vectors are coded with reference to MBs in the current GOB only. But if the GOB header is not present for the current GOB, three motion vectors must be available to decode one macroblock, where two of them might come from the previous GOB. To correctly decode the whole inter-coded GOB, all the motion vectors for MBs in the previous GOB must be available to compute the predictors or the predictors themselves must be present. This can be a major problem for a packetization scheme like the one defined for H.261 when packetizing at MB boundaries [5]. Let's assume a packet starts with one MB but the GOB header is not coded. If the previous packet is lost, then all the motion vectors to predict the motion vector for the MBs in this GOB are not available. In order to decode the received MBs correctly, all the motion vectors for the previous GOB or the motion vector predictors would have to be saved at the beginning of the packet. This would be very expensive and unacceptable in terms of bandwidth overhead. The encoding strategy of each H.263 codec implementation is beyond the scope of this document, even though it has very significant impact on visual quality in the presence of packet loss. However, we strongly recommend use of the GOB header for every GOB at the beginning of a packet to address these problems. 3.4 Macroblock Address As specified by H.261, macroblock address (MBA) is encoded with a variable length code to indicate the position of a macroblock within a group of blocks in the H.261 bitstream. H.263 does not code the MBA explicitly, but the macroblock address within a GOB is necessary to recover the decoder state in the presence of packet loss when fragmenting at MB boundaries. Therefore, this information must be included in the H.263 payload header for two of the modes (Mode B and Mode C as described in section 5) that allow packetization at MB boundaries. Zhu [Page 4] Internet Draft draft-ietf-avt-payload-03.txt January 10, 1997 4. Usage of RTP When transmitting H.263 video streams over the Internet, the output of the encoder can be packetized directly. All the bits resulting >from the bitstream including the fixed length codes and variable length codes (Huffman codes, or SAC if SAC is used) will be included in the packet. Also multiplexing audio and video signals in the same packet is not accommodated, as UDP and RTP provide a much more efficient way to achieve multiplexing. RTP does not guarantee a reliable and orderly data delivery service, so a packet might get lost in the network. To achieve a best-effort recovery from packet loss, the decoder needs assistance to proceed with decoding of other packets that are received. Thus it is desirable to be able to process each packet independent of other packets. Some frame level information is included in each packet, such as source format and flags for optional features to assist the decoder in operating correctly and efficiently in presence of packet loss. The flags for H.263 optional features also provide information about coding options used in the H.263 video streams that can be used by session management tools. The H.263 video stream will be carried as payload data within the RTP packets. A new H.263 payload header is defined in section 5, H.263 payload header. This section defines the usage of RTP fixed header and H.263 video packet structure. 4.1 RTP Header usage Each RTP packet starts with a fixed RTP header. The following fields of the RTP fixed header are used for H.263 video stream: Marker bit (M bit): The Marker bit of the RTP header is set to 1 when the current packet carries the end of current frame. 0 otherwise. Payload Type (PT): The Payload Type shall specify H.263 video payload format. Timestamp: The RTP Timestamp encodes the sampling instance of the first video frame contained in the RTP data packet. The RTP timestamp may be the same on successive packets if a video frame occupies more than one packet. For H.263 video stream, the RTP timestamp is based on a 90 kHz clock, the same as that of RTP payload for H.261 stream [5]. 4.2 Video Packet Structure H.263 compressed bitstream is carried as payload within each RTP packet. For each RTP packet, the RTP header is followed by the H.263 payload header, which is followed by the standard H.263 compressed bitstream. The size of the H.263 payload header is variable depending on modes used as detailed in the next section. The layout of the RTP H.263 video packet is shown as: Zhu [Page 5] Internet Draft draft-ietf-avt-payload-03.txt January 10, 1997 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263 Payload Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | H.263 stream | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. H.263 Payload Header For H.263 video streams, each RTP packet carries only one H.263 video packet. The H.263 payload header is always present for each H.263 video packet. Three formats (Mode A, Mode B and Mode C) are defined for RTP H.263 payload header. In Mode A, a H.263 payload header of four bytes is present before actual compressed H.263 video bitstream in the packet. It allows fragmentation at GOB boundaries. In Mode B, a eight byte H.263 payload header is used and each packet starts at MB boundaries with the PB frame option off. Finally, Mode C with a 12 byte header is provided to support fragmentation at MB boundaries for frames that are coded with the PB frame option. The mode is indicated by the F field and P field in the header. The three modes can be intermixed for one compressed frame. All client application are required to be able to receive packets in all three modes, but decoding of Mode C packets is optional because PB-frame is an optional feature of H.263 decoder. In this section, the H.263 payload format is shown as rows of 32-bit word. Each word is transmitted in network byte order with the most significant byte shown at the right in the following diagrams. 5.1 Mode A In this mode, H.263 bitstream will be packetized at GOB boundaries. In other words, each packet will start at the beginning of a GOB, and it can carry one or more MBs or GOBs. Only four bytes are used for the header. Mode A can be used with or without PB frame option. For those GOBs that are smaller than network packet size, this mode is recommended. The H.263 payload header definition for Mode A is shown as follows with F=0. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC |I|U|S|A|R |DBQ| TRB | TR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhu [Page 6] Internet Draft draft-ietf-avt-payload-03.txt January 10, 1997 F: 1 bit The flag bit indicates the format of the header. F=0, Mode A, F=1, Mode B or Mode C. P: 1 bit Optional PB-frame mode as defined by the H.263 [4]. "0" implies normal I or P frame, "1" PB-frame. When F=1, P also indicates modes. Mode B if P=0, Mode C if P=1. SBIT: 3 bits Start bits specifies number of bits that should be ignored in the first data byte. EBIT: 3 bits End bits specifies number of bits that should be ignored in the last data byte. SRC : 3 bits Source format specifies the resolution of the frames contained as defined by the H.263 [4]. I: 1 bit. Picture coding type, defined by H.263[4], "0" is intra-coded, "1" is inter-coded. U: 1 bit Unrestricted Motion Vector mode as defined by H.263 [4], "0" off, "1" on. S: 1 bit Optional Syntax-based Arithmetic Code mode as defined by the H.263 [4], 0" off, "1" on. A: 1 bit Optional Advanced Prediction mode as defined by H.263 [4], "0" off, "1" on. R: 4 bits Reserved, must be set to zero. DBQ: 2 bits Differential quantization parameter used to calculate quantizer for the B frame based on quantizer for the P frame, when PB frame option is on. The value should be the same as DBQUANT defined by the H.263 [4]. Set to zero if PB frame option is off. Zhu [Page 7] Internet Draft draft-ietf-avt-payload-03.txt January 10, 1997 TRB: 3 bits Temporal Reference for the B frame as defined by the H.263 [4]. Set to zero if PB frame option is off. TR: 8 bits Temporal Reference for the P frame as defined by the H.263 [4]. Set to zero if the PB frame option is off. 5.2 Mode B In this mode, the H.263 stream can be fragmented at MB boundaries. Thus necessary information is needed at the start of a packet to recover the decoder internal state in the presence of packet loss. It is intended for those GOBs whose sizes are larger than the maximum packet size allowed in the underlying protocol. This mode can only be used with PB frame option off. Mode C as defined in the next section can be used to fragment at MB boundaries with PB frame option on. The H.263 payload header definition for Mode B is shown as follows with F=1 and P=0: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | QUANT | GOBN | MBA |R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|U|S|A| HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in Mode A: F, P, SBIT, EBIT, SRC, I, U, S and A. Other fields are defined as follows: QUANT: 5 bits Quantization value for the first MB coded at the starting of the packet. Set to 0 if the packet begins with a GOB header. This is the equivalent of GQUANT defined by the H.263 [4]. GOBN: 5 bits GOB number in effect at the start of the packet. GOB number is specified differently for different resolutions. See H.263 [4] for details. MBA: 9 bits The absolute address of the first MB within its GOB, counting from 0. HMV1, VMV1: 7 bits each. Horizontal and vertical motion vector predictors for the first MB in this packet[4]. When four motion vectors are used for current MB with advanced prediction option, these would be the motion vector predictors for block number 1 in this MB. Zhu [Page 8] Internet Draft draft-ietf-avt-payload-03.txt January 10, 1997 HMV2, VMV2, 7 bits each. Horizontal and vertical motion vector predictors for block number 3 in the current MB when four motion vectors are used for this MB in advanced prediction mode. This is needed because block number 3 in the first MB needs different motion vector predictors from other blocks in the MB. These two fields are not used when the current MB only has one motion vector. See the H.263 [4] for block organization in a frame. R : 2 bits Reserved, must be set to zero. 5.3 Mode C In this mode, H.263 stream can be fragmented at MB boundaries of P frames when the PB frame option is on. It is intended for those GOBs whose sizes are larger than the maximum packet size allowed in the underlying protocol. H.263 payload header definition for Mode C is shown as follows with F=1 and P=1: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | QUANT | GOBN | MBA |R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|U|S|A| HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RR |DBQ| TRB | TR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in Mode B: F, P, SBIT, EBIT, SRC, QUANT, GOBN, MBA, R, I, U, S, A, HMV1, VMV1, HMV2, VMV2. The rest of the fields (TR, DBQ, TRB) are defined the same as in Mode A, except field RR of 19 bits is reserved and its value must be zero. 5.4 Selection of Modes for the H.263 Payload Header Packets with different modes can be intermixed. The modes shall be selected carefully based on performance characteristics, H.263 coding modes and underlying network protocols. We strongly recommend use of Mode A whenever possible. The major advantage of Mode A over Mode B and C is its simplicity. The header is one half and one third of the size of Mode B and C respectively. Transmission overhead is reduced and the savings may be very significant when working with very low bit rates, especially when low latency is desired. Zhu [Page 9] Internet Draft draft-ietf-avt-payload-03.txt January 10, 1997 Another advantage of Mode A is that it simplifies error recovery in the presence of packet loss. The internal state of the decoder can be recovered at GOB boundaries instead of having to synchronize with MBs as in Mode B and C. The GOB headers and the picture start code are easy to identify, and their presence will normally cause the H.263 decoder to re-synchronize its internal states. Requiring the decoder to synchronize its internal states at MBs introduces extra overhead and complexity for the decoder. Mode A shall be used for packets starting with a GOB of size smaller than the network packet size. The major disadvantage of Mode A is lack of flexibility in packetization when a GOB can not fit in a network packet. Mode B has the advantage of flexibility with fragmentation at MB boundaries with PB frame option off. This mode is necessary when a GOB is larger than the network packet size. It has the disadvantage of higher overhead with a long header of 8 bytes. For small packets, this may not be desirable. Mode C is the same as B, except it allows fragmentation with PB option on at the price of 4 additional bytes. Finally, we would like to emphasize that recovery from packet loss will depend on the decoder's ability to use the information provided in the H.263 payload header within the RTP packets. 6. References [1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP : A Transport Protocol for Real-Time Applications, RFC 1889. [2] Video Codec for Audiovisual Services at px64 kbits/s, ITU-T Recommendation H.261, 1993 [3] RTP Profile for Audio and Video Conference with Minimal Control, RFC 1890. [4] Video Coding for Low Bitrate Communication, ITU-T Recommendation H.263, 1996 [5] T. Turletti, C. Huitema, RTP Payload Format for H.261 Video Stream. RFC 2032. 7. Author's Address Chunrong "Chad" Zhu Mail Stop: JF2-78 Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Zhu [Page 10] Internet Draft draft-ietf-avt-payload-03.txt January 10, 1997 Email: czhu@ibeam.intel.com Tel: (503) 264-8849 Fax: (503) 264-6067 Zhu [Page 11] --=====================_853816466==_ Content-Type: text/plain; charset="us-ascii" --=====================_853816466==_-- From rem-conf-request@es.net Mon Jan 20 14:55:13 1997 Received: from gorf (actually gorf.Stanford.EDU) by osi-west.es.net with ESnet SMTP (PP); Mon, 20 Jan 1997 11:54:34 -0800 Received: from vxtreme.com by gorf (931110.SGI/inc-1.0) id AA04201; Mon, 20 Jan 97 11:51:22 -0800 Received: from zima_gold by uncola via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id LAA15765; Mon, 20 Jan 1997 11:53:27 -0800 Message-Id: <32E3CD8D.3978@vxtreme.com> Date: Mon, 20 Jan 1997 11:54:53 -0800 From: Anders Klemets Organization: VXtreme, Inc. X-Sender: Anders Klemets X-Mailer: Mozilla 4.0b1 (WinNT; I) Mime-Version: 1.0 To: Peter Parnes Cc: rem-conf@es.net Subject: Re: Some comments on current SDP usage X-Priority: Normal References: <199701191852.TAA08743@salt.cdt.luth.se> Content-Type: multipart/mixed; boundary="----------7D4EF89EB918" This is a multi-part message in MIME format. ------------7D4EF89EB918 Content-Type: multipart/alternative; boundary="----------633011824D9219" ------------633011824D9219 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Peter Parnes wrote: > Where does the specs say that fields must be in any strict order? The BNF syntax at the end of the document, (appendix A, I think) makes it quite clear that there is a strict order in which the fields must appear. Anders ------------633011824D9219 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
 Peter Parnes wrote:
> Where does the specs say that fields must be in any strict order?
 
The BNF syntax at the end of the document, (appendix A, I think) makes it
quite clear that there is a strict order in which the fields must appear.
 
Anders
 
------------633011824D9219-- ------------7D4EF89EB918 Content-Transfer-Encoding: 7bit Content-Description: Address Book Card for Anders Klemets Content-Disposition: inline; filename="nsmail8Q.TMP" Content-Type: text/x-vCard; charset=us-ascii; name="nsmail8Q.TMP" BEGIN:VCARD FN:Anders Klemets N:Klemets;Anders ORG:VXtreme, Inc. ADR:;;701 Welch Rd., Building C;Palo Alto;CA;94086 EMAIL;INTERNET:klemets@vxtreme.com TEL;WORK:415-614-0718 TEL;FAX:415-614-0710 X-NAV-HTML:T END:VCARD ------------7D4EF89EB918-- From rem-conf-request@es.net Mon Jan 20 16:57:35 1997 Received: from emout05.mail.aol.com (actually emout05.mx.aol.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 20 Jan 1997 13:56:57 -0800 Received: (from root@localhost) by emout05.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id QAA24100; Mon, 20 Jan 1997 16:56:53 -0500 (EST) Date: Mon, 20 Jan 1997 16:56:53 -0500 (EST) From: Videoduck1@aol.com Message-ID: <970120164835_504954690@emout05.mail.aol.com> To: rem-conf@es.net, videophone@es.net Subject: UK ISDN Videoconferencing Check out the UK ISDN Videoconferencing Demonstration Service Website at: http://members.aol.com/videoduck1 Three demo numbers are available to H.320 ISDN videoconferencing users in the UK 0897 596001 0891 517488 0891 517488 Hope you like them. From rem-conf-request@es.net Mon Jan 20 20:47:08 1997 Received: from dilbert.com-path.com by osi-west.es.net with ESnet SMTP (PP); Mon, 20 Jan 1997 17:46:37 -0800 Received: from default (206.133.8.141) by dilbert.com-path.com (EMWAC SMTPRS 0.81) with SMTP id ; Mon, 20 Jan 1997 20:53:29 -0500 Message-ID: <32E41FBA.6EC5@com-path.com> Date: Mon, 20 Jan 1997 20:45:30 -0500 From: glenn kline Reply-To: glenn@com-path.com X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: unsubscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubscribe From rem-conf-request@es.net Tue Jan 21 02:47:38 1997 Received: from manuel.nta.no by osi-west.es.net with ESnet SMTP (PP); Mon, 20 Jan 1997 23:47:03 -0800 X400-Received: by mta tf in /PRMD=telenor/ADMD=TELEMAX/C=no/; Relayed; Tue, 21 Jan 1997 08:46:48 +0100 Date: Tue, 21 Jan 1997 08:46:48 +0100 X400-Originator: Stein-E.Myklebust@kjeller.fou.telenor.no X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=telenor/ADMD=TELEMAX/C=no/;4238 97/01/21 08:46] Content-Identifier: 4238 97/01/21 Alternate-Recipient: Allowed From: Stein-E.Myklebust@kjeller.fou.telenor.no Message-ID: <"4238 97/01/21 08:46*/G=Stein-E/S=Myklebust/OU=kjeller/O=fou/PRMD=telenor/ADMD=TELEMAX/C=no/"@MHS> To: rem-conf Subject: unsubscribe unsubscribe From rem-conf-request@es.net Tue Jan 21 04:16:07 1997 Received: from sonne.darmstadt.gmd.de by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 01:15:22 -0800 Received: from kappa (kappa [141.12.59.12]) by sonne.darmstadt.gmd.de (8.8.4/8.8.2) with SMTP id KAA09206 for ; Tue, 21 Jan 1997 10:15:15 +0100 (MET) Message-ID: <32E489B3.59EB@darmstadt.gmd.de> Date: Tue, 21 Jan 1997 10:17:39 +0100 From: Peter Hoermann X-Mailer: Mozilla 3.0Gold (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Gateways Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi everybody, I'm looking for a solution to bring Internet and ISDN videoconferences together. Has anyone already experiences in this area ? And furthermore: has one of you already experienced RADVision's H.320/H.323 Gateway(s) ? Are there maybe products of other companies that are solving the same problem ? Hope to hear from you. Thanks in advance. Peter Hoermann From rem-conf-request@es.net Tue Jan 21 04:57:10 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 01:56:31 -0800 Received: from boom.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 21 Jan 1997 09:56:05 +0000 X-Mailer: exmh version 1.6.6 3/24/96 To: Peter Hoermann cc: merci@cs.ucl.ac.uk, rem-conf@es.net Subject: Re: Gateways In-reply-to: Your message of "Tue, 21 Jan 1997 10:17:39 +0100." <32E489B3.59EB@darmstadt.gmd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Jan 1997 09:56:01 +0000 Message-ID: <10045.853840561@cs.ucl.ac.uk> From: Roy Bennett Peter >Hi everybody, > >I'm looking for a solution to bring Internet and ISDN videoconferences >together. Has anyone already experiences in this area ? And furthermore: This solution is being addressed in our project MERCI (Multimedia European Research Conferencing Integration) - a successor to the MICE project and also funded by the European Union. You can find information on our plans at our web site http://www-mice.cs.ucl.ac.uk/merci/ Most of the work on this aspect of the project is being done by our partner in Berlin, TELES AG, which specialises in ISDN videoconferencing. We expect to have an initial H323/MBONE G/W to allow a single MBONE terminal to join an H320 conference by the end of next month. After that we will develop the gateway further to allow multiple participants on each side. >has one of you already experienced RADVision's H.320/H.323 Gateway(s) ? >Are there maybe products of other companies that are solving the same >problem ? I, personally, have not seen this G/W. >Hope to hear from you. Thanks in advance. > >Peter Hoermann Best wishes Roy ----------------------------------------------------------------------- Roy Bennett, Project Manager, MERCI Computer Science Phone: +44 171 380 7934 University College London Fax: +44 171 387 1397 Gower Street, LONDON WC1E 6BT Email: rbennett@cs.ucl.ac.uk --------- URL http://www-dept.cs.ucl.ac.uk/staff/R.Bennett ------------ From rem-conf-request@es.net Tue Jan 21 06:05:30 1997 Received: from proxy1.ba.best.com by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 03:04:35 -0800 Received: from kaipara.live.com (kaipara.live.com [206.86.37.12]) by proxy1.ba.best.com (8.8.4/8.8.3) with SMTP id DAA25828 for ; Tue, 21 Jan 1997 03:02:46 -0800 (PST) Date: Tue, 21 Jan 1997 03:02:46 -0800 (PST) Message-Id: <1.5.4.16.19970121035011.0a375910@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: New mailing list of interest to many Many of the subscribers to "rem-conf" may also be interested in a mailing list - described below - that has recently been created. To subscribe: Send email to "mafp-request@lists.best.com", with the word subscribe in the BODY of the message. Description of the mailing list: ================================ The "mafp@lists.best.com" mailing list is an open forum for the discussion of "on the wire" data formats and protocols for transmitting generic 'attribute' data in distributed applications - especially multicast-based applications. (MAFP stands for "multicast attribute framing protocol".) A large class of distributed applications involve the dynamic sharing, dissemination, or 'pushing' of structured data - data that in many cases can be considered as a set of "attributes": (name, value) pairs, or perhaps (name, type, value) tuples. The primary goal of this mailing list is to help achieve consensus on one or more common formats for representing attribute data, particularly in multicast-based applications. The adoption of such a format (or formats) would benefit a wide variety of applications, both simplifying their development and encouraging their interoperability. In the future, such a format could conceivably be standardized by the IETF. A document describing one such format has been published as an Internet Draft: "draft-finlayson-mafp-00.txt". (This document can also be found online as "http://www.lvn.com/mafp.txt".) Subscribers to this mailing list are encouraged to comment on this draft, and/or submit additional documents for discussion. Ross Finlayson finlayson@lvn.com From rem-conf-request@es.net Tue Jan 21 08:26:52 1997 Received: from radvision.rad.co.il by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 05:26:12 -0800 Received: by firewall.radvision.rad.co.il id <24200>; Tue, 21 Jan 1997 15:22:31 +0200 Message-Id: <97Jan21.152231ist.24200@firewall.radvision.rad.co.il> From: Amotz Shemi To: 'Peter Hoermann' Cc: "'rem-conf@es.net'" Subject: RE: Gateways Date: Tue, 21 Jan 1997 15:26:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter,=20 RADVision's LAN to WAN gateway is in the market for about two years. It = connects four LAN segments with four WAN ports (V.35, ISDN or leased = lines). The next H.323/H.320 GW version has passed interop tests and = now in a beta phase (more info in www.radvision.com - am not one of the = marketing folks) Amotz Shemi RADVision amotz@radvision.rad.co.il ---------- From: Peter Hoermann[SMTP:peha@darmstadt.gmd.de] Sent: Tuesday, January 21, 1997 11:17 AM To: rem-conf@es.net Subject: Gateways Hi everybody, I'm looking for a solution to bring Internet and ISDN videoconferences together. Has anyone already experiences in this area ? And furthermore: has one of you already experienced RADVision's H.320/H.323 Gateway(s) ? Are there maybe products of other companies that are solving the same problem ? Hope to hear from you. Thanks in advance. Peter Hoermann From rem-conf-request@es.net Tue Jan 21 09:47:00 1997 Received: from mail.cs.tu-berlin.de by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 06:46:07 -0800 Received: from kolbmais.cs.tu-berlin.de (jo@kolbmais.cs.tu-berlin.de [130.149.25.97]) by mail.cs.tu-berlin.de (8.8.4/8.8.4) with ESMTP id PAA10673; Tue, 21 Jan 1997 15:46:04 +0100 (MET) From: Joerg Ott Received: (from jo@localhost) by kolbmais.cs.tu-berlin.de (8.8.4/8.8.4) id PAA26115; Tue, 21 Jan 1997 15:46:02 +0100 (MET) Message-Id: <199701211446.PAA26115@kolbmais.cs.tu-berlin.de> Subject: Re: Gateways To: peha@darmstadt.gmd.de Date: Tue, 21 Jan 1997 15:45:59 +0100 (MET) Cc: cabo@informatik.uni-bremen.de (Carsten Bormann), rem-conf@es.net X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Hi Peter, we doing a great deal of work in the area of conferencing interoperability for ITU-T H.320/H.324, H.323, and systems based on IETF MMUSIC/AVC documents (part of which is done in the context of the MERCI project). TELES is offering products in this area, at the university we are doing research and protocol development (together with the University of Bremen). Send me an e-mail, if you like further information. Gruesse, Joerg ------------------------------------------------------------------------------- Joerg Ott jo@cs.tu-berlin.de Technische Universitaet Berlin, Germany fax + 49 30 314-25 156 TELES AG voice + 49 30 314-73 389 From rem-conf-request@es.net Tue Jan 21 10:39:15 1997 Received: from apollo.telecom.ipn.mx by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 07:38:21 -0800 Received: by apollo.telecom.ipn.mx (1.38.193.5/16.2) id AA05500; Tue, 21 Jan 1997 09:37:01 -0600 Date: Tue, 21 Jan 1997 09:37:01 -0600 (Mexico) From: Eduardo Mendoza To: rem-conf@es.net Subject: unsubscribe Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From rem-conf-request@es.net Tue Jan 21 10:54:23 1997 Received: from er6.rutgers.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 07:53:50 -0800 Received: from localhost (ddeepika@localhost) by er6.rutgers.edu (8.6.12+bestmx+oldruq+newsunq/8.6.12) with SMTP id KAA14452 for ; Tue, 21 Jan 1997 10:53:46 -0500 Date: Tue, 21 Jan 1997 10:53:44 -0500 (EST) From: Deepika To: rem-conf@es.net Subject: Unsubscribe In-Reply-To: <32E489B3.59EB@darmstadt.gmd.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Unsubscribe From rem-conf-request@es.net Tue Jan 21 12:42:36 1997 Received: from woody.multilink.com (actually multilink.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 09:41:14 -0800 Received: (from mail@localhost) by woody.multilink.com (8.6.12/8.7.3) id MAA06793; Tue, 21 Jan 1997 12:46:13 -0500 From: Jim_Hirni@multilink.com Received: from multimail.multilink.com(172.16.7.3) by woody via smap (V1.3) id sma006781; Tue Jan 21 12:45:46 1997 Received: from cc:Mail by multimail.multilink.com id AA853879968; Tue, 21 Jan 97 12:44:54 PST Date: Tue, 21 Jan 97 12:44:54 PST Encoding: 25 Text Message-Id: <9700218538.AA853879968@multimail.multilink.com> To: rem-conf@es.net, Peter Hoermann Subject: Re: Gateways Peter, Try VideoServer. You can find their web page at www.videosever.com Regards, Jim Hirni ______________________________ Reply Separator _________________________________ Subject: Gateways Author: Peter Hoermann at InterNet Date: 1/21/97 8:12 AM Hi everybody, I'm looking for a solution to bring Internet and ISDN videoconferences together. Has anyone already experiences in this area ? And furthermore: has one of you already experienced RADVision's H.320/H.323 Gateway(s) ? Are there maybe products of other companies that are solving the same problem ? Hope to hear from you. Thanks in advance. Peter Hoermann From rem-conf-request@es.net Tue Jan 21 13:01:07 1997 Received: from gatekeeper.sprintlabs.com (actually dmz.sprintlabs.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 10:00:22 -0800 Received: by gatekeeper.sprintlabs.com id AA09507 (5.67b/IDA-1.5 for ); Tue, 21 Jan 1997 10:04:55 -0800 Received: from unknown(199.2.53.28) by gatekeeper.sprintlabs.com via smap (V3.1) id xma009505; Tue, 21 Jan 97 10:04:46 -0800 X-Sender: aollikai@gatekeeper Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Jan 1997 10:04:47 -0800 To: rem-conf@es.net From: ari@sprintlabs.com (Ari Ollikainen) Subject: How to UNSUBSCRIBE from rem-conf I humbly suggest that the recent unsubscribers try to do it the right way...by sending your UNSUBSCRIBE request (in both Subject: line and body of message) to: rem-conf-request@es.net The list maintainers do NOT read the messages sent to the list. Back when I ran/maintained this list, I used to post a periodic reminder for change requests and archive(s) location...I also studiously ignored drop requests sent to the whole list unless I had some time available to service them. Please do NOT send *me* any requests for changes...I've moved on... _/_/ _/_/_/_/ _/ Ari Ollikainen _/ _/ _/ _/ _/ Sprint Advanced Technology Laboratories _/_/_/_/ _/_/_/_/ _/ Switching and Interworking Development _/ _/ _/ _/ _/ 1 Adrian Court (M/S: CABURS0102) _/ _/ _/ _/ _/ Burlingame, CA 94010 ~~RECOM Technologies Inc.~~ Voice: 415.375.4265 FAX: 415.375.4490 From rem-conf-request@es.net Tue Jan 21 13:36:40 1997 Received: from bugs-bunny.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 10:34:48 -0800 Received: from nobozo.CS.Berkeley.EDU (nobozo.CS.Berkeley.EDU [128.32.34.58]) by bugs-bunny.CS.Berkeley.EDU (8.8.4/8.8.2) with SMTP id KAA27005 for <298-list@bmrc.Berkeley.EDU>; Tue, 21 Jan 1997 10:27:52 -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 KAA31299 for <298-list@bmrc>; Tue, 21 Jan 1997 10:27:55 -0800 Date: Tue, 21 Jan 1997 10:27:55 -0800 Message-Id: <199701211827.KAA31299@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@bugs-bunny.CS.Berkeley.EDU From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday January 22, 1997 12:30-2:00 PDT 405 Soda Hall) "Music Delivery and Promotion on the Internet" Philip R. Wiser Liquid Audio The promise of commercial music distribution via the Internet is ready to be fulfilled. This talk will describe the technical and legal complexities of online music distribution. It will also present solutions to current online distribution barriers. Music is a natural product for online delivery. Digital representations are of desirable quality and only marginal value is added by physical packaging. In fact, delivery of musical information via the Internet has been available for many years. None of this content, however, has been distributed commercially. It is only recently that large amounts of easily accessible, high quality content has been exposed. The natural progression is to commercially distribute this information electronically. Several technologies are required to make digital music distribution a reality. Audio compression, embedded digital signalling, and cryptography provide the framework for these systems. In addition, commerce and rights reporting components must be implemented. This discussion will address all of these features. ------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PST (GMT - 8 hrs). See sdr 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 Jan 21 13:56:14 1997 Received: from palrel3.hp.com by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 10:54:11 -0800 Received: from hpinrput.cup.hp.com (hpindac.cup.hp.com [15.13.136.82]) by palrel3.hp.com with SMTP (8.7.5/8.7.3) id KAA12794 for ; Tue, 21 Jan 1997 10:53:42 -0800 (PST) Received: by hpinrput.cup.hp.com with SMTP (1.38.193.4/15.5+IOS 3.20+cup+OMrelay) id AA03826; Tue, 21 Jan 1997 10:53:46 -0800 Message-Id: <9701211853.AA03826@hpinrput.cup.hp.com> To: rem-conf@es.net Subject: unsubscribe Date: Tue, 21 Jan 1997 10:53:45 -0800 From: Cheng Tang unsubscribe From rem-conf-request@es.net Tue Jan 21 15:17:18 1997 Received: from stargate.acs.ohio-state.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 12:14:45 -0800 Received: (from rdixon@localhost) by stargate.acs.ohio-state.edu (8.7.3/8.7.3) id PAA13894; Tue, 21 Jan 1997 15:14:43 -0500 (EST) Date: Tue, 21 Jan 1997 15:14:42 -0500 (EST) From: Bob Dixon To: rem-conf@es.net Subject: Re: Gateways Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII >Hi everybody, > >I'm looking for a solution to bring Internet and ISDN videoconferences >together. Has anyone already experiences in this area ? And furthermore: In addition to the RADVision research project I mentioned earlier, we are also looking into doing this using a Mac as a gateway. Feed the Mac baseband video and audio, and have the Mac running any desired IP videoconferencing software. We use this now to send video >from our campus TV station and satellite dishes to people on the Internet, using CU-SeeMe. Bob Dixon Ohio State University From rem-conf-request@es.net Tue Jan 21 16:40:07 1997 Received: from gatekeeper.sprintlabs.com (actually dmz.sprintlabs.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 13:38:07 -0800 Received: by gatekeeper.sprintlabs.com id AA11022 (5.67b/IDA-1.5 for ); Tue, 21 Jan 1997 13:42:35 -0800 Received: from unknown(199.2.53.28) by gatekeeper.sprintlabs.com via smap (V3.1) id xma011019; Tue, 21 Jan 97 13:42:28 -0800 X-Sender: aollikai@gatekeeper Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Jan 1997 13:42:28 -0800 To: Jim_Hirni@multilink.com From: ari@sprintlabs.com (Ari Ollikainen) Subject: Re: Gateways Cc: rem-conf@es.net > Try VideoServer. You can find their web page at www.videosever.com > Could you cite specific products? The only references to H.323 and "Internet" are the press releases dealing with Videoserver's relationships with Compaq and cisco: 12/11/96 "...the combined Compaq and VideoServer conferencing solution will integrate the Compaq ProLiant line of servers and VideoServer hardware modules and software. The VideoServer conferencing modules will consist of audio, video and data processing units, H.323 gateway solutions, and ISDN and Ethernet connectivity. Customers will be able to add an optional module for Continuous Presence, which enables up to four conference sites to be viewed simultaneously. Initially, two base configurations will be available: a four-user or eight-user conferencing system. In addition, either configuration can be upgraded to support up to 48 users. The joint VideoServer/Compaq collaboration and conferencing systems will augment Compaq's existing videoconferencing terminal offerings... " and 10/28/96 "...The collaboration mobilizes the emerging videoconferencing standard H.323, making conferencing available to a broader range of customers. Joining the strengths of Cisco IOS software and VideoServer's conferencing infrastructure capabilities, improves H.323-based multimedia connectivity . The two companies will integrate VideoServer's gateway software and hardware modules into a wide range of Cisco platforms. "We are committed to delivering a full array of network services through Cisco IOS software and this partnership is an important step in the evolution of real-time, multimedia conferencing solutions," said Stephen DeWitt, vice president of Cisco IOS software marketing at Cisco Systems. "The results of this joint effort will contribute to making videoconferencing a mainstream application for corporations." "This is a business of standards," said Robert Castle, president of VideoServer, Inc. "Cisco and VideoServer share this belief and have put standards support and interoperability at the top of our product requirements. Working with the major endpoint manufacturers, the two companies have already tested key elements of standards support and we are working to help make the combinations of endpoints, routers, and conferencing gateways a seamless solution that fits the corporate network. Together we will build software capabilities which incorporate key elements of the ITU standard H.323 for LAN conferencing." Under the understanding, Cisco will OEM gateway modules from VideoServer to enable conferencing between LAN and WAN endpoints. VideoServer is demonstrating the gateway this week at Telecon in Anaheim, CA the leading annual exposition for conferencing products. ..." _/_/ _/_/_/_/ _/ Ari Ollikainen _/ _/ _/ _/ _/ Sprint Advanced Technology Laboratories _/_/_/_/ _/_/_/_/ _/ Switching and Interworking Development _/ _/ _/ _/ _/ 1 Adrian Court (M/S: CABURS0102) _/ _/ _/ _/ _/ Burlingame, CA 94010 ~~RECOM Technologies Inc.~~ Voice: 415.375.4265 FAX: 415.375.4490 From rem-conf-request@es.net Tue Jan 21 18:07:58 1997 Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 15:06:58 -0800 Received: from galaxy (galaxy.ctr.columbia.edu [128.59.68.54]) by sirius.ctr.columbia.edu (8.8.4/8.6.4.287) with SMTP id SAA03505; Tue, 21 Jan 1997 18:06:51 -0500 (EST) Sender: liao@ctr.columbia.edu Message-ID: <32E550C3.BAC@ctr.columbia.edu> Date: Tue, 21 Jan 1997 18:26:59 -0500 From: Raymond Liao Organization: CTR, Columbia University X-Mailer: Mozilla 3.0Gold (X11; I; HP-UX A.09.07 9000/725) MIME-Version: 1.0 To: rem-conf@es.net CC: mnl@ctr.columbia.edu Subject: Comet Group Seminar, CTR, Columbia Univ. References: <199701200341.MAA17811@tsbgw.wide.toshiba.co.jp> <32E2F762.7D52@ctr.columbia.edu> <32E36728.677C@cs.columbia.edu> <32E3A781.1556@ctr.columbia.edu> <32E3DD1B.41C67EA6@ctr.columbia.edu> <32E4245C.3A30@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi there: There is going to be a live broadcast on Mbone for the seminar of the Comet Group at the Center for Telecommunications Research, Columbia University, New York City. The seminar is held weekly on Thursday from 10 AM to 11 AM EST, with the exception of this week which will be on Friday, Jan. 24th. The audio part will be PCM encoded, through RTP, IP address is 224.2.131.73/25792, ttl=127 The video part will be H.261 encoded, through RTP, IP address is 224.2.189.122/57242, ttl=127. The seminar home page is: http://comet.ctr.columbia.edu/activities/seminars/ Best, Raymond. ????? \ @ @ / ---------------------------.oOO--0--OOo.--------------------------- Raymond R.-F. Liao Email: liao@ctr.columbia.edu Center for Telecomm. Research Web: www.ctr.columbia.edu/~liao Columbia University Phone: (212) 939-7158 New York City, NY10027-6699 Fax: (212) 316-9068 ___________________________.oooO___Oooo.___________________________ From rem-conf-request@es.net Tue Jan 21 18:11:34 1997 Received: from woody.multilink.com (actually multilink.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 21 Jan 1997 15:10:26 -0800 Received: (from mail@localhost) by woody.multilink.com (8.6.12/8.7.3) id SAA11552; Tue, 21 Jan 1997 18:15:20 -0500 From: Jim_Hirni@multilink.com Received: from multimail.multilink.com(172.16.7.3) by woody via smap (V1.3) id sma011550; Tue Jan 21 18:15:18 1997 Received: from cc:Mail by multimail.multilink.com id AA853899780; Tue, 21 Jan 97 18:13:57 PST Date: Tue, 21 Jan 97 18:13:57 PST Encoding: 84 Text Message-Id: <9700218538.AA853899780@multimail.multilink.com> To: ari@sprintlabs.com (Ari Ollikainen) Cc: rem-conf@es.net Subject: Re[2]: Gateways Ari, I'm not a Videoserver employee, but I bet if you call their Burlington Ma number (617-229-2000) and ask for sales, someone there will be happy to talk with you about specific producs. Regards, Jim Hirni ______________________________ Reply Separator _________________________________ Subject: Re: Gateways Author: ari@sprintlabs.com (Ari Ollikainen) at InterNet Date: 1/21/97 6:12 PM > Try VideoServer. You can find their web page at www.videosever.com > Could you cite specific products? The only references to H.323 and "Internet" are the press releases dealing with Videoserver's relationships with Compaq and cisco: 12/11/96 "...the combined Compaq and VideoServer conferencing solution will integrate the Compaq ProLiant line of servers and VideoServer hardware modules and software. The VideoServer conferencing modules will consist of audio, video and data processing units, H.323 gateway solutions, and ISDN and Ethernet connectivity. Customers will be able to add an optional module for Continuous Presence, which enables up to four conference sites to be viewed simultaneously. Initially, two base configurations will be available: a four-user or eight-user conferencing system. In addition, either configuration can be upgraded to support up to 48 users. The joint VideoServer/Compaq collaboration and conferencing systems will augment Compaq's existing videoconferencing terminal offerings... " and 10/28/96 "...The collaboration mobilizes the emerging videoconferencing standard H.323, making conferencing available to a broader range of customers. Joining the strengths of Cisco IOS software and VideoServer's conferencing infrastructure capabilities, improves H.323-based multimedia connectivity . The two companies will integrate VideoServer's gateway software and hardware modules into a wide range of Cisco platforms. "We are committed to delivering a full array of network services through Cisco IOS software and this partnership is an important step in the evolution of real-time, multimedia conferencing solutions," said Stephen DeWitt, vice president of Cisco IOS software marketing at Cisco Systems. "The results of this joint effort will contribute to making videoconferencing a mainstream application for corporations." "This is a business of standards," said Robert Castle, president of VideoServer, Inc. "Cisco and VideoServer share this belief and have put standards support and interoperability at the top of our product requirements. Working with the major endpoint manufacturers, the two companies have already tested key elements of standards support and we are working to help make the combinations of endpoints, routers, and conferencing gateways a seamless solution that fits the corporate network. Together we will build software capabilities which incorporate key elements of the ITU standard H.323 for LAN conferencing." Under the understanding, Cisco will OEM gateway modules from VideoServer to enable conferencing between LAN and WAN endpoints. VideoServer is demonstrating the gateway this week at Telecon in Anaheim, CA the leading annual exposition for conferencing products. ..." _/_/ _/_/_/_/ _/ Ari Ollikainen _/ _/ _/ _/ _/ Sprint Advanced Technology Laboratories _/_/_/_/ _/_/_/_/ _/ Switching and Interworking Development _/ _/ _/ _/ _/ 1 Adrian Court (M/S: CABURS0102) _/ _/ _/ _/ _/ Burlingame, CA 94010 ~~RECOM Technologies Inc.~~ Voice: 415.375.4265 FAX: 415.375.4490 From rem-conf-request@es.net Wed Jan 22 05:36:53 1997 Received: from rzdspc1.informatik.uni-hamburg.de by osi-west.es.net with ESnet SMTP (PP); Wed, 22 Jan 1997 02:36:19 -0800 Received: from ro2.informatik.uni-hamburg.de (ro2.informatik.uni-hamburg.de [134.100.15.162]) by rzdspc1.informatik.uni-hamburg.de (8.8.4/8.8.4) with SMTP id LAA02014 for ; Wed, 22 Jan 1997 11:36:16 +0100 (MET) Received: from ro4.informatik.uni-hamburg.de by ro2.informatik.uni-hamburg.de (4.1/SMI-4.1/RZ-1.04/s) with SMTP id ; Wed, 22 Jan 97 11:36:53 +0100 From: richter@ro2.informatik.uni-hamburg.de (Jan-Peter Richter) Message-Id: <9701221036.AA01657@ro2.informatik.uni-hamburg.de> Subject: Re: How to UNSUBSCRIBE from rem-conf To: rem-conf@es.net Date: Wed, 22 Jan 1997 11:36:15 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Hi, being bugged by an ever increasing number of 'unsubscribe' messages to the list, Juergen Schoenwaelder - the maintainer of another mailing list - has decided to append automatically the following message to _every_ posting: (quote) -- !! This message is brought to you via the `tkined & scotty' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to . !! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information. (unqoute) Something similar should be done with the rem-conf distributions also! JPR ------------------------------------------------------------------------------ Jan-Peter Richter Vogt-Koelln-Str.30 Universitaet Hamburg D-22527 Hamburg Fachbereich Informatik Tel: +49 40 5494-2350 Arbeitsgruppe Telekommunikation Fax: +49 40 5494-2328 und Rechnernetze e-mail: richter@informatik.uni-hamburg.de ------------------------------------------------------------------------------ From rem-conf-request@es.net Wed Jan 22 14:18:31 1997 Received: from arioch.ams.ameslab.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 22 Jan 1997 11:17:57 -0800 Received: by arioch.ams.ameslab.gov (940816.SGI.8.6.9/930416.SGI) for rem-conf@es.net id NAA08887; Wed, 22 Jan 1997 13:17:51 -0600 From: Joe Metzger Message-Id: <9701221317.ZM8885@arioch.ams.ameslab.gov> Date: Wed, 22 Jan 1997 13:17:50 -0600 In-Reply-To: richter@ro2.informatik.uni-hamburg.de (Jan-Peter Richter) "Re: How to UNSUBSCRIBE from rem-conf" (Jan 22, 11:36am) References: <9701221036.AA01657@ro2.informatik.uni-hamburg.de> Organization: ESnet X-Phone: (515)294-1918 X-Fax: (515)294-4491 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: rem-conf@es.net Subject: Upcoming changes to rem-conf Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hello, Currently rem-conf@es.net is a manually maintained list. Mail sent to rem-conf-request@es.net is forwarded to a real person who updates the distribution list. Mail sent to rem-conf@es.net is not sent to the maintainer. This list currently contains over a thousand subscribers. Around 100 of those subscribers appears to be re-distribution lists at other sites. As part of a larger task to update the ESnet email infrastructure, I am evaluating mailing list software to take over this task. The goal is to increase the level of service provided and to reduce the human resources required to maintain lists. Several of the mailing list systems I am looking at contain mechanisms to detect and prevent mailing loops. Some of these systems will have problems if a subscriber is actually another list managed by the same software. If you are currently running a rem-conf re-distribution list with automated software, please let me know. Send these notes to METZGER@ES.NET. NOT TO THE LIST. I will be providing additional updates before we actually switch this list over to a new system. If you have any questions or comments, please send mail to metzger@es.net. Thanks. ************************************************************************* * Joe Metzger Ames Office: (515)294-1939 * * Computer Systems Engineer LBNL Office: (510)486-5740 * * Network Information Services Group metzger@es.net * * ESnet, Lawrence Berkeley Laboratory 314 Wilhelm, ISU, Ames IA, 50011 * ************************************************************************* From rem-conf-request@es.net Thu Jan 23 12:31:19 1997 Received: from cbgw1.lucent.com by osi-west.es.net with ESnet SMTP (PP); Thu, 23 Jan 1997 09:30:43 -0800 Received: from hoserve by cbig1.firewall.lucent.com (SMI-8.6/EMS-L sol2) id MAA02684; Thu, 23 Jan 1997 12:23:35 -0500 Received: by hoserve.ho.lucent.com (4.1/EMS-L SunOS) id AA21645; Thu, 23 Jan 97 10:03:19 EST From: rameshn@lucent.com Received: from hopaw33 (hopaw33.ho.lucent.com) by hoserve.ho.lucent.com (4.1/EMS-L SunOS) id AA21588; Thu, 23 Jan 97 10:01:55 EST Received: by hopaw33 (4.1/EMS-L SunOS) id AA10193; Thu, 23 Jan 97 10:02:26 EST Date: Thu, 23 Jan 97 10:02:26 EST Original-From: ramesh@hoserve.ho.lucent.com Message-Id: <9701231502.AA10193@hopaw33> To: rem-conf@es.net Subject: IEEE INFOCOM'98 - Advance Call for Papers Colleagues, Please consider submitting your work to INFOCOM'98. Apologies for multiple copies and please feel free to distribute this call for papers by any means appropriate. Thanks. Ramesh. ------------------------------------------------------------------ | INFOCOM'98 - SEVENTEENTH IEEE INTERNATIONAL CONFERENCE | | ON | | COMPUTER COMMUNICATIONS | | | | Gateway to the 21st Century | | | | March 29 - April 2, 1998 | | Hotel Nikko, San Francisco, USA | | | | Sponsored by: | | | | Computer Communications Technical Committees of the | | IEEE Computer and Communications Societies | | | ------------------------------------------------------------------ CALL FOR PAPERS: Authors are invited to submit full papers reporting results, strongly substantiated by mathematical analysis, experiment, implementation, or simulation, in all areas of computer communications and networks; however, more qualitative exploration of important architectural issues is also encouraged. A more detailed list of specific areas of interest can be obtained from the INFOCOM'98 WWW site. SCHEDULE AND IMPORTANT DATES: Full Paper Due - July 15, 1997 Notification of Acceptance - October 31, 1997 Camera Ready Version of Accepted Paper Due - January 5, 1998 Conference - March 31-April 2, 1998 Tutorials - March 29-30, 1998 SUBMISSION INSTRUCTIONS: The first page of your paper should contain paper title, author name(s), complete address (telephone, fax, email) for all authors, indication of who is the corresponding author, abstract, followed by key words and optionally one or more areas of interest from the list on the WWW site. The paper should be limited to 20 pages excluding illustrations and 30 pages overall. We strongly encourage electronic submission of manuscripts in Postscript format. Please consult the INFOCOM '98 WWW site for electronic submission instructions. Hard copy submissions will still be handled on an exception basis, but require explicit permission from the Infocom'98 Technical Program Chair who can be reached at: Professor Ian Akyildiz Technical Program Chair, IEEE INFOCOM '98 School of ECE Georgia Tech, Atlanta, Georgia 30332. (email) infocom98@ee.gatech.edu (phone) +1 404-894-5141 (fax) +1 404-894-0035 STUDENT GRANTS: You may qualify for a Student Travel Grant to defray some of your costs for presenting a paper at this conference. IEEE Communications Society will award a limited number of Student Travel Grants to full-time students who represent their accepted papers at INFOCOM '98. Please refer to the INFOCOM'98 WWW site for further details. WORLD-WIDE WEB: Information on Infocom'98 is available through the World Wide Web at USA: http://www.comsoc.org/~infocom98 Europe: http://www.cs.ucl.ac.uk/research/infocom98 Asia/Pacific: http://www.iss.nus.sg/INFOCOM +------------------------------------------------------------------+ INFOCOM'98 EXECUTIVE COMMITTEE: GENERAL CHAIR VICE GENERAL CHAIR Roch Guerin Henning Schulzrinne IBM T.J. Watson Research Center Columbia Univ. Yorktown Heights, NY, USA. New York, NY, USA. TECHNICAL CHAIR Ian Akyildiz Georgia Institute of Technology Atlanta, Georgia, USA. PUBLICITY CHAIR PUBLICATIONS CHAIR Ramesh Nagarajan, Bell labs, USA. Abhijit Choudhury, Bell labs, USA. TUTORIAL CO-CHAIRS PANELS CO-CHAIRS Arvind Krishna, IBM, USA. David Tipper, Univ. of Pittsburgh, USA. Catherine Rosenberg, Nortel, UK. Vittorio Trecordi, CEFRIEL, Italy. LOCAL ARRANGEMENTS CHAIR FINANCIAL CO-CHAIRS Fred Bauer, SRI, USA. Ariel Orda, Technion, Israel. Yannis Korilis, Bell labs, USA. INFOCOM STANDING COMMITTEE CHAIR: Harvey Freeman, LANWORKS, Inc., U.S.A. +----------------------------------------------------------------+ From rem-conf-request@es.net Thu Jan 23 15:17:37 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Thu, 23 Jan 1997 12:16:16 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id MAA02740 for ; Thu, 23 Jan 1997 12:16:22 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma002729; Thu Jan 23 12:15:26 1997 Received: by hille.msri.org (8.7/MSRI) id MAA23804; Thu, 23 Jan 1997 12:14:08 -0800 (PST) Date: Thu, 23 Jan 1997 12:14:08 -0800 (PST) Message-Id: <199701232014.MAA23804@hille.msri.org> To: rem-conf@es.net From: joe Reply-to: joe@msri.org Subject: Bruce Sagan on Group Representations and Symmetric Functions, Part I MBone Broadcast Announcement ---------------------------- Title: Bruce Sagan on Group Representations and Symmetric Functions, Part I Date: Jan 28, 1997 Time: 12:00 PST8PDT 1 hours Contact: joe@msri.org URL: http://www.msri.org/events/introLN.html Description: Bruce Sagan's first lecture from the MSRI Introductory Lecture Series in Combinatorics, August 12 - 23, 1996 mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Jan 23 15:19:12 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Thu, 23 Jan 1997 12:17:26 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id MAA02770 for ; Thu, 23 Jan 1997 12:17:23 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma002755; Thu Jan 23 12:16:51 1997 Received: by hille.msri.org (8.7/MSRI) id MAA23838; Thu, 23 Jan 1997 12:15:34 -0800 (PST) Date: Thu, 23 Jan 1997 12:15:34 -0800 (PST) Message-Id: <199701232015.MAA23838@hille.msri.org> To: rem-conf@es.net From: neal Reply-to: neal@msri.org Subject: Bruce Sagan on Group Representations and Symmetric Functions, Part II MBone Broadcast Announcement ---------------------------- Title: Bruce Sagan on Group Representations and Symmetric Functions, Part II Date: Jan 29, 1997 Time: 12:00 PST8PDT 1 hours Contact: neal@msri.org URL: http://www.msri.org/events/introLN.html Description: Bruce Sagan's second lecture lecture from the MSRI Introductory Lecture Series in Combinatorics, August 12 - 23, 1996 mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Jan 23 15:20:26 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Thu, 23 Jan 1997 12:18:22 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id MAA02826 for ; Thu, 23 Jan 1997 12:18:29 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma002808; Thu Jan 23 12:18:19 1997 Received: by hille.msri.org (8.7/MSRI) id MAA23872; Thu, 23 Jan 1997 12:17:02 -0800 (PST) Date: Thu, 23 Jan 1997 12:17:02 -0800 (PST) Message-Id: <199701232017.MAA23872@hille.msri.org> To: rem-conf@es.net From: neal Reply-to: neal@msri.org Subject: Bruce Sagan on GroupRepresentations and Symmetric Functions, Part III MBone Broadcast Announcement ---------------------------- Title: Bruce Sagan on GroupRepresentations and Symmetric Functions, Part III Date: Jan 30, 1997 Time: 12:00 PST8PDT 1 hours Contact: neal@msri.org URL: http://www.msri.org/events/introLN.html Description: Bruce Sagan's third lecture from the MSRI Introductory Lecture Series in Combinatorics, August 12 - 23, 1996 mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Jan 23 20:05:09 1997 Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 23 Jan 1997 17:04:34 -0800 Received: from yosemite (liao@yosemite.ctr.columbia.edu [128.59.72.34]) by sirius.ctr.columbia.edu (8.8.5/8.6.4.287) with SMTP id UAA24090; Thu, 23 Jan 1997 20:04:31 -0500 (EST) Sender: liao@ctr.columbia.edu Message-ID: <32E80A9D.794BDF32@ctr.columbia.edu> Date: Thu, 23 Jan 1997 20:04:29 -0500 From: Raymond Liao Organization: CTR, Columbia University X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3 sun4c) MIME-Version: 1.0 To: rem-conf@es.net CC: "Andrew T. Campbell" Subject: Mbone Seminar Notice References: <199701221844.NAA20405@sirius.ctr.columbia.edu> <32E687ED.4492@ctr.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MBone Broadcast Announcement Title: CSR (Cell Switch Router): High Performance Router for Realtime Internet and Intranet Speaker: Hiroshi Esaki Chief Architect, CSR Project Computer & Network Division Toshiba Corporation, Japan Date: Friday, January 24, 1997 Time: 10:00 A.M. - 12:00 noon EST Contact: Prof. Andrew T. Campbell (campbell@ctr.columbia.edu) URL: http://comet.ctr.columbia.edu/activities/seminars/ Place: Multimedia Network Laboratory 8LE1 Schapiro Research Building Center for Telecommunications Research Columbia University New York City, USA Abstract: Architecture overview of Cell Switch Router (CSR) is presented. CSR contains cell switch fabric and IP packet switch fabric to achieve high throughput IP forwarding. CSR can operate both with PVC (Permanent Virtual Connection) and with SVC as the VC for cut-thru packet forwarding. With cut-thru packet forwarding, CSR does not need to analyze the IP header to forward packet but uses VPI/VCI information for packet forwarding. Since the CSR is router, CSR has full functionality of existing router. For example, the packet routing path can be dynamically changed according to the network status, even regarding cut-thru packet forwarding. Similar architecture models are proposed by many researchers. The architectural difference and the technical features will also be discussed in the presentation. From rem-conf-request@es.net Thu Jan 23 22:40:39 1997 Received: from ness.arch.su.EDU.AU by osi-west.es.net with ESnet SMTP (PP); Thu, 23 Jan 1997 19:39:55 -0800 Received: from arch.su.EDU.AU (archsci-server [129.78.66.193]) by ness.arch.su.EDU.AU (8.7.5/8.7.3) with ESMTP id OAA28054 for ; Fri, 24 Jan 1997 14:39:50 +1100 (EST) Received: from duich (duich.arch.su.EDU.AU [129.78.66.251]) by arch.su.EDU.AU (8.7.5/8.6.12) with SMTP id OAA20341 for ; Fri, 24 Jan 1997 14:39:48 +1100 (EST) Date: Fri, 24 Jan 1997 14:34:42 +1100 (EST) From: Anna Cicognani X-Sender: anna@duich To: rem-conf@es.net Subject: VC97 - Mbone Broadcast Message-ID: URL: http://www.arch.usyd.EDU.AU/~anna MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Title: VC97 International Conference on Creative Collaboration in Virtual Communities Start: 13 february 1997, 21.00 GMT End: 15 february 1997, 08.00 GMT Test session from 11.2.97, 23.00 GMT to 12.2.97, 06.00 GMT Contact: Mrs. Anna Cicognani - Chair URL: http://www.arch.usyd.edu.au/kcdc/conferences/VC97 Place: Sydney University Faculty of Architecture Key Centre of Design Computing Abstract: VC97 is a leading Conference about VCs and virtual enviroments. Keynote speakers include: Howard Rheingold and Stewart Brand. Topics from politics in cyberspace, to design an architecture of virtual environments. Scenario planning at the end of the Conference. From rem-conf-request@es.net Fri Jan 24 09:55:32 1997 Received: from monitor.internaut.com by osi-west.es.net with ESnet SMTP (PP); Fri, 24 Jan 1997 06:54:53 -0800 Received: from multi ([204.57.137.9]) by monitor.internaut.com (8.7.6/8.6.12) with SMTP id GAA12987 for ; Fri, 24 Jan 1997 06:52:05 -0800 (PST) Received: by multi with Microsoft Mail id <01BC09C3.12C4EEA0@multi>; Fri, 24 Jan 1997 06:51:49 -0800 Message-ID: <01BC09C3.12C4EEA0@multi> From: Bernard Aboba To: "'rem-conf@es.net'" Subject: New mailing list on multicasting of Web content Date: Fri, 24 Jan 1997 06:51:48 -0800 Encoding: 45 TEXT New mailing list on multicasting Web content A new mailing list has been set up for discussing the distribution of Web content via "unreliable multicast." To subscribe, send a message to "www-multicast-request@w3.org", and put "subscribe" in the subject line. The archive of the mailing list is available as http://lists.w3.org/Archives/Public/www-multicast/, and the FTP server (used for archiving of related documents) is available at ftp://ftp.zilker.net/pub/mailcom/WWW-MULTICAST/. The primary initial goals of this list will be to produce an Internet Draft reviewing existing implementations of unreliable multicasting of Web content, as well as a draft reviewing potential applications and their requirements. Should an IETF working group be formed in this area, it is envisioned that this list would subsequently be used for discussions relating to working group business. Many Web sites that distribute popular, frequently updated content experience problems with "flash crowds": thousands of access per minute to the same Web page overload the Web server or the network link leading to the server. It is possible that integrating IP multicast with the transport protocol used by the Web (HTTP) may solve this problem. This mailing list focusses on unreliable multicasting of Web content due to the current immaturity of reliable multicast protocols (see "IETF Criteria For Evaluating Reliable Multicast Transport and Application Protocols", A. Mankin, A. Romanow, 11/27/1996 (ftp://ietf.org/Internet-drafts/draft-mankin-reliable-multicast-00.txt).). Reliable multicast protocols will be dealt with by a research group within the IRTF (Internet Research Task Force). Unreliable multicast is better understood. Moreover, there is considerable interest in the Web community to use this technology, both to solve serious existing operational problems like "flash crowds", and to avoid creating new problems due to "server push" applications. Several applications (i.e. cache stuffing) appear to be naturally amenable to use of unreliable multicast. Thus, moving ahead on unreliable webcasting will serve to advance these applications as well as to potentially provide short-term solutions for other applications. The newly created mailing list will focus on these solutions. From rem-conf-request@es.net Fri Jan 24 11:06:44 1997 Received: from ns.research.att.com by osi-west.es.net with ESnet SMTP (PP); Fri, 24 Jan 1997 08:06:08 -0800 Received: from research.research.att.com by ns; Fri Jan 24 11:05:06 EST 1997 Received: from learnx.research.att.com by research; Fri Jan 24 11:02:11 EST 1997 Received: (from baldine@localhost) by learnx.research.att.com (8.7.5/8.7.3) id LAA25685; Fri, 24 Jan 1997 11:00:40 -0500 (EST) Date: Fri, 24 Jan 1997 11:00:40 -0500 (EST) From: Baldine Paul Message-Id: <199701241600.LAA25685@learnx.research.att.com> To: rem-conf@es.net Subject: RTP/H.263 Motion Vector Predictors Cc: basso@research.att.com, mrc@research.att.com In sections 5.2 and 5.3 of RTP Payload Format for H.2363 Video Streams, references are made to HMV1, VMV1, HMV2, VMV2, motion vector predictors included in the packet header for type B and type C packets. The document does not specify the representation of these 7-bit integer quantities. Does anyone know of any other document to clarify this point? The ITU-T H.263 Document will not help since motion vector predictors are not coded in the bit stream but inferred >from the previously decoded macroblock and/or BOG or initialized to zero, depending on the decoding context. Please, send reply to Baldine-Brunel Paul AT&T Labs-Research baldine@research.att.com From rem-conf-request@es.net Fri Jan 24 11:42:08 1997 Received: from roatan.ucs.indiana.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 24 Jan 1997 08:41:23 -0800 Received: from stone51.netlab.indiana.edu (netlab-backup.netlab.indiana.edu [129.79.12.33]) by roatan.ucs.indiana.edu (8.7.3/8.7.3/1.12IUPO) with ESMTP id LAA09480; Fri, 24 Jan 1997 11:41:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by stone51.netlab.indiana.edu (8.7.5/8.7.3) with ESMTP id LAA13271; Fri, 24 Jan 1997 11:41:16 -0500 (EST) Message-Id: <199701241641.LAA13271@stone51.netlab.indiana.edu> X-Mailer: exmh version 2.0beta 12/23/96 Reply-to: robelr@netlab.indiana.edu X-keywords: AllenRobel X-info: Allen Robel, 812-855-0962, 2711 E. 10th Street, Bloomington, IN 47408 To: rem-conf@es.net cc: kling@indiana.edu, robelr@netlab.indiana.edu Subject: Event: Cyberspace and the Future of Community Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Jan 1997 11:41:16 -0500 From: Allen Robel Indiana University is pleased to provide Mbone coverage of the following event. Cyberspace and the Future of Community February 7, 1997 14:00 - 21:30 UTC (09:00 - 16:30 EST) http://www/cs/indiana.edu/horizon/970207 Cyberspace and the Future of Community is jointly sponsored at Indiana University by the Computer Science department, as part of their "Horizon Days" series, by the Philosophy department, and by the Center for Social Informatics (of the School of Library and Information Science), with support >from Sigma Chi for interdisciplinary campus meetings. At a time when the vitality of community is in serious question in the U.S., some hope that Cyberspace can open up new ways for people to join together around common interests. Electronic mail, newsgroups, civic nets (such as HoosierNet), chat rooms, cybercafes, moderated discussion groups, muds and moos -- these are just some of the ways people are starting to interact on-line. How well does the new technology underwrite age-old human tendencies to congregate and communicate? Does it reflect something genuinely novel? Are they good, bad, or transformative? Can electronic forums strengthen local community, or will the new connections be national or international? How much privacy must we sacrifice when we communicate on the net? What will happen to ethics, responsibility, and personal identity? Come participate in a public forum with five nationally-known commentators on the future of community in the age of the internet. **************************************************************************** 9:00 a.m. Reception 9:15 a.m. William Mitchell Dean of the MIT School of Architecture and Planning; author of City of Bits: Space, Place and the Infobahn (published on the Net) 10:45 a.m. Geoffrey Nunberg Xerox Palo Alto Research Center and Stanford University; editor, The Future of the Book; commentator, NPR's "Fresh Air," Usage Editor, The American Heritage Dictionary 1:30 p.m. Langdon Winner Professor of Political Science and Technology Studies, Rennselaer Polytechnic Institute; author of Democracy in a Technological Society 3:00 p.m. Comments and discussion with Rob Kling Professor, School of Library and Information Science, Director, Center for Social Informatics, Indiana University editor of Computerization and Controversy Gregory Rawlins Professor of Computer Science, Indiana University; author of Moths to the Flame ****************************************************************************** Available Abstracts and Biographies: William J. Mitchell, MIT School of Architecture and Planning City of Bits In the past, we always had to go places to do things; we went to work, we went to school, and sometimes we just went out. Now, the unfolding Digital Revolution has changed things; telepresence is an increasingly viable and attractive alternative to physical presence, and virtual spaces compete with physical venues as sites for many transactions. This does not mean that architecture becomes irrelevant, or that cities will just disappear, but it does suggest that we must fundamentally reconsider our concepts of place and community. The cities of the 21st century will be very different from those we know today. Biography: William J. Mitchell is Professor of Architecture and Media Arts and Sciences and Dean of the School of Architecture and Planning at the Massachusetts Institute of Technology. He teaches courses and conducts research in design theory, computer applications in architecture and urban design, and imaging and image synthesis. He consults extensively in the field of computer-aided design and was the co-founder of a California software company. Mitchell's most recent book, City of Bits: Space, Place and the Infobahn, examines architecture and urbanism in the context of the digital tele-communications revolution and the growing domination of software over materialized form. In The Reconfigured Eye: Visual Truth in the Post-Photographic Era (MIT Press, 1992), Mitchell examined the social and cultural impact of digitally altered photographs and synthesized photorealistic scenes. In addition to numerous articles, Mitchell is also the author of Digital Design Media, with Malcolm McCullough (Van Nostrand Reinhold, second ed., 1995; orig. publ. 1991); The Logic of Architecture: Design, Computation, and Cognition (MIT Press, 1990); The Poetics of Gardens, with Charles Moore and William Turnbull (MIT Press, 1988); The Art of Computer Graphics Programming, with Robin S. Liggett and Thomas Kvan (Van Nostrand Reinhold, 1987); and Computer-Aided Architectural Design (Van Notrand Reinhold, 1977). With Patrick Purcell and Malcolm McCullough he edited, and contributed essays to, The Electronic Design Studio (MIT Press, 1990). Geoffrey Nunberg, Xerox PARC Biography: Geoffrey Nunberg (PhD, CUNY 1977) is a Principal Scientist at the Xerox Palo Alto Research Center and a professor of linguistics at Stanford University. He has done research on a number of aspects of natural language and on the history and use of media; he is editor of the recent collection The Future of the Book (UC Press). He also does a regular language feature on the NPR program "Fresh Air," and is Usage Editor and Chair of the Usage Panel of the American Heritage Dictitionary. Langdon Winner, Science and Technology Studies, Rennselaer Polytechnic Institute Cyberlibertarian Dreams and the Future of Civil Society The introduction of digital technology provides an occasion for transforming countless social practices and institutions. At present there is a strong tendency to argue that events are moving in a particular direction, that the future will unfold in a particular way. This view is expressed in an emerging ideology, cyberlibertarianism, a collection of ideas that links ecstatic enthusiasm for electronically mediated forms of living with right wing libertarian ideas about the proper definition of freedom, social life, economics, and politics in the years to come. But is their vision of a wired world truly the utopia it claims to be? Is it a reliable guide to the choices before us? Biography: Langdon Winner is a political theorist who focuses upon social and political issues that surround modern technological change. He is the author of Autonomous Technology, a study of the idea of "technology-out-of-control" in modern social thought, The Whale and the Reactor: A Search for Limits in an Age of High Technology, and editor of Democracy in a Technological Society. Mr. Winner was born and raised in San Luis Obispo, California. He received his B.A., M.A., and Ph.D. in political science from the University of California at Berkeley. He is Professor of Political Science in the Department of Science and Technology Studies at Rensselaer Polytechnic Institute and Director of Graduate Studies in his department. He has also taught at the New School for Social Research, M.I.T., the University of California at Santa Cruz, and the University of Leiden in the Netherlands, and has lectured widely throughout the United States and Europe. In 1991-1992 he was visiting research fellow at the Center for Technology and Culture at the University of Oslo, Norway. Rob Kling, Center for Social Informatics, School of Library and Information Science, Indiana University Biography: Rob Kling's current research focuses on the ways that computerization is a social process with technical elements, how intensive computerization transforms work, and how computerization entails many social choices. He has also studied the ways that complex information systems and expert systems are integrated into the social life of organizations. He has conducted studies in numerous kinds of organizations, including local governments, insurance companies, pharmaceutical firms, and hi-tech manufacturing firms. He has written about the value conflicts implicit in and social consequences ofcomputerization which directly affect the public. He is currently studying the effective use of digital libraries to support research and teaching, and the conditions that foster effective public use of the emerging National Information Infrastructure ("data superhighways"). Dr. Kling is co-author of Computers and Politics: High Technology in American Local Governments (Columbia University Press, 1982). He is co-editor of PostSuburban California: The Transformation of Postwar Orange County (University of California Press, 1990). Computerization and Controversy: Value Conflicts & Social Choices (Academic Press, 1991) examines the social controversies about computerization in organizations and social life, regarding productivity, worklife, personal privacy, risks of computer systems, and computer ethics. Dr. Kling is the sole editor of a substantially rewritten 2nd edition of Computerization and Controversy that Academic Press published in April 1996. Gregory Rawlins, Computer Science Department, Indiana University Gregory Rawlins is associate professor of computer science. He received a BSc in mathematics from the University of the West Indies (1980), and an MSc in mathematics and a PhD in computer science from the University of Waterloo (1983, 1987). He chaired the first workshop on the foundations of genetic algorithms in 1990, is on the editorial board of the Journal of Evolutionary Computation, and has published several books on computer science both for general audiences and for specialists in genetic algorithms and the analysis of algorithms. Rawlins's research centers on computational complexity and machine learning. His current main passion is the investigation of self-adaptive software. He is author of Compared to What?: An Introduction to the Analysis of Algorithms (Computer Science Press), Moths to the Flame (MIT Press), and the forthcoming Slaves of the Machine: The Quickening of Computer Technology (MIT Press), appearing in Spring 1997. -- Allen Robel Indiana University mailto:robelr@netlab.indiana.edu Area Code + Prefix: 812-855 http://www.netlab.indiana.edu/~robelr Office 0962, NetLab 3697, Fax 8299 From rem-conf-request@es.net Fri Jan 24 17:09:29 1997 Received: from mailhost2.BayNetworks.COM (actually ns1.BayNetworks.COM) by osi-west.es.net with ESnet SMTP (PP); Fri, 24 Jan 1997 14:08:43 -0800 Original-Received: from ns1.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.3/BNET-96/12/06-E) with ESMTP id OAA24035 PP-warning: Illegal Received field on preceding line Original-Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns1.BayNetworks.COM (8.8.3/BNET-97/01/07-I) with ESMTP id OAA14411 PP-warning: Illegal Received field on preceding line Posted-Date: Fri, 24 Jan 1997 14:08:37 -0800 (PST) Received: from ester.engeast (ester [192.32.170.56]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-SVR4-S) with SMTP id RAA06314; Fri, 24 Jan 1997 17:08:37 -0500 for Received: by ester.engeast (4.1/SMI-4.1) id AA17396; Fri, 24 Jan 97 17:02:52 EST Message-Id: <9701242202.AA17396@ester.engeast> To: Bill Fenner Cc: mbone@isi.edu, rem-conf@es.net, vvolfson@lobster.wellfleet.com Subject: draft-ietf-idmr-traceroute-ipm-01 question In-Reply-To: Your message of "Thu, 19 Dec 1996 14:26:33 PST." <96Dec19.142648pst.177713@crevenia.parc.xerox.com> Date: Fri, 24 Jan 1997 17:02:50 -0500 From: Vera Volfson Hi, I have a question about draft-ietf-idmr-traceroute-ipm-01 (5.4.3). "If the Responce Address is multicast, the router MUST use a globally routable address, if it has one " What is the definition of 'globally routable address' ? Thanks, Vera From rem-conf-request@es.net Fri Jan 24 18:39:04 1997 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Fri, 24 Jan 1997 15:38:03 -0800 Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.8.4/8.8.4) with SMTP id PAA03890; Fri, 24 Jan 1997 15:37:53 -0800 (PST) Received: from quasar by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0vnvEW-000S9CC; Fri, 24 Jan 97 15:40 PST Message-Id: <1.5.4.32.19970124233801.0091a150@ibeam.intel.com> X-Sender: czhu@ibeam.intel.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Jan 1997 15:38:01 -0800 To: Baldine Paul From: Chunrong Chad Zhu Subject: Re: RTP/H.263 Motion Vector Predictors Cc: rem-conf@es.net, czhu@ibeam.jf.intel.com Each 7 bits field represents a motion vector predictor in half pixel resolution as 2's complement. For example, if HMV1=1000000 (bits 4 through 10 repectively), it represents motion vector predictor 0.5 as speficied by H.263, since half-pel motion vector is often used in inter-coded frame. I will add this clearification into the next revision of the document. Thanks very much for pointing this out. --Chad At 11:00 AM 1/24/97 -0500, you wrote: > >In sections 5.2 and 5.3 of RTP Payload Format >for H.2363 Video Streams, references are made >to HMV1, VMV1, HMV2, VMV2, motion vector predictors >included in the packet header for type B and type C >packets. The document does not specify the representation >of these 7-bit integer quantities. Does anyone know >of any other document to clarify this point? >The ITU-T H.263 Document will not help since motion vector >predictors are not coded in the bit stream but inferred >from the previously decoded macroblock and/or BOG or initialized >to zero, depending on the decoding context. > >Please, send reply to > Baldine-Brunel Paul > AT&T Labs-Research > baldine@research.att.com > > From rem-conf-request@es.net Sat Jan 25 14:15:34 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Sat, 25 Jan 1997 11:13:48 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id LAA07478 for ; Sat, 25 Jan 1997 11:13:48 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma007475; Sat Jan 25 11:12:52 1997 Received: by hille.msri.org (8.7/MSRI) id LAA24888; Sat, 25 Jan 1997 11:11:38 -0800 (PST) Date: Sat, 25 Jan 1997 11:11:38 -0800 (PST) Message-Id: <199701251911.LAA24888@hille.msri.org> To: rem-conf@es.net From: donajski Reply-to: donajski@sunsite.icm.edu.pl Subject: Donajski's Digital Gallery at ICM Warsaw University MBone Broadcast Announcement ---------------------------- Title: Donajski's Digital Gallery at ICM Warsaw University Date: Jan 28, 1997 Time: 18:00 GMT 2 hours Contact: donajski@sunsite.icm.edu.pl URL: http://sunsite.icm.edu.pl/ddg/opening_a-v.html Description: Opening day for 'Garden of forklike paths' exhibition with music concert by Camerata Quartet. Event will start 28 of Jan. 97 at 6.00 pm. From 25 of Jan we will give a daily 'like-test' transmission. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Sat Jan 25 23:21:28 1997 Received: from fawlty5.eng.monash.edu.au by osi-west.es.net with ESnet SMTP (PP); Sat, 25 Jan 1997 20:20:53 -0800 Received: (atiq@localhost) by fawlty5.eng.monash.edu.au (8.7.3/8.6.4) id PAA27947 for rem-conf@es.net; Sun, 26 Jan 1997 15:20:47 +1100 Message-Id: <199701260420.PAA27947@fawlty5.eng.monash.edu.au> Subject: CFP: Switching and Traffic Management To: rem-conf@es.net Date: Sun, 26 Jan 1997 15:20:44 +1100 (EST) Reply-to: atiq@eng.monash.edu.au (Mohammed Atiquzzaman) From: atiq@eng.monash.edu.au (Mohammed Atiquzzaman) X-Mailer: ELM [version 2.4 PL24 ME8b] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit CALL FOR PAPERS SPIE International Symposium Voice, Video, & Data Communications Conference on Performance & Control of Network System 3-7 November 1997, Dallas, Texas, USA Special Session on Switching and Traffic Management in High Speed Networks Session Organizers: Mohammed Atiquzzaman, Monash University, Australia. Bhumip Khasnabish, GTE Labs, USA. Telecommunications in today's competitive marketplace typically involve multiple carriers, multiple services, varied equipment from multiple vendors, and multiple interconnected networks and network systems. The increasing demand in bandwidth for computing and communications has given rise to high speed networks. These networks require special types of switching and traffic management mechanisms. This special session is intended to cover different aspects of high speed switching, congestion control and service interworking mechanisms. Topics include (but are not limited to): o Switching architectures o Buffer management o Congestion control mechanisms o Traffic characterization, control, measurement, models and tools o Prototyping experience and trial results o Scheduling algorithms o Service interworking (Frame Relay and ATM, TCP/IP and ATM, etc.) o Performance evaluation, scalability, reliability and availability Authors should send the following items by email to one of the session organizers (Hard copy of papers may be sent only if electronic submission is impossible). o Postscript copy of full paper. o Plain text file containing the title of the paper, a 250-word abstract, and the author listing (principal author first) with full name, affiliation, mailing address, e-mail address, phone number and fax number for each author. Session Organizers: Mohammed Atiquzzaman Bhumip Khasnabish Dept. of Elect. & Comp. Syst. Engg GTE Labs. Inc., MS-48, Rm.4-292 Monash University, Clayton 40 Sylvan Road, Melbourne 3168, Australia. Waltham MA 02254, USA Tel: +61 3 9905 5383 Tel: +1-617-466-2080 Fax: +61 3 9905 3454 Fax: +1-617-890-9320 email: atiq@eng.monash.edu.au email: bhumip@gte.com http://www.monash.edu.au/~atiq http://www1.acm.org:82/~bhumip/ Important Dates: Deadline for receipt of manuscripts: 30 April 1997 Notification of acceptance/rejection: late June 1997 Proceedings of this conference will be published and available at the symposium. Length of camera-ready manuscript is limited to 12 pages with single-spaced text. ASCII and Postscript versions of this announcement and information about the conference are available >from http://www.monash.edu.au/~atiq From rem-conf-request@es.net Sun Jan 26 01:26:20 1997 Received: from naveen.ncst.ernet.in by osi-west.es.net with ESnet SMTP (PP); Sat, 25 Jan 1997 22:24:54 -0800 Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3]) by naveen.ncst.ernet.in (8.6.12/8.6.6) with ESMTP id LAA00733 for ; Sun, 26 Jan 1997 11:59:54 +0530 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-8.6.5) id LAA16488; Sun, 26 Jan 1997 11:55:15 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA17601; Sun, 26 Jan 97 11:54:45+0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9701260624.AA17601@ece.iisc.ernet.in> Subject: RTCP scalability To: rem-conf@es.net Date: Sun, 26 Jan 97 11:54:44 GMT+5:30 X-Mailer: ELM [version 2.3 PL11] Hi, There has been a major thread of discussion on the RTCP scalability issue. Hoping that this is still an issue and open for discussion... To reduce the possible initial chaos in the network, as well as the receivers, I am wondering about the possibility of reduced/truncated RTCP information carried in the SR and RR reports at the beginning of the session just enough to allow for faster convergence in terms of listener participation (may be an email), and incrementally increase the SR/RR content with time. Once the network sees a periodic, and predictable behaviour of the session,eventually, we can then think of header compression. I realise that I am not in a position to point out the exact nature of the information that can cause a minimal RTCP packet to begin with, to eventually have complete information. Please let me know if the basic idea is acceptable, and worth exploring further. I appreciate your comments and criticism. Regards Anand. From rem-conf-request@es.net Mon Jan 27 11:16:34 1997 Received: from bugs-bunny.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 27 Jan 1997 08:15:56 -0800 Received: from bugs-bunny.CS.Berkeley.EDU (larry@localhost) by bugs-bunny.CS.Berkeley.EDU (8.8.4/8.8.2) with ESMTP id IAA18537; Mon, 27 Jan 1997 08:04:02 -0800 (PST) Message-Id: <199701271604.IAA18537@bugs-bunny.CS.Berkeley.EDU> X-Mailer: exmh version 1.6.9 8/22/96 From: Larry Rowe To: smoliar@pal.xerox.com, blattner@ocfkms.llnl.gov, brauer@faslab.com, kelly_parker@maillink.berkeley.edu, kurt@ampex.com, mm-group@bugs-bunny.CS.Berkeley.EDU, mslade@ix.netcom.com, nic@gigabitnet.net, pmcc@hpl.hp.com, rem-conf@es.net, sfchang@ctr.columbia.edu, sullivan@path0.its.berkeley.edu, tierney@george.lbl.gov, jkeyser@linfield.edu Subject: [Rebroadcast] Berkeley Multimedia Seminar (P. Wiser "Music Delivery and Promotion on the Internet" Reply-To: Rowe@plateau.CS.Berkeley.EDU Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jan 1997 08:03:07 -0800 Sender: larry@plateau.CS.Berkeley.EDU Hi - Last week the broadcast of the Berkeley Multimedia and Graphics Seminar did not get beyond Berkeley due to a network failure about 5 minutes before the broadcast. Because Phil Wiser's talk was so interesting and several remote viewers were already connected to watch the broadcast, we will rebroadcast his talk this wednesday during the seminar. If you want to ask questions after the seminar, you can contact Phil at Liquid Audio (see http://bmrc.berkeley.edu/298/w1.html for addresses). Larry Rowe -- Professor Lawrence A. Rowe Internet: Rowe@BMRC.Berkeley.EDU Computer Science Division - EECS Phone: 510-642-5117 University of California, Berkeley Fax: 510-642-5615 Berkeley, CA 94720-1776 URL: http://www.bmrc.berkeley.edu/~larry --- Berkeley Multimedia and Graphics Seminar (Wednesday January 29, 1997 12:30-2:00 PDT 405 Soda Hall) "Music Delivery and Promotion on the Internet" Philip R. Wiser (Liquid Audio ) The promise of commercial music distribution via the Internet is ready to be fulfilled. This talk will describe the technical and legal complexities of online music distribution. It will also present solutions to current online distribution barriers. Music is a natural product for online delivery. Digital representations are of desirable quality and only marginal value is added by physical packaging. In fact, delivery of musical information via the Internet has been available for many years. None of this content, however, has been distributed commercially. It is only recently that large amounts of easily accessible, high quality content has been exposed. The natural progression is to commercially distribute this information electronically. Several technologies are required to make digital music distribution a reality. Audio compression, embedded digital signalling, and cryptography provide the framework for these systems. In addition, commerce and rights reporting components must be implemented. This discussion will address all of these features. From rem-conf-request@es.net Mon Jan 27 13:33:09 1997 Received: from frodo.casarosso.com (actually 194.151.11.22) by osi-west.es.net with ESnet SMTP (PP); Mon, 27 Jan 1997 10:32:28 -0800 Received: from aragorn (jps@aragorn.casarosso.com [194.151.11.103]) by frodo.casarosso.com (8.7.5/8.7.3) with SMTP id UAA09350 for ; Mon, 27 Jan 1997 20:41:07 +0100 Sender: jps@frodo.casarosso.com Message-ID: <32ECF505.7A8D70A1@casarosso.com> Date: Mon, 27 Jan 1997 19:33:41 +0100 From: Jan Paul Stegeman Organization: Janot Entertainment X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.28 i586) 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 Mon Jan 27 15:55:38 1997 Received: from cs.wvu.edu (actually stat.cs.wvu.edu) by osi-west.es.net with ESnet SMTP (PP); Mon, 27 Jan 1997 12:54:16 -0800 Received: from backus by cs.wvu.edu (SMI-8.6/SMI-SVR4) id PAA00792; Mon, 27 Jan 1997 15:56:23 -0500 Date: Mon, 27 Jan 1997 15:54:01 -0500 (EST) From: "Todd L. Montgomery" X-Sender: tmont@backus To: rem-conf@es.net, rmp-discuss@aurora.jhuapl.edu, rm@irtf.cs.berkeley.edu, floyd@ee.lbl.gov, mccanne@cs.berkeley.edu, gcast_all@gcast.com Subject: Announcing an SRM implementation in C++ Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I apologize for any duplicates of this message received, but I want to try and reach all the interested parties.... This announcement is also available through: http://research.ivv.nasa.gov/projects/RMP/GSRM.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Generic Scaleable Reliable Multicast (GSRM) Framework GlobalCast Communications (http://www.gcast.com) announces the beta test availability of a Scaleable Reliable Multicast protocol. The Generic Scaleable Reliable Multicast (GSRM) framework is a C++ library that allows a C++ application to reliably multicast data to large groups of computers on a LAN, WAN or Internet. It is an adaptation and implementation of the SRM work that Steve McCanne, Sally Floyd, Lixia Zhang, Van Jacobson, and others pioneered as part of the wb mbone tool[1]. GSRM allows a developer to either use the standard stream-based framework (SSRM), which organizes packets in a stream sent from each sender, or to build its own model by defining its own ALF frames and application data units (ADUs). In this way, GSRM provides a general framework within which applications may define their own formats and protocol processing. The flexibility of this ALF approach [2] allows GSRM to be applicable for a wide range of potential applications. GSRM provides a stream-based, best effort reliable multicast system called Stream-based SRM (SSRM). SSRM is built on top of the GSRM framework and provides a partial ALF model that the application can customize to fits its needs. Most applications will not need to use anything more than SSRM. However, the framework fully allows new ALF models to be constructed from scratch. Some of GSRMs features: - Supports a connection-less, best-effort, reliable multicast group communication model over a WAN. - Supports a generic notion of application level framing (ALF) of data into application data units (ADUs) as well as support for integrated layer processing (ILP) of ADUs. - Decouples the SRM request/repair policy on ADUs from the ALF model. - Provides a rate-based flow control mechanism. Some of SSRMs features: - Supports a stream-based, best-effort, push model reliable multicast delivery system with the following assumptions of ordering, message stability, and group communication models: - Ordering requirements of a stream are application defined - Message stability is also application defined - one-to-many or few-to-many group communication model - Finite length streams Supported Platforms: Windows 95/NT with Microsoft Visual C++ 4.x Sun Solaris 2.5 with SunPro C++ 4.x Availability: Through the GlobalCast Communications web site at http://www.gcast.com through the BETA Program. Contact for Additional Information Thomas Yeh (tyeh@gcast.com) Albert Chen (achen@gcast.com) Brian Whetten (whetten@gcast.com) Todd Montgomery (tmont@cs.wvu.edu) About GlobalCast: GlobalCast Communications is a venture capital backed company committed to providing world leading reliable multicast protocols, tools, and applications. It is actively involved in helping drive forward the state of the art in reliable multicast research and protocols, and is committed to doing all it can to assist the research community and standards bodies in developing open standards for reliable multicast. To this end, it has a history of open disclosure of its protocols and of allowing free use of its software for academic or other non-commercial use. [1] S. Floyd, V. Jacobson, S. McCanne. "A Reliable Multicast Framework for Light-weight Sessions and Application Level Framing". Proceedings of the 1995 ACM SIGCOMM Conference. August, 1995, Cambridge, MA. pp. 342-356. [2] D. Clark and D. Tennenhouse. "Architectural Considerations for a New Generation of Protocols". Proceedings of ACM SIGCOMM '90, Sept. 1990, pp. 201-208. ------------------------------------------------------------------------------ Todd L. Montgomery GlobalCast Communications, Inc. Senior Scientist and Co-Founder 3777 Depot Road E-mail: tmont@gcast.com Suite 415, 416A tmont@research.ivv.nasa.gov Hayward, CA 94545 tmont@io.com Telephone: (510) 266-0400 tmont@cs.wvu.edu FAX: (510) 266-0401 tmont@access.mountain.net tmont@wvu.edu http://www.cs.wvu.edu/~tmont/ ------------------------------------------------------------------------------ From rem-conf-request@es.net Mon Jan 27 16:46:29 1997 Received: from basil.cdt.luth.se by osi-west.es.net with ESnet SMTP (PP); Mon, 27 Jan 1997 13:45:47 -0800 Received: from salt.cdt.luth.se (root@salt.cdt.luth.se [130.240.193.242]) by basil.cdt.luth.se (8.7.5/8.7.3) with ESMTP id WAA14217; Mon, 27 Jan 1997 22:35:30 +0100 (MET) Received: from salt (peppar@localhost [127.0.0.1]) by salt.cdt.luth.se (8.6.12/8.6.12) with ESMTP id WAA15662; Mon, 27 Jan 1997 22:39:38 +0100 Message-Id: <199701272139.WAA15662@salt.cdt.luth.se> X-Mailer: exmh version 2.0gamma 1/24/96 To: "Todd L. Montgomery" cc: rem-conf@es.net, rmp-discuss@aurora.jhuapl.edu, rm@mash.cs.berkeley.edu, floyd@ee.lbl.gov, mccanne@cs.berkeley.edu, gcast_all@gcast.com Subject: Re: Announcing an SRM implementation in C++ In-reply-to: Your message of "Mon, 27 Jan 1997 15:54:01 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jan 1997 22:39:38 +0100 From: Peter Parnes tmont@cs.wvu.edu said: > Supported Platforms: > Sun Solaris 2.5 with SunPro C++ 4.x How about other compilers such as GNU g++ ? Any plans on providing a Java-api? /P From rem-conf-request@es.net Mon Jan 27 18:24:23 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 27 Jan 1997 15:23:26 -0800 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 27 Jan 1997 23:23:15 +0000 To: "Todd L. Montgomery" cc: rem-conf@es.net, rmp-discuss@aurora.jhuapl.edu, rm@irtf.cs.berkeley.edu, floyd@ee.lbl.gov, mccanne@cs.berkeley.edu, gcast_all@gcast.com Subject: Re: Announcing an SRM implementation in C++ In-reply-to: Your message of "Mon, 27 Jan 1997 15:54:01 EST." Date: Mon, 27 Jan 1997 23:23:12 +0000 Message-ID: <2727.854407392@cs.ucl.ac.uk> From: Jon Crowcroft hmmmm..... but srm never addressed 3 key quesions of (reli)able multicast 0 selective unreliability 1/ congestion 2/ per source ordering i think this should continue on the rm list only. excet that the only active discussion to date there has been rmfp........ how long is it since the ietf announcement of the rm list/group? .....hmmm.... i spose everyone is too busy writing sigcomm papers:-) jon From rem-conf-request@es.net Mon Jan 27 19:38:19 1997 Received: from nobozo.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 27 Jan 1997 16:37:33 -0800 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 QAA24032 for ; Mon, 27 Jan 1997 16:37:32 -0800 Date: Mon, 27 Jan 1997 16:37:32 -0800 Message-Id: <199701280037.QAA24032@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: rem-conf@es.net From: Jerrlyn Iwata Subject: [reminder] Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday January 29, 1997 12:30-2:00 PDT 405 Soda Hall) "[Rebroadcast] Music Delivery and Promotion on the Internet" Philip R. Wiser Liquid Audio The promise of commercial music distribution via the Internet is ready to be fulfilled. This talk will describe the technical and legal complexities of online music distribution. It will also present solutions to current online distribution barriers. Music is a natural product for online delivery. Digital representations are of desirable quality and only marginal value is added by physical packaging. In fact, delivery of musical information via the Internet has been available for many years. None of this content, however, has been distributed commercially. It is only recently that large amounts of easily accessible, high quality content has been exposed. The natural progression is to commercially distribute this information electronically. Several technologies are required to make digital music distribution a reality. Audio compression, embedded digital signalling, and cryptography provide the framework for these systems. In addition, commerce and rights reporting components must be implemented. This discussion will address all of these features. From rem-conf-request@es.net Mon Jan 27 20:08:22 1997 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Mon, 27 Jan 1997 17:07:24 -0800 Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.8.4/8.8.4) with SMTP id RAA09164; Mon, 27 Jan 1997 17:07:16 -0800 (PST) Received: from quasar by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0vp23j-000S9MC; Mon, 27 Jan 97 17:09 PST Message-Id: <1.5.4.32.19970128010726.0091ae94@ibeam.intel.com> X-Sender: czhu@ibeam.intel.com X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Jan 1997 17:07:26 -0800 To: "Wilson C. Chung" From: Chunrong Chad Zhu Subject: Re: RTP/H.263 Motion Vector Predictor Cc: rem-conf@es.net In case, someone else also missed my earlier replay to this question, here it is: Each 7 bits field represents a motion vector predictor in half pixel resolution as 2's complement. For example, if HMV1=1000000 (bits 4 through 10 repectively), it represents motion vector predictor 0.5 as speficied by H.263, since half-pel motion vector is often used in inter-coded frame. I will add this clearification into the next revision of the document. Thanks very much for pointing this out. --Chad At 04:06 PM 1/27/97 -0500, you wrote: >Dear BB: > >According to Turletti/Huitema's RTP payload format for H.261 video >streams >date July 7, 1996 document Section 5.1, HMVD and VMVD is a 5 bits number >encoded as a 2's complement number. I think Chad Zhu from Intel will >need >to be more specific about what the 7 bits number represent. >BTW, Chad's earlier RTP payload format for H.263 Video stream document >dated >Feb 26, 1996 and June 10, 1996 have 8 bits instead of 7 bits. >I did not join the e-mail reflector until recently so I do not know is >there >any discussion regarding that. > >best regards, Wilson > >Baldine Paul wrote: >> >> My understanding is that the RTP packetization will provide some >> level of error resilience in case of packet losses. In order to recover >> the motion vector of the current macroblock (in case of loss of the previous packet) >> the motion vector associated with the previous macroblock in the GOB is to be >> encoded as part of the RTP/H.263 packet header. This, in addition to the MVD that >> is encoded in the H.263 bitstream, will allow to decoder to reconstruct the current >> macroblock, even if the previous is lost. As I was saying to Wilson, what is not specified >> in the document is whether the 7 bit represents a motion vector component in >> sign/magnitude, 2's complement, 1's complement or any other format(like, e.g. indexing >> into a table of motion vector values). >> What fo you think of this interpretation? >> Baldine > >-- >Wilson C. Chung (T)1-508-623-4667 (F)1-508-749-2804 >PictureTel Corp, 100 Minuteman Road, M/S 635, Andover MA 01810 USA > > From rem-conf-request@es.net Mon Jan 27 20:21:25 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 27 Jan 1997 17:20:52 -0800 Received: from little-bear.precept.com by precept.com (SMI-8.6/SMI-SVR4) id RAA05311; Mon, 27 Jan 1997 17:20:48 -0800 Date: Mon, 27 Jan 1997 17:20:47 -0800 (PST) From: Stephen Casner To: rem-conf@es.net Subject: Minutes for AVT WG at San Jose IETF Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Minutes of the Audio/Video Transport Working Group Reported by Steve Casner 1. Introduction and status The AVT working group met for two sessions at the San Jose '96 IETF. AVT has produced the Real-time Transport Protocol, which was published in January 1996 as a Proposed Standard RFC 1889 along with the companion RTP profile for audio/video conferencing RFC 1890. The minimum interval before advancement to Draft Standard has now passed; during that time, RTP use has grown with additional independent implementations and a broader range of applications. Accordingly, at this meeting we discussed what changes to the spec may be required for advancement to Draft Standard. In particular, the biggest topic was RTCP scalability for very large sessions, especially with asymmetric or low data rate links. Also of significance for low-speed links was the second major topic of this meeting, an update on the IP/UDP/RTP header compression protocol. Since the last meeting, RFCs 2029, 2032, 2035 and 2038 defining the RTP payload formats for CellB, H.261, JPEG and MPEG video encodings were also published as Proposed Standards, in October 1996. In the second AVT session, a problem with RFC 2038 regarding packet loss resilience for MPEG2 was presented, as were RTP Payload Formats for Redundant Audio, H.728 audio and H.263 video. A status report on development of an RTP MIB was presented; this is a potential future work item for the group, along with completion of the changes for transition of the RTP spec to Draft Standard and standardization of additional profiles and payload formats. 2. RTCP scaling for large "broadcast" sessions Before this IETF meeting, there were several messages to the AVT mailing list regarding use of RTCP in very large "broadcast" scenarios, especially those where endpoints are connected by low-speed modems or asymmetric cable systems with low-speed uplinks. Bernard Aboba and Henning Schulzrinne gave presentations on the problems that arise along with a variety of possible solutions. The interval between RTCP packets increases with the group size so that RTCP consumes a constant fraction of the session bandwidth. This keeps RTP well behaved as it scales to large groups. However, there are scenarios for which the current spec is inadequate: - Because the initial RTCP report is sent within a fixed interval after joining the session independent of the group size, there can be a large bandwidth spike if many participants join at the same time, e.g., for a scheduled event. Convergence to the proper report interval may take too long, in particular for low-bandwidth sessions. - For sessions larger than a few thousand, the long RTCP interval may preclude collection of the desired information. - The memory required by the suggested RTCP interval calculation algorithm to track all the participant SSRC identifiers may be excessive for very large sessions. - For some types of sessions, privacy of reception may be more important than the feedback RTCP provides. - On low-speed modems, giving even 5% of the bandwidth to RTCP draws cries from the people who have to squeeze the data to fit. - Network operators are concerned about the multicast routing state required to track all the participants as multicast sources. Several potential solutions for these problems were presented and evolved in the discussion that followed: - The initial bandwidth spike can be avoided if the report interval is "reconsidered" before sending a report. That is, sending is delayed until the updated group size estimate at the end of the interval is not much larger than it was at the start. Group size estimation can also be accelerated by having each participant send the estimate it has counted, but use the maximum of all estimates received to calculate the interval. - Memory requirements may be reduced by storing only a sampling of the SSRC identifiers heard, based on a probability function. The probability can be scaled as needed to fit the group size. - The report interval can be reduced by having only some of the participants report, perhaps controlled by a sampling function from the sender, if partial feedback is appropriate. - Receiver RTCP reports could be sent via unicast to the sender or some monitor, or sent on a separate multicast address, but the report interval must be controlled by some external means since the receiver can't calculate the interval itself. There is a danger that if receivers allow some other entity to control their report rate and destination, this could be subverted to packet bomb some innocent party. - It is always safe (from a network load point of view) if receive-only participants do not send RTCP. This avoids several of the problems listed, but precludes feedback. The development of diagnostic tools such as mtrace makes RTCP less critical for network diagnosis than before. - Report bandwidth can be reduced by summarization of reports by selected receivers through self-organization using TTL scoping, or by RTP translators explicitly interposed in the distribution tree. This adds significant complication. Many good points were brought up in the discussion of these possible solutions: - Using a distributed consensus algorithm driven by multicast is robust because a single defector can't inflate the rate. - Encryption can be used for privacy, though this can add legal complications in some countries. - The current RTCP algorithm represents a design point that we believe works well for a wide range of applications and which has been tested in experiments on the MBone. But there may be changes needed to extend operation to highly asymmetric networks or other scenarios outside that range. Each of the potential solutions has some drawbacks, and there is not one solution that is the clear answer in all cases. Further experimentation is needed to test the proposed ideas. 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. These profiles might be specified in the description of a session, e.g., in SDP using "RTP/AVB" ("B" for broadcast) rather than "RTP/AVP". Proposals are solicited in the form of Internet Drafts defining additional profiles to be the subject of experimentation and then consideration for standardization. 3. IP/UDP/RTP header compression Steve Casner presented an update on the proposal developed with Van Jacobson for hop-by-hop compression of IP/UDP/RTP headers to allow use over low-speed lines. This proposal was introduced at the previous AVT meeting in Montreal. The update incorporates changes agreed in Montreal and subsequent improvements: - The context ID is always sent, and in the first byte to allow overlap with a link-level segmentation scheme when feasible. - The sequence number is increased to 4 bits and is changed to be context-specific rather than global. - A new delta encoding scheme was designed to fit the patterns encountered in typical RTP applications, replacing the temporary use of the scheme from RFC 1144 TCP/IP header compression. - RTP header compression is now integrated into the IPv6 header compression scheme (which also supports IPv4 and encapsulation in multiple headers). - It is now specified that RTCP packets will not be compressed, since the traffic fraction is small and the required increase in shared context would be impractical. Manoj Leelanivas presented a report on his implementation of the header compression algorithm and its performance. He emphasized that since the identification of which UDP streams carry RTP is only though heuristics, it is essential to have a negative cache for UDP streams that don't compress; otherwise, the context cache will thrash as each new packet may fail to match any existing context. The compression scheme performed as expected: most audio packet headers compressed to 2 bytes without UDP checksum or 4 with; most video packet headers compressed to 4 or 6 bytes. During discussion of the proposal, it was agreed that the delta encoding should be specified to be table driven, with the default table being as presented but with holes in the encoding space used to encode negative deltas that may occur with MPEG or out-of-order packets. Also, for use of header compression over higher-speed lines where there may be a larger number of contexts, either an 8- or 16-bit context ID should be allowed via negotiation. The working group agreed that this proposal should go to Last Call with these revisions in place. Steve Casner also made a short presentation in the PPPEXT working group meeting to coordinate the allocation of PPP packet types that will be required for this compression scheme. 4. Transport aspects of RTSP Proposal The Real-Time Streaming Protocol is under discussion primarily in the MMUSIC working group, but also has some transport aspects that were discussed briefly in AVT. The RTSP proposal has included a reduced-sized variant of RTP that was termed "compressed RTP". Since the AVT working group agreed in Montreal that the combined IP/UDP/RTP compression scheme described in the previous section should be standardized and that an end-to-end RTP-only compression scheme should not, the RTSP authors will extract the definition of RTP variant into a separate non-standards-track interim proposal named CUSH, for Compressed UDP Stream Header. In the main RTSP specification, the means of specifying the underlying stream transport protocol will be made more flexible to provide better separation between control and transport. 5. RTP payload formats The second AVT session covered topics beyond the main RTP spec, primarily additional payload formats plus some potential new application areas for RTP. 5.1 Redundant audio payload format Colin Perkins gave an update on draft-perkins-rtp-redundancy-01.txt which defines a mechanism for carrying redundant audio formats in RTP to compensate for packet loss. The redundant copy is usually more heavily compressed to reduce overhead. This updated draft includes modifications suggested at the Montreal meeting. Two interoperating implementations are in regular use. The working group agreed that this proposal should go to Last Call after a few minor edits. 5.2 Payload format for H.263 video Chad Zhu presented revisions to the payload format for H.263 video in draft-ietf-avt-rtp-payload-02.txt. These revisions reflect changes in the ITU H.263 spec in addition to suggested clarifications and other minor changes from the AVT group. One change, prompted by the development of H.263+, was to add a version number in the payload format. This change generated some discussion because it introduces another multiplexing point in the processing of each data packet. The group concluded that it would be preferable to design the payload format to accommodate the expected changes as well as possible, and then assign a new payload type if an incompatibility arises. The H.263 payload format spec should also be ready for Last Call after the version number is removed. 5.3 Problems with MPEG2 payload format The payload format spec for MPEG1 and MPEG2 was recently published as Proposed Standard RFC 2038. Reha Civanlar has identified a problem with this spec in that the packet loss resilience information is insufficient for MPEG2. He presented two recommendations for supplying the necessary information: - An optional second payload-specific header word would be added to carry the additional picture layer information required, and redundant sequence and GOP headers would be transmitted periodically as needed to achieve the desired loss probability. The overhead would be less than 1% for a 4 Mbps data rate assuming 2 sequence/GOP header retransmissions per second. - To reduce the redundancy overhead, the "high priority" header information could be sent using a "reliable" protocol prior to the main transmission of the video data using RTP. Since inclusion of the additional redundancy information in the payload header is optional, use of this method does not require changes to RTP. The group accepted the proposed extensions, and the chair asked Reha to write up the proposed change for inclusion into the MPEG payload format specification before its transition to Draft Standard. Reha also proposed an alternate format for bundled audio + video MPEG payload format described in draft-civanlar-bmpeg-00.txt. This format would give reduced overhead and better error resilience compared to the encapsulation defined in RFC 2038 for MPEG1 Systems or MPEG2 Transport streams. However, such improvements were considered in an early draft of RFC 2038 but were discarded because applications that have data in the Systems or Transport streams formats and can't afford the data handling required to take advantage of the benefits of separate audio and video Elementary streams also could not afford to use the more efficient bundled format. Reha's proposal is put forth for comparison testing and will be considered as an alternate format. 5.4 Payload format for G.728 audio Ofer Shapiro has submitted text to be added to the RTP Audio/Video Profile to describe the payload format for G.728 audio. No separate payload format spec is needed since only a few paragraphs are needed to describe the format. The four 10-bit vectors per audio frame are simply packed into 5 bytes, MSB first. Multiple frames may be packed into each packet. This format has been accepted by the ITU study group covering the use of RTP in H.323. 6. New applications of RTP Several proposals for new applications of RTP have been recently submitted to the working group. Two of them, a payload format for carrying HTTP over RTP in draft-aboba-rtp-http-01.txt, and a proposal for adding Scalable Reliable Multicast mechanisms to RTP, described in draft-parnes-rtp-ext-srm-01.txt, 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, but discussion of these proposals was deferred until organization of the reliable multicast research area is sorted out. 6.1 Using RTP with caching Two presentations on new applications were made at this meeting. The first was by Roger Kermode on the idea of layering audio and video streams in time as well as quality, then combining this layering with "proactive" caching to reduce latency and bandwidth requirements for on-demand playback. Multiple RTP streams (layers) from a particular video subject would be used for the different access phases implied by (near) on-demand access as well as for multiple quality levels as desired by different receivers. Receivers would combine multiple streams from caches and original sources with local storage to produce the desired quality of playback at the desired time. This work is at the research stage, but is likely to draw on RTP (possibly with SRM extensions), RTCP, RTSP and SDP as building blocks. 6.2 Aggregation Service within RTP The second presentation 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. Such gateways have recently been developed and deployed to allow long-distance telephone callers to dial a local gateway which then establishes an RTP stream to another gateway near the desired destination and instructs the remote gateway to dial the callee's telephone. There may be many parallel streams of small packets between these gateways; aggregating these streams into larger packets conserves header overhead without increasing delay as would be the case for large packets in a single stream. Jonathan presented various methods for assigning individual streams to logical channels in the aggregate and for carrying the information that must remain specific to each stream. The variations trade off efficiency and the extent to which interpretation of fields in the RTP header must change. Full details of the options and efficiency results are given in draft-rosenberg-itg-00.txt and .ps. Further work is needed before deciding whether some standardization should be undertaken. 7. Status report on RTP MIB Stan Naudus gave a status report on the development of an RTP MIB. While RTCP provides an efficient and scalable means to obtain feedback >from end systems in a multicast session, it does not provide third party management of unicast sessions such as in Internet Telephony. There may also be a need for additional remote control of RTP mixers and translators beyond what would be practical to implement with RTCP. The challenge in designing a MIB for RTP is to make it scalable over the wide variety of applications in which RTP might be used. The design currently includes 8 tables and 62 objects. Greg Minshall questioned whether 62 was too many objects for a practical MIB. The goal of the authors is to continue work on the MIB, including implementation testing to assess practicality, and submit it for AVT consideration at the next meeting in Memphis. 8. Advancing RTP to Draft Standard As noted in the introduction, it is time to advance the RTP spec, RFC 1889, and the RTP Profile, RFC 1890 to Draft Standard. Steve Casner presented a list of (potential) changes to be addressed for advancement: - changes for RTCP scaling as described earlier - rule changes proposed for layered encodings as described in draft-speer-avt-layered-video-01.txt - revision of the loop/collision algorithm for separate RTP and RTCP source port numbers - some clarifications of the wording and small changes such as allowing separate unicast ports that have already been made in the spec source files - allowing separate multicast addresses for RTP/RTCP These items are all straightforward or were previously discussed except for the last. Should the specification of an RTP session be generalized to allow different addresses to be used for RTP and RTCP? This would allow RTCP delivery to be constrained for improved scalability in some scenarios. After some discussion, the consensus of the group was that we should take the conservative approach and not make this change at this time. In addition to any required revisions of the RTP specification, advancing to Draft Standard requires evidence that interoperability requirements have been met. This should be easy to provide since there are several genetically distinct implementations of RTP, both research and commercial, in use. The exact form required for the evidence has not been determined by the Area Directors yet, but it is likely that an applicability document will be needed to list the areas in which RTP has been successfully used and the areas to which we believe it can be extended. We may also be required to document the scalability of RTP in a manner similar to that proposed by the Area Directors as a requirement for reliable multicast protocol proposals. 9. Advancing RTP Profile to Draft Standard Since the RTP Profile is a simpler document than the main RTP spec, there are fewer issues for its advancement. One question of significance is whether the Profile should restrict the format of the RTCP SDES CNAME item beyond the suggestions of the RTP spec so that separate implementations of audio and video tools will be more likely to use a common format. This commonality is important to allow audio and video streams to be associated for synchronization and other presentation management. The group agreed that the profile should recommend use of only the numeric address form of the CNAME. In addition to this change, there are several of the simple audio payload formats included in the Profile that need some additional details specified, such as bit and byte order for packing. Some additional formats, such as G.723 and G.728, will also be added. 10. Future work 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 Mon Jan 27 22:39:48 1997 Received: from julia.mlds.com by osi-west.es.net with ESnet SMTP (PP); Mon, 27 Jan 1997 19:38:46 -0800 Received: from ashleigh.gcast.com by julia.mlds.com (SMI-8.6/SMI-SVR4) id TAA02730; Mon, 27 Jan 1997 19:39:46 -0800 Message-Id: <2.2.32.19970128034300.00f6ccbc@julia.mlds.com> X-Sender: whetten@julia.mlds.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Jan 1997 19:43:00 -0800 To: Jon Crowcroft , "Todd L. Montgomery" From: Brian Whetten Subject: Re: Announcing an SRM implementation in C++ Cc: rem-conf@es.net, rmp-discuss@aurora.jhuapl.edu, rm@mash.CS.Berkeley.EDU, floyd@ee.lbl.gov, mccanne@cs.berkeley.edu, gcast_all@gcast.com These are things we are working to help fix, through whatever contributions we can. Our SRM implementation (which we would again like to reiterate does not necessarily have fidelity to the original intentions of the SRM authors) has provided a solution for per-source ordering. The framework we have provided can be adapted for selective unreliability, and an instance of this, which we call source/time ordering (per-source ordering, with a time bound) will be released shortly. Congestion control for _all_ reliable multicast protocols is still a very active research area, and while we have proposed two solutions (one in RMP, and one in SRM), we are working hard in this area as well, and will be releasing new WAN congestion control algorithms soon as well. You are right...let's switch this discussion over to the rm mailing list, and see if we can get some traffic going there. Brian At 11:23 PM 1/27/97 +0000, Jon Crowcroft wrote: > > >hmmmm..... > >but srm never addressed 3 key quesions of (reli)able multicast > >0 selective unreliability >1/ congestion >2/ per source ordering > >i think this should continue on the rm list only. excet that the only >active discussion to date there has been rmfp........ > >how long is it since the ietf announcement of the rm list/group? > >.....hmmm.... i spose everyone is too busy writing sigcomm papers:-) > >jon > > Brian Whetten 3777 Depot, Suite 415 President, GlobalCast Communications Hayward, CA 94545 whetten@gcast.com (510) 266-0400 FAX 266-0401 From rem-conf-request@es.net Tue Jan 28 00:39:08 1997 Received: from gorf (actually gorf.Stanford.EDU) by osi-west.es.net with ESnet SMTP (PP); Mon, 27 Jan 1997 21:38:14 -0800 Received: from vxtreme.com by gorf (931110.SGI/inc-1.0) id AA25115; Mon, 27 Jan 97 21:35:05 -0800 Received: from zima_gold by uncola via ESMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id VAA07803; Mon, 27 Jan 1997 21:37:09 -0800 Message-Id: <32ED90F0.7FE1@vxtreme.com> Date: Mon, 27 Jan 1997 21:38:56 -0800 From: Anders Klemets Organization: VXtreme, Inc. X-Sender: Anders Klemets X-Mailer: Mozilla 4.0b1 (WinNT; I) Mime-Version: 1.0 To: Stephen Casner Cc: rem-conf@es.net Subject: Re: Minutes for AVT WG at San Jose IETF X-Priority: Normal References: Content-Type: multipart/alternative; boundary="----------54FC1E5610BA2" ------------54FC1E5610BA2 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > The group agreed that the profile should > recommend use of only the numeric address form of the CNAME. I don't recall that we actually agreed on that. But in any case, only having the numeric address form in the CNAME, and nothing else, is not such a good idea. If you have two applications running on the same machine that try to talk to each other, the RTP loop detection function may think that an RTP loop has occurred. Some of the RTP implementations that are available today might avoid false RTP loop detection by checking the source IP address and port number. But that is not a very nice hack, since RTP is supposed to be independent of the underlying protocol. Anders P.S. Sorry for sending HTML'fied stuff to the list, that's a feature of my mail program, and it cannot be turned off. ------------54FC1E5610BA2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
> The group agreed that the profile should
> recommend use of only the numeric address form of the CNAME.

I don't recall that we actually agreed on that.  But in any case, only having the
numeric address form in the CNAME, and nothing else, is not such a good idea.
If you have two applications running on the same machine that try to talk to each
other, the RTP loop detection function may think that an RTP loop has occurred.
 
Some of the RTP implementations that are available today might avoid false
RTP loop detection by checking the source IP address and port number.
But that is not a very nice hack, since RTP is supposed to be independent of the
underlying protocol.
 
Anders
 
P.S.  Sorry for sending HTML'fied stuff to the list, that's a feature of my 
mail program, and it cannot be turned off.
 
------------54FC1E5610BA2-- From rem-conf-request@es.net Tue Jan 28 02:02:51 1997 Received: from willy.cra.enel.it by osi-west.es.net with ESnet SMTP (PP); Mon, 27 Jan 1997 23:02:09 -0800 Received: from wind (wind.cra.enel.it [158.47.122.44]) by willy.cra.enel.it (Netscape Mail Server v2.0) with ESMTP id AAA9758 for ; Tue, 28 Jan 1997 08:02:04 +0100 From: Mauro Redini To: rem-conf Subject: unsubscribe Date: Tue, 28 Jan 1997 08:12:53 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <19970128070204.AAA9758@wind.cra.enel.it> unsubscribe From rem-conf-request@es.net Tue Jan 28 07:58:31 1997 Received: from nlanr.net (actually oceana.sdsc.edu) by osi-west.es.net with ESnet SMTP (PP); Tue, 28 Jan 1997 04:57:48 -0800 Received: (from kc@localhost) by nlanr.net (8.7.3/8.7.3) id EAA21895; Tue, 28 Jan 1997 04:57:48 -0800 (PST) From: k claffy Message-Id: <199701281257.EAA21895@nlanr.net> Subject: announce broadcast of apricot conference 28-29th jan 97 To: rem-conf@es.net Date: Tue, 28 Jan 1997 04:57:47 -0800 (PST) Cc: evi@xor.com (evi n) X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Content-Type: text what: APRICOT [asian pacific rim Internet conference on operational techniques] where: from hong kong, excelsior hotel who: apricot and APNIC and commercial sponsors when: 28-29th jan 97 [29-30th in .hk] program details: http://202.77.253.68/program.html source host: 166.222.30.4 check sdr for advertisement note there are three tracks and only one mbone channel. so from the program at the URL above, we will try to broadcast track 2 in real time and then try to rebroadcast tapes of track 3 and then track 1 during the .hk off hours track hk time US PST time GMT 2 0830-1700 1730-0200 0130-1000 3 1700-2300 0200-0800 1000-1600 1 2300-0500 0800-1400 1600-2400 [not that we have any legitimate reason to belive that any of this will work anyway, so advise to add grains of salt to the hour glass] k send complaints to kc@nlanr.net or evi@cs.colorado.edu From rem-conf-request@es.net Tue Jan 28 08:04:42 1997 Received: from alpes.eurecom.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 28 Jan 1997 05:03:55 -0800 Received: from rosa.eurecom.fr (erbi@rosa.eurecom.fr [193.55.114.19]) by alpes.eurecom.fr (8.7.4/8.7.3) with SMTP id OAA12837; Tue, 28 Jan 1997 14:04:07 +0100 (MET) Date: Tue, 28 Jan 1997 14:04:07 +0100 (MET) From: Biersack Ernst Message-Id: <199701281304.OAA12837@alpes.eurecom.fr> To: rem-conf@es.net Subject: SIGCOMM 97 submission deadline is coming up Cc: erbi@alpes.eurecom.fr Dear colleagues, Its time to hurry up! The deadline for submission to SIGCOMM 97 is Jan 31st, i.e. the end of this week. Yours, \Ernst Biersack (Sigcomm Publicity Chair) The next ACM SIGCOMM will be in September 1997 at the Palais des Festivals in Cannes, France. Tutorials, September 14-15, 1997 Conference, September 16-18, 1997 The deadlines are: Paper submissions: 31 January 1997 Tutorial proposals: 31 January 1997 Notification of acceptance: 28 April 1997 Camera-ready paper due: 30 May 1997 For more details, please see: http://www.inria.fr/rodeo/sigcomm97/ From rem-conf-request@es.net Tue Jan 28 15:49:34 1997 Received: from zoom.bga.com (actually zoom.realtime.net) by osi-west.es.net with ESnet SMTP (PP); Tue, 28 Jan 1997 12:48:52 -0800 Received: from kewxp.hire.com (hire253.hire.com [204.96.177.253]) by zoom.bga.com (8.6.12/8.6.12) with SMTP id OAA08053; Tue, 28 Jan 1997 14:48:49 -0600 Message-ID: <32EE65F2.7934@technologists.com> Date: Tue, 28 Jan 1997 14:47:47 -0600 From: Charlie Sauer X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 Newsgroups: comp.dcom.videoconf CC: rem-conf@es.net, videophone@es.net Subject: book availability announcement: Duran/Sauer, Mainstream Videoconferencing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mainstream Videoconferencing: A Developer's Guide to Distance Multimedia, by Joe Duran and myself, is now available. For more information, see http://www.aw.com/cp/duran-sauer.html. That location includes table of contents, preface, first chapter and an appendix of web resources. Charlie From rem-conf-request@es.net Tue Jan 28 20:45:22 1997 Received: from mail.arc.nasa.gov (actually nick.arc.nasa.gov) by osi-west.es.net with ESnet SMTP (PP); Tue, 28 Jan 1997 17:44:51 -0800 Received: from [128.102.80.28] by mail.arc.nasa.gov (8.7.6/1.35) id RAA11644; Tue, 28 Jan 1997 17:42:36 -0800 (PST) Date: Tue, 28 Jan 1997 17:42:36 -0800 (PST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: mallard@mail.arc.nasa.gov (Mark Allard) Subject: NASA-Remote University Course The second in a series of Remote University Courses in Telerobotics will be broadcast on the MBone Wednesday, February 29, 1997 from 2PM-7PM. Contact Mark Allard for more information or go to for additional details on the course. This course material is being provided as a service to the MBone community by NASA-Ames Research Center. From rem-conf-request@es.net Wed Jan 29 03:54:31 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 29 Jan 1997 00:53:51 -0800 Received: from little-bear.precept.com by precept.com (SMI-8.6/SMI-SVR4) id AAA09019; Wed, 29 Jan 1997 00:53:12 -0800 Date: Wed, 29 Jan 1997 00:53:11 -0800 (PST) From: Stephen Casner To: Anders Klemets , Henning Schulzrinne cc: rem-conf@es.net Subject: Re: CNAME In-Reply-To: <32EDF7B0.6445@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Anders and Henning, Anders> > The group agreed that the profile should Anders> > recommend use of only the numeric address form of the CNAME. Anders> Anders> I don't recall that we actually agreed on that. We can certainly discuss this topic further here on this list. My recollection of the discussion was that Colin Perkins agreed that RAT should change to use the numeric form, and that there there were a couple of other speakers in favor but no strong objections voiced. This topic was near the end of the meeting, and there was not a lot of discussion on any side. Henning> I figured there must have been a straw poll of some sort with Henning> unanimous agreement. Well, consensus process is a rough one. On this topic, I don't recall asking for raising of hands on both sides, but I think I asked if there was general agreement and got some hums but no shouts. (A WG chair also often looks out on a relatively large number of blank stares as well, which is one of the harder aspects of the job.) As I say, I would be happy to hear more input. Anders> But in any case, only having the numeric address form in the Anders> CNAME, and nothing else, is not such a good idea. If you have Anders> two applications running on the same machine that try to talk Anders> to each other, the RTP loop detection function may think that Anders> an RTP loop has occurred. Sorry, I did not mean to imply that the "user@address" form would be replaced with the "address" only form, only that the two address forms would be recommended over the FQDN forms. Anders> Some of the RTP implementations that are available today might Anders> avoid false RTP loop detection by checking the source IP Anders> address and port number. But that is not a very nice hack, Anders> since RTP is supposed to be independent of the underlying Anders> protocol. I believe one must use the IP address and port in the collision/loop detection algorithm, and that the CNAME turns out to provide only marginal information. Since I wrote the collision/loop detection algorithm as it currently appears in the spec, that's what it says. I Henning and I have had some debate about this, but I firmly believe it. I can go back and dig up that debate if needed. I invite folks to take another look at the algorithm, but note that the following section: IF the source transport address is found in the list of conflicting addresses: THEN IF the source identifier is not from an RTCP SDES chunk containing a CNAME item OR if that CNAME is the participant's own: THEN (optionally) count occurrence of own traffic looped. mark current time in conflicting address list entry. ABORT processing of data packet or control element. the "ABORT" should be move out one indentation level, i.e., it is always done in the first THEN clause independent of the second IF. There are two points I'd like to make on the use of source IP addresses and ports: 1. Doing this check does not strictly make RTP dependent upon the lower layer protocol. The IP addresses and ports are opaque to the algorithm; it only checks for equality. Well, we do depend upon there being a source address. 2. The original source address is lost for packets that go through a translator, but that translator is also responsible for performing the collision/loop detection with the original source info. Henning> I was also surprised by "agreed", given all the unresolved Henning> issues (Net10 replication, IPv4/IPv6, debuggability, which Henning> interface to pick and how to get all interfaces, etc.) Net10 is indeed a cause for concern. Unfortunately, the places where Net10 is used are often the ones that don't provide sufficient information to obtain an FQDN either, since those hosts don't need to be known outside the firewall. To the extent that UUID's depend upon addresses, they don't help, either (and temporal uniqueness is a problem for matching tools that don't start at the same exact instant). I think IPv4/IPv6 and interface choice are much less significant issues (less likely to cause trouble). I'm not sure what the debuggability issue is. I've been exchanging messages with Dermot Tynan who works on the AltaVista Firewall. He suggests that firewalls may be required to rewrite CNAMEs to hide internal information. If this will be the case, and if we can devise a common translation rule (that keeps uniqueness of the machine identities), that may solve the Net10 problem. Henning> It might also be worth looking into what if any effect the 8/8 IPv6 Henning> addressing proposal might have, where the address prefix might change Henning> during a session. That may not be a problem if we only need to coordinate tools that start at the same time. The CNAME does not need to change when the prefix changes. I guess I'll burn this bridge when I come to it. -- Steve From rem-conf-request@es.net Wed Jan 29 04:14:08 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 29 Jan 1997 01:13:16 -0800 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 29 Jan 1997 09:13:07 +0000 To: Charlie Sauer cc: rem-conf@es.net, videophone@es.net Subject: Re: book availability announcement: Duran/Sauer, Mainstream Videoconferencing In-reply-to: Your message of "Tue, 28 Jan 1997 14:47:47 CST." <32EE65F2.7934@technologists.com> Date: Wed, 29 Jan 1997 09:13:05 +0000 Message-ID: <1046.854529185@cs.ucl.ac.uk> From: Jon Crowcroft >Mainstream Videoconferencing: A Developer's Guide to Distance >Multimedia, by Joe Duran and myself, is now available. Charlie looks good meanwhile, our internet multimedia book is at http://www.cs.ucl.ac.uk/staff/jon/mmbook/book/book.html feel free to browse/download/comment.... its mostly mbone/rsvp/rtp technology type book...... to be published soonsh.... jon From rem-conf-request@es.net Wed Jan 29 06:47:02 1997 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 29 Jan 1997 03:45:27 -0800 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 29 Jan 1997 11:44:22 +0000 To: Stephen Casner cc: Anders Klemets , Henning Schulzrinne , rem-conf@es.net Subject: Re: CNAME In-reply-to: Your message of "Wed, 29 Jan 1997 00:53:11 PST." Date: Wed, 29 Jan 1997 11:44:21 +0000 Message-ID: <970.854538261@cs.ucl.ac.uk> From: Colin Perkins --> Stephen Casner writes: >Anders> > The group agreed that the profile should >Anders> > recommend use of only the numeric address form of the CNAME. >Anders> >Anders> I don't recall that we actually agreed on that. > >We can certainly discuss this topic further here on this list. My >recollection of the discussion was that Colin Perkins agreed that RAT >should change to use the numeric form, and that there there were a >couple of other speakers in favor but no strong objections voiced. >This topic was near the end of the meeting, and there was not a lot of >discussion on any side. I made the change to RAT, starting with RAT-3.0.8 (we hope to have a general release of RAT-3.0.x relatively soon). It seems that allowing two different, but equivalent, forms for a CNAME is unnecessary, and can only serve to cause confusion. Given that, in some cases, it's not possible to determine the FQDN it seems sensible to mandate the user@dotted-quad form of CNAME in the a/v profile. Henning> I was also surprised by "agreed", given all the unresolved Henning> issues (Net10 replication, IPv4/IPv6, debuggability, which Henning> interface to pick and how to get all interfaces, etc.) These other issues seem much more serious: my particular concern being the choice of interface for multi-homed hosts (since I'm currently working on an audio transcoder/mixer). Colin From rem-conf-request@es.net Wed Jan 29 10:08:11 1997 Received: from rzdspc1.informatik.uni-hamburg.de by osi-west.es.net with ESnet SMTP (PP); Wed, 29 Jan 1997 07:07:30 -0800 Received: from ro2.informatik.uni-hamburg.de (ro2.informatik.uni-hamburg.de [134.100.15.162]) by rzdspc1.informatik.uni-hamburg.de (8.8.5/8.8.5) with SMTP id QAA22037 for ; Wed, 29 Jan 1997 16:07:27 +0100 (MET) Received: from ro4.informatik.uni-hamburg.de by ro2.informatik.uni-hamburg.de (4.1/SMI-4.1/RZ-1.04/s) with SMTP id ; Wed, 29 Jan 97 16:08:02 +0100 From: richter@ro2.informatik.uni-hamburg.de (Jan-Peter Richter) Message-Id: <9701291508.AA09758@ro2.informatik.uni-hamburg.de> Subject: ext. deadline Feb 10. ANMT/QoS Modeling Conference To: rem-conf@es.net Date: Wed, 29 Jan 1997 16:07:25 +0100 (MET) X-Mailer: ELM [version 2.4 PL25] Content-Type: text Please notice that the deadline for the ANMT/ QoS Modelling Conference to be held in Singapore, September 1-4, has been extended to >>> Feb. 10 <<< Jan-Peter Richter ---------------------------------------------------------------------------- Call for Papers 4th International Conference on Analytical and Numerical Modelling Techniques with the application to QUALITY OF SERVICE (QoS) MODELLING Singapore, September 1-4, 1997 The submission of papers is solicited for the "4th Analytical and Numerical Modelling Techniques Conference" on QUALITY OF SERVICE (QoS) MODELLING which is organized by SCS as part of the 1st World Congress on Systems Simulation. Technical Background: -------------------- Recently, the concept of Quality of Service (QoS) has attracted a lot of attention in research and development of high speed computer and communication networks with multimedia applications. Real-time and other qualities such as guaranteed performance and dependability are vital properties of offered services to be provided by future communication networks. Contractual relationships between service user and service provider regarding prospective services and their required qualities have to be realized. Guarantees should be given even in the presence of stochastic uncertainties. Network components may fail, transmission errors cannot be totally avoided, or temporary overload conditions are likely to occur due to incorporated multiplexing techniques in the usage of system resources. Quantitative modeling represents a promising approach to appropriately support system design and dynamic management. Accurate projections of computer and communication systems' behavior are needed. The first challenge for QoS modeling comes from the fact that timeliness, performance, and dependability properties are equally vital issues for the applications. The second challenge is due to the peculiar novelty that application and customer specific metrics rather than system related ones are of major interest. As a third challenge it becomes increasingly important that QoS support is provided in heterogeneous environments. Original papers which have not been published and which deal with QoS related quantitative modeling topics are solicited for submission. The conference focus is on modeling techniques and tools as well as on evaluation studies relevant to the theme. QoS modeling combined with practical implementation experience is of predominant interest. The following is an incomplete list of topics relevant to the conference: - QoS modeling techniques and tools for evaluation of multimedia services in high speed networks - QoS management - QoS specification - QoS mapping - QoS negotiation and admission control - QoS modeling and evaluation case studies - QoS modeling and practical implementation experience - QoS support in heterogeneous environments - User oriented QoS modeling - Neurocomputing and cognitive modeling for QoS support - Real-time services - Adaptive and reconfigurable systems - Responsive systems modeling - Dependability evaluation - Performability modeling - Stochastic Petri net models - Queueing systems - Markov models - Simulation studies - Measurement techniques and studies ------------------------------------------------------------------------ ------------------------------------------------------------------------ Conference Chair: ---------------- Gunter Bolch Department of Computer Science - OS, University Erlangen-Nuremberg Martensstrasse 1, D-91058 Erlangen, Germany bolch@informatik.uni-erlangen.de Tel.: +49 9131 85-7903, Fax: +49 9131 39388 Program Chair: -------------- Hermann de Meer Department of Computer Science - TKRN, University of Hamburg Vogt-Koelln-Strasse 30, D-22527, Hamburg, Germany demeer@informatik.uni-hamburg.de Tel: +49 40 5494-2347, Fax: +49 40 5494-2328 Program Committee: ----------------- Andres Albanese, International Computer Science Institute at Berkeley, USA Gordon Blair, Lancaster Univ., UK Andrew Campbell, Columbia Univ., USA Mario Dal Cin, Erlangen Univ., Germany Petre Dini, Univ. de Montreal, Canada Winfried Dulz, Erlangen Univ., Germany Pankaj Garg, Hewlett Packard Lab. at Palo Alto, USA Stefan Greiner, Erlangen Univ., Germany Roch Guerin, IBM T.J. Watson Research Center, USA Abdelhakim Hafid, Univ. de Montreal, Canada Guenter Haring, Univ. of Vienna, Austria Boudewijn Haverkort, Aachen Univ., Germany Ulrich Herzog, Erlangen Univ., Germany Gardeep Hura, Nanyang Technological University, Singapore Klaus Irmscher, Bergakademie Freiberg, Germany Werner Jarschel, Siemens AG Erlangen, Germany Yoshiaki Kakuda, Osaka Univ., Japan David Kirsh, Univ. of California at San Diego, USA Edward Knightly, Rice Univ., USA Udo Krieger, Deutsche Telekom AG Darmstadt, Germany Jorg Liebeherr, University of Virginia, USA Dimitris Logothetis, Lucent Technologies, USA Miroslaw Malek, Humboldt Univ. Berlin, Germany Jan de Meer, GMD-Fokus Berlin, Germany Bruno Mueller-Clostermann, Essen Univ., Germany Jogesh Muppala, Hong Kong University of Science and Technology, Hong Kong Klara Nahrstedt, University of Illinois at Urbana-Champaign, USA Victor Nicola, Univ. of Twente, The Netherlands Giovanni Pacifici, IBM T.J. Watson Research Center, USA Antonio Puliafito, Universita di Catania, Italy Jan-Peter Richter, Univ. of Hamburg, Germany Miklos Telek, Budapest Univ., Hungary Don Towsley, Univ. of Massachusetts at Amherst, USA Satish Tripathi, Univ. of Maryland, USA Kishor Trivedi, Duke University, USA Andreas Vogel, Univ. of Queensland, Australia Sandy Wang, Stratacom at Palo Alto, USA Weiguo Wang, ISS, National University of Singapore, Singapore Bernd Wolfinger, Univ. of Hamburg, Germany Martina Zitterbart, Braunschweig Univ., Germany Deadlines: --------- Paper Submission (extended deadline): Feb. 10, 1997 Notification of Acceptance: April 1, 1997 Camera Ready Copy: May 15, 1997 Submission Policy: ----------------- The submission of SIX COPIES of double-spaced full manuscripts is solicited. The length of double-spaced papers should not exceed 15 PAGES, including figures and references. The camera ready copy will be required to be in double column format, not exceeding five pages of length. The papers should be sent to: Office of the 1st WORLD CONGRESS ON SYSTEMS SIMULATION ANMT: QoS Modeling Attention: Mr. Jonnovan Hong c/o IEEE Singapore Section 59D Science Park Drive, The Fleming Singapore 118243 Republic of Singapore Tel: +65 773 1141 Fax: +65 773 1142 ieeesgp@pacific.net.sg ATTENTION! Please help to speed up the reviewing process and submit also a POSTSCRIPT version of your paper by EMAIL to the program chair: demeer@informatik.uni-hamburg.de Publication Policy: ------------------ All submitted papers will be reviewed by at least four members of the international program committee. Accepted papers will be published in the IEEE Computer Society and SCS-Europe Publishing House proceedings. Exhibitions and Tutorials: ------------------------- Exhibitions, tutorials, and vendor sessions are also solicited for presentation. If interested, please contact the appropriate conference or program chair person. Organization: ------------ Organized and sponsored by: SCS The Society for Computer Simulation International National University of Singapore Nanyang Technical University, Singapore University Erlangen-Nuremberg, Germany University of Ottawa, Canada Participating Societies: ASIM, CASS, CSSS, FRANKOSIM, HSS, IEEE Singapore, ISCS, JSST, KSS, SCS Europe, SCS International, SiE, SIMS, UKSS, NUS, NTU From rem-conf-request@es.net Wed Jan 29 11:15:54 1997 Received: from icarus.lis.pitt.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 29 Jan 1997 08:15:14 -0800 Received: by icarus.lis.pitt.edu (4.1/1.34) id AA18823; Wed, 29 Jan 97 11:15:30 EST Received: from finch.lis.pitt.edu(136.142.116.21) by icarus.lis.pitt.edu via smap (V1.3) id sma018782; Wed Jan 29 11:15:09 1997 Received: by finch.lis.pitt.edu (4.1/1.34) id AA03156; Wed, 29 Jan 97 11:14:59 EST Date: Wed, 29 Jan 1997 11:14:55 -0500 (EST) From: Wendy Fleming Subject: Re: book availability announcement: Duran/Sauer, Mainstream Videoconferencing To: Jon Crowcroft Cc: Charlie Sauer , rem-conf@es.net, videophone@es.net In-Reply-To: <1046.854529185@cs.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe From rem-conf-request@es.net Wed Jan 29 17:31:26 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 29 Jan 1997 14:29:04 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id OAA10731; Wed, 29 Jan 1997 14:06:01 -0800 Date: Wed, 29 Jan 1997 14:08:04 -0800 () From: Stephen Casner To: Colin Perkins cc: Anders Klemets , Henning Schulzrinne , rem-conf@es.net Subject: Re: CNAME In-Reply-To: <970.854538261@cs.ucl.ac.uk> Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > These other issues seem much more serious: my particular concern being the > choice of interface for multi-homed hosts (since I'm currently working on > an audio transcoder/mixer). If there is a conventional way to get one of the addresses, we don't care which one it is for the CNAME. We just want all the tools to get the same one. -- Steve From rem-conf-request@es.net Wed Jan 29 18:11:29 1997 Received: from cheerios.cisco.com by osi-west.es.net with ESnet SMTP (PP); Wed, 29 Jan 1997 15:10:36 -0800 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id PAA18165 for ; Wed, 29 Jan 1997 15:10:29 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Jan 1997 15:10:28 -0800 To: rem-conf@es.net From: Steve Deering Subject: MBone teleconf tools for Macs? Has anyone ported any of the MBone teleconferencing tools to the Macintosh yet? Apple has their MBone TV app which is a partial implementation of some of the capabilities in the Unix MBone suite, all nicely integrated with Apple's QuickTime architecture. I'm sure it will be fabulous when (if) they finish it, but for now it is only good for passive reception of MBone audio and video using some subset of the common encodings -- it doesn't support transmission of audio, so it's not yet useable for teleconferencing with vat users. Some folks at UCLA began an implementation (USeeLA), but according to their web page, they decided to stop development since Apple was already doing it. Too bad. CUSeeMe, of course, supports teleconferencing on Macs, but as far as I know it does not interoperate with the MBone RTP-based tools. I am particularly interested in Mac versions of sdr and vat, or interoperable equivalents. wb would also be great, as an adjunct to the first two. vic is much lower priority for me, though it seems that implementors always want to do the flashy video stuff first. Freeware or payware, either will do. I'm willing to be a tester for pre-release implementations. Just tell me I don't have to buy a PeeCee! Steve From rem-conf-request@es.net Wed Jan 29 20:51:30 1997 Received: from MVS.OAC.UCLA.EDU by osi-west.es.net with ESnet SMTP (PP); Wed, 29 Jan 1997 17:50:26 -0800 Received: from UCLAMVS.BITNET by MVS.OAC.UCLA.EDU (IBM MVS SMTP V2R2.1) with BSMTP id 4023; Wed, 29 Jan 97 17:50:29 PST Date: Wed, 29 Jan 97 17:49 PST To: Steve Deering From: Denis DeLaRoca Subject: Re: MBone teleconf tools for Macs? CC: rem-conf@ES.NET On Wed, 29 Jan 1997 15:10:28 -0800, Steve Deering said: > Has anyone ported any of the MBone teleconferencing tools to the > Macintosh yet? I am afraid the answer is no! Apple's Mbone TV stuff is way too limited and in practice not very useful... UCLA's UseeLA is long dead and didn't get too far. CUSeeMe's latest version, at least their Windows version, is multicast aware, but I don't know to whet extent it interoperates with the MBONE tools -- the White Pine people came to the IP Multicast summit. The UCL people also looked at doing MBONE tools for the MAC but gave up as well... Apple sort of said they would solve the problem but so far we have no decent tools yet. So maybe the only reasonable option is to get yourself an Intel notebook and run Windows or some- thing like FreeBSD or Linux. There's now TCL/TK for the Macintosh, and Apple's Open Transport does support multicasting. So I think the framework to port vat, vic and sdr to the Macintosh is there, pretty much like it was done for Windows '95 -- the audio and video programming is all done thru Quicktime. Let's hope someone else can give us better news. :-( -- Denis From rem-conf-request@es.net Wed Jan 29 21:53:58 1997 Received: from ness.arch.usyd.EDU.AU (actually ness.arch.su.EDU.AU) by osi-west.es.net with ESnet SMTP (PP); Wed, 29 Jan 1997 18:51:52 -0800 Received: from archsci (archsci-server [129.78.66.193]) by ness.arch.usyd.EDU.AU (8.7.5/8.7.3) with ESMTP id NAA11544 for ; Thu, 30 Jan 1997 13:51:44 +1100 (EST) Received: from duich (duich.arch.su.EDU.AU [129.78.66.251]) by archsci (8.7.5/8.6.12) with SMTP id NAA10402 for ; Thu, 30 Jan 1997 13:51:42 +1100 (EST) Date: Thu, 30 Jan 1997 13:46:29 +1100 (EST) From: Anna Cicognani X-Sender: anna@duich To: rem-conf@es.net Subject: Calendar In-Reply-To: <199701300244.NAA11435@ness.arch.usyd.EDU.AU> Message-ID: URL: http://www.arch.usyd.EDU.AU/~anna MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I noticed that an announcment i made a while ago, has disappeared from the sdr calendar (when I open my suite). Is that possible? Do they have a TTL too....? From rem-conf-request@es.net Wed Jan 29 22:16:59 1997 Received: from matilda.wpine.com by osi-west.es.net with ESnet SMTP (PP); Wed, 29 Jan 1997 19:16:04 -0800 Received: from daveb200.wpine.com ([192.80.72.189]) by matilda.wpine.com (post.office MTA v2.0 0813 ID# 0-13495) with SMTP id AAA750; Wed, 29 Jan 1997 22:14:10 -0500 Message-Id: <2.2.32.19970130032200.0074bcac@matilda.wpine.com> X-Sender: dob@matilda.wpine.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Jan 1997 22:22:00 -0500 To: Denis DeLaRoca From: daveb@wpine.com (David Bundy) Subject: Re: MBone teleconf tools for Macs? Cc: Steve Deering , rem-conf@ES.NET Hello folks, We are working on such interopability in our upcoming 3.0, 3.1 releases for Mac and Windows of CU-SeeMe client and reflector (eg. MBONE TOOLS, RTP, H.323). I do not have a date on this I can legally give you but we have stated publicly we will have it this year. Our current 2.1.1 Windows release follows the SDR and Mutlicast standards but didn't get the RTP and Mbone Codecs. Dave B. At 05:49 PM 1/29/97 PST, Denis DeLaRoca wrote: >On Wed, 29 Jan 1997 15:10:28 -0800, > Steve Deering said: >> Has anyone ported any of the MBone teleconferencing tools to the >> Macintosh yet? > >I am afraid the answer is no! Apple's Mbone TV stuff is way too limited >and in practice not very useful... UCLA's UseeLA is long dead and didn't >get too far. CUSeeMe's latest version, at least their Windows version, >is multicast aware, but I don't know to whet extent it interoperates >with the MBONE tools -- the White Pine people came to the IP Multicast >summit. The UCL people also looked at doing MBONE tools for the MAC >but gave up as well... Apple sort of said they would solve the problem >but so far we have no decent tools yet. So maybe the only reasonable >option is to get yourself an Intel notebook and run Windows or some- >thing like FreeBSD or Linux. > >There's now TCL/TK for the Macintosh, and Apple's Open Transport does >support multicasting. So I think the framework to port vat, vic and sdr >to the Macintosh is there, pretty much like it was done for Windows '95 >-- the audio and video programming is all done thru Quicktime. > >Let's hope someone else can give us better news. :-( > >-- Denis > > David O. Bundy VP Engineering White Pine Software LOOK WE MOVED! 542 Amherst St Nashua NH, 03063 =============== dbundy@wpine.com http://www.wpine.com/~dob Phone: 603-886-9050 Fax: 603-886-9051 From rem-conf-request@es.net Thu Jan 30 04:52:45 1997 Received: from nz11.rz.uni-karlsruhe.de by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 01:52:08 -0800 Received: from rpksf2.mach.uni-karlsruhe.de.mach.uni-karlsruhe.de (actually rpksf2.mach.uni-karlsruhe.de) by nz11.rz.uni-karlsruhe.de with SMTP (PP); Thu, 30 Jan 1997 10:52:01 +0100 Received: by rpksf2.mach.uni-karlsruhe.de.mach.uni-karlsruhe.de (5.65/Ultrix3.0-C) id AA09419; Thu, 30 Jan 1997 10:49:20 GMT From: pocsai@rpksf2.mach.uni-karlsruhe.de (Zsolt Pocsai ) Message-Id: <9701301049.AA09419@rpksf2.mach.uni-karlsruhe.de.mach.uni-karlsruhe.de> Subject: unsubscribe To: rp-ml@bart.lpt.fi Date: Thu, 30 Jan 1997 10:49:19 +0000 (GMT) Cc: rem-conf@es.net Reply-To: pocsai@rpksf2.mach.uni-karlsruhe.de X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 43 unsubscribe pocsai@rpk.uni-karlsruhe.de From rem-conf-request@es.net Thu Jan 30 05:25:18 1997 Received: from tel1.tte.vtt.fi by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 02:24:43 -0800 Received: from tte2049.tte.vtt.fi (tte2049.tte.vtt.fi [130.188.12.149]) by tel1.tte.vtt.fi (8.8.5/8.8.5) with SMTP id MAA08585; Thu, 30 Jan 1997 12:23:47 +0200 (EET) Message-Id: <3.0.32.19970130120645.006de6cc@tel1.tte.vtt.fi> X-Sender: lucenius@tel1.tte.vtt.fi X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 30 Jan 1997 12:25:40 +0200 To: Steve Deering , rem-conf@es.net From: Jan Lucenius Subject: Re: MBone teleconf tools for Macs? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 15:10 29.1.1997 -0800, Steve Deering wrote: > >CUSeeMe, of course, supports teleconferencing on Macs, but as far as I >know it does not interoperate with the MBone RTP-based tools. > According to answers that I got last spring about CuSeeMe, it is able to communicate with NV through a reflector. (Do not remeber whether it supports Mbone and not either about vat/vic/sdr compatibility.) CuSeeMe does not itself support RTP itself. I also remind that I have seen some notice that some of the Mac products should cooperate with Microsoft's Net Meeting in the future - not sure if it was CuSeeMe ? It also seems like NetPhone would be NV compatible, but that's only audio. I think one of the best summaries , where to start finding out about existing products is http://www3.ncsu.edu/dox/video/products.html . > Just tell me I don't have to buy a PeeCee! My feeling is also that Macintosh would be at least as good if not better platform for audio and video I also think that you should use it, if its possible. Write what you find out. Jan From rem-conf-request@es.net Thu Jan 30 08:39:52 1997 Received: from maelstrom.CC.McGill.CA by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 05:38:17 -0800 Received: (from yves@localhost) by maelstrom.CC.McGill.CA (8.7.1/8.6.10) id IAA03310; Thu, 30 Jan 1997 08:38:04 -0500 (EST) Date: Thu, 30 Jan 1997 08:38:04 -0500 (EST) From: Yves Lepage Message-Id: <199701301338.IAA03310@maelstrom.CC.McGill.CA> To: deering@cisco.com, rem-conf@es.net Subject: Re: MBone teleconf tools for Macs? Hi Steve, With the merge of Apple and NeXT, I'm not too sure that either Apple or third parties `will be willing to be put too much energy in an OS that's destined to die (die of old age however). I was able to get some inter-operability between Mbone and Cu-SeeMe by hacking around difficulties. The CuSeeMe reflector is supposed the perfectly sned and receive mcast traffic but: 1- for me, it didn't 2- It can only support the CuSeeMe video format and DVI audio, which makes it useless I know I'm not being very useful here but I felt I had to say if I was you, I'd not hold my breath. Do an altavista search of the words MBone and CuSeeMe (ok, they're not really words) and you'll several web pages of people who tried to make these two worlds inter-operate. Some succeded. Regards, Yves Lepage From rem-conf-request@es.net Thu Jan 30 12:02:26 1997 Received: from zephyr.isi.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 09:01:46 -0800 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 30 Jan 1997 09:01:32 -0800 Date: Thu, 30 Jan 1997 09:01:22 -0800 From: touch@ISI.EDU Posted-Date: Thu, 30 Jan 1997 09:01:22 -0800 Message-Id: <199701301701.AA04411@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Thu, 30 Jan 1997 09:01:22 -0800 To: rem-conf@es.net, aboba@internaut.com Subject: Re: New mailing list on multicasting of Web content X-Auto-Sig-Adder-By: faber@isi.edu > From rem-conf-request@es.net Fri Jan 24 10:45:51 1997 > X-UIDL: 854242089.010 > From: Bernard Aboba > To: "'rem-conf@es.net'" > Subject: New mailing list on multicasting of Web content > Date: Fri, 24 Jan 1997 06:51:48 -0800 > Encoding: 45 TEXT > > New mailing list on multicasting Web content > > A new mailing list has been set up for discussing the distribution of > Web content via "unreliable multicast." To > subscribe, send a message to "www-multicast-request@w3.org", and put > "subscribe" in the subject line. The archive of the mailing list is > available as http://lists.w3.org/Archives/Public/www-multicast/, and > the FTP server (used for archiving of related documents) is available at > ftp://ftp.zilker.net/pub/mailcom/WWW-MULTICAST/. > Why do we need another list?? > From owner-w-bone@net.lut.ac.uk Fri Jun 14 06:04:35 1996 > From: Mark Handley > X-Organisation: University College London, CS Dept. > X-Phone: +44 171 419 3666 > To: dauphin@sig.enst.fr (Gilles Dauphin) > Cc: mbone@ISI.EDU, w-bone@mrrl.lut.ac.uk > Subject: Re: ANNOUNCE: webcast mailing-list > Date: Fri, 14 Jun 96 13:49:10 +0100 > > > > I'd like to announce a new mailing-list called webcast. > > > > The goal of this list is to provide an informal forum for people interested > > in multicasting hypertext. > > > > Subscription: > > > > Anyone can subscribe by sending a special message to the address > > "listserv@sig.enst.fr" without subject indication but with, on a line by > > itself, the message "subscribe webcast" followed by identification (person > > or group); e.g.: > > > > To: listserv@sig.enst.fr > > Subject: > > subscribe webcast Gilles Dauphin > > > > Subscription confirmation is normally sent back a few minutes later. > > Perhaps I'm confused, but I though this was also (partly) the purpose of > w-bone@mrrl.lut.ac.uk > > Do these lists serve the same purpose? If so, can we agree to use only > one. If not, could you enlighten me as to the difference between them? > > Mark > ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From rem-conf-request@es.net Thu Jan 30 14:36:42 1997 Received: from zephyr.isi.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 11:35:19 -0800 Received: from ash.isi.edu (ash-a.isi.edu) by zephyr.isi.edu (5.65c/5.61+local-23) id ; Thu, 30 Jan 1997 11:33:44 -0800 Date: Thu, 30 Jan 1997 11:33:43 -0800 From: touch@ISI.EDU Posted-Date: Thu, 30 Jan 1997 11:33:43 -0800 Message-Id: <199701301933.AA08160@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Thu, 30 Jan 1997 11:33:43 -0800 To: rem-conf@es.net, aboba@internaut.com, touch@ISI.EDU Subject: Re: New mailing list on multicasting of Web content X-Auto-Sig-Adder-By: faber@isi.edu I'm resending this because I believe the brain-dead rem-conf remailer punted it due to "too much included text, not enough new". Please excuse the defeater attached at the bottom... PS - there appear to be three lists, as a result: w-bone@mrrl.lut.ac.uk webcast (Mark H's proposal) www-multicast@w3.org I propose that w-bone is the correct place for this list, because it already exists. Joe > From: Bernard Aboba > To: "'rem-conf@es.net'" > Subject: New mailing list on multicasting of Web content > Date: Fri, 24 Jan 1997 06:51:48 -0800 > > New mailing list on multicasting Web content > > A new mailing list has been set up for discussing the distribution of > Web content via "unreliable multicast." To > subscribe, send a message to "www-multicast-request@w3.org", and put Why do we need another list?? > From: Mark Handley > To: dauphin@sig.enst.fr (Gilles Dauphin) > Cc: mbone@ISI.EDU, w-bone@mrrl.lut.ac.uk > Subject: Re: ANNOUNCE: webcast mailing-list > Date: Fri, 14 Jun 96 13:49:10 +0100 > > > I'd like to announce a new mailing-list called webcast. > > > > The goal of this list is to provide an informal forum for people interested > > in multicasting hypertext. > > Perhaps I'm confused, but I though this was also (partly) the purpose of > w-bone@mrrl.lut.ac.uk > > Do these lists serve the same purpose? If so, can we agree to use only > one. If not, could you enlighten me as to the difference between them? > > Mark (defeater text follows, to ensure that including two old messages plus a small amount of information isn't mistaken as 'me-too' mail aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ From rem-conf-request@es.net Thu Jan 30 15:19:29 1997 Received: from bugs-bunny.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 12:18:24 -0800 Received: from nobozo.CS.Berkeley.EDU (nobozo.CS.Berkeley.EDU [128.32.34.58]) by bugs-bunny.CS.Berkeley.EDU (8.8.4/8.8.2) with SMTP id LAA05819 for <298-list@bmrc.Berkeley.EDU>; Thu, 30 Jan 1997 11:51:26 -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 LAA06453 for <298-list@bmrc>; Thu, 30 Jan 1997 11:51:28 -0800 Date: Thu, 30 Jan 1997 11:51:28 -0800 Message-Id: <199701301951.LAA06453@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@bugs-bunny.CS.Berkeley.EDU From: Jerrlyn Iwata Subject: Berkeley Multimedia & Graphics Seminar Berkeley Multimedia and Graphics Seminar (Wednesday February 5, 1997 12:30-2:00 PDT 405 Soda Hall) "The Impact of Future Developments in Flat Panel and Projection Display" Dave Mentley Stanford Resources, Inc. San Jose, CA The search for a useful and economical flat panel display began in the 1960s. The problem has been much harder to solve than anyone imagined, but the progress in recent years has also been astounding. Likewise, electronic projection technology, after many stagnant years, has accelerated to the point where a new generation of projector is arriving every year. Despite the progress, many issues remain to be resolved, particularly regarding performance, price and reliability. The talk will discuss the technology market and performance issues for LCDs, color plasma, projection displays and some of the advanced displays expected to make an impact within the next 5 years. ----------------------------------------------------------------------------- This seminar will be broadcast on the Internet MBONE. The broadcast will begin at 12:40 PST (GMT - 8 hrs). See sdr or http://bmrc.berkeley.edu/298 for instructions on setting up, connecting to, and operating the MBONE tools. From rem-conf-request@es.net Thu Jan 30 15:58:06 1997 Received: from gatekeeper.es.dupont.com by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 12:57:15 -0800 Received: by gatekeeper.es.dupont.com; id PAA05674; Thu, 30 Jan 1997 15:57:11 -0500 Received: by aladdin.es.dupont.com; id PAA05361; Thu, 30 Jan 1997 15:57:10 -0500 Message-Id: <199701302057.PAA05361@aladdin.es.dupont.com> To: rem-conf@es.net Subject: SunFastEthernet if_bqe driver Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Jan 1997 15:57:09 -0500 From: Mike Minnich Does anyone have a recent (working) if_bqe driver for SunOS 4.1.3_U1 with the requisite IP Multicast patches applied? The version supplied with the release3.5 kernel mods does not work with our boards (rev -08). Sun patch 103345-01 supplies a more recent driver which works fine, but as you might guess it is not multicast capable. Mike From rem-conf-request@es.net Thu Jan 30 16:34:15 1997 Received: from monitor.internaut.com by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 13:33:06 -0800 Received: from multi ([204.57.137.9]) by monitor.internaut.com (8.7.6/8.6.12) with SMTP id NAA23358; Thu, 30 Jan 1997 13:30:29 -0800 (PST) Received: by multi with Microsoft Mail id <01BC0EB1.AD10F060@multi>; Thu, 30 Jan 1997 13:29:53 -0800 Message-ID: <01BC0EB1.AD10F060@multi> From: Bernard Aboba To: "rem-conf@es.net" , "'touch@ISI.EDU'" Subject: RE: New mailing list on multicasting of Web content Date: Thu, 30 Jan 1997 13:29:51 -0800 Encoding: 9 TEXT The WWW-MULTICAST list was created for the explicit purpose of preparing for a future IETF BOF on the topic of unreliable multicasting of Web content. Should an IETF working group be formed, it is expected that the list will transition over to use for working group discussions. Since the list has explicit goals (i.e. preparation of Internet-Drafts reviewing existing work, and defining the problem) relating to IETF activity, its purpose is distinct from the other lists you mention. From rem-conf-request@es.net Thu Jan 30 18:49:12 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 15:47:56 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id PAA16302 for ; Thu, 30 Jan 1997 15:48:06 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma016267; Thu Jan 30 15:47:12 1997 Received: by hille.msri.org (8.7/MSRI) id PAA28211; Thu, 30 Jan 1997 15:46:04 -0800 (PST) Date: Thu, 30 Jan 1997 15:46:04 -0800 (PST) Message-Id: <199701302346.PAA28211@hille.msri.org> To: rem-conf@es.net From: osserman Reply-to: osserman@msri.org Subject: Gordon Shaw: Computation by Symmetry Operations in a Structured Neural Model of the Brain: Music and Abstract Reasoning MBone Broadcast Announcement ---------------------------- Title: Gordon Shaw: Computation by Symmetry Operations in a Structured Neural Model of the Brain: Music and Abstract Reasoning Date: Feb 03, 1997 Time: 16:15 PST8PDT 1 hours Contact: osserman@msri.org URL: http://www.msri.org/lecturenotes/97/shaw/ Description: Predictions from our structured neural model of the cortex led us to the hypothesis that music could causally enhance spatial-temporal reasoning. We have shown a) College students scored significantly higher on a spatial-temporal reasoning task after listening to a Mozart Sonata (K.448), but not after listening to silence or to minimalist music. b) Preschool children who received private keyboard lessons for 6 months improved dramatically on a spatial-temporal reasoning task while appropriate control groups did not improve significantly. Enhancement a) lasted roughly 10 minutes and established the causal effect, while enhancement b) lasts long enough to have major educational implications. Here we review the model, in particular, the "built-in" ability of the cortex to recognize symmetry relations among the inherent spatial-temporal firing patterns, which we suggest is a crucial feature of the cortical relationship between music and spatial-temporal reasoning. Then,! ! we summarize the behavioral results, and make further predictions relevant to education. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Jan 30 18:50:08 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 15:49:03 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id PAA16338 for ; Thu, 30 Jan 1997 15:49:07 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma016327; Thu Jan 30 15:48:39 1997 Received: by hille.msri.org (8.7/MSRI) id PAA28245; Thu, 30 Jan 1997 15:47:33 -0800 (PST) Date: Thu, 30 Jan 1997 15:47:33 -0800 (PST) Message-Id: <199701302347.PAA28245@hille.msri.org> To: rem-conf@es.net From: osserman Reply-to: osserman@msri.org Subject: Gordon Shaw: Computation by Symmetry Operations in a Structured Neural Model of the Brain: Music and Abstract Reasoning MBone Broadcast Announcement ---------------------------- Title: Gordon Shaw: Computation by Symmetry Operations in a Structured Neural Model of the Brain: Music and Abstract Reasoning Date: Feb 04, 1997 Time: 12:00 PST8PDT 1 hours Contact: osserman@msri.org URL: http://www.msri.org/lecturenotes/97/shaw/ Description: Predictions from our structured neural model of the cortex led us to the hypothesis that music could causally enhance spatial-temporal reasoning. We have shown a) College students scored significantly higher on a spatial-temporal reasoning task after listening to a Mozart Sonata (K.448), but not after listening to silence or to minimalist music. b) Preschool children who received private keyboard lessons for 6 months improved dramatically on a spatial-temporal reasoning task while appropriate control groups did not improve significantly. Enhancement a) lasted roughly 10 minutes and established the causal effect, while enhancement b) lasts long enough to have major educational implications. Here we review the model, in particular, the "built-in" ability of the cortex to recognize symmetry relations among the inherent spatial-temporal firing patterns, which we suggest is a crucial feature of the cortical relationship between music and spatial-temporal reasoning. Then, ! ! we summarize the behavioral results, and make further predictions relevant to education. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Jan 30 18:52:42 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 15:50:57 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id PAA16397 for ; Thu, 30 Jan 1997 15:51:07 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma016373; Thu Jan 30 15:50:18 1997 Received: by hille.msri.org (8.7/MSRI) id PAA28279; Thu, 30 Jan 1997 15:49:11 -0800 (PST) Date: Thu, 30 Jan 1997 15:49:11 -0800 (PST) Message-Id: <199701302349.PAA28279@hille.msri.org> To: rem-conf@es.net From: osserman Reply-to: osserman@msri.org Subject: Gordon Shaw: The Mozart Effect MBone Broadcast Announcement ---------------------------- Title: Gordon Shaw: The Mozart Effect Date: Feb 04, 1997 Time: 16:15 PST8PDT 1 hours Contact: osserman@msri.org URL: http://www.msri.org/lecturenotes/97/shaw/ Description: Music Training Causes Long-Term Enhancement of Spatial-Temporal Reasoning and Mathematical Conceptualization in Young School Children Professor Gordon Shaw of UC Irvine has been a key figure in the music-and-mathematics educational experiments that have been in the news during the past few years. In some of the experiments, students who listened to Mozart for ten minutes before taking a standard exam did considerably better than those who did not. (Various controls were used, including ten minutes of silence, ten minutes of a "relaxation" tape, and ten minutes of Philip Glass.) More recently, extensive experiments have been carried out with pre-schoolers to see if exposure to music training has a long-lasting effect on brain development and the ability to master certain kinds of spatial-temporal tasks, such as mental rotation of the different parts of a fragmented picture to recognize the original. Gordon Shaw was featured recently on Canadian television i! ! n connection with a school district's decision to drop its music program in order to purchase large numbers of computers. He describes his current experiment with a public school kindergarten class in which half the class is given extra music training and the other half is given extra computer training. Toward the end of the year they will be tested to see if one or the other half does significantly better on certain standard tests, such as those described above. The work of Gordon Shaw and his collaborators has broad implications, both for basic theoretical questions about the structure and function of the brain, and for practical matters involving educational programs. mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Jan 30 18:54:05 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 15:51:59 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id PAA16524 for ; Thu, 30 Jan 1997 15:52:08 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma016458; Thu Jan 30 15:51:39 1997 Received: by hille.msri.org (8.7/MSRI) id PAA28313; Thu, 30 Jan 1997 15:50:32 -0800 (PST) Date: Thu, 30 Jan 1997 15:50:32 -0800 (PST) Message-Id: <199701302350.PAA28313@hille.msri.org> To: rem-conf@es.net From: osserman Reply-to: osserman@msri.org Subject: Gordon Shaw: The Mozart Effect MBone Broadcast Announcement ---------------------------- Title: Gordon Shaw: The Mozart Effect Date: Feb 05, 1997 Time: 12:00 PST8PDT 1 hours Contact: osserman@msri.org URL: http://www.msri.org/lecturenotes/97/shaw/ Description: Music Training Causes Long-Term Enhancement of Spatial-Temporal Reasoning and Mathematical Conceptualization in Young School Children Professor Gordon Shaw of UC Irvine has been a key figure in the music-and-mathematics educational experiments that have been in the news during the past few years. In some of the experiments, students who listened to Mozart for ten minutes before taking a standard exam did considerably better than those who did not. (Various controls were used, including ten minutes of silence, ten minutes of a "relaxation" tape, and ten minutes of Philip Glass.) More recently, extensive experiments have been carried out with pre-schoolers to see if exposure to music training has a long-lasting effect on brain development and the ability to master certain kinds of spatial-temporal tasks, such as mental rotation of the different parts of a fragmented picture to recognize the original. Gordon Shaw was featured recently on Canadian television in co! ! nnection with a school district's decision to drop its music program in order to purchase large numbers of computers. He describes his current experiment with a public school kindergarten class in which half the class is given extra music training and the other half is given extra computer training. Toward the end of the year they will be tested to see if one or the other half does significantly better on certain standard tests, such as those described above. The work of Gordon Shaw and his collaborators has broad implications, both for basic theoretical questions about the structure and function of the brain, and for practical matters involving educational programs mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Jan 30 18:56:21 1997 Received: from msri.org by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 15:54:02 -0800 Received: (from smap@localhost) by msri.org (8.8.2/8.7.2) id PAA16657 for ; Thu, 30 Jan 1997 15:54:10 -0800 (PST) X-Authentication-Warning: msri.org: smap set sender to using -f Received: from hille.msri.org(198.129.64.225) by msri.org via smap (V1.3) id sma016597; Thu Jan 30 15:53:18 1997 Received: by hille.msri.org (8.7/MSRI) id PAA28347; Thu, 30 Jan 1997 15:52:11 -0800 (PST) Date: Thu, 30 Jan 1997 15:52:11 -0800 (PST) Message-Id: <199701302352.PAA28347@hille.msri.org> To: rem-conf@es.net From: joe Reply-to: joe@msri.org Subject: George Andrews: The Death of Proof MBone Broadcast Announcement ---------------------------- Title: George Andrews: The Death of Proof Date: Feb 06, 1997 Time: 12:00 PST8PDT 1 hours Contact: joe@msri.org URL: http://www.msri.org/lecturenotes/96/andrews/1/ Description: Recently John Horgan in the Scientific American and Doron Zeilberger in the A.M.S. Notices provided lengthy articles suggesting that proof as we know it is on the skids. The object of this talk will be to examine the mathematical evidence for these assertions. We hope to show that proof still has some life left in it. We shall especially examine the role of computer algebra system in this controversy mbone broadcast schedule http://www.msri.org/mbone From rem-conf-request@es.net Thu Jan 30 20:43:15 1997 Received: from mail-out1.apple.com by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 17:40:58 -0800 Received: from scv3.apple.com (A17-128-100-121.apple.com [17.128.100.121]) by mail-out1.apple.com (8.8.5/8.8.4) with ESMTP id RAA22916 for ; Thu, 30 Jan 1997 17:39:13 -0800 Received: from mailman.apple.com.CPT (mailman.apple.com [17.206.40.179]) by scv3.apple.com (8.8.4/8.8.4) with SMTP id RAA05536 for ; Thu, 30 Jan 1997 17:41:16 -0800 Received: from [17.255.9.131] (skylawn.research.apple.com) by mailman.apple.com.CPT (4.1/SMI-4.1) id AA27137; Thu, 30 Jan 97 17:36:46 PST Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Jan 1997 17:40:41 -0800 To: rem-conf@es.net From: alagu@mailman.apple.com (Alagu Periyannan) Subject: Re: MBone teleconf tools for Macs? At 3:10 PM 1/29/97, Steve Deering wrote: >Has anyone ported any of the MBone teleconferencing tools to the >Macintosh yet? > Here is what Apple already has or is looking into having as far as MBone/RTP tools ... Reception Tools: Apple has an MBone client called "MBone TV" that handles, Video: H.261, JPEG, NV Audio: PCM, GSM There is an implementation of SDR called "MBone Directory" which handles receiving announcements. We are looking into adding announcement generation capabilities. All the MBone/RTP client software can be downloaded at, http://qttv.quicktime.apple.com/qttv/qttv.RTP.html Broadcast Tools: Apple has a broadcast tool called "Broadcaster Lite" that let's you broadcast audio/video. We are looking into adding MBone/RTP capabilities into the broadcaster application soon. (It currently uses the "MovieTalk" protocol, i.e. does not use multicast or RTP. It works with Apple's reflector to make distribution easier in the absence of multicast. Broadcasts can be viewed with the "Quicktime TV" application.) The Broadcaster can be downloaded at, http://qttv.quicktime.apple.com/qttv/qttv.blite.sysreq.html We're also looking into getting support for other RTP audio/video payload types such as DVI, etc. for both MBone TV as well as the Broadcaster. There has been some change in personel on these projects which has caused temporary delays. We will keep users updated through our website at, http://qttv.quicktime.apple.com/ Thanks for your patience. And stay tuned (to our website). > >I am particularly interested in Mac versions of sdr and vat, or >interoperable equivalents. wb would also be great, as an adjunct to >the first two. vic is much lower priority for me, though it seems that >implementors always want to do the flashy video stuff first. > There is a tool called "Maven" available on the internet that will interoperate with VAT. Alagu Periyannan alagu@mailman.apple.com Communications Products and Technology Apple Computer, Inc. From rem-conf-request@es.net Thu Jan 30 21:33:08 1997 Received: from cheerios.cisco.com by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 18:31:11 -0800 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id SAA04136; Thu, 30 Jan 1997 18:31:02 -0800 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Jan 1997 18:31:00 -0800 To: alagu@mailman.apple.com (Alagu Periyannan) From: Steve Deering Subject: Re: MBone teleconf tools for Macs? Cc: rem-conf@es.net Thanks a lot for the status report, Alagu. I'm delighted to hear you say that Apple plans to continue development of RTP- and multicast- compatible tools. From the private responses to my message I have learned that there are a fair number of us Mac lovers anxious to use the MBone from our favorite platform. The partitioning into "reception tools" and "broadcast tools" makes some sense for broadcast-style (one-to-many) applications, but doesn't seem a very comfortable fit with interactive use of multicast, such as teleconferencing (many-to-many). A tool that integrates the sending and receiving capabilities, like vat, would be much more natural, in my opinion. Perhaps extending the Apple VideoPhone app (which I have not yet tried out) to support multiple participants via multicast and RTP would be something powerful and easy to do. > There is a tool called "Maven" available on the internet > that will interoperate with VAT. Last I knew, Maven supported point-to-point (i.e., unicast) operation only. Steve From rem-conf-request@es.net Fri Jan 31 02:12:23 1997 Received: from monitor.internaut.com by osi-west.es.net with ESnet SMTP (PP); Thu, 30 Jan 1997 23:11:44 -0800 Received: from multi ([204.57.137.9]) by monitor.internaut.com (8.7.6/8.6.12) with SMTP id XAA23788; Thu, 30 Jan 1997 23:09:14 -0800 (PST) Received: by multi with Microsoft Mail id <01BC0F02.85024140@multi>; Thu, 30 Jan 1997 23:08:35 -0800 Message-ID: <01BC0F02.85024140@multi> From: Bernard Aboba To: "rem-conf@es.net" , 'Stephen Casner' Subject: RE: Minutes for AVT WG at San Jose IETF Date: Thu, 30 Jan 1997 23:08:34 -0800 Encoding: 26 TEXT Steve Casner said: Should the specification of an RTP session be generalized to allow different addresses to be used for RTP and RTCP? This would allow RTCP delivery to be constrained for improved scalability in some scenarios. After some discussion, the consensus of the group was that we should take the conservative approach and not make this change at this time. I think this point is worth some debate. While placement of RTP and RTCP on separate groups is certainly not a panacea, allowing this would have a pretty big impact for networks running SM-PIM. For a session with 1 sender and 20K receivers, we're talking about the difference between 20K potential (S,G) forwarding table entries, and one (S,G) entry, with the rest on the shared tree. So this modification has the potential to dramatically enhance scalability in one to many scenarios. What I would suggest is to keep RTP/RTCP on the same group by default, but define a profile that will cause them to use separate groups. Similarly, I would argue for a profile with no RTCP, and one which defines the bandwidth fraction to be some number less than 5 percent, for asymmetric networks. If we do all this, plus fix the RTCP "spike" problem via reconsideration, we'll have made a substantial step toward enabling major multicast deployments. From rem-conf-request@es.net Fri Jan 31 03:10:13 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 31 Jan 1997 00:09:16 -0800 Received: from little-bear.precept.com by precept.com (SMI-8.6/SMI-SVR4) id AAA15070; Fri, 31 Jan 1997 00:05:52 -0800 Date: Fri, 31 Jan 1997 00:05:51 -0800 (PST) From: Stephen Casner To: Bernard Aboba cc: "rem-conf@es.net" Subject: RE: Minutes for AVT WG at San Jose IETF In-Reply-To: <01BC0F02.85024140@multi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I think this point is worth some debate. While placement of RTP and RTCP > on separate groups is certainly not a panacea, allowing this would have > a pretty big impact for networks running SM-PIM. For a session with > 1 sender and 20K receivers, we're talking about the difference between > 20K potential (S,G) forwarding table entries, and one (S,G) entry, > with the rest on the shared tree. So this modification has the potential > to dramatically enhance scalability in one to many scenarios. I agree that SM could be a significant savings for this scenario. However, I thought that the decision to create (S,G) state was made independently for each source, based on the data rate from that source. If that is accurate, wouldn't the savings be the same even with one address? > Similarly, I would argue for a profile with > no RTCP, and one which defines the bandwidth fraction to be > some number less than 5 percent, for asymmetric networks. Doesn't the 5-second minimum interval keep the data rate low enough for the small-group case on asymmetric networks? You cited an example of a net with 1Mb/s downstream and 50kb/s upstream (or something like that); 1 RTCP packet every 5 seconds is only about 200b/s. As the upstreams of multiple users come together, I would hope that the bandwidth available increases. > If we do all this, plus fix the RTCP "spike" problem via reconsideration, > we'll have made a substantial step toward enabling major multicast > deployments. That, and specify the sampling technique for tracking SSRC id's to reduce memory requirements. -- Steve From rem-conf-request@es.net Fri Jan 31 03:35:21 1997 Received: from chow.cisco.com by osi-west.es.net with ESnet SMTP (PP); Fri, 31 Jan 1997 00:34:41 -0800 Received: (mleelani@localhost) by chow.cisco.com (8.6.12/8.6.5) id AAA22467; Fri, 31 Jan 1997 00:32:07 -0800 From: Manoj Leelanivas Message-Id: <199701310832.AAA22467@chow.cisco.com> Subject: Re: Minutes for AVT WG at San Jose IETF To: aboba@internaut.com (Bernard Aboba) Date: Fri, 31 Jan 1997 00:32:07 -0800 (PST) Cc: rem-conf@es.net, casner@precept.com In-Reply-To: <01BC0F02.85024140@multi> from "Bernard Aboba" at Jan 30, 97 11:08:34 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2093 => => Steve Casner said: => => Should the specification of an RTP session be => generalized to allow different addresses to be used for RTP and RTCP? => This would allow RTCP delivery to be constrained for improved => scalability in some scenarios. After some discussion, the consensus => of the group was that we should take the conservative approach and not => make this change at this time. => => I think this point is worth some debate. While placement of RTP and RTCP => on separate groups is certainly not a panacea, allowing this would have => a pretty big impact for networks running SM-PIM. For a session with => 1 sender and 20K receivers, we're talking about the difference between => 20K potential (S,G) forwarding table entries, and one (S,G) entry, => with the rest on the shared tree. So this modification has the potential => to dramatically enhance scalability in one to many scenarios. Just to clarify, the protocol specification for PIM-SM specifies: - Creation of (S, G) at the RP and subsequent joining of source tree, only if the register rate from S warrants it. - Creation of (S, G) in the leaf routers is also triggered only if the packets from that particular S has crossed the threshold for switching to source tree. So, even with one group for both RTP/RTCP, sparse mode as specified by the draft should be OK. It wont create tons of (S, G)s. Of course, some implementations switch to shortest path tree if the cumulative threshold on the (*, G) is exceeded (rather than per S) and in that case having two groups is beneficial to avoid lot of (S, G) states. There is another motivation for assigning RTP and RTCP different groups. If you have 20K receivers sending RTCP reports, the RP is going to get the load of large number of registers(intermittent from each source). If we have 2 RPs, one serving the RTP group-range and another serving an RTCP group range, then the RTCP register load (This may be helpful only if you have 20K+ receivers as you mentioned), could be diverted to the 2nd RP. -Manoj From rem-conf-request@es.net Fri Jan 31 08:47:46 1997 Received: from irafs1.ira.uka.de by osi-west.es.net with ESnet SMTP (PP); Fri, 31 Jan 1997 05:47:02 -0800 Received: from 129.13.2.171 (actually i02mac171.ira.uka.de) by irafs1 with SMTP (PP); Fri, 31 Jan 1997 14:46:58 +0000 Message-ID: <32F1F7FC.17A7@ira.uka.de> Date: Fri, 31 Jan 1997 14:47:41 +0100 From: Sven Claussen Organization: University of Karlsruhe X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) MIME-Version: 1.0 To: rem-conf@es.net Subject: Preferences for SDR-Tools??? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am using the sdr-tools on a sun-machine for broadcasting lessons out of the university. After starting the programs (nv, wb, vic, vat) I have to configure them. And this again and again after each new session. Can I create a preference file somewhere to store my favorite configuration? Or can I put all the parameter I needed into the function call, e.g. vic -f h261 -t 47 etc.?? Who has further information about the parameters of the call? The manpages I got are not sufficient:-( I like to call the tools as a cron-job. Does this work? Sven -- *************************** * Sven Claussen * * Fakultaet f. Informatik * * Universitaet Karlsruhe * * claussen@ira.uka.de * *************************** From rem-conf-request@es.net Fri Jan 31 20:26:38 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 31 Jan 1997 17:25:53 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id RAA17573; Fri, 31 Jan 1997 17:19:45 -0800 Date: Fri, 31 Jan 1997 17:21:01 -0800 () From: Stephen Casner To: Manoj Leelanivas cc: rem-conf@es.net Subject: Re: Minutes for AVT WG at San Jose IETF In-Reply-To: <199701310832.AAA22467@chow.cisco.com> Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Manoj, > Just to clarify, the protocol specification for PIM-SM specifies: > > - Creation of (S, G) at the RP and subsequent joining of source tree, > only if the register rate from S warrants it. > - Creation of (S, G) in the leaf routers is also triggered only if the > packets from that particular S has crossed the threshold for switching > to source tree. > > So, even with one group for both RTP/RTCP, sparse mode as specified by > the draft should be OK. It wont create tons of (S, G)s. Thanks for clarifying; that's what I thought. > Of course, some implementations switch to > shortest path tree if the cumulative threshold on the (*, G) is > exceeded (rather than per S) and in that case having two groups is > beneficial to avoid lot of (S, G) states. Is that because the leaf router essentially has to keep some (S,G) state in order to measure the rate for that S? Does this negate the points you clarified in most (not just some) implementations? That is, in practice would we need two groups in order to avoid lots of (S,G) state? Or do we just need to make sure implementers know that there is a good reason to do what the spec says. > There is another motivation for assigning RTP and RTCP different > groups. If you have 20K receivers sending RTCP reports, the RP is > going to get the load of large number of registers(intermittent from > each source). If we have 2 RPs, one serving the RTP group-range and > another serving an RTCP group range, then the RTCP register load (This > may be helpful only if you have 20K+ receivers as you mentioned), > could be diverted to the 2nd RP. Good thought, but this doesn't divide the work evenly. For the RTP RP there is only one source in this scenario, and all 20K of the other sources are on the RTCP RP. To handle many sessions, you could have a large range assigned to the RTP RP, and a bunch of RTCP RP's each with a small range, but the effect would be essentially the same with an equal number of small ranges for RPs serving combined RTP and RTCP. Also, if we did have separate addresses for RTP and RTCP, we'd probably want a simple arithmetic relationship between the addresses. That may make it difficult to achieve the desired mapping to separate RPs, depending on the mapping function. -- Steve From rem-conf-request@es.net Fri Jan 31 20:54:18 1997 Received: from burdell.cc.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 31 Jan 1997 17:53:33 -0800 Received: from flora.cc.gatech.edu (kevin@flora.cc.gatech.edu [130.207.8.20]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id UAA02255; Fri, 31 Jan 1997 20:53:29 -0500 (EST) Received: (from kevin@localhost) by flora.cc.gatech.edu (8.8.4/8.6.9) id UAA11260; Fri, 31 Jan 1997 20:53:29 -0500 (EST) Date: Fri, 31 Jan 1997 20:53:29 -0500 (EST) From: kevin@cc.gatech.edu (Kevin C. Almeroth) Message-Id: <199702010153.UAA11260@flora.cc.gatech.edu> To: claussen@ira.uka.de, rem-conf@es.net Subject: Re: Preferences for SDR-Tools??? >>I am using the sdr-tools on a sun-machine for broadcasting >>lessons out of the university. After starting the programs >>(nv, wb, vic, vat) I have to configure them. And this again >>and again after each new session. >>Can I create a preference file somewhere to store my favorite >>configuration? Or can I put all the parameter I needed into >>the function call, e.g. vic -f h261 -t 47 etc.?? >>Who has further information about the parameters of the call? >>The manpages I got are not sufficient:-( >>I like to call the tools as a cron-job. Does this work? Vic and vat are extremely flexible this way... Here is one set of parameters I use to configure everything and even start transmitting. Check out the man pages for all the options. vat -r -I2 -N"Session Source" -fdvi2 -t16 \ -XlectureMode=ture \ -XmikeMute=false \ -XlineinGain=40 \ -XinputPort=Line \ -XspeakerMode=FullDuplex \ -XlineoutMode=FullDuplex \ -Xlineout2Mode=FullDuplex \ 224.2.129.147/17982 & vic -Dsunvideo -I2 -B256 -N"Session Source" \ -Xframerate=30 \ 224.2.129.147/63984//16 & -Kevin Almeroth From rem-conf-request@es.net Fri Jan 31 22:28:20 1997 Received: from chow.cisco.com by osi-west.es.net with ESnet SMTP (PP); Fri, 31 Jan 1997 19:27:33 -0800 Received: (mleelani@localhost) by chow.cisco.com (8.6.12/8.6.5) id TAA03048; Fri, 31 Jan 1997 19:27:30 -0800 From: Manoj Leelanivas Message-Id: <199702010327.TAA03048@chow.cisco.com> Subject: Re: Minutes for AVT WG at San Jose IETF To: casner@precept.com (Stephen Casner) Date: Fri, 31 Jan 1997 19:27:30 +73600 (PST) Cc: mleelani@cisco.com, rem-conf@es.net In-Reply-To: from "Stephen Casner" at Jan 31, 97 05:21:01 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3404 => => Manoj, => => > Just to clarify, the protocol specification for PIM-SM specifies: => > => > - Creation of (S, G) at the RP and subsequent joining of source tree, => > only if the register rate from S warrants it. => > - Creation of (S, G) in the leaf routers is also triggered only if the => > packets from that particular S has crossed the threshold for switching => > to source tree. => > => > So, even with one group for both RTP/RTCP, sparse mode as specified by => > the draft should be OK. It wont create tons of (S, G)s. => => Thanks for clarifying; that's what I thought. => => > Of course, some implementations switch to => > shortest path tree if the cumulative threshold on the (*, G) is => > exceeded (rather than per S) and in that case having two groups is => > beneficial to avoid lot of (S, G) states. => => Is that because the leaf router essentially has to keep some (S,G) => state in order to measure the rate for that S? Yes, it has to keep a small source cache(S, G and the rate) to implement the way the protocol specifies it. Still the baggage is much lesser than the (S, G) entry which needs to keep track of the outgoing interfaces and such. => Does this negate the => points you clarified in most (not just some) implementations? That => is, in practice would we need two groups in order to avoid lots of => (S,G) state? Or do we just need to make sure implementers know that => there is a good reason to do what the spec says. I am not sure what to say here. There is some justification from the implementors point of view to keep the source state switching simple (ie not caching each source and its packets) by keeping a cumulative threshold for the (*, G). But then you need 2 groups, if you want to keep the state down on the routers. But if all implementations adhere to the spec(keeping a source/rate cache around), then we dont need 2 groups. So,IMHO we cannot justify 2 groups for this problem. => => > There is another motivation for assigning RTP and RTCP different => > groups. If you have 20K receivers sending RTCP reports, the RP is => > going to get the load of large number of registers(intermittent from => > each source). If we have 2 RPs, one serving the RTP group-range and => > another serving an RTCP group range, then the RTCP register load (This => > may be helpful only if you have 20K+ receivers as you mentioned), => > could be diverted to the 2nd RP. => => Good thought, but this doesn't divide the work evenly. For the RTP RP => there is only one source in this scenario, and all 20K of the other => sources are on the RTCP RP. To handle many sessions, you could have a => large range assigned to the RTP RP, and a bunch of RTCP RP's each with => a small range, but the effect would be essentially the same with an => equal number of small ranges for RPs serving combined RTP and RTCP. => The RP which is switching RTP traffic also may have sources which are sending RTP streams interrmittently. Even otherwise, it has to switch the traffic for the active source(ie, it is indeed loaded to an extent though switching path may be much faster). What we could do is essentially moving the RTCP load to another RP, so that the primary RP can still have enough CPU to handle data streams. -Manoj From rem-conf-request@es.net Fri Jan 31 22:58:33 1997 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 31 Jan 1997 19:55:57 -0800 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id TAA17888; Fri, 31 Jan 1997 19:46:59 -0800 Date: Fri, 31 Jan 1997 19:48:16 -0800 () From: Stephen Casner To: Manoj Leelanivas cc: rem-conf@es.net Subject: Re: Minutes for AVT WG at San Jose IETF In-Reply-To: <199702010327.TAA03048@chow.cisco.com> Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Yes, it has to keep a small source cache(S, G and the rate) to > implement the way the protocol specifies it. Still the baggage is much > lesser than the (S, G) entry which needs to keep track of the outgoing > interfaces and such. And, it's important to make the distinction that it is only the leaf router which keeps this cache, and only for the sources sending through that leaf router. This compares to (S,G) routing state that would have to be kept in all the routers involved in the source-rooted trees, some of which would have to have state for all 20000 sources. > I am not sure what to say here. There is some justification from the > implementors point of view to keep the source state switching simple > (ie not caching each source and its packets) by keeping a cumulative > threshold for the (*, G). But then you need 2 groups, if you want to > keep the state down on the routers. But if all implementations adhere > to the spec(keeping a source/rate cache around), then we dont need 2 > groups. So,IMHO we cannot justify 2 groups for this problem. Yes, even if we changed the spec for RTP to use two groups, other protocols may have groups involving senders at both high and low rates. It does not seem reasonable to assume that all sources sending to a group will have comparable rates (so that switching them all to source-rooted trees when the data rate from one exceeds a threshold will make sense). > The RP which is switching RTP traffic also may have sources which are > sending RTP streams interrmittently. Even otherwise, it has to switch > the traffic for the active source(ie, it is indeed loaded to an extent though > switching path may be much faster). But doesn't that load get moved off to a source-rooted tree? -- Steve