From rem-conf-request@es.net Sat Jun 01 07:05:47 1996 Received: from basil.cdt.luth.se by osi-east.es.net with ESnet SMTP (PP); Sat, 1 Jun 1996 04:05:14 -0700 Received: from kalkyl.cdt.luth.se (kalkyl.cdt.luth.se [130.240.193.31]) by basil.cdt.luth.se (8.7.5/8.6.12) with ESMTP id NAA28518; Sat, 1 Jun 1996 13:02:46 +0200 (MET DST) Received: from kalkyl (localhost [127.0.0.1]) by kalkyl.cdt.luth.se (8.6.12/8.6.12) with ESMTP id NAA05585; Sat, 1 Jun 1996 13:05:07 +0200 Message-Id: <199606011105.NAA05585@kalkyl.cdt.luth.se> X-Mailer: exmh version 1.6.7 5/3/96 To: w-bone@mrrl.lut.ac.uk, rem-conf@es.net X-uri: http://www.cdt.luth.se/~peppar/ Subject: ANNOUNCE: Java-networking mailing-list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Jun 1996 13:05:07 +0200 From: Peter Parnes Hi I'd like to announce a new mailing-list called Java-networking. The goal of this list is to provide an informal forum for people interested in networking issues of the Java-language and library. This list is sponsored by the Centre for Distance-spanning Technology, CDT, . The list is unmoderated now but if the traffic gets out of hand I'll start to moderate it. To subscribe to this list, send the word "subscribe" to the administrative alias, java-networking-request@cdt.luth.se e.g., echo "subscribe" | mail java-networking-request@cdt.luth.se This info can be found at . /Peppar From rem-conf-request@es.net Sat Jun 01 07:29:57 1996 Received: from nemesis.ics.forth.gr (actually nemesis.csi.forth.gr) by osi-east.es.net with ESnet SMTP (PP); Sat, 1 Jun 1996 04:29:26 -0700 Received: from cuckoo.csi.forth.gr by nemesis.ics.forth.gr (ICS mailhost); on Sat, 1 Jun 1996 14:30:31 +0300 (EET DST); with id AA19581 From: Vidalis Antonis Received: by cuckoo.csi.forth.gr (SMI-8.6/SMI-SVR4) id OAA07526; Sat, 1 Jun 1996 14:29:58 +0300 Date: Sat, 1 Jun 1996 14:29:58 +0300 Message-Id: <199606011129.OAA07526@cuckoo.csi.forth.gr> Organization: Institute of Computer Science, Foundation for Research and Technology-Hellas (FORTH) Science and Technology Park of Crete Vassilika Vouton, P.O.Box 1385 GR 711 10 Heraklion, Crete, Greece tel.: +30 (81) 39 16 00, fax: +30 (81) 39 16 01 To: rem-conf@es.net Subject: RTP dump Hi all, I would like to download the latest version of rtpdump. Can someone tell me where I can find it. Thanks in advance, Antonis Vidalis From rem-conf-request@es.net Sat Jun 01 08:14:25 1996 Received: from ceres.fokus.gmd.de by osi-east.es.net with ESnet SMTP (PP); Sat, 1 Jun 1996 05:13:45 -0700 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Sat, 1 Jun 1996 14:07:42 +0200 X-Mailer: exmh version 1.6.7 5/3/96 To: Vidalis Antonis cc: rem-conf@es.net From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: RTP dump In-reply-to: Your message of "Sat, 01 Jun 1996 14:29:58 +0300." <199606011129.OAA07526@cuckoo.csi.forth.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Jun 1996 14:07:31 +0200 Sender: schulzrinne@fokus.gmd.de ftp://ftp.fokus.gmd.de/pub/step/rtptools Henning P.S. General hint: RTP applications can be found on the RTP resource page at http://www.fokus.gmd.de/step/rtp From rem-conf-request@es.net Sun Jun 02 09:48:09 1996 Received: from radvision.rad.co.il by osi-west.es.net with ESnet SMTP (PP); Sun, 2 Jun 1996 06:47:37 -0700 Received: by firewall.radvision.rad.co.il id <24194>; Sun, 2 Jun 1996 17:43:23 +0300 From: Ami Amir To: IMTC Reflector , IETF remote conference , "H.324 Reflector" Subject: subscribe Date: Mon, 3 Jun 1996 02:45:00 +0300 Message-Id: <96Jun2.174323idt.24194@firewall.radvision.rad.co.il> Encoding: 3 TEXT X-Mailer: Microsoft Mail V3.0 subscribe amir@radvision.rad.co.il From rem-conf-request@es.net Sun Jun 02 22:15:25 1996 Received: from sh.iij-mc.co.jp by osi-west.es.net with ESnet SMTP (PP); Sun, 2 Jun 1996 19:14:55 -0700 Received: from mcgw.iij-mc.co.jp (root@mcgw.iij-mc.co.jp [192.168.10.2]) by sh.iij-mc.co.jp (8.6.12+2.4W/3.4W2) with ESMTP id LAA01923; Mon, 3 Jun 1996 11:14:48 +0900 Received: from localhost (teapot.iij-mc.co.jp [192.168.10.16]) by mcgw.iij-mc.co.jp (8.6.12+2.5Wb7/3.4W) with ESMTP id LAA17711; Mon, 3 Jun 1996 11:14:46 +0900 To: mbone@isi.edu, rem-conf@es.net Cc: nakamura@rd.tksc.nasda.go.jp, watanabe@eorc.nasda.go.jp, yoshida@eorc.nasda.go.jp, takeda@eorc.nasda.go.jp Cc: goin-staff@iij-mc.co.jp, mc-mbone@iij-mc.co.jp Subject: GOIN Workshop Mime-Version: 1.0 From: YAMAMOTO Bunji X-Mailer: Mew version 1.03 on Emacs 19.28.1, Mule 2.3 Content-Type: Text/Plain; charset=us-ascii Message-Id: <19960603111445M/bunji@iij-mc.co.jp> Date: Mon, 03 Jun 1996 11:14:45 +0900 X-Dispatcher: impost version 0.81 Lines: 15 We will broadcast below session. Contents: GOIN Japan-US Joint Technical Workshop see also http://www.goin.nasda.go.jp/ Date: 1996/06/04 09:30 JST - 18:00 JST (00:30 UTC - 09:00 UTC) 1996/06/05 09:30 JST - 18:00 JST (00:30 UTC - 09:00 UTC) Contact To: mc-mbone@iij-mc.co.jp We will use sdr and RTPv2, and bandwidth is about 100kbps. Thanks, -- YAMAMOTO Bunji IIJ Media Communications Inc. From rem-conf-request@es.net Sun Jun 02 23:00:21 1996 Received: from tis-mail.thepoint.net (actually tis-backup.thepoint.net) by osi-west.es.net with ESnet SMTP (PP); Sun, 2 Jun 1996 19:59:51 -0700 Received: by tis-mail.thepoint.net with Microsoft Exchange (IMC 4.0.837.3) id <01BB50CE.036ED1E0@tis-mail.thepoint.net>; Sun, 2 Jun 1996 21:54:03 -0400 Message-ID: From: Arlie Davis To: "'Audio / Video Transport Group (REM-CONF)'" Subject: Thanks for info on SDR address assignment. Date: Sun, 2 Jun 1996 21:54:01 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Many thanks to everyone who provided information on SDR and its (mostly random) address assignment. -- arlie -- Arlie Davis -- System & Network Administrator, ThePoint Internet Services, Inc. -- (Mail in Microsoft Exchange "Rich Text" format is preferred.) From rem-conf-request@es.net Mon Jun 03 05:04:28 1996 Received: from ifhamy.insa-lyon.fr by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Jun 1996 02:03:42 -0700 Received: (from clesigne@localhost) by ifhamy.insa-lyon.fr (8.6.9/8.6.5/AEDI-AG) id LAA16783 for rem-conf@es.net; Mon, 3 Jun 1996 11:03:38 +0200 From: Christophe Lesigne Message-Id: <199606030903.LAA16783@ifhamy.insa-lyon.fr> Subject: Vat-Vic for Windows95 To: rem-conf@es.net Date: Mon, 3 Jun 1996 11:03:38 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 613 I have problems with Vat and Vic for Windows95: Sometimes when I start vic or vat I have a Tcl_main error or if it seems to work well, I can't receive any sound or video! and vat can't see a vat session runnning on the same address on a Unix platform! But in this case, a vat session running on a Unix platform can see the Windows vat session! I run Windows95 with a Pentium120 and a TCP-IP stack, a sound-blaster16 card but there is no video card. Can anyone say me what is wrong or if he has the same problems with vat or vic for Windows95? Christophe Lesigne clesigne@ifhamy.insa-lyon.fr From rem-conf-request@es.net Mon Jun 03 08:06:13 1996 Received: from speedy.grolier.fr by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Jun 1996 05:05:41 -0700 Received: from vto1 (ppp-206-5.neuilly.club-internet.fr [194.117.206.5]) by speedy.grolier.fr (8.7.5/MGC-960516) with SMTP id OAA09715 for ; Mon, 3 Jun 1996 14:04:41 +0200 (MET DST) Message-ID: <31B34C46.6807@deltabeta.com> Date: Mon, 03 Jun 1996 13:34:14 -0700 From: "Henry C. DeBey" Reply-To: debey@deltabeta.com Organization: Delta Beta Pty. Ltd. X-Mailer: Mozilla 3.0b3Gold (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Seeking acronym and term definitions Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am trying to come up to speed with the issues discussed in this mailing list. Can someone point me toward definitions for some of the terms and acronyms used here. Henry From rem-conf-request@es.net Mon Jun 03 10:55:02 1996 Received: from smrc.gdc.ca (actually gateway-isdn.gdc.ca) by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Jun 1996 07:54:25 -0700 Received: from suntan.gdc.ca (suntan.gdc.ca [192.34.72.103]) by smrc.gdc.ca (8.6.12/gdc-fs) with ESMTP id KAA15432 for ; Mon, 3 Jun 1996 10:55:19 -0400 Received: by suntan.gdc.ca (SMI-8.6/SMI-SVR4) id LAA16853; Mon, 3 Jun 1996 11:03:55 -0400 Date: Mon, 3 Jun 1996 11:03:55 -0400 From: ken@gdc.ca (Ken) Message-Id: <199606031503.LAA16853@suntan.gdc.ca> To: rem-conf@es.net Subject: H.320 MIB definition Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: yRSOFZsKSEML8z3Y7SnMlg== Anyone aware of an H.320 MIB definition ? Ken -------------------------------------------------------------------- Ken McVey Senior Engineer General DataComm Ltd. Multimedia Research & Development Center Montreal, Quebec. Canada email: kmcvey@gdc.ca -------------------------------------------------------------------- From rem-conf-request@es.net Mon Jun 03 18:13:20 1996 Received: from riker.read.tasc.com by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Jun 1996 15:12:50 -0700 Received: from snowflake (snowflake.read.tasc.com [147.81.240.218]) by riker.read.tasc.com (SMI-8.6/PRAT[SECURE-2.8]) with SMTP id SAA13109; Mon, 3 Jun 1996 18:13:05 -0400 From: wgsmith@riker.read.tasc.com (W. Garth Smith) Received: by snowflake (5.x) id AA02525; Mon, 3 Jun 1996 18:15:53 -0400 Date: Mon, 3 Jun 1996 18:15:53 -0400 Message-Id: <9606032215.AA02525@snowflake> To: rem-conf@es.net, ietf-dis@gmu.edu Subject: MBONE in Wired X-Sun-Charset: US-ASCII On page 86 of the June issue of Wired is a short description of the MBONE. From rem-conf-request@es.net Mon Jun 03 18:29:19 1996 Received: from riker.read.tasc.com by osi-west.es.net with ESnet SMTP (PP); Mon, 3 Jun 1996 15:28:43 -0700 Received: from snowflake (snowflake.read.tasc.com [147.81.240.218]) by riker.read.tasc.com (SMI-8.6/PRAT[SECURE-2.8]) with SMTP id SAA13418; Mon, 3 Jun 1996 18:29:05 -0400 From: wgsmith@riker.read.tasc.com (W. Garth Smith) Received: by snowflake (5.x) id AA02528; Mon, 3 Jun 1996 18:31:52 -0400 Date: Mon, 3 Jun 1996 18:31:52 -0400 Message-Id: <9606032231.AA02528@snowflake> To: rem-conf@es.net, ietf-dis@gmu.edu Subject: MBONE Intranet X-Sun-Charset: US-ASCII I am sending a URL of some work we are doing with the MBONE, Distributed Interactive Simulation (DIS), and an Intranet. http://www.tasc.com/simweb/papers/disramp/ We have tied several remote company sites together to have continuous multicast support for distributed simulations over our Sprint based WAN. The MBONE applications have been very reliable thus far. We now have about five locations all connected on our Intranet. We use a Reliable Adaptive Multicast Protocol for our transport layer through the tunnels http://www.tasc.com/simweb/papers/RAMP/ Do other people primarily use the MBONE tools for the Internet or are they being used for Intranet applications as well? Garth From rem-conf-request@es.net Tue Jun 04 03:31:05 1996 Received: from ifhamy.insa-lyon.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Jun 1996 00:30:31 -0700 Received: (from ldepieri@localhost) by ifhamy.insa-lyon.fr (8.6.9/8.6.5/AEDI-AG) id JAA25004 for rem-conf@es.net; Tue, 4 Jun 1996 09:30:17 +0200 From: Luis de Pieri Message-Id: <199606040730.JAA25004@ifhamy.insa-lyon.fr> Subject: SG-15 last meeting To: rem-conf@es.net Date: Tue, 4 Jun 1996 09:30:17 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 169 Hello, Does anybody knows if we're going to get on this list, or on the Internet, the happenings/results of the SG-15 last meeting at Geneva/May.96 ? Thanks, Luis From rem-conf-request@es.net Tue Jun 04 09:59:35 1996 Received: from speedy.grolier.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Jun 1996 06:59:06 -0700 Received: from vto1 (ppp-206-65.neuilly.club-internet.fr [194.117.206.65]) by speedy.grolier.fr (8.7.5/MGC-960516) with SMTP id PAA16400 for ; Tue, 4 Jun 1996 15:58:03 +0200 (MET DST) Message-ID: <31B4B901.3C63@deltabeta.com> Date: Tue, 04 Jun 1996 15:30:25 -0700 From: "Henry C. DeBey" Reply-To: debey@deltabeta.com Organization: Delta Beta Pty. Ltd. X-Mailer: Mozilla 3.0b3Gold (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Statistics on MBone sessions. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I would like to get some idea of the numbers of particpants in past MBone multicasts. Can someone provide some pointers to results of mlisten monitoring or other statistics on MBone participation? Henry From rem-conf-request@es.net Tue Jun 04 15:45:17 1996 Received: from calvin.dgbt.doc.ca by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Jun 1996 12:44:32 -0700 Received: by calvin.dgbt.doc.ca (4.1/SMI-4.1) id AA14273; Tue, 4 Jun 96 15:44:29 EDT Date: Tue, 4 Jun 96 15:44:29 EDT From: andrew@calvin.dgbt.doc.ca (Andrew Patrick) Message-Id: <9606041944.AA14273@calvin.dgbt.doc.ca> Reply-To: andrew@calvin.dgbt.doc.ca X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rem-conf@es.net Subject: CRC Open House on the MBONE (June 14) CRC Open House on the MBONE Friday June 14, 1996 9:00am - 5:00pm EDT Once every two years or so, Industry Canada's Communications Research Centre in Ottawa opens its gates so that visitors can see for themselves the communications research programs, the licensing opportunities, and the facilities that are open for business. This year we will be demonstrating the Internet MBONE applications to people who visit our labs in Ottawa, and we want to invite MBONE users from around the world to participate. Join the MBONE session and interact with our visitors in Ottawa. Learn more about the CRC and the various research programs conducted here. To faciliate good interactions, we suggest you: - transmit video if possible so we can see each other - limit your video transmission to a low rate (e.g., 10-20 Kbps), so we can have many simultaneous views. - ask questions and tell us about yourself - have fun! For more information about this MBONE event, contact Andrew.Patrick@crc.doc.ca. NOTE: the session will be announce in SDR. -- Andrew Patrick, Ph.D. Networks Services & Interfaces Laboratory Communications Research Centre http://debra.dgbt.doc.ca/ From rem-conf-request@es.net Wed Jun 05 00:17:02 1996 Received: from radvision.rad.co.il by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Jun 1996 21:16:34 -0700 Received: by firewall.radvision.rad.co.il id <24194>; Wed, 5 Jun 1996 08:12:27 +0300 From: Tanir Danon To: "'rem-conf@es.net'" Date: Wed, 5 Jun 1996 17:15:00 +0300 Message-Id: <96Jun5.081227idt.24194@firewall.radvision.rad.co.il> Encoding: 37 TEXT X-Mailer: Microsoft Mail V3.0 > How might I get information on who is using video over LANs (especially > ethernet), how it is being done, how well it performs, what vendors provide > video server and multimedia products, etc. RADVision provides communication solutions for running H320 Videoconferencing over LANs (Ethernet & Token Ring) while still enabling access to the WAN via RADVision Video Gateway. The OnLAN solution not only provides a reliable H.320 videoconferencing connection on standard Ethernet but also provides a Gateway connecting videoconferencing on LAN to WAN. This unique solution brings meeting-room quality to every desk, at rates of up to 384Kbps, using existing network infrastructure. The ability to perform +Call Transfer+ and +Call Forwarding+ are part of the +PBX+ functionality that OnLAN delivers. System support of multicast (one to many) sessions is an added feature. OnLAN is a system. It consists of codec interface options (software or hardware), Video Gateways and management utilities. It connects to any H.320 compliant videoconferencing equipment that can utilize one of the OnLAN interface options. For further details please contact: In the U.S. Shyke Gordon Tel 201529 4300 email - shy.radv@nis.net Outside of U.S. Tanir Danon Tel. - 972-3-645-5272 email - tanir@radvision.rad.co.il Tanir Danon RADVision Ltd From rem-conf-request@es.net Wed Jun 05 01:01:30 1996 Received: from radvision.rad.co.il by osi-west.es.net with ESnet SMTP (PP); Tue, 4 Jun 1996 22:01:00 -0700 Received: by firewall.radvision.rad.co.il id <24193>; Wed, 5 Jun 1996 08:56:52 +0300 From: Tanir Danon To: "'rem-conf@es.net'" Subject: re: Video Over LAN Date: Wed, 5 Jun 1996 18:00:00 +0300 Message-Id: <96Jun5.085652idt.24193@firewall.radvision.rad.co.il> Encoding: 37 TEXT X-Mailer: Microsoft Mail V3.0 > How might I get information on who is using video over LANs (especially > ethernet), how it is being done, how well it performs, what vendors provide > video server and multimedia products, etc. RADVision provides communication solutions for running H320 Videoconferencing over LANs (Ethernet & Token Ring) while still enabling access to the WAN via RADVision Video Gateway. The OnLAN solution not only provides a reliable H.320 videoconferencing connection on standard Ethernet but also provides a Gateway connecting videoconferencing on LAN to WAN. This unique solution brings meeting-room quality to every desk, at rates of up to 384Kbps, using existing network infrastructure. The ability to perform +Call Transfer+ and +Call Forwarding+ are part of the +PBX+ functionality that OnLAN delivers. System support of multicast (one to many) sessions is an added feature. OnLAN is a system. It consists of codec interface options (software or hardware), Video Gateways and management utilities. It connects to any H.320 compliant videoconferencing equipment that can utilize one of the OnLAN interface options. For further details please contact: In the U.S. Shyke Gordon Tel 201529 4300 email - shy.radv@nis.net Outside of U.S. Tanir Danon Tel. - 972-3-645-5272 email - tanir@radvision.rad.co.il Tanir Danon RADVision Ltd From rem-conf-request@es.net Wed Jun 05 03:48:41 1996 Received: from garfield.CS.Berkeley.EDU by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jun 1996 00:47:58 -0700 Received: from garfield.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1]) by garfield.CS.Berkeley.EDU (8.6.11/8.6.9) with ESMTP id AAA11475; Wed, 5 Jun 1996 00:47:36 -0700 Message-Id: <199606050747.AAA11475@garfield.CS.Berkeley.EDU> From: Andrew Swan To: rem-conf@es.net Cc: drbacher@cs.Berkeley.EDU Subject: alpha release of rtcp monitor program X-URL: http://www.cs.berkeley.edu/~aswan/ Date: Wed, 05 Jun 1996 00:47:31 -0700 Sender: aswan@plateau.CS.Berkeley.EDU An alpha release of rtpmon, which displays the information sent in RTCP Receiver Report messages, is now available from ftp://mm-ftp.cs.berkeley.edu/pub/rtpmon/ The README file is included here. Questions, comments, etc.. to rtpmon@bmrc.berkeley.edu. -- Rtpmon 1.0 Alpha Release David Bacher (drbacher@cs.berkeley.edu) Andrew Swan (aswan@cs.berkeley.edu) Rtpmon is a tool for viewing RTCP feedback packets from a session using the Real-Time Transport Protocol (RTP). It presents loss rate and jitter information from RTCP Receiver Report (RR) packets in a tabular format. The table can be sorted by various parameters and the recent history of reports from a particular receiver can be viewed in a stripchart. This is an alpha release of rtpmon. The basic functionality is in place although we still plan to add many enhancements. We are making it available now so that we can get feedback and make it as useful as possbile. There is not yet any formal documentation although rtpmon is relatively simple so it should be easy to use. The source code is available via anonymous ftp from: ftp://mm-ftp.cs.berkeley.edu/pub/rtpmon/rtpmon.tar.gz We also plan to make pre-compiled binaries available there. If you have compiled rtpmon on a platform for which a binary is not available, please let us know so that we can make it available from our ftp site. Compiling and installing rtpmon is (hopefully!) a painless process. You need Tcl 7.5 and Tk 4.1, both of which are available from ftp://ftp.smli.com/pub/tcl. You also need a C++ compiler. All of our development has been done using the GNU C and C++ compilers but the code does not take advantage of any features unique to them. To simplify the process of building rtpmon from source, a configuration script produced using GNU autoconf is included. The configure script has two optional arguments, --with-tcl=/path and --with-tk=/path. These should be used if the configure script cannot find your Tcl and Tk libraries. More details about GNU autoconf and how to use the configure script are available at in the autoconf documentation, available via www at http://www.ai.mit.edu/!info/autoconf.info/!!first. We're very interested in getting feedback to make rtpmon useful. Pleae send bugs, comments, suggestions, etc.. to rtpmon@bmrc.berkeley.edu. If you would like to be notified by e-mail of future releases, send a note to the same address. -- Andrew Swan aswan@cs.berkeley.edu Plateau Multimedia Research Group http://www.cs.berkeley.edu/~aswan/ From rem-conf-request@es.net Wed Jun 05 06:33:48 1996 Received: from didier.ee.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jun 1996 03:33:13 -0700 Received: from duchess.ee.gatech.edu (duchess.ee.gatech.edu [130.207.230.13]) by didier.ee.gatech.edu (8.7.5/8.7.2) with ESMTP id GAA29338; Wed, 5 Jun 1996 06:32:12 -0400 (EDT) From: Joe Ammond Received: (ammond@localhost) by duchess.ee.gatech.edu (8.6.9/8.6.9) id GAA19898; Wed, 5 Jun 1996 06:32:10 -0400 Message-Id: <199606051032.GAA19898@duchess.ee.gatech.edu> Subject: Broadcast of _Starchild: The Opera_ To: rem-conf@es.net, mbone@cilea.it Date: Wed, 5 Jun 1996 06:32:10 -0400 (EDT) X-Phone: (404) 894-7346 X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The Georgia Institute of Technology would like to broadcast audio and low-bandwidth still-frame video from the new opera _Starchild_, by composer James Oliverio. From the Starchild page: StarChild tells the epic tale of two souls separated near the beginning of Time and their constant struggle towards reunion across the light years. Although it references classical opera in scope and development, it is distinctly cinematic and twentieth-century in its esthetic. Set in six scenes, the work progresses on several levels simultaneously. Major themes, including the tenacity of love, the evolution of human consciousness, and our changing paradigm of the universe, are woven throughout the musical and visual imagery. More information can be found at the Starchild Web page at http://www.gatech.edu/starchild/ The broadcast would start at 8:00PM EST, and continue until 10:30PM EST. We would like to apologise for the short notice of this request, but until recently we were not sure if we would have everything needed to pull this off. If there are no booking problems, I will announce the session in 'sdr' this afternoon. ja. -- Joe Ammond ammond@ee.gatech.edu From rem-conf-request@es.net Wed Jun 05 09:53:02 1996 Received: from relay2.eunet.fr by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jun 1996 06:52:32 -0700 Received: from alpes.eurecom.fr by relay2.eunet.fr (5.65c8d/96.05.03) via EUnet-France id AA17877; Wed, 5 Jun 1996 15:51:08 +0200 (MET) Received: from nebin.eurecom.fr by alpes.eurecom.fr (4.1/SMI-4.0) id AA22185; Wed, 5 Jun 96 15:53:37 +0200 Return-Path: Organization: Eurecom, Sophia-Antipolis, France Received: from localhost by nebin.eurecom.fr with 4.1/2.28 id ; Wed, 5 Jun 96 15:53:35 +0200 Message-Id: <9606051353.AA09867@nebin.eurecom.fr> X-Mailer: exmh version 1.6.7 5/3/96 To: debey@deltabeta.com Cc: rem-conf@es.net Subject: Re: Statistics on MBone sessions / Web-page multicasting In-Reply-To: debey's message of Tue, 04 Jun 96 15:30:25 -0700 X-Face: +*!YJ>tO{UEuAf!2V7@zr[0U)psHFTZN[i\-O$v7kkuP?Ec!\91`|l:NQZwD6EnE{nMtS*Ha9enYx^BA4PjHT.@"?7r#UaaJRB"IHEhe"O@z#V]tu:ZqyQ:DW{@SCwanC>N0FC`Z:tJ8sA}6=n{#UA4-tPht_(A\jvs+EquH?4`[_Ft,Zc?{,k9&k+WooGf#{`?}4\Ol-[]G<_)c|wMA=Ct7&#l&"[&/@.0G2[6Pr:bvR5LQl[82k9zji*(8\nk\ X-Uri: http://www.eurecom.fr/~nonnen Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Jun 96 15:53:34 +0200 From: Jorg Nonnenmacher > I would like to get some idea of the numbers of particpants in past > MBone multicasts. Can someone provide some pointers to results of > mlisten monitoring or other statistics on MBone participation? > > Henry > > At Georgia Tech they made some measurements about ip-multicast concerning group-size join-and leave behaviour, etc. The PhD student K. Almeroth of M. Ammar did this. The best thing is to look up his homepage: http://www.cc.gatech.edu/computing/Telecomm/people/Phd/kevin/kevin.html M.H.Ammar developped also a transport mechanism for multicasting Web-Pages, and accumulating requests for hot pages. Of course it is reliable transport. They looked at response time then. Joerg =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= JOERG NONNENMACHER Institut Eurecom Phone : +33 93 00 26 18 2229, route des Cretes Fax : +33 93 00 26 27 BP 193 Secr. : +33 93 00 26 64 06904 Sophia Antipolis E-Mail: nonnen@eurecom.fr cedex FRANCE URL : http://www.eurecom.fr/~nonnen ------------------------------------------------------------------------------- Video macht Kinder froh und Erwachsene ebenso. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From rem-conf-request@es.net Wed Jun 05 10:42:52 1996 Received: from didier.ee.gatech.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jun 1996 07:42:27 -0700 Received: from duchess.ee.gatech.edu (duchess.ee.gatech.edu [130.207.230.13]) by didier.ee.gatech.edu (8.7.5/8.7.2) with ESMTP id KAA05980 for ; Wed, 5 Jun 1996 10:42:25 -0400 (EDT) From: Joe Ammond Received: (ammond@localhost) by duchess.ee.gatech.edu (8.6.9/8.6.9) id KAA27165 for rem-conf@es.net; Wed, 5 Jun 1996 10:42:24 -0400 Date: Wed, 5 Jun 1996 10:42:24 -0400 Message-Id: <9606051042.ZM27163@duchess.ee.gatech.edu> X-Mailer: Z-Mail (3.2.0 06sep94) To: rem-conf@es.net Subject: Re: Broadcast of _Starchild: The Opera_ Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I had a thinko this morning and forgot to include the date that we'd like to do the broadcast. Today, June 5th, from 8:00PM to 10:30PM. ja. -- Joe Ammond ammond@ee.gatech.edu From rem-conf-request@es.net Wed Jun 05 18:26:47 1996 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jun 1996 15:26:16 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id PAA19640; Wed, 5 Jun 1996 15:26:40 -0700 Message-Id: <199606052226.PAA19640@rx7.ee.lbl.gov> To: Andrew Swan cc: rem-conf@es.net, drbacher@cs.Berkeley.EDU Subject: Re: alpha release of rtcp monitor program In-reply-to: Your message of Wed, 05 Jun 96 00:47:31 PDT. Date: Wed, 05 Jun 96 15:26:40 PDT From: Van Jacobson Cool tool! Nice job Andrew & David! If people want to integrate rtpmon with vat and/or vic, you can copy the following tcl code to file ~/.vat.tcl and/or ~/.vic.tcl and it will add a "monitor" button next to the "menu" button. Click on "monitor" & it will start an rtpmon for the vat or vic session. (Note that you have to be running the beta version or later of vic/vat for this to work. The alpha versions don't have the tcl "user_hook".) - Van ============= copy to ~/.vat.tcl and/or ~/.vic.tcl proc start_rtpmon { } { global V set net $V(data-net) exec rtpmon -t 0 -C [resource conferenceName] [$net addr]/[$net port] & } proc mk.rtpmon { w } { button $w.rtpmon -text Monitor \ -font [smallfont] -highlightthickness 1 \ -command start_rtpmon pack $w.rtpmon -after $w.menu -side left -pady 1 -padx 1 } proc user_hook {} { global V if {$V(sessionType) == "rtp"} { if {$V(app) == "vic"} { set w .top.bar } else { set w .bar } mk.rtpmon $w } } From rem-conf-request@es.net Wed Jun 05 21:45:01 1996 Received: from tama.tas.ntt.jp by osi-west.es.net with ESnet SMTP (PP); Wed, 5 Jun 1996 18:44:18 -0700 Received: by tama.tas.ntt.jp (8.7.5/tas-sh-02) with TCP; Thu, 6 Jun 1996 10:44:44 +0900 (JST) Received: by nttmail.tas.ntt.jp (8.6.12/nttmail-02) with TCP; Thu, 6 Jun 1996 10:44:14 +0900 Received: by nttvdt.hil.ntt.jp (8.6.9/hil-1.1); Thu, 6 Jun 1996 10:44:07 +0900 Message-Id: <199606060144.KAA23316@nttvdt.hil.ntt.jp> Date: Thu, 6 Jun 1996 10:43:59 +0900 From: jinzen@nttvdt.hil.ntt.jp (Hiroshi Jinzenji) To: rem-conf@es.net Cc: sv@www-hil.tas.ntt.jp Subject: Propose RSTP & SoftwareVision Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Dear all, We are working on the video transport protocol over the Internet, RSTP (Real-time Stream Transport Protocol). RSTP's applications are video broadcasting and video on demand, not bi-directional application, such as video conference. SoftwareVision, that is H.261 based video broadcasting system, is currently implemented on RSTP. RSTP concept consists to achieve scalable video, minimum transmission and best video quality under every condition. Our method must send video without packet loss, so it uses TCP. RTP and Multicast is a good choice for a real-time communication, but We think it is not suitable for video mass broadcasting and stored video on demand services. Many Internet user, almost dial-up users, can't access Mbone now. We want to apply those applications and those situations. Now, SoftwareVision, using RSTP, Home Page is open. And SoftwareVision clients is distributed on this page. Please evaluate and comment our system. URL: http://www.hil.ntt.jp/SoftwareVision/index-e.html If you are interested, here follows a description of the RSTP. This document is a brief version of DAVIC/CFP4_018, that is submitted to "The Digital Audio Visual Council" DAVIC's forth call for proposals section 5.4 Access to services of the Internet d). Thank you, Hiroshi Jinzenji - NTT ECL -------------------------------------------------------------- Hiroshi JINZENJI Visual Communication Laboratory, NTT Human Interface Laboratories Nippon Telegraph and Telephone Corporation 1-2356 Take Yokosuka-shi, Kanagawa 230-03 Japan [EM: jinzen@nttvdt.hil.ntt.jp TEL: +81-468-59-3550 FAX: +81-468-59-2829] BEGIN DOCUMENT--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- SoftwareVision: A Scalable Video Distribution Technique for the Internet 1 Introduction This document covers the use of scalable signals for real time audio and video on the Internet. Real-time Stream Transport Protocol (not RTP) provides server-clients network transport functions suitable for transmitting real-time data, such as audio or video, over TCP transport. SoftwareVision, that is H.261 based video broadcasting system, is currently implemented on RSTP. RSTP can change data stream rate depending on the situations of server, network and clients. The situation is monitored by clients, and all controls are driven by the clients. Therefore RSTP is considered as a client oriented protocol. RSTP achieves a scalable video transmission and a efficient transmission without useless stream data. RSTP is implemented on a single end-to-end TCP connection, like a HTTP for WWW, so it is easy to build a relay server and a proxy server. 2 RSTP Use Scenario RSTP is implemented over TCP/IP. Both of control commands and stream data are transported over TCP/IP. RSTP's goal is to realize a video broadcasting framework, consisting of distribution servers, relay servers, and software based clients, on the Internet (not Mbone). Even Dial UP users can enjoy broadcasted video segments in the RSTP framework. This framework supports, typically, a live video broadcasting and a video on demand system. RSTP uses a same video stream every situation. The basic concept is abandonment of data transmission under bad conditions, such as a high load condition of severs, network congestion, a narrow band network and low performance clients. The requirements on video stream encoding are 1) partitioning video stream into cyclic time slots and 2) rearranging transmission packets according to priority for decoding. Every packet has a timestamp for synchronized decoding. Under a bad condition, a client requests only higher priority packets, which are placed at the front of the time slot, and abandon the other packets. The number of packets to retrieve are changed according to the condition. Then the clients request high priority packets of the next time slot in order to synchronize. SoftwareVision uses a full-INTRA frame as high priority packets for H.261, currently. But the encoding scheme is not restricted to H.261. The above concept is shown in "http://www.hil.ntt.jp/SoftwareVision/index-e.html". 3 Expression to locate a Distributed Real-time Stream Content The clients use the following expression to locate a distributed content when they request a server to transmit a stream. The syntax is similar to URL. RSTP://{hostname}[:{portnum}]/{content} *{ } means a parameter field. *[ ] means that the field can be omitted. hostname: Internet address portnum: Server*s TCP Listen port number content: The name of the content 4 Specification of RSTP RSTP is built on a single TCP connection between a client and a server. After initializing sequence of the TCP connection, RSTP begins with a negotiation mode, which is used to carry a client*s content request and a server's acknowledgment. Next, RSTP shifts to a stream transmission mode. 4.1 Negotiation Mode In the negotiation mode, text type commands are used, like SMTP and POP, because it is easy to maintain a server and to access to it by "telnet". RSTP servers open TCP port and wait for a client*s connection. First, a RSTP client connects to a RSTP server in the negotiation mode. The following commands are used in the negotiation mode. (Carriage Return) terminates a command to allow variable message length. * Server welcome message +OK RSTP/X.X/ [{optional message}] * X.X is RSTP version number. * Client Request command REQ RSTP://{hostname}[:{portnum}]/{content} * Server Ack command +OK [{optional message}] * Server Nack command -NG [{optional message : error message}] * Shift command to stream transmission mode BIN * Server Ack for shift to stream transmission mode BIN 4.2 Stream Transmission Mode The stream transmission mode uses a binary mode to achieve a fast response. Only two types are defined as client data transmission request commands: a high priority data request and a subsequent data request. RSTP header is attached to the data transferred from a server. ## Command and Header formats are omitted. * High priority data request (client -> server) This command requests a server to transfer high priority data with the specific timestamp, that is a top priority packets arranged at the front of the time slot. This command has two parameters, a target time and a number of packets to transfer. The server sends the packets that have the timestamp close to the target time. * Subsequent data request (client -> server) This command requests a server to transfer stream data following the last transferred data. This command has a parameter, a number of packets to transfer. * RSTP stream data format (server -> client) The header size is 9 bytes. * Termination command (client -> server, server -> client) This command closes a connection from a client or a server. This command is used at the end of a stream on server. A client can also issue this command to request termination. 4.3 RSTP protocol sequence RSTP protocol sequence is shown in "http://www.hil.ntt.jp/SoftwareVision/index-e.html". END DOCUMENT--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- From rem-conf-request@es.net Thu Jun 06 11:18:05 1996 Received: from ocate.edu (actually 198.106.198.40) by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jun 1996 08:17:25 -0700 Received: by ocate.edu (/\==/\ Smail3.1.28.1 #28.23) id ; Thu, 6 Jun 96 08:17 PDT Message-ID: Date: 6 Jun 1996 08:10:07 -0800 From: Danm Subject: subscribe To: rem-conf@es.net X-Mailer: Mail*Link SMTP-MS 3.0.2 subscribe Dan Mathews From rem-conf-request@es.net Thu Jun 06 18:23:42 1996 Received: from gatekeeper.sprintlabs.com (actually dmz.sprintlabs.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jun 1996 15:23:14 -0700 Received: by gatekeeper.sprintlabs.com id AA19466 (5.67b/IDA-1.5 for ); Thu, 6 Jun 1996 15:23:49 -0700 Message-Id: <199606062223.AA19466@gatekeeper.sprintlabs.com> Received: from unknown(199.2.53.28) by gatekeeper.sprintlabs.com via smap (V3.1) id xma019464; Thu, 6 Jun 96 15:23:45 -0700 X-Sender: aollikai@gatekeeper Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Jun 1996 15:25:07 -0700 To: rem-conf@es.net From: ari@sprintlabs.com (Ari Ollikainen) Subject: Re: Propose RSTP & SoftwareVision jinzen@nttvdt.hil.ntt.jp (Hiroshi Jinzenji) wrote > >We are working on the video transport protocol over the Internet, >RSTP (Real-time Stream Transport Protocol). RSTP's applications are >video broadcasting and video on demand, not bi-directional application, >such as video conference. SoftwareVision, that is H.261 based video >broadcasting system, is currently implemented on RSTP. > >RSTP concept consists to achieve scalable video, minimum transmission and >best video quality under every condition. Our method must send video without >packet loss, so it uses TCP. > >RTP and Multicast is a good choice for a real-time communication, >but We think it is not suitable for video mass broadcasting and stored video >on demand services. Many Internet user, almost dial-up users, can't access >Mbone now. We want to apply those applications and those situations. > Since no one else has mentioned this, I suggest that you take a look at Vosaic (www.vosaic.com) which, allegedly, solves the same problem with "... a network bandwidth friendly algorithm that avoids congestion. It uses: VDP: - A Video Datagram Protocol that operates end-to-end, - the standard UDP network protocol, - a best effort, adaptive flow control, - a control loop that adapts to network conditions, - and adapts to client side CPU conditions. ..." Unfortunately, the Netscape plug-in that would have allowed me to see the Vosaic technical presentation blows up on my PowerMac... _/_/ _/_/_/_/ _/ Ari Ollikainen _/ _/ _/ _/ _/ Sprint Advanced Technology Laboratories _/_/_/_/ _/_/_/_/ _/ 1 Adrian Court (M/S: CABURS0102) _/ _/ _/ _/ _/ Burlingame, CA 94010 _/ _/ _/ _/ _/ Voice: 415 375 4265 FAX: 415 375 4490 ~~RECOM Technologies Inc.~~ From rem-conf-request@es.net Thu Jun 06 19:11:09 1996 Received: from atg.apple.com by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jun 1996 16:10:32 -0700 Received: from [17.255.9.143] (jpallas.atg.apple.com [17.255.9.143]) by atg.apple.com (8.7.2/8.6.12) with SMTP id QAA26371 for ; Thu, 6 Jun 1996 16:07:35 -0700 (PDT) X-Sender: pallas@apple.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Jun 1996 16:10:27 -0700 To: rem-conf@es.net From: Gordon Garb (by way of Pallas@Apple.COM \(Joe Pallas\)) Subject: MBone concert planned The QuickTime Live! team plans to multicast a live concert by Metallica. The event is Monday, June 10th, from 9pm to 12 midnight, PDT. For a description of the event beyond "Metallica live concert for their fans to launch their new album - LOAD" look at the web page, http://live.apple.com/metallica/ The session will use RTPv2 PCM audio and H.261 video, and be announced with sdr. If there are conflicts or questions, contact ggarb@apple.com. From rem-conf-request@es.net Thu Jun 06 19:12:45 1996 Received: from basil.cdt.luth.se by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jun 1996 16:11:50 -0700 Received: from dragos (dragos.cdt.luth.se [130.240.142.26]) by basil.cdt.luth.se (8.7.5/8.7.3) with ESMTP id BAA08311 for ; Fri, 7 Jun 1996 01:08:55 +0200 (MET DST) Received: from dragos (localhost [127.0.0.1]) by dragos (8.6.12/8.6.12) with ESMTP id BAA09340 for ; Fri, 7 Jun 1996 01:12:33 +0200 Message-Id: <199606062312.BAA09340@dragos> X-Mailer: exmh version 1.6.6 3/24/96 To: rem-conf@es.net Subject: conference room equipment Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jun 1996 01:12:31 +0200 From: Johnny Widen We have been using MBone on a regular basis for about 1.5 years. Our offices are equiped with Sun Sparcs and Ultras with cameras, mikes, stereo receivers and loudspeakers giving us a "virtual open space office", which we use daily for internal discussions. We have been giving seminars locally on MBone. And of course, we follow what ever interesting happening on the MBone. We have also temporarily set up MBone conferences from a bigger room, with many people participating from that room. For example we participated in a nation wide forming of a culture society, using MBone. We are now in the process of setting up one permanent room (an old class room) and two theatre like rooms (for 100+ people) at the university to be used for - demonstrations - MBone conferences - MBone lectures The question is: How? This is our approach: Display a big screen Liesegang dv1024 projector (Probably Barco 808G for the theatre) Computers Computer 1, Sun Ultra 170E, SunVideo board its display to be shown on the big screen Computer 2, Sun Ultra 140 for MBone operator control, wb discussions, vat, RS232 control of cameras and video switcher Computer 3, PC, some frame grabber, which? for people prefering this kind of platform for demo Video in Camera 1, Canon VC-C1, RS232 control showing the speaker Camera 2, Canon VC-C1 showing the audience, RS232 control VCR, Mitsibushi 1000? Document camera, ? for documents and plastic slides Video out Projector, Liesegang dv1024 (Probably Barco 808G for the theatre) VCR, Mitsibushi 1000? Computer {1,2,3} Monitor to view the different video sources before sending them Sound Stereo amplifier, loud speakers Body mike for the speaker Handhold cordless mike for the audience Others Video switcher matrix 4x4, Y/C & composite, RS232 controllable to switch the different video ins and outs TBC alike gear (Time Base Corrector) to manage distortion free switching to the VCR video source Most of the above equipment have been ordered. This design is mainly for speeches/lectures, recently we have been discussing the possibility to use the smaller room for "discussion" conferences. A gang sitting in that room disussing with the people sitting in their offices. In this case, the bode mike and the handhold mike would not be enough. We need some general mike, or several mikes. This will get us echoing problems. How to manage that? An expensive echo-canceller? Choosing the computer display to be shown will be done manually. We think that we either use Computer 1 or Computer 3 for this. The video matrix switcher 4x4 is full for a start. Are there more equipment we haven't thought of yet? For those interested I have more information on exactly which brand of equipment we have ordered. I don't have that at hand right now. The speaker will control the display that is showned on the screen. An operator will control the controlling computer. So, what do you say? Is this the way to go? How have you done it? What about RS232 controlling software? I think there are camera software for the Sun, but what about video switcher software? Our budget is rather limited. We can't afford the professional M$-equipment that would solve all this for us. -- Johnny http://www.cdt.luth.se/~johnny http://www.cdt.luth.se/ From rem-conf-request@es.net Thu Jun 06 22:10:36 1996 Received: from ntnet3.ksc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jun 1996 19:09:54 -0700 Received: by ntnet3.ksc.nasa.gov with Microsoft Exchange (IMC 4.0.837.3) id <01BB53F4.F6947270@ntnet3.ksc.nasa.gov>; Thu, 6 Jun 1996 22:10:25 -0400 Message-ID: From: "Kyramarios, Steve" To: Rem-Conf Subject: NASA's DC-XA single-stage rocket Date: Thu, 6 Jun 1996 16:30:00 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Encoding: 17 TEXT Sorry for the late notice, but NASA-KSC would like to broadcast the second in a series of five test flights planned for NASA's Delta Clipper-Experimental Advanced (DC-XA) single- stage rocket. The coverage is scheduled to begin around 11:15 E.D.T.. If conditions permit, another flight of the DC-XA may be attempted around 8pm. The broadcast will advertised in sdr. Audio: GSM Video: H.261 ttl: 127 Please direct all comments to Steve Kyramarios at skyramarios@mail.arc.nasa.gov. From rem-conf-request@es.net Thu Jun 06 23:57:23 1996 Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jun 1996 20:56:41 -0700 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA28726; Thu, 6 Jun 96 23:56:39 EDT Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA11166; Thu, 6 Jun 96 23:56:37 EDT Received: by smtpnotes.pictel.com (4.1/SMI-4.1) id AA09723; Thu, 6 Jun 96 23:56:36 EDT Message-Id: <9606070356.AA09723@smtpnotes.pictel.com> Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id F8BF31DF7851AD8B852563420012A149; Fri, 7 Jun 96 03:56:34 To: Luis de Pieri Cc: confctrl , rem-conf , IMTC From: Rich Baker/PicTel Date: 6 Jun 96 23:49:31 EDT Subject: (CNC) Re: SG-15 last meeting Mime-Version: 1.0 Content-Type: Text/Plain I am pleased to announce that H.323 was "Decided" at the SG15 meeting in Geneva last Tuesday. In ITU-T parlance, that makes H.323 as good as a "Standard", since the final step (an official vote, nation-by-nation, with 70% approval) virtually always is achieved. So... o Given the number of major manufacturers already in the process of developing interworking H.323 implementations; o Given H.323's adoption of RTP/RTCP; o Given H.323's compatibility with RSVP; o Given H.323's comprehensive support of edge gateways to H.320/H.324 (ISDN/POTS) standards based terminals, which permit WAN-based and Internet-based terminals to easily conference and interwork... ... I have confidence that H.323 is poised to become the intranet and internet standard for videoconferencing. Another step towards this goal was made last month. The IMTC CNC activity group I chair formed an "H.323 Implementators" subgroup, chaired by Jim Toga, to facilitate vendors building H.323 products. Those interested in joining should contact myself (bake@pictel.com) or Jim (jtoga @ ibeam.jf.intel.com). Later this month work begins on the next phase of H.323 standards development. Many, many thanks to the tireless efforts of the folks who made it all happen, particulary our intrepid (and sleep deprived...) editors: o Gary Thom (Delta Information Systems), H.323 Editor o Dale Skran (Lucent), H.224 Editor o Mark Reid (PictureTel), H.245 extensions Editor ... and to Sakae OKUBO (Graphics Communication Laboratories, okubo@gctech.co.jp), who is the Rapporteur for this work inside SG15. Cheers, -rich baker IMTC Corporate Network Conferencing AG Chair PictureTel Corporation bake@pictel.com ===== To: confctrl @ ISI.EDU @ smtp From: ldepieri @ ifhamy.insa-lyon.fr (Luis de Pieri) @ smtp Date: 06/05/96 09:01:54 AM Subject: SG-15 last meeting Hello, Does anybody knows if we're going to get on this list, or on the Internet, the happenings/results of the SG-15 last meeting at Geneva/May/96 ? Thanks, Luis From rem-conf-request@es.net Fri Jun 07 02:30:04 1996 Received: from dns2.noc.best.net by osi-west.es.net with ESnet SMTP (PP); Thu, 6 Jun 1996 23:29:37 -0700 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id XAA11473 for ; Thu, 6 Jun 1996 23:29:35 -0700 Date: Thu, 6 Jun 1996 23:29:35 -0700 (PDT) From: edgemedia X-Sender: intelinc@shellx.best.com To: rem-conf@es.net Subject: Live Metallica Webcast Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello all, Apple computer is planning to multicast a special fan club-only Metallica concert from San Francisco on June 10, 1996, from 9 PM-midnight PST. This concert will also be rebroadcast from 9 AM until noon the following morning (June 11). Any questions of comments can be sent to ggarb@apple.com. From rem-conf-request@es.net Fri Jun 07 04:04:23 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 01:03:52 -0700 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Fri, 7 Jun 1996 10:01:54 +0200 X-Mailer: exmh version 1.6.7 5/3/96 To: ari@sprintlabs.com (Ari Ollikainen) cc: rem-conf@es.net, jinzen@nttvdt.hil.ntt.jp From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: Propose RSTP & SoftwareVision In-reply-to: Your message of "Thu, 06 Jun 1996 15:25:07 PDT." <199606062223.AA19466@gatekeeper.sprintlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jun 1996 10:01:09 +0200 Sender: schulzrinne@fokus.gmd.de Hiroshi Jinzenji: (Description of RSTP deleted). It might be helpful to discuss why you feel that RTP is not suitable for video distribution. One might argue that having individual TCP streams for video data distribution is not exactly the most scaleable approach (besides the usual other problems of using TCP), besides that RTP runs just fine on top of TCP if you prefer that for some reason. RTP is not in any way tied to the use of the Mbone. The Vosaic approach appears fairly closed and proprietary; the paper available says little to nothing of technical detail, apparently as patents have been applied for. It should be noted that the bandwidth/CPU adaptation can readily be done within the RTP framework (see, among others, our Computer Communications paper for some experiments); indeed, that was a design goal. Henning From rem-conf-request@es.net Fri Jun 07 04:17:27 1996 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 01:16:29 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id KAA13168 (8.7.5/7.5b-FAU); Fri, 7 Jun 1996 10:16:24 +0200 (MET DST) From: Toerless Eckert Message-Id: <199606070816.KAA13168@faui40.informatik.uni-erlangen.de> Subject: Re: conference room equipment To: johnny@cdt.luth.se (Johnny Widen) Date: Fri, 7 Jun 1996 10:16:22 +0200 (MET DST) Cc: rem-conf@es.net In-Reply-To: <199606062312.BAA09340@dragos> from "Johnny Widen" at Jun 7, 96 01:12:31 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Ok, some comments on conferencing room equipment, and i'll only give small points because otherwise it would become endless. By the way: I'm setting up the very same thing here. - Projection system: If you do have 2 meters to spare behind the screen, try to set up a back-projection system. Much better lightening, and the option to use direct input devices and have the screen act as a whiteboard. - I like the Electrohome projectors due to the ACON automatic geometry adjusting system, but i guess barco is fine too (a bit expensive, isn't it ?) - I hate the SS12 system (Ultra1) because they do only have 2 SBus slots, i use SS20 and Ultraserver 3000 because they provide me with enough I/O to hold Parallax AND SunVideo and FDDI OR ATM and a RS-232 board. I guess the Ultra1 is just damned cheap. I also use the SlicVideo framegrabber because it can better adjust contrast, brightness and saturation than SunVideo and it can do CC decoding. - I've to admit i've got a PC too, vor the very same reasons than you *sigh*. Best source of trouble. - We've got an abundance of VC-C1 too, but i hope that the new sony camera on the horizon will improve on several points (price, simultaneous smooth pan & tilt, greater pan & tilt angle, ...). We still have to get them. - VCRs are a hassle. The professional ones give you a good steady picture, but they don't have any features. - We use the Extron video switchers and i guess they are quite good and can be controlled via RS232. - I guess you should also be looking for a echo cancellation system to improve audio. We use coherent. - If you want to be able to tape anything of what you do, either get a XVideo board or better an external scan converter. We've got a Folsom scan converter, but yes, it's too expensive and loud. But there are cheaper ones. - Controlling all this stuff is really a hassle. I've got 3 cameras, 2 switchers, 1 scan converter, 3 VCRs, 1 beamer, 1 mixer, 1 echo canceller, some consumer stuff (TV, sat-tv receiver,..) and they all want to be controlled by RS-232. Well, i've got a student working on it *grin*.... Best regards Toerless From rem-conf-request@es.net Fri Jun 07 05:22:24 1996 Received: from speedy.grolier.fr by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 02:21:22 -0700 Received: from vto1 (ppp-206-189.neuilly.club-internet.fr [194.117.206.189]) by speedy.grolier.fr (8.7.5/MGC-960516) with SMTP id LAA03341; Fri, 7 Jun 1996 11:20:03 +0200 (MET DST) Message-ID: <31B86C3A.42FF@deltabeta.com> Date: Fri, 07 Jun 1996 10:51:54 -0700 From: "Henry C. DeBey" Reply-To: debey@deltabeta.com Organization: Delta Beta Pty. Ltd. X-Mailer: Mozilla 3.0b3Gold (Win95; I) MIME-Version: 1.0 To: Hiroshi Jinzenji CC: rem-conf@es.net Subject: Re: Propose RSTP & SoftwareVision References: <199606060144.KAA23316@nttvdt.hil.ntt.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is there a difference between your references to "video broadcasting and video on demand" and "video mass broadcasting and stored video on demand"? Does "stored video on demand" mean the video is downloaded from a broadcast or multicast delivery and then accessed on demand from a local disk? Henry Hiroshi Jinzenji wrote: > > Dear all, > > We are working on the video transport protocol over the Internet, > RSTP (Real-time Stream Transport Protocol). RSTP's applications are > video broadcasting and video on demand, not bi-directional application, > such as video conference. SoftwareVision, that is H.261 based video > broadcasting system, is currently implemented on RSTP. > > RSTP concept consists to achieve scalable video, minimum transmission and > best video quality under every condition. Our method must send video without > packet loss, so it uses TCP. > > RTP and Multicast is a good choice for a real-time communication, > but We think it is not suitable for video mass broadcasting and stored video > on demand services. Many Internet user, almost dial-up users, can't access > Mbone now. We want to apply those applications and those situations. > > Now, SoftwareVision, using RSTP, Home Page is open. And SoftwareVision clients > is distributed on this page. > > Please evaluate and comment our system. > > URL: http://www.hil.ntt.jp/SoftwareVision/index-e.html From rem-conf-request@es.net Fri Jun 07 06:21:38 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 03:21:09 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 7 Jun 1996 11:20:49 +0100 To: Henning Schulzrinne cc: ari@sprintlabs.com (Ari Ollikainen), rem-conf@es.net, jinzen@nttvdt.hil.ntt.jp Subject: Re: Propose RSTP & SoftwareVision In-reply-to: Your message of "Fri, 07 Jun 1996 10:01:09 +0200." Date: Fri, 07 Jun 1996 11:20:42 +0100 Message-ID: <833.834142842@cs.ucl.ac.uk> From: Jon Crowcroft >It might be helpful to discuss why you feel that RTP is not suitable >for video distribution. One might argue that having individual TCP >streams for video data distribution is not exactly the most scaleable >approach (besides the usual other problems of using TCP), besides that >RTP runs just fine on top of TCP if you prefer that for some reason. >RTP is not in any way tied to the use of the Mbone. agreed.... there are moves afoot to define error correction protocols using RTP too - these may be "lighter" than TCP (and may not have unbounded delay behaviour - experience a few years back with running TCP over real internet paths to carry video over any realistic WQAN path was that the control algorithms for error recovery (rtt/rtx estimation and congestion avoidance) are NOT at all right even for loss free video - you want a combination of ARQ over low delay paths, and FEC over high delay paths.... >The Vosaic approach appears fairly closed and proprietary; the paper >available says little to nothing of technical detail, apparently as >patents have been applied for. It should be noted that the >bandwidth/CPU adaptation can readily be done within the RTP framework >(see, among others, our Computer Communications paper for some >experiments); indeed, that was a design goal. pointers to Vosaic protocol documentation would be very welcome! cheers jon From rem-conf-request@es.net Fri Jun 07 06:42:38 1996 Received: from tama.tas.ntt.jp by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 03:42:03 -0700 Received: by tama.tas.ntt.jp (8.7.5/tas-sh-02) with TCP; Fri, 7 Jun 1996 19:40:49 +0900 (JST) Received: by nttmail.tas.ntt.jp (8.6.12/nttmail-02) with TCP; Fri, 7 Jun 1996 19:40:19 +0900 Received: by nttvdt.hil.ntt.jp (8.6.9/hil-1.1); Fri, 7 Jun 1996 19:40:16 +0900 Message-Id: <199606071040.TAA25769@nttvdt.hil.ntt.jp> Date: Fri, 7 Jun 1996 19:40:07 +0900 From: jinzen@nttvdt.hil.ntt.jp (Hiroshi Jinzenji) To: rem-conf@es.net In-reply-to: <199606070805.RAA11331@tama.tas.ntt.jp> (message from Henning Schulzrinne on Fri, 07 Jun 1996 10:01:09 +0200) Subject: Re: Propose RSTP & SoftwareVision Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Dear all, Thank you for your comments. Following is my comment: Why I use TCP for RSTP. TCP, stream type transport, achieves reliable data deliverry. Video stream data is true stream type data. Someone says that reliable message delivery is not required for video and audio. I don't think so. Many video encoding scheme, MPEG, H.261, H.263, etc., uses Inter-Frame Predictive Coding. Using that conding scheme, random packet loss, including UDP transfer protocol, damage decoder. For example, if part of I frame data is lost, following frames data can't be decoded. Resend or next I frame data request algorithm is required. If using UDP, that algorithm has to be implemented on application layer. If using TCP, that algorithm is in TCP protocol layer. Under low speed network, such as a dialup connection, that algorithm is very important. RSTP concept consists to achieve scalable video, minimum transmission and best video quality under every condition. Our method doesn't permit packet loss and controls abandonment of trassmission data using TCP and client-orientd protocol. TCP is good choice (but not best), I think, to send video without packet loss. RSTP is used by not only server-client connections but also server-server connections. If packet loss occur on relay route, error is spreaded on lower clients and servers. Relay server implementation using RSTP is our main subject. In our system, relay servers is very important server to decrease duplicate flows. Using TCP, connection-oriented protocol, relay server and proxy server are simply implementation. RSTP's applications are uni-directional application, such as video broadcasting and video on demand, not bi-directional application, such as video conference. Bi-directional application doesn't permit delays. But in uni-directional application, Some jitters and delays are permitted, within the limits of severs and clients buffer. Our servers, originating, distribution and relay server, use a ring packet buffer scheme and thread programming in order to permit some jitters and delays. In our current implementation, servers and clients support multicast transport protocol, RSTP multicast extension. Multicast is good solution to deliver multi-server and multi-client, but it has a packet loss problem. Packet loss almost occur on a router. Our multicast extension is used on one segment broadcast type network, like a Ethernet and FDDI. Henning wrote; >> One might argue that having individual TCP >> streams for video data distribution is not exactly the most scaleable >> approach (besides the usual other problems of using TCP), besides that >> RTP runs just fine on top of TCP if you prefer that for some reason. >> RTP is not in any way tied to the use of the Mbone. RSTP data packet header isn't equal to RTP format now, but very similar. Perhaps I think that our system can deal with RTP format and works as robust a relay system. RSTP defines negotiation scheme for ondemand real-time media access and client-oriented transfer protocol. Henry wrote; >> Is there a difference between your references to "video broadcasting and >> video on demand" and "video mass broadcasting and stored video on demand"? No difference. >> Does "stored video on demand" mean the video is downloaded from a broadcast or >> multicast delivery and then accessed on demand from a local disk? Clients accesses stored video on server, and play video in real-time without using a local disk, such as StreamWorks, VDOlive and VOSAIC. Of course, if you want, you can record receiving stream to a local disk and play from a local disk. By the way, if you can access "www.hil.ntt.jp:7000" like a following, please download our client and evaluate our system from your machine. % telnet www.hil.ntt.jp 7000 Trying 192.68.248.31... Connected to www.hil.ntt.jp. Escape character is '^]'. +OK RSTP/1.0/ ^] rtelnet> quit Connection closed. % # Servers somtimes down without previous notice. ----------- Hiroshi Jinzenji jinzen!! From rem-conf-request@es.net Fri Jun 07 06:47:16 1996 Received: from speedy.grolier.fr by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 03:46:44 -0700 Received: from vto1 (ppp-206-189.neuilly.club-internet.fr [194.117.206.189]) by speedy.grolier.fr (8.7.5/MGC-960516) with SMTP id MAA11573; Fri, 7 Jun 1996 12:45:32 +0200 (MET DST) Message-ID: <31B886F5.2022@deltabeta.com> Date: Fri, 07 Jun 1996 12:45:57 -0700 From: "Henry C. DeBey" Reply-To: debey@deltabeta.com Organization: Delta Beta Pty. Ltd. X-Mailer: Mozilla 3.0b3Gold (Win95; I) MIME-Version: 1.0 To: jinzen@nttvdt.hil.ntt.jp CC: rem-conf@es.net Subject: Re: Propose RSTP & SoftwareVision Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiroshi Jinzenji wrote: (Message not included.) Is there a difference between references to "video broadcasting and video on demand" and "video mass broadcasting and stored video on demand"? Does "stored video on demand" mean the video is downloaded from a broadcast or multicast delivery and then accessed on demand from a local disk? Henry From rem-conf-request@es.net Fri Jun 07 10:55:43 1996 Received: from dns2.noc.best.net by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 07:54:52 -0700 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id HAA17302; Fri, 7 Jun 1996 07:53:09 -0700 Date: Fri, 7 Jun 1996 07:53:08 -0700 (PDT) From: edgemedia X-Sender: intelinc@shellx.best.com To: mbone@cilea.it cc: rem-conf@es.net Subject: Date switch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Accidentally switched info in the month and day fields. There is no Metallica webcast on November 6, 1996. Thanks Ryan From rem-conf-request@es.net Fri Jun 07 10:58:16 1996 Received: from ntnet3.ksc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 07:57:52 -0700 Received: by ntnet3.ksc.nasa.gov with Microsoft Exchange (IMC 4.0.837.3) id <01BB5460.46AE9220@ntnet3.ksc.nasa.gov>; Fri, 7 Jun 1996 10:58:36 -0400 Message-ID: From: "Kyramarios, Steve" To: Rem-Conf Subject: DC-XA single-stage rocket Date: Fri, 7 Jun 1996 09:15:00 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 Encoding: 26 TEXT All, The date of the DC-XA broadcast is Friday, June 7th. Sorry for forgetting to add this critical piece of data. The existing protocol for broadcasting such programs is to wait for a request before broadcasting on the mbone. This of course is not the case for STS missions, but for the majority of all other programs broadcasted on NASA-TV. If interested parties could visit http://www.hq.nasa.gov/office/pao/ntv.htmv on a frequent basis and contact me for mbone transmission, I would be happy to support these requests. I can be contacted a skyramarios@mail.arc.nasa.gov. Once again, sorry for the late notice. ------ Steve N. Kyramarios NASA-Ames Research Center Project Engineer/Manager, Communications and Networks skyramarios@mail.arc.nasa.gov > e-mail (407)867-8542 > office phone, voice mail (407)867-7133 > fax From rem-conf-request@es.net Fri Jun 07 12:44:23 1996 Received: from dxmint.cern.ch by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 09:43:54 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id SAA04114 for ; Fri, 7 Jun 1996 18:43:46 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA04447; Fri, 7 Jun 1996 18:43:46 +0200 Message-Id: <9606071643.AA04447@dxcoms.cern.ch> Subject: CERN MBONE Announcement: ATLAS Plenary Meetings To: rem-conf@es.net Date: Fri, 7 Jun 1996 18:43:45 +0200 (MET DST) From: Christian Isnard - CERN/CN/CS X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit CERN is pleased to announce the MBONE broadcast of the next Plenary Meetings of the ATLAS LHC Experiment Provisional Agenda: ------------------- Thursday 27th June: 09:00-13:00 (GMT+2): Physics Working Group 14:00-17:30 (GMT+2): Plenary Meeting (Part I) Friday 28th June: 08:30-13:00 (GMT+2): Plenary Meeting (Part II) The new generation of MBONE tools will be used with ttl 127: sdr v2.2a9, vat v4.0b2, vic v2.7b2 (in RTPv2 mode). The sessions are advertised in sdr session directory as "CERN - ATLAS". In case of questions or conflicts please contact . This message is sent to distribution lists, sorry if you receive multiple copies of it. Best regards, -------------------------------------------------------------------- Christian Isnard CERN - CN/CS/EN isnard@dxcoms.cern.ch European Laboratory for Particle Physics Computers and Networks division CH-1211 Geneva 23 - Switzerland From rem-conf-request@es.net Fri Jun 07 13:31:03 1996 Received: from mail1.digital.com by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 10:29:29 -0700 Received: from acetes.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA29240; Fri, 7 Jun 1996 10:16:03 -0700 Received: by acetes.pa.dec.com; id AA23882; Fri, 7 Jun 96 10:16:02 -0700 Date: Fri, 7 Jun 96 10:16:02 -0700 From: templin@pa.dec.com (Fred Templin) Message-Id: <9606071716.AA23882@acetes.pa.dec.com> To: jinzen@nttvdt.hil.ntt.jp, rem-conf@es.net Subject: Re: Propose RSTP & SoftwareVision > RSTP data packet header isn't equal to RTP format now, but very similar. > Perhaps I think that our system can deal with RTP format and works as robust > a relay system. RSTP defines negotiation scheme for ondemand real-time media > access and client-oriented transfer protocol. One additional question - if the above is true, then why not propose the RSTP innovations as extensions to RFC 1889 rather than define a new protocol alltogether? It seems to me that a unified approach would be more likely to bring about the timely and widespread adoption of realtime internetworking services than a fragmented approach... Fred templin@pa.dec.com From rem-conf-request@es.net Fri Jun 07 22:49:38 1996 Received: from omzrelay.mci.com by osi-west.es.net with ESnet SMTP (PP); Fri, 7 Jun 1996 19:49:09 -0700 Received: by omzrelay.mci.com; (8.6.12/1.1.8.2/07Nov95-0827AM) id VAA07852; Fri, 7 Jun 1996 21:49:08 -0500 Received: from pop1a.mail.mci.com by omzrelay.mci.com; (8.6.12/1.1.8.2/14Nov95-0411PM) id VAA18560; Fri, 7 Jun 1996 21:49:07 -0500 Received: from infolink-204.189.237.144.Chicago.mci.net by pop1a.mail.mci.com; (5.65v3.2/1.1.8.2/24Apr96-0705PM) id AA14954; Fri, 7 Jun 1996 21:48:59 -0500 Received: by infolink-204.189.237.75.Chicago.mci.net with Microsoft Mail id <01BB54BB.1512ED00@infolink-204.189.237.75.Chicago.mci.net>; Fri, 7 Jun 1996 21:48:37 -0500 Message-Id: <01BB54BB.1512ED00@infolink-204.189.237.75.Chicago.mci.net> From: Henry Sinnreich To: Luis de Pieri , 'Rich Baker/PicTel' Cc: confctrl , rem-conf , IMTC Subject: RE: (CNC) Re: SG-15 last meeting Date: Fri, 7 Jun 1996 21:48:35 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Rich, Is the any online info anywhere ? Would appreciate it. Thanks, Henry ---------- From: Rich Baker/PicTel[SMTP:Rich_Baker@smtpnotes.pictel.com] Sent: Thursday, June 06, 1996 10:49 PM To: Luis de Pieri Cc: confctrl; rem-conf; IMTC Subject: (CNC) Re: SG-15 last meeting I am pleased to announce that H.323 was "Decided" at the SG15 meeting in Geneva last Tuesday. In ITU-T parlance, that makes H.323 as good as a "Standard", since the final step (an official vote, nation-by-nation, with 70% approval) virtually always is achieved. So... o Given the number of major manufacturers already in the process of developing interworking H.323 implementations; o Given H.323's adoption of RTP/RTCP; o Given H.323's compatibility with RSVP; o Given H.323's comprehensive support of edge gateways to H.320/H.324 (ISDN/POTS) standards based terminals, which permit WAN-based and Internet-based terminals to easily conference and interwork... ... I have confidence that H.323 is poised to become the intranet and internet standard for videoconferencing. Another step towards this goal was made last month. The IMTC CNC activity group I chair formed an "H.323 Implementators" subgroup, chaired by Jim Toga, to facilitate vendors building H.323 products. Those interested in joining should contact myself (bake@pictel.com) or Jim (jtoga @ ibeam.jf.intel.com). Later this month work begins on the next phase of H.323 standards development. Many, many thanks to the tireless efforts of the folks who made it all happen, particulary our intrepid (and sleep deprived...) editors: o Gary Thom (Delta Information Systems), H.323 Editor o Dale Skran (Lucent), H.224 Editor o Mark Reid (PictureTel), H.245 extensions Editor ... and to Sakae OKUBO (Graphics Communication Laboratories, okubo@gctech.co.jp), who is the Rapporteur for this work inside SG15. Cheers, -rich baker IMTC Corporate Network Conferencing AG Chair PictureTel Corporation bake@pictel.com ===== To: confctrl @ ISI.EDU @ smtp From: ldepieri @ ifhamy.insa-lyon.fr (Luis de Pieri) @ smtp Date: 06/05/96 09:01:54 AM Subject: SG-15 last meeting Hello, Does anybody knows if we're going to get on this list, or on the Internet, the happenings/results of the SG-15 last meeting at Geneva/May/96 ? Thanks, Luis From rem-conf-request@es.net Sun Jun 09 02:56:45 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sat, 8 Jun 1996 23:56:14 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA04925; Sat, 8 Jun 1996 23:55:38 -0700 Date: Sat, 8 Jun 1996 23:55:37 -0700 (PDT) From: Stephen Casner To: Hiroshi Jinzenji Cc: rem-conf@es.net Subject: Re: Propose RSTP & SoftwareVision In-Reply-To: <199606071040.TAA25769@nttvdt.hil.ntt.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > RSTP is used by not only server-client connections but also server-server > connections. If packet loss occur on relay route, error is spreaded on lower > clients and servers. Relay server implementation using RSTP is our main > subject. In our system, relay servers is very important server to decrease > duplicate flows. Using TCP, connection-oriented protocol, relay server > and proxy server are simply implementation. The difficulty is: 1. getting relay servers situated at each branch point (each router), or at least a sufficient number of them to keep the load down; and 2. assuming (1) is solved, then finding paths through the servers between all desired sources and receivers (i.e. routing). The beauty of IP multicast is that it handles these problems automatically at the natural point: in the routers. The service is provided at the network level for any application that needs it (you don't need a server for each application). -- Steve From rem-conf-request@es.net Sun Jun 09 11:39:54 1996 Received: from cs.nps.navy.mil by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Jun 1996 08:39:14 -0700 Received: from capella.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA24271; Sun, 9 Jun 96 08:38:20 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Received: by capella.cs.nps.navy.mil (4.1) id AA29867; Sun, 9 Jun 96 08:38:18 PDT Message-Id: <9606091538.AA29867@capella.cs.nps.navy.mil> Subject: Re: ion group agenda items and drafts for Montreal To: malis@nexen.com (Andrew G. Malis) Date: Sun, 9 Jun 1996 08:38:18 -0700 (PDT) Cc: ion@nexen.com, rem-conf@es.net (Remote Conferencing mail list), iirg@navy.stl.nps.navy.mil (Information Infrastructure Research Group) In-Reply-To: from "Andrew G. Malis" at Jun 6, 96 04:09:07 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Content-Length: 1714 Andrew G. Malis writes: > I just wanted to forward the reminder below for internet drafts. Also, I > want to remind the group that since we are currently scheduled to be > multicast, presentations should be done in advance (and made available in > Postscript) so that they can be multicast on the whiteboard (which works > much better than pointing a TV camera at the screen in front of the room). > That will also allow me to make the presentations available via ftp for > those of you that cannot attend the meeting. Yes. An additional tip: when using vic, sliding the Quality bar to the right (from default 10 towards highest quality 1) improves the resolution of the image. We experimented this past week during the AUV 96 multicast and found that qualities of 2 or 3 were plenty adequate to produce readable video. Bringing Quality back down during discussions was similarly helpful by capturing more of peoples' gestures and expressions. As usual, slides which are unreadable to people in the room (too busy, font too small, etc.) also tend to be unreadable over video. > Also, the secretariate would GREATLY appreciate it if you followed the > presentation guidelines in > http://www.ietf.cnri.reston.va.us/instructions/slides.html and > http://www.ietf.cnri.reston.va.us/instructions/multicast.html. > > If you want time on the agenda, and you haven't yet contacted us, please > send email to malis@nexen.com and swallow@nexen.com. all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman From rem-conf-request@es.net Sun Jun 09 12:20:28 1996 Received: from ussenterprise.ufp.org by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Jun 1996 09:19:56 -0700 Received: (bicknell@localhost) by ussenterprise.ufp.org (8.7.1/8.7.ufp) id MAA11732 for rem-conf@es.net; Sun, 9 Jun 1996 12:19:54 -0400 From: Leo Bicknell Message-Id: <199606091619.MAA11732@ussenterprise.ufp.org> Subject: High Bandwidth MBONE To: rem-conf@es.net Date: Sun, 9 Jun 1996 12:19:54 -0400 (EDT) Reply-To: bicknell@ufp.org X-Mailer: ELM [version 2.4 PL23] Content-Type: text I've been working with the MBONE tools some locally to expierment with video conferencing. Later this month we are going to be broadcasting an announcement using the MBONE tools of a new state-wide high speed networking system. Since we're showing off high speed networking (the local room will be all OC-3 connected workstations) I'd like to use the MBone tools for high bandwidth. To that end, I have a few questions: 1) VIC seems to lower the max bandwidth as you increase the TTL. With OC-3 available across campus having it be limited to 1Megabit at ttls's in the upper 20's is a problem. Is it easy to modify this behavior so I can send out a 10+ megabit stream across campus? 2) For our demo we will have a T1 to the internet just for our MBone feed. I would like to send out video at > 128Kbit for several places to pick up, but as I understand sening > 128kbit is considered a nono for many places on the net. Can I send out > 128Kbits worldwide somehow and be polite about it, or do I need multiple streams, or are there any other suggestions? 3) I want to send out the same image to both the internet and a machine across the room. For the machine across the room I would like there to be no limits, but for the internet there obviously needs to be. Is there any way I can do this with a single capture system or am I going to have to get a second capture system and run one for the local room and one for the internet? 4) I get better results (picture quality/frame rate) with the jpeg option of VIC. I believe all the things I've seen on the MBONE use the 'nv' format though. Should I use 'nv' for compatabilty, or can I use jpeg? Thanks for any input you can give me. -- Leo Bicknell - TMBG List Admin - tmbg-list-request@tmbg.org System Administrator / Network Technician bicknell@ufp.org - bicknell@vt.edu - bicknell@tmbg.org From rem-conf-request@es.net Sun Jun 09 21:39:49 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Jun 1996 18:39:04 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA08434; Sun, 9 Jun 1996 18:39:03 -0700 Date: Sun, 9 Jun 1996 18:39:02 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Start of draft of RTP compression Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, What follows is a draft in the true sense. I'm working to get to an acceptable shape for posting before the June 13 cutoff, but several people have asked about this and I would like to have a change to get some comments first. Obviously there are many places where this is incomplete; more will come. -- Steve Internet Engineering Task Force Audio/Video Transport Working Group INTERNET-DRAFT S. Casner / Precept Software draft-casner-jacobson-crtp-00.txt V. Jacobson / LBNL June 9, 1996 Expires: 12/96 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links Status of this Memo This document is not yet an Internet-Draft, but is in preparation to become one. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed into a single byte. This document is not (yet) a protocol specification, but it proposes several ideas on header compression and discusses some design issues. It is expected that this work will be combined with contributions from others to produce a protocol specification within the Audio/Video Tran- sport working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s). Expires December 1996 [Page 1] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 1. Introduction Since the Real-time Transport Protocol has been published as an RFC, there is growing interest in using it as one step to achieve interopera- bility among different implementations of network audio/video applica- tions. However, there is also concern that the 12-byte RTP is too large an overhead for 20-byte payloads when operating over low speed lines such as dial-up modems at 14.4 or 28.8 kb/s. (Existing applications operating in this mode may use an application-specific protocol with a one- or two-byte header and reduced functionality relative to RTP.) In the past few months, several people have developed ideas for compressing the RTP header alone, on an end-to-end basis, or for compressing the combination of IP, UDP and RTP headers on a link-by-link basis. In particular, Scott Petrack of IBM presented his ideas on RTP- only compression in the AVT session at the Los Angeles IETF meeting in March, 1996, and Carsten Bormann presented his ideas on an overall achi- tecture for compression in combination with traffic control across a low-speed link in the ISSLL session. This draft is the result of a meeting of the two authors to discuss a translation of Jacobson's design for TCP/IP header compression (RFC 1144) to the problem of combined compression of IP/UDP/RTP headers between the two endpoints of a low-speed link. David Oran of cisco independently developed a note based on similar ideas, and suggested the use of this compression in combination with the PPP Multilink protocol for segmentation. Compressing 40 bytes of IP, UDP and RTP headers together provides sub- stantially more gain than compressing 12 bytes of RTP header alone because the resulting size is a few bytes in either case and can be just a single byte in the case of the combined compression if UDP checksum are not being used. However, use of the combined compression requires development and deployment of infrastructure, whereas end-to-end RTP compression can be implemented independently in an application. Even though implementation of the combined compression scheme in the routers and protocol stacks that operate as the endpoints of low-speed links may occur quickly, and even though the motivation for service providers to deploy the new compression may be high, the process is likely to take a year or more. To allow application developers to proceed before the "complete solu- tion" of combined IP/UDP/RTP header compression can be deployed, it has been proposed that an "interim solution" of RTP-only compression be developed. The problem is that interim schemes are typically very dif- ficult to eliminate once the complete solution is ready. Therefore, it is critical to design a transition strategy as part of the interim scheme that allows applications to determine whether the complete Expires December 1996 [Page 2] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 solution is available, and if so, to avoid doing the RTP-only compres- sion. This draft, in its current form, discusses only a proposal for combined IP/UDP/RTP header compresssion. If this document goes on to serve as the basis for a protocol specification sponsored by AVT, it is expected that contributions will be incorporated from other drafts and that the author list will expand. In particular, Scott Petrack is drafting ideas for end-to-end RTP compression and for the transition strategy. One document structure that has been proposed is to include the interim solution as an appendix to the specification of the complete solution so the intended transition can be clearly conveyed and so that the two are not seen as alternatives. 2. The Compression Algorithm The motivation and description given here are sketchy. Readers are referred to the description of TCP/IP header compression in RFC1144. 2.1. The basic idea In TCP header compression, the first factor of two comes from the obser- vation that half of the bytes in the header remain constant over the life of the connection. The remaining compression comes from differen- tial coding on the fields that change to reduce their size, and from eliminating the changed fields entirely for common cases by calculating the changes from the length of the packet indicated by the link-level protocol. For RTP header compression, some of the same techniques may be applied. However, the big gain comes from the observation that although several fields change in every packet, the difference from packet to packet is often constant and therefore the second difference is zero. By main- taining those first differences as part of the session state shared between the compressor and decompressor, all that must be communicated is an indication that the second difference was zero. The decompressor can reconstruct the original header without any loss of information. Because the compression is lossless, it may be applied to any UDP traffic that benefits from it. Most likely, the only packets that will benefit are RTP packets, but it is acceptable to use heuristics to determine whether or not the packet is an RTP packet because no harm is done if the heurisic gives the wrong answer. This protocol depends upon the link layer being able to provide an indi- cation of four packet types: Expires December 1996 [Page 3] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 UNCOMPRESSED_UDP which communicates the uncompressed IP/UDP headers plus any following headers and data, but with the session context ID replacing the IP protocol field. COMPRESSED_UDP which communicates the IP and UDP headers compressed to 5 or fewer octets (usually 1), followed by any subsequent headers (possibly RTP) and data. COMPRESSED_RTP which includes the RTP header in the compression still with the usual result being one octet. CONTEXT_ERROR which indicates loss of synchronization between the compressor and decompressor. 2.2. Compression of RTP Data Packet Headers In the IP header, only the total length, packet ID, and header checksum fields will normally change. The total length is redundant with the length provided by the link layer, and since this compression scheme must depend upon the link layer to provide good error detection (e.g., PPP's CRC), the header checksum may also be elided. This leaves only the packet ID, which, assuming no IP fragmentation, would not need to be communicated. However, in order to maintain lossless compression, we will encode changes in the packet ID. In the UDP header, the length field is redundant with the IP total length field and the length indicated by the link layer. The UDP check- sum field will be a constant zero if the source elects not to generate UDP checksums. Otherwise, the checksum must be communicated in order to preserve the lossless compression. Allowing end-to-end error detection for applications that require it is an important principle. In typical usage of the RTP header, the sequence number and the times- tamp will change from packet to packet. If packets are not lost or misordered, the sequence number will increment by one for each packet. For audio packets of constant duration, the timestamp will increment by the number of sample periods conveyed in each packet. For video, the timestamp will change on the first packet of each frame, but then stay constant for the remaining packets in the frame. Note that in both scenarios the second difference of these fields is usually zero. When they do change, the magnitude of the change is usually much smaller than the full number of bits in the field, so the size can be reduced by encoding the difference rather than the absolute value. The M bit will be set on the first packet of a talkspurt and the last packet of a video frame. If it were treated as a constant field such that each change required sending the full RTP header, this would reduce the compression significantly. Therefore we will dedicate one bit in Expires December 1996 [Page 4] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 the compressed header to it. If the packets are flowing through an RTP mixer, most commonly for audio, then the CSRC list and CC count will also change. However, the CSRC list will typically remain constant during a talkspurt or longer, so it need be sent only when it changes. 2.3. The protocol When the second difference of the RTP header is zero, all we need to communicate is a small sequence number to maintain synchronization and detect packet loss between the compressor and decompressor. When some fields have changed by amounts other than the first difference stored in the session state, we want to communicate only the new differences for those fields that have changed, and to encode them as compactly as pos- sible. To do this, we will use a bit mask indicating which fields have changed by other than the expected difference. In addition to the link sequence number, the list of items to be condi- tionally communicated in the compressed IP/UDP/RTP header is as follows: C = session context ID I = IP packet ID ? = UDP checksum M = RTP marker bit S = RTP sequence number T = RTP timestamp ? = RTP CSRC count and list If we are to allow 3 bits for the link sequence number to get a reason- able probability of loss detection, there are too few bits remaining to assign one bit to each of these items and still fit them all into our target compressed header size of one byte. We do not need to explicitly indicate the presence of the UDP checksum because a source will typically include checksums on all packets of a session or none of them. When the session state is initialized with an uncompressed header, if there is a nonzero checksum present, an unen- coded 16-bit checksum will be appended to the compressed header in all subsequent packets until this setting is changed by sending another uncompressed packet. Of the remaining items, the CSRC list may be the one least frequently used. We can avoid dedicating a bit to indicate CSRC change by using an unusual combination of the other bits instead. If all three of the bits for the RTP sequence number, RTP timestamp and RTP marker bit are set, we will treat this as a special case indicating that a special partially compressed form of the RTP header will follow. That header will include Expires December 1996 [Page 5] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 the CC count and CSRC list in addition to the RTP sequence number and timestamp differences that would normally be present as indicated by that bit combination, plus a separate copy of the marker bit since this combination may sometimes be used when the marker bit was not actually set. Note that the CSRC list will most often be used for audio mixers, and that it will usually change at the start of a talkspurt when the M bit will be set and the timestamp will change by an unexpected amount. Therefore, using this special combination will add little overhead when communicating CSRC changes. The resulting compressed IP/UDP/RTP header would look something like the following diagram. Note that the order of bits shown in the mask is arbitrary and may be changed as indicated by implementation experience. Also, the differential encodings of changed values have not yet been determined; it may be appropriate to define the smallest representation to use only 4 bits rather than 8 as shown here. A study of packet traces will provide some statistics for the design of the encodings. Expires December 1996 [Page 6] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | M | S | T | I | C | sequence | +---+---+---+---+---+---+---+---+ : session context (C) : +...............................+ : delta IP ID (I) : +...............................+ : : + UDP checksum + : : +...............................+ : CC and M (MST) : +...............................+ : delta RTP sequence : +...............................+ : delta RTP timestamp : +...............................+ : : : RTP header extension : : (only if X set in context) : : : +...............................+ : : : CSRC list (MST) : : : : : +---+---+---+---+---+---+---+---+ | data | : : 2.4. Compression of RTCP Control Packets By relying on the RTP convention that data is carried on an even port number and the corresponding RTCP packets are carried on the next higher (odd) port number, one can tailor separate compression schemes to be applied to RTP and RTCP packets. The details of the RTCP compression are not worked out yet to the same level as that for RTP, but the mechanisms will be similar. For RTCP, the compression applies not only to the header but also the "data", that is, the contents of the dif- ferent packet types. The numbers in Sender Report (SR) and Receiver Report (RR) packets will not compress well, but the text information in the Source Description (SDES) packets can be compressed down to a bit mask indicating the pres- ence of each item type for timing purposes (particularly for the SDES Expires December 1996 [Page 7] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 NOTE item; the other items need not be repeated except to allow the end system to measure the average RTCP packet size for the interval calcula- tion). Note that the RTP protocol specification suggests that the RTCP packet interval be scaled so that the aggregate RTCP bandwidth used by all participants in a session will be no more than 5% of the session bandwidth, so compression of RTCP should not be too big a problem. 3. Acknowledgments This protocol design draws heavily upon the design of TCP/IP header compression. 4. Security Considerations Security issues are not discussed in this memo. 5. Authors' Addresses Stephen L. Casner Precept Software, Inc. 1072 Arastradero Road Palo Alto, CA 94304 United States EMail: casner@precept.com Van Jacobson MS 46a-1121 Lawrence Berkeley National Laboratory Berkeley, CA 94720 United States EMail: van@ee.lbl.gov Expires December 1996 [Page 8] From rem-conf-request@es.net Mon Jun 10 00:41:53 1996 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Sun, 9 Jun 1996 21:41:15 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id VAA23280; Sun, 9 Jun 1996 21:41:43 -0700 Message-Id: <199606100441.VAA23280@rx7.ee.lbl.gov> To: brutzman@cs.nps.navy.mil (Don Brutzman) cc: malis@nexen.com (Andrew G. Malis), ion@nexen.com, rem-conf@es.net (Remote Conferencing mail list), iirg@navy.stl.nps.navy.mil (Information Infrastructure Research Group) Subject: Re: ion group agenda items and drafts for Montreal In-reply-to: Your message of Sun, 09 Jun 96 08:38:18 PDT. Date: Sun, 09 Jun 96 21:41:42 PDT From: Van Jacobson > An additional tip: when using vic, sliding the Quality bar to > the right (from default 10 towards highest quality 1) improves > the resolution of the image. No, please don't do this -- it will actually make things worse. Vic uses an adaptive quantizer that will do as good a job as possible sending slides if you leave it at the default setting. Vic tracks the motion in every 8x8 pixel image block on the screen. When a block is changing rapidly (e.g., someone is changing slides), vic sends as coarsely quantized image (using the q that you set on the menu panel) that helps to rapidly paint the large, solid areas. As soon as a block's motion stops, vic repaints the block at twice the quality (half the q you selected) and as soon as most of the total image motion stops, all the image is repainted at the highest quality possible with h.261 (q=1). So if you push the quantizer down, vic has to expend much more of its bit budget sending a high resolution version of worthless data (the image of a slide being removed or placed on the projector) which only serves make the vic updates seriously lag the speaker & delays getting the high res version of the slide painted. [I have looked, in detail, at what happens when sending sides with vic. Using the default q=10 + clicking on the 'sending slides' button on the menu panel (which makes vic expend more of its bandwidth buget on the hi res updates) gets the highest quality slides out sooner than any other scheme or q setting. (If you'd like to look at this yourself, rtp_record a presentation then build the "h261_play" tool in the vic distribution; it will let you view the video both continuously & single step, and optionally highlight only the blocks that change so you can see exactly what vic was doing.)] If you find pushing q down to 3 or 4 really improved things, you might have an old copy of vic (the adaptive quantizer didn't go in until around the beta-1 release). Or there might be a problem in your video capture -- ground loops can make noise artifacts that crawl across the screen & fool vic into thinking that there's motion when there isn't. Or if the camera is handheld rather than on a tripod, it's probably impossible to hold it still enough for vic to switch to high quality mode. Or if your camera operator is into pan & scan (a *really* bad idea for mbone sessions) and leaves their hand on the tripod control arm, or if your camera is set to autofocus (which almost always 'hunts' on slide images & degrades the image quality), a lot of extraneous motion can get introduced. But any of these problems will drastically cut down on the video frame rate & quality, no matter what q you use. They should be fixed beforehand so you can simply leave vic alone & let it dynamically choose the right quality to send at. - Van From rem-conf-request@es.net Mon Jun 10 03:36:49 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jun 1996 00:36:08 -0700 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <10947-0@ceres.fokus.gmd.de>; Mon, 10 Jun 1996 09:34:20 +0200 To: rem-conf@es.net Subject: Infocom 97 deadline June 14 Content-Length: 1378 Date: Mon, 10 Jun 1996 09:34:20 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de Paper submission due is for infocom 97 is June 14, '96, this coming Friday. I would like to encourage you and your colleagues to submit papers to infocom. We have created a web based paper submission system to aid your paper submission process, and detailed paper submission instructions (as well as information on the conference) are found in the following WWW pages. http://www.ics.uci.edu/~infocom/ http://arpeggio.ics.es.osaka-u.ac.jp/infocom.html We accept both postscript submissions and hard copy submissions; however, postscript submissions are STRONGLY encouraged. Those who are submitting hard copies are also asked to check the submission instructions on the infocom web and fill up the form; it will facilitate our processing of the papers. Before submitting a postscript file, please print it out to see if it is complete and printable. (If available, you might wish to use ghostview or pageview or check whether you can convert it to PDF using the 'distill' program.) Please also format your file according to the American letter size paper, not A4. Here are some important dates: Paper Submission Deadline: June 14, 1996 Notification of Acceptance: Sept. 30, 1996 IEEE Infocom '97 conference: April 7 - 11, 1997, Kobe, Japan We are looking forward to receiving your submissions. Tatsuya Suda Henning Schulzrinne Yuji Oie From rem-conf-request@es.net Mon Jun 10 04:40:57 1996 Received: from tama.tas.ntt.jp by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jun 1996 01:40:24 -0700 Received: by tama.tas.ntt.jp (8.7.5/tas-sh-02) with TCP; Mon, 10 Jun 1996 17:40:31 +0900 (JST) Received: by nttmail.tas.ntt.jp (8.6.12/nttmail-02) with TCP; Mon, 10 Jun 1996 17:40:00 +0900 Received: by nttvdt.hil.ntt.jp (8.6.9/hil-1.1); Mon, 10 Jun 1996 17:40:00 +0900 Message-Id: <199606100840.RAA17172@nttvdt.hil.ntt.jp> Date: Mon, 10 Jun 1996 17:39:47 +0900 From: jinzen@nttvdt.hil.ntt.jp (Hiroshi Jinzenji) To: casner@precept.com Cc: rem-conf@es.net, sv@www-hil.tas.ntt.jp Subject: Re: Propose RSTP & SoftwareVision Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Thank you for your comments. Fred wrote: Fred > One additional question - if the above is true, then why not propose the Fred > RSTP innovations as extensions to RFC 1889 rather than define a new Fred > protocol alltogether? First, I don't think RSTP is competitor for RTP. I think RSTP is innovations as extensions to RFC 1889 for on demand access, like a your idea. In our proposal, packet header format information is omitted, because RSTP data packet header isn't equal to RTP format now, and we want to use same header format in the near future. # We are a newcomer of IETF AVT WG, so we are inexperienced at a discussion # and a strategy in IETF and the WG. I feel RTP main discussion is real-time bi-directional communication, such as a teleconference, on MBone. I'm engaged in studies in real-time uni-directional communication, such as a netcasting and VOD, for every Internet user. I think thoes two services need different approach and strategy. RSTP is a one idea for ondemand accesssing, including scalable access; client-oriented system. Steve wrote: Steve > The difficulty is: Steve > Steve > 1. getting relay servers situated at each branch point (each router), Steve > or at least a sufficient number of them to keep the load down; and Yes, like a mrouted :-) In our current implementation, Internet providers use relay server and Intranet users RSTP multicast stream, reformed by relay server; RSTP(TCP) -> RSTP(Multicast). Relay path information is manual setting now. Steve > 2. assuming (1) is solved, then finding paths through the servers Steve > between all desired sources and receivers (i.e. routing). I think so. But this subject is very interesting study, I think. Current servers has a static relay path table file. But I want to get this subject under control. Steve > The beauty of IP multicast is that it handles these problems Steve > automatically at the natural point: in the routers. The service is Steve > provided at the network level for any application that needs it (you Steve > don't need a server for each application). But IP multicast has a random packet loss problem. If using congested network, packet loss occur frequently, like a japanese internet on day time. And multicast routing network is a small part of the Internet, so many Internet user can't receive MBone traffic. RSTP relay server support not only video stream but also audio, text, etc. stream. So I want to use RSTP relay server like a mrouted. ------------ Jinzen!! Hiroshi Jinzenji From rem-conf-request@es.net Mon Jun 10 07:53:47 1996 Received: from eng.tau.ac.il (actually yarkon.eng.tau.ac.il) by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jun 1996 04:53:06 -0700 Return-Path: Received: (oshapiro@localhost) by ayalon.eng.tau.ac.il (8.6.12/8.6.12) id OAA29262; Mon, 10 Jun 1996 14:51:57 +0300 Date: Mon, 10 Jun 1996 14:51:56 +0300 (IDT) From: Ofer Shapira To: rem-conf@es.net Subject: internet real time applications Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hi, I've been monitoring the rem-conf news group, but up until now I ignored everything that had to do with MBONE, mrouted, and other multimedia over the internet - related issues. Now I need to find out what all these things are, and the question is: where do I start? is there a FAQ somewhere? what RFCs should I read? how do I get them? any other newsgroups I should subscribe to? any information would be most welcomed Neta From rem-conf-request@es.net Mon Jun 10 14:51:36 1996 Received: from mach-1.tridis.ist.ucf.edu (actually 132.170.197.1) by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jun 1996 11:50:49 -0700 Received: by mach-1.tridis.ist.ucf.edu (SMI-8.6/SMI-SVR4) id OAA09990; Mon, 10 Jun 1996 14:49:56 -0400 Date: Mon, 10 Jun 1996 14:49:56 -0400 From: myjak@tridis.ist.ucf.edu (Michael Myjak) Message-Id: <199606101849.OAA09990@mach-1.tridis.ist.ucf.edu> To: jinzen@nttvdt.hil.ntt.jp CC: casner@precept.com, rem-conf@es.net, sv@www-hil.tas.ntt.jp In-reply-to: <199606100840.RAA17172@nttvdt.hil.ntt.jp> (jinzen@nttvdt.hil.ntt.jp) Subject: Re: Propose RSTP & SoftwareVision Hello, first a Q: Where can I read about RSTP? > I feel RTP main discussion is real-time bi-directional > communication, such as a teleconference, on MBone. I'm engaged in > studies in real-time uni-directional communication, such as a > netcasting and VOD, for every Internet user. I think thoes two > services need different approach and strategy. RSTP is a one idea for > ondemand accesssing, including scalable access; client-oriented > system. Interesting... when I read the RTP draft spec, I came to the conclusion that RTP was more oriented fortoward the multicasted undirectional communications crowd, and would support a small number of bi-directional side-bar channels. (Again, that this is my perspective and not necessarily the intent of RTP... I'm from the distributed interactive simulation crowd.) > But IP multicast has a random packet loss problem. If using > congested network, packet loss occur frequently, like a japanese > internet on day time. And multicast routing network is a small part > of the Internet, so many Internet user can't receive MBone traffic. Indeed. Random lossage is a problem, and the loss grows proportionally with load. This is the problem I see hope to see (dream?) RSVP solving. - Michael D. Myjak Senior Research Scientist Institute for Simulation and Training The University of Central Florida Voice: 407.658.5043 FAX: 407.658.5059 LAB: 407.658.5078 Off the keyboard, over the bridge, through the router..... Nothin' but Net! From rem-conf-request@es.net Mon Jun 10 15:31:17 1996 Received: from cbgw1.att.com (actually gw1.att.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jun 1996 12:30:40 -0700 Received: from mvgsf.mv.att.com by cbig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id PAA20719; Mon, 10 Jun 1996 15:15:30 -0400 Received: by mvgsf.mv.att.com (5.x/EMS-L sol2) id AA20092; Mon, 10 Jun 1996 15:08:42 -0400 From: bhagavath@att.com (Vijay K Bhagavath) To: cnom@maestro.bellcore.com, cip@bbn.com, atm@bbn.com, arl@arl1.wustl.edu, announcements.chi@xerox.com, rem-conf@es.net, end2end-interest@isi.edu, perform@tay1.dec.com, atm-list@csc.com, smds@cnri.reston.va.us, sigmedia@bellcore.com, iplpdn@cnri.reston.va.us, icad-request@santafe.edu, hipparch@sophia.inria.fr, globecom@signet.com.sg, g-troup@dworkin.wustl.edu, f-troup@aurora.cis.upenn.edu, enternet@bbn.com, enternet-ec@bbn.com, ccrc@dworkin.wustl.edu, staples@bnr.ca, jne@glasgow-caledonian.ac.uk, yoshida@rosso.mss.netwk.ntt-at.co.jp, chuanyi@ecse.rpi.edu, fad@prism.uvsq.fr, Faouzi.Daoud@prism.uvsq.fr, tsuzuki@ccsd.ho.nec.co.jp, xtp-relay@cs.concordia.ca, uist.chi@xerox.com, tf-mm@i4serv.informatik.rwth-a, tcplw@cray.com, t.stevenson@ieee.org, mouftah@eleceng.ee.queensu.ca, Ron.Horn.0090874@nt.com, nkc@bellcore.com, c.desmond@ieee.org, sbw@ccrl.nj.nec.com, bhumip@gte.com, kjl@bellcore.com, aidarous@bnr.ca, dnzuckerman@att.com, pogran@bbn.com, just4net@aol.com, bran@silcom.com, rlfike@aol.com, braudyb@aol.com, ahmadi@engn.uwindsor.ca, wlai@att.com, g.weisman@ieee.org, vik@ihades.ih.att.com, prabhu@ee.uta.edu, jandre@imtn.tpd.dsccc.com, enternet-ec@bbn.com, dotti@fokus.gmd.de, labetoul@eurecom.fr, sidou@eurecom.fr, oliveira@eurecom.fr, bobchap@ibm.net, clytle@sed.stel.com, lewis@ctron.com, mohan@ccmail.inet.com, paulcov@bnr.ca, guthery@austin.sar.slb.com, pradeep@dstc.uts.edu.au, scott_linke@aus.hp.com, rdantu@tddcae99.fnts.com, bumblis@mcc.com, kseo@bbn.com, 100765.3267@compuserve.com, murase@nwk.cl.nec.co.jp, jknecht@att.com, jerry@ece.concordia.ca, mustafa@ece.concordia.ca, ahmed@ece.concordia.ca, lanworks@delphi.com, yemini@cs.columbia.edu, craig@bbn.com, yoshida@netwk.ntt-at.co.jp, hegering@lrz-muenchen.de, wz@prosun.first.gmd.de, xrjo@atc.boeing.com, saracco@cselt.stet.it, christos@ece.miami.edu, wolfson@ouri.eecs.uic.edu, G_F_Wetzel@att.com, comswtc@gmu.edu, commsoft@cc.bellcore.com, ieeetcpc@ccvm.sunysb.edu, badri@cs.rutgers.edu, cellular@comnets.rwth-aachen.de, mobile-ip@tadpole.com, reres@laas.fr, cost237-transport@comp.lancs.ac.uk, dbworld@cs.wisc.edu, tccc@cs.umass.edu Received: by mvgsf.mv.att.com (5.x/EMS-L sol2) id AA17671; Mon, 10 Jun 1996 14:02:06 -0400 Date: Mon, 10 Jun 1996 14:02:06 -0400 Message-Id: <9606101802.AA17671@mvgsf.mv.att.com> Original-From: vkb@mvgsf.mv.att.com (Vijay K Bhagavath) Original-To: cnom@maestro.bellcore.com, cip@bbn.com, atm@bbn.com, arl@arl1.wustl.edu, announcements.chi@xerox.com, rem-conf@es.net, end2end-interest@isi.edu, perform@tay1.dec.com, atm-list@csc.com, smds@cnri.reston.va.us, sigmedia@bellcore.com, iplpdn@cnri.reston.va.us, icad-request@santafe.edu, hipparch@sophia.inria.fr, globecom@signet.com.sg, g-troup@dworkin.wustl.edu, f-troup@aurora.cis.upenn.edu, enternet@bbn.com, enternet-ec@bbn.com, ccrc@dworkin.wustl.edu, staples@bnr.ca, jne@glasgow-caledonian.ac.uk, yoshida@rosso.mss.netwk.ntt-at.co.jp, chuanyi@ecse.rpi.edu, fad@prism.uvsq.fr, Faouzi.Daoud@prism.uvsq.fr, tsuzuki@ccsd.ho.nec.co.jp, xtp-relay@cs.concordia.ca, uist.chi@xerox.com, tf-mm@i4serv.informatik.rwth-a, tcplw@cray.com, t.stevenson@ieee.org, mouftah@eleceng.ee.queensu.ca, Ron.Horn.0090874@nt.com, nkc@bellcore.com, c.desmond@ieee.org, sbw@ccrl.nj.nec.com, bhumip@gte.com, kjl@bellcore.com, aidarous@bnr.ca, w2xd@mtnms.mt.lucent.com, pogran@bbn.com, just4net@aol.com, bran@silcom.com, rlfike@aol.com, braudyb@aol.com, ahmadi@engn.uwindsor.ca, waisum@buckaroo.ho.att.com, g.weisman@ieee.org, vik@ihades.ih.att.com, prabhu@ee.uta.edu, jandre@imtn.tpd.dsccc.com, enternet-ec@bbn.com, dotti@fokus.gmd.de, labetoul@eurecom.fr, sidou@eurecom.fr, oliveira@eurecom.fr, bobchap@ibm.net, clytle@sed.stel.com, lewis@ctron.com, mohan@ccmail.inet.com, paulcov@bnr.ca, guthery@austin.sar.slb.com, pradeep@dstc.uts.edu.au, scott_linke@aus.hp.com, rdantu@tddcae99.fnts.com, bumblis@mcc.com, kseo@bbn.com, 100765.3267@compuserve.com, murase@nwk.cl.nec.co.jp, knecht@mvuss.mv.att.com, jerry@ece.concordia.ca, mustafa@ece.concordia.ca, ahmed@ece.concordia.ca, lanworks@delphi.com, yemini@cs.columbia.edu, craig@bbn.com, yoshida@netwk.ntt-at.co.jp, hegering@lrz-muenchen.de, wz@prosun.first.gmd.de, xrjo@atc.boeing.com, saracco@cselt.stet.it, christos@ece.miami.edu, wolfson@ouri.eecs.uic.edu, G_F_Wetzel@att.com, comswtc@gmu.edu, commsoft@cc.bellcore.com, ieeetcpc@ccvm.sunysb.edu, badri@cs.rutgers.edu, cellular@comnets.rwth-aachen.de, mobile-ip@tadpole.com, reres@laas.fr, cost237-transport@comp.lancs.ac.uk, dbworld@cs.wisc.edu, tccc@cs.umass.edu Subject: Looking for Panelists for IEEE Enterprise Networking (ENM '97) Content-Type: text Folks, I am chairing a Panel Session at IEEE Enterprise Networking Miniconference '97 (co-held with ICC '97) in beautiful Montreal, Quebec, June 11-12, '97. Please respond ASAP if you wish to serve on the following panel. Please also feel free to forward this email to anyone whom you think might be ideal for this panel. I am also encl. the call-for-papers for ENM '97. I wish you all a nice day! Dr. Vijay Bhagavath Bell Laboratories, Rm. 21-1D20 1600 Osgood St., N. Andover, MA 01845 (508) 960-5291 Email: bhagavath@bell-labs.com ----------------------------------------- Panel # 1: Design of Enterprise Networks Using Open Internet Technologies Panel Chair: Dr. Vijay Bhagavath, Bell Laboratories Email: bhagavath@bell-labs.com Panel Team (tentative list): Dr. Mario Santoro, AT&T Mr. Sid Shelton, Bellcore Mr. Rick Enns, Hybrid Networks Mr. Scott Marcus, BBN Planet Mr. Ken Pogran, BBN Mr. Akira Nambu, NTT Labs Dr. Stan Moyer, Bellcore (tbc) Dr. David Kirsch, (tbc) Panel Discussion Abstract (views reflect Panel Chair's only): The design of corporate computer networks using open Internet (TCP/IP, HTTP, etc) protocols and technologies (a.k.a Intranets) creates opportunities for an enormously simplified and flexible corporate computer network infrastructure, which is low-cost, and offers easy access to branch offices, employees, customers, vendors etc. A potential multibillion dollar market exists as companies transition their existing enterprise networks (often based on proprietary technologies) to Intranets. This panel will discuss the fundamental technical and business issues and challenges relating to the integration of existing- and often disparate enterprise networks using open Internet technologies. Also discussed are the attendant productivity gains resulting from Intranets, and how Intranets would potentially reshape the global business community and human society. The panelists will also answer questions solicited from the audience while the panel session is in progress. ----------------------------------------- First IEEE Enterprise Networking Mini-conference (ENM-97) in Conjunction with ICC-97, June 8-12, Montreal, Quebec, Canada CALL FOR PAPERS --------------------------------------- A Mini-conference on Enterprise Networking (ENM-97) is being organized to be held in parallel and co-located with the ICC-97 (8-12 June 1997 in Montreal, Quebec, Canada). A separate proceedings will be published and each of the ENM-97 registrants will receive a copy. ENM-97 (June 11-12, 1997) is sponsored by the IEEE Communications Society's Technical Committee on Enterprise Networking. It provides an open forum for the enterprise networking communities to review the new and emerging technologies, services, their implications from both business and technological viewpoints. The objective is to bridge the gap across: (a) Enterprise-wide business drivers and (b) Technology-driven solutions and enablers. Some examples of enterprise drivers are: (i) Cost reduction via process re-engineering, (ii) Revenue enhancement using new services, (iii) Effective interaction, efficient information access and distribution across the enterprise. The mini-conference includes keynote speeches, panel discussions, papers and poster sessions by the leaders, recognized experts and active researchers in the field. Special emphasis will be put on case studies involving efficient design/re-design, operations and management of enterprise wide computing and communications utilities with the right mix of technology and business process updates. Instructions: The title page must include corresponding author's full name, complete postal and e-mail addresses, telephone and fax numbers, and a 200-word abstract. Five double-spaced copies of the panel proposals and papers (12 point times font, maximum 3000 words) on 8.5"x11" papers should be sent to the ENM-97 program chair at the address given below. Schedule: Complete Manuscript Due: November 15, 1996 Acceptance Note Mailed: February 01, 1997 Camera-ready Paper Due: March 01, 1997 Technical areas of interest include but are not limited to: * Utilization of new and emerging technologies like ATM, PCS, CTI, full-duplex LAN services, etc. for evolution of enterprise networks to meet business and customers needs, *IntraNets, Middlenets and Internets: How they are shaping Enterprise Networks, * Handling of the legacy systems or technologies with the new and emerging ones for graceful migration to deployment of new technologies, * Integration of subsystems of enterprise networks, such as e-mail gateways, LAN switches, bridges and routers, database systems, and security and authentication mechanisms with the internets to provide "end-user" oriented services, such as video- conferencing, multi-media mails, etc., * Integration between applications and services offered by the enterprise network itself e.g., multicast service, policy routing, information retrieval, etc., * Interconnection and interoperability of all pieces of an enterprise network * Enterprise-wide computing, including distributed processing systems, distributed applications, client-serving computing, etc. * Enterprise information resource management. Enterprise Networks Management (e.g., configuration, fault, performance, accounting, security, etc.), * Business processes re-engineering using computer and communications resources distributed across the organization * Pros and cons of outsourcing the operations, management and design of enterprise networks, Negotiating for outsourcing, Insourcing after outsourcing, etc., * Integration of network and systems management from an enterprise viewpoint. * Interaction and relationship of public versus private networks, especially in light of the Telecom Act of Feb.08, 1996. Program Committee: Chair: Bhumip Khasnabish, GTE Labs. Inc., 40 Sylvan Rd., Waltham, MA 02254, USA. Tel +1-617-466-2080, Fax +1-617-890-9320 E-Mail: bhumip@gte.com Vice-Chairs: Ken Pogran (pogran@bbn.com), BBN, USA Douglas N. Zuckerman (w2xd@mtnms.att.com), AT&T, USA Publicity Chair: Vijay K. Bhagavath (vkb@mvgsf.mv.att.com), Bell Labs., USA Business and Finance: Robert S. Braudy (braudyb@aol.com), BTG, LLC, NJ, USA. Local Arrangements Co-ordinators: Mike Devetsikiotis (mike@sce.carleton.ca), Carleton University, Ottawa, Canada Oliver Yang (yang@trix.genie.O ttawa.ca), University of Ottawa, Ottawa, Canada ComSoc Co-Ordinator: Tom Stevenson (t.stevenson@ieee.org), IEEE ComSoc HQ, USA Committee Members (to-date): Majid Ahmadi , U. of Windsor, Canada Salah Aidarous, NorTel, Canada Vijay K. Bhagavath, Bell Labs., USA Robert S. Braudy, BTG, USA Nim K. Cheung, Bellcore, USA. Celia L. Desmond, Stentor Canada Chris Douligeris, U. of Miami, USA Ahmed Elhakeem, Concordia U., Canada Shervin Erfani, Bell Labs., USA Rick Enns, Hybrid Networks, Inc., USA Bob Fike, RNF Systems, USA Harvey Freeman, LANWORKS, USA Daniel Heer, AT&T, USA Heinz-Gerd Hegering,LRZ M., Germany Ron Horn, NorTel, Canada Rudolf Jaeger, BetaTechnik, Germany David Kirsch, NDC, USA John E. Knecht, Bell Labs., USA Ken Lutz, Bellcore, USA Branislav Meandzija, GI, USA Hussein Mouftah, Queen's U., Canada Robert J. Ordemann, Boeing, USA Algirdas Pakstas, Norway Craig Partridge, BBN, USA Ken Pogran, BBN, USA Mario A. Santoro, AT&T, USA Roberto Saracco, CSELT, Italy Steve Weinstein, NEC, USA Yechiam Yemini, Columbia U., USA Mac Yoshida, NTT, Japan Wolfgang Zimmer, Germany Douglas N. Zuckerman, AT&T, USA. --------------------------------------------------------------------------- -- --- End Included Message --- Subject: Looking for a few good panelists for IEEE ENM '97 From rem-conf-request@es.net Mon Jun 10 19:05:35 1996 Received: from lhc.nlm.nih.gov by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jun 1996 16:05:00 -0700 Received: from billings.nlm.nih.gov by lhc.nlm.nih.gov (4.1/SMI-4.0) id AA02676; Mon, 10 Jun 96 19:04:50 EDT Received: by billings.nlm.nih.gov (5.x/SMI-SVR4) id AA19119; Mon, 10 Jun 1996 19:07:45 -0400 Date: Mon, 10 Jun 1996 19:07:45 -0400 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <9606102307.AA19119@billings.nlm.nih.gov> To: rem-conf@es.net, debey@deltabeta.com Subject: Re: Statistics on MBone sessions. X-Sun-Charset: US-ASCII This of course varies depending upon the event. Any few folks go to the considerable trouble of documentating the level of remote attendance -- having done this once myself, I can understand why! 8^) You might be interested in our recently revised report from the 2nd Int. WWW Conf. in Chicago in Oct. 1994. We summarize the attendance logs and a remote participant survey, among other things. Navigate to "HyperDOC," our principal server, then to the "Publications" and "NLM- Published Reports...," and "Report: Multicasting..." items. I dont' supply a URL here because it is likely to change in the coming weeks... Cheerio, Rick Rodgers > From rem-conf-request@es.net Tue Jun 4 10:46 EDT 1996 > Date: Tue, 04 Jun 1996 15:30:25 -0700 > From: "Henry C. DeBey" > Reply-To: debey@deltabeta.com > Organization: Delta Beta Pty. Ltd. > X-Mailer: Mozilla 3.0b3Gold (Win95; I) > Mime-Version: 1.0 > To: rem-conf@es.net > Subject: Statistics on MBone sessions. > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; charset="us-ascii" > Content-Length: 207 > > I would like to get some idea of the numbers of particpants in past > MBone multicasts. Can someone provide some pointers to results of > mlisten monitoring or other statistics on MBone participation? > > Henry > > From rem-conf-request@es.net Tue Jun 11 00:23:53 1996 Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP); Mon, 10 Jun 1996 21:23:25 -0700 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA15679; Tue, 11 Jun 96 00:23:23 EDT Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA06955; Tue, 11 Jun 96 00:23:21 EDT Received: by smtpnotes.pictel.com (4.1/SMI-4.1) id AA27200; Tue, 11 Jun 96 00:23:21 EDT Message-Id: <9606110423.AA27200@smtpnotes.pictel.com> Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id BFBA407FC1E034DC85256346001431EC; Tue, 11 Jun 96 04:23:19 To: Henry Sinnreich Cc: Luis de Pieri , confctrl , rem-conf , IMTC , Sakae Okubo From: Rich Baker/PicTel Date: 10 Jun 96 23:48:39 EDT Subject: RE: (CNC) Re: SG-15 last meeting Mime-Version: 1.0 Content-Type: Text/Plain Hi Henry: The H.323 working documents are maintained at an FTP site by Mr. Okubo, the Rapporteur for H.323. While password protected, Mr. Okubo encourages anyone interested in the H.323 work to access the site: Site: ftp.gctech.co.jp Login name: itu-t Password: sg15!avc You can see most recently posted 10 files by typing "ls -ltr | tail". Please note that Mr. Okubo assures me he will post the most recent drafts of the H.323, H.225.0 and H.245 recommendations within the next few days. Cheers, -rich baker IMTC Corporate Network Conferencing AG chair bake@pictel.com ===== To: Rich Baker, ldepieri @ ifhamy.insa-lyon.fr (Luis de Pieri) @ smtp cc: confctrl @ ISI.EDU @ smtp, rem-conf @ es.net @ smtp, IMTC @ world.std.com @ smtp From: henry.sinnreich @ mci.com (Henry Sinnreich) @ smtp Date: 06/07/96 09:48:35 PM Subject: RE: (CNC) Re: SG-15 last meeting Rich, Is the any online info anywhere ? Would appreciate it. Thanks, Henry From rem-conf-request@es.net Tue Jun 11 04:00:44 1996 Received: from xr3.atlas.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 01:00:03 -0700 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Tue, 11 Jun 1996 09:59:14 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Tue, 11 Jun 1996 09:59:14 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Tue, 11 Jun 1996 09:59:17 +0200 X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed; Tue, 11 Jun 1996 12:59:00 +0200 Date: Tue, 11 Jun 1996 12:59:00 +0200 X400-Originator: haignere@issy.cnet.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=FR/;834479946@x400.issy.cnet.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: internet and vid Alternate-Recipient: Allowed From: Isabelle HAIGNERE Message-ID: <9606110759.AA01673@haddock> To: oshapiro@eng.tau.ac.il, rem-conf@es.net Subject: internet and videoconference Content-Length: 1237 *-------------------------------------------------------* | From : Isabelle Haignere | | CNET - PAB/STC/SGV | | 38-40 rue du General Leclerc | | F-92 131 Issy les Moulineaux | | FRANCE | | | | Tel. : + 33 1 45 29 40 08 | | Fax. : + 33 1 45 29 52 94 | | | | E-mail : isabelle.haignere@issy.cnet.fr | *-------------------------------------------------------* hi, I would like to know what RFCs and what problems are devoted to videoconference, I see two fields : - problems linked to the quality of the service (bandwith of Internet, error protection, ...) how are the coding schemes influenced by these characteristics ? How will H263 evolve ? What about audio ? - problems linked with the MBone for multicast conferences. Am I right ? Please , could you help me ? Thank you very much. The following site could help you, Ofer : http://www.research.att.com/mbone-faq.html. Isabelle HAIGNERE From rem-conf-request@es.net Tue Jun 11 04:17:01 1996 Received: from ifhamy.insa-lyon.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 01:16:32 -0700 Received: (from clesigne@localhost) by ifhamy.insa-lyon.fr (8.6.9/8.6.5/AEDI-AG) id KAA23304 for rem-conf@es.net; Tue, 11 Jun 1996 10:16:30 +0200 From: Christophe Lesigne Message-Id: <199606110816.KAA23304@ifhamy.insa-lyon.fr> Subject: Vat-Vic for Windows 95 To: rem-conf@es.net Date: Tue, 11 Jun 1996 10:16:30 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 559 Now I have the latest versions of Vat and Vic for Windows95. I have no problem to run a session but I can't receive any sound or video from a vat or vic session running on a Unix station, and the Unix vat or vic sessions are not detected by the PC sessions. On the Unix vat or vic sessions I can see the Windows95 sessions! I have a sound blaster 16 card but no video capture board. So what can I do? Is it possible that the PC with Windows95 doesn't support multicast? In this case what can I do to be sure to have the multicast option working well? From rem-conf-request@es.net Tue Jun 11 06:53:02 1996 Received: from VNET.IBM.COM by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 03:52:26 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3627; Tue, 11 Jun 96 06:52:10 EDT Date: Tue, 11 Jun 96 13:05:30 IST From: Scott Petrack To: casner@precept.com, cabo@ruin.informatik.uni-bremen.de, ellesson@VNET.IBM.COM, rem-conf@es.net, its@www.raleigh.ibm.com Subject: draft-petrack-crtp-00.txt Friends, Here is a draft of my part of the RTP compression draft. It is clearly incomplete, but contains some issues that I think need to be resolved before going further. In case your curious about the relation between draft-petrack-crtp-00.txt and draft-casner-jacobson-crtp-00.txt, well, you'll have to read them both. They are definitely not "rival proposals" in any case. (well, of course I can speak only for myself here ;-)). I send it here in case someone wants to complain before Thursday. (Although I can't promise to pay attention, I'll try to do so). Scott ====================================================== Internet Engineering Task Force Audio/Video Transport Working Group INTERNET-DRAFT Scott Petrack, IBM draft-petrack-crtp-00.txt 11 June 1996 Expires: December 1996 Compression of Headers in RTP Streams Status of this Memo This document is a draft of a part of 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. Please see the acknowledgements at the end of this note for a special comment about the past, present, and future contributors to this note. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete 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 We analyze the requirement to compress the headers of RTP data streams. It is argued that there is a need to define two different compression schemes: an "interim solution" in which only RTP headers are compressed, and a "complete solution" which compresses the RTP/UDP/IP headers only across serial links. It is argued that the complete solution must include a new "guaranteed header compression service," if it is to be useful. The two solutions are described, along with a transition strategy which ensures that only the complete solution will be used when this is possible. 0. Introduction RTP [1] is finding acceptance as the standard means of transporting time related data over the Internet. Unfortunately, it is often impossible to use RTP/UDP/IP over a low-bitrate link - the header overhead leaves no room at all for data, or at the very least implies an unacceptable delay in the delivery of the data, because too much data must be lumped into a single packet. This paper gives two precise solutions. The central theme common to both is to compress the headers of the RTP data stream. draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 11 June 1996 Page 2 The first solution involves compressing the RTP/UDP/IP headers within the stream. Enabling this requires specific additions to the current Internet infrastructure. We show that these are necessary to produce a "complete" solution. The modifications involved are similar in spirit to those of the general framework outlined in [2]. But we claim that something stronger is needed. Indeed, one can consider our solution as a definition of a new service to be provided in the context of Integrated Services. The second solution requires compressing only RTP itself, and can be implemented immediately. Because of its more limited nature, the second solution gives only interim relief, and it is intended that it will disappear seamlessly once the necessary Internet infrastructure has been established. That is, the interim solution has enough knowledge of the complete solution so that it can recognize the presence of the complete solution in the network, and turn itself off. We describe precisely the way in which the "interim solution" will transform into the "complete solution." This document is a submission to the IETF AVT working group. Although our solution does indeed have implications for other IETF working groups, the essential center of the work is a new algorithm for the compression of headers which include RTP headers, and how this header compression will fit into Internet infrastructure. The problem that is solved is how to enable the transport of real-time data that cannot be transported using the full RTP/UDP/IP headers as currently defined, when crossing a low bitrate link. 1. What's the matter? The smallest (and most common) size of an RTP header is 12 bytes [1]. When combined with UDP and IP, this implies at least a 40 byte per header overhead. There are many discussions available about the adverse effect of header overhead on interactivity in general. See [3] for a discussion of the particular problem of interactive telnet traffic. This was a primary motivation for TCP/IP header compression now in widespread use. When the traffic involved is interactive voice, then header compression ceases to be something extremely useful and becomes something absolutely necessary. Indeed, consider transmitting voice over a link of bandwidth b bytes/sec. Suppose that each there are: n bytes per each compressed voice-frame, f voice-frames/sec, h bytes/packet-header, and suppose one decides to lump together k voice frames into each network packet, in order to make it fit into the bandwidth b. A moment's thought shows that the bandwidth required is: b = (nk + h) * (f / k) bytes/sec; draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 11 June 1996 Page 3 Equivalently if we have b bandwidth available, then: k = (h * f)/(b-nf) voice-frames/network-packet. k is the measure of the delay in the voice communication, so this means that the delay will increase linearly with the total header size. There are at least two situations where the overhead is unnacceptable: a. low-bandwidth serial links The explosion of modem dial-up links to the Internet, (and the explosion in the desire of users to run audio and video over those links), makes it imperative that RTP scale down to links of bandwidth 14.4kbps and 28.8kbps. b. multiple RTP streams Some multimedia applications require several real-time streams to be running simultaneously, and each stream is a separate RTP session. Of course, "low" is a relative term: an ISDN link is certainly low bandwidth if one wishes to receive MBONE traffic. In general, the ideas here will be useful on sub-T1 links as in [2]. Also, we will restrict our attention to point-to-point links. But much of the discussion will be valid for other link technologies as well. We expect that the following technology will indeed be useful in other contexts where it makes sense. The current crop of Internet Telephone and Video applications are very sensitive to this problem. The extra 12 bytes/packet that RTP imposes has implied simply that these applications do not use RTP. Now one solution is to blame these horrible applications; but in fact with the currently common frame rate of one voice frame every 20 msecs, the 40 byte RTP/UDP/IP header per packet is already too large to send across a 14.4kbps link. The problem is a real one. Even if one excludes 14.4 kbps links (a terrible idea), one must consider the Internet version of Parkison's law: a bytestream expands to fill the bandwidth allotted to it. These internet communication applications will continue to develop, and they will continue to prefer to use the available bandwidth for tranporting their data rather than headers. Surely a decent respect for the prinicples of engineering requires that one try to compress the transport headers in a reasonable manner. Note that although RTP is not quite a third of the total RTP/UDP/IP bandwidth, it is indeed the difference between the possible and the impossible for these applications: one can send 36 bytes every 20msecs over a 14.4 link. The result is that most applications simply have not used RTP for encapsulating voice when there is a slow serial link between the two ends. They use some non- interoperable, proprietary scheme which sends at most one or two bytes in place of RTP's 12. draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 11 June 1996 Page 4 Indeed, the problem of encapsulation overhead for real-time streams has given rise to at least two incompatible ITU-T standards for mixed voice and data over a serial link. These developments should worry anyone who shares the dream of IP and the Internet being used for multiple real-time and non-real time streams, some of which may or may not be synchronized. Excluding dial-up users from this game would be very sad, and extremely counter-productive. 2. Previous Suggestions RTP-only compression as a means of making serial-link Internet Telephony acceptable and interoperable was first proposed in [4]. It was suggested to compress only the RTP headers because not doing this is what made Internet Telephony impossible, and because anything else requires changes to the Internet infrastructure. It was immediately noticed [5] that one could combine RTP-only compression independently with the IPv6 UDP/IP compression of [6] to obtain a more useful service. And the already cited [2] argues that compressing RTP makes sense only in the framework of integrated services and compressing all the headers RTP/UDP/IP, together with a real-time multiplexing service for giving guranteed bandwidth or controlled load over a serial link. There is a fourth possibility, which is recently proposed by Casner and Jacobson in an upcoming (outcoming?) internet-draft [7], which is to perform RTP/UDP/IP similarly to the way one now performs TCP/IP header compression, according to RFC 1144. This would be simply a new elective protocol for compression of the RTP/UDP/IP headers across a point-to-point link, divorced from the ideas of Integrated Services. Indeed, it is explicitly stated in RFC 1144 that the two reasons not to compress UDP/IP traffic are that this traffic either lacks coherence from packet to packet (like DNS traffic), or that other higher level headers overwhelm the gain from UDP/IP compression (like RPC/NFS). These two arguments are clearly not valid for a typical RTP stream carrying interactive voice traffic, if one extends to compress the 40 byte RTP/UDP/IP header. In some sense these approaches are not contradictory and can co-exist. But obviously one should not waste valuble time defining and RTP-only compression scheme if indeed this is not useful, as [2] argues. And if independent RTP and IPv6 UDP/IP compression is enough, then there is no need to define a new RTP/UDP/IP standard, or to juggle the integration that is required by Integrated Services. 3. The Requirements To uncut this difficult knot, let us list the requirements at hand: a. It is a requirement to end the current chaos of non-interoperable (and non-multicast) audio and video applications. This chaos does more and more harm, and a concerted effort to tame these applications is necessary immediately. draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 11 June 1996 Page 5 This means that an effort should be made to replace the one- (or few-) byte real time encapsulation used by current realtime non-RTP applications with some standard encapsulation which is not ruinous in overhead, and yet allows for multicast and other applications. It is certainly desireable, and probably required, that this encapsulation contain all the information that is contained in RTP. b. There is a requirement to allow these applications to become good citizens without changing the Internet Infrastructure, since these applications are not going to wait for RTP/UDP/IP compression to become widespread over dialup links, and certainly not for Integrated Services to become widely available over dial up links. This means that there must be some form of end-to-end RTP compression sanctioned. c. There is a requirement to ourselves, to truth, justice, and the Internet Way, to decide what the correct solution is, or would be, if there were no Internet Telephones that need relief right now. Such a complete solution contains the following elements: 1. no end-to-end hard state 2. special header compresssion only along hops which require it - i.e. only along "slow links." 3. along such slow links, since one must install state and new code, all headers should be compressed, not just RTP. 4. if an application requires that such compression take place, there should be some standard interface to allow it. It was argued in [2] that the PATH message of RSVP is the correct "standard interface." The word "requires" in c.4 demands special comment. The suggestions mentioned above in section 2 all have one important point in common: they assume that header compression is applied electively. Even the suggestion to use the PATH message was so that the application can inform the relevant links that compression is possible and desireable. We claim that there is an important difference between TCP/IP compression and the current situation of RTP applications over slow serial links: in the current situation, the application truly *requires* there to be header compression in order to make transmission worthwhile. It is not just a very useful - it is necessary. Using 40 byte RTP/UDP/IP headers over 14.4 modems implies delays which are measured in seconds. It is common practise to blame "the Internet" for such horrible performance, but some experimenting with two computers connected via a null modem cable (or better, a single brain connected to some paper and pencil) will convince one that a single low bandwidth link implies unacceptably large delays. draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 11 June 1996 Page 6 For this reason, we are confronted with the need for a new service: the application must be able to ask the network for a guarantee that headers will be compressed along slow links. This is a different service from either of the two usual services of IntServ. A hard guarantee is required, but not of available bandwidth. Internet Phones can work just fine without bandwidth guarantees or even controlled load, but they cannot function with 40 byte RTP/UDP/IP headers. We have just argued that requirement c.4 implies the need for a new service of "guranteed header compression," at least across slow links. There is another more unpleasant reason that the complete solution should be careful to include giving an application the right to to require guranteed header compression, related to requirement b: The current non-RTP one-byte encapsulation schemes have the advantage that they Internet Telephone and Video applications to exist. If it can happen with the new standard that there is a slow link where RTP headers at least are not compressed, then the applications won't use the new standard. Certainly nothing is going to go to the trouble of using a new piece of internet infrastructure unless it gives them at least as good a service as it was getting with the old infrastructure. Only a "guaranteed header compression service" can give an application the piece of mind that it has now, when it uses a proprietary one-byte encapsulation. If the new extensions do not offer this much, then the internet telephone applications will at best agree among themselves on a new one or two-byte encapsulation. You might think that the guaranteed bandwidth service, when it becomes widely available, will suffice. This is unfortunately not the case. We have seen that the entire bandwidth of a slow serial link will not suffice if RTP/UDP/IP is used. In any case, it is preferable to offer a "header compression service" than to have all those applications use a guaranteed bandwidth service. The conclusion is that there is requirement for a new service, where the application can request a guarantee that the RTP/UDP/IP headers will be compressed over the slow links. More generally, one could make this service one whose parameters would be the the protocols of headers which for which one obtains a guarantee of compression, and the type of link over which the compression will occur. This service would be "XXX, YYY, ZZZ header compression over qqq-links." draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 11 June 1996 Page 7 The problem of dealing with header compression when using the usual guaranteed bandwidth service was mentioned in [2], but in the context of how to enable the routers to use the header compression to allow them to reserve bandwidth. This is not the same as a guaranteed header compression service, which is what is required here. A new service for "guaranteed bandwidth b for my data, which is being sent with protocols RTP/UDP/IP", although perhaps very useful, is stronger than what is required. There will be many situations where header compression is required but not guaranteed reserved bandwidth or even controlled load. Of course, one might define a "header compression requested" service to be the controlled-load analogue of the "header compression required" service considered here. There is one more feature left to consider, which we consider to be so obviously desireable as to be a fourth requirement: d. There must be a smooth transition from the end-to-end compression scheme into the new integrated service being proposed. Indeed, it should be possible for any application which can negotiate for end-to-end compression to be able to receive and understand from the network a message which instructs it "not to bother" to perform the end-to-end compression, but to send full RTP headers and let the network take care of the compression. If we can do this, there are very desireable advantages, apart from the obvious one of planning the obsolence of something disgusting. The application will be very happy to use the standard solution, because is it guaranteed that it will obtain improved performance as soon as the complete solution is in place. This is because the complete solution will compress RTP/UDP/IP and not just RTP. Also, it will allow forward compatibility with new applications which will not know about the interim end-to-end compression. We have now finished defining the task at hand. Let us list our conclusions: 1. We require an interim standard for end-to-end RTP compression. 2. We require a complete solution which uses RTP/UDP/IP compression only over the slow links. The complete solution will also include a new Integrated Service: "guaranteed RTP/UDP/IP header compression over slow serial links." 3. We require that the interim solution have enough knowledge of the complete solution that it will be able to recognize the presence of the complete solution in the network. When it does so, it will turn itself off. The rest of this paper is devoted to defining these two compression standards, "interim" and "complete." We shall also define an algorithm by which an implementation of the interim solution will detect the presence of the complete solution, and a QoS routing algorithm which is needed to deploy the new Integrated Service. draft-petrack-crtp-00.txt Compression of Headers in RTP Streams 11 June 1996 Page 8 Left to write up: 1. RTP/UDP/IP compression (from SC and VJ). 2. algorithm for QoS routing for guaranteed header compression on slow links, links to ISSLOW (ISSLL) and IntServ. 3. RTP-only compression 4. RTCP and RTCP/UDP/IP compression 5. new RTCP message types to negotiate end-to-end RTP-only compression 6. transition from interim to complete solution: using port on local stack to request complete solution in interim-solution applications Acknowledgements: The author wishes to acknowledge useful discussions with and expressions of distaste from Steve Casner, Carsten Bormann, and Ed Ellesson. NB: Steve Casner and Van Jacobson have produced an algorithm for compression of the RTP/UDP/IP headers [7], which is being produced as a separate draft. The author here both hopes (plans?) the two drafts will be merged into one. It is very important that no end-to-end compression scheme be allowed which does not already require a hook for the complete solution. The two drafts are at present separate because time considerations precluded integration of any sort. References: [1] H. Shulzrinne, S. Casner, R. Frederick, and S. McCanne, "RTP: A Transport Protocol for real-time applications." RFC 1889 [2] Carsten Borman: "Providing integrated services over low-bitrate links" draft-bormann-issll-isslow-00-pre-3.txt (http://www-rn.informatik.uni-bremen.de/research/isslow.html, .txt, .ps) [3] Jacobson, "TCP/IP Compression for Low-Speed Serial Links." RFC 1144 [4] Petrack and Ellesson, "Framework for C/RTP: Compressed RTP Using Adaptive Differential Header Compression." contribution to mailing list rem-conf@es.net, Feb. 96 and talk at AVT working group, IETF March 96 [5] M. Degermark, private correspondence [6] Degermark et. al.: "Header Compression for IPv6" draft-degermark-ipv6-hc-00.txt [7] S. Casner and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links." draft-casner-jacobson-crtp-00.txt From rem-conf-request@es.net Tue Jun 11 07:19:16 1996 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 04:18:39 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id EAA25116; Tue, 11 Jun 1996 04:15:15 -0700 Message-Id: <199606111115.EAA25116@rx7.ee.lbl.gov> To: Christophe Lesigne cc: rem-conf@es.net Subject: Re: Vat-Vic for Windows 95 In-reply-to: Your message of Tue, 11 Jun 96 10:16:30 N. Date: Tue, 11 Jun 96 04:15:15 PDT From: Van Jacobson > I can't receive any sound or video from a vat or vic session > running on a Unix station, and the Unix vat or vic sessions are > not detected by the PC sessions. On the Unix vat or vic sessions > I can see the Windows95 sessions! I believe what you are seeing is a bug in Microsoft's tcp/ip stack. If you have "Microsoft Dialup Networking" support installed, you might try removing it -- multicast does not appear to work if this is installed (even if you are not using it; e.g., Microsoft Dialup Networking completely breaks ethernet multicast). - Van From rem-conf-request@es.net Tue Jun 11 08:15:39 1996 Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 05:14:40 -0700 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA26673; Tue, 11 Jun 96 08:14:38 EDT Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA10187; Tue, 11 Jun 96 08:14:37 EDT Received: by smtpnotes.pictel.com (4.1/SMI-4.1) id AA00491; Tue, 11 Jun 96 08:14:36 EDT Message-Id: <9606111214.AA00491@smtpnotes.pictel.com> Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id FA0BD0D38C58FB8B85256346004200C3; Tue, 11 Jun 96 12:14:35 To: rem-conf , confctrl , IMTC Cc: okubo From: Rich Baker/PicTel Date: 11 Jun 96 8:13:00 EDT Subject: CNC: Latest H.323 documents now posted Mime-Version: 1.0 Content-Type: Text/Plain Hi Folks: Final versions of H.323 and H.245 have been posted to the H.323 working document ftp site. These docs have filenames H323NCM3.DOC (96/06/11 H.323 decided on 28 May 1996 with no change marks) and H245NCM5.DOC (96/06/11 Definitive H.245 Version 1 to be published). Site: ftp.gctech.co.jp Login name: itu-t Password: sg15!avc Note that compressed versions (*.gz) are there to minimize downloading times >from the server in Japan. Cheers, -rich To: sg15.avc @ research.kpn.com @ smtp, h32z2-list @ mtgzfs3.mt.att.com @ smtp cc: (bcc: Rich Baker/PicTel) From: okubo @ gctech.co.jp @ cbig1.att.att.com @ smtp Date: 06/11/96 07:55:40 PM Subject: Output documents of the last week SG15 meeting Dear AVC colleagues, I have uploaded the attached files which were output at the SG15 meeting held during 27 May - 7 June. More will be available soon. Here are some tips to retrieve the document you need. - You can see the most recently posted 10 files by typing "ls -ltr |tail". - You can use the gzip (different from zip) compression on the fly by typing "get filename.gz" for faster transfer. For example, if you need the file named H245NCM5.DOC (1631744 Bytes), type "get H245NCM5.DOC.gz". Then you will receive H245NCM5.DOC.gz (282252 Bytes). Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0185 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo@gctech.co.jp 151 Japan ******************************************************************** login directory ----------------------------------------------------------------- File name Date Content ================================================================= H323NCM3.DOC 96/06/11 H.323 decided on 28 May 1996 with no change marks ----------------------------------------------------------------- DELTA2.DOC 96/06/11 Defect Report for Recommendation H.245 - Delta Document 2 ----------------------------------------------------------------- H245NCM5.DOC 96/06/11 Definitive H.245 Version 1 to be published, = h245ncm4.doc + DELTA2.DOC ----------------------------------------------------------------- H245NCM6.DOC 96/06/11 Recommendation H.245 Version 2, determined on 7 June 1996 = H245NCM5.DOC + D_H245V2.DOC ----------------------------------------------------------------- D_H245V2.DOC 96/06/11 Proposed Modifications to H.245 Version 1 to obtain Version 2, determined on 7 June 1996 by SG15 ----------------------------------------------------------------- NEW_QUES.DOC 96/06/11 Six Questions for 1997-2000 proposed by WP1/15 ----------------------------------------------------------------- FRAMEJUN.DOC 96/06/11 Framework for standards for audiovisual/ multimedia services - by Dr. Norman D. Kenyon ----------------------------------------------------------------- GUIDEJUN.DOC 96/06/11 A Guide to International Telecomms-related Multimedia Standards, a companion to the "framework" - by Dr. Norman D. Kenyon ----------------------------------------------------------------- WP1_REP.DOC 96/06/11 Meeting report of WP1/15 issued by Mr. Makoto Yamashita ----------------------------------------------------------------- H323WHT8.DOC 96/06/11 H.323 decided on 28 May 1996, with change marks to COM 15-245 ----------------------------------------------------------------- H323WTD8.DOC 96/06/11 Changes to COM 15-245 agreed by SG15 on 28 May 1996 ----------------------------------------------------------------- H310_dec.ww2 96/06/10 H.310 - converted from H310_dec.mw5 ----------------------------------------------------------------- H310_dec.mw5 96/06/10 H.310 agreed by SG15 on 7 June 1996, to be decided after receiving the advice of France which requested the six week reservation ----------------------------------------------------------------- /N_ISDN ----------------------------------------------------------------- File name Date Content ================================================================= FRAMEJUN.DOC 96/06/11 Framework for standards for audiovisual/ multimedia services - by Dr. Norman D. Kenyon ----------------------------------------------------------------- H230JUN.DOC 96/06/11 revision of H.230 determined on 7 June 1996 --------------------------------------------------------------- H221JUN.DOC 96/06/11 revision of H.221 determined on 7 June 1996 ---------------------------------------------------------------- GUIDEJUN.DOC 96/06/11 A Guide to International Telecomms-related Multimedia Standards, a companion to the "framework" - by Dr. Norman D. Kenyon ---------------------------------------------------------------- H242JUN.DOC 96/06/11 revision of H.242 determined on 7 June 1996 ---------------------------------------------------------------- From rem-conf-request@es.net Tue Jun 11 09:09:51 1996 Received: from tama.tas.ntt.jp by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 06:09:04 -0700 Received: by tama.tas.ntt.jp (8.7.5/tas-sh-02) with TCP; Tue, 11 Jun 1996 22:09:05 +0900 (JST) Received: by nttmail.tas.ntt.jp (8.6.12/nttmail-02) with TCP; Tue, 11 Jun 1996 22:08:35 +0900 Received: by nttvdt.hil.ntt.jp (8.6.9/hil-1.1); Tue, 11 Jun 1996 22:08:23 +0900 Message-Id: <9606111252.AA00486@nttvdt.hil.ntt.jp> Date: Tue, 11 Jun 1996 21:52:35 +0900 From: Hiroshi Jinzenji To: myjak@tridis.ist.ucf.edu (Michael Myjak) Cc: rem-conf@es.net, sv@www-hil.tas.ntt.jp Subject: Re: Propose RSTP & SoftwareVision In-Reply-To: <199606101849.OAA09990@mach-1.tridis.ist.ucf.edu> X-Mailer: AL-Mail 1.12 myjak@tridis.ist.ucf.edu (Michael Myjak) wrote: >> first a Q: Where can I read about RSTP? I have some documents, but those are written in japanese. Sorry, English version is only "DAVIC / CFP4_018", that is almost same as mail version. I will answer your questions and publish infomations and FAQ of RSTP on our Web page. ----------- jinzen!! From rem-conf-request@es.net Tue Jun 11 10:53:08 1996 Received: from trout.nosc.mil by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 07:52:26 -0700 Received: from cod.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA04427; Tue, 11 Jun 96 07:52:23 PDT Received: from dilbert.nosc.mil ([198.253.148.70]) by cod.nosc.mil (4.1/SMI-4.1) id AA23178; Tue, 11 Jun 96 07:49:36 PDT Date: Tue, 11 Jun 1996 07:49:41 -0700 (PDT) From: "Mark T. Ganzer" To: Van Jacobson Cc: Christophe Lesigne , rem-conf@es.net Subject: Re: Vat-Vic for Windows 95 In-Reply-To: <199606111115.EAA25116@rx7.ee.lbl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 11 Jun 1996, Van Jacobson wrote: > > I can't receive any sound or video from a vat or vic session > > running on a Unix station, and the Unix vat or vic sessions are > > not detected by the PC sessions. On the Unix vat or vic sessions > > I can see the Windows95 sessions! > > I believe what you are seeing is a bug in Microsoft's tcp/ip > stack. If you have "Microsoft Dialup Networking" support > installed, you might try removing it -- multicast does not > appear to work if this is installed (even if you are not using > it; e.g., Microsoft Dialup Networking completely breaks ethernet > multicast). > > - Van Van, A couple of weeks ago, I tested the Windows 95 versions of Vic/Vat on a laptop that had dial-up networking inastalled and had no problems. I DID have to start the sessions "manually" using the command line generated by SDR on my Sun Ultra because the UVA version of SDR for Windows 95 is v2.1 and won't recognize sessions created with SDR 2.2. I haven't had a chance to try any of the other Windows 95 session managers. I should note that the laptop was running Windows 95 w/ Service Pack 1. Dial-up networking is installed (I use it for travel) but was not active during the tests - the connection to the network during this test was via a 3Com PCMCIA ethernet card. Mark Ganzer Naval Command, Control & Ocean Surveillance Center, ganzer@nosc.mil RDT&E Div (NRaD), Code 4123, San Diego, CA Ph: (619) 553-1186 FAX: (619) 553-4808 From rem-conf-request@es.net Tue Jun 11 13:41:25 1996 Received: from unb.ca (actually hermes.csd.unb.ca) by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 10:40:52 -0700 Received: (from cythera.unb.ca [131.202.3.18]) by unb.ca (8.7.5/960430-08:40) id OAA27642 for ; Tue, 11 Jun 1996 14:40:47 -0300 (ADT) Received: (from cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.7.5/8.7.1) with SMTP id OAA28151 for ; Tue, 11 Jun 1996 14:40:46 -0300 (ADT) Date: Tue, 11 Jun 1996 14:40:46 -0300 (ADT) From: "Dwight E. Spencer" To: rem-conf@es.net Subject: mbone broadcast, "CSpace" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm currently sending a very low bandwidth video stream to a session I have on the MBone under "Community Acces Office / CSpace " .. I've been sending this to Canada only , as of late (ttl 63), and decided to let a few more people watch the locale. If this causes a problem with anyone trying to do a more 'valueable' broadcast, please let me know and I'll stop it immediately. dwight s. ----------------------------------------------------------------------- Dwight E. Spencer Canada's Community Access Network eMail: spencer@unb.ca, Server Administrator UNB, Fredericton, NB, Canada Phone: +1 506 447 3153 Url: http://cspace.unb.ca/~spencer/ From rem-conf-request@es.net Tue Jun 11 14:01:27 1996 Received: from my28.sm.luth.se by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 11:00:26 -0700 Received: from my8.sm.luth.se (my8.sm.luth.se [130.240.3.38]) by my28.sm.luth.se (8.7.5/8.7.2) with ESMTP id TAA19166 for ; Tue, 11 Jun 1996 19:59:48 +0200 Received: from localhost (micke@localhost) by my8.sm.luth.se (8.6.11/8.6.11) with SMTP id UAA03479 for ; Tue, 11 Jun 1996 20:03:02 +0200 Message-Id: <199606111803.UAA03479@my8.sm.luth.se> X-Mailer: exmh version 1.6.6 3/24/96 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: rem-conf@es.net Subject: Compression of RTP/UDP/IP Date: Tue, 11 Jun 1996 20:03:00 +0200 From: Mikael Degermark I have just read the first versions of Casner and Jacobsons draft on compression of RTP/UDP/IP and Petrack's draft and being the main author of the draft on header compression for IPv6 I have the following comments from the top of my head: 1. I like it. Header compression for IPv6 should definitely include mechanisms for compressing RTP. With IPv6 we have the opportunity to require all hosts and routers to support good header compression (it is *needed* for IPv6...) 2. Multihop radio-based networks such as Metricom will reorder packets when they are routed around congestion points. On such links it will not be sufficient with three bits of sequence number as suggested by Casner and Jacobson. Is it really a good idea to have a compression mechanism that excludes such links? Such links can have fairly low bandwidth, and it seems to me that radio will be a very common way to access the Internet... 3. Wouldn't it be better to use the Length field of the UDP and/or IP header to transfer the session context (C) in full headers? The link-layer must provide the length of the frame to allow decompression, so the length fields are available. Using the Protocol field makes it impossible to compress headers other than the simplest possible IPv4/UDP/RTP headers. 4. There does not seem to be any methods for compressing tunneled packets, i.e., packets with multiple IP headers. Such packets occur for example when Mobile IP is used. Since the headers are even bigger then, shouldn't such packets be compressed too? 5. Finally, although I personally think that using authentication on *every* packet is a bad idea on low-speed links since the hash uses so many bytes, I can see the need to authenticate or encrypt over radio links. Shouldn't we make it possible to compress even when the ipsec stuff is being used? Mikael Degermark From rem-conf-request@es.net Tue Jun 11 17:08:22 1996 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 14:07:25 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id OAA26046; Tue, 11 Jun 1996 14:07:39 -0700 Message-Id: <199606112107.OAA26046@rx7.ee.lbl.gov> To: "Mark T. Ganzer" cc: Christophe Lesigne , rem-conf@es.net Subject: Re: Vat-Vic for Windows 95 In-reply-to: Your message of Tue, 11 Jun 96 07:49:41 PDT. Date: Tue, 11 Jun 96 14:07:38 PDT From: Van Jacobson Mark, Your laptop sounds identical to mine (w95 + service pack 1 & 3c589 pcmcia card). We couldn't receive multicast (sending worked fine) then I saw a note on one of the usenet comp.sys.win groups about problems with MS dial-up networking & removed it (we never used it -- it was only there because it's installed by default). Ethernet multicast reception immediately started working. Since then about half a dozen people have reported the same problem as Christophe, we've suggested this fix & it has worked. Perhaps the difference with your machine is that you actually use the dial-up networking -- maybe configuring it resets whatever causes it to eat multicast. I admit we didn't try to circumscribe the bug -- there are so many win95 bugs that we're happy to just find a usable path through the minefield & never try to map every charge. - Van From rem-conf-request@es.net Tue Jun 11 18:30:20 1996 Received: from trystero.radio.com by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 15:29:23 -0700 Received: (carl@localhost) by trystero.radio.com (8.7.5/940816.06ccg) id SAA07195; Tue, 11 Jun 1996 18:29:06 -0400 (EDT) From: "Carl Malamud [IMS]" Message-Id: <199606112229.SAA07195@trystero.radio.com> Subject: Re: Vat-Vic for Windows 95 To: van@ee.lbl.gov (Van Jacobson) Date: Tue, 11 Jun 1996 18:29:06 -0400 (EDT) Cc: ganzer@nosc.mil, clesigne@ifhamy.insa-lyon.fr, rem-conf@es.net In-Reply-To: <199606112107.OAA26046@rx7.ee.lbl.gov> from "Van Jacobson" at Jun 11, 96 02:07:38 pm Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Van - Win95 plays very bad games with the routing tables. What probably happened is that it was directing multicast traffic out your dialup interface, even if you weren't using it. For folks who use dialup, you might try Net Switch at: http://www.winsite.com/info/pc/win95/netutil/netsw190.zip/ Allows you to save various configurations in a file and switch them without (usually) rebooting. Good way to flip between different network providers and to zap away the extra routes. Carl According to Van Jacobson: > > Mark, > > Your laptop sounds identical to mine (w95 + service pack 1 & 3c589 > pcmcia card). We couldn't receive multicast (sending worked fine) > then I saw a note on one of the usenet comp.sys.win groups about > problems with MS dial-up networking & removed it (we never used > it -- it was only there because it's installed by default). Ethernet > multicast reception immediately started working. Since then about > half a dozen people have reported the same problem as Christophe, > we've suggested this fix & it has worked. Perhaps the difference > with your machine is that you actually use the dial-up networking -- > maybe configuring it resets whatever causes it to eat multicast. > I admit we didn't try to circumscribe the bug -- there are so many > win95 bugs that we're happy to just find a usable path through the > minefield & never try to map every charge. > > - Van > From rem-conf-request@es.net Tue Jun 11 19:50:07 1996 Received: from dns2.noc.best.net by osi-west.es.net with ESnet SMTP (PP); Tue, 11 Jun 1996 16:48:18 -0700 Received: from mg128-24.ricochet.net (mg128-24.ricochet.net [204.179.128.24]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id QAA08401 for ; Tue, 11 Jun 1996 16:48:05 -0700 Date: Tue, 11 Jun 1996 16:48:05 -0700 Message-Id: <1.5.4.16.19960611164755.25b77350@pop.best.com> X-Sender: rsf@pop.best.com X-Mailer: Windows Eudora Light Version 1.5.4 (16) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Ross Finlayson Subject: Re: Vat-Vic for Windows 95 I originally had the same problem getting multicast to work on Windoze 95. The breakthrough, in my case, was discovering that it has a set of (DOS-mode) networking diagnosting commands, including "route" (equivalent to Unix's "netstat -r"). When I ran "route print", I discovered that the machine had two different sets of routes to everwhere (including two different routes for 224.0.0.0). The problem was - as Van and Carl have also noted - that there were two different TCP/IP entries in my "network" control panel: one for "dialup", and the other for Ethernet. Removing the first TCP/IP entry (which I no longer used anyway) solved the problem. Come to think of it, it was kinda surprised that *unicast* had ever worked properly, with all of these bogus route entries present. Ross. From rem-conf-request@es.net Wed Jun 12 03:54:29 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jun 1996 00:53:43 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA22437; Wed, 12 Jun 1996 00:53:03 -0700 Date: Wed, 12 Jun 1996 00:53:02 -0700 (PDT) From: Stephen Casner To: Hiroshi Jinzenji Cc: rem-conf@es.net Subject: Re: Propose RSTP & SoftwareVision In-Reply-To: <199606100840.RAA17172@nttvdt.hil.ntt.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I feel RTP main discussion is real-time bi-directional > communication, such as a teleconference, on MBone. Not at all. Most of what is transmitted on the MBone is more like broadcasting than teleconferencing. RTP is not tied to bi-directional communication (though it does make use of bi-directional packet flow for receiver feedback, just as TCP needs bi-directional packet flow for ACKs). > Steve wrote: > Steve > The difficulty is: > Steve > > Steve > 1. getting relay servers situated at each branch point (each router), > Steve > or at least a sufficient number of them to keep the load down; and > > Yes, like a mrouted :-) It is important to recognize the difference between the current experimental deployment of IP multicasting in the MBone, with many of the multicast routers based on workstations and mrouted, and the production deployment of native IP multicast capability in the same high-performance routers that handle unicast routing. The MBone has served an important role to demonstrate the feasibility and value of IP multicasting in the Internet. We are looking forward to the day, not far in the future, I hope, when the MBone as a separate entity fades away IP multicast becomes a part of the basic IP service. A BOF is scheduled for the upcoming IETF meeting to discuss this topic. > Steve > 2. assuming (1) is solved, then finding paths through the servers > Steve > between all desired sources and receivers (i.e. routing). > > I think so. But this subject is very interesting study, I think. > Current servers has a static relay path table file. > But I want to get this subject under control. I don't expect you will find it to be easy. > But IP multicast has a random packet loss problem. If using > congested network, packet loss occur frequently, like a japanese > internet on day time. Compression schemes designed with packet transmission in mind may be more tolerant of packet loss than schemes which were designed for circuits but have been transplanted. Capacity must also grow. Retransmission will eliminate losses but at the cost of delay. If there is insufficient capacity, the delay will grow to infinity. If there is sufficient capacity, loss will not be a problem. > And multicast routing network is a small part > of the Internet, so many Internet user can't receive MBone traffic. I would guess that the "RSTP relay server network" is a much smaller part of the Internet than the MBone is, and that catching up would be difficult. True, from an RSTP server you can serve an end host anywhere, but it is just as true that you could set up a multicast tunnel covering the same path. In both cases, doing so might be a bad idea because it might cause parallel transmission of data across a portion of the path. Ubiquitous deployment of native IP multicast will avoid that. -- Steve From rem-conf-request@es.net Wed Jun 12 08:01:38 1996 Received: from vtt.fi by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jun 1996 05:01:01 -0700 Received: from tte2049.tte.vtt.fi (tte2049.tte.vtt.fi [130.188.12.149]) by vtt.fi (8.6.10/8.6.9) with SMTP id PAA05357; Wed, 12 Jun 1996 15:00:48 +0300 Message-Id: <2.2.32.19960612120249.00ac6ca4@tel1.tte.vtt.fi> X-Sender: lucenius@tel1.tte.vtt.fi X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Jun 1996 15:02:49 +0300 To: debey@deltabeta.com, rem-conf@es.net From: Jan Lucenius Subject: Re: Seeking acronym and term definitions At 13:34 3.6.1996 -0700, Henry C. DeBey wrote: >I am trying to come up to speed with the issues discussed in this >mailing list. Can someone point me toward definitions for some of the >terms and acronyms used here. Same for me! > From rem-conf-request@es.net Wed Jun 12 08:45:08 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jun 1996 05:44:38 -0700 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Wed, 12 Jun 1996 14:42:41 +0200 X-Mailer: exmh version 1.6.7 5/3/96 To: Jan Lucenius cc: debey@deltabeta.com, rem-conf@es.net From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: Seeking acronym and term definitions In-reply-to: Your message of "Wed, 12 Jun 1996 15:02:49 +0300." <2.2.32.19960612120249.00ac6ca4@tel1.tte.vtt.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Jun 1996 14:42:33 +0200 Sender: schulzrinne@fokus.gmd.de You might find the RTP home page (http://www.fokus.gmd.de/step/rtp) helpful, as well as the glossary in the "Issues" expired Internet draft listed on those pages. The latter is getting somewhat stale, but the glossary should still be correct. (If not, I'd like to know about it...) Henning From rem-conf-request@es.net Wed Jun 12 08:55:31 1996 Received: from ruin.informatik.uni-bremen.de by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jun 1996 05:54:27 -0700 Original-Received: by ruin.informatik.uni-bremen.de (8.6.10/20.9.94cl) id OAA28826 Wed, 12 Jun 1996 14:54:16 +0200 PP-warning: Illegal Received field on preceding line Date: Wed, 12 Jun 1996 14:54:16 +0200 Message-Id: <199606121254.OAA28826@ruin.informatik.uni-bremen.de> From: Carsten Bormann To: Jan Lucenius Cc: debey@deltabeta.com, rem-conf@es.net Subject: Re: Seeking acronym and term definitions In-Reply-To: <2.2.32.19960612120249.00ac6ca4@tel1.tte.vtt.fi> References: <2.2.32.19960612120249.00ac6ca4@tel1.tte.vtt.fi> I'd suggest draft-ietf-mmusic-confarch-00.ps as a possible overview, e.g. from ftp://nic.nordu.net/internet-drafts or one of the other internet drafts directories. Gruesse, Carsten From rem-conf-request@es.net Wed Jun 12 09:43:44 1996 Received: from lhc.nlm.nih.gov by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jun 1996 06:42:54 -0700 Received: from billings.nlm.nih.gov by lhc.nlm.nih.gov (4.1/SMI-4.0) id AA18444; Wed, 12 Jun 96 09:42:50 EDT Received: by billings.nlm.nih.gov (5.x/SMI-SVR4) id AA22974; Wed, 12 Jun 1996 09:45:42 -0400 Date: Wed, 12 Jun 1996 09:45:42 -0400 From: rodgers@nlm.nih.gov (R. P. C. Rodgers, M.D.) Message-Id: <9606121345.AA22974@billings.nlm.nih.gov> To: debey@deltabeta.com, rem-conf@es.net, jan.lucenius@vtt.fi Subject: Re: Seeking acronym and term definitions X-Sun-Charset: US-ASCII The lingo can indeed be daunting! I'm full of sympathy, also trying to track developments in this fast-moving scene. I have been trying to gather together terminology and pointers to didactic material in the course materials I use for various presentations on Internet, WW, and multicasting, which you can find by connecting to our principal Web serve, HyperDOC, at: http://www.nlm.nih.gov and then navigating through "NLM Publications," "NLM PUblished Reports...," and finally "NLM Medical Informatics Mini-Course -- The Internet." There you can browse the multicasting/teleconferencing items. I'm always on the lookout for technically solid new materials, so let me know if you come across any. Good luck! Cheerio, Rick Rodgers > From rem-conf-request@es.net Wed Jun 12 08:36 EDT 1996 > X-Sender: lucenius@tel1.tte.vtt.fi > X-Mailer: Windows Eudora Pro Version 2.2 (32) > Mime-Version: 1.0 > Date: Wed, 12 Jun 1996 15:02:49 +0300 > To: debey@deltabeta.com, rem-conf@es.net > From: Jan Lucenius > Subject: Re: Seeking acronym and term definitions > > At 13:34 3.6.1996 -0700, Henry C. DeBey wrote: > >I am trying to come up to speed with the issues discussed in this > >mailing list. Can someone point me toward definitions for some of the > >terms and acronyms used here. > > Same for me! > > > > From rem-conf-request@es.net Wed Jun 12 11:55:29 1996 Received: from cancer.ucs.ed.ac.uk (actually 129.215.16.3) by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jun 1996 08:54:44 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with SMTP id QAA07065; Wed, 12 Jun 1996 16:54:10 +0100 Date: Wed, 12 Jun 1996 16:54:09 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Jan Lucenius cc: debey@deltabeta.com, rem-conf@es.net Subject: Re: Seeking acronym and term definitions In-Reply-To: <2.2.32.19960612120249.00ac6ca4@tel1.tte.vtt.fi> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 12 Jun 1996, Jan Lucenius wrote: > At 13:34 3.6.1996 -0700, Henry C. DeBey wrote: > >I am trying to come up to speed with the issues discussed in this > >mailing list. Can someone point me toward definitions for some of the > >terms and acronyms used here. > > Same for me! You could look at http://mice.ed.ac.uk/mice/glossary/glossary.shtml. It is something I started working on recently and it is far from complete and a number of the entries have not yet been filled in. I am sure there are probably some errors too. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Wed Jun 12 14:43:17 1996 Received: from relay.hp.com by osi-west.es.net with ESnet SMTP (PP); Wed, 12 Jun 1996 11:42:13 -0700 Received: from it_750.ch.apollo.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA057004925; Wed, 12 Jun 1996 11:42:06 -0700 Received: from tisbury.ch.apollo.hp.com by it_750.ch.apollo.hp.com id AA171834924; Wed, 12 Jun 1996 14:42:04 -0400 Message-Id: <2.2.32.19960612184147.0071953c@pop-e3.ch.apollo.hp.com> X-Sender: brezak@pop-e3.ch.apollo.hp.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 12 Jun 1996 14:41:47 -0400 To: "Carl Malamud [IMS]" From: John Brezak Subject: Re: Vat-Vic for Windows 95 Cc: van@ee.lbl.gov (Van Jacobson), ganzer@nosc.mil, clesigne@ifhamy.insa-lyon.fr, rem-conf@es.net At 06:29 PM 6/11/96 -0400, Carl Malamud [IMS] wrote: >Van - > >Win95 plays very bad games with the routing tables. What probably >happened is that it was directing multicast traffic out your >dialup interface, even if you weren't using it. This happened to me also. I got around this by not specifying the IP address for the dialup port. Instead I let PPP tell me. I left the IP address there for my Lan card (Xircom). Add this to the Win95 "book of spells" ... > >For folks who use dialup, you might try Net Switch at: > > http://www.winsite.com/info/pc/win95/netutil/netsw190.zip/ > >Allows you to save various configurations in a file and switch >them without (usually) rebooting. Good way to flip between different >network providers and to zap away the extra routes. > >Carl > >According to Van Jacobson: >> >> Mark, >> >> Your laptop sounds identical to mine (w95 + service pack 1 & 3c589 >> pcmcia card). We couldn't receive multicast (sending worked fine) >> then I saw a note on one of the usenet comp.sys.win groups about >> problems with MS dial-up networking & removed it (we never used >> it -- it was only there because it's installed by default). Ethernet >> multicast reception immediately started working. Since then about >> half a dozen people have reported the same problem as Christophe, >> we've suggested this fix & it has worked. Perhaps the difference >> with your machine is that you actually use the dial-up networking -- >> maybe configuring it resets whatever causes it to eat multicast. >> I admit we didn't try to circumscribe the bug -- there are so many >> win95 bugs that we're happy to just find a usable path through the >> minefield & never try to map every charge. >> >> - Van >> > > From rem-conf-request@es.net Thu Jun 13 03:33:22 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 00:32:41 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA29680; Thu, 13 Jun 1996 00:32:38 -0700 Date: Thu, 13 Jun 1996 00:32:37 -0700 (PDT) From: Stephen Casner To: Allison Mankin Cc: rem-conf@es.net, confctrl@ISI.EDU Subject: Re: Second slot scheduled for AVT In-Reply-To: <199605312038.AA00579@metro.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII AVT Working Group: I'm assembling the agenda for our sessions on June 25 at the upcoming IETF in Montreal. As Allison's message informed us, we have two sessions back-to-back, 13:00 and 15:30. The biggest topic for this meeting will be RTP header compression. I expect the bulk of the first session to be occupied by presentations and discussion on this topic. In the second session, there are several additional topics scheduled: - RTP/SRM: extensions to RTP for variable reliability - Payload formats for redundant encodings - SISP: signalling protocol, nudged here from MMUSIC because their session filled up and because it's RTCP-based - What's needed to progress RTP to Draft Standard - GSMVQ low-rate audio encoding Possible additional topics: - Payload formats for H.263 and G.723 - RTP profile for professional audio and video - Payload format for Microsoft ASF It doesn't look like we'll have any trouble filling the two slots. If anyone has other topics they would like to present, please contact me. -- Steve From rem-conf-request@es.net Thu Jun 13 03:53:18 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 00:52:39 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA29776; Thu, 13 Jun 1996 00:52:29 -0700 Date: Thu, 13 Jun 1996 00:52:28 -0700 (PDT) From: Stephen Casner To: Mikael Degermark Cc: rem-conf@es.net Subject: Re: Compression of RTP/UDP/IP In-Reply-To: <199606111803.UAA03479@my8.sm.luth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mikael, Thanks for your comments. > 2. Multihop radio-based networks such as Metricom > will reorder packets when they are routed around > congestion points. On such links it will not be sufficient > with three bits of sequence number as suggested by Casner and > Jacobson. Is it really a good idea to have a compression > mechanism that excludes such links? Such links can have fairly > low bandwidth, and it seems to me that radio will be a very > common way to access the Internet... Would it be feasible to perform the compression on a hop-by-hop basis? Is the delay over multiple hops going to be long enough that it is a problem anyway? > 3. Wouldn't it be better to use the Length field of the UDP and/or > IP header to transfer the session context (C) in full headers? > The link-layer must provide the length of the frame to allow > decompression, so the length fields are available. I suppose so. > Using the Protocol field makes it impossible to compress headers other > than the simplest possible IPv4/UDP/RTP headers. You mean because using the protocol field makes the selection of UDP implicit, and otherwise other protocols could be indicated? If not, I am not sure what you mean. > 4. There does not seem to be any methods for compressing tunneled > packets, i.e., packets with multiple IP headers. Such packets > occur for example when Mobile IP is used. Since the headers > are even bigger then, shouldn't such packets be compressed too? This seems like a reasonable idea, but how many encapsulations or other combinations should we allow for? Note that there aren't a whole lot of bits to play with. > 5. Finally, although I personally think that using authentication on > *every* packet is a bad idea on low-speed links since the hash > uses so many bytes, I can see the need to authenticate or encrypt > over radio links. Shouldn't we make it possible to compress even > when the ipsec stuff is being used? Encryption is designed to obliterate redundancy, so it's a pretty solid conflict with compression. You might encrypt after compression, but then the intermediate nodes need to be involved. Or, you might encrypt only the data through the use of "encrypted payload types" as discussed in the RTP spec. -- Steve From rem-conf-request@es.net Thu Jun 13 07:47:53 1996 Received: from my28.sm.luth.se by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 04:46:38 -0700 Received: from my8.sm.luth.se (my8.sm.luth.se [130.240.3.38]) by my28.sm.luth.se (8.7.5/8.7.2) with ESMTP id NAA27836; Thu, 13 Jun 1996 13:45:59 +0200 Received: from localhost (micke@localhost) by my8.sm.luth.se (8.6.11/8.6.11) with SMTP id NAA23702; Thu, 13 Jun 1996 13:49:17 +0200 Message-Id: <199606131149.NAA23702@my8.sm.luth.se> X-Mailer: exmh version 1.6.6 3/24/96 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Stephen Casner Cc: rem-conf@es.net Subject: Re: Compression of RTP/UDP/IP In-reply-to: Your message of Thu, 13 Jun 1996 00:52:28 PDT. Date: Thu, 13 Jun 1996 13:49:16 +0200 From: Mikael Degermark Hi Steve, > 2. Multihop radio-based networks such as Metricom > will reorder packets when they are routed around > congestion points. On such links it will not be sufficient > with three bits of sequence number as suggested by Casner and > Jacobson. Is it really a good idea to have a compression > mechanism that excludes such links? Such links can have fairly > low bandwidth, and it seems to me that radio will be a very > common way to access the Internet... Would it be feasible to perform the compression on a hop-by-hop basis? These kinds of networks tend to have fairly simple base-stations, and lots of them so they have to be cheap. I think it will be hard to convince people to put more hardware in them in order to deal with reordering. It's not like each hop is an IP router, they are much simpler. Is the delay over multiple hops going to be long enough that it is a problem anyway? I'm not sure I see what you are getting at here, you seem to ask whether it is worth bothering with these links if they have high delays anyway. I *think* the delay is usually reasonable, but that it sometimes can be as high as a second. > Using the Protocol field makes it impossible to compress headers other > than the simplest possible IPv4/UDP/RTP headers. You mean because using the protocol field makes the selection of UDP implicit, and otherwise other protocols could be indicated? Yes. > 4. There does not seem to be any methods for compressing tunneled > packets, i.e., packets with multiple IP headers. Such packets > occur for example when Mobile IP is used. Since the headers > are even bigger then, shouldn't such packets be compressed too? This seems like a reasonable idea, but how many encapsulations or other combinations should we allow for? Note that there aren't a whole lot of bits to play with. You do not need any bits in the compressed header to do this kind of compression. What subheaders are present is clear from the stored header used for decompression. If you don't use differential coding of the encapsulating headers, the size of the compressed header is the same. The Identification field in encapsulating IPv4 headers can be sent "as-is" without differential encoding. As you have observed, the problem is to select what encapsulations to compress. For the above to work without extra bits in compressed headers, compressor and decompressor must agree on what subheaders are compressed. This must be specified. For IPv4 I think it is reasonable to compress basic IPv4 headers only, or possibly the minimal encoding of the IPv4 header too (there is an rfc on that, can't remember the number just now...). These are the ones that are most likely to be used for mobility purposes. Encryption is designed to obliterate redundancy, so it's a pretty solid conflict with compression. You might encrypt after compression, but then the intermediate nodes need to be involved. Or, you might encrypt only the data through the use of "encrypted payload types" as discussed in the RTP spec. The conflict is not necessarily there. Encryption does not necessarily increase the size of the data so it makes sense to have as little data as possible before encrypting. Routers must see the IP header in order to be able to forward the packet. So at least that part will be visible and can be compressed hop-by-hop. I can imagine that someone might want to encrypt the UDP/RTP/data part of a packet end-to-end and add a visible IP header for routing. In this case it would make sense to compress the UDP/RTP header before encryption and treat the encrypted tunnel as a link over which there can be reordering. The new draft on IPv6 header compression has mechanisms that allow you to do all this except for compression of the RTP header. It would be great to have a such a mechanism there too. I look forward to reading your coming draft! See ftp://cdt.luth.se/micke/draft-degermark-ipv6-hc-01.txt Mikael Degermark From rem-conf-request@es.net Thu Jun 13 10:25:46 1996 Received: from tis-mail.thepoint.net (actually tis-backup.thepoint.net) by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 07:25:11 -0700 Received: by tis-mail.thepoint.net with Microsoft Exchange (IMC 4.0.837.3) id <01BB5909.6710E9C0@tis-mail.thepoint.net>; Thu, 13 Jun 1996 09:19:20 -0400 Message-ID: From: Arlie Davis To: 'Stephen Casner' Cc: "'rem-conf@es.net'" , Michael Jung Subject: RE: Compression of RTP/UDP/IP Date: Thu, 13 Jun 1996 09:19:18 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm beginning to think that hop-by-hop compression, for any scheme (unicast, multicast, etc.) is a bad idea. It's crazy to require every router or relay agent in the middle of a traffic path to decompress and then recompress data. De/compression is processor and memory intensive, and if it is going to be "required" then it is going to make multicast deployment much more expensive and painful. End-to-end compression seems much better; only two machines do any compression work at all. Also, the intermediate nodes don't know (or care) if the end-nodes are doing compression. Of course, there are several kinds of compression. Generic payload compression, in which the intermediate nodes have no knowledge of the contents of the data being compressed, is the most difficult to compress. Header compression, in which the intermediate nodes do have some idea of the contents and can make certain informed assumptions about the contents of the data, is much more realistic. I don't think generic payload compression belongs in the routers at all. There is nothing that a router can do in this respect that an end-node could not, and indeed, should not be doing. Blessing a certain set of compression algorithms and then requiring that they be implemented in routers is harmful. It will require routers to have much faster processors (or even dedicated compression processors) and much more memory. Compress it once on the transmitting end-node, decompress it once on the receiving end-node. Header compression, or any kind of compression in which the machine has some knowledge of the contents of the data, seems a likely candidate for compression. However, I think this should be viewed with some skepticism. We all know, love, and use VJ TCP header compression on slow serial links. This works because the link is typically used for a single (or very few) TCP sessions at once, and when the link is used, it is important that the overhead be as low as possible. Something similar for UDP/IP is probably realistic, easy to implement, and would require very little memory or processor. Just noticing that the source and destination address (and other UDP/IP header fields) are the same on hundreds of consecutive packets would allow the router to drop perhaps 16 - 20 bytes per packet, which is significant. This would be a Good Thing. I think it was never implemented before because the majority of traffic over slow links was TCP/IP, and now there are some UDP/IP applications that people want to use over slow links. However, that said, I would shy away from implementing the same scheme for the RTP headers on routers. Why? Because the applications (i.e. end-nodes) can do a much better job of optimizing exactly what needs to be transmitted and what does not. Trying to make up for verbose packets in intermediate nodes is a band-aid fix; it is not well-designed. RTP's payload is (usually) already compressed, based on whatever video or audio codec is driving the data stream. (I doubt any router would be able to compress H.261 or GSM data any more than the app could.) That leaves only the RTP header. If the header is too long, too verbose, then it should be made shorter and terser by the part of the system which has the greatest opportunity to do so -- the transmitting end-node. RTP's spec should be modified. A version of RTP could be designed specifically for low-bandwidth media streams, or RTP itself could be made to be less verbose. For low-bandwidth, the timestamp field could be shortened to two octets and the SSID could be dropped or made optional, etc. -- arlie >---------- >From: Stephen Casner[SMTP:casner@precept.com] >Sent: Thursday, June 13, 1996 3:52 AM >To: Mikael Degermark >Cc: rem-conf@es.net >Subject: Re: Compression of RTP/UDP/IP > >Mikael, > >Thanks for your comments. > >> 2. Multihop radio-based networks such as Metricom >> will reorder packets when they are routed around >> congestion points. On such links it will not be sufficient >> with three bits of sequence number as suggested by Casner and >> Jacobson. Is it really a good idea to have a compression >> mechanism that excludes such links? Such links can have fairly >> low bandwidth, and it seems to me that radio will be a very >> common way to access the Internet... > >Would it be feasible to perform the compression on a hop-by-hop basis? >Is the delay over multiple hops going to be long enough that it is a >problem anyway? > >> 3. Wouldn't it be better to use the Length field of the UDP and/or >> IP header to transfer the session context (C) in full headers? >> The link-layer must provide the length of the frame to allow >> decompression, so the length fields are available. > >I suppose so. > >> Using the Protocol field makes it impossible to compress headers other >> than the simplest possible IPv4/UDP/RTP headers. > >You mean because using the protocol field makes the selection of UDP >implicit, and otherwise other protocols could be indicated? If not, I >am not sure what you mean. > >> 4. There does not seem to be any methods for compressing tunneled >> packets, i.e., packets with multiple IP headers. Such packets >> occur for example when Mobile IP is used. Since the headers >> are even bigger then, shouldn't such packets be compressed too? > >This seems like a reasonable idea, but how many encapsulations or >other combinations should we allow for? Note that there aren't a >whole lot of bits to play with. > >> 5. Finally, although I personally think that using authentication on >> *every* packet is a bad idea on low-speed links since the hash >> uses so many bytes, I can see the need to authenticate or encrypt >> over radio links. Shouldn't we make it possible to compress even >> when the ipsec stuff is being used? > >Encryption is designed to obliterate redundancy, so it's a pretty >solid conflict with compression. You might encrypt after compression, >but then the intermediate nodes need to be involved. Or, you might >encrypt only the data through the use of "encrypted payload types" as >discussed in the RTP spec. > -- Steve > > From rem-conf-request@es.net Thu Jun 13 14:13:25 1996 Received: from cyclops.ece.ncsu.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 11:12:50 -0700 Received: by cyclops.ece.ncsu.edu (8.6.9/EC06jan95) id OAA07105; Thu, 13 Jun 1996 14:12:45 -0400 From: Kathy Lynn Hewitt Message-Id: <9606131412.ZM7103@eos.ncsu.edu> Date: Thu, 13 Jun 1996 14:12:44 -0400 In-Reply-To: aspecker@hydra.informatik.uni-ulm.de (Alexander Specker) "recording video/audio" (Jun 13, 12:12pm) References: <199606131012.MAA02036@octavian.informatik.uni-ulm.de> X-Mailer: Z-Mail (3.2.1 10oct95) To: rem-conf@es.net Subject: VIC and DEC Alpha Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi! I've been asked to find out the proper hardware necessary to outfit a DEC Alpha to use the mbone tools. All the tools have been set up and run fine. We would like to now be able to transmit video from it. I've seen reports of compatibility problems with boards in the past with the tools on different architectures... so I thought somebody on this list might be able to suggest some equipment for it. I appreciate any and all help I can get!! Thank you, Kathy Hewitt klhewitt@eos.ncsu.edu From rem-conf-request@es.net Thu Jun 13 15:39:01 1996 Received: from mail2.digital.com by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 12:38:24 -0700 Received: from acetes.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA02046; Thu, 13 Jun 1996 12:33:46 -0700 Received: by acetes.pa.dec.com; id AA17762; Thu, 13 Jun 96 12:33:46 -0700 Date: Thu, 13 Jun 96 12:33:46 -0700 From: templin@pa.dec.com (Fred Templin) Message-Id: <9606131933.AA17762@acetes.pa.dec.com> To: rem-conf@es.net Subject: Re: Compression of RTP/UDP/IP Cc: templin@pa.dec.com > From: Arlie Davis > To: 'Stephen Casner' > Cc: "'rem-conf@es.net'" , Michael Jung > Subject: RE: Compression of RTP/UDP/IP > Date: Thu, 13 Jun 1996 09:19:18 -0400 > X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > Status: RO > > > > We all know, love, and use VJ TCP header compression on slow serial > links. This works because the link is typically used for a single (or > very few) TCP sessions at once, and when the link is used, it is > important that the overhead be as low as possible. Something similar > for UDP/IP is probably realistic, easy to implement, and would require > very little memory or processor. Just noticing that the source and > destination address (and other UDP/IP header fields) are the same on > hundreds of consecutive packets would allow the router to drop perhaps > 16 - 20 bytes per packet, which is significant. This would be a Good > Thing. I think it was never implemented before because the majority of > traffic over slow links was TCP/IP, and now there are some UDP/IP > applications that people want to use over slow links. I've been following this thread and had some observations which I'm hoping might be helpful. Another reason that TCP is a good candidate for header compression is that TCP traffic consists of a continuous stream(s) of packets having a significant portion of their inter-packet header fields invariant (i.e. a "session"). This makes it feasible for compression/decompression engines on either end of a slow link to cache TCP/IP headers in a state table and expect a reasonably high percentage of cache hits. Conversely, UDP traffic has traditionally not shown the same sort of inter-packet continuity (or, "session-orientedness") of TCP, which would render such caches uselss and yeild no gains from following a co/dec discipline. But, with the advent of "streaming" UDP applications such as realtime A/V, it might be reasonable to conclude that there are now two distinct classes of UDP packets on the Internet - traditional request/response, standalone UDP packets which don't lend themselves well to header compression, and session-oriented UDP packets which do. Running a header compression algorithm for the former class of packets would simply thrash the caches at either end of the link and yeild no compression benefits, whereas header compression for session-oriented UDP packets would give significant compression payoffs given reasonable longevity for the sessions. One method for detecting session-oriented UDP packets would be to peer into the data region and detect whether the packets "smell like" RTP, as Casner and Jacobsen have proposed. But, an alternative would be to define a new IP protocol type (IPPROTO_UDPSTREAM??) which would serve as an indication to a slow-link compression engine that certain UDP packets are session-oriented (and thus good candidates for header compression) whereas others are not. This would provide significant payoff for link-level UDP/IP header compression while allowing applications to do end-to-end RTP header compression if they so desired. Additionally, it would allow UDP/IP header compression benefits for session- oriented UDP packet streams other than just RTP. The obvious drawback is that defining a new IP protocol type touches all end-node implementations which run streaming-UDP applications (such as RTP). But, I think the same is true for end-to-end RTP header compression... Regards, Fred templin@pa.dec.com From rem-conf-request@es.net Thu Jun 13 15:42:41 1996 Received: from my28.sm.luth.se by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 12:41:22 -0700 Received: from my8.sm.luth.se (my8.sm.luth.se [130.240.3.38]) by my28.sm.luth.se (8.7.5/8.7.2) with ESMTP id VAA07302; Thu, 13 Jun 1996 21:40:36 +0200 Received: from localhost (micke@localhost) by my8.sm.luth.se (8.6.11/8.6.11) with SMTP id VAA27811; Thu, 13 Jun 1996 21:43:55 +0200 Message-Id: <199606131943.VAA27811@my8.sm.luth.se> X-Mailer: exmh version 1.6.6 3/24/96 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: ipng@sunroof.eng.sun.com, rem-conf@es.net Subject: IPv6 Header Compression Date: Thu, 13 Jun 1996 21:43:54 +0200 From: Mikael Degermark We have a new i-d on IPv6 header compression. It will appear before the IETF. Meanwhile you can fetch it at ftp://cdt.luth.se/micke/draft-degermark-ipv6-hc-01.txt Abstract This document describes how to compress IPv6 headers over point-to- point links. The method can be applied to IPv6 base and extension headers, IPv4 headers, TCP and UDP headers, and encapsulated IPv6 and IPv4 headers. A typical IPv6/UDP header can be compressed down to 4 octets including the UDP checksum. A typical IPv6/TCP header can be compressed down to 4-6 octets including the TCP checksum. Important changes from the previous version are * link-layer is required to indicate type of compressed headers. This saves a lot of real-estate in the new compressed header formats. * new mechanisms for dealing with links that reorder. These mechanisms also solve a problem caused by the TCP window scale option pointed out by Craig Partridge at the LA IETF * mechanisms for quick repair of the compression state after loss. This can improve TCP performance by up to 30 per cent when header compression is used over lossy links such as wireless. * revised section on grouping of packets into packet streams. We would like to hear any comments you might have... Micke From rem-conf-request@es.net Thu Jun 13 16:33:28 1996 Received: from my28.sm.luth.se by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 13:32:16 -0700 Received: from my8.sm.luth.se (my8.sm.luth.se [130.240.3.38]) by my28.sm.luth.se (8.7.5/8.7.2) with ESMTP id WAA08354; Thu, 13 Jun 1996 22:31:44 +0200 Received: from localhost (micke@localhost) by my8.sm.luth.se (8.6.11/8.6.11) with SMTP id WAA28282; Thu, 13 Jun 1996 22:35:03 +0200 Message-Id: <199606132035.WAA28282@my8.sm.luth.se> X-Mailer: exmh version 1.6.6 3/24/96 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Arlie Davis Cc: rem-conf@es.net Subject: Re: Compression of RTP/UDP/IP In-reply-to: Your message of Thu, 13 Jun 1996 09:19:18 EDT. Date: Thu, 13 Jun 1996 22:35:02 +0200 From: Mikael Degermark Hello Arlie, I read your mail and answered at the same time. My important objections are near the bottom. > I'm beginning to think that hop-by-hop compression, for any scheme > (unicast, multicast, etc.) is a bad idea. It's crazy to require every > router or relay agent in the middle of a traffic path to decompress and > then recompress data. De/compression is processor and memory intensive, > and if it is going to be "required" then it is going to make multicast > deployment much more expensive and painful. End-to-end compression > seems much better; only two machines do any compression work at all. > Also, the intermediate nodes don't know (or care) if the end-nodes are > doing compression. I disagree. First, with header compression you pay with memory and processing time to reduce transmission time and bandwith requirements. Over fast links in the "center" of the internet, this is a bad deal as there is lots of bandwidth and the transmission time is negligible. Second, with end-to-end header compression the IP header cannot be compressed because it is needed for routing. However, on a slow-speed link it is not acceptable to have 20 bytes (IPv4) or 40 bytes (IPv6) extra on each header. Hmmm, now that I read the above I begin to suspect that you are under the impression that header compression is required to be done on every hop. This is of course a terrible idea. Header compression should only be done where it is needed. What should be required is that all IPv6 implementations should be *able* to do header compression. Good header compression. > I don't think generic payload compression belongs in the routers at all. > There is nothing that a router can do in this respect that an end-node > could not, and indeed, should not be doing. Blessing a certain set of > compression algorithms and then requiring that they be implemented in > routers is harmful. It will require routers to have much faster > processors (or even dedicated compression processors) and much more > memory. Compress it once on the transmitting end-node, decompress it > once on the receiving end-node. I can imagine that a company that is spread out around the world would like to configure compressed (and encrypted) tunnels between its offices. Such compression and encryption is likely to be done in routers. > We all know, love, and use VJ TCP header compression on slow serial > links. Yes, and I predict that header compression will be used also over medium-speed wireless links because reducing the number of bits per packet gives a lower packet-loss rate. Both TCP and UDP will benefit >from this. TCP in particular as a reduced packet loss rate means that the congestion control mechanisms of TCP is triggered to a lesser degree, and TCP throughput will improve. > However, that said, I would shy away from implementing the same scheme > for the RTP headers on routers. Why? Because the applications (i.e. > end-nodes) can do a much better job of optimizing exactly what needs to > be transmitted and what does not. Trying to make up for verbose packets > in intermediate nodes is a band-aid fix; it is not well-designed. The problem with end-to-end header compression is that you need to deal with reordering. This will cost you some bytes in the compressed headers. On a severly bandwith-limited link, that is not something you want to do. > RTP's payload is (usually) already compressed, based on whatever video > or audio codec is driving the data stream. (I doubt any router would be > able to compress H.261 or GSM data any more than the app could.) That > leaves only the RTP header. If the header is too long, too verbose, > then it should be made shorter and terser by the part of the system > which has the greatest opportunity to do so -- the transmitting > end-node. Yes, except for reordering. There is a strong case to be made for per-hop header compression, because on most links there is no reordering. And, more important, the outermost IP header cannot be compressed end-to-end. > RTP's spec should be modified. A version of RTP could be designed > specifically for low-bandwidth media streams, or RTP itself could be > made to be less verbose. For low-bandwidth, the timestamp field could > be shortened to two octets and the SSID could be dropped or made > optional, etc. I agree that as a short-term solution, a way to compress the RTP header end-to-end is justified. However, we should consider the reordering problem when doing so. Differential coding is broken when compressed headers are reordered. If the resulting glitches are acceptable, all is well. If not, end-to-end compression of RTP header cannot (as far as I know) be as efficient as per-link header compression. > -- arlie Micke From rem-conf-request@es.net Thu Jun 13 16:43:18 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 13:42:03 -0700 Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.7.4/8.7.3) with SMTP id NAA12300; Thu, 13 Jun 1996 13:41:57 -0700 (PDT) Received: from hot-rtp by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0uUJEv-000RVdC; Thu, 13 Jun 96 13:43 PDT Message-ID: <31C07D11.24A6@ibeam.intel.com> Date: Thu, 13 Jun 1996 13:41:53 -0700 From: Chunrong Zhu Organization: Intel Corp. X-Mailer: Mozilla 2.0 (WinNT; I) MIME-Version: 1.0 To: internet-drafts@cnri.reston.va.us CC: rem-conf@es.net, Chunrong Zhu , mojy@ibeam.jf.intel.com Subject: RTP payload format for H.263, revised draft Content-Type: multipart/mixed; boundary="------------18CF4E6054B1" This is a multi-part message in MIME format. --------------18CF4E6054B1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Colleagues, Attached, please find the revised draft on H.263 payload format for RTP. Previous draft is named draft-ietf-avt-rtp-payload-00.txt. This version incorporated comments from my colleagues at Intel as well as others from AVT. If you have any questions or comments, feel free to send me email at: czhu@ibeam.intel.com Best regards. --Chad --------------18CF4E6054B1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Rtp263id.txt" Internet Engineering Task Force Audio-Video Transport WG INTERNET-DRAFT C. Zhu Intel Corp. June 10, 1996 Expires: 12/10/96 RTP Payload Format for H.263 Video Stream Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of 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 "lid-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 Cost). 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). The H.263 payload header is designed for flexibility and simplicity. RTP can use one of three possible modes for H.263 video streams depending on the desired performance characteristics. The shortest header mode (Mode A) results in simplicity and easy recovery from lost packets, brought about by fragmentation at Group of Block (GOB) boundaries. The long header modes (Mode B and C) result in more efficient use of bandwidth, brought about by fragmentation at Macroblock (MB) boundaries. Zhu [Page 1] Internet Draft RTP Payload for H.263 June 10, 1996 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 288 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=3 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 RTP Payload for H.263 June 10, 1996 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 effect 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. Unrestricted motion vector feature does not effect packetization directly. No special treatment is needed. 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 all QCIF, and three half rows of MB for CIF format. Like H.261, a GOB is divided into macroblocks. 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. 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. Zhu [Page 3] Internet Draft RTP Payload for H.263 June 10, 1996 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 are from the previous GOB. To decode the whole inter-coded GOB, all the motion vectors must be available from the previous GOB. This can be a major problem for a packetization scheme like the one defined for H.261 when packetizing at MB boundaries. 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 would have to be saved at the beginning of the packet. This would be very expensive in terms of bandwidth. We address these problems by recommending the use of the GOB header for every GOB at the beginning of a packet. In addition, treating the GOB boundary as the picture boundary during the encoding will further improve the visual quality in the presence of packet loss. Several simulations during ITU meetings on H.324 Mobile have also demonstrated its effectiveness and desirability. 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. 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. 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. 4. Usage of RTP When transmitting H.263 video streams over the internet, we will directly packetize the output of the encoder. 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 we do not intend to multiplex audio and video signals in the same packets, as UDP and RTP provide a much more efficient way to achieve multiplexing. Zhu [Page 4] Internet Draft RTP Payload for H.263 June 10, 1996 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 7, 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. 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: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Zhu [Page 5] Internet Draft RTP Payload for H.263 June 10, 1996 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 bytes header is provided to support fragmentation at MB boundaries for frames that are coded with the PB frame option on. The mode is indicated by the F field and P field in the first two bits of the header. The three modes can be intermixed for one compressed frame. All the 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 left 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 | R |I|A|S|DBQ| TRB | TR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 bit position specifies number of bits that should be ignored in the first data byte. Zhu [Page 6] Internet Draft RTP Payload for H.263 June 10, 1996 EBIT: 3 bits End bit position indicates 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]. R: 5 bits Reserved, must be 0. I: 1 bit. Set to 1 if current picture is intra-coded. Otherwise 0. Notice this is opposite to the picture coding type in PTYPE as defined within the H.263 bitstream [4]. A: 1 bit Optional Advanced Prediction mode as defined by H.263 [4]. "0" implies off, "1", implies on. S: 1 bit Optional Syntax-based Arithmetic Code mode as defined by the H.263 [4]. 0" off, "1" on. DBQ: 2 bits Differential quantization parameter 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 0 if PB frame option is off. 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 (such as IP). 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: Zhu [Page 7] Internet Draft RTP Payload for H.263 June 10, 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | QUANT |I|A|S| GOBN | MBA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in Mode A: F, P, SBIT, EBIT, SRC, I, A, S. The new 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: 8 bits The absolute address of the first MB within its GOB. Unlike in H.261, MB address is not coded explicitly in the bitstream. Instead, MB position is decided relative to its immediate previous MB. In order to continue decoding in the presence of loss of the previous packet, the absolute address of the first MB within its GOB in the packet is coded in the header. HMV1, VMV1, 8 bits each. Horizontal and vertical motion vector predictors for the first MB coded in this packet from the MB on the left. The same as MV1 defined by H.263 [4]. We strongly recommend using a GOB header for every GOB as explained in section 3.3. HMV2, VMV2, 8 bits each. Horizontal and vertical motion vector predictors from the block or MB on the left of block number 3 in the current MB when advanced prediction option is on. They are the same as MV1 defined for block number 3 in H.263 [4]. This is needed because block number 3 in the first MB needs the motion vector predictor >from the block to its left, as block number 1. These two fields are not used when advanced prediction is off and must be set to 0. See the H.263 [4] for block organization in a frame. 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 (such as IP). H.263 payload header definition for Mode C is shown as follows with F=1 and P=1: Zhu [Page 8] Internet Draft RTP Payload for H.263 June 10, 1996 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|P|SBIT |EBIT | SRC | QUANT |I|A|S| GOBN | MBA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMV1 | VMV1 | HMV2 | VMV2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R |DBQ| TRB | TR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following fields are defined the same as in Mode A: F, P, SBIT, EBIT, SRC, I, A, S, TR, DBQ, TRB, and the rest of the fields are defined the same as in Mode B, except field R of 19 bits is reserved and must be set to 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. 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. 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 is recommended for GOBs whose size is smaller than the network packet size. The major disadvantage of Mode A is lack of flexibility in packetization and that it does not work 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, 1996. Zhu [Page 9] Internet Draft RTP Payload for H.263 June 10, 1996 [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, 1995. [4] Video Coding for Low Bitrate Communication, ITU-T Recommendation H.263, 1995 [5] T. Turletti, C. Huitema, RTP Payload Format for H.261 Video Stream. 1995. 7. Author's Address Chunrong "Chad" Zhu Mail Stop: JF2-78 Intel Architecture Lab Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Tel: (503) 264-8849 Fax: (503) 264-6067 Email: czhu@ibeam.intel.com 8. Table of Contents 1. Introduction.........................................2 2. Definitions..........................................2 3. Design Issues for Packetizing H.263 Bitstream........2 3.1 Optional Features of H.263...........................3 3.2 GOB Numbering........................................3 3.3 Motion Vectors Encoding..............................4 3.4 Macroblock Address...................................4 4. USAGE OF RTP.........................................4 4.1 RTP Header usage.....................................5 4.2 Video Packet Structure...............................5 5. H.263 Payload Header.................................6 5.1 Mode A...............................................6 5.2 Mode B...............................................7 5.3 Mode C...............................................8 5.4 Selection of Modes for H.263 Payload Header..........9 6. References...........................................9 7. Author's Address....................................10 Zhu [Page 10] --------------18CF4E6054B1-- From rem-conf-request@es.net Thu Jun 13 17:12:30 1996 Received: from my28.sm.luth.se by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 14:11:46 -0700 Received: from my8.sm.luth.se (my8.sm.luth.se [130.240.3.38]) by my28.sm.luth.se (8.7.5/8.7.2) with ESMTP id XAA09017; Thu, 13 Jun 1996 23:11:13 +0200 Received: from localhost (micke@localhost) by my8.sm.luth.se (8.6.11/8.6.11) with SMTP id XAA28662; Thu, 13 Jun 1996 23:14:32 +0200 Message-Id: <199606132114.XAA28662@my8.sm.luth.se> X-Mailer: exmh version 1.6.6 3/24/96 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: templin@pa.dec.com (Fred Templin) Cc: rem-conf@es.net Subject: Re: Compression of RTP/UDP/IP In-reply-to: Your message of Thu, 13 Jun 1996 12:33:46 PDT. Date: Thu, 13 Jun 1996 23:14:31 +0200 From: Mikael Degermark Fred Templin writes: >One method for detecting session-oriented UDP packets would be to peer into >the data region and detect whether the packets "smell like" RTP, as Casner and >Jacobsen have proposed. But, an alternative would be to define a new IP protocol >type (IPPROTO_UDPSTREAM??) which would serve as an indication to a slow-link >compression engine that certain UDP packets are session-oriented (and thus good >candidates for header compression) whereas others are not. A better (but unfortunately unrealistic) idea is to get rid of the Length field in the UDP header as it is completely redundant with the length field in the IP header. The two-octet length field could then be put to better use, for instance by indicating the payload type. Seriously, Casner and Jacobson are likely to be correct in believing that heuristics will work well. Micke From rem-conf-request@es.net Thu Jun 13 17:49:58 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 14:48:41 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 13 Jun 1996 22:47:32 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: rem-conf@es.net Subject: sdr-supported platforms Date: Thu, 13 Jun 96 22:47:24 +0100 Message-ID: <14029.834702444@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk Several people have done sterling work recently in porting sdr to more platforms, so I've attempted to gather all the known versions together again. Platforms for which sdr V2.2a9 or later is now available are: Solaris 2 (built on 2.5) SunOS 4 (built on 4.1.3_U1) Irix (built on 5.3) DEC Alpha (OSF/1) (built on 2.0) HPUX (built on 9.05) Linux (current a.out, but will change to ELF shortly) NeXT (m68k only) FreeBSD BSDI (not yet on our server due to piece of wet string where there should be a network...) Windows 95 WIndows NT All of these are now available from ftp://cs.ucl.ac.uk/mice/sdr/ and should be available from the mirror sites listed in mirrors.html in due course. The current release of sdr is 2.2a9, except for Windows95/NT and BSDI, where it's later. The distribution README is enclosed below. Please keep the comments, suggestions and bug reports coming! Mark -------- Sdr: The UCL Mbone Session Directory This directory contains the current releases of the sdr session directory tool. The file mirrors.html contains the location of mirror sites which should provide better performance for site outside Europe. The master site is ftp://cs.ucl.ac.uk/mice/sdr/ The Solaris2, SunOS4, OSF/1, Irix, HPUX, and linux versions of sdr have been built at UCL. The BSDI version was built by Alan Batie , and has not been tested at UCL. The FreeBSD version was built by Bill Fenner , and has not been tested at UCL. The NeXT version of sdr was ported and built by Yves Lepage and has not been tested at UCL. It is for m68k only. The Windows 95/NT release in winsdr22.zip was ported and built by Van Jacobson at LBNL, and includes Windows95/NT binaries for vic, vat and cal (which is required by sdr). Currently this file contains sdr2.2a12. Session Invitation is disabled in this version. The file xm contains a script for comminuicating URLs from session descriptions to a Mosaic or netscape running on the same machine. xm does not work on Windows95/NT. Several people have made significant contributions to sdr, and in particular Bill Fenner and Van Jacobson have both contributed large numbers of fixes and extensions to the current sdr source. Source to sdr is not currently publically available due to the problems of integrating changes from large numbers of contributors and due to the not-yet-completely-finalised nature of the SDP, SIP and SDAP protocols. Sdr source will be available in due course when its rate of change decreases somewhat. Please contact me directly if you wish to port sdr to a platform not listed above, but do note - sdr is not finished and so this is something of a moving target! Mark Handley , 13/6/96 From rem-conf-request@es.net Fri Jun 14 02:05:59 1996 Received: from ruin.informatik.uni-bremen.de by osi-west.es.net with ESnet SMTP (PP); Thu, 13 Jun 1996 23:04:56 -0700 Original-Received: by ruin.informatik.uni-bremen.de (8.6.10/20.9.94cl) id IAA11525 Fri, 14 Jun 1996 08:04:31 +0200 PP-warning: Illegal Received field on preceding line Date: Fri, 14 Jun 1996 08:04:31 +0200 Message-Id: <199606140604.IAA11525@ruin.informatik.uni-bremen.de> From: Carsten Bormann To: Mikael Degermark Cc: templin@pa.dec.com (Fred Templin), rem-conf@es.net Subject: Re: Compression of RTP/UDP/IP In-Reply-To: <199606132114.XAA28662@my8.sm.luth.se> References: <199606132114.XAA28662@my8.sm.luth.se> Mikael Degermark writes: > Fred Templin writes: > > >One method for detecting session-oriented UDP packets would be to peer into > >the data region and detect whether the packets "smell like" RTP, as Casner and > >Jacobsen have proposed. But, an alternative would be to define a new IP > protocol > >type (IPPROTO_UDPSTREAM??) which would serve as an indication to a slow-link > >compression engine that certain UDP packets are session-oriented (and thus > good > >candidates for header compression) whereas others are not. > > [...] > > Seriously, Casner and Jacobson are likely to be correct > in believing that heuristics will work well. Another way to find out about real-time streams is to look at RSVP packets. While the existence of RSVP PATH messages already is a good hint that something session-oriented is going on, the ISSLOW draft proposes to define RSVP objects that can be used to add detail the compressor may be interested in. See draft-ietf-issll-isslow-00.txt, or, while that is being processed, http://www-rn.informatik.uni-bremen.de/research/isslow.ps, .txt, .html Gruesse, Carsten From rem-conf-request@es.net Fri Jun 14 05:36:09 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jun 1996 02:35:33 -0700 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Fri, 14 Jun 1996 09:22:46 +0200 X-Mailer: exmh version 1.6.7 5/3/96 To: Mikael Degermark cc: templin@pa.dec.com (Fred Templin), rem-conf@es.net From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: Compression of RTP/UDP/IP In-reply-to: Your message of "Thu, 13 Jun 1996 23:14:31 +0200." <199606132114.XAA28662@my8.sm.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 14 Jun 1996 09:22:38 +0200 Sender: schulzrinne@fokus.gmd.de . > > A better (but unfortunately unrealistic) idea is to > get rid of the Length field in the UDP header as it is > completely redundant with the length field in the IP header. One might also argue that the UDP checksum is not exactly necessary for A/V delivery as the likelihood of bit errors is low and the effect of a bit error in many cases less dramatic than a dropped packet. (Since the UDP checksum is not particularly strong, among other reasons, applications have to be prepared to deal with misdelivered packets in any event.) Henning From rem-conf-request@es.net Fri Jun 14 05:42:15 1996 Received: from vtt.fi by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jun 1996 02:41:46 -0700 Received: from tte2049.tte.vtt.fi (tte2049.tte.vtt.fi [130.188.12.149]) by vtt.fi (8.6.10/8.6.9) with SMTP id MAA01872; Fri, 14 Jun 1996 12:41:41 +0300 Message-Id: <2.2.32.19960614094342.007110f0@tel1.tte.vtt.fi> X-Sender: lucenius@tel1.tte.vtt.fi X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Jun 1996 12:43:42 +0300 To: Mikael Degermark , rem-conf@es.net From: Jan Lucenius Subject: Re: Compression of RTP/UDP/IP At 20:03 11.6.1996 +0200, Mikael Degermark wrote: >5. Finally, although I personally think that using authentication on > *every* packet is a bad idea on low-speed links since the hash > uses so many bytes, I can see the need to authenticate or encrypt > over radio links. Yes, but in that case the encryption is (or should be) implemented in the radio link protocols below the IP (e.g. GSM data). From rem-conf-request@es.net Fri Jun 14 06:48:26 1996 Received: from ruin.informatik.uni-bremen.de by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jun 1996 03:46:18 -0700 Original-Received: by ruin.informatik.uni-bremen.de (8.6.10/20.9.94cl) id MAA13316 Fri, 14 Jun 1996 12:46:10 +0200 PP-warning: Illegal Received field on preceding line Date: Fri, 14 Jun 1996 12:46:10 +0200 Message-Id: <199606141046.MAA13316@ruin.informatik.uni-bremen.de> From: Carsten Bormann To: rem-conf@es.net Subject: Re: Compression of RTP/UDP/IP In-Reply-To: <199606132114.XAA28662@my8.sm.luth.se> References: <199606132114.XAA28662@my8.sm.luth.se> Mikael Degermark writes: Fred Templin writes: >One method for detecting session-oriented UDP packets would be to >peer into the data region and detect whether the packets "smell like" >RTP, as Casner and Jacobsen have proposed. But, an alternative would >be to define a new IP protocol type (IPPROTO_UDPSTREAM??) which would >serve as an indication to a slow-link compression engine that certain >UDP packets are session-oriented (and thus good candidates for header >compression) whereas others are not. [...] Seriously, Casner and Jacobson are likely to be correct in believing that heuristics will work well. Another way to find out about real-time streams is to look at RSVP packets. While the existence of RSVP PATH messages already is a good hint that something session-oriented is going on, the ISSLOW draft proposes to define RSVP objects that can be used to add detail the compressor may be interested in. See draft-ietf-issll-isslow-00.txt, or, while that is being processed, http://www-rn.informatik.uni-bremen.de/research/isslow.ps, .txt, .html Gruesse, Carsten From rem-conf-request@es.net Fri Jun 14 09:46:51 1996 Received: from maverick.risq.qc.ca by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jun 1996 06:46:18 -0700 Received: from localhost by maverick.risq.qc.ca (SMI-8.6/SMI-SVR4) id JAA05327; Fri, 14 Jun 1996 09:46:13 -0400 Message-Id: <199606141346.JAA05327@maverick.risq.qc.ca> Reply-to: Francois.Robitaille@maverick.risq.qc.ca To: rem-conf@es.net Subject: Announcement: Networking '96 Montreal, Canada MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 14 Jun 1996 09:46:13 -0400 From: Francois Robitaille Announcement: Networking '96 Montreal, Canada The tenth annual Canadian Networking Conference will be held in Montreal at the Palais des Congres on June 25, 1996. Networking '96 will focus on Canadian issues and events related to the evolution of the Internet in Canada. (The 36th IETF Meeting is also held during that week in Montreal (24-28 June) and Networking '96 will be followed immediately by INET'96. These two events will also be transmited on the MBONE.) We will be broadcasting all day sessions including the Canadian Internet Awards Banquet at night. Latest MBONE tools and protocols will be used with ttl 127. This has been announced in sdr and on both MBONE Agenda servers. Agenda: Tuesday June 25th: 08:30 - 17:15 (GMT-4) Day sessions 20:00 - 23:00 (GMT-4) Canadian Internet Awards Banquet Please see http://relish.concordia.ca/net96/net96.html for the detailed program. For further information or any problems, please contact . Cheers, Francois Robitaille RISQ, CRIM Francois.Robitaille@risq.qc.ca (514) 398-8488 From rem-conf-request@es.net Fri Jun 14 10:09:59 1996 Received: from maverick.risq.qc.ca by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jun 1996 07:09:21 -0700 Received: from localhost by maverick.risq.qc.ca (SMI-8.6/SMI-SVR4) id KAA05383; Fri, 14 Jun 1996 10:09:19 -0400 Message-Id: <199606141409.KAA05383@maverick.risq.qc.ca> Reply-to: Francois.Robitaille@maverick.risq.qc.ca To: rem-conf@es.net Subject: Announcement: INET'96 Montreal, Canada MIME-version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Fri, 14 Jun 1996 10:09:19 -0400 From: Francois Robitaille Announcement: INET'96 Montreal, Canada INET'96, the 6th Annual Conference of the Internet Society focusing on worldwide issues of Internet networking will be held 25-28 June 1996 in Montreal, Canada. We will be broadcasting the plenary sessions and possibly some breakout sessions to be determined. Latest MBONE tools and protocols will be used with ttl 127. This has been announced in sdr and on both MBONE Agenda servers (http://www.msri.org/mbone/, http://www.cilea.it/MBone/agenda.html). Agenda: Wednesday June 26th: 08:30 - 10:30 (GMT-4) Opening Plenary Session Thursday June 27th: 08:30 - 10:30 (GMT-4) Plenary Session Friday June 28th: 10:30 - 12:30 (GMT-4) Closing Plenary Session Please see http://info.isoc.org:80/conferences/inet96/english/ for the detailed program. For further information or any problems, please contact . Francois Robitaille RISQ, CRIM Francois.Robitaille@risq.qc.ca (514) 398-8488 From rem-conf-request@es.net Fri Jun 14 10:37:06 1996 Received: from dub-img-7.compuserve.com by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jun 1996 07:36:32 -0700 Received: by dub-img-7.compuserve.com (8.6.10/5.950515) id KAA04641; Fri, 14 Jun 1996 10:36:30 -0400 Date: 14 Jun 96 10:34:04 EDT From: Christie To: AVT Subject: unsubscribe Message-ID: unsubscribe From rem-conf-request@es.net Fri Jun 14 10:49:37 1996 Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jun 1996 07:49:10 -0700 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA22336; Fri, 14 Jun 96 10:49:05 EDT Received: from dilbert.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA07178; Fri, 14 Jun 96 10:49:03 EDT Received: by dilbert.pictel.com (SMI-8.6/SMI-SVR4) id KAA16811; Fri, 14 Jun 1996 10:50:40 -0400 Date: Fri, 14 Jun 1996 10:50:40 -0400 From: wchung@pictel.com (Wilson Chung) Message-Id: <199606141450.KAA16811@dilbert.pictel.com> To: rem-conf@es.net Subject: subscribe subscribe From rem-conf-request@es.net Fri Jun 14 13:40:08 1996 Received: from mail.arc.nasa.gov by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jun 1996 10:39:00 -0700 Received: from nikki ([163.206.3.4]) by mail.arc.nasa.gov (post.office MTA v1.9.3 ID# 0-13121) with SMTP id AAA6874 for ; Fri, 14 Jun 1996 10:40:47 -0700 Sender: root@es.net Message-ID: <31C1816E.41C6@mail.arc.nasa.gov> Date: Fri, 14 Jun 1996 11:12:46 -0400 From: "Steve N. Kyramarios" Organization: Code ID X-Mailer: Mozilla 3.0b4 (X11; I; IRIX 5.3 IP22) MIME-Version: 1.0 To: rem-conf@es.net Subject: STS-78 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Unique video only pre-launch coverage of mission STS-78 will start Monday (6/17) until 4 hours prior to launch. At that time, video/audio coverage of the mission will start and continue for the duration of the mission. Contact Steve Kyramarios for pre-launch issues and Mark Allard for mission coverage or other issues pertaining to this service. Daily mission status updates are available at . This broadcast is coordinated and offered as a service to the MBone community by NASA-Ames Research Center and NASA-Kennedy Space Center. Please refer to the above pao homepage and/or to the sdr advertisement for further details. -- Steve N. Kyramarios NASA-Ames Research Center Systems Engineer Communications and Networks skyramarios@mail.arc.nasa.gov (415)604-4950 > office phone with voice mail (415)604-6999 > fax From rem-conf-request@es.net Fri Jun 14 14:15:23 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jun 1996 11:14:04 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA13456; Fri, 14 Jun 1996 11:13:51 -0700 Date: Fri, 14 Jun 1996 11:13:51 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Compressing IP/UDP/RTP Headers Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, Here is my more complete draft on IP/UDP/RTP compression. There is still a more to be worked out, but that's part of the discussion in Montreal. I hope this draft gets posted officially, but I'm not sure I made it in time. -- Steve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Internet Engineering Task Force Audio/Video Transport Working Group INTERNET-DRAFT S. Casner / Precept Software draft-casner-jacobson-crtp-00.txt V. Jacobson / LBNL June 13, 1996 Expires: 12/96 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Abstract This document describes a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In many cases, all three headers can be compressed into a single byte. This document is not (yet) a protocol specification, but it proposes several ideas on header compression and discusses some design issues. It is expected that this work will be combined with contributions from others to produce a protocol specification within the Audio/Video Tran- sport working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group mailing list rem-conf@es.net and/or the author(s). Expires December 1996 [Page 1] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 1. Introduction Since the Real-time Transport Protocol has been published as an RFC [1], there is growing interest in using it as one step to achieve interopera- bility among different implementations of network audio/video applica- tions. However, there is also concern that the 12-byte RTP is too large an overhead for 20-byte payloads when operating over low speed lines such as dial-up modems at 14.4 or 28.8 kb/s. (Existing applications operating in this mode may use an application-specific protocol with a one- or two-byte header and reduced functionality relative to RTP.) In the past few months, several people have developed ideas for compressing the RTP header alone, on an end-to-end basis, or for compressing the combination of IP, UDP and RTP headers on a link-by-link basis. In particular, Scott Petrack of IBM presented his ideas on RTP- only compression in the AVT session at the Los Angeles IETF meeting in March, 1996, and Carsten Bormann presented his ideas on an overall achi- tecture for compression in combination with traffic control across a low-speed link in the ISSLL session. This draft is the result of a meeting of the two authors to discuss a translation of Jacobson's design for TCP/IP header compression (RFC1144) [3] to the problem of combined compression of IP/UDP/RTP headers between the two endpoints of a low-speed link. David Oran of cisco indepen- dently developed a note based on similar ideas, and suggested the use of this compression in combination with the PPP Multilink protocol for seg- mentation. Compressing 40 bytes of IP, UDP and RTP headers together provides sub- stantially more gain than compressing 12 bytes of RTP header alone because the resulting size is a few bytes in either case and can be just a single byte in the case of the combined compression if UDP checksums are not being used. However, use of the combined compression requires development and deployment of infrastructure, whereas end-to-end RTP compression can be implemented independently in an application. Even though implementation of the combined compression scheme in the routers and protocol stacks that operate as the endpoints of low-speed links may occur quickly, and even though the motivation for service providers to deploy the new compression may be high, the process is likely to take a year or more. To allow application developers to proceed before the "complete solu- tion" of combined IP/UDP/RTP header compression can be deployed, it has been proposed that an "interim solution" of RTP-only compression be developed. The problem is that interim schemes are typically very dif- ficult to eliminate once the complete solution is ready. Therefore, it is critical to design a transition strategy as part of the interim scheme that allows applications to determine whether the complete Expires December 1996 [Page 2] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 solution is available, and if so, to avoid doing the RTP-only compres- sion. This draft, in its current form, discusses only a proposal for combined IP/UDP/RTP header compression. If this document goes on to serve as the basis for a protocol specification sponsored by AVT, it is expected that contributions will be incorporated from other drafts and that the author list will expand. In particular, Scott Petrack has drafted ideas for end-to-end RTP compression and for the transition strategy [4, 6]. One document structure that has been proposed is to include the interim solution as an appendix to the specification of the complete solution so the intended transition can be clearly conveyed and so that the two are not seen as alternatives. 2. Assumptions and Tradeoffs The proposal described here is a relatively simple one. The goal was to reduce the IP/UDP/RTP headers to a single byte for most packets in the case where no UDP checksums are being sent. It is motivated primarily by the specific problem of sending audio and video over 14.4 and 28.8 dialup modems. These links tend to provide full-duplex communication, so the proposal takes advantage of that fact, though this constraint could be removed. This proposal does not address segmentation and preemption of large packets to reduce the delay across the slow link experienced by small real-time packets, except to suggest the use of PPP Multilink protocol for this purpose. Carsten Bormann's draft [2] explores this issue in more detail. Since this proposal is a translation of the design of TCP/IP header compression in RFC1144, which predated IPv6, this proposal also consid- ers only IPv4. (Conceivably, the low-speed dialup modems will be obsoleted by higher-speed lines before anyone attemts to deploy IPv6 on them, and then compression of RTP may no longer be required; on the other hand, IPv6 addresses are so large that compression may be required on every link.) Mikael Degermark, et. al., have designed a compression scheme [5] for IPv6 as well as IPv4 that deals with TCP and non-TCP as two classes of transport above IP. It may be feasible to adapt this design to create a third class specifically for IP/UDP/RTP. Likewise, this proposal does not address encapsulations with multiple IP headers as does the IPv6 scheme. That limitation could be removed if it is feasible to merge the two schemes. It should be noted that implementation simplicity is an important factor to consider in evaluating the a compression scheme. Communications Expires December 1996 [Page 3] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 servers may need to support compression over perhaps as many as 100 dial-up modem lines using a single processor. Therefore, it may be appropriate to make some simplifications in the design at the expense of generality, or to produce a flexible design that is general but can be subsetted for simplicity. The next sections discuss some of the trade- offs listed here. 2.1. Simplex vs. Full Duplex In the absence of other constraints, a compression scheme that worked over simplex links would be preferred over one that did not. The schemes proposed by Degermark [5] and Oran [7] support this. However, operation over a simplex link requires periodic refreshes with an uncompressed packet header to restore compression state in case of error. If an explicit error signal can be returned instead, the delay to recovery may be shortened substantially. The overhead in the no- error case is also reduced. Some UDP applications may require only sim- plex communication, but RTP applications will frequently require full duplex communication. The application may be 2-way, as in a telephone conversation, or at least there is a need for a return path to carry reception feedback in RTCP packets. One of the motivations for supporting simplex links is to allow link- level multicast. How real is that requirement? Are there low-rate mul- tiaccess links in use today or planned? Note that support of IP multi- cast over a low-bandwidth point-to-point link certainly should be a goal, but link-layer multicast is a separate question. Asked more gen- erally, are there low- data-rate links that need compression but are not full duplex? This proposal allocates includes an error indication on the reverse path, however it would be possible to use a periodic refresh instead. Whenever the decompressor detected an error, it would simply invalidate all compression contexts and wait for an uncompressed header to be transmitted in a particular context before resuming decompression of packets in that context. 2.2. Segmentation Delay induced by the time required to send a large packet over the slow link is not a problem for one-way audio, for example, because the receiver can adapt to the variance in delay. However, for interactive conversations, minimizing the end-to-end delay is critical. The problem is that implementing a good, robust segmentation scheme can be quite difficult. It may be feasible to avoid large packets as an alternative to segmenta- tion. For TCP traffic, MSS negotiation should be used to avoid the Expires December 1996 [Page 4] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 problem at the endpoints. For UDP-based traffic that is part of a real-time session, such as audio, video, or shared whiteboard data, the MSS should be controlled along with the maximum session bandwidth as a session parameter. For example, in SDP [8] there is already a session bandwidth parameter, and perhaps a session MSS should be added. That is, for sessions that are intended to include participants on low-speed links, a low-rate encoding will be selected as part of a conscious deci- sion to meet the participants' requirements. For large sessions in which degrading the service to all recipients for the benefit of a few is not justified, RTP provides a mechanism to interpose "mixers" and "translators" to transcode to a lower bandwidth. The low-rate encodings in these translators should also use small MSS's. On the other hand, one might argue that multicasting small packets over many links of a wide-area network just to fit the needs of a small number of recipients on low-speed links is a misuse of a global solution to for a local problem. A scheme for segmenting large packets and interleaving small packets between the segments is described in Section 4. 2.3. Layering This proposal deals with compression as a separate layer because it seems inappropriate to integrate segmentation and compression in such a way that the compression could not be used by itself in situations where segmentation was deemed unnecessary or impractical. Similarly, one would like to avoid any requirements for a reservation protocol. The compression scheme can be applied locally on the two ends of a link independent of any other mechanisms except for the requirements that the link layer provide some packet type codes, a packet length indication, and good error detection. Conversely, separately compressing the IP/UDP and RTP layers loses too much of the compression gain that is possible by treating them together. It seems appropriate to cross these protocol layer boundaries because the same function is being applied across all layers. 3. The Compression Algorithm The motivation and description given here are sketchy. Readers are referred to the description of TCP/IP header compression in RFC1144. 3.1. The basic idea In TCP header compression, the first factor of two comes from the obser- vation that half of the bytes in the header remain constant over the life of the connection. The remaining compression comes from differen- tial coding on the changing fields to reduce their size, and from Expires December 1996 [Page 5] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 eliminating the changing fields entirely for common cases by calculating the changes from the length of the packet. This length is indicated by the link-level protocol. For RTP header compression, some of the same techniques may be applied. However, the big gain comes from the observation that although several fields change in every packet, the difference from packet to packet is often constant and therefore the second-order difference is zero. By maintaining both the uncompressed header and the first-order differences in the session state shared between the compressor and decompressor, all that must be communicated is an indication that the second-order differ- ence was zero. The decompressor can reconstruct the original header without any loss of information. Because the RTP compression is lossless, it may be applied to any UDP traffic that benefits from it. Most likely, the only packets that will benefit are RTP packets, but it is acceptable to use heuristics to determine whether or not the packet is an RTP packet because no harm is done if the heurisic gives the wrong answer. This does require execut- ing the compression algorithm for all UDP packets. It might be possible to save work in the compressor by keeping track of packet streams (iden- tified by addresses and ports) that have failed to compress as RTP pack- ets for some number of attempts. On the other hand, making that test may take as much time as attempting RTP compression and finding that the "RTP header" needs to be sent uncompressed. When RTP compression fails, the IP and UDP headers may still be compressed. Just as TCP/IP header compression maintains shared state for multiple simultaneous TCP connections, this IP/UDP/RTP compression must maintain state for multiple session contexts. A session context is defined by the combination of the IP source and destination addresses, the UDP source and destination ports, and the RTP SSRC field. In order to communicate packets in the various uncompressed and compressed forms, this protocol depends upon the link layer being able to provide an indication of four packet types in addition to the packet type that indicates IP: UNCOMPRESSED_UDP which communicates the uncompressed IP/UDP headers plus any following headers and data to establish the uncompressed header state in the decompressor for a particular context. That context is identified by an 8-bit session context ID. In order to carry the ID without expanding the size of the header, RFC1144 specifies that the ID replaces the IP protocol field, which would known to indicate UDP in this case. In [5], the IP total length field is used instead since the length may be inferred from the length provided by the link layer. This allows the IP protocol field to indicate encapsulations or other transport protocols. Expires December 1996 [Page 6] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 COMPRESSED_UDP which communicates the IP and UDP headers compressed to 5 or fewer octets (often 1), followed by any subsequent headers (possibly RTP) and data. This form is used when there are differ- ences in fields of the (possible) RTP header that are usually con- stant. It redefines the SSRC field of the session context. COMPRESSED_RTP which indicates that the RTP header is compressed along with the IP and UDP headers. The result may still be a sin- gle octet. This form is used when the second-order difference is zero and also to communicate first-order differences as delta encodings. CONTEXT_ERROR which indicates loss of synchronization between the compressor and decompressor. No other contents are carried. 3.2. Compression of RTP Data Packet Headers In the IP header, only the total length, packet ID, and header checksum fields will normally change. The total length is redundant with the length provided by the link layer, and since this compression scheme must depend upon the link layer to provide good error detection (e.g., PPP's CRC), the header checksum may also be elided. This leaves only the packet ID, which, assuming no IP fragmentation, would not need to be communicated. However, in order to maintain lossless compression, we will encode changes in the packet ID. In the UDP header, the length field is redundant with the IP total length field and the length indicated by the link layer. The UDP check- sum field will be a constant zero if the source elects not to generate UDP checksums. Otherwise, the checksum must be communicated in order to preserve the lossless compression. Allowing end-to-end error detection for applications that require it is an important principle. In typical usage of the RTP header, the sequence number and the times- tamp will change from packet to packet. If packets are not lost or misordered, the sequence number will increment by one for each packet. For audio packets of constant duration, the timestamp will increment by the number of sample periods conveyed in each packet. For video, the timestamp will change on the first packet of each frame, but then stay constant for the remaining packets in the frame. Note that in both scenarios the second-order difference of these fields is usually zero. When they do change, the magnitude of the change is usually much smaller than the full number of bits in the field, so the size can be reduced by encoding the difference rather than the absolute value. The M bit will be set on the first packet of a talkspurt and the last packet of a video frame. If it were treated as a constant field such that each change required sending the full RTP header, this would reduce Expires December 1996 [Page 7] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 the compression significantly. Therefore we will dedicate one bit in the compressed header to it. If the packets are flowing through an RTP mixer, most commonly for audio, then the CSRC list and CC count will also change. However, the CSRC list will typically remain constant during a talkspurt or longer, so it need be sent only when it changes. 3.3. The protocol When the second-order difference of the RTP header is zero, all we need to communicate is a small sequence number to maintain synchronization and detect packet loss between the compressor and decompressor. This sequence number must be global across all session contexts since its purpose is to detect losses even when packets from multiple contexts are interleaved. The sequence number is reset to zero whenever an UNCOMPRESSED_UDP packet is transmitted to synchronize with the decompressor. When the second-order difference of the RTP header is not zero for some fields, we want to communicate the new first-order difference for only those fields, and we want to use a compact encoding. The new first- order difference is used to update the uncompressed header in the decompressor's session context, and it is also stored explicitly in the context to be used for updating the field on subsequent packets assuming the second-order difference is zero. In practice, the only field for which it is useful to store the first- order difference is the RTP timestamp. For the RTP sequence number field and the IP ID field, the usual increment is 1. If the sequence number changes by other than 1, we want to communicate the difference, but we don't want to have to explicitly communicate a difference of 1 on the next packet assuming it is in order. Instead, we want the expected first-order difference to remain 1. For the RTP timestamp, when an UNCOMPRESSED_UDP packet is sent to refresh the state, the stored first-order difference is set to zero. If the timestamp is the same on the next packet (e.g., same video frame), then the second-order difference is zero. Otherwise, the difference between the timestamps of the two packets is transmitted as the new first-order difference. To indicate which fields have changed by other than the expected differ- ence, we will use a bit mask. In addition to the small link sequence number, the list of items to be conditionally communicated in the compressed IP/UDP/RTP header is as follows: C = session context ID Expires December 1996 [Page 8] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 I = IP packet ID U = UDP checksum M = RTP marker bit S = RTP sequence number T = RTP timestamp L = RTP CSRC count and list If we are to allow 3 bits for the link sequence number to get a reason- able probability of loss detection, there are too few bits remaining to assign one bit to each of these items and still fit them all into our target compressed header size of one byte. We do not need to explicitly indicate the presence of the UDP checksum because a source will typically include checksums on all packets of a session or none of them. When the session state is initialized with an uncompressed header, if there is a nonzero checksum present, an unen- coded 16-bit checksum will be appended to the compressed header in all subsequent packets until this setting is changed by sending another uncompressed packet. Of the remaining items, the CSRC list may be the one least frequently used. We can avoid dedicating a bit to indicate CSRC change by using an unusual combination of the other bits instead. If all three of the bits for the RTP sequence number, RTP timestamp and RTP marker bit are set, we will treat this as a special case indicating that a special partially compressed form of the RTP header will follow. That header will include the CC count and CSRC list in addition to the RTP sequence number and timestamp differences that would normally be present as indicated by that bit combination, plus a separate copy of the marker bit since this combination may sometimes be used when the marker bit was not actually set. Note that the CSRC list will most often be used for audio mixers, and that it will usually change at the start of a talkspurt when the M bit will be set and the timestamp will change by an unexpected amount. Therefore, using this special combination will add little overhead when communicating CSRC changes. The resulting compressed IP/UDP/RTP header would look something like the following diagram. Note that the order of bits shown in the mask is arbitrary and may be changed as indicated by implementation experience. Also, the differential encodings of changed values have not yet been determined; it may be appropriate to define the smallest representation to use only 4 bits rather than 8 as shown here. A study of packet traces will provide some statistics for the design of the encodings. Expires December 1996 [Page 9] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | M | S | T | I | C | sequence | +---+---+---+---+---+---+---+---+ : session context (C) : +...............................+ : delta IP ID (I) : +...............................+ : : + UDP checksum + : : +...............................+ : CC and M (MST) : +...............................+ : delta RTP sequence : +...............................+ : delta RTP timestamp : +...............................+ : : : RTP header extension : : (only if X set in context) : : : +...............................+ : : : CSRC list (MST) : : : : : +---+---+---+---+---+---+---+---+ | data | : : 3.4. Compression of non-RTP UDP Packets If there is a change in any of the fields of the RTP header that are normally constant (such as the payload type field), then an UNCOMPRESSED_RTP packet may be sent rather than a full UNCOMPRESSED_UDP packet. The UNCOMPRESSED_RTP packet has the same format as the COMPRESSED_RTP packet except that the M, S and T bits are always 0 and the corresponding fileds are not present: Expires December 1996 [Page 10] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | I | C | sequence | +---+---+---+---+---+---+---+---+ : session context (C) : +...............................+ : delta IP ID (I) : +...............................+ : : + UDP checksum + : : +---+---+---+---+---+---+---+---+ | data | : : Note that this constitutes a form of IP/UDP header compression different >from that proposed for IPv6. The motivation is to allow reaching the target of one byte when UDP checksums are disabled, as IPv4 allows. The IPv6 proposal does not use differential coding for UDP packets, so in the IPv4 case, two bytes of IP ID and two bytes of UDP checksum would always be transmitted. 3.5. Compression of RTCP Control Packets By relying on the RTP convention that data is carried on an even port number and the corresponding RTCP packets are carried on the next higher (odd) port number, one can tailor separate compression schemes to be applied to RTP and RTCP packets. The details of the RTCP compression are not worked out yet to the same level as that for RTP, but the mechanisms will be similar. For RTCP, the compression applies not only to the header but also the "data", that is, the contents of the dif- ferent packet types. The numbers in Sender Report (SR) and Receiver Report (RR) packets will not compress well, but the text information in the Source Description (SDES) packets can be compressed down to a bit mask indicating the pres- ence of each item type for timing purposes (particularly for the SDES NOTE item; the other items need not be repeated except to allow the end system to measure the average RTCP packet size for the interval calcula- tion). In order to allow compression when SDES information for several sources is sent through an RTP "mixer", it is necessary to maintain separate RTCP session contexts for each SSRC identifier. Since the RTP protocol specification suggests that the RTCP packet interval be scaled so that the aggregate RTCP bandwidth used by all par- ticipants in a session will be no more than 5% of the session bandwidth, weak compression of RTCP should not be too big a problem. Expires December 1996 [Page 11] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 3.6. Error Recovery Whenever the link layer detects an error, or whenever the 3-bit sequence number increments by other than 1 (except for the reset to zero after an UNCOMPRESSED_UDP packet), the decompressor must invalidate all session contexts and send a CONTEXT_ERROR packet back to the compressor. All packets for an invalid context must be discarded until an UNCOMPRESSED_UDP packet is received for that context. This means that line errors can be rather expensive if there are many active contexts. The impact could be reduced if differential encoding were not used, and in the IPv6 non-TCP case, but the compressed header size in the non-error case would then be substantially larger. A less drastic change would be to eliminate the C bit and always send the one- byte context. This would allow each context to have a distinct 4-bit sequence number and would allow separately invalidating contexts only if there was a sequence number jump for that context. In this case, the CONTEXT_ERROR packet would contain a list of the context IDs for which a jump was seen. In the case where UDP checksums are being transmitted, the decompressor could attempt decompression of packets following an error and use the checksum to test for success. However, there is a nontrivial risk of an incorrect positive indication. 4. Segmentation with PPP Multilink David Oran suggested that the PPP Multilink protocol could be used to segment large, presumably non-real-time packets and allow small, real- time packets to be interleaved with the segments. This technique might be applied on a single physical link as well as multiple links. Since the sequencing of packets is modified by the interleaving, the large packets sent in the ML encapsulation bypass the compressor and decompressor, and they do not carry the 3-bit compression sequence number. This is practical because the overhead of an uncompressed header on a large packet is not significant. The ML-encapsulated pack- ets also do not cause the sequence number to reset. However, link errors detected by the Multilink reassembly functions using its own sequence numbers are indicated to the compressor with the CONTEXT_ERROR message just as link errors detected by a jump in the 3-bit sequence number. A packet would be selected for segmentation based strictly upon size. A reasonable size to balance delay versus ML-encapsulation overhead for links speeds such as 28.8 kb/s would be around 128 bytes. Depending upon the implementation, there is a possibility of re-ordering of pack- ets within a session context if some are large enough to be segmented Expires December 1996 [Page 12] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 and sent via Multilink while others are small. However, this should not cause problems because the RTP sequence numbers should be reconstructed correctly and will allow the application to correct the ordering. 5. Acknowledgments This protocol design draws heavily upon the design of TCP/IP header compression. 6. References: [1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for real-time applications," RFC1889. [2] C. Bormann, "Providing integrated services over low-bitrate links," work in progress. [3] V. Jacobson, "TCP/IP Compression for Low-Speed Serial Links," RFC1144. [4] S. Petrack and E. Ellesson, "Framework for C/RTP: Compressed RTP Using Adaptive Differential Header Compression," contribution to mailing list rem-conf@es.net, Feb. 96 and talk at AVT working group, IETF March 96. [5] M. Degermark, B. Nordgren, and S. Pink, "Header Compression for IPv6," work in progress. [6] S. Petrack, "Compression of Headers in RTP Streams," work in progress. [7] D. Oran, "Thoughts on RTP Compression", private communication. [8] M. Handley and V. Jacobson, "SDP: Session Description Protocol," work in progress. 7. Security Considerations Because encryption eliminates the redundancy that this compression scheme tries to exploit, there is some inducement to forgo encryption in order to achieve operation over a low-bandwidth link. However, for those cases where encryption of data and not headers is satisfactory, RTP does specify an alternative encryption method indicated by different payload types. Expires December 1996 [Page 13] Internet Draft draft-casner-jacobson-crtp-00.txt May 1996 8. Authors' Addresses Stephen L. Casner Precept Software, Inc. 1072 Arastradero Road Palo Alto, CA 94304 United States EMail: casner@precept.com Van Jacobson MS 46a-1121 Lawrence Berkeley National Laboratory Berkeley, CA 94720 United States EMail: van@ee.lbl.gov Expires December 1996 [Page 14] From rem-conf-request@es.net Fri Jun 14 16:54:44 1996 Received: from IETF.cnri.reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jun 1996 13:53:57 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa19191; 14 Jun 96 10:05 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-avt-cellb-07.txt Date: Fri, 14 Jun 96 10:05:12 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9606141005.aa19191@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : RTP Payload Format of Sun's CellB Video Encoding Author(s) : M. Speer, D. Hoffman Filename : draft-ietf-avt-cellb-07.txt Pages : 8 Date : 06/13/1996 This draft describes a packetization scheme for the CellB video encoding. The scheme proposed allows applications to transport CellB video flows over protocols used by RTP. This document is meant for implementors of video applications that want to use RTP and CellB. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-cellb-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-cellb-07.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-cellb-07.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960613135701.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-cellb-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-cellb-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960613135701.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Fri Jun 14 19:49:20 1996 Received: from VNET.IBM.COM by osi-west.es.net with ESnet SMTP (PP); Fri, 14 Jun 1996 16:48:46 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2331; Fri, 14 Jun 96 19:48:28 EDT Date: Fri, 14 Jun 96 16:40:42 IST From: Scott Petrack To: rem-conf@es.net Subject: End to end RTP compression Fred wrote: >defining a new IP protocol type touches all end-node implementations which run > streaming-UDP applications (such as RTP). But, I think the same is true for > end-to-end RTP header compression... The end-to-end header compression (the 'interim solution') that is being proposed for RTP is an application level thing. No stacks anywhere are being modified. After all RTP is at present unknown to stacks, and the whole point of the end to end solution is that applications can get some benefit now while preparing themselves for the correct solution. Of course, this doesn't reflect on whether or not a new IP protocol type is a good thing. I am just saying that the end to end solution just requires apps that are running on serial links to move from whatever they are doing now ( and it's not RTP) to something standard. About Carsten's real time encapsulation.... The main reason I did not put a description of RTP-only compression in my draft is that I wanted to see precisely what the correct RTP/UDP/IP will look like. I would like to see if it is possible to make RTP-only compression very very close to the "RTP-part" of RTP/UDP/IP compression. I don't think that it can be identical, but I'm hoping that it can be really very close. I think that this would be a very good thing both for technical and strategic reasons. Scott From rem-conf-request@es.net Sun Jun 16 03:43:24 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sun, 16 Jun 1996 00:42:04 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA23972; Sun, 16 Jun 1996 00:41:48 -0700 Date: Sun, 16 Jun 1996 00:41:48 -0700 (PDT) From: Stephen Casner To: Scott Petrack Cc: rem-conf@es.net Subject: Re: End to end RTP compression In-Reply-To: <9606150029.AA16466@precept.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Scott, > I would > like to see if it is possible to make RTP-only compression very very > close to the "RTP-part" of RTP/UDP/IP compression. I don't think that it > can be identical, but I'm hoping that it can be really very close. I think > that this would be a very good thing both for technical and strategic > reasons. I agree that would be desirable, but I fear it is not feasible because of the much longer delay, the higher loss rate, and the additional consideration of reordering on the end-to-end path compared to a single link. -- Steve From rem-conf-request@es.net Sun Jun 16 04:44:05 1996 Received: from VNET.IBM.COM by osi-west.es.net with ESnet SMTP (PP); Sun, 16 Jun 1996 01:42:30 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7645; Sun, 16 Jun 96 04:41:56 EDT Date: Sun, 16 Jun 96 11:06:28 IST From: Scott Petrack To: its@www.raleigh.ibm.com, rem-conf@es.net Subject: SISP - Simple Internet Signalling Protocol Appended below is an I-D about SISP, the "simple internet signalling protocol," which I hope is a useful addition to controlling realtime internet communication. The draft was sent before the gong, and an announcement and abstract was sent to this mailing list. But I just got the dreaded "unable to deliver mail" message from the mailing lists, so I have decided to post the entire I-D to here (in case I get the same ubdeliverable message from the I-D editor.) Internet Engineering Task Force MMusic WG INTERNET-DRAFT Scott Petrack, IBM draft-petrack-sisp-00.txt 13 June 1996 Expires: December 1996 SISP - Simple Internet Signalling Protocol Status of this Memo This document is a first draft of 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. This document is truly rough, but it was felt that the timeliness of the ideas justified dissemination in this preliminary form. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete 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 Simple Internet Signalling Protocol (SISP) performs one function: signalling of realtime data streams over IP networks. SISP has several distinguishing features: it is a tiny extension of RTCP, running over UDP or TCP, it can integrate very well with PSTN signalling, and it can run in very low bandwidth situations without disturbing the real time stream. It is completely scalable with respect to number of participants and also with respect to "tightness" of control, and can work with an extremely wide variety of conference models, policies, and standards. SISP differs from other conferencing protocols in that it performs a single essential task completely. It is argued that other protocols solve only parts of several overlapping problems. SISP can serve as the lowest common denominator for signalling of real-time streams. The requirements that SISP fulfills, the features it offers, the fact that it uses RTCP as an encapsulation scheme, and its generally minimalist approach of solving one problem only are more important than the actual state machine it implements or particular format of its messages. draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 2 1. Introduction This paper discusses a solution to a one particular aspect of the very large "session/conference control problem": the problem of signalling. It is also an attempt to help resolve a crisis. There are at present two separate groups of applications which perform conferencing over the Internet. One is the suite of MBONE tools. These tools have little or no conference control built in. Separate protocols and tools are used to supply control if it is desired. This is quite a reasonable approach: after all, streaming is streaming and control is control. There is a long list of protocols emerging at present (SIP, SAP, SDP, SCIP, SCCP) which solve an equally long list of problems (location, announcement, setup, session description, scheduling, negotiation of capabilities). The problem is that these protocols have a large overlap, and in many cases they solve overlapping and ill-defined problems. The second group is the plethora of commercial Internet telephones, videophones, and other real time communication applications. These applications often have control built in directly into the real time stream. Of course, these applications are really very immature, and certainly have not done their IETF homework in almost any subject: none use multicast, few use RTP, and none are interoperable in any way, neither for control nor for streaming. Many people consider this a crisis, although oddly enough there are wildly differing views on what the crisis is. Now of course it is very distasteful to have to deal with this second group of applications at all. One has the impression that there are no "real problems" here, certainly none worthy of real research time or thought. It seems clear that if one does some serious work on the first group of applications, then the commercial applications will fall into line as they realize the advantages of standardization. This note argues otherwise: it begins with the question: "what is the absolute minimum infrastructure that must be in place to allow different multimedia conferencing applications to become interoperable?" I claim that there is a very tiny thing which stands out: signalling of realtime streams. This is the mechanism by which one sets up, maintains, and tears down a realtime stream. All of conference control has as object to allow human users to pass real time streams amongst themselves (although of course there will be cases where some or all users are not human). Signalling is what happens at the very last stage, when all decisions about location, announcement, policy, scheduling, have taken place, and you want to setup the real time stream NOW. It also happens when the real time stream is already streaming, and you need to change some shared ephermal state of it NOW. draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 3 SISP has no mechanism to perform location queries, or scheduling of future conferences. In fact, it doesn't really know at all about conferences. It knows about a single RTP stream. SISP simply adds some new RTCP SDES items and a packet type to add some control to a single RTP stream. That's all. If you are satsified with the loose control that RTCP gives over a real time stream, then you do not need to use the new packet type. These allow one to scale the currently available loose control across to a very tightly controlled model. It reuses a number of mechanisms that already exist within RTCP, such as SDES and CNAME. In fact, it is better to say that SISP simply uses these mechanisms, not reuses them. One very important feature of RTP is that each real time stream is a separate entity with its own control; in the same way, SISP treats each real time stream as a separate entity. For example, this allows you to transfer the audio stream in an AudioVideo Call, without transferring the Video stream. These sorts of services are very important. Rather than reinventing them, we get them from RTCP. In general, all issues relating to "shared ephermal state" are implemented on a per-stream basis. Of course, it is very desireable to have standard tools and protocols for location, etc., and of course there is overlap between the need to "announce" and "describe" and "invite." Unfortunately, these problems have not been well enough defined and separated yet, and this is the reason that there are many overlapping protocols which are solving many overlapping problems. We avoid this morass by simply not addressing it in any way. We solve the smaller and perfectly well defined problem of signalling. We certainly hope that solving this will help clarify the other higher level issues. This paper is written from a double perspective. On the one hand, it is indeed a "letter from the front." The author is writing to the generals and strategists back home, describing a particular crisis. He has already done something about it, and he thinks that it is important the generals know. He is a bit upset that the guidelines he has from headquarters are a bit confusing and frankly confused. >From another point of view, the author believes that the knot of overlapping requirements and protocols is making for bad strategy. He has an alternative solution, and he thinks that at least some of its features are truly superior to what now exists. He hopes that the following will contribute to untangling the problem. The author's goal is thus a contribution both to the "problem" of overlapping protocols and also to the "crisis" of non-interoperable Internet Telephones and VideoPhones. draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 4 With all this out of the way, the rest of the paper can be more straightforward. We will describe the the motivation for SISP, the motivation for using RTCP as transport, basic features of SISP, and a few signal flows. For many reasons (including the "shared ephemeral state" of people submitting internet drafts in June 1996 ), a great amount of important detail is missing >from this paper. Apart from simply regretting this, the author wishes to state that the two main ideas of this paper, to use RTCP and to separate out signalling from all other multimedia conferencing problems, can be explained without reference to the bit patterns of the new RTCP packets proposed. In a final section, I compare and contrast broadly SISP with various features of SIP, SAP, SDP, SCIP, SCCP. It is important to understand the claim that non-SISP protocols try to do too much on the one hand, and on the other are not quite rich enough. At first we thought to call the new protocol "YACC" - "yet another conference control." We have convinced ourselves that this would not be accurate: SISP separates out one particular, specific, essential problem, and solves it. 2. RTCP - a model of what is needed The basic features of SISP stem directly from the decision to use RTCP as a basis. So it makes sense to begin with a discussion of the principles that impelled us to such a decision: As explained above, our motivation was to perform signalling, in the dictionary sense of "an act, event, or watchword that has been agreed upon as the occasion of concerted action." That is, signalling are those messages involved in call setup, tear down, and maintenance which causes an action to happen NOW. In particular, the thing of interest which is acted upon is a real time media stream, which in our world is an RTP [1] stream. So we wish to send messages to control real time streams in real time. Now of course it might be interesting to discuss if we really want to control real time streams, or some higher level thing like a "session" or a "conference." But it should be clear that whatever higher level constructs one makes, at some point this turns into control of some real time stream. When a user joins or leaves a conference, for example, then a real time stream is starts or stops flowing over a portion of the Internet, whatever particular meaning you like to assign to the words "user", "join", "leave," or "conference". Since we have to control these RTP streams, it is natural to see what they are made of, and what already exists to signal them. draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 5 Looking at the definition of RTP, one discovers that it contains RTCP, a "control protocol," by definition. In fact, the manual states explicitly that "RTCP may be sufficient for `loosely controlled' sessions" [1,p.2]. Hmmm. It is certainly natural to try to make precise just which signalling and control functions are already in RTCP, before going on to invent something new. In any case, we would certainly like to have a signalling mechanism which can scale from very enabling very loose to very tight control. If RTCP covers one end of the spectrum, it is interesting to see how far it can be pushed, at what point it breaks, and if a continuum can be built with it as one end. One discovers that RTCP is pretty rich already. For example, "by having each participant send its control packets to all the others, each can independently observe the number of participants." [1,p.15] This is certainly some sort of session awareness, of "shared ephemeral state" in the sense of [2]. There is also a great deal of information sent about the sender in the RTCP SDES packet. Although it is not clear at first why one needs to know the email of the person to whom you are talking (I don't know the email address of many of the people I talk to over the telephone), the fact is that *all* the current suggestions within MMUSIC seem to think that this is very important. Luckily for us, then, every RTP stream is already required to have this information transmitted within and SDES packet. So applications already have code to transmit this information. It seems a shame to code it again. In fact, RTCP already solves some other difficult problems in multimedia signalling. Consider the problem of how to define a "session" or "conference." In RTCP, one has the notion of a "Canonical Name" (CNAME). This is used in the RTCP packets so that different RTP streams can be associated. For example, this is how one can know that a particular RTP video stream and a different RTP audio stream are in fact meant to be a synchronized VideoPhone call. What more natural thing to do than to use an RTCP stream to convey all this information which is vital to call signalling? For example, in a very tightly controlled conference (like an ordinary phone call), one might start by sending an RTCP stream with a CNAME and SDES and other necessary information, and when the necessary shared stated has been obtained, the RTP stream itself can begin. If there are several RTP streams that make up a session, one could actually keep one RTCP stream exclusively for signalling, or just add new RTCP and RTP streams as needed. draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 6 In fact, just by using RTP one can get a range of loose to tight control models. As one example among many others, if one wishes to have a multicast session, where some parameters can not be announced in advance, then one can send out the required parameters in an SDES packet, and any RTCP monitor looking at the traffic can join the conference. If one wants tighter control, then security and encryption are both a part of RTCP already. Before we come to the bad news, let us continue and see how RTCP solves some problems of signalling simply and naturally. The BYE packet of RTCP is actually a true signal, in that it does indeed constitute a "watchword which has been agreed upon as the occasion of concerted action." (Well, of course in an extremely loosely controlled conference, of course, this may not be true, but in such a case the BYE is not very important). Here is a more sophisticated reason to use RTCP as a signalling mechanism: signalling often involves precise timing considerations. The need for precise timestamps to deal with some aspects of "shared ephemeral state" is carefully discussed in [2]. Indeed, in the public telephone network (PSTN), passing these strict timing requirements is one aspect of the process of homologation. RTCP packets come with timestamps as well. Another advantage of RTCP is that it allows for separate signalling for each real time stream. For example, if I wish to transfer a VideoPhone conversation to someone who is connected only by telephone, I might wish to transfer the audio stream of the call, but not the video stream. It would be unfortunate if the transfer had to fail, just because the third party had no video support. Just as one doesn't want to *force* someone to associate or interleave two separate streams, logically or physically, one shouldn't try to force association of signalling either. Problems that arise because of bandwidth considerations are best dealt with by RTCP compression [3,4], not by forcing users to have reduced functionality. Finally, for those applications which run on very low bandwidth links, using RTCP has two advantages, one of which is perhaps a bit subtle: First, we have seen that many things one needs to send for signalling are required in any case by RTCP. So apart from saving tired fingers the trouble of writing new code, using RTCP can also save bandwidth. draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 7 Second, on a very low bandwidth link, merely sending a signal can overload the bandwidth, when an application is sending true RTP. Now there is a small amount of tolerance for when one can send an RTCP packet. In particular, a clever application can arrange to send the RTCP packet during a "silence" period, which for the present purpose just means a period when the RTP stream is not itself transmitting. This is sometimes difficult, but a good application will know how to exploit this. Of course, one can perform similar juggling with the signals, but if one is transmitting signals for an RTP stream along with the RTCP stream, it is obviously easier to coordinate things. I hope that the reader is convinced that RTCP is already well on the way to enable signalling for real time streams that is robust, flexible on the scale of loose/tight control, and very effecient in bandwidth and implementation. 3. Extensions to RTCP Unfortunately, there are indeed some needed messages that are missing from RTCP. Not surprisingly, these are needed precisely to fill out the "tightly controlled" end of the scale. What is amazing is that so little is needed. I am sorry to be very informal here, and beg the extreme indulgence of the reader. A committment is made to provide details at a later date. 3.1 RDES - receiver description packet type In a tightly coupled conference you clearly need to identify the person you wish to speak to. Now exactly what "identify" means is of course an interesting subject. We can say what we mean quite precisely: It is assumed that the remote machine receiving the RTCP packets has some means of identifying the person you wish to contact. It is the duty of a decent "location service" to provide both the address (IP, port) of the machine to recieve the real time stream, and hence the RTCP signalling, as well as the tag/value information needed to identify the actual remote party. How this location service works is beyond the scope of the signalling-for-RTP-streams considered here. In any case, the RDES message should have exactly the description needed to identify the remote party. Of course, there is no *requirement* that one use the RDES field to tightly control a conference. One could imagine a private multicast to thousands of members of a cult, where the standard methods of RTCP security could be used to control conference membership very tightly. But it is equally obvious that one mechanism for tight control is that an RDES message should be sent at the very beginning of a call to identify the called party. draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 8 It should come as no surprise that the suggested format for an RDES message is identical to that of an SDES message. We shall give an example of the use of the RDES message in the appendix. 3.2 RCAP item - receiver capabilities, new item in SDES Until now, I have not yet given a single hint of any signal flow. I have given no model of any kind for control. The next item type seems indeed related to the particular model for signal flows. But in fact it does not really forbid any particular model. The "receiver capabilities" items list the RTP payload types that the particular Receiver is willing to accept. Note once again that I make no assumption whatsoever about how this list is obtained. It may be a list of the coders that the receiver's machine can actually decode, or it may be a subset of that list based on such things as available machine resources, hierarchy within an organization, or the phase of the moon. As far as the needs of signalling go, a potential receiver must be able to send out a list of those RTP payload types that it is willing to receive right now. This list can contain any of the accepted standard RTP payload types, or elements of some other list of payload types agreed upon by non-RTP means. An example of setting up a simple call will be given in the appendix, but it may help to state here that the basic mode of call setup is inspired by the H.245 capabilities exchange of ITU-T standard H.323. Namely, the reciever merely lists the payload types that it is willing to accept, and then the transmitter chooses one of those types for transmission. Note that we can agree that the order of payload types within a list describes the order of preference which the receiver has. Note also that we need no special new item in SDES to describe what is actually being sent. This is done in the payload type of RTP. It might be rather confusing that the RCAP item type is found in the SDES packet, and not in the RDES packet. This is pure logic: an RDES packet is sent in order to identify the *remote* party. But one sends a SDES packet to describe "oneself," and part of this description is what one is willing to tolerate receiving. 3.3 CP item - call progress, new item in SDES The final item that we need to add is one that allows call progress to occur. Call Progress is the feedback that one obtains during the life of a call from the network system. For example, you hear a particular sound after you dial a remote user, and you know that his or her equipment is ringing. The call progress words currently supported by SISP are the following: Ringing, Accept, Busy, NoAnswer, Reject, Pause, Error, Release, Info. draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 9 When the remote party's application is "ringing," it sends an SDES packet with the CP item set to "ringing." The local application receives this and can send the appropriate message ("Drrrrrrrring!") to the local user. These are new items for an SDES packet because we think of the user who is "ringing", or "accepts" a call as describing "himself" in an SDES packet. Unfortunately, this means that even if I am a receiver only, I might send an SDES packet, for example to say that my app is "ringing." This has caused some confusion, even with the author. It is really the "receiver" who is ringing, or busy, or pausing. But it seems to be RTCP convention that an SDES packet is describing "himself". Originally, these call progress items were part of the receiver report. There was no release item, and the BYE packet was used instead. (All this point needs to be clarified). Although the general meaning of each word is clear, there are a few comments to make about some of the CP items: Accept: The application sends an "accept" CP item when it is ready for the other side to start streaming its RTP data. Of course, there are many conference models where this makes no sense. For example, in a loosely defined model, I certainly don't want to wait for an accept message to begin streaming. This is entirely correct. SISP does not *require* that an application send an "accept" message before the remote party begins to stream. Whether or not this is necessary is decided by means totally outside of SISP, and is definitely a part of the conference model being used. This will be decided by a session "announcement" or "description", or some other means. SISP is merely a signaling protocol. SISP claims that RTCP, supplemented with the very few additions here, is rich enough for all Internet Signalling means. One can make a similar comment about every item of type CP (Call Progress). Indeed, we have seen that in the loosest conference model, RTCP suffices (the RTP standard says it does, so this statement is by IETF consensus true). But if one wants to distinguish, for example, between a call that is rejected because there was no answer or because the user made an active choice to reject the call, one can use SISP to do this. We shall see another example of the fact that SISP does not mandate conference policy, but merely allows one to express it, in the appendix. Pause: This SDES item just says that the receiver is stopping recieving "for a while". It is an indication that the receiver has "put you on hold." Note that I did not put a "Resume" item type. When I put you on hold, you really have no way of knowing this in an ordinary call. But one might wish to add the signal. draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 10 Release: On the face of it, this is a totally superfluous item, because there is a BYE packet. It was added so that a receiver can also request or announce that s/he will disconnect. It was also added to allow for some more complicated supplementary services. The idea is that many supplementary services end with a simultaneous release, and an instruction for one party to do something else. For example, in a blind call transfer, where A has called B, and after some time, A would like B to speak to C instead, but doesn't need to inform C about it first (this is the "blind" part of the transfer), then A would send an SDES with a release CP item to B, along with an INFO CP item which said "call C." This last example is one of many many supplementary services. The author has checked that the very simple list here is enough to implement the gamut of supplementary services. Signal flows will be given in the next version of this document. The conclusion of this is that by adding only 3 things to RTCP - one packet type and two new SDES items, it is possible to use RTCP to implement the full range of Signalling needed for Internet Conferencing Applications. 4. Complaints, complaints. With such a scant description of SISP, it would be highly inappropriate to critisize other attempts to provide for internet signalling in detail. We shall try to list general objections to previous solutions. First, signalling should be totally separate from the location service. Of course, a location server may indeed use SISP if that is appropriate. But that would be signalling for the location server call, not for the actual call one wishes to make. SISP begins its function after the location of the remote party has already been decided. Second, the signalling protocol should be allow for any conference model. For example, a protocol which *forces* an application to distinguish "reject" and "no answer" is flawed: the user may not wish to convey the information that s/he rejected an invitation to confer. Certainly there cannot be a requirement for any centralized statekeeper if one wishes to include loosely controlled multicast conferences. Third, there must be the possibilty of dynamic negotiation of capabilities in real-time, via signalling at the time of connection. This is because one may need to reserve machine resources, and one can only do this "at the last minute." draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 11 Fourth, it is important to allow for independent signalling on independent RTP streams. This in itself is a strong motivation for starting with RTCP. Fifth, it is important to be truly scalable, in terms of available bandwidth, number of users in the session, and along the tight-loose control access. This is not an easy problem, and much work has gone into RTCP to this end. Sixth, it is important that the signalling allow for timestamps on signals. Seventh, it is important in some applications that the signalling itself be secure. At the other extreme, for some loosely controlled conferences, it is useful to have "signal monitors" that can "pick up" enough of the required information to join the conference. Eighth, by definition RTCP is everywhere where RTP is. It is far from clear that SMTP, HTTP, etc. will be there. (Imagine very small cheap special purpose communication devices). Ninth, the "global id" problem is quite complicated, and tying down multimedia conferencing to any particular solution of this problem is difficult. In any case, the part of the problem that is location should be treated by a location server, and the part of the global id problem that relates to shared ephemeral state is best treated by the simple CNAME mechanism of RTP. The part of the problem relating to things like dynamic IP or "Integration into Email," for example, is not really a problem that is related to signalling. 5. Reliability of SISP messages The reader may have the impression that the author has somehow forgotten that RTCP is not reliable. Indeed, in trials he has simply used TCP for the RTCP flow. Since the RTCP traffic is really very slight, this has not caused problems, even on slow serial links. (In fact, because of TCP/IP compression, TCP is usually a more effecient choice over a dial up link!). Of course in situations where it is not possible to use TCP, some other means must be used to ensure the reliability of the SISP signalling. draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 12 6. Signal Flows (These must be written up, but I shall give at least one!) 6.1. Of course, the simple open multicast conference is an example of SISP signalling, as is any other conference which relies on some non-RTP means to determine location, and then only RTCP for conference control. But we shall give an example of a simple Internet Telephone Call, using SISP. In the following example A wishes to call B. The precise timings are not given for simplicity, but the packets sent are written in time order. a. A sends B the following RTCP packets, in this order: (RTP is not yet being sent) SDES: identifies the caller. (This is optional) RDES: identifies the callee. The information used in this packet is obtained from some location server or other means. RCAP: identifies the recpetion capabilities of A (remember that if there is more than one RTP stream, then there will be more than one SISP stream as well). b. B receives the three packets, and perhaps it consults with the OS and with some databases. It starts a ringing signal to the user, and sends the following packet to A: SDES: identifies B, and sends the "ringing" CP item c. Perhaps after some consultation with the user, with some databases, and with the operating system, B sends the following RTCP packets, in this order: SDES: identifies B and sends the "accept" CP item d. Upon getting the "accept" message, A knows that it can start streaming. It sends the following packet to B: SDES: identifies A and sends the "accept" CP item And now B knows that it can start streaming as well. draft-petrack-sisp-00.txt Simple Internet Signalling Protocol 13 June 1996 Page 13 Acknowledgements: The author wishes to thank Ed Ellesson of IBM for helpful ideas and advice, encouragement, and tolerance. References [1] H. Shulzrinne, S. Casner, R. Frederick, and S. McCanne, "RTP: A Transport Protocol for real-time applications." RFC 1889 [2] S. Shenker, A. Weinrib, E. Schooler, "Managing Shared Ephemeral Teleconferencing State: Policy and Mechanism." draft-mmusic- ietf-agree-00.ps [3] S. Casner and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links." draft-casner-jacobson-crtp-00.txt [4] S. Petrack, "Compression of Headers in RTP Streams", draft-petrack-crtp-00.txt Author's Location Information Name=Scott Petrack Address=IBM Haifa Research Lab, Haifa 31905, Israel Email=petrack@vnet.ibm.com Telephone=+972 4 829 6290 Fax=+972 4 829 6112 From rem-conf-request@es.net Sun Jun 16 10:50:11 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Sun, 16 Jun 1996 07:49:39 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 16 Jun 1996 15:48:03 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Scott Petrack cc: its@www.raleigh.ibm.com, rem-conf@es.net Subject: Re: SISP - Simple Internet Signalling Protocol In-reply-to: Your message of "Sun, 16 Jun 96 11:06:28 +0700." Date: Sun, 16 Jun 96 15:47:57 +0100 Message-ID: <1556.834936477@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >Appended below is an I-D about SISP, the "simple internet signalling protocol, >which I hope is a useful addition to controlling realtime internet >communication. Hmm, I can see we're going to have some interesting discussions in Montreal :-) I'll just comment on a few points for now, but I do have some serious reservations about this approach... >Internet Engineering Task Force MMusic WG >INTERNET-DRAFT Scott Petrack, IBM >draft-petrack-sisp-00.txt >13 June 1996 Expires: December 1996 > > SISP - Simple Internet Signalling Protocol ... >There are at present two separate groups of applications which >perform conferencing over the Internet. One is the suite of MBONE >tools. These tools have little or no conference control built in. >Separate protocols and tools are used to supply control if it >is desired. This is quite a reasonable approach: after all, >streaming is streaming and control is control. There is a long >list of protocols emerging at present (SIP, SAP, SDP, SCIP, SCCP) >which solve an equally long list of problems (location, >announcement, setup, session description, scheduling, negotiation >of capabilities). The problem is that these protocols have a >large overlap, and in many cases they solve overlapping and >ill-defined problems. I can't really speak for SCIP and SCCP, but SIP, SAP and SDP are designed to be complementory, and don't overlap. SIP and SAP have well defined purposes, and carry SDP. SDP would be well defined if sessions were well defined, but they're not, and we have to live within that ill-defined framework of evolving protocols and session types. .... >One discovers that RTCP is pretty rich already. For example, "by >having each participant send its control packets to all the others, >each can independently observe the number of participants." [1,p.15] >This is certainly some sort of session awareness, of "shared >ephemeral state" in the sense of [2]. > >There is also a great deal of information sent about the sender in >the RTCP SDES packet. Although it is not clear at first why one >needs to know the email of the person to whom you are talking >(I don't know the email address of many of the people I talk to >over the telephone), the fact is that *all* the current suggestions >within MMUSIC seem to think that this is very important. >Luckily for us, then, every RTP stream >is already required to have this information transmitted within >and SDES packet. So applications already have code to transmit this >information. It seems a shame to code it again. I think it's in RTCP as a result of early experience with diagnosing and fixing (or failing to fix) Mbone problems. One of the prices you pay for lightweight sessions if that there may be very little information you have to go on to contact someone who (for example) accidentally hit transmit... It's in SDP because there is (generally) no session in progress at the time the advertisement or invitation carrying the SDP description is sent. Being able to contact the session initiator to warn them of problems (of any sort) before the session starts is necessary at the current stage of evolution of the real-time sessions on the internet. >3.1 RDES - receiver description packet type > >In a tightly coupled conference you clearly need to identify >the person you wish to speak to. Now exactly what "identify" >means is of course an interesting subject. We can say what >we mean quite precisely: It is assumed that the remote >machine receiving the RTCP packets has some means of identifying >the person you wish to contact. It is the duty of a decent >"location service" to provide both the address (IP, port) of the >machine to recieve the real time stream, and hence the RTCP >signalling, as well as the tag/value information needed to >identify the actual remote party. How this location service >works is beyond the scope of the signalling-for-RTP-streams >considered here. In any case, the RDES message should have >exactly the description needed to identify the remote party. This is where I get confused as to what you have in mind, and none of the rest of the draft makes any sense with clearing up some assumptions. Destination addresses and ports for RTP+RTCP are allocated to send multimedia data. You allocate one address and a port-pair for each media session (possibly several session=one conf). Are you suggesting that a *well-known* port is used for RTCP *session setup* information? And then another port-pair is used for the actual RTP/RTCP data? >3.3 CP item - call progress, new item in SDES > >The final item that we need to add is one that allows call >progress to occur. Call Progress is the feedback that one >obtains during the life of a call from the network system. >For example, you hear a particular sound after you dial >a remote user, and you know that his or her equipment is ringing. >The call progress words currently supported by SISP are >the following: Ringing, Accept, Busy, NoAnswer, Reject, >Pause, Error, Release, Info. This section implies you might be thinking of using a well-known port for SISP messages, because otherwise you need to have your session *up-and-running* in order to inform the remote user that you want to start a session. But that makes no sense to me becasue you have no way to bootstrap from your initial session to multiple sessions (ie a *multi* media conference) in SISP. So you can't be thinking of that. That or you need something like SIP to set up the port/receivers in advance, and if you do that you no longer need most of SISP. Just assuming for the moment that you've a cut-down user-location and invitation protocol that simply finds the user and conveys media and port information, and then you use SISP for *each* RTP flow in the conference to initiate that flow. What are the consequences of this... Now you still need to provide the user with feedback in a sensible fashion, and the user doesn't want to be presented with a series of questions such as "incoming call, receive video?" "incoming call, receive audio?", ... So you need to group these in some way. SISP doesn't appear to let you associate flows in any way. Now how about if you want to "invite" someone to join a multi-way multi-media session that you're having. Presumably you'd like to warn them they're just about to appear in a large meeting rather than a private call, so they have to option to reject you. Thus you really need some session description stuff in addition to grouped sessions. If SISP doesn't do these things (and being tied to RTCP, it can't easily), then the process that does initial contact with the user (which sets up the RTP/RTCP receivers) needs to do so to coordinate all this. If that process needs to know about media streams, ports and session descriptions, and needs to coordinate pre-session feedback such as "ringing", then you tend to end up with something that looks remarkably like SIP and SCIP, and most of the functionality in SISP is irrellevant - all we end up with is Accept, Pause and Reject, which might be a good idea anyway (especially Pause), but what's left isn't really signalling. Presumably I must have misunderstood something of what you're proposing. Mark From rem-conf-request@es.net Mon Jun 17 01:23:08 1996 Received: from hplms26.hpl.hp.com by osi-west.es.net with ESnet SMTP (PP); Sun, 16 Jun 1996 22:22:24 -0700 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 AA170718941; Sun, 16 Jun 1996 22:22:21 -0700 Received: by hplabsz.hpl.hp.com (1.37.109.15/15.5+ECS 3.3+HPL1.1) id AA021748949; Sun, 16 Jun 1996 22:22:30 -0700 From: deleon@hplabsz.hpl.hp.com (Laura de Leon) Message-Id: <9606162222.ZM2172@hplabsz.hpl.hp.com> Date: Sun, 16 Jun 1996 22:22:29 -0700 X-Mailer: Z-Mail (3.0.0 15dec93) To: sage-members@usenix.org, rem-conf@es.net Subject: BayLISA: working with cable modems Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 --- Forwarded mail from deleon@hplabsz.hpl.hp.com (Laura de Leon) Received: by hplabsz.hpl.hp.com (1.37.109.15/15.5+ECS 3.3+HPL1.1) id AA020538778; Sun, 16 Jun 1996 22:19:38 -0700 Return-Path: From: deleon@hplabsz.hpl.hp.com (Laura de Leon) Message-Id: <9606162219.ZM2051@hplabsz.hpl.hp.com> Date: Sun, 16 Jun 1996 22:19:38 -0700 X-Mailer: Z-Mail (3.0.0 15dec93) To: baylisa@baylisa.org Subject: BayLISA: working with cable modems Cc: deleon@hplabsz.hpl.hp.com 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 Synopsys Building C in Mountain View, California off Highway 237 at Middlefield. The meetings are also broadcast via MBONE. Schedule -------- June 20: Buck Gee, Com21 Speaking on cable modems The Internet is fast coming into the home, and cable modems are becoming more prevalent. Come hear about the direction the technology is taking. July 18: Bob Cousins, Network General/AIM July 21: BayLISA picnic Please join us at Sunnyvale Baylands Park at 1:00 PM for the annual BayLISA Picnic. Send mail to deleon@hpl.hp.com or blw@baylisa.org for more information. ALSO: Get your BayLISA t-shirt! They're new, They're eye-catching, They're available S to XXXL, The price is $15. [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:/BayLISA/location or you can query the BayLISA mail server by cutting and pasting the following line to your shell: echo "index baylisa" | mail majordomo@baylisa.org BayLISA makes video tapes of the meetings available to members. For more information on available videos, please send email to: video@baylisa.org 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. --- End of forwarded mail from deleon@hplabsz.hpl.hp.com (Laura de Leon) From rem-conf-request@es.net Mon Jun 17 05:29:03 1996 Received: from xr3.atlas.fr by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jun 1996 02:28:13 -0700 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 17 Jun 1996 11:26:44 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Mon, 17 Jun 1996 11:26:44 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Mon, 17 Jun 1996 11:25:57 +0200 X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed; Mon, 17 Jun 1996 14:23:53 +0200 Date: Mon, 17 Jun 1996 14:23:53 +0200 X400-Originator: haignere@issy.cnet.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=FR/;835003530@x400.issy.cnet.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: questions on the Alternate-Recipient: Allowed From: Isabelle HAIGNERE Message-ID: <9606170923.AA00480@haddock> To: rem-conf@es.net Subject: questions on the RTP H263 payload Content-Length: 2397 *-------------------------------------------------------* | From : Isabelle Haignere | | CNET - PAB/STC/SGV | | 38-40 rue du General Leclerc | | F-92 131 Issy les Moulineaux | | FRANCE | | | | Tel. : + 33 1 45 29 40 08 | | Fax. : + 33 1 45 29 52 94 | | | | E-mail : isabelle.haignere@issy.cnet.fr | *-------------------------------------------------------* Hello, I have read the H263 last version of the H263 RTP payload. I have some questions : 1) It is written "the three modes (A, B and C) can be intermixed for one compressed frame; for one compressed frame, PB frame option is on or off, for this reason it is not possible to mix the two B and Cmodes for the same frame. Is it true or do I make a mistake ? 2) There is no identification of what picture number is in the B mode, would it be useful and even mandatory to add such a frame number; u=in the two A and C modes, there are TR and TRB. 3) in the two B and C modes, there are HMV1, VMV1, HMV2., VMV2. I do not understand : let's assume that one uses the option APM : - to know MV of the first block of the MB (upperleft block), we need the MV predictor (HMV1 and VMV1) and the difference and at the decoder side one reconstructs the vector :OK, no problem; - to know MV of the second block of the MB (upper right block), we need the MV predictor (HMV2 and VMV2) and the difference and at the decoder side one reconstructs the vector : OK , no problem. - to know MV of the third block (lower left block), we need the predictor (there may be no known predictor if there is packet loss) , in such a case problem for the vector, - to know MV of the fourth block (lower right block), we need the predictor and the predictor can be reconstructed with information of the current MB : OK , no problem. Am I right or do I make a mistake ? 4) With the A mode, we add delay in the video coding due to GOB storage ? 5) What the packet size at the IP layer depend on ? Who decides about the size ? Can this size vary in the course of time ? Thank you very much Best regards Isabelle HAIGNERE From rem-conf-request@es.net Mon Jun 17 09:47:42 1996 Received: from seawind.bellcore.com by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jun 1996 06:47:10 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id JAA02520; Mon, 17 Jun 1996 09:45:30 -0400 Date: Mon, 17 Jun 1996 09:45:30 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9606170945.ZM2518@seawind.bellcore.com> In-Reply-To: Henning Schulzrinne "Re: Compression of RTP/UDP/IP" (Jun 14, 9:22am) References: <199606141122.HAA27695@thumper.bellcore.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: Henning Schulzrinne , Mikael Degermark Subject: Re: Compression of RTP/UDP/IP Cc: templin@pa.dec.com (Fred Templin), rem-conf@es.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 14, 9:22am, Henning Schulzrinne wrote: > Subject: Re: Compression of RTP/UDP/IP > . > > > > A better (but unfortunately unrealistic) idea is to > > get rid of the Length field in the UDP header as it is > > completely redundant with the length field in the IP header. > > One might also argue that the UDP checksum is not exactly necessary for > A/V delivery as the likelihood of bit errors is low and the effect of a > bit error in many cases less dramatic than a dropped packet. One might argue that, and he would be wrong. If you start doing compression, then accepting an incorrect packet is likely to result in high energy noise, something which is much worse than filling upthe missing packet interval with some appropriate reconstruction. -- Christian Huitema From rem-conf-request@es.net Mon Jun 17 10:33:55 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jun 1996 07:33:17 -0700 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Mon, 17 Jun 1996 16:29:44 +0200 X-Mailer: exmh version 1.6.7 5/3/96 To: huitema@bellcore.com (Christian Huitema) cc: Mikael Degermark , templin@pa.dec.com (Fred Templin), rem-conf@es.net From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: Compression of RTP/UDP/IP In-reply-to: Your message of "Mon, 17 Jun 1996 09:45:30 EDT." <9606170945.ZM2518@seawind.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jun 1996 16:29:35 +0200 Sender: schulzrinne@fokus.gmd.de > On Jun 14, 9:22am, Henning Schulzrinne wrote: > > Subject: Re: Compression of RTP/UDP/IP > > . > > > > > > A better (but unfortunately unrealistic) idea is to > > > get rid of the Length field in the UDP header as it is > > > completely redundant with the length field in the IP header. > > > > One might also argue that the UDP checksum is not exactly necessary for > > A/V delivery as the likelihood of bit errors is low and the effect of a > > bit error in many cases less dramatic than a dropped packet. > > One might argue that, and he would be wrong. If you start doing > compression, then accepting an incorrect packet is likely to result in > high energy noise, something which is much worse than filling upthe > missing packet interval with some appropriate reconstruction. > Depends. It seems that most highly-compressed encodings have enough structure so that the decoder will detect that this is not a valid packet and pitch it. (Decoders need to handle garbage sem-gracefully in any event.) Misdelivered packets will, in almost all cases and with much higher detection probability than the 16-bit UDP checksum, fail the RTP header validity test in any event. If random bit errors are most likely on slow-speed links AND if there's no lower-layer checksum AND your contention is true, all the compressed-IP/UDP/RTP schemes are going to have a problem... If I take Mogul's 1992 TCP (long-distance) numbers, the packet error probability is about 1E-5, one errored packet every about 30 minutes at 50 p/s. I'd be curious if there are any more recent tests for UDP in permanently connected and modem cases. A quick check of my netstat results shows 91 UDP errors for 2527223 UDP packets, which is about the same rate. Strangely enough, IGMP reports 19201 bad checksum in 122267 messages - a 15% rate. This seems rather peculiar. > -- > Christian Huitema Henning From rem-conf-request@es.net Mon Jun 17 13:36:39 1996 Received: from rsung.crn.cogs.susx.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jun 1996 10:36:02 -0700 Received: by rsung.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0uViDn-00020uC; Mon, 17 Jun 96 18:36 BST Message-Id: Date: Mon, 17 Jun 96 18:36 BST From: ianw@cogs.susx.ac.uk (Ian Wakeman) To: Henning Schulzrinne Cc: huitema@bellcore.com (Christian Huitema), Mikael Degermark , templin@pa.dec.com (Fred Templin), rem-conf@es.net Subject: Re: Compression of RTP/UDP/IP In-Reply-To: References: <9606170945.ZM2518@seawind.bellcore.com> >>>>> "Henning" == Henning Schulzrinne writes: Christian writes out of Bellcore >> One might argue that, and he would be wrong. If you start doing >> compression, then accepting an incorrect packet is likely to >> result in high energy noise, something which is much worse than >> filling upthe missing packet interval with some appropriate >> reconstruction. >> Henning> Depends. It seems that most highly-compressed encodings Henning> have enough structure so that the decoder will detect Henning> that this is not a valid packet and pitch it. Surely some mistake - high compression and retention of structure seem incompatible to me. Henning> (Decoders Henning> need to handle garbage sem-gracefully in any event.) Garbage is actually extremely difficult to detect without remembering lots of state. I seem to recall that the RTPv2 spec had to go through a number of hoops based on receiving consecutive SSRCs to validate packets. Henning> Misdelivered packets will, in almost all cases and with Henning> much higher detection probability than the 16-bit UDP Henning> checksum, fail the RTP header validity test in any Henning> event. If random bit errors are most likely on slow-speed Henning> links AND if there's no lower-layer checksum AND your Henning> contention is true, all the compressed-IP/UDP/RTP schemes Henning> are going to have a problem... Umm, no. And yes, they are going to have problems. That's what happens when you remove redundancy - the solution is to only use header compression when there is low level checksums or to keep high level checksums. cheers ian From rem-conf-request@es.net Mon Jun 17 16:51:43 1996 Received: from PRIDE-I2.POLY.EDU by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jun 1996 13:51:08 -0700 Received: by PRIDE-I2.POLY.EDU (940816.SGI.8.6.9/940406.SGI.AUTO) id QAA17101; Mon, 17 Jun 1996 16:45:52 -0400 Date: Mon, 17 Jun 1996 16:45:42 +30000 From: Farzad Haghi To: WOSBIS@PRIDE-I2.POLY.EDU Subject: Internet Realtime Conference and Internet CoursewareDear Colleagues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear Colleagues: The academic semester should be over for most schools. It is time to do a serious paper call and conference organizing. The Global Information and Software Society (GISSIC96) will hold its second annual Internet Realtime Conference on October 21 to 25 world wide via WWW and Internet. A suggestion to have a poster session has been accepted by the committee. A poster session cyberspace is being designed and implemented with VRML, ie a virtual reality Poster Session. Although some people may have difficulty running the VRML software on their workstation, the committee felt that the graphical representation of a poster session will add more realism to the session. It will be treated as an innovative experiement in GISSIC96. Of course, without the VR, the poster papers can still be accessed via HTML files. The theme of GISSIC96 (Information Sharing) and its details (technical domains: Distanceless Learning,Telemedicine, Multimedia Creation Technology and Application, Image and Video Processing and Application, Internet Technology and Application, etc.) of call for paper can be accessed by http//quasar.poly.edu:80/~llin/GISS/gissic96call. Please note that you must submit paper and register on-line (by Internet). The important datesto be remembered are 1. Conference dates October 21st to 25th, 1996,Keynoter Vinton Cerf, VP MCI. 2. paper submission deadline 7/14, 1996. 3. Panel session complete proposal deadline 8/1, 1996 4. There are three types of papers in addition to keynote papers: i. Invited paper, paper invited by the organizing committee ii. Papers submitted and reviewed by the committee members which are organized by topic sessions. Each session will have a session chairperson to moderate the Q&A for each paper. iii. Poster papers are papers submitted that either do not fit into an organized session or by author's own request to be a poster paper (for example, a student paper wish to be less formal). 5. For those who have not attended last year's conference (http://quasar.poly.edu/~llin/GISS/gissic95proceedings), the location of the conference is at your most favorite spot, office, home, or on the road. There will be a set of tools made available to GISSIC96 attendees to make conference communication more realistic and effective. The concept, user interface and maintanence of these tools will be kindly licensed to GISSIC96 to use by PRIDE, Polytechnic University. These tools have been developed for PRIDE's Internet Informatics course offered via Internet (http://PRIDE-i2.poly.edu/I-CARE) from 7/15-8/14/1996. We recommend highly that you browse their public descriptions to get familiar with these tools. The course is a certificate program featuring a new pedagogy emphasizing hyperlearning and group teaching and learning methodology. Please send any suggestions or comments related to GISSIC96to Ifay@pride-i2.poly.edu. Sincerely Yours, Ifay Chang, Professor of CIS, Polytechnic University GISSIC96 Steering Committee Chair From rem-conf-request@es.net Mon Jun 17 19:46:38 1996 Received: from IETF.cnri.reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jun 1996 13:32:54 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa25033; 17 Jun 96 14:21 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; cc: rem-conf@es.net From: Internet-Drafts@CNRI.Reston.VA.US Reply-to: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-ietf-avt-rtp-payload-01.txt Date: Mon, 17 Jun 96 14:21:12 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9606171421.aa25033@IETF.CNRI.Reston.VA.US> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP Payload Format for H.263 Video Stream Author(s) : C. Zhu Filename : draft-ietf-avt-rtp-payload-01.txt Pages : 10 Date : 06/14/1996 This document specifies the RTP payload format for encapsulating H.263 bitstreams in the Real-Time Transport Protocol (RTP). The H.263 payload header is designed for flexibility and simplicity. RTP can use one of three possible modes for H.263 video streams depending on the desired performance characteristics. The shortest header mode (Mode A) results in simplicity and easy recovery from lost packets, brought about by fragmentation at Group of Block (GOB) boundaries. The long header modes (Mode B and C) result in more efficient use of bandwidth, brought about by fragmentation at Macroblock (MB) boundaries. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rtp-payload-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-rtp-payload-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-avt-rtp-payload-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960614145853.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-rtp-payload-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-rtp-payload-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960614145853.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Jun 18 00:27:04 1996 Received: from mail2.digital.com by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jun 1996 21:26:26 -0700 Received: from zkons1.zko.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA25661; Mon, 17 Jun 1996 21:22:05 -0700 Received: from mmsrv by zkons1.zko.dec.com; (5.65/1.1.8.2/28Oct95-0953AM) id AA15603; Tue, 18 Jun 1996 00:21:56 -0400 Received: by mmsrv.zko.dec.com; id AA31666; Tue, 18 Jun 1996 00:20:55 -0400 Received: from localhost by voile.zko.dec.com; (5.65v3.2/1.1.8.2/03Jun95-0317AM) id AA01726; Tue, 18 Jun 1996 00:20:32 -0400 Sender: morris@mmsrv.zko.dec.com Message-Id: <31C62E8F.3F54@zko.dec.com> Date: Tue, 18 Jun 1996 00:20:31 -0400 From: Tom Morris Organization: Digital Equipment Corp. X-Mailer: Mozilla 2.02 (X11; I; OSF1 V3.2 alpha) Mime-Version: 1.0 To: Kathy Lynn Hewitt Cc: rem-conf@es.net Subject: Re: VIC and DEC Alpha References: <9606131412.ZM7103@eos.ncsu.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kathy, There are two different types of systems using the Alpha processor, each with its own set of multimedia options. The older DEC 3000 Turbochannel machines have built-in 8 KHz audio and you can add the Sound & Motion J300 card (AV300) to get video capture in Motion JPEG and uncompressed formats, video output, and CD quality stereo audio recording and playback. The newer AlphaStation line is based around the PCI bus and has CD quality stereo audio bundled. Video capture is available by using any of the following three options: AV201 FullVideo Basic AV301 FullVideo Supreme AV321 FullVideo Supreme JPEG The currently available versions of vic and vat require the use of experimental software from Digital's Research group (jvdriver & AF, respectively) which only supports a subset of the above devices, but we are currently testing versions of both which use the Multimedia Services for their multimedia I/O which will allow access to the full range of supported devices as well as easing some of the currently interoperability problems between MMS applications and the MBONE tools. We've sent the source changes off to the authors and hope to see them included in the next release. For anyone who's interested in testing this before the next public beta release, we'll probably try to make the programs available more widely after we've had more internal testing experience. As far as choosing among the various video capture boards goes, any of them will do if you are going to use one of the sofware compression schemes like nv or CellB, but you can save a significant amount of CPU time at the sender by using one of the Motion JPEG cards (AV300 or AV321) if you are sending JPEG or H.261 (with transcoding from JPEG). --------------------------------------------------------------------------- Tom Morris Digital Equipment Corporation morris@zko.dec.com 110 Spit Brook Road ZKO1-1/E37 +1 603 881 0894 Nashua, NH, 03062 USA From rem-conf-request@es.net Tue Jun 18 00:53:22 1996 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Mon, 17 Jun 1996 21:52:55 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id VAA09298; Mon, 17 Jun 1996 21:53:29 -0700 Message-Id: <199606180453.VAA09298@rx7.ee.lbl.gov> To: rem-conf@es.net Subject: Re: Compression of RTP/UDP/IP In-reply-to: Your message of Mon, 17 Jun 96 18:36:00 A. Date: Mon, 17 Jun 96 21:53:28 PDT From: Van Jacobson Friends, I've enjoyed reading the exchange prompted by Henning's uninformed & incorrect comments on UDP checksums and the nature of A/V data (particularly Ian Wakeman's cogent reply) but should point out that the compression we propose is lossless so checksums are strictly an end-node sending issue: if the sender doesn't use udp checksums, they take *no* bits in the compressed header. If it sends them, they go through unmodified. (My personnal belief is that all senders should use checksums but that's a debate that has little to do with compression.) I might also note that Henning's blathering on the strength of udp checksums in this context was completely wrong. The UDP checksum is *very* strong for detecting a likely class of fairly harmful decompression errors. Interested parties should read section 4.1 of RFC1144. - Van From rem-conf-request@es.net Tue Jun 18 09:57:04 1996 Received: from elaine.crcg.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jun 1996 06:56:33 -0700 Received: by elaine.crcg.edu (4.1/SMI-4.1) id AA02334; Tue, 18 Jun 96 08:56:32 EST Date: Tue, 18 Jun 1996 09:56:27 -0400 (EDT) From: Mike Macedonia X-Sender: mmacedon@elaine To: Theresa-Marie Rhyne Cc: brutzman@cs.nps.navy.mil, rem-conf@es.net Subject: computer graphics and networking In-Reply-To: <9606180730.ZM18210@norton.rtpnc.epa.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We need to establish a dialog between the SIGGRAPH and SIGCOMM communities. How is yet to be determined. Networking *and* computer graphics have an important and evolving relationship. It is more than just VRML or teleconferencing and more than just writing technical standards. They are both technological areas that are driving each other forward in many areas. Unfortunately, there are alot of folks in both fields who just don't get it yet. If anyone from either community is interested in participating in this effort, please let us know. - Mike ----------------------------------------------------------------- | Michael R. Macedonia, Ph.D. | URL: http://www.crcg.edu | | Vice President | EMAIL: mmacedon@crcg.edu | | Fraunhofer CRCG | | | 167 Angell Street | PH : (+1) 401 453-6363 | | Providence, RI 02906 | FAX: (+1) 401 453-0444 | ----------------------------------------------------------------- On Tue, 18 Jun 1996, Theresa-Marie Rhyne wrote: > Okay Don and Mike: > > > Apparently SIGGRAPH hits roadblocks when it tries to do > "standards" type things... that is really an ACM thing... > it least that is what I've gathered from a very quick > study... > > Now...I'm going to need some "grass roots" momentum to make > this stuff happen... remember SIGGRAPH has been doing > important things like education / bringing on board artists / > public policy... and to ask the Executive types to really > think about pushing technical stuff (although it seems rather > obvious) is sort of a challenge ... the question is what > kinds of tools do the Executive types have to make things > happen....so my note below tries to list a few.... > > I could also use any in roads into SIGCOMM....... who with SIGCOMM > might be interested in examining the interrelationship between graphics > and networking issues ?? > > Smiles.... Theresa-Marie > > > From rem-conf-request@es.net Tue Jun 18 13:10:33 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jun 1996 10:09:52 -0700 Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.7.4/8.7.3) with SMTP id KAA07317; Tue, 18 Jun 1996 10:09:50 -0700 (PDT) Received: from shark.jfsv01 by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0uW4JT-000RVhC; Tue, 18 Jun 96 10:11 PDT Message-ID: <31C6E2DC.557E@ibeam.intel.com> Date: Tue, 18 Jun 1996 10:09:48 -0700 From: Chunrong Zhu Organization: Intel Corp. X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: Isabelle HAIGNERE CC: rem-conf@es.net Subject: Re: questions on the RTP H263 payload References: <9606170923.AA00480@haddock> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Isabelle, Please see my comments below as I answer your questions related to RTP H263 payload spec. --Chad Isabelle HAIGNERE wrote: > > *-------------------------------------------------------* > | From : Isabelle Haignere | > | CNET - PAB/STC/SGV | > | 38-40 rue du General Leclerc | > | F-92 131 Issy les Moulineaux | > | FRANCE | > | | > | Tel. : + 33 1 45 29 40 08 | > | Fax. : + 33 1 45 29 52 94 | > | | > | E-mail : isabelle.haignere@issy.cnet.fr | > *-------------------------------------------------------* > > Hello, > > I have read the H263 last version of the H263 RTP payload. > I have some questions : > 1) It is written "the three modes (A, B and C) can be intermixed > for one compressed frame; for one compressed frame, PB frame option is > on or off, for this reason it is not possible to mix the two B and Cmodes > for the same frame. Is it true or do I make a mistake ? You are right that for one frame, you will not get packets from Mode B and C at the same time. But you could get packets from Mode A and Mode B (or Moda A and Mode C when PB is on). What I meant was that you can intermix packets with different modes IF POSSIBLE. YOU DO NOT HAVE TO. I will add a sentence to make that clear. > 2) There is no identification of what picture number is in the B mode, > would it be useful and even mandatory to add such a frame number; > u=in the two A and C modes, there are TR and TRB. The reason TR and TRB are included in the header for Mode A and C was that they are used to calculate motion vectors for B frame when PB is on. For Mode C, they are critical information to decode motion vectors. They are used only if the first packet for the current frame is lost. Besides, Mode A has bits available in the header. For Mode B, picture number in the header is not useful when the first packet is not lost. When TR is lost with the first packet for the current frame, picture number is useful, but might not be so much better than guessing it. Because most codecs select evenly spaced frames to code. Even if this is not true and we guessed wrong, the end result is that the frame is presented slightly late or early than it should be, but it does not effect other frame and more importantly, there would not be any visiable degradation. So I am not convinced it is "mendatory" to have picture number in the header as another overhead. Keep in mind, we would also want to keep the header as small as possible. > 3) in the two B and C modes, there are HMV1, VMV1, HMV2., VMV2. > I do not understand : > let's assume that one uses the option APM : > - to know MV of the first block of the MB (upperleft block), we need > the MV predictor (HMV1 and VMV1) and the difference and at the decoder > side one reconstructs the vector :OK, no problem; > - to know MV of the second block of the MB (upper right block), we need > the MV predictor (HMV2 and VMV2) and the difference and at the decoder > side one reconstructs the vector : OK , no problem. > - to know MV of the third block (lower left block), we need the > predictor (there may be no known predictor if there is packet loss) , > in such a case problem for the vector,HMV2 and VMV2 are defined as MV1 for block 3. They are not used for block 2 because GOB header is present. I understand why you are confused, please read my document and H.263 spec again. If it is still not clear, give me a call. > - to know MV of the fourth block (lower right block), we need the > predictor and the predictor can be reconstructed with information > of the current MB : OK , no problem. > Am I right or do I make a mistake ? > 4) With the A mode, we add delay in the video coding due to GOB storage ?I am not clear what you mean by GOB storage. > 5) What the packet size at the IP layer depend on ? Who decides > about the size ? Can this size vary in the course of time ? > > Thank you very much > > Best regards > > Isabelle HAIGNERE From rem-conf-request@es.net Tue Jun 18 14:10:17 1996 Received: from anduin.ocf.llnl.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jun 1996 11:09:30 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by anduin.ocf.llnl.gov (4.1/SMI-4.0) id AA23875; Tue, 18 Jun 96 11:09:26 PDT X-Sender: jed@anduin.ocf.llnl.gov Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jun 1996 11:09:30 -0800 To: Mike Macedonia From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: computer graphics and networking Cc: rem-conf@es.net >We need to establish a dialog between the SIGGRAPH and SIGCOMM >communities. Additional dialog? Why? >Networking *and* computer graphics have an important and evolving >relationship. It is more than just VRML or teleconferencing and more than >just writing technical standards. They are both technological areas that >are driving each other forward in many areas. It is certainly true that expanding communication opportunities are enabling expanded communication of computer graphics. It is also true that expanded computer graphics capabilities are providing content that is motivating additional expansion of communications. One could point to similar mutually supportive roles with the computing and/or storage disciplines. Expansion of capabilities in all of these areas are providing support for further developments. What is it that you see is particularly lacking in the dialog between the communication and graphics communities. >Unfortunately, there are alot of folks in both fields who just don't >get it yet. I find myself among them. It would help me if you would further explain the need you see for more dialog. I certainly see some areas of common interest - e.g. compression techniques specific to graphics semantics (e.g. jpeg or mpeg). I also believe that graphics and communications (and storage and computing) are important and continuing to grow in importance. However, I see these disciplines as quite distinct. I personally see value in the distinctions and prefer to keep from blurring them together any more than is necessary to support the areas of common interest. At this time I don't see a need for a substantial change in this area. >If anyone from either community is interested in participating in this >effort, please let us know. Sorry to rain on your parade. I will be happy to be shown the error of my ways. It would seem to me that it would help if you would send to this mail list at least a pointer to a description of the need you see for more dialog and/or more interdisciplinary working between these two areas. --Jed http://www-atp.llnl.gov/atp/jed-signature.html From rem-conf-request@es.net Tue Jun 18 15:07:21 1996 Received: from CNRI.Reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jun 1996 12:06:08 -0700 Received: from mac-53.cnri.reston.va.us by CNRI.Reston.VA.US id aa17961; 18 Jun 96 15:01 EDT X-Sender: mbeaulie@newcnri.cnri.reston.va.us Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jun 1996 15:01:51 -0500 To: rem-conf@es.net From: Marcia Beaulieu Subject: Multicast Guide for the 36th IETF - Montreal, Canada Cc: scoya@CNRI.Reston.VA.US MULTICAST GUIDE Note that times are in US Eastern Time (ET). UTC (aka GMT) also provided. MONDAY 0900-0930 0930-1130 1300-1500 1530-1730 1930-2200 (UTC) 1300-1330 1330-1530 1700-1900 1930-2130 2330-0200 ==========+=============+=============+==========+=============+============+ CHAN 1 |intro plenary| issll | ion | mmusic | ipngwg | ==========+=============+=============+==========+=============+============+ CHAN 2 | " | rps | mboned | applmib | rsvp | ==========+=============+=============+==========+=============+============+ TUESDAY 0900-1130 1300-1500 1530-1730 (UTC) 1300-1530 1700-1900 1930-2130 ==========+=============+=============+==========+ CHAN 1 | ipngwg | ion | ion | ==========+=============+=============+==========+ CHAN 2 | rps | avt | avt | ==========+=============+=============+==========+ WEDNESDAY 0900-1130 1300-1500 1530-1730 1930-2200 (UTC) 1300-1530 1700-1900 1930-2130 2330-0200 ==========+=============+=============+==========+=============+ CHAN 1 | ipngwg | mobileip | intserv | iab | ==========+=============+=============+==========+=============+ CHAN 2 | mmusic | rsvp | idmr | applmib | ==========+=============+=============+==========+=============+ THURSDAY 0900-1130 1300-1500 1530-1630 1630-1830 (UTC) 1300-1530 1700-1900 1930-2030 2030-2230 ==========+=============+=============+==============+============+ CHAN 1 | otsv | mobileip |tech. plenary |open plenary| ==========+=============+=============+==============+============+ CHAN 2 | nmarea | idmr | " | " | ==========+=============+=============+==============+============+ There will be no multicasting of sessions on Friday, June 28, 1996. Advice for remote participants: Please keep your microphones muted and your video transmissions disabled during the plenaries and working group sessions, unless or until invited to respond by the chair of the session. Vat users can disable reception of accidental sources of audio multicasts (such as people who forget to mute their mics) by clicking in the box next to that source's name. From rem-conf-request@es.net Tue Jun 18 15:17:17 1996 Received: from CNRI.Reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jun 1996 12:16:30 -0700 Received: from mac-53.cnri.reston.va.us by CNRI.Reston.VA.US id aa18298; 18 Jun 96 15:15 EDT X-Sender: mbeaulie@newcnri.cnri.reston.va.us Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jun 1996 15:15:57 -0500 To: rem-conf@es.net From: Marcia Beaulieu Subject: Updated Multicast Guide for the 36th IETF - Montreal, Canada Cc: scoya@CNRI.Reston.VA.US A change has been made in the Monday schedule, the Intro. Plenary will not be multicast. MULTICAST GUIDE Note that times are in US Eastern Time (ET). UTC (aka GMT) also provided. MONDAY 0930-1130 1300-1500 1530-1730 1930-2200 (UTC) 1330-1530 1700-1900 1930-2130 2330-0200 ==========+=============+==========+=============+============+ CHAN 1 | issll | ion | mmusic | ipngwg | ==========+=============+==========+=============+============+ CHAN 2 | rps | mboned | applmib | rsvp | ==========+=============+==========+=============+============+ TUESDAY 0900-1130 1300-1500 1530-1730 (UTC) 1300-1530 1700-1900 1930-2130 ==========+=============+=============+==========+ CHAN 1 | ipngwg | ion | ion | ==========+=============+=============+==========+ CHAN 2 | rps | avt | avt | ==========+=============+=============+==========+ WEDNESDAY 0900-1130 1300-1500 1530-1730 1930-2200 (UTC) 1300-1530 1700-1900 1930-2130 2330-0200 ==========+=============+=============+==========+=============+ CHAN 1 | ipngwg | mobileip | intserv | iab | ==========+=============+=============+==========+=============+ CHAN 2 | mmusic | rsvp | idmr | applmib | ==========+=============+=============+==========+=============+ THURSDAY 0900-1130 1300-1500 1530-1630 1630-1830 (UTC) 1300-1530 1700-1900 1930-2030 2030-2230 ==========+=============+=============+==============+============+ CHAN 1 | otsv | mobileip |tech. plenary |open plenary| ==========+=============+=============+==============+============+ CHAN 2 | nmarea | idmr | " | " | ==========+=============+=============+==============+============+ There will be no multicasting of sessions on Friday, June 28, 1996. Because the Conference Center closes at 11:00, there will be no rebroadcast of sessions. Advice for remote participants: Please keep your microphones muted and your video transmissions disabled during the plenaries and working group sessions, unless or until invited to respond by the chair of the session. Vat users can disable reception of accidental sources of audio multicasts (such as people who forget to mute their mics) by clicking in the box next to that source's name. From rem-conf-request@es.net Tue Jun 18 15:23:07 1996 Received: from my28.sm.luth.se by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jun 1996 12:22:23 -0700 Received: from my8.sm.luth.se (my8.sm.luth.se [130.240.3.38]) by my28.sm.luth.se (8.7.5/8.7.2) with ESMTP id VAA03396; Tue, 18 Jun 1996 21:22:02 +0200 Received: from localhost (micke@localhost) by my8.sm.luth.se (8.6.11/8.6.11) with SMTP id VAA27099; Tue, 18 Jun 1996 21:25:12 +0200 Message-Id: <199606181925.VAA27099@my8.sm.luth.se> X-Mailer: exmh version 1.6.6 3/24/96 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Stephen Casner Cc: steve@sics.se, bcn@cdt.luth.se, engan@cdt.luth.se, rem-conf@es.net Subject: CONTEXT_ERROR Date: Tue, 18 Jun 1996 21:25:11 +0200 From: Mikael Degermark Steve, In the context :-) of the CONTEXT_ERROR indication mentioned in your draft I have the following suggestions: 1. In the draft you propose a link-layer indication CONTEXT_ERROR. For efficient use of the protocol or packet type identifier space I propose that we define a common format for such messages so that it is possible to use the same protocol-type and format for IPv6 header compression and other compression schemes. The message would then start with a byte saying what the context error is for, be it Casner-Jacobson IP/UDP/RTP header compression, IPv6 header compression, or something else. The values of that byte should be given out by the IANA and can include 0 reserved 1 casner-jacobson IP/UDP/RTP header compression 3 IPv6 TCP 4 IPv6 non-TCP 5 IPv6 RTP -------- 2. In your draft your main proposal is not to have CONTEXT_ERROR packets carry any information, which implies that all context information (compression state) must be invalidated when receiving such messages. This can have a bad impact on performance over lossy links such as wireless. Over such links it seems preferrable to have the context on each packet and separately invalidate contexts. You also have an alternative where the C-bit is eliminated and the whole one-byte context is always present. Then it is possible to separately invalidate contexts by supplying outdated contexts in CONTEXT_ERROR packets. The loss properties of the link determines which choice is better. Therefore I propose that it should be negotiated on a per-link basis whether the context should be sent on each packet and the sequence number be per context, or if the C-bit can be used and the sequence number is for all contexts. The default when there is no negotiation should be to not use the C-bit. Comments? Mikael Degermark From rem-conf-request@es.net Tue Jun 18 16:15:16 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jun 1996 13:14:10 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA28077; Tue, 18 Jun 1996 13:13:18 -0700 Date: Tue, 18 Jun 1996 13:13:16 -0700 (PDT) From: Stephen Casner To: Mikael Degermark Cc: steve@sics.se, bcn@cdt.luth.se, engan@cdt.luth.se, rem-conf@es.net Subject: Re: CONTEXT_ERROR In-Reply-To: <199606181925.VAA27099@my8.sm.luth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mikael, There is a design tradeoff between: A: C-bit compression to get to 1 byte minimum length global sequence number CONTEXT_ERROR contains no other info B: Context byte always sent (2 bytes minimum length) sequence number per context CONTEXT_ERROR contains a list of errored contexts Right now our draft chooses A, but B might be the better choice. Van commented to me in email today also that this choice should be reconsidered. He said that if he had TCP/IP compression to do over again, he would eliminate the C-bit compression. Because we should try to keep simplicity as a strong goal in addition to these others, we should probably make this choice in the protocol spec and avoid trying to negotiate it at runtime. I have no objection to expanding the utility of the CONTEXT_ERROR packet type for use with protocols other than IP/UDP/RTP. I note that you managed to squeeze the one bit you needed for TCP into the existing packet version field. But if a CONTEXT_ERROR type is defined, then it could be used instead. > 0 reserved > 1 casner-jacobson IP/UDP/RTP header compression > 3 IPv6 TCP > 4 IPv6 non-TCP > 5 IPv6 RTP What happened to 2? -- Steve From rem-conf-request@es.net Tue Jun 18 16:49:28 1996 Received: from my28.sm.luth.se by osi-west.es.net with ESnet SMTP (PP); Tue, 18 Jun 1996 13:47:12 -0700 Received: from my8.sm.luth.se (my8.sm.luth.se [130.240.3.38]) by my28.sm.luth.se (8.7.5/8.7.2) with ESMTP id WAA04743 for ; Tue, 18 Jun 1996 22:46:46 +0200 Received: from localhost (micke@localhost) by my8.sm.luth.se (8.6.11/8.6.11) with SMTP id WAA27820 for ; Tue, 18 Jun 1996 22:49:57 +0200 Resent-Message-Id: <199606182049.WAA27820@my8.sm.luth.se> Message-Id: <199606182049.WAA27820@my8.sm.luth.se> X-Mailer: exmh version 1.6.6 3/24/96 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Stephen Casner Cc: steve@sics.se, bcn@cdt.luth.se, engan@cdt.luth.se, rem-conf@es.ne Subject: Re: CONTEXT_ERROR In-reply-to: Your message of Tue, 18 Jun 1996 13:13:16 PDT. Date: Tue, 18 Jun 1996 22:46:54 +0200 From: Mikael Degermark Resent-To: rem-conf@es.net Resent-Date: Tue, 18 Jun 1996 22:49:56 +0200 Resent-From: Mikael Degermark Steve, > Right now our draft chooses A, but B might be the better choice. Van > commented to me in email today also that this choice should be > reconsidered. He said that if he had TCP/IP compression to do over > again, he would eliminate the C-bit compression. > > Because we should try to keep simplicity as a strong goal in addition > to these others, we should probably make this choice in the protocol > spec and avoid trying to negotiate it at runtime. I agree. Very good. > I have no objection to expanding the utility of the CONTEXT_ERROR > packet type for use with protocols other than IP/UDP/RTP. I note that > you managed to squeeze the one bit you needed for TCP into the > existing packet version field. But if a CONTEXT_ERROR type is > defined, then it could be used instead. You read my mind :-) When it is easy to identify the compressor (as it is when PPP is used), CONTEXT_ERROR is the way to go. This will be covered in a coming draft on IPv6 header compression over PPP. > What happened to 2? A mistake :-( The list should be 0 reserved 1 casner-jacobson IP/UDP/RTP header compression 2 IPv6 TCP 3 IPv6 non-TCP 4 IPv6 UDP/RTP I suggest the convention that if no CID (or context in your terminology) is present in a CONTEXT_ERROR message, it means that all compression state is invalidated. Mikael Degermark From rem-conf-request@es.net Wed Jun 19 03:44:35 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jun 1996 00:43:54 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA29230; Wed, 19 Jun 1996 00:43:48 -0700 Date: Wed, 19 Jun 1996 00:43:48 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: RTP profile for professional audio/video Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The following draft was sent to me as AVT WG chair. I forwarded it to be posted as an Internet-Draft, but apparently not in time. Although the author will not be at the Montreal meeting, I will ask for comments there. I think there are several potentially controversial points. Please give the draft a look. -- Steve ---------- Forwarded message ---------- Date: Thu, 13 Jun 1996 17:29:20 +0100 From: Neil Harris To: Stephen Casner Cc: Cosmos Nicolaou Subject: Re: Draft profile document Dear Stephen, Here is the latest version, with a boiler-plate attached. I'm not sure it's up to an acceptable standard, but at least it can be used to provoke some discussion. I can already think of several things wrong with it, but I guess that's what Internet-Drafts are for. -- Neil Internet Engineering Task Force Audio-Video Transport Working Group Internet Draft Neil Harris xxxxxx.txt Sohonet Limited June 13, 1996 Expires: xxxxxx A Professional Profile for Audio and Video over RTP? 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 note discusses a proposed embedding for uncompressed video and audio within an RTP stream. Whilst this is not a finished document, and although it was not written with wider distribution in mind, I think it may be useful as a 'straw man' proposal to provoke further discussion of the use of RTP for professional media. 1. Rationale At the time of writing [early 1996] professional audio and video production is undergoing a fundamental change, from dedicated hardware processing and dedicated digital transports, to computer-based processing and general-purpose network transports. Digital data compression will undoubtedly be the dominant format in domestic and broadcast media delivery, due to its advantages in terms of high performance and low bandwidth, combined with high perceived quality. However, for the origination of material, data compression is not an ideal technology. Firstly, compression of material generates artifacts which can accumulate over multiple generations of processing. Secondly, compressed media are not in a suitable fo rm for processing: they typically have to be decompressed, either in hardware or software, processed, and re-compressed again. Data compression is currently popular because it has allowed late-1980's technology to process pictures at near-professional quality. However, for these professional applications, network technologies are now available which can meet the bandwidth needs of current professional production, and beyond. In the next two years, these technologies will move from being relatively expensive to being relatively inexpensive. With the widespread availability of wideband I/O busses, and 500 MHz processors and beyond, processing uncompressed images on standard wo rkstations will become a commonplace. In fact, working with compressed images may well represent an overall increase in complexity and use of system resources. At the same time, research into new and better compression methods and improved picture and sound transducers continues. Any attempt to create a new standard around an existing compression method will fix the bandwidth and computation compromises of present-day technology into professional media for the life of that standard. This will have detrimental effects on programmes made using these standards: in five, ten or twenty years, the effects of their compression artifacts and compromises will stand out as clearly as 1970's colour-camera artifacts and composite-video standards do today. In contrast, material originated on film continues to preserve its value, as it was based on the best technology of its day, and continues to evolve to this day. But, note that the sprocket holes and film gauges are unchanged from the 1930's. This has not stopped film-makers from using a large number of frame formats, aspect ratios and types of stock and processing over that period to create their artistic effects. Adopting a poor standard in order to replace it later will have adverse effects on the growth of the professional media industry: it would seem reasonable that a standard designed in 1996 should be targeted for the inexpensive hardware of 1997-8, rather t han the special-purpose hardware of 1996. Such a standard can be adopted today for high-end systems, with either high-performance computing resources or hardware acceleration, with low-end systems following early next year. The adoption of a lossless standard for interworking should not unfairly disadvantage compression-based systems. These compression-based systems should be able to compress and decompress material in real-time in order to work at all: exchanging video and audio over the network in an uncompressed form should not compromise their internal workings in their proprietary compressed internal formats and protocols. Good standards already exist for professional media, in the form of CCIR 601 video and AES/EBU audio, together with EBU/SMPTE timecode. These formats are vendor-neutral, and have already allowed for the explosive growth of the video and audio industries. Any new standard should provide for all the capabilities of these existing standards, whilst providing for future expansion to full uniform sampling, RGB colour space, and higher tonal depths and resolutions. The mapping to the underlying network layer should be as simple as possible, without loss of generality or connectivity. Such a standard already exists. The IETF has established a draft standard for transport of real-time data over networks: RTP. 2. RTP: The Internet Real-Time Protocol RTP provides a means of transmitting time stamped, sequence-numbered packets with information relating to synchronisation source and contribution entities. Whilst RTP is currently used for low-bandwidth video- and audio-conferencing over networks, it can naturally be extended to high-bandwidth media, such as professional audio and video. To do this, we need to define a profile that describes how digital video or audio fits into the stream of packets defined by RTP. Note that RTP does not provide any means for error-correction or retries. However, it does allow for error-detection based on packets being dropped by the lower-level transport, which is typically is equipped with CRC error detection. We assume that the underlying transport is already fast and reliable, and that any further error detection or correction is only there to make an already reliable system even more reliable. 3. Goals for a professional media RTP profile The professional media profile should be: non-proprietary: in the public domain, not owned by any company: this allows for the development of multiple compatible implementations, without 'turf wars'. based on existing standards, wherever possible: there is no need to re-invent existing standards for colourimetry, sampling, time-coding and so forth architecture-neutral: not dependent on any hardware or software architecture features of current computers; in particular, it should be designed for efficiency in both hardware and software implementations. transport-neutral: independent of the underlying transport architecture and protocols, whether ATM, HIPPI, Fibre Channel, SMDS or other; whether IP-based or hardware layer based, whether connection-oriented or connectionless. scalable: to higher frame rates, bit-depths, resolutions and large associations of sources and destinations, without need for re-writing of software or re-design of hardware. extensible: to accommodate new features, without breaking existing implementations compatible with existing professional video and audio formats designed explicitly for professional use: not competing with other profiles or standards such as MPEG, JPEG, DAVIC provide support for precise synchronisation: a need greatly overlooked in non-professional media. provide support for variable picture formats and sampling rates provide support for varispeed and frame skipping provide optional support for forward error correction provide support for infra-black and super-white values: these allow for better matting, colour gamut and resampling behaviour in extreme conditions provide support for labelling of image streams: this includes timecode, ARRI code, Aaton code, Keykode and other formats, as well as shot/scene and other information. not rely on or exclude the use of data compression limited in ambition: there is no attempt to define a standard for consumer media, or for medical imaging, pre-press, astronomy, or multi spectral satellite imagery. The professional media profile should not: attempt to enforce ones-density: this is a network hardware layer function attempt to provide channel coding, such as 8-to-10 bit coding: this is a function of the network hardware layer. code horizontal or vertical blanking or sync pulses: this is a function of the analog video I/O interface perform packet sequence numbering: this is a function of RTP provide multiplexing: this is a function of RTP attempt to provide framing: this is provided by the network layer restrict colour component values, slew rates, or bandwidth: these are restrictions of certain conventional video standards, and may be applied as part of post-processing or viewing, if necessary. attempt to distribute precise timing information along the media stream: this is better done by methods such as NTP or GPS. attempt to provide error-detection: this is a function of the network layer 4. Recommended migration path Although the parametric header format allows many possible formats to be defined, this profile does not recommend the selection and use of arbitrary formats. The recommended migration path is: 1 Encapsulation of existing CCIR and AES/EBU video formats 2 Movement to RGB picture formats only 3 Movement to progressive scan picture formats only 4 Movement to higher bit depths, sample rate, and picture resolutions In particular, 10 bit video and 20 bit audio are recommended. 5. Design principles The profile consists of two parts: format description data encoding 6. Format Description: General The format of the data is described by a binary header transmitted at intervals with the data. The format of the binary header follows the 'chunk' format of EA IFF '85, as used in formats such as PNG. This is easy to parse and generate, whilst allowing both extensibility and efficiency. This header information is transmitted once per 'frame', at the head of an RTP packet. Such packets will have the RTP profile-dependent marker bit set, to indicate that they contain header information. The header information is not regarded as taking up any 'time' in the synchronisation timestamp. The header is a parametric description of the contents of the stream. The description format is intended to be orthogonal, even though only a subset of the possible image formats may ever be used, for compatibility and efficiency reasons. 7. Data encoding: General Wherever possible, the data encoding uses the most 'neutral' possible design decisions. Network byte ordering (that is, 'big endian', with the most significant bits/bytes first) is used throughout. Padding of bulk data to word boundaries is not used by default, as this is a gratuitous waste of network resources. 8. General header parameters Profile version, 4 bits, coded, mandatory 0 undefined/invalid 1 this specification 2..15 RESERVED FOR FUTURE USE Media flag, 2 bits, coded, mandatory 0 undefined/invalid 1 audio 2 video 3 RESERVED FOR FUTURE USE Synchronisation flag, 2 bits, coded, mandatory This represents the synchronisation of the source's 'media sync spindle'. 0 unsynchronised, free-running or internal sync 1 synchronised to external hardware sync or RTP sync source 2 synchronised to UTC 3 RESERVED FOR FUTURE USE FEC parity stripe factor, 8 bits, unsigned, mandatory This is the number of RTP data packets to be coded in each group of packets. The parity stripe packet is not included in this count. The value 0 indicates that no parity striping is present. 9. Audio-specific parameters Sample rate: 2 x 32 bits, unsigned, mandatory This is the audio sampling frequency, expressed in Hertz, as a ratio of two 32-bit unsigned numbers. This represents the nominal presentation rate of the sample stream in its natural form. Note that this is not necessarily the rate of transport of the sample stream over RTP; the stream may be presented faster or slower than the natural sample rate, for example during varispeed play. This is a nominal frequency: the exact frequency will depend on the synchronisation source. The true frequency should, however, be within 100 ppm of this value. Frequently-used rates will be: 32000 44100 48000 32000/1.001 44100/1.001 48000/1.001 Play rate: 32 bits, signed, mandatory This is the current playout rate of the material, expressed in units of 1/65536 of the nominal sample rate. Note that the playout rate may be zero, or reverse. Loudness reference: 8 bits, unsigned, mandatory This is a reference for the 'natural' level of the sound. The value encoded is the level in dBA that a full-intensity 1 kHz peak-to-peak sine wave in the current encoding represents. This is coded in dBA, with the value 255 reserved for unknown/undefined levels. Channels: 16 bits This is the number of sound channels carried. All sound channels carried together are regarded as being in sync; that is, the data values from a group of sound channels should be emitted from the audio outputs of those channels simultaneously. Bit-depth: 8 bits This is the number of bits in the sound samples. Whilst any number may be coded in this field, only the values 16 20 24 are recommended. Audio samples are always linearly sampled. Timecode This is a timecode descriptor: see the section 'timecode' for more information. AES-EBU Auxiliary information This contains pre-emphasis, sample rate, and other auxiliary information, compatible with the AES-EBU audio data format. 10. Video-specific parameters Sample rate: 2 x 32 bits, unsigned, mandatory This is expressed in Hertz, as a ratio of two 32-bit numbers. In this context, a video 'sample' is a frame. Note that this is not necessarily the rate of transport of the sample stream over RTP; the stream may be presented faster or slower than the natural sample rate, for example during varispeed play. This is a nominal frequency: the exact frequency will depend on the synchronisation source. The true frequency should, however, be within 100 ppm of this value. Typical values will be 24 25 24/1.001 30 30/1.001 Play rate: 32 bits, signed, mandatory This is the current playout rate of the material, expressed in units of 1/65536 of the nominal sample rate. Note that the playout rate may be zero, or reverse. Horizontal samples: 32 bits, unsigned, mandatory This is a 32-bit unsigned integer, specifying the number of sampling cells across the picture. Vertical samples: 32 bits, unsigned, mandatory This is a 32-bit unsigned integer, specifying the number of lines of sampling cells down the picture. Image aspect ratio: 2 x 32 bits, unsigned, mandatory This is the ratio of the width of the picture to its height, when displayed in its natural form, specified as the ratio of two 32-bit unsigned integers. These integers should have been reduced so as to have no common factors: 4:3 rather than 768:576. Note that this, combined with the vertical and horizontal sample parameters, define the pixel aspect ratio. For compatibility reasons with CCIR 601 a pixel aspect ratio of 15:16 may be used. A square pixel is preferred whenever possible, unless deliberate anamorphic processing is desired. Bit-depth: 8 bits This is the number of bits in the each colour channel's samples. Whilst any number may be coded in this field, only the values 8 10 12 16 are recommended. Interlace factor: 4 bits, unsigned, mandatory This is the number of 'fields' the picture is divided into. The number of lines is defined to be divisible by the number of fields. Where a field structure is present, the data values are coded field-sequentially, in an order determined by the field ordering parameter. Typical values are 1 progressive scan: no field structure 2 two fields Note: interlace is deprecated, and is only present to accommodate historical picture formats. For this reason, the field is limited to four bits, in the earnest hope that more will never be needed, and that interlace will die a quiet death over the next few years. The value zero is reserved. Field ordering: 16 bits, unsigned, mandatory The value in this field is determined as follows: Take the permutation of [0..n-1] made by the indices of the first lines of each field in order of transmission. The field ordering parameter is the ordinal number of this permutation in the table of all permutations of [0..n-1] arranged in 'dictionary' order, where the first entry is counted as zero. This may seem rather elaborate, but is designed to accommodate any conceivable field ordering, for up to 8 fields, within a 16-bit identifier. In particular, it gives simple encodings for progressive scan and two-field interlace! For example: Progressive scan: permutations of [0]: there's only one: so code zero in this field. Two fields: permutations of [0 1]. There are two, [0 1]: even field first, code 0 [1 0]: odd field first, code 1 Three fields: permutations of [0 1 2]. There are six, [0 1 2]: code 0 [0 2 1]: code 1 [1 0 2]: code 2 [1 2 0]: code 3 [2 0 1]: code 4 [2 1 0]: code 5 Values of more than (n! - 1), where n is the interlace factor, are reserved, and should not be coded. Colour component count: 4 bits, unsigned, mandatory This describes the number of colour components in the image. Typically, this value is 1, 3 or 4. Colour space descriptor: 4 bits, coded This describes the image's colour space, to a first approximation. Currently, the colour space descriptors available are: 0 unknown, undefined or not appropriate 1 monochrome 2 CIE XYZ system [for purists only] 3 EBU RGB phosphors 4 SMPTE RGB phosphors 5 colour film positive 6 colour film negative 7 colour film interpositive Whilst this field is not intended to replace exact colourimetry values (for which, see the section 'colourimetry description') the nearest value appropriate should be coded whenever possible. Colour space encoding law: 4 bits, coded, mandatory This describes the colour space encoding law of the image, in the simplest terms. The options available are: 0 unknown, undefined or not appropriate 1 linear 2 gamma law other than linear 3 logarithmic intensity 4 logarithmic density Wherever possible, the nearest approximate value should be coded. Component coding structure: 8 bits, coded, mandatory 0 undefined 1 monochrome 2 RGB 3 A 4 RGBA [?: separate RGB and A signals are more general] 5 YUV, 4:4:4 [deprecated: RGB is preferred] 6 YUV, 4:2:2 [that is, conventional D-1 video] 7 YUV CIF, 4:1:1 [deprecated, but useful for MPEG coding purposes] Where YUV coding is applied, the coding of CCIR recommendation 601 is assumed. Note that this includes the assumption of coding of transformed gamma-uncorrected signals, and precludes any other component-encoding laws. Extension for simple colour reference /// PROVISIONAL/// Colour space examples: in data encoding format, optional The following picture values should now be coded, as if appearing in picture material. 10% white, yellow, cyan, green, red, blue; black 90% white, yellow, cyan, green, red, blue; black 100% white, yellow, cyan, green, red, blue; black Note: this is not intended to replace detailed colourimetry information. However, an attempt should always be made to encode these values for all encodings. By incorporating these values in the 'picture', we ensure that even after incorrect processing, some colour reference information is preserved. Audio data encoding rules Samples are packed in big-endian bit order into a stream of bits. This stream is then broken into a stream of bytes in big-endian bit order. Samples are packed in the following order: most significant: time, earliest samples first less significant: sample channel, lowest numbered first Video data encoding rules Samples are packed in big-endian bit order into a stream of bits. This stream is then broken into a stream of bytes in big-endian bit order. Samples are packed in the following order: most significant: time, earliest frames first field: first transmitted field first line: topmost lines first pixel: leftmost pixel first least significant: sample channel, lowest numbered first Channel ordering for RGB, YUV and XYZ formats Red, then Green, then Blue [then optional Alpha]. X, then Y, then Z. Y, then U, then V. Sub-sampled formats [YUV 4:2:2, Y:U:V 4:1:1 CIF] Where 4:2:2 subsampled video is used, the samples are stored as follows: even samples [0,2,4...] Y, U, V [co-sited] odd samples [1,3,5...] Y only, no U or V coded Where 4:1:1 CIF subsampled video is used, the samples are coded as follows: even lines [0,2,4...] even samples [0,2,4...] Y, U, V [co-sited] odd samples [1,3,5...] Y only, no U or V coded odd lines [1,3,5...] even samples [0,2,4...] Y only, no U or V coded odd samples [1,3,5...] Y only, no U or V coded Forward error correction: optional Forward error correction (FEC) is preferred to selective re-transmission. The reasons for this are: Selective re-transmission is difficult in a high-delay transmission path, such as a satellite or transatlantic cable link, as it needs an extra delay of at least a round-trip time to allow for re-transmission. It also requires extra buffering at both the transmitter and the receiver. Selective re-transmission does not scale well to large multicast conferences. On a high-performance network, forward error correction may be unnecessary or be performed at the lower hardware layers, using techniques like interleaved Reed-Solomon codes. We believe that if FEC is necessary, it is best implemented in the network hard ware layer. However, there may be times when added FEC is necessary, when operating over a network with degraded performance or no provision for hardware error correction. The preferred mode is parity striping. For every n packets of image or audio data, a parity stripe packet will be sent, consisting of the bit-wise XOR of the date of the preceding n packets. Note that this requires that all the data packets be equal leng ths. The group of packets counter is reset after a parameter header. After reception, any single lost packet can be reconstructed from the surrounding group of packets and their parity stripe packet. Two lost packets will preclude any reconstruction of either lost packet, but is at least no worse than before. This simple FEC strategy involves an overhead of 1/n extra data to be sent, and is not recommended except in the presence of excessive data loss. There is also a buffering delay of n packets for any receiver that desires to perform parity-stripe reconstruction. Encoders are not required to emit parity-striped data, but the capability is recommended. All decoders must be able to receive parity-striped data, even if they cannot perform the reconstruction function. In this case, the parity stripe packets should be discarded. Lossless compression of sampled values ///TO BE WRITTEN/// Timecode and labels Support for missing, mis-synchronised and degraded timecode LTC and VITC Off-by-one encoding Leap seconds to match UTC: once per year Generic label format Extended timecode including full NTP timestamp??? ///TO BE WRITTEN/// Extensions for precise colourimetry description ///TO BE WRITTEN/// Extensions for precise geometry description ///TO BE WRITTEN/// Extensions for encryption and authentication ///TO BE WRITTEN/// Transport over an arbitrary byte-stream [TCP, HTTP etc] ///TO BE WRITTEN/// Storage in files ///TO BE WRITTEN/// Reference implementation ///TO BE WRITTEN/// Profile examples ///TO BE WRITTEN/// Go-faster stripes MTU, page alignment and efficiency Hardware acceleration and alignment issues ///TO BE WRITTEN/// Specification of 'artistic frame' vs. sampled frame vs. reference frame ///TO BE WRITTEN/// 11. Address of author Neil Harris Sohonet Limited 11 Bear Street London WC2H 7AS England neil@sohonet.co.uk From rem-conf-request@es.net Wed Jun 19 03:53:24 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jun 1996 00:52:43 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Jun 1996 08:50:22 +0100 To: Mike Macedonia cc: Theresa-Marie Rhyne , brutzman@cs.nps.navy.mil, rem-conf@es.net Subject: Re: computer graphics and networking In-reply-to: Your message of "Tue, 18 Jun 1996 09:56:27 EDT." Date: Wed, 19 Jun 1996 08:50:22 +0100 Message-ID: <822.835170622@cs.ucl.ac.uk> From: Jon Crowcroft >We need to establish a dialog between the SIGGRAPH and SIGCOMM >communities. How is yet to be determined. > >Networking *and* computer graphics have an important and evolving >relationship. It is more than just VRML or teleconferencing and more than >just writing technical standards. They are both technological areas that >are driving each other forward in many areas. >Unfortunately, there are alot of folks in both fields who just don't get it >yet. >If anyone from either community is interested in participating in this >effort, please let us know. Mike what is wrong with SIG Multimedia the MM conference covers exactly this crossover area, and has a lot of SIGCOMM people involved..........and some SIGGRAPH... some of those folks are even IETFers and W3Cers... cheers jon [sigcomm chair....] From rem-conf-request@es.net Wed Jun 19 03:55:41 1996 Received: from ruin.informatik.uni-bremen.de by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jun 1996 00:54:33 -0700 Original-Received: by ruin.informatik.uni-bremen.de (8.6.10/20.9.94cl) id JAA21612 Wed, 19 Jun 1996 09:54:17 +0200 PP-warning: Illegal Received field on preceding line Date: Wed, 19 Jun 1996 09:54:17 +0200 Message-Id: <199606190754.JAA21612@ruin.informatik.uni-bremen.de> From: Carsten Bormann To: Stephen Casner CC: micke@sm.luth.se, steve@sics.se, bcn@cdt.luth.se, engan@cdt.luth.se, rem-conf@es.net In-reply-to: Stephen Casner's message of Tue, 18 Jun 1996 13:13:16 -0700 (PDT) Subject: Re: CONTEXT_ERROR References: <199606181925.VAA27099@my8.sm.luth.se> > From: Stephen Casner > Date: Tue, 18 Jun 1996 13:13:16 -0700 (PDT) > > There is a design tradeoff between: > > A: C-bit compression to get to 1 byte minimum length > global sequence number > CONTEXT_ERROR contains no other info > > B: Context byte always sent (2 bytes minimum length) > sequence number per context > CONTEXT_ERROR contains a list of errored contexts It seems to me B is the sensible choice if you have reordering based on priorities in the underlying framing layer. You would then only have to make sure that packets from a single context are not reordered against each other (you probably want that for other reasons anyway). Alternatively, if the framing layer unambiguously transmits the priority level, you can of course have multiple instances of the compression engine (one per priority level), but this gets a bit messy. Gruesse, Carsten From rem-conf-request@es.net Wed Jun 19 08:16:02 1996 Received: from saturn.hrz.tu-chemnitz.de by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jun 1996 05:15:30 -0700 Received: from rhea.informatik.tu-chemnitz.de by saturn.hrz.tu-chemnitz.de with Local SMTP (PP) id <05488-0@saturn.hrz.tu-chemnitz.de>; Wed, 19 Jun 1996 14:14:31 +0200 Received: by rhea.informatik.tu-chemnitz.de.inf_192_D0M (4.1/SMI-4.1) id AA02173; Wed, 19 Jun 96 14:15:04 +0200 Date: Wed, 19 Jun 1996 14:15:02 +0200 (MET DST) From: Dietrich Thie To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII subscribe rem-conf From rem-conf-request@es.net Wed Jun 19 10:19:56 1996 Received: from rumms.uni-mannheim.de by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jun 1996 07:19:09 -0700 Received: from pi4.informatik.uni-mannheim.de by rumms.uni-mannheim.de with SMTP id AA26597 (5.67a/IDA-1.5 for ); Wed, 19 Jun 1996 16:18:52 +0200 Received: from eratosthenes.informatik.uni-mannheim.de (eratosthenes [134.155.48.125]) by pi4.informatik.uni-mannheim.de (8.7.3/8.7.3) with ESMTP id QAA27333; Wed, 19 Jun 1996 16:19:03 +0200 Received: (from whd@localhost) by eratosthenes.informatik.uni-mannheim.de (8.7/8.7) id QAA06264; Wed, 19 Jun 1996 16:19:03 +0200 (MET DST) Resent-Message-Id: <199606182049.WAA27820@my8.sm.luth.se> Message-Id: <199606182049.WAA27820@my8.sm.luth.se> X-Mailer: exmh version 1.6.6 3/24/96 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: Stephen Casner Cc: steve@sics.se, bcn@cdt.luth.se, engan@cdt.luth.se, rem-conf@es.ne Subject: Re: CONTEXT_ERROR In-Reply-To: Your message of Tue, 18 Jun 1996 13:13:16 PDT. Date: Tue, 18 Jun 1996 22:46:54 +0200 From: Mikael Degermark Resent-To: rem-conf@es.net Resent-Date: Tue, 18 Jun 1996 22:49:56 +0200 Resent-From: Mikael Degermark Resent-Date: Wed, 19 Jun 1996 16:19:01 +0200 (MET DST) Resent-From: Wieland Holfelder Resent-To: Wieland Holfelder Resent-Message-Id: Steve, > Right now our draft chooses A, but B might be the better choice. Van > commented to me in email today also that this choice should be > reconsidered. He said that if he had TCP/IP compression to do over > again, he would eliminate the C-bit compression. > > Because we should try to keep simplicity as a strong goal in addition > to these others, we should probably make this choice in the protocol > spec and avoid trying to negotiate it at runtime. I agree. Very good. > I have no objection to expanding the utility of the CONTEXT_ERROR > packet type for use with protocols other than IP/UDP/RTP. I note that > you managed to squeeze the one bit you needed for TCP into the > existing packet version field. But if a CONTEXT_ERROR type is > defined, then it could be used instead. You read my mind :-) When it is easy to identify the compressor (as it is when PPP is used), CONTEXT_ERROR is the way to go. This will be covered in a coming draft on IPv6 header compression over PPP. > What happened to 2? A mistake :-( The list should be 0 reserved 1 casner-jacobson IP/UDP/RTP header compression 2 IPv6 TCP 3 IPv6 non-TCP 4 IPv6 UDP/RTP I suggest the convention that if no CID (or context in your terminology) is present in a CONTEXT_ERROR message, it means that all compression state is invalidated. Mikael Degermark From rem-conf-request@es.net Wed Jun 19 20:02:15 1996 Received: from VNET.IBM.COM by osi-west.es.net with ESnet SMTP (PP); Wed, 19 Jun 1996 17:01:30 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0222; Wed, 19 Jun 96 20:01:12 EDT Date: Thu, 20 Jun 96 02:56:58 IST From: Scott Petrack To: M.Handley@cs.ucl.ac.uk, its@www.raleigh.ibm.com, rem-conf@es.net Subject: Re: SISP - Simple Internet Signalling Protocol Mark, Here are my answers to your comments about SISP. In the following, I use these tags: "SBP" = Scott Petrack "MH" = Mark Handley. I hope that you find I address your concerns. I believe that SISP can withstand your first frontal assault: SBP> The problem is that these protocols have a SBP> large overlap, and in many cases they solve overlapping and SBP> ill-defined problems. MH> SIP, SAP and SDP are MH> designed to be complementory, and don't overlap. SIP and SAP have MH> well defined purposes, and carry SDP. The abstract of the i-d draft for SDP says that it is "for announcing multicast sessions." I don't have the SAP draft in front of me, but I believe that it has also something to do with announcing sessions. This does sound like overlap to me. But this is perhaps a comment about the i-d's and not about the protocols. More seriously, there *is* overlap with *other* protocols. For example, it is claimed that SIP "aims to enable user mobility..." I just don't see what user mobility has to do with session invitation. "Invitation" is what you do once you have *found* the person you wish to invite. Aren't there other working groups which are aiming to enable user mobility? So I claim that the parts of SIP which have to do with redirection, user location, addressing, etc., overlap with other problems and protocols. Some of these are in the domain of MMUSIC, and some are not. In any case SISP is not concerned with them. Please don't get me wrong, I think that all these problems are very important and interesting ones. I just claim (among other things) that there is this little problem called "signalling" which I can define and then solve. And that solving this little problem is a neccessary step to going one level higher and solving the next problem up, which would indeed be a protocol for defining a "session". I claim that it is orthogonal to the problem of locating a user (which might use email, userid/machine name, or ouija boards). Signalling is sending, receiving, and exchanging information NOW about an RTP stream which is about to exist, exists, or is about to cease to exist. It also can use the mechanism of the CNAME to send, receive, and exchange information NOW about a SET of ASSOCIATED RTP streams which is about to exist, exists, or is about to cease to exist. I think that that really *is* well defined. Finally, note that I made a claim that much information in an SD packet overlaps with information in an RTCP packet. In fact, not only does the information overlap, but the *function* of that information also overlaps, in that it is used in RTCP for loose session control. Since there is this overlap, I suggested that one use RTCP packets (perhaps slightly extended) as the basic packets, rather than something new. MH> I think [the email item in the SDES packet is] MH> in RTCP as a result of early experience with diagnosing MH> and fixing (or failing to fix) Mbone problems. One of the prices you MH> pay for lightweight sessions if that there may be very little MH> information you have to go on to contact someone who (for example) MH> accidentally hit transmit... MH> MH> It's in SDP because there is (generally) no session in progress at the MH> time the advertisement or invitation carrying the SDP description is MH> sent. Being able to contact the session initiator to warn them of MH> problems (of any sort) before the session starts is necessary at the MH> current stage of evolution of the real-time sessions on the internet. What a perfect example of my point. The email item was put into RTCP to be able to contact someone about trouble. You put it into SDP so you can contact someone before the session begins about trouble. In addition, we may want it in tightly controlled sessions to provide "caller id." Since it's already in RTCP, and you're transmitting it when you signal a loosely controlled session, why do it somewhere else when you signal a tightly controlled session? And why do it in a different way for announcement? SBP> In any case, the RDES message should have SBP> exactly the description needed to identify the remote party. MH> This is where I get confused as to what you have in mind, and none of MH> the rest of the draft makes any sense with clearing up some MH> assumptions. You are probably getting confused because I really don't make many assumptions about what you call "specific conference control schemes." (Of course you confusion has nothing to do with my perfectly opaque explanation ;-)). Let me try to clear this up: There are cases where one will want to use a well known port number. There are cases where one will get a port number by some Session Announcement or Directory Protocol. There are cases where one will get a port number from the location server. There are cases where one will get a port number in some other way. To "port number" in the above sentences one might have to add Address. There are many different models and ways to get these things. I take seriously my claim that these important problems are not a part of signalling. They are (or may be) a part of the specific conference control scheme. (You claim that SIP is "not tied to any specific conference control scheme," and then proceed to explain how you will get port numbers from SIP. What do I do if my specific conference control scheme requires me to get my port number from the newspaper, or from a private email, or....In this case I cannot use SIP?) I tried to give some examples which show how you can use the same signalling scheme with wildly differing conference models. So now to your specific confusion: Suppose A wants to call B. The RDES packet which A sends will have whatever items are needed to identify B to the remote machine. It is the RDES that will include the info that let's me tell the remote machine that I want to speak to M.Handley@cs.ucl.ac.uk, or whatever. As to *where* to send this RDES packet, that has already been established by some other means (location server, whatever....) The SDES "capabilities" packet B sends back to A will contain whatever information is needed so that B can receive a stream from A. This may or may not include information about the port-pair. Whether it does or not depends on the specific conference control scheme. How A and B agree on what that conference control scheme is may or may not be decided by signalling. That is, it may be that the location service returned the information that A should use port XXX to get conference scheme Z.222. Or MMUSIC might define a set of codepoints for a bunch of common conference control schemes, and then the control scheme that A wants will be passed in the SDES message, or a bunch of other clever things might happen. Again, these are important problems that MMUSIC better solve. SISP might even be used to solve them (as in using an SDES item). My claim is that whatever scheme is used, SISP can be used to do signalling. Since there is a vast universe of possible schemes, I was rather vague in how the initial bootstrap might happen. I hope that this and the following detail will make it clearer. MH> Are you suggesting that a *well-known* port is used for RTCP *session MH> setup* information? And then another port-pair is used for the MH> actual RTP/RTCP data? This is indeed one mode that we use. (Except that there may be several other port-pairs) In this mode, you might say indeed that SISP is quite similar to SIP, with the following differences: 1. The packets that are sent are RTCP packets, not SDP packets. 2. A CNAME item is used. The remote party uses the CNAME to associate the various streams, so it can combine them into a multimedia conference. MH> This section implies you might be thinking of using a well-known port MH> for SISP messages, because otherwise you need to have your session MH> *up-and-running* in order to inform the remote user that you want to MH> start a session. But that makes no sense to me becasue you have no MH> way to bootstrap from your initial session to multiple sessions (ie a MH> *multi* media conference) in SISP. So you can't be thinking of that. If a session is already in progress, using a single port-pair, here is one simple way to use SISP to bootstram from the initial session to multiple sessions. You start with an ordinary (say) audio conference, and then "bootstrap" by sending several RDES packets, all addressed to the same person, using the same CNAME, but use the RDES packet to ask for different kinds of media. The RDES packet describes the "kind of receiver" I want NOW, and the SDES message I get back might have an item which tells me, in addition to what coders the remote party can receive, on which port-pair he can recieve them. So I might use a well known port number, or I might do this simple "bootstrap," as you put it. The RDES packet says "Here is the kind of receiver I want", which includes ALL info necessary to send an RTP stream, and the SDES capabilities message is used to send back all the info needed so the sender can stream away. Once again, I certainly didn't say that there is no overlap between SIP and SISP. I just said that I want to use RTCP packets, and I don't want to do anything having to do with user location or anything else that is not involved with setting up some stream *now*. (Or some streams associated by CNAME ). You are right, I was not at all clear about this. This was partly because there are so many different control models. I will try to make this clearer. MH> Just assuming for the moment that you've a cut-down user-location and MH> invitation protocol that.... I may have a HUGE user location protocol (DDNS, LDAP, ....). It just won't be SISP.... MH> then you use SISP for *each* RTP flow.... MH> the user doesn't want to be presented with a series of MH> questions such as "incoming call, receive video?" "incoming call, MH> receive audio?", ... So you need to group these in some way. SISP MH> doesn't appear to let you associate flows in any way. First of all, I definitely want to allow the possibility of letting the user accept the audio part and refuse the video part, etc. Or do an assisted call transfer by first transferring the audio part, and only if the third party wants the call, then transferring the video also, etc.... So I definitely had in mind to enable this separate stream control. Second, RTCP uses the CNAME item to associate streams, and on possibility I had in mind that there might be an RTCP stream that would perform signalling on the entire set of streams associated by a single CNAME. I do this now by using a well known port number for signalling all the streams associated with a CNAME. That is, the call starts with some RTCP packets to a well known port number. This sends a lot of RDES packets to set up the multimedia conference. Each realtime stream is a separate port pair. I can signal any stream I want separately. But the original well known port is still used to signal all the associated streams together. I mentioned this possibility in the draft when I mentioned "RTCP compression." Logically, one really does want to signal each stream separately, but the conference model can agree that to "compress" the signalling by using a separate stream with a CNAME item to signal all associated streams. Or in fact you don't really need a separate port. It would be enough to say that a packet with BOTH a CNAME *and* a signal item would signal all the associated streams. I shall think about this.... May I suggest that you read RFC 1889 with an eye to signalling? It is very illuminating. Do a grep on the word "before," and you will see that some care has been taken about sending a first RTCP packet before any data is sent, to prevent SSRC collisions. To make a long story short, it is quite natural to start a session by sending some RTCP data, and then to bootstrap from there. Here is a quote about session association: 2.2 Audio and Video Conference If both audio and video media are used in a conference, they are transmitted as separate RTP sessions RTCP packets are transmitted for each medium using two different UDP port pairs and/or multicast addresses. There is no direct coupling at the RTP level between the audio and video sessions, except that a user participating in both sessions should use the same distinguished (canonical) name in the RTCP packets for both so that the sessions can be associated. One motivation for this separation is to allow some participants in the conference to receive only one medium if they choose. One of the ideas in SISP is indeed to use a stream of RTCP packets, using a CNAME, without any associated RTP stream, in order to signal together the entire set of RTP streams with that CNAME. MH> Now how about if you want to "invite" someone to join a multi-way MH> multi-media session that you're having. Presumably you'd like to warn MH> them they're just about to appear in a large meeting rather than a MH> private call, so they have to option to reject you. Thus you really MH> need some session description stuff in addition to grouped sessions. Once again you're falling victim to doing too much and trying to solve too many problems. If I want to "invite" someone to a conference in the way you suggest, then "inviting" might mean something different than signalling. Indeed, this happens right now with conference bridges. When you dial up the conference bridge, you might ask the operator something like "how late am I? How long has this session been going on? Until when is it scheduled?" And the operator if s/he's nice will tell you. After all this conversation is over, the operator does some SIGNALLING to get you into the conference. By the way, your example happens to be a bad one, since RTCP indeed allows you know how many participants are in a conference. Indeed, this is an important part of RTCP. So once again you prove my point: a lot of what is needed for conference control already is in RTCP, so why do it again? Suppose that you are correct, and it is important to know the colour of the T-shirts of the participants in the conference, or whether any of them had garlic for lunch (in case the multimedia conference supports smell), so that you need to send some session description stuff. I have no problem with this, but this is not signalling. But note very carefully: if in the future there is a possibility of streaming smell over the internet in realtime, then I assume that smell will be streamed in an RTP stream. And this means that one might have to define some new RTCP packets to describe the realtime stream. And then indeed I'll bet that those parts of the session that are related to signalling will already be defined in RTCP. So at that point in time, there really will be a reason to do signalling of a smell stream. But if one is using SISP, then the relevant fields will already have been defined. MH> If SISP doesn't do these things (and being tied to RTCP, it can't MH> easily), I think that it's been doing them pretty easily up til now.... Scott From rem-conf-request@es.net Thu Jun 20 03:30:00 1996 Received: from cs.nps.navy.mil by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 00:29:20 -0700 Received: from libra.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA02674; Thu, 20 Jun 96 00:28:19 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9606200728.AA02674@cs.nps.navy.mil> Subject: Re: computer graphics and networking To: jed@llnl.gov (James E. [Jed] Donnelley) Date: Thu, 20 Jun 1996 00:28:19 -0700 (PDT) Cc: mmacedon@crcg.edu, rem-conf@es.net, trhyne@vislab.epa.gov (Theresa-Marie Rhyne) In-Reply-To: from "James E. [Jed] Donnelley" at Jun 18, 96 11:09:30 am X-Mailer: ELM [version 2.4 PL25] Content-Type: text Content-Length: 3635 Jed has good questions. I think interactive 3D graphics connected in large-scale virtual environments provide driving requirements that are extremely demanding. The following abstract leads to a chapter which addresses those questions. May I incidentally point out that no one is asking network folks to throw down their packets (or cells) for polygons! The motivation rather is that a lot of valuable work might be enabled by greater collaboration and dialog among individuals working in networking and graphics. Professional societies (such as SIGGRAPH and SIGCOMM) might productively support & encourage such interdisciplinary efforts. Graphics Internetworking: Bottlenecks and Breakthroughs Don Brutzman Code UW/Br, Naval Postgraduate School Monterey, California 93943 USA 408.656.2149 voice, 408.656.3679 fax brutzman@nps.navy.mil http://www.stl.nps.navy.mil/~brutzman/vrml/breakthroughs.html To appear in _Digital Illusions_, Clark Dodsworth editor, Addison-Wesley, Reading Massachusetts, 1996. Introduction and Motivation. Although networking is considered to be "different" than computer graphics, network considerations are integral to large-scale interactive three-dimensional (3D) graphics. Graphics and networks are now two interlocking halves of a greater whole: distributed virtual environments. New capabilities, new applications and new ideas abound in this rich intersection of critical technologies. Our ultimate goal is to use networked interactive 3D graphics to take full advantage of all computation, content and people resources available on the Internet. Network breakthroughs repeatedly remove bottlenecks and provide new opportunities. A pattern appears as we attempt to scale up in capability and capacity without limit: every old bottleneck broken reveals another. Understanding the bottlenecks, the corresponding solutions and potential upper bounds to growth permits us to develop effective networked graphics. When we overcome current bottlenecks, "effectively networked graphics" will mean "applications." Internetworked graphics can be examined from the perspectives of connectivity, content, interaction, economics, applications and personal impacts. Internetworking refers to the ability to seamlessly interconnect multiple dissimilar networks globally. Connectivity has numerous dimensions including capacity, bandwidth, protocols and the many-to-many capabilities of multicasting. Content equals the World Wide Web and includes any type of information, dataset or stream that might be used in the graphics environment. Interaction implies minimal latency, a sense of presence, and the ability to both access and modify content. The economics of networked graphics environments is developing rapidly and principal forces can be identified. Applications drive infrastructure development and are the most exciting part of networked graphics. Finally, the personal impacts which accompany these developments range from trivial to profound as high-quality interactive internetworked computer graphics become the norm on all computers. all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman From rem-conf-request@es.net Thu Jun 20 04:06:37 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 01:05:57 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA01291; Thu, 20 Jun 1996 01:05:44 -0700 Date: Thu, 20 Jun 1996 01:05:43 -0700 (PDT) From: Stephen Casner To: Scott Petrack Cc: M.Handley@cs.ucl.ac.uk, its@www.raleigh.ibm.com, rem-conf@es.net Subject: Re: SISP - Simple Internet Signalling Protocol In-Reply-To: <9606200038.AA00822@precept.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Scott, I have a few comments on this exchange. > I hope that you find I address your concerns. I believe that SISP > can withstand your first frontal assault: The war metaphor seems a bit overstated. > The abstract of the i-d draft for SDP says that it is "for announcing > multicast sessions." I don't have the SAP draft in front of me, but I > believe that it has also something to do with announcing sessions. This > does sound like overlap to me. This argument is specious. SDP describes sessions; SIP and SAP are two ways of many possible ways to carry SDP session descriptions, each for a different purpose. > What a perfect example of my point. The email item was put into RTCP > to be able to contact someone about trouble. You wrote that the EMAIL SDES item was "required" in RTCP. It is not. All of the SDES information other than CNAME is optional. In fact, the RTP spec is careful to warn about limiting the bandwidth consumed by the additional information. > May I suggest that you read RFC 1889 with an eye to signalling? It is > very illuminating. Do a grep on the word "before," and you will see > that some care has been taken about sending a first RTCP packet > before any data is sent, to prevent SSRC collisions. There is no requirement to send an RTCP packet before sending data. This may be likely in some scenarios, but it not required. > One of the ideas in SISP is indeed to use a stream of RTCP packets, > using a CNAME, without any associated RTP stream, in order to signal > together the entire set of RTP streams with that CNAME. RTCP is a convenient channel for communication of additional control information when the RTP session already exists. If no session exists, it is not clear that RTCP to a well-known port is the right way to get a session started. There might well be good reasons for that communication to be in a different form. -- Steve From rem-conf-request@es.net Thu Jun 20 04:32:14 1996 Received: from xr3.atlas.fr by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 01:31:43 -0700 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Thu, 20 Jun 1996 10:31:13 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Thu, 20 Jun 1996 10:31:13 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Thu, 20 Jun 1996 10:31:14 +0200 X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed; Thu, 20 Jun 1996 13:31:06 +0200 Date: Thu, 20 Jun 1996 13:31:06 +0200 X400-Originator: haignere@issy.cnet.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=FR/;835259468@x400.issy.cnet.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: Urgent question Alternate-Recipient: Allowed From: Isabelle HAIGNERE Message-ID: <9606200831.AA02106@haddock> To: scoya@ietf.cnri.reston.va.us, rem-conf@es.net Subject: Urgent question on the IETF 36th meeting Content-Length: 1900 *-------------------------------------------------------* | From : Isabelle Haignere | | CNET - PAB/STC/SGV | | 38-40 rue du General Leclerc | | F-92 131 Issy les Moulineaux | | FRANCE | | | | Tel. : + 33 1 45 29 40 08 | | Fax. : + 33 1 45 29 52 94 | | | | E-mail : isabelle.haignere@issy.cnet.fr | *-------------------------------------------------------* Hello, I would like to know what software is needed to follow the 36th IETF meeting, last week; we would like to listen to and see conferences. I suppose that conferences are broadcast on the Mbone (this meeting is registered in the AGenda Mbone which can be reached by "http://www.mbone.com"). Is it necessary to be registered prior to the meeting ? Or is it possible to listen to and see the meeting during its broadcasting ? I have some questions on the MBone : - very often, meetings published in the Mbone Agenda are broadcasted meetings ? Do some bi-directional and multicast meetings exist ? - If one has to be registered prior to the meeting, why is it necessary ? - Does MBone reserve some ressource bandwidth ? I have given a look to the reservation book of meetings on the Mbone, I do not understand that you mention "overbooking", why is it possible to meet overbooking if we are on the Net, I assumed that it was not possible that such an overbooking "phenomen" can happen, doees it mean that bandwidth ressource reservation is handled before such a meeting ? - Is it possible to be added unexpectedly to a meeting ? Best regards Thank you very much Isabelle HAIGNERE From rem-conf-request@es.net Thu Jun 20 05:12:47 1996 Received: from VNET.IBM.COM by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 02:12:12 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5440; Thu, 20 Jun 96 05:11:54 EDT Date: Thu, 20 Jun 96 11:21:27 IST From: petrack@VNET.IBM.COM To: CASNER@PRECEPT.COM Cc: M.Handley@cs.ucl.ac.uk, its@www.raleigh.ibm.com, rem-conf@es.net Subject: Re: SISP - Simple Internet Signalling Protocol Reply-To: PETRACK@HAIFASC3.VNET.IBM.COM News-Software: UReply 3.1 In a previous message, you wrote: >Scott, > >The war metaphor seems a bit overstated. Sorry, no offense at all was meant. I'll drop it. Believe me, the style of this group is something that's hard to get into for a newcomer. I'm sorry if I was tiring. > > SDP describes sessions; SIP and SAP are >two ways of many possible ways to carry SDP session descriptions, each >for a different purpose. Please remember that I am learning this stuff from Internet drafts, not directly from the people involved. The actual abstract of the SDP draft did confuse me about SDP. But I understand this point now. I still think that my comments about the overlap with the user location and directory services is correct. > >> What a perfect example of my point. The email item was put into RTCP >> to be able to contact someone about trouble. > >You wrote that the EMAIL SDES item was "required" in RTCP. It is not. >All of the SDES information other than CNAME is optional. In fact, >the RTP spec is careful to warn about limiting the bandwidth consumed >by the additional information. I should have said that every implementation of of RTCP is required to understand this message. And that if you need to transmit it, then RTCP requires you to do it in such-and-such a format. Again, my point is only that if one needs to transmit this information, then RTCP gives you a place and a format to do it with. It seems that SIP, SAP, etc. also find that you may need to transmit this information. By doing it with the RTCP packet, I hope to save both bandwith and code. If I am using for SIP for what I call signalling in a loosely controlled conference, I may well have to send the EMAIL twice, once in an SDES and once in an SDP packet. Saving bandwidth is an important consideration for me and a main motivation for SISP. >There is no requirement to send an RTCP packet before sending data. >This may be likely in some scenarios, but it not required. I did not mean to suggest that there is such a requirement. I just meant that if you decide you want to do it, then RTCP already allows it, and contains some information needed for the "bootstrapping process" that Mark was worried about. >> One of the ideas in SISP is indeed to use a stream of RTCP packets, >> using a CNAME, without any associated RTP stream, in order to signal >> together the entire set of RTP streams with that CNAME. > >RTCP is a convenient channel for communication of additional control >information when the RTP session already exists. If no session >exists, it is not clear that RTCP to a well-known port is the right >way to get a session started. There might well be good reasons for >that communication to be in a different form. In the scenario that you describe, where no session exists, but where you'd like to start one up *NOW*, and where by "session" you mean RTP session, then you have to start sending RTP and RTCP somewhere sometime. In the case where one wants some session control, then it does seem to me to be logical and efficient to start by sending RTCP packets. You might send them to a "well-known" port, or you might send them to a port which was agreed upon in email, or via SDP. But if you have to setup the RTP session or sessions, RTCP seemed to me to be the best way to do it. Maybe it depends on what you mean by "start a session." If you include the announcement as being part of the "start", so that the session might "start" a week before any RTP ever gets sent, then I agree - there is a very important place for a protocol like SAP (let's leave aside the format of an SDP packet) in "session startup." I meant by startup something that happens *now*. I think that Mark's word "bootstrapping" describes it well. SISP concentrates on stuff that happens just before and during the life of an RTP session. And I think that in the scenarios where one wants something tighter than the loosest control possible of an RTP session or group of sessions, then it is very natural and effecient to bootstrap via RTCP to some port which is agreed upon in advance (either by being well-known, or by some other agreement or announcement procedure). I gave the example of a private multicast where the session is tightly controlled via some encryption. In this scenario, you are right, there may be no need to send some RTCP before the RTP session begins. I just made the claim that in those scenarios where you *do* need to send *something* just before the RTP session can begin (in order to "bootstrap" or control the RTP session or sessions), that RTCP packets are a rich and efficient choice. Scott From rem-conf-request@es.net Thu Jun 20 05:25:01 1996 Received: from Mat075207.student.utwente.nl by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 02:24:16 -0700 Received: from HollYWOOD by Mat075207.student.utwente.nl (951211.SGI.8.6.12.PATCH1042/940406.SGI) id LAA07615; Thu, 20 Jun 1996 11:25:05 +0200 From: Wessel de Roode Message-Id: <9606201125.ZM7613@Mat075207.student.utwente.nl> Date: Thu, 20 Jun 1996 11:25:05 -0600 Reply-To: wessel@Mat075207.student.utwente.nl X-face: 0!Z(ni#lPG&^v^7~USe=jO0r%^:KZdlAiQH(exdn<95LUN~!Z77u8g13= X-URL: http://Mat075207.student.utwente.nl/~wessel X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: rem-conf@es.net Subject: Which language on the the Mbone ? Cc: mbone@isi.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, I've was just brouwsing through the announcements from the Mbone when I bumpt into a forneir language quit differend from englisch. I was just wondering if we could keep all announcements in englisch but if the broadcast is in a differend language than englisch just write it down in the announcement as wel :-)) It's not that I want all the forneir laguages bounced from the Mbone but just keep all the anouncements readable worldwide, or scale your ttl to your country. Any unwriten habbits about this ? Wessel -- [---] Your fortune cookie today is: All wars are civil wars, because all men are brothers ... Each one owes infinitely more to the human race than to the particular country in which he was born. -- Francois Fenelon From rem-conf-request@es.net Thu Jun 20 05:32:38 1996 Received: from nthx02.nt.fht-esslingen.de by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 02:31:31 -0700 Received: from ntpc67.nt.fht-esslingen.de by nthx02.nt.fht-esslingen.de with SMTP (1.38.193.4/16.2) id AA00845; Thu, 20 Jun 1996 11:36:51 +0200 Message-Id: <31C91A70.7EEE@nthx02.nt.fht-esslingen.de> Date: Thu, 20 Jun 1996 11:31:28 +0200 From: "Thomas C. Fischer" Organization: FHT Esslingen X-Mailer: Mozilla 2.0 (Win95; I) Mime-Version: 1.0 To: rem-conf@es.net Subject: subscribe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe -- ------------------------------------------------------------ Dipl.-Ing. (FH) Thomas C. Fischer, MSc Assistent - Department of Communications Engineering ------------------------------------------------------------ Direct Line: + 49 (0) 711 397-3810 Departmental Facsimile: + 49 (0) 711 397-3792 Electronic Mail: fischer@nthx02.nt.fht-esslingen.de ------------------------------------------------------------ Postal Address: Fachhochschule Esslingen Fachbereich Informationstechnik Flandernstrasse 101 73732 Esslingen Germany ------------------------------------------------------------ From rem-conf-request@es.net Thu Jun 20 07:09:56 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 04:08:36 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Jun 1996 12:08:10 +0100 To: brutzman@cs.nps.navy.mil (Don Brutzman) cc: jed@llnl.gov (James E. [Jed] Donnelley), mmacedon@crcg.edu, rem-conf@es.net, trhyne@vislab.epa.gov (Theresa-Marie Rhyne) Subject: Re: computer graphics and networking In-reply-to: Your message of "Thu, 20 Jun 1996 00:28:19 PDT." <9606200728.AA02674@cs.nps.navy.mil> Date: Thu, 20 Jun 1996 12:08:07 +0100 Message-ID: <1632.835268887@cs.ucl.ac.uk> From: Jon Crowcroft >May I incidentally point out that no one is asking network folks to >throw down their packets (or cells) for polygons! why not? - a profile for polygons in RTP and use of SRM would seem to fit the bill.... cheers jon remember there is a multimedia bit of the ACM now see http://www.acm.org/sigmm/ i think that they already have a remit to cover this though maybe they talk more about audio and video than about virtual worlds right now.... From rem-conf-request@es.net Thu Jun 20 07:29:29 1996 Received: from norton (actually norton.rtpnc.epa.gov) by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 04:27:59 -0700 Received: by norton (940816.SGI.8.6.9/1.34) id HAA21003; Thu, 20 Jun 1996 07:27:22 -0400 From: Theresa-Marie Rhyne Message-Id: <9606200727.ZM21001@norton.rtpnc.epa.gov> Date: Thu, 20 Jun 1996 07:27:21 -0400 In-Reply-To: Jon Crowcroft "Re: computer graphics and networking" (Jun 20, 12:08pm) References: <1632.835268887@cs.ucl.ac.uk> X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: Jon Crowcroft , brutzman@cs.nps.navy.mil (Don Brutzman) Subject: Re: computer graphics and networking Cc: cunningham@siggraph.org, jed@llnl.gov (James E. [Jed] Donnelley), mmacedon@crcg.edu, rem-conf@es.net, trhyne@vislab.epa.gov (Theresa-Marie Rhyne) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Jon: perhaps your last comment hit upon some of the issues us folks in the 3D graphics world are concerned about.... "remember there is a multimedia bit of the ACM now see http://www.acm.org/sigmm/ i think that they already have a remit to cover this though maybe they talk more about audio and video than about virtual worlds right now...." -- Jon Crowcroft 3D graphics on a network is more than audio and video.... and more than just virtual reality... it includes real time steering of 3-D visualizations; the development of VRML as the 3-D world envrionment on the WWW & Internet....the notion that once folks start viewing 3-D worlds on the network, they might want to snap their fingers and go run another computational model on a remote computer and compare it to the existing 3-D visualization...and of course this would need to be completely transparent model execution with no network bottlenecks... this is the stuff some of us SIGGRAPH types -- who only claim to be graphics types --- are concerned about... and the folks who handle the networking world I immediately live in always seem to get worried that graphics types like me will create such nifty pictures and teach users how to do it themselves... that we will overload the network...and get in the way of down to earth functions like getting transactions processed like maybe paychecks or something... what ACM SIG is worried about that.... or are maybe all of us ?? Smiles.... Theresa-Marie From rem-conf-request@es.net Thu Jun 20 12:15:25 1996 Received: from omicron.csustan.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 09:14:23 -0700 Received: by omicron.csustan.edu (4.1/1.12) id AA01672; Thu, 20 Jun 96 09:32:42 PDT Date: Thu, 20 Jun 96 09:32:42 PDT From: rsc%omicron.csustan.edu@altair.csustan.edu (Steve Cunningham) Message-Id: <9606201632.AA01672@omicron.csustan.edu> To: J.Crowcroft@cs.ucl.ac.uk, brutzman@cs.nps.navy.mil, trhyne@vislab.epa.gov Subject: Re: computer graphics and networking Cc: cunningham@siggraph.org, jed@llnl.gov, mmacedon@crcg.edu, rem-conf@es.net Theresa et al., We're quite aware of SIGMM -- we helped get the first ACM multimedia conference off the ground in 1993, we're a co-sponsor of the ACM MM conference, and we are in ongoing contact with them through our ACM Program Director, who also is the program director for SIGMM. I don't think that any of the questions that Theresa raises conflict with SIGMM at all -- SIGGRAPH has always been concerned with graphics and interactive techniques, however they are embodied, and the networks are just another facet of this. We'd be happy to have SIGMM cooperate with anything in this area, I'm sure, but they seem much more focused on supporting technologies. I don't know the answer to the question of "who in ACM is concerned with the networks' ability to handle transaction processing," but I would expect it to be SIGCOMM. I still have a lot to learn about the division of the world into SIGs, and the division sometimes seems not to be clean... -- Steve From rem-conf-request@es.net Thu Jun 20 12:35:45 1996 Received: from hplms26.hpl.hp.com by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 09:35:03 -0700 Received: from jade.hpl.hp.com by hplms26.hpl.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3+HPL1.1S) id AA013088497; Thu, 20 Jun 1996 09:34:58 -0700 Received: by jade.hpl.hp.com (1.37.109.18/15.5+ECS 3.3+HPL1.1) id AA064968495; Thu, 20 Jun 1996 09:34:56 -0700 From: Eve Schooler Message-Id: <9606200934.ZM6494@jade.hpl.hp.com> Date: Thu, 20 Jun 1996 09:34:54 -0700 In-Reply-To: Scott Petrack "Re: SISP - Simple Internet Signalling Protocol" (Jun 20, 2:56am) References: <199606200304.AA15556@venera.isi.edu> X-Mailer: Z-Mail (3.2.1 10oct95) To: M.Handley@cs.ucl.ac.uk, Scott Petrack , its@www.raleigh.ibm.com, rem-conf@es.net Subject: Re: SISP - Simple Internet Signalling Protocol Cc: schooler@jade.hpl.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi Scott, >More seriously, there *is* overlap with *other* protocols. For example, >it is claimed that SIP "aims to enable user mobility..." I just >don't see what user mobility has to do with session invitation. >"Invitation" is what you do once you have *found* the person >you wish to invite. Aren't there other working groups which are >aiming to enable user mobility? So I claim that the parts of SIP >which have to do with redirection, user location, addressing, etc., >overlap with other problems and protocols. Some of these are in the >domain of MMUSIC, and some are not. In any case SISP is not >concerned with them. By saying SIP "aims to enable user mobility..." we were *not* claiming that SIP itself performs user location. Rather, we were thinking of a number of scenarios where SIP can take advantage of additional user location services, if they exist. In particular, if a user frequents multiple locations, and a location service tracks this mobility, then SIP can build upon this knowledge. For example, if the user agent initiating an invitation obtains (from a location server) multiple addresses for a remote user, then an invitation request can be sent to those multiple addresses simultaneously; typically a user will reside at only one or none of those addresses, so only one of those requests can succeed. Another example where additional user location information is beneficial is when the recipient (a user agent or proxy) of a SIP invitation acts to forward or to redirect the request. Again, the knowledge about the alternate user addressing is obtained from a location server. SIP just makes use of that knowledge. In these types of situations, I would claim SIP enables or facilitates user mobility, i.e., SIP does not require that a user be associated with a rigid address. Section 4 of the SIP draft provides further explanation of the relationship between SIP and location servers. E. From rem-conf-request@es.net Thu Jun 20 13:24:02 1996 Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 10:23:10 -0700 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA00780; Thu, 20 Jun 96 13:23:06 EDT Received: from smtpnotes.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA09487; Thu, 20 Jun 96 13:23:05 EDT Received: by smtpnotes.pictel.com (4.1/SMI-4.1) id AA01782; Thu, 20 Jun 96 13:23:04 EDT Message-Id: <9606201723.AA01782@smtpnotes.pictel.com> Received: from PicTel with "Lotus Notes Mail Gateway for SMTP" id 9810D1BA0D6C0A6B8525634F005F2A5B; Thu, 20 Jun 96 17:23:02 To: h32z2-list , imtc , rem-conf , confctrl From: Rich Baker/PicTel Date: 20 Jun 96 2:41:24 EDT Subject: Reminder: IMTC CNC audiocall on H.323 tomorrow 6/20 Mime-Version: 1.0 Content-Type: Text/Plain Hi folks: Apologies for duplicate postings... This is a reminder that we will convene an IMTC sponsored CNC AG audioconference this Thursday (tomorrow), 20 Jun, at 8am West Coast, 11am East Coast, 4pm UK time, for two hours. Four agenda items thus far: 1) THUNDEROUS APPLAUSE! H.323 "Decided" in Geneva 28 May 96! 2) Update on SG15 meeting held in Geneva (Gary, Dale, Mark, et al.) 3) Now that H.323 is Decided -- time to begin the process of enhancing it with more "way cool" stuff: o What do we want to accomplish? o By when? o How best to facilitate the process? o Schedule follow on IMTC CNC AG meetings 4) Brief status report/update on Jim Toga's sub-group on H.323 Implementation. Where: +1-212-346-0450. When: 8am Pacific, 11am East Coast, 4pm U.K. Duration: 2 hours Confirmation #172 0506 Chair: Rich Baker Note that this conference is automated, so please honor the open nature of these meetings and announce your name when you join. They are scheduled through ConferTech, at +1-800-252-5150 or +1-303-633-3000. All IMTC CNC AG members and other folks deeply involved in multimedia collaboration over IP-multicast intranets using H.323 are invited to attend these meetings. I have reserved only 20 ports for the audiocall. So... if you are a "worker bee", please join us! If you just want to be a "fly on the wall," please leave the port open for a "bee" instead... Cheers, -rich baker IMTC Corporate Network Conferencing AG Chair PictureTel Corporation +1-508-292-5936 (new phone number) bake@pictel.com From rem-conf-request@es.net Thu Jun 20 22:02:58 1996 Received: from iexpo.expo.or.kr (actually 203.239.68.3) by osi-west.es.net with ESnet SMTP (PP); Thu, 20 Jun 1996 19:02:07 -0700 Received: from hmkim.expo.or.kr ([203.239.68.13]) by iexpo.expo.or.kr (8.6.12h2/8.6.12) with SMTP id LAA07536; Fri, 21 Jun 1996 11:09:04 +0900 Message-ID: <31CA0250.3B43@expo.or.kr> Date: Fri, 21 Jun 1996 11:00:48 +0900 From: Kim Mansu Reply-To: mskim@iexpo.expo.or.kr X-Mailer: Mozilla 3.0b4Gold (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net CC: mskim@expo.or.kr Subject: To: Mbone User in other country , help pls. References: <9606201632.AA01672@omicron.csustan.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi~~ all (and sorry other people ) Now I plan to Mbone broadcasting "Open concert by KBS(Korea Boradcasting Service)" to world. I think it's the first realtime Korean TV Mbone broadcasting, so I need some help, 'Program director of Open Concert' want to TV broadcaste "people who see the Mbone broadcasting(open concert)" I need people who can use 512Kbps or higher lines, and can use Mbone tools(SD, SDR,NV, VAT, VIC) is there any people who help me? I plan to broadcaste open concert July 7th 18:00 pm KST(sorry I cannot find other standard time) If you can help me, please mail to me. World Internet Exposition 1996 Korean Organization, Kim, Mansu(mskim2expo.or.kr, +82-2-3443-7585) ps) sorry If disturbing you, From rem-conf-request@es.net Fri Jun 21 03:57:20 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jun 1996 00:56:45 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA03552; Fri, 21 Jun 1996 00:56:44 -0700 Date: Fri, 21 Jun 1996 00:56:43 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: IETF AVT meeting agenda Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII AVT Working Group: A couple of items have been dropped from the tentative agenda I sent a week ago, but I expect we will have a very interesting meeting none the less. Our two sessions are back-to-back, so we can be somewhat flexible on the boundary (we will take a break at the scheduled time for cookies). Comments on the agenda continue to be welcome. We can make adjustments at the start of the session as appropriate. -- Steve Casner Audio/Video Transport WG A G E N D A Tuesday, June 25, 13:00-15:00 and 15:30-17:30 - RTP header compression - Proposal for IP/UDP/RTP link-level compression [Casner] - Proposal for RTP end-to-end compression and transition [Petrack] - Other proposals? - Discussion: deployment; transition; coordination with PPP, segmentation and traffic control. - Proposed new payload formats - Payload format for G.723 [Intel] - Payload formats for redundant encodings [Handley] - RTP profile for professional audio and video [Casner] - GSMVQ low-rate audio encoding [Petrack] - What's needed to progress RTP to Draft Standard [Casner] - Edits needed, e.g. one vs. two source ports in RTP loop/collision algorithm - Changes proposed for layered encodings - Proof of interoperability requirements - RTCP additions - SISP: signalling protocol [Petrack] - VCR controls for VOD? [Casner, query from Larry Rowe] - Other topics - MBone transition to RTPv2 audio - Should there be an interface service definition for RTP? - Should we define an RTP MIB? From rem-conf-request@es.net Fri Jun 21 09:24:14 1996 Received: from xr3.atlas.fr by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jun 1996 06:23:44 -0700 X400-Received: by /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 21 Jun 1996 15:22:43 +0200 X400-Received: by mta xr3.atlas.fr in /PRMD=INTERNET/ADMD=ATLAS/C=FR/; Relayed; Fri, 21 Jun 1996 15:22:43 +0200 X400-Received: by /ADMD=ATLAS/C=FR/; Relayed; Fri, 21 Jun 1996 15:22:45 +0200 X400-Received: by /PRMD=cnet/ADMD=atlas/C=FR/; Relayed; Fri, 21 Jun 1996 18:22:26 +0200 Date: Fri, 21 Jun 1996 18:22:26 +0200 X400-Originator: haignere@issy.cnet.fr X400-Recipients: non-disclosure:; X400-MTS-Identifier: [/PRMD=cnet/ADMD=atlas/C=FR/;835363357@x400.issy.cnet.fr] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: To: Mbone Us Alternate-Recipient: Allowed From: Isabelle HAIGNERE Message-ID: <9606211322.AA03509@haddock> To: mskim@iexpo.expo.or.kr Cc: rem-conf@es.net, mskim@expo.or.kr In-Reply-To: "Kim Mansu(039)s message(009)of (q), June 21, 1996 02:00:48 GMT(q)(009)regarding (q)To: Mbone User in other country , help pls.(": Subject: Re: To: Mbone User in other country , help pls. Content-Length: 2043 *-------------------------------------------------------* | From : Isabelle Haignere | | CNET - PAB/STC/SGV | | 38-40 rue du General Leclerc | | F-92 131 Issy les Moulineaux | | FRANCE | | | | Tel. : + 33 1 45 29 40 08 | | Fax. : + 33 1 45 29 52 94 | | | | E-mail : isabelle.haignere@issy.cnet.fr | *-------------------------------------------------------* id <31CA0250.3B43@expo.or.kr> References: <9606201632.AA01672@omicron.csustan.edu> <31CA0250.3B43@expo.or.kr> Report-Mode: Confirmed You have to be registered on the Mbone agenda at the web site "http://www.mbone.com"; after you have to surf in order to find the agenda. You have to surf toward " Mbone event schedules and program guides". After that, choose the "book" item. BY By and good luck. Isabelle HAIGNERE > [ On , June 21, 1996 at 02:00:48, Kim Mansu wrote: > Subject: To: Mbone User in other country , help pls. > hi~~ all > (and sorry other people ) > > Now I plan to Mbone broadcasting > "Open concert by KBS(Korea Boradcasting Service)" to world. > I think it's the first realtime Korean TV Mbone broadcasting, > > so I need some help, 'Program director of Open Concert' want to > TV broadcaste "people who see the Mbone broadcasting(open concert)" > > I need people who can use 512Kbps or higher lines, and can use Mbone > tools(SD, SDR,NV, VAT, VIC) > is there any people who help me? > > I plan to broadcaste open concert July 7th 18:00 pm KST(sorry I cannot > find other standard time) > > If you can help me, please mail to me. > > World Internet Exposition 1996 Korean Organization, > Kim, Mansu(mskim2expo.or.kr, +82-2-3443-7585) > > ps) sorry If disturbing you, > > > From rem-conf-request@es.net Fri Jun 21 12:48:22 1996 Received: from piraya.electrum.kth.se by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jun 1996 09:47:30 -0700 Received: from it.kth.se (katla.it.kth.se [130.237.215.106]) by piraya.electrum.kth.se (8.7.3/8.7.3) with ESMTP id SAA03429; Fri, 21 Jun 1996 18:47:01 +0200 (MET DST) Message-Id: <199606211647.SAA03429@piraya.electrum.kth.se> X-Mailer: exmh version 1.6.2 7/18/95 To: Isabelle HAIGNERE cc: mskim@iexpo.expo.or.kr, rem-conf@es.net, mskim@expo.or.kr Subject: Re: To: Mbone User in other country , help pls. In-reply-to: Your message of "Fri, 21 Jun 1996 18:22:26 +0200." <9606211322.AA03509@haddock> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Jun 1996 18:46:58 +0200 From: Magnus Danielson > You have to be registered on the Mbone agenda at the web site Correction, "You have to be" should rather be "You are strongly recommended to be". http://www.cilea.it/MBone/agenda.html is BTW the URL to the agenda page. Magnus From rem-conf-request@es.net Fri Jun 21 14:20:18 1996 Received: from anduin.ocf.llnl.gov by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jun 1996 11:19:47 -0700 Received: from [134.9.49.103] (donnelley.ocf.llnl.gov) by anduin.ocf.llnl.gov (4.1/SMI-4.0) id AA07933; Fri, 21 Jun 96 11:19:36 PDT X-Sender: jed@anduin.ocf.llnl.gov Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jun 1996 11:19:40 -0800 To: Theresa-Marie Rhyne From: jed@llnl.gov (James E. [Jed] Donnelley) Subject: Re: computer graphics and networking (long) Cc: rem-conf@es.net, cunningham@siggraph.org I am happy to see that you are finding some additional opportunities for productive cross discipline dialog (other messages from you and others in this "Re: computer graphics and networking" thread). You made one comment that I feel strongly enough about to comment on: >this is the stuff some of us SIGGRAPH types -- who only claim to >be graphics types --- are concerned about... and the folks who >handle the networking world I immediately live in always seem to get >worried that graphics types like me will create such nifty >pictures and teach users how to do it themselves... that we will >overload the network...and get in the way of down to earth >functions like getting transactions processed like maybe paychecks >or something... Specifically I don't believe anybody should limit the extent to which graphics types "create such nifty pictures and teach users how to do it themselves" out of concern that they will overload the existing networks. This is unfortunately a fairly complex and controversial issue that the one sentence above cannot do justice to. I will be happy to entertain discussion of it, but I hope we can keep it off the list until some concensus is achieved that can be reported back to the list. Naturally I can't keep anyone >from responding to the list, but I will not reply to the list except in the form of a summary of a concensus should some develop at a future time. The issue is complicated by many special cases. One example is the MBONE - which is still more of a research vehicle than a production facility. Another concern are the aspects of the Internet that are still transitioning from government funded research to commercial services. In many cases research sites have higher bandwidth ports into the Internet than they could commercially justify. I believe this entails some special responsibility. I am sure there are many other special circumstances. Having said that, however, I do believe that people should feel free to put together any sorts of applications (graphics, distributed computing, distributed storage, etc.) that make effective (i.e. "nifty") use of available networking resources. If such applications can only be used in LANs or "intranets" currently where more bandwidth, lower latency, better reliability, less sharing, etc. are availble, so be it. If such applications are so useful that people try to use them on overloaded networks (e.g. the Internet) and exaccerbate the overloading problem, so be it. My belief is that it will only be by making all the applications available to the marketplace and letting people use them as best they can that we will affect transition of the Internet to a viable commercial entity with an effectively operating market mechanism. If there is going to be a crisis that results >from making such applications avaialable to the "public" (e.g. Internet "telephone" and/or "videophone" applications), then I would like to see us take the "hit" sooner rather than later so that we can more quickly transit to a network where the markets for such popular services can be exploited. --Jed http://www-atp.llnl.gov/atp/jed-signature.html From rem-conf-request@es.net Fri Jun 21 18:12:20 1996 Received: from wayback.uoregon.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jun 1996 15:11:37 -0700 Received: (from meyer@localhost) by wayback.uoregon.edu (8.7.5/8.7.1) id PAA08356; Fri, 21 Jun 1996 15:10:15 -0700 (PDT) Date: Fri, 21 Jun 1996 15:10:15 -0700 (PDT) Message-Id: <199606212210.PAA08356@wayback.uoregon.edu> From: "David M. Meyer 503/346-1747" To: mbone@ISI.EDU, rem-conf@es.net Subject: Reminder: Multicast Deployment BOF Folks, A BOF on Deployment of Multicast Routing is being planned for the IETF meeting in Montreal. The purpose of the BOF is to discuss the barriers to more ubiquitous multicast routing. In particular, NSPs and ISPs, as well as in others interested in multicast routing, are invited to attend and share their perspectives. Time: Monday, 24-Jun-1996 at 1300 Current BOF Organizer(s): David Meyer Draft Agenda ------------ I. Agenda Bashing II. Goals (i). Document Deployment History (a). Review any existing documents that may be relevant. For example, draft-ietf-idmr-traceroute-ipm-00.txt draft-rfced-info-semeria-00.txt <... (b). Possibly create a history document (ii). Document Multicast Routing Implementation Inventory (iii). Create Configuration Guidelines Documents DVMRP (mrouted, gated, Cisco, Bay, Alantec, ...) PIM (Cisco, gated, ....) MOSPF CBT (Bay, ...) Specification of protocol interoperatbility and interfaces? (iv). Document and standardize tools for operators, including (a). Document and standarize tools such as mtrace mrinfo mrdebug mrmap MIBs .... Specify what support is required (such as in the mtrace case). Also, there are a few tools that I would like for management purposes. Specification of these tools may have requirements on protocol implementations. (v). Create Practice & Experience Documents (vi). Host and router requirements for multicast requirements. Can we provide additional input for these documents? (vii). Document Deployment Objectives (a). Current interoperatability problems/issues (b). How to facilitate moving to native multicast (c). What is holding back large scale deployment? (d). Hierarchical multicast routing deployment Need guidelines. Also need volunteers to host "higher-level" RPs (in the PIM case). Also need coordination for the "HDVMRP" deployment. III. Action Items (a). Formation of working group? (b). Others? Please forward any addtional agenda items. Thanks, Dave From rem-conf-request@es.net Fri Jun 21 19:06:54 1996 Received: from Erich.Triumf.CA by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jun 1996 16:06:09 -0700 Received: from andrew.triumf.ca by Erich.Triumf.CA (MX V4.0-1 VAX) with SMTP; Fri, 21 Jun 1996 16:03:49 PST Date: Fri, 21 Jun 1996 16:10:56 -0700 (PDT) From: Andrew Daviel To: rem-conf@es.net Subject: ISDN and Mbone on one platform ?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Is there any one platform that will run both the Mbone tools (vat/vic) and ISDN H.321 conferencing software, preferably with only one operating system and one video grabber card ? How about 2 cards ? I believe that the Win95 version of vic is fully functional using the Matrox Meteor grabber ? Is there any ISDN system using this, or do they all use their own (e.g. PictureTel, Intel) ? Andrew Daviel email: advax@triumf.ca TRIUMF voice: 604-222-7376 From rem-conf-request@es.net Fri Jun 21 20:15:58 1996 Received: from piraya.electrum.kth.se by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jun 1996 17:15:07 -0700 Received: from it.kth.se (katla.it.kth.se [130.237.215.106]) by piraya.electrum.kth.se (8.7.3/8.7.3) with ESMTP id CAA08027; Sat, 22 Jun 1996 02:14:52 +0200 (MET DST) Message-Id: <199606220014.CAA08027@piraya.electrum.kth.se> X-Mailer: exmh version 1.6.2 7/18/95 To: Andrew Daviel cc: rem-conf@es.net From: Magnus Danielson Subject: Re: ISDN and Mbone on one platform ?? In-reply-to: Your message of "Fri, 21 Jun 1996 16:10:56 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Jun 1996 02:14:44 +0200 Sender: e93_mda@it.kth.se > Is there any one platform that will run both the Mbone tools (vat/vic) and > ISDN H.321 conferencing software, preferably with only one operating > system and one video grabber card ? I run mrouted 3.8, vic , vat, wb and sd on my home Indy. The Indy comes with ISDN, framegrabber and a camera (OK, not the best... plug in anotherone for better picture). ISDN migth be too tigth for some sessions, but better than 28.8 kbaud.... I don't know of the H.321 stuff, but I believe there migth be one around. No extra cards are needed. There where no specific magic in bringing it up and it behaivs pretty well. Note: When running Mrouted over an ISDN line which uses timeouts for bringing the line down (to save money usually :) both ends of the tunnels must be disabled, otherwise the Mrouted in the other end will continue to send routeing updates and by that keeping the line up, this is true even after you killed your local mrouted. There is several short cuts to bringing the line down. Magnus From rem-conf-request@es.net Fri Jun 21 21:45:52 1996 Received: from gatekeeper.sprintlabs.com (actually dmz.sprintlabs.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jun 1996 18:45:13 -0700 Received: by gatekeeper.sprintlabs.com id AA07981 (5.67b/IDA-1.5 for ); Fri, 21 Jun 1996 18:45:49 -0700 Message-Id: <199606220145.AA07981@gatekeeper.sprintlabs.com> Received: from unknown(199.2.53.28) by gatekeeper.sprintlabs.com via smap (V3.1) id xma007979; Fri, 21 Jun 96 18:45:43 -0700 X-Sender: aollikai@gatekeeper Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jun 1996 18:47:11 -0700 To: Andrew Daviel , Magnus Danielson From: ari@sprintlabs.com (Ari Ollikainen) Subject: Re: ISDN and Mbone on one platform ?? Cc: rem-conf@es.net >> Is there any one platform that will run both the Mbone tools (vat/vic) and >> ISDN H.321 conferencing software, preferably with only one operating >> system and one video grabber card ? > >I run mrouted 3.8, vic , vat, wb and sd on my home Indy. The Indy comes with >ISDN, framegrabber and a camera (OK, not the best... plug in anotherone for >better picture). ISDN migth be too tigth for some sessions, but better than >28.8 kbaud.... > >I don't know of the H.321 stuff, but I believe there migth be one around. > >No extra cards are needed. > InPerson2.0 won't do H.320, it's very IP centric (even when applied to ISDN), as shown by this excerpt from SGI's white paper on collaboration (see http://www.sgi.com/Products/collaborate/wp.html): "...InPerson 2.0 supports H.261, the video compression component of H.320, as well as several of the audio compression algorithms defined within H.320. These components support customers who conference over low-bandwidth services and provide for a higher number of simultaneous InPerson users on medium- and high-bandwidth networks. InPerson 2.0 does not support the H.221 and H.242 standards, because these standards are not applicable to the IP shared network environment in which the InPerson application is designed to run. ..." CLI, PictureTel, VTEL, VCON, Zydachron, and others, make single card PCI-bus PC/Windows/Windows95 ISDN H.320 solutions which generally integrate video&audio inputs (and sometimes outputs) on the same card. Sagem(USA) makes a single card PCI-bus (or Nubus) ISDN H.320 solution for AVcapable (Power)Macs... RSI systems makes an EXTERNAL ISDN H.320 codec which attaches to a PC, Mac, and, supposedly RealSoonNow, to a Ultra/SPARCstation using the SCSI interface. _/_/ _/_/_/_/ _/ Ari Ollikainen _/ _/ _/ _/ _/ Sprint Advanced Technology Laboratories _/_/_/_/ _/_/_/_/ _/ 1 Adrian Court (M/S: CABURS0102) _/ _/ _/ _/ _/ Burlingame, CA 94010 _/ _/ _/ _/ _/ Voice: 415 375 4265 FAX: 415 375 4490 ~~RECOM Technologies Inc.~~ From rem-conf-request@es.net Fri Jun 21 22:45:32 1996 Received: from piraya.electrum.kth.se by osi-west.es.net with ESnet SMTP (PP); Fri, 21 Jun 1996 19:44:43 -0700 Received: from it.kth.se (katla.it.kth.se [130.237.215.106]) by piraya.electrum.kth.se (8.7.3/8.7.3) with ESMTP id EAA09766; Sat, 22 Jun 1996 04:44:18 +0200 (MET DST) Message-Id: <199606220244.EAA09766@piraya.electrum.kth.se> X-Mailer: exmh version 1.6.2 7/18/95 To: ari@sprintlabs.com (Ari Ollikainen) cc: Andrew Daviel , Magnus Danielson , rem-conf@es.net, e93_mda@it.kth.se Subject: Re: ISDN and Mbone on one platform ?? In-reply-to: Your message of "Fri, 21 Jun 1996 18:47:11 PDT." <199606220145.AA07981@gatekeeper.sprintlabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Jun 1996 04:44:16 +0200 From: Magnus Danielson > InPerson2.0 won't do H.320, it's very IP centric (even when applied > to ISDN), as shown by this excerpt from SGI's white paper on > collaboration (see http://www.sgi.com/Products/collaborate/wp.html): InPerson never impressed me, that's why I use other tools... Magnus From rem-conf-request@es.net Sat Jun 22 13:10:53 1996 Received: from tec.oz.cc.utah.edu by osi-west.es.net with ESnet SMTP (PP); Sat, 22 Jun 1996 10:10:17 -0700 Received: from cor.oz.cc.utah.edu (root@cor-oz [155.99.2.2]) by tec.oz.cc.utah.edu (8.7.5/8.7.1) with ESMTP id LAA01948; Sat, 22 Jun 1996 11:02:21 -0600 (MDT) Received: (from lfp1035@localhost) by cor.oz.cc.utah.edu (8.7.1/8.7.1) id KAA14072; Sat, 22 Jun 1996 10:10:56 -0600 (MDT) Date: Sat, 22 Jun 1996 10:10:55 -0600 (MDT) From: Lombardo F Palma To: Med Inf List , agosta@sumex-aim.stanford.edu, ai-ed@sun.com, ai-medicine@croquet.Stanford.EDU, ai-nat@adfa.oz.au, ai-stats@watstat.uwaterloo.ca, aisb@cogs.sussex.ac.uk, announcements.chi@xerox.com, arl@arl.wustl.edu, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, ccrc@dworkin.wustl.edu, cellular@dfv.rwth-aachen.de, cip@bbn.com, cnom@maestro.bellcore.com, cogsci@cogsci.ed.ac.uk, cybsys-l@bingvmb.cc.binghamton.edu, diagrams@cs.swarthmore.edu, elsnet-list@cogsci.edinburgh.ac.uk, end2end-interest@isi.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, fj-ai@etl.go.jp, g-troup@dworkin.wustl.edu, globecom@signet.com.sg, hipparch@sophia.inria.fr, icad-request@santafe.edu, IE-list@cs.ucl.ac.uk, ietf@isi.edu, ikbsbb@inf.rl.ac.uk, iplpdn@cnri.reston.va.us, ircpeople@cogsci.ed.ac.uk, John Lee , kdd@gte.com, met-ai@comp.vuw.ac.nz, mmws@caad.ed.ac.uk, perform@tay1.dec.com, rem-conf@es.net, schulzrinne@fokus.gmd.de, sig11@roses.stanford.edu, sigmedia@bellcore.com, smds@cnri.reston.va.us, sound@ACM.ORG, tccc@cs.umass.edu, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, xtp-relay@cs.concordia.ca Subject: Re: Automated Stroke Registry (ASR) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, First, I apologize for any double postings. I just submitted a grant proposal to my hospital charitable foundation for an automated stroke registry (ASR). I wonder if anyone has experience with this matter. I will appreciate any info or leads in this regard. The funding results will not be available till the end of next month. Sincerely, Lombardo F. Palma, M.D., MSPH 801-566-7701 Office Voice Office: 1847 West 9000 South 801-566-7704 Office Facsimile West Jordan, UT 84088 lombardo.palma@m.cc.utah.edu Email ************************************************************************** From rem-conf-request@es.net Sun Jun 23 23:20:34 1996 Received: from emout09.mail.aol.com (actually emout09.mx.aol.com) by osi-west.es.net with ESnet SMTP (PP); Sun, 23 Jun 1996 20:19:43 -0700 Received: by emout09.mail.aol.com (8.6.12/8.6.12) id XAA13542 for rem-conf@es.net; Sun, 23 Jun 1996 23:20:30 -0400 Date: Sun, 23 Jun 1996 23:20:30 -0400 From: GVSI@aol.com Message-ID: <960623232029_337428731@emout09.mail.aol.com> To: rem-conf@es.net cc: GVSI@aol.com Subject: Fwd: New Web Page --------------------- Forwarded message: From: gvsi@ix.netcom.com (Megan Kirst) To: CU-SEEME-L@cornell.edu, videophone@es.net Date: 96-06-23 22:48:18 EDT We have just gotten our web page up and running! If you would like to get pricing on some of the latest videoconferencing equipment, please visit us at www.GLOBALVIDEOCONF.com Thanks Global Videoconferencing Solutions, Inc. 1-800-909-4874 From rem-conf-request@es.net Mon Jun 24 00:38:45 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sun, 23 Jun 1996 21:38:11 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA06447; Sun, 23 Jun 1996 21:38:09 -0700 Date: Sun, 23 Jun 1996 21:38:09 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: A busy week on the MBone Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There are several simultaneous events on the MBone this week: the NASA shuttle, two channel of IETF, one channel of INET'96, and the CERN ATLAS meeting. There's only partial time overlap for CERN, but at times there will be at least 4 and possibly 5 audio+video sessions. There was a precedent of 4 when IETF and SIGGRAPH collided, but we were careful to reduce the bandwidth of each. I would advise that all these sessions be transmitted with an audio encoding of DVI4 (or GSM, which is lower bandwidth, if you've already chosen that) and with a maximum video bandwidth set to 64 kb/s or so. -- Steve From rem-conf-request@es.net Mon Jun 24 04:45:05 1996 Received: from radvision.rad.co.il by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Jun 1996 01:44:07 -0700 Received: by firewall.radvision.rad.co.il id <24193>; Mon, 24 Jun 1996 12:39:19 +0300 From: neta@purple (Neta Weinryb) Message-Id: <96Jun24.123919idt.24193@firewall.radvision.rad.co.il> Date: Mon, 24 Jun 1996 14:43:26 +0300 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: rem-conf@es.net Subject: mbone protocols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, Can someone tell me what audio and video protocols are used for the Mbone broadcasts? From rem-conf-request@es.net Mon Jun 24 05:14:50 1996 Received: from cancer.ucs.ed.ac.uk (actually 129.215.16.3) by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Jun 1996 02:14:08 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with SMTP id KAA25302 for ; Mon, 24 Jun 1996 10:14:06 +0100 Date: Mon, 24 Jun 1996 10:14:03 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: rem-conf@es.net Subject: Re: mbone protocols In-Reply-To: <96Jun24.123919idt.24193@firewall.radvision.rad.co.il> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 24 Jun 1996, Neta Weinryb wrote: > Hi, > > Can someone tell me what audio and video protocols are used for the Mbone > broadcasts? I don't think you nice people on rem-conf will be able to reply to this message, as I don't think this system runs a mail system. I will try and track this person down locally and answer the question (now I just have to figure out who this is). ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Mon Jun 24 14:16:54 1996 Received: from spock.dis.cccd.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Jun 1996 11:16:03 -0700 Received: (from markb@localhost) by spock.dis.cccd.edu (8.7.5/8.7.3) id LAA02688 for rem-conf@es.net; Mon, 24 Jun 1996 11:16:01 -0700 (PDT) From: Mark Bixby Message-Id: <199606241816.LAA02688@spock.dis.cccd.edu> Subject: subscribing to mbone@isi? To: rem-conf@es.net Date: Mon, 24 Jun 1996 11:16:00 -0700 (PDT) Reply-To: markb@cccd.edu X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit What does it take to subscribe to mbone@isi.edu? I sent in a subscribe command to their majordomo, which said that subscriptions needed to be approved by the list owner. Fine; so I waited for 5 days without any response. Then I sent e-mail to mbone-approval (the list owner address mentioned by majordomo), and still no response after another 5 days or so. Is mbone@isi by invitation only? I just put my site on the mbone and would like to join this list so I can keep informed about operational and architectural issues. I've been reading the list archives on the web, and the subject content seems quite useful. Thanks. -- Mark Bixby E-mail: markb@cccd.edu Coast Community College Dist. Web: http://www.cccd.edu/~markb/ District Information Services 1370 Adams Ave., Costa Mesa, CA, USA 92626-5429 Technical Support +1 714 432-5865 x7064 "You can tune a file system, but you can't tune a fish." - tunefs(1M) From rem-conf-request@es.net Mon Jun 24 17:05:16 1996 Received: from piper.cs.colorado.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Jun 1996 14:04:34 -0700 Received: (from evi@localhost) by piper.cs.colorado.edu (8.7.5/8.7.3) id PAA27786; Mon, 24 Jun 1996 15:04:28 -0600 (MDT) Date: Mon, 24 Jun 1996 15:04:28 -0600 (MDT) From: Evi Nemeth Message-Id: <199606242104.PAA27786@piper.cs.colorado.edu> To: casner@precept.com, rem-conf@es.net Subject: Re: A busy week on the MBone Cc: evi@piper.cs.colorado.edu the ietf sessions are using dvi4 and our video is rate limited at 64k with the sending slides option turned on. -evi From rem-conf-request@es.net Mon Jun 24 17:07:17 1996 Received: from necom830.hpcl.titech.ac.jp by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Jun 1996 14:06:49 -0700 From: Masataka Ohta Message-Id: <199606242057.FAA07478@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id FAA07478; Tue, 25 Jun 1996 05:57:09 +0900 Subject: More strict MPEG profiling & RTP URL To: rem-conf@es.net Date: Tue, 25 Jun 96 5:57:08 JST X-Mailer: ELM [version 2.3 PL11] Dear AVT WG members; We'd like to discuss on the attached proposal (to DAVIC last week) on more strict profiling of MPEG2 (for interoperability without NEGOTIATION). It is designed to work with MTU of 1500 and for easy interoperation with DAVIC format. That is, we want to use DAVIC complient equipments on the Internet environment with the least modification. We'd also want to discuss on URL for RTP on whether we need it or not and how it, if any, should be. Masataka Ohta =====================================8x--------------------------------------- Title: Using RTP for Internet access Document No.: DAVIC/SUB/96/06/ Place/Date: New York, June 17-22,1996 Purpose: Contribution of GCL in response to CFP4_012 Topic: Access to services of the Internet Source: Graphics Communication Laboratories Authors: Koji Okamura oka@kobe-u.ac.jp Masataka Ohta mohta@necom830.hpcl.titech.ac.jp Shinji Shimojo shimojo@center.osaka-u.ac.jp Hiroaki Kago kago@olu.info.waseda.ac.jp Address: 6F Annex Thoshin Bldg.,4-36-19,Yoyogi,Shibuya-Ku,Tokyo 151,JAPAN Telephone: +81-3-5351-0181 Fax: +81-3-5351-0185 o Introduction Considering that DAVIC provides MPEG-2 audio/video into the Interment, four fundamental difference are exist with respect to the ATM network as follows: 1) heterogeneuity of bandwidth The Internet has wide variety of bandwidth from 14.4Kbps modem connection through 150Mbps ATM conneciton. 2) heterogeneuity of set top Internet has a wide variety of terminals such as workstations and PCs each of which has different CPU power. Therefore, the acceptable audio/video rate of terminals varies depending on their hardware configurations. 3) service model Currently Internet provides only best-effort service model and is not suitable for the real-time audio and video transmission. For the real-time audio and video transmission, it is strongly desired to provide the gualanteed of QoS service model. The major factors of QoS describe below. o hardware resource reservation o bandwidth reservation o jitter control 4) relatively high jitter Some jitter is inevitable with large MTU over shared slow (ADSL, 10 base T, ...) link. To handle the heterogeneuity of Internet, one possible scenario is that a server provides various class of services which require different bandwidth and a client selects an appropriate class of service based on its environment and requests it. For sending audio/video service, RealTime Protocol (RTP) is proposed in IETF. In this paper, we propose possible class of services for MPEG/MPEG-2 which clients can select depending on their environment and various class of service which can be applyed to RTP. We also propose an URL extention by which a client can select a service class for MPEG/MPEG-2 transmission. 1) For hardware resource reservation To use MPEG2 classified profile for exchaging the information of encoder/decoder abilities between DAVIC HTTP gateway and STB. 2) For bandwidth reservation To use the resource reservation protocol like RSVP. RSVP is under consideration on IETF. In this contribution, we don't mention for this topic. 3) For jitter control Use time stamp of RTP header additionally, for the interroperability to existing IP multimedia applications. +------------- Internet -------------+ | +-------------+ | | | Session and | | | | Resource +---------+ | | | Manager(SRM)| | | | +------+------+ +------+------+ | | | | DSMCC/HTTP | | | | | Gateway | | | | | Gateway | | | | +---++---++---+ | | +------+------+ || || | | | Content +======++ || | | | Service | || | | | Element(CSE)+======++ || | | +-------------+ || || | +-----------------------||---||------+ || || +---++---++---+ | WWW Browser | | STB/PC/WS | +-------------+ o MPEG2-TS over IP Some packet overhead (RTP=12, UDP=4, IP=20 or 40...) Defact default MTU of 1500 -----> 7 Tses (1316B) in an IP packet o Classfied MPEG Profile 1) Video Profile o Profile and Level +------------------------+-----------------------------------------+ | Profile and Level | SP@ML,MP@HL,MP@H-14,MP@ML,MP@LL,SNR@ML, | | | SNR@LL,Spatial@H-14,HP@HL,HP@H-14,HP@ML | +------------------------+-----------------------------------------+ o SP@ML,MP@ML,SNR@ML +------------------------+-------------------+ | Band Width[Mbps] | 3,6,9,15 | +------------------------+-------------------+ | Pixels Per Line | 352,360,704,720 | +------------------------+-------------------+ | Lines Per Frame | 240,288,480,576 | +------------------------+-------------------+ | Frames Per Seconds[Hz] | 25,30 | +------------------------+-------------------+ o Audio Profile +--------------------+--------------------------------+ | Band Width[kbps] | 96,128,160,192,224,256,320,384 | +--------------------+--------------------------------+ | Sampling Rate[kHz] | 44.1,48,32 | +--------------------+--------------------------------+ | Mode | stereo,single channel | +--------------------+--------------------------------+ o Mandatory Profile We propose to determine the mandatory profile. The SPS(Service Provider System) must support one of SP@ML/MP@ML profiles. The SCS(Service Consumer System) must support all of SP@ML/MP@ML profiles. o SP@ML,MP@ML +------------------------+---------+ | Band Width[Mbps] | 6 | +------------------------+---------+ o Audio Profile +--------------------+--------+ | Band Width[kbps] | 192 | +--------------------+--------+ | Sampling Rate[kHz] | 48 | +--------------------+--------+ | Mode | stereo | +--------------------+--------+ o Port Number +-------------+------+ | Port Number | 5004 | +-------------+------+ * RFC-1890 o URL Notation URL notation for RTP including, but not limited to MPEG2. URL notaion looks like this. rtpurl = "rtp." enctype "://" hostport [[ ";bwv=" bwvvalue ] [ ";ppl=" pplvalue ] [ ";lpf=" lpfvalue ] [ ";fps=" fpsvalue ] [ ";bwa=" bwavalue ] [ ";sr=" srvalue ] [ ";ch=" chvalue ]] enctype = "mpeg2" [ "." pltype ] | "mpeg1" | "h261" | "celb" pltype = "spml" | "mphl" | "mph1440" | "mpml" | "mpll" | "snrml" | "snrll" | "spatialh1440" | "hphl" | "hph1440" | "hpml" hostport = host [ ":" port ] bwvvalue = NUMBER pplvalue = NUMBER lpfvalue = NUMBER fpsvalue = NUMBER bwavalue = NUMBER srvalue = NUMBER chvalue = "mono" | "lr" | "lrc" | "FlFrRlRr" | "lcrS" | "FlFrFcSlSr" | "llccrrcS" ex.) URL: rtp.mpeg2://www.olu-dmp.olu.ad.jp:5004/ Default values Port: 5004 Profile & Level: MP@ML (with MPEG2 audio) Bandwidth for Video: 6Mbps o References H.Schulzrinne,S.Casner,R.Frederick and V.Jacobson, "RTP A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. H.Schulzrinne, "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996. Don Hoffman and Vivek Goyal, "RTP Payload Format for MPEG1/MPEG2 Video", Internet Draft, November 1995. =====================================8x--------------------------------------- From rem-conf-request@es.net Mon Jun 24 23:19:59 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 24 Jun 1996 20:19:28 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA08949; Mon, 24 Jun 1996 20:18:51 -0700 Date: Mon, 24 Jun 1996 20:18:51 -0700 (PDT) From: Stephen Casner To: markb@cccd.edu Cc: rem-conf@es.net Subject: Re: subscribing to mbone@isi? In-Reply-To: <199606241816.LAA02688@spock.dis.cccd.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 24 Jun 1996, Mark Bixby wrote: > What does it take to subscribe to mbone@isi.edu? > > I sent in a subscribe command to their majordomo, which said that > subscriptions needed to be approved by the list owner. Fine; so I > waited for 5 days without any response. Then I sent e-mail to > mbone-approval (the list owner address mentioned by majordomo), and > still no response after another 5 days or so. You need to subscribe to mbone-na sublist (for North America) rather than the top-level mbone list. The top level list only has sublists on it, hence the rejection. It has been a year now since I left ISI, so I no longer have anything directly to do with the mbone list. However, I did suggest to the folks who take care of the list that the message returned in response to a request to join the top-level list should tell the requestor about the hierarchical structure and list the regional sublists. I guess that has not been done. -- Steve From rem-conf-request@es.net Tue Jun 25 10:33:45 1996 Received: from juliet (actually juliet.wiltel.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 07:32:25 -0700 Received: from phantom.wcom.com (actually host phantom.wiltel.com) by juliet; Tue, 25 Jun 1996 09:31:42 -0500 Received: by phantom.wcom.com (4.1/SMI-4.1) id AA07650; Tue, 25 Jun 96 09:36:23 CDT From: chris.whittenburg@wcom.com (Chris Whittenburg) Message-Id: <9606251436.AA07650@phantom.wcom.com> Subject: Parallax support To: rem-conf@es.net Date: Tue, 25 Jun 1996 09:36:22 -0500 (CDT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 360 UUEncode: TRUE Is nv the only mbone application with support for the Parallax Xvideo/Powervideo cards? The notes for vic mention that it has yet to be added, but that there are plans for this? thanks, chris -- Chris Whittenburg Data Network Mechanic (918) 590-5845 LDDS Worldcom chris.whittenburg@wcom.com Me. From rem-conf-request@es.net Tue Jun 25 11:03:47 1996 Received: from cancer.ucs.ed.ac.uk (actually 129.215.166.13) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 08:03:10 -0700 Received: from kfarvis-test-1 (kfarvis-test-1.ucs.ed.ac.uk [129.215.200.63]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with SMTP id QAA03530; Tue, 25 Jun 1996 16:02:49 +0100 Date: Tue, 25 Jun 1996 16:07:09 +0100 (BST) From: Graeme Wood X-Sender: jaw@kfarvis-test-1 Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Chris Whittenburg cc: rem-conf@es.net Subject: Re: Parallax support In-Reply-To: <9606251436.AA07650@phantom.wcom.com> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 25 Jun 1996, Chris Whittenburg wrote: > > Is nv the only mbone application with support for the > Parallax Xvideo/Powervideo cards? The notes for vic > mention that it has yet to be added, but that there are > plans for this? vic has supported Parallax for ages. I think the documentation must be out of date or you have a very old version. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Tue Jun 25 11:08:33 1996 Received: from spock.dis.cccd.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 08:08:05 -0700 Received: (from markb@localhost) by spock.dis.cccd.edu (8.7.5/8.7.3) id IAA24396; Tue, 25 Jun 1996 08:08:02 -0700 (PDT) From: Mark Bixby Message-Id: <199606251508.IAA24396@spock.dis.cccd.edu> Subject: Re: subscribing to mbone@isi? To: casner@precept.com (Stephen Casner) Date: Tue, 25 Jun 1996 08:08:01 -0700 (PDT) Cc: rem-conf@es.net Reply-To: markb@cccd.edu In-Reply-To: from "Stephen Casner" at Jun 24, 96 08:18:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Stephen Casner writes: > You need to subscribe to mbone-na sublist (for North America) rather > than the top-level mbone list. The top level list only has sublists > on it, hence the rejection. Thanks, that did the trick. The mbone list web archive I had been poking around in didn't mention that it was sublisted, hence I automatically tried to subscribe to mbone instead of mbone-na. > It has been a year now since I left ISI, so I no longer have anything > directly to do with the mbone list. However, I did suggest to the > folks who take care of the list that the message returned in response > to a request to join the top-level list should tell the requestor > about the hierarchical structure and list the regional sublists. I > guess that has not been done. Yes, you just get back the vanilla majordomo text that doesn't mention the sublists. -- Mark Bixby E-mail: markb@cccd.edu Coast Community College Dist. Web: http://www.cccd.edu/~markb/ District Information Services 1370 Adams Ave., Costa Mesa, CA, USA 92626-5429 Technical Support +1 714 432-5865 x7064 "You can tune a file system, but you can't tune a fish." - tunefs(1M) From rem-conf-request@es.net Tue Jun 25 12:15:48 1996 Received: from trout.nosc.mil by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 09:14:59 -0700 Received: from cod.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA21645; Tue, 25 Jun 96 09:14:57 PDT Received: from dilbert.nosc.mil (dilbert-eth.nosc.mil) by cod.nosc.mil (4.1/SMI-4.1) id AA04894; Tue, 25 Jun 96 09:11:57 PDT Date: Tue, 25 Jun 1996 09:11:45 -0700 (PDT) From: ganzer@nosc.mil Sender: ganzer@dilbert.nosc.mil Reply-To: ganzer@nosc.mil Subject: Re: Parallax support To: Chris Whittenburg Cc: rem-conf@es.net In-Reply-To: <9606251436.AA07650@phantom.wcom.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > > Is nv the only mbone application with support for the > Parallax Xvideo/Powervideo cards? The notes for vic > mention that it has yet to be added, but that there are > plans for this? You need the latest beta version (2.7b1 or b2) of vic available in the conferencing/vic/alpha-test directory at ftp.ee.lbl.gov. The Sun binaries (both SunOS and Solaris) have support for the Parallax card compiled in. Vic 2.7 even has a built-in JPEG->h261 transcoder that reduces the CPU load on the machine, although this feature appears to be broken on Solaris 2.5/UltraSPARC machines. The question I have is what Parallax libraries are needed to compile a binary with Parallax support? Do I need to purchase the Parallax Video Developers Environment to do this? Mark Ganzer Naval Command, Control & Ocean Surveillance Center, ganzer@nosc.mil RDT&E Div (NRaD), Code 4123, San Diego, CA Ph: (619) 553-1186 FAX: (619) 553-4808 From rem-conf-request@es.net Tue Jun 25 12:54:23 1996 Received: from fun.inria.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 09:52:46 -0700 Received: by fun.inria.fr (8.7.5/8.6.12) id SAA18981; Tue, 25 Jun 1996 18:50:26 +0200 (MET DST) Message-Id: <199606251650.SAA18981@fun.inria.fr> X-Mailer: exmh version 1.6.5 12/11/95 To: rem-conf@es.net, merci@cs.ucl.ac.uk Subject: Release of FreePhone audio tool X-url: http://www.inria.fr/rodeo/avega.html Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Jun 1996 18:50:25 +0200 From: Andres Vega Garcia This is to announce that release 2.0b2 of the Free Phone audio tool (fphone) is now available from INRIA on ftp://zenon.inria.fr/rodeo/fphone/ This release includes a number of features such as * A redundancy mechanism that can reconstruct up to 4 consecutively lost packets. The mechanism can be controlled manually, or automatically. In the later case, it is coupled with a feedback rate control mechanism (using RTCP feedback). We have found that it provides decent quality audio even with high loss rates. * The usual assortment of codecs that span rates from 5.6 to 64 kbits/s (assuming 8 kHz/8 bit sampling), including PCM, VADPCM, ADPCM (6-2), GSM, and LPC. * High quality audio, provided by sampling at rates up to 48Khz * Compatibility with VAT (used in RTP2 mode with the `-r' option) when neither the redundancy nor the high sampling rate is turned on. Both redundancy and high quality audio data are sent using special payload types (as discussed this week at the Montreal IETF meeting) * Compatibility with RAT. * Support for the following platforms/OS - SunOS 4.1.3, - Solaris 2.4,2.5, - and Linux v1.3.xx. Refer to the Free Phone Web page at URL http://www.inria.fr/rodeo/fphone/ for additional information. Please do send your comments to fphone-dev@sophia.inria.fr From rem-conf-request@es.net Tue Jun 25 12:59:51 1996 Received: from spock.dis.cccd.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 09:58:56 -0700 Received: (from markb@localhost) by spock.dis.cccd.edu (8.7.5/8.7.3) id JAA26679 for rem-conf@es.net; Tue, 25 Jun 1996 09:58:55 -0700 (PDT) From: Mark Bixby Message-Id: <199606251658.JAA26679@spock.dis.cccd.edu> Subject: vic2.7b3/win95 weirdness To: rem-conf@es.net Date: Tue, 25 Jun 1996 09:58:54 -0700 (PDT) Reply-To: markb@cccd.edu X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I'm running vic2.7b3 under win95. I'm also running Netscape Navigator Gold 3.0b4, and PCN 1.00a (http://www.pointcast.com). Generally when the PCN screen saver is active (but not always), vic will pop up a tiny error window that says something like "sendto error: 10035". Clicking on OK (?) closes the window, and vic may continue or not. Sometimes vic will die with "program has requested an illegal operation" (?); other times it will be Netscape that dies with the same condition. I fully expect fun interactions between alpha software (vic) and beta software (Netscape), but I was wondering if anybody else is having this problem too. Netscape and PCN work just fine when I'm not running vic. -- Mark Bixby E-mail: markb@cccd.edu Coast Community College Dist. Web: http://www.cccd.edu/~markb/ District Information Services 1370 Adams Ave., Costa Mesa, CA, USA 92626-5429 Technical Support +1 714 432-5865 x7064 "You can tune a file system, but you can't tune a fish." - tunefs(1M) From rem-conf-request@es.net Tue Jun 25 14:20:19 1996 Received: from unb.ca (actually hermes.csd.unb.ca) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 11:19:08 -0700 Received: (from cythera.unb.ca [131.202.3.18]) by unb.ca (8.7.5/960430-08:40) id PAA24724; Tue, 25 Jun 1996 15:19:06 -0300 (ADT) Received: (from cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.7.5/8.7.1) with SMTP id PAA19435; Tue, 25 Jun 1996 15:19:05 -0300 (ADT) Date: Tue, 25 Jun 1996 15:19:05 -0300 (ADT) From: "Dwight E. Spencer" To: Don Brutzman cc: rem-conf@es.net Subject: Re: A busy week on the MBone In-Reply-To: <9606251731.AA09415@cs.nps.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 25 Jun 1996, Don Brutzman wrote: > We're still seeing loss from STS-78. I am wondering why people are reluctant > to use redundant codings (forward error correction) using the rat tool. > That seems to make a big difference with loss rates around 10%. probably for the same reason as myself, vat is still the most "popular" (for lack of a better term) tool for audio. I tried a few of the people in the IETF and Net96 meeting listings, and a lot are still running vat. to get a big push on using rat, people will probably need to start trasmitting with it by default (as seems to have happened with using VIC instead of NV). secondly, getting to cs.ucl.ac.uk to get into /mice/* to get the tools sometimes can be a trying experience from this side of the atlantic. I currently have all the (latest I believe) tools for sparc solaris 2 if anyone wants to get them (wb/nt/vic etc etc..) from ftp://cnet.unb.ca/pub/internet/multicast/solaris/tools/ dwight spencer. ----------------------------------------------------------------------- Dwight E. Spencer Canada's Community Access Network eMail: spencer@unb.ca, Server Administrator UNB, Fredericton, NB, Canada Phone: +1 506 447 3153 Url: http://cspace.unb.ca/~spencer/ From rem-conf-request@es.net Tue Jun 25 16:01:59 1996 Received: from cs.nps.navy.mil by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 13:01:10 -0700 Received: from medusa.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA15845; Tue, 25 Jun 96 13:00:07 PDT Received: by medusa.cs.nps.navy.mil (950215.SGI.8.6.10) id NAA01363; Tue, 25 Jun 1996 13:00:07 -0700 From: NPSNET Research Group Message-Id: <9606251300.ZM1361@medusa.cs.nps.navy.mil> Date: Tue, 25 Jun 1996 13:00:06 -0700 X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: rem-conf@es.net Subject: PlayDay June 28, 1996 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii We will be creating DIS trafic on Multicast group 224.2.121.93 from 8:00am to 12:00pm (PST). If you would like more information about PlayDay see: http://www-npsnet.cs.nps.navy.mil/npsnet/playday/index.html Please send questions to: npsnet@cs.nps.navy.mil -NPSNET Research Group From rem-conf-request@es.net Tue Jun 25 16:21:21 1996 Received: from unb.ca (actually hermes.csd.unb.ca) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 13:20:42 -0700 Received: (from cythera.unb.ca [131.202.3.18]) by unb.ca (8.7.5/960430-08:40) id RAA16982; Tue, 25 Jun 1996 17:20:36 -0300 (ADT) Received: (from cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.7.5/8.7.1) with SMTP id RAA20513; Tue, 25 Jun 1996 17:20:31 -0300 (ADT) Date: Tue, 25 Jun 1996 17:20:31 -0300 (ADT) From: "Dwight E. Spencer" To: Russell Sutherland cc: rem-conf@es.net Subject: Re: vat/rat and X terminals In-Reply-To: <199606252016.QAA19879@madhaus.utcs.utoronto.ca> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 25 Jun 1996, Russell Sutherland wrote: > Do you know if vat or rat support the NAS X audio stuff > so that an Xterminal can listen to the audio portions > of an MBONE broadcast? Hmm.. I've never seen reference to this in the documentation, but the developers may be able to point you in the right direction. dwight spencer. ----------------------------------------------------------------------- Dwight E. Spencer Canada's Community Access Network eMail: spencer@unb.ca, Server Administrator UNB, Fredericton, NB, Canada Phone: +1 506 447 3153 Url: http://cspace.unb.ca/~spencer/ From rem-conf-request@es.net Tue Jun 25 16:22:44 1996 Received: from nautique.epm.ornl.gov (actually nautiquee.epm.ornl.gov) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 13:20:44 -0700 Received: from nautique (lpz@localhost [127.0.0.1]) by nautique.epm.ornl.gov (8.7.4/8.7.3) with SMTP id QAA05479; Tue, 25 Jun 1996 16:20:25 -0400 (EDT) Sender: lpz@nautique.epm.ornl.gov Message-ID: <31D04A08.FF6@nautique.epm.ornl.gov> Date: Tue, 25 Jun 1996 16:20:24 -0400 From: Lawrence Macintyre Organization: Oak Ridge National Laboratory X-Mailer: Mozilla 3.0b3 (X11; I; OSF1 V3.2 alpha) MIME-Version: 1.0 To: "Dwight E. Spencer" CC: rem-conf@es.net Subject: Re: A busy week on the MBone References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dwight E. Spencer wrote: > > On Tue, 25 Jun 1996, Don Brutzman wrote: > > We're still seeing loss from STS-78. I am wondering why people are reluctant > > to use redundant codings (forward error correction) using the rat tool. > > That seems to make a big difference with loss rates around 10%. > > probably for the same reason as myself, vat is still the most "popular" > (for lack of a better term) tool for audio. I tried a few of the people > in the IETF and Net96 meeting listings, and a lot are still running vat. > to get a big push on using rat, people will probably need to start > trasmitting with it by default (as seems to have happened with using VIC > instead of NV). > > secondly, getting to cs.ucl.ac.uk to get into /mice/* to get the tools > sometimes can be a trying experience from this side of the atlantic. Also, vat is supported on more OSs, and the code is available. -- Lawrence ~ ------------------------------------------------------------------------ Lawrence MacIntyre Oak Ridge National Laboratory 423.574.8696 lpz@ornl.gov http://www.epm.ornl.gov/~lpz lpz@nautique.epm.ornl.gov From rem-conf-request@es.net Tue Jun 25 17:32:31 1996 Received: from cs.nps.navy.mil by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 10:33:11 -0700 Received: from libra.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA09415; Tue, 25 Jun 96 10:31:58 PDT From: brutzman@cs.nps.navy.mil (Don Brutzman) Message-Id: <9606251731.AA09415@cs.nps.navy.mil> Subject: Re: A busy week on the MBone To: casner@precept.com (Stephen Casner) Date: Tue, 25 Jun 1996 10:31:56 -0700 (PDT) Cc: rem-conf@es.net In-Reply-To: from "Stephen Casner" at Jun 23, 96 09:38:09 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Content-Length: 477 We're still seeing loss from STS-78. I am wondering why people are reluctant to use redundant codings (forward error correction) using the rat tool. That seems to make a big difference with loss rates around 10%. all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman From rem-conf-request@es.net Tue Jun 25 18:40:22 1996 Received: from broon.off.connect.com.au by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 15:39:23 -0700 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id IAA22091 (8.7.4/IDA-1.6); Wed, 26 Jun 1996 08:38:53 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs X-Mailer: exmh version 1.6.6 3/24/96 To: "Dwight E. Spencer" cc: Russell Sutherland , rem-conf@es.net Subject: Re: vat/rat and X terminals In-reply-to: Your message of "Tue, 25 Jun 1996 17:20:31 -0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Jun 1996 08:38:48 +1000 Message-ID: <22090.835742328@connect.com.au> From: George Michaelson On Tue, 25 Jun 1996, Russell Sutherland wrote: > Do you know if vat or rat support the NAS X audio stuff > so that an Xterminal can listen to the audio portions > of an MBONE broadcast? Hmm.. I've never seen reference to this in the documentation, but the developers may be able to point you in the right direction. I asked Van about this a couple of years ago. NAS implements a model of audio data on the network which is inherently hard to scale. It seemed to presume a model of audio need relating to "click on a button and get a bing" or of other programmatic sourced audio info. re-layering it into multicast is probably non-trivial. I think there was a reluctance of the Author to put gross hacks into the code. I believe NAS and AF have been tabling some kind of merged effort for some time (maybe inside X consortium) and that given AF's ability to do timing and event driven i/o its possible good things would happen that way. Maybe people from BROADWAY can comment. Meantime, if you really really wanted to, I guess you could write something that listened on an AF portal and re-injected into NAS. vat can already do the inject side of that via some cmdline arg to specify the AF device to send audio to. I had something evil which did named socket i/o long long ago but the buffering never worked right and the output was just awful. I threw the code away, but it was only 20 lines or so... -George -- George Michaelson | connect.com.au pty/ltd Email: ggm@connect.com.au | c/o AAPT, Phone: +61 7 3834 9976 | level 8, the Riverside Centre, Fax: +61 7 3834 9908 | 123 Eagle St, Brisbane QLD 4000 From rem-conf-request@es.net Wed Jun 26 00:34:59 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 21:34:28 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA11856; Tue, 25 Jun 1996 21:34:10 -0700 Date: Tue, 25 Jun 1996 21:34:09 -0700 (PDT) From: Stephen Casner To: Andres Vega Garcia Cc: rem-conf@es.net, merci@cs.ucl.ac.uk Subject: Re: Release of FreePhone audio tool In-Reply-To: <199606251650.SAA18981@fun.inria.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Both redundancy and high quality audio data are sent using special > payload types (as discussed this week at the Montreal IETF meeting) Are these dynamic payload types (96-127) defined through sdr or some other similar mechanism, or are they stolen static types? One of my crusades as AVT chair is to get people to understand and implement dynamic payload types. -- Steve From rem-conf-request@es.net Wed Jun 26 02:02:05 1996 Received: from janus.jnl.com (actually janus.industries.net) by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 23:01:30 -0700 Received: (from smap@localhost) by janus.jnl.com (8.7.1/8.7.1) id XAA22760; Tue, 25 Jun 1996 23:09:33 -0700 (PDT) Received: from zeus.industries.net(199.245.106.6) by janus.jnl.com via smap (V1.3) id sma022757; Tue Jun 25 23:09:18 1996 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 25 Jun 1996 23:06:43 -0700 To: rem-conf@es.net From: John Larson Subject: Which ISPs in SF Bay area assist in providing MBone connections ? Cc: jlarson@industries.net Folks, I want to get connected to the MBone, but my current ISP has so far been uninterested in being helpful. Does anyone have a recommendation for an ISP in the SF Bay area which *would* be helpful in getting me setup with an MBone tunnel ? Thanks much, John Larson Internet Industries, Inc. From rem-conf-request@es.net Wed Jun 26 02:17:06 1996 Received: from radvision.rad.co.il by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 23:16:31 -0700 Received: by firewall.radvision.rad.co.il id <24193>; Wed, 26 Jun 1996 10:11:34 +0300 From: neta@purple (Neta Weinryb) Message-Id: <96Jun26.101134idt.24193@firewall.radvision.rad.co.il> Date: Wed, 26 Jun 1996 12:17:08 +0300 X-Mailer: Z-Mail (3.2.2 10apr95 MediaMail) To: rem-conf@es.net Subject: audio/video protocols Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, I'm trying to figure out what audio/video protocols are used for mbone multicasts. Any help will be most appriciated. -- +++++++++++++++++++++++++++++++++++++++++++++++++++++ Neta Weinryb Tel 972-3-645-5258 RADVision Ltd., ISRAEL Fax 972-3-647-6669 neta@radvision.rad.co.il VDO 972-3-648-9010 From rem-conf-request@es.net Wed Jun 26 02:37:23 1996 Received: from sonne.darmstadt.gmd.de by osi-west.es.net with ESnet SMTP (PP); Tue, 25 Jun 1996 23:36:35 -0700 Received: from ilm.darmstadt.gmd.de (ilm [141.12.35.128]) by sonne.darmstadt.gmd.de (8.7.3/8.7.3) with ESMTP id IAA10509 for ; Wed, 26 Jun 1996 08:36:30 +0200 (MET DST) From: Joerg Geissler Received: (from geissler@localhost) by ilm.darmstadt.gmd.de (8.7.3/8.7.3) id IAA06812 for rem-conf@es.net; Wed, 26 Jun 1996 08:36:05 +0200 (MET DST) Date: Wed, 26 Jun 1996 08:36:05 +0200 (MET DST) Message-Id: <199606260636.IAA06812@ilm.darmstadt.gmd.de> To: rem-conf@es.net Subject: Re: Parallax support X-Sun-Charset: US-ASCII > You need the latest beta version (2.7b1 or b2) of vic available in the > conferencing/vic/alpha-test directory at ftp.ee.lbl.gov. The Sun binaries (both > SunOS and Solaris) have support for the Parallax card compiled in. Vic 2.7 even > has a built-in JPEG->h261 transcoder that reduces the CPU load on the machine, > although this feature appears to be broken on Solaris 2.5/UltraSPARC machines. vic2.7b1 works fine on one of our Solaris machines (Sun SPARC20) with Parallax. The only problem we have is that it is not possible to use the JPEG decompression and the video output option of our Parallax boards at the same time. The result is always a flickering video output signal. Does anybody have the same problems or even knows how to avoid the flickering? Is it a bug in the vic software or should we address Parallax? -JG ---------------------------------------------------------------------- Joerg Geissler ++49 6151 869-924 GMD-IPSI * ++49 6151 869-966 Dolivostrasse 15 mailto:geissler@darmstadt.gmd.de D-64293 Darmstadt http://www.darmstadt.gmd.de/~geissler ---------------------------------------------------------------------- SITUS VILATE IN ISET AB ERNIT | RENT THIS SPACE! ONLY $5/EMAIL! ---------------------------------------------------------------------- * German National Research Center for Information Technology - Integrated Publication and Information Systems Institute From rem-conf-request@es.net Wed Jun 26 07:01:01 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 04:00:25 -0700 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jun 1996 11:50:13 +0100 To: rem-conf@es.net Subject: Re: vat/rat and X terminals Date: Wed, 26 Jun 1996 11:50:12 +0100 Message-ID: <1840.835786212@cs.ucl.ac.uk> From: Colin Perkins --> "Dwight E. Spencer" writes: >On Tue, 25 Jun 1996, Russell Sutherland wrote: >> Do you know if vat or rat support the NAS X audio stuff >> so that an Xterminal can listen to the audio portions >> of an MBONE broadcast? > >Hmm.. I've never seen reference to this in the documentation, but the >developers may be able to point you in the right direction. Well, rat certainly doesn't support it at present, and since we don't have any Xterminals to play with, it's unlikely to do so. That said, if there's anyone out there who understands the NAS X audio stuff, and feels like trying a port, then get in touch and we'll see if we can help out..... Regards, Colin -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk Department of Computer Science Phone: (+44) 171 419 3666 University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf-request@es.net Wed Jun 26 07:01:23 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 04:00:27 -0700 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jun 1996 11:56:07 +0100 To: Stephen Casner Cc: rem-conf@es.net Subject: Re: Release of FreePhone audio tool In-reply-to: Your message of "Tue, 25 Jun 1996 21:34:09 PDT." Date: Wed, 26 Jun 1996 11:56:04 +0100 Message-ID: <2058.835786564@cs.ucl.ac.uk> From: Colin Perkins --> Stephen Casner writes: >> Both redundancy and high quality audio data are sent using special >> payload types (as discussed this week at the Montreal IETF meeting) > >Are these dynamic payload types (96-127) defined through sdr or some >other similar mechanism, or are they stolen static types? > >One of my crusades as AVT chair is to get people to understand and >implement dynamic payload types. By default, the current implementation of rat (and I believe FreePhone) steals a static payload type. In rat this can be changed using a command line flag (-rpt ), so sdr could configure this as required. Colin -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk Department of Computer Science Phone: (+44) 171 419 3666 University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf-request@es.net Wed Jun 26 08:14:00 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 05:13:11 -0700 Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id FAA25064; Wed, 26 Jun 1996 05:12:32 -0700 (PDT) Message-Id: <199606261212.FAA25064@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: nas@ncd.com cc: rem-conf@es.net Subject: anyone willing to help port rat to NAS? MIME-Version: 1.0 Content-Type: plain/text Date: Wed, 26 Jun 1996 05:12:32 -0700 From: Amancio Hasty C.Perkins@cs.ucl.ac.uk said: > Return-Path: rem-conf-request@es.net Received: from osi-west.es.net > (osi-west.es.net [198.128.3.61]) by rah.star-gate.com (8.7.5/8.7.3) > with SMTP id FAA24933 for ; Wed, 26 Jun 1996 > 05:05:20 -0700 (PDT) Received: from bells.cs.ucl.ac.uk by > osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 04:00:25 -0700 > Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP > id ; Wed, 26 Jun 1996 11:50:13 +0100 > To: rem-conf@es.net Subject: Re: vat/rat and X terminals Date: Wed, > 26 Jun 1996 11:50:12 +0100 Message-ID: <1840.835786212@cs.ucl.ac.uk> > From: Colin Perkins > --> "Dwight E. Spencer" writes: >On Tue, 25 Jun 1996, Russell > Sutherland wrote: >> Do you know if vat or rat support the NAS X > audio stuff >> so that an Xterminal can listen to the audio portions > > > of an MBONE broadcast? > >Hmm.. I've never seen reference to this > in the documentation, but the >developers may be able to point you in > the right direction. > Well, rat certainly doesn't support it at present, and since we don't > have any Xterminals to play with, it's unlikely to do so. > That said, if there's anyone out there who understands the NAS X > audio stuff, and feels like trying a port, then get in touch and > we'll see if we can help out..... > Regards, > Colin > -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk > Department of Computer Science Phone: (+44) 171 419 3666 University > College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf-request@es.net Wed Jun 26 08:24:35 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 05:24:06 -0700 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Jun 1996 13:23:53 +0100 To: rem-conf@es.net Cc: rat-trap@cs.ucl.ac.uk, v.hardman@cs.ucl.ac.uk Subject: Re: A busy week on the MBone Date: Wed, 26 Jun 1996 13:23:53 +0100 Message-ID: <2547.835791833@cs.ucl.ac.uk> From: Colin Perkins --> "Dwight E. Spencer" writes: >secondly, getting to cs.ucl.ac.uk to get into /mice/* to get the tools >sometimes can be a trying experience from this side of the atlantic. I >currently have all the (latest I believe) tools for sparc solaris 2 if >anyone wants to get them (wb/nt/vic etc etc..) from >ftp://cnet.unb.ca/pub/internet/multicast/solaris/tools/ You can also find rat, sdr, etc at the following places, which may be easier to reach than cs.ucl.ac.uk ftp://ftp.parc.xerox.com/pub/net-research/apps/ ftp://ftp.funet.fi/mirrors/cs.ucl.ac.uk/mice/ ftp://www-ks.rus.uni-stuttgart.de/pub/mbone ftp://mice.ed.ac.uk/pub/videoconference/ ftp://sunsite.doc.ic.ac.uk/pub/computing/comms/ip/videoconference Many of these sites are provided by the MICE National Support centres: http://www-mice-nsc.cs.ucl.ac.uk/mice-nsc/ Colin -- Colin Perkins Email: c.perkins@cs.ucl.ac.uk Department of Computer Science Phone: (+44) 171 419 3666 University College London WWW : http://www.cs.ucl.ac.uk/staff/c.perkins/ From rem-conf-request@es.net Wed Jun 26 11:25:34 1996 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 08:24:58 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id RAA09417 (8.7.5/7.5b-FAU); Wed, 26 Jun 1996 17:24:53 +0200 (MET DST) From: Toerless Eckert Message-Id: <199606261524.RAA09417@faui40.informatik.uni-erlangen.de> Subject: Re: Parallax support To: geissler@darmstadt.gmd.de (Joerg Geissler) Date: Wed, 26 Jun 1996 17:24:50 +0200 (MET DST) Cc: rem-conf@es.net In-Reply-To: <199606260636.IAA06812@ilm.darmstadt.gmd.de> from "Joerg Geissler" at Jun 26, 96 08:36:05 am Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > The only problem we have is that it is not possible to use the JPEG > decompression and the video output option of our Parallax boards at the > same time. The result is always a flickering video output signal. Does > anybody have the same problems or even knows how to avoid the > flickering? Is it a bug in the vic software or should we address Parallax? It is possible. It is just a pain in the ... to program with the library >from parallax. Try out ftp.informatik.uni-erlangen.de:/MMSvideo. best regards Toerless From rem-conf-request@es.net Wed Jun 26 11:52:15 1996 Received: from dns1.noc.best.net by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 08:51:32 -0700 Received: from ietf192-13.ietf.risq.qc.ca (ietf192-13.ietf.risq.qc.ca [206.167.192.13]) by dns1.noc.best.net (8.6.12/8.6.5) with SMTP id IAA20240; Wed, 26 Jun 1996 08:51:10 -0700 Date: Wed, 26 Jun 1996 08:51:10 -0700 Message-Id: <1.5.4.16.19960626085007.4f4fc4c4@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: John Larson From: Ross Finlayson Subject: Re: Which ISPs in SF Bay area assist in providing MBone connections ? Cc: rem-conf@es.net, karl@best.com At 11:06 PM 6/25/96 -0700, John Larson wrote: >I want to get connected to the MBone, but my current ISP has so far been >uninterested in being helpful. > >Does anyone have a recommendation for an ISP in the SF Bay area which >*would* be helpful in getting me setup with an MBone tunnel ? My current ISP - Best Internet Communications (best.com) - has an MBone feed, and is willing to set up tunnels to customers with full-time connections. The contact person for this is Karl Mueller (karl@best.com). Note, however, that Best considers this an experimental service, and doesn't provide the same level of assistance that it does for its regular (unicast) service. You need to know what you're doing... Ross. From rem-conf-request@es.net Wed Jun 26 12:09:53 1996 Received: from fun.inria.fr by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 09:08:48 -0700 Received: by fun.inria.fr (8.7.5/8.6.12) id SAA24009; Wed, 26 Jun 1996 18:04:50 +0200 (MET DST) Message-Id: <199606261604.SAA24009@fun.inria.fr> X-Mailer: exmh version 1.6.5 12/11/95 To: Stephen Casner cc: rem-conf@es.net, merci@cs.ucl.ac.uk Subject: Re: Release of FreePhone audio tool In-reply-to: your message of Tue, 25 Jun 1996 21:34:09 PDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 26 Jun 1996 18:04:48 +0200 From: Andres Vega Garcia : Stephen Casner wrote: >> Both redundancy and high quality audio data are sent using special >> payload types (as discussed this week at the Montreal IETF meeting) > >Are these dynamic payload types (96-127) defined through sdr or some >other similar mechanism, or are they stolen static types? > >One of my crusades as AVT chair is to get people to understand and >implement dynamic payload types. > -- Steve The current implementation of Free Phone (and that of RAT) indeed identifies redundant information using a static payload type (http://www.inria.fr/rodeo/fphone/ptypes.html). The details of this were presented by Mark Handley back in the Feb. IETF meeting, with additional stuff presented yesterday by Mark Handley and Walid Dabbous (but I didn't get to MBone-attend the meeting). In any case, there would be no problem to pass those payload types as parameters to the tool. -Andres From rem-conf-request@es.net Wed Jun 26 13:42:09 1996 Received: from mach-1.tridis.ist.ucf.edu (actually 132.170.197.1) by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 10:41:05 -0700 Received: by mach-1.tridis.ist.ucf.edu (SMI-8.6/SMI-SVR4) id NAA06032; Wed, 26 Jun 1996 13:39:58 -0400 Date: Wed, 26 Jun 1996 13:39:58 -0400 From: myjak@tridis.ist.ucf.edu (Michael Myjak) Message-Id: <199606261739.NAA06032@mach-1.tridis.ist.ucf.edu> To: npsnet@cs.nps.navy.mil CC: rem-conf@es.net, ietf-dis@bacon.gmu.edu In-reply-to: <9606251300.ZM1361@medusa.cs.nps.navy.mil> (message from NPSNET Research Group on Tue, 25 Jun 1996 13:00:06 -0700) Subject: Re: PlayDay June 28, 1996 NPS folks, you may (or may not know) but we (DIS/CAS) are attempting to get DIS folks to use the IANA assigned DIS mcast address range(s). These are IPmc groups from 225.252.0.0 through 224.254.255.255 with 224.252.0.1 being used for all-entities ststic-multicast. (or so says the DIS multicast guidance document.) --FYI Net@You.Later, - Michael D. Myjak Senior Research Scientist (& DIS CAS Secretary) Institute for Simulation and Training The University of Central Florida email: Voice: 407.658.5043 FAX: 407.658.5059 LAB: 407.658.5078 Off the keyboard, over the bridge, through the router..... Nothin' but Net! From rem-conf-request@es.net Wed Jun 26 14:09:04 1996 Received: from philabs.research.philips.com by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 11:07:38 -0700 Received: from frank.philabs.research.philips.com (frank.philabs.research.philips.com [130.140.55.10]) by philabs.research.philips.com (8.7.1/8.6.12) with SMTP id OAA07271 for ; Wed, 26 Jun 1996 14:07:36 -0400 (EDT) Received: from trauma.philabs.research.philips.com by frank.philabs.research.philips.com (4.1/SMI-4.1) id AA18184; Wed, 26 Jun 96 14:07:34 EDT Received: (from jec@localhost) by trauma.philabs.research.philips.com (8.7.3/8.6.12) id OAA27777; Wed, 26 Jun 1996 14:07:30 -0400 (EDT) Date: Wed, 26 Jun 1996 14:07:30 -0400 (EDT) From: Jorge Caviedes Message-Id: <199606261807.OAA27777@trauma.philabs.research.philips.com> To: rem-conf@es.net Subject: Graphic tablets for Sun -- WB useable Cc: jec@trauma.philabs.research.philips.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: Ch2A64KdzRJKQmjWlNyB5w== Hi all, Somebody has mentioned in the past the use of graphic tablets for WB input. I have been looking for Sun/Solaris compatible tablets and had no luck so far. Pointers anyone? thanks, Jorge E. Caviedes, Ph.D. Philips Research jec@philabs.research.philips.com Philips Electronics North America Sr. Member Research Staff 345 Scarborough Road (914)945-6386 Briarcliff Manor, NY 10510 From rem-conf-request@es.net Wed Jun 26 14:30:35 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 11:28:41 -0700 Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <14518(9)>; Wed, 26 Jun 1996 11:28:33 PDT Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Wed, 26 Jun 1996 11:28:20 -0700 To: brutzman@cs.nps.navy.mil (Don Brutzman) cc: rem-conf@es.net Subject: Re: A busy week on the MBone In-reply-to: Your message of "Tue, 25 Jun 96 10:31:56 PDT." <9606251731.AA09415@cs.nps.navy.mil> Date: Wed, 26 Jun 1996 11:28:08 PDT Sender: Bill Fenner From: Bill Fenner Message-Id: <96Jun26.112820pdt.177476@crevenia.parc.xerox.com> In message <9606251731.AA09415@cs.nps.navy.mil> you write: >We're still seeing loss from STS-78. Just a note that this doesn't appear to be actual network loss, rather it's being caused by bogus IP stacks that send ICMP unreachable errors in response to multicast traffic. There's nothing to be done about the bogus stacks other than try to get them upgraded or turned off. SGI will be integrating a workaround (have ICMP ignore the bogus error messages). Bill From rem-conf-request@es.net Wed Jun 26 22:00:39 1996 Received: from mercury.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 19:00:04 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA15392; Wed, 26 Jun 1996 19:00:02 -0700 Received: from basilisk.Eng.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA24864; Wed, 26 Jun 1996 19:00:00 -0700 Received: from sioux.Eng.Sun.COM by basilisk.Eng.Sun.COM (5.x/SMI-SVR4) id AA24192; Wed, 26 Jun 1996 18:59:58 -0700 Received: by sioux.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id SAA22930; Wed, 26 Jun 1996 18:59:53 -0700 Date: Wed, 26 Jun 1996 18:59:53 -0700 From: drapeau@basilisk-154.Eng.Sun.COM (George Drapeau) Message-Id: <199606270159.SAA22930@sioux.Eng.Sun.COM> To: geissler@darmstadt.gmd.de Cc: rem-conf@es.net In-Reply-To: <199606260636.IAA06812@ilm.darmstadt.gmd.de> (message from Joerg Geissler on Wed, 26 Jun 1996 08:36:05 +0200 (MET DST)) Subject: Re: Parallax support Reply-To: George.Drapeau@Eng.Sun.COM Hi, > From: Joerg Geissler > Date: Wed, 26 Jun 1996 08:36:05 +0200 (MET DST) > X-Sun-Charset: US-ASCII > > > You need the latest beta version (2.7b1 or b2) of vic available in the > > conferencing/vic/alpha-test directory at ftp.ee.lbl.gov. The Sun binaries (both > > SunOS and Solaris) have support for the Parallax card compiled in. Vic 2.7 even > > has a built-in JPEG->h261 transcoder that reduces the CPU load on the machine, > > although this feature appears to be broken on Solaris 2.5/UltraSPARC machines. > > vic2.7b1 works fine on one of our Solaris machines (Sun SPARC20) with Parallax. > > The only problem we have is that it is not possible to use the JPEG > decompression and the video output option of our Parallax boards at the > same time. The result is always a flickering video output signal. Does > anybody have the same problems or even knows how to avoid the > flickering? Is it a bug in the vic software or should we address Parallax? If you are running Parallax's Solaris 2.4 version of the software, you should contact Parallax to get their latest release. The latest release, available for Solaris 2.5, should fix this problem if I understand you correctly. Parallax had a problem with the way data paths were being allocated for video input/output and JPEG operations, and a common-case problem was when trying to do output and decompression at the same time. If this doesn't make sense, please feel free to send me private email directly and I'd be happy to try and explain the situation more clearly. I hope this is of some help. George ------------------------------------------------- George Drapeau 415-336-6551 SunSoft FAX: 415-336-2060 2550 Garcia Ave. Mountain View, CA George.Drapeau@Eng.Sun.COM From rem-conf-request@es.net Thu Jun 27 00:10:25 1996 Received: from trout.nosc.mil by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 21:09:57 -0700 Received: from cod.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA12868; Wed, 26 Jun 96 21:09:55 PDT Received: from catbert.nosc.mil by cod.nosc.mil (4.1/SMI-4.1) id AA23763; Wed, 26 Jun 96 21:06:49 PDT Date: Wed, 26 Jun 1996 21:09:44 -0700 (PDT) From: "Mark T. Ganzer" To: George.Drapeau@Eng.Sun.COM Cc: geissler@darmstadt.gmd.de, rem-conf@es.net Subject: Re: Parallax support In-Reply-To: <199606270159.SAA22930@sioux.Eng.Sun.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 26 Jun 1996, George Drapeau wrote: > If you are running Parallax's Solaris 2.4 version of the software, you > should contact Parallax to get their latest release. The latest > release, available for Solaris 2.5, should fix this problem if I > understand you correctly. Parallax had a problem with the way data > paths were being allocated for video input/output and JPEG operations, > and a common-case problem was when trying to do output and > decompression at the same time. Just to clarify my situation, I have run Vic with the Parallax card successfully on Sparc 5/Solaris 2.4 and Sparc 20/SunOS 4.1.4 combinations with no problem (except that the Sparc 5 was REALLY slow). When we put together the Ultra 170 with a Parallax, we HAD to get new drivers from Parallax to support the Sun4u architecture. With this combo and using the "JPEG for h261" option, the image transmitted is EXTREMELY grey and lacking in contrast (it looks like the room is full of fog) and there are significant JPEG artififacts visible. Turning off the "use JPEG for h261" option results in the transmission of a clean, clear picture (although using significantly more CPU cycles). Because the problem only shows up while using the JPEG->h261 transcoder option, it makes me think that the changes Parallax made to their drivers for Solaris 2.5 broke the transcoder in Vic. I'd be happy to work with anyone who wants to see what this problem looks like. Mark Ganzer Naval Command, Control & Ocean Surveillance Center, ganzer@nosc.mil RDT&E Div (NRaD), Code 4123, San Diego, CA Ph: (619) 553-1186 FAX: (619) 553-4808 From rem-conf-request@es.net Thu Jun 27 01:10:36 1996 Received: from mercury.Sun.COM by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 22:09:39 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA10901; Wed, 26 Jun 1996 22:09:03 -0700 Received: from basilisk.Eng.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA04482; Wed, 26 Jun 1996 22:09:00 -0700 Received: from sioux.Eng.Sun.COM by basilisk.Eng.Sun.COM (5.x/SMI-SVR4) id AA25152; Wed, 26 Jun 1996 22:08:59 -0700 Received: by sioux.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id WAA25284; Wed, 26 Jun 1996 22:09:00 -0700 Date: Wed, 26 Jun 1996 22:09:00 -0700 From: drapeau@basilisk-154.Eng.Sun.COM (George Drapeau) Message-Id: <199606270509.WAA25284@sioux.Eng.Sun.COM> To: ganzer@nosc.mil Cc: George.Drapeau@Eng.Sun.COM, geissler@darmstadt.gmd.de, rem-conf@es.net In-Reply-To: (ganzer@nosc.mil) Subject: Re: Parallax support Reply-To: George.Drapeau@Eng.Sun.COM Hello Mark, nice to meet you, > Date: Wed, 26 Jun 1996 21:09:44 -0700 (PDT) > From: "Mark T. Ganzer" > Cc: geissler@darmstadt.gmd.de, rem-conf@es.net > > Just to clarify my situation, I have run Vic with the Parallax card > successfully on Sparc 5/Solaris 2.4 and Sparc 20/SunOS 4.1.4 combinations > with no problem (except that the Sparc 5 was REALLY slow). When we put > together the Ultra 170 with a Parallax, we HAD to get new drivers from > Parallax to support the Sun4u architecture. With this combo and using the > "JPEG for h261" option, the image transmitted is EXTREMELY grey and lacking > in contrast (it looks like the room is full of fog) and there are significant > JPEG artififacts visible. Turning off the "use JPEG for h261" option results > in the transmission of a clean, clear picture (although using significantly > more CPU cycles). > > Because the problem only shows up while using the JPEG->h261 transcoder > option, it makes me think that the changes Parallax made to their drivers > for Solaris 2.5 broke the transcoder in Vic. I'd be happy to work with > anyone who wants to see what this problem looks like. Ah! Well, that's a different problem indeed. Uh, I'd say that if you're seeing washed out images, that's a little different than flickering images on the output monitor. The "EXTREMELY gray and lacking in contrast" is most likely due to changes Parallax made to fix problems in the way they were dealing with quantization tables (actually, they had gotten buggy code from C-Cube, and recently fixed the problem). The problem can be seen if you use software that was compiled against an older version of Parallax's libraries but run it against a new server. This is because the older software constructs Q tables in the old way, but the server interprets them in the "correct" way. "the old way" means that Q tables are not zig-zagged, but the newer, correct servers expect zig-zagged Q tables. The resulting mismatch in Q table formats causes images to lack contrast when going one way, and to have too much contrast when going the other. In addition, you will notice more extreme artifacts. So, two things, if you can: * recompile your software against the latest Plx libraries * If you use Parallax functions to set Q factor (i.e., using the MakeQTables() function), then change your Q settings to half of what they would be (i.e., if you used to call MakeQTables(100, blah blah blah), you should now call MakeQTables(50, blah blah blah)). There are some compatibility issues here. For example, if you're compressing on your 4.1.4 machine and decompressing on the Ultra, then you're likely dealing with an old-style-Q-table-system to new-style-Q-table-system, because all Parallax servers before the Solaris 2.5 product used the old, broken Q table scheme. Parallax should be able to give you a newer X11R5 server for your 4.1.4 machine that also has the Q table fix. Also, any software that was compiled against the older libraries needs to be recompiled so that it starts using the correct Q table scheme. Is any of what I'm saying here clear at all? I hope so, but if not, send me mail and I'll be glad to elaborate. Also, I don't know when you got your Ultra support software, but if it came on the so-called Parallax "Jumbo CD", then you should also have the latest SunOS 4.1.4 X11R5 support which includes the Q table fixes. Good luck. George ------------------------------------------------- George Drapeau 415-336-6551 SunSoft FAX: 415-336-2060 2550 Garcia Ave. Mountain View, CA George.Drapeau@Eng.Sun.COM From rem-conf-request@es.net Thu Jun 27 02:42:26 1996 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Wed, 26 Jun 1996 23:41:48 -0700 Received: from faui45r.informatik.uni-erlangen.de (eckert@faui45r.informatik.uni-erlangen.de [131.188.2.54]) by immd4.informatik.uni-erlangen.de with ESMTP id IAA14904 (8.7.5/7.5b-FAU); Thu, 27 Jun 1996 08:41:36 +0200 (MET DST) From: Toerless Eckert Message-Id: <199606270641.IAA14904@faui40.informatik.uni-erlangen.de> Subject: Re: Parallax support To: George.Drapeau@Eng.Sun.COM Date: Thu, 27 Jun 1996 08:41:33 +0200 (MET DST) Cc: ganzer@nosc.mil, geissler@darmstadt.gmd.de, rem-conf@es.net In-Reply-To: <199606270509.WAA25284@sioux.Eng.Sun.COM> from "George Drapeau" at Jun 26, 96 10:09:00 pm Organisation: CSD IMMD IV, University of Erlangen, Germany X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit ne remark about the new parallax servers: after waiting for more than half a year for the 2.5/4.1.4 release we finally received it yesterday, so i guess: yes, it's finally available. Best regards Toerless From rem-conf-request@es.net Thu Jun 27 04:06:42 1996 Received: from cancer.ucs.ed.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Jun 1996 01:06:06 -0700 Received: from scorpio.ucs.ed.ac.uk (jaw@scorpio.ucs.ed.ac.uk [129.215.200.48]) by cancer.ucs.ed.ac.uk (8.6.10/8.6.12) with SMTP id JAA14674; Thu, 27 Jun 1996 09:05:36 +0100 Date: Thu, 27 Jun 1996 09:05:32 +0100 (BST) From: Graeme Wood Reply-To: Graeme.Wood@ucs.ed.ac.uk To: Toerless Eckert cc: George.Drapeau@eng.sun.com, ganzer@nosc.mil, geissler@darmstadt.gmd.de, rem-conf@es.net Subject: Re: Parallax support In-Reply-To: <199606270641.IAA14904@faui40.informatik.uni-erlangen.de> Message-ID: X-Department: "Unix Systems Support, Computing Services" X-Organisation: "The University of Edinburgh" X-URL: "http://ugwww.ucs.ed.ac.uk/People/Graeme.Wood/" X-Phone: +44 131 650 5003 X-Fax: +44 131 650 6552 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 27 Jun 1996, Toerless Eckert wrote: > ne remark about the new parallax servers: after waiting for more than > half a year for the 2.5/4.1.4 release we finally received it yesterday, > so i guess: yes, it's finally available. Hmm, I'm still waiting for it and given I pay an absolute fortune for the privilege of software updates I would expect better response than I get. ============================================================================= Graeme Wood Email: Graeme.Wood@ucs.ed.ac.uk Unix Systems Support Phone: +44 131 650 5003 The University of Edinburgh Fax: +44 131 650 6552 ----------------------------------------------------------------------------- Scottish MICE National Support Centre Email: mice-nsc-scotland@ed.ac.uk for your multimedia conferencing support WWW: http://mice.ed.ac.uk/mice/ ============================================================================= From rem-conf-request@es.net Thu Jun 27 04:10:08 1996 Received: from cismsun.univ-lyon1.fr by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Jun 1996 01:09:35 -0700 Received: (from lucia@localhost) by cismsun.univ-lyon1.fr (8.6.12/8.6.12) id KAA29166 for rem-conf@es.net; Thu, 27 Jun 1996 10:09:32 +0200 Message-Id: <199606270809.KAA29166@cismsun.univ-lyon1.fr> Subject: Re: vat/rat and X terminals To: rem-conf@es.net Date: Thu, 27 Jun 1996 10:09:32 +0200 (MET DST) From: Lucia Gradinariu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1135 > > On Tue, 25 Jun 1996, Russell Sutherland wrote: > > Do you know if vat or rat support the NAS X audio stuff > > so that an Xterminal can listen to the audio portions > > of an MBONE broadcast? > I don't know about NAS but I have used vat (and french Telesia) with X terminals where audio was supported by AFserver and aplay client (I have Tektronix XP400 with 16M of Ram and with a Tek. implementation of AFserver) You may have locally good audio but the variable delay of large scope conferences in combination with vat adaptation scheme is not well managed by the AF server during long, continuous transmissions. As I said, locally you can used both input and output audio facilities of the TX in a vat session. AF is AF3R1 from Dec. -------------------------------------------------------------------------------- Lucia GRADINARIU, Eng. CISM-Univ. Cl. Bernard Lyon1 voice:(33).72.43.13.69 Bat. 101 Bd. du 11 Novembre 1918 fax:(33).72.44.84.10 69622 Villeurbanne FRANCE email:lucia@univ-lyon1.fr http://www.univ-lyon1.fr/CISM/lucia --------------------------------------------------------------------------------- From rem-conf-request@es.net Thu Jun 27 08:00:21 1996 Received: from radvision.rad.co.il by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Jun 1996 04:59:34 -0700 Received: by firewall.radvision.rad.co.il id <24193>; Thu, 27 Jun 1996 15:54:28 +0300 From: Ofer Shapiro To: 'h323list' , "'rem-conf@es.net'" Subject: RTP payload for G.728 Date: Fri, 28 Jun 1996 01:01:00 +0300 Message-Id: <96Jun27.155428idt.24193@firewall.radvision.rad.co.il> Encoding: 24 TEXT X-Mailer: Microsoft Mail V3.0 AVC colleagues: In the last ITU-T/SG15 meeting in Geneva a need to specify RTP payload for LAN carried G.728 in H.323 environment was identified. It is my intention to make a submission to the IETF of such a payload, in one of it's next meetings. If anyone reading this has any knowledge on LAN based G.728 implementations or have some ideas regarding such a payload, I would appreciate if he (or she) would contact me. Many thanks, Ofer Shapira RADVision, ofer@radvision.rad.co.il From rem-conf-request@es.net Thu Jun 27 15:21:28 1996 Received: from trout.nosc.mil by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Jun 1996 12:20:51 -0700 Received: from cod.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA07886; Thu, 27 Jun 96 12:20:48 PDT Received: from dilbert.nosc.mil (dilbert-eth.nosc.mil) by cod.nosc.mil (4.1/SMI-4.1) id AA04959; Thu, 27 Jun 96 12:17:47 PDT Date: Thu, 27 Jun 1996 12:17:31 -0700 (PDT) From: ganzer@nosc.mil Sender: ganzer@dilbert.nosc.mil Reply-To: ganzer@nosc.mil Subject: Re: Parallax support To: George.Drapeau@Eng.Sun.COM Cc: ganzer@nosc.mil, George.Drapeau@Eng.Sun.COM, geissler@darmstadt.gmd.de, rem-conf@es.net In-Reply-To: <199606270509.WAA25284@sioux.Eng.Sun.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII George, thanks for the detailed response (I should have caught it in the new Parallax driver docs...). It looks like the Vic binaries on the ftp.ee.lbl.gov server are still being compiled against the older Parallax library. Unfortunately, I don't have access to a copy of the Parallax VDE needed to recompile Vic, so will have to wait for some other kind soul to do it and make it available via ftp :-) I haven't yet installed the new Parallax 2.0 drivers on the other Sun machines, so that is why we haven't seen the problem there. When we received the Ultra back in early May, we contacted Parallax tech support. I guess we complained enough that they mad a copy of available via FTP, and the CD followed about 2 weeks later... -Mark Ganzer > Ah! Well, that's a different problem indeed. Uh, I'd say that if > you're seeing washed out images, that's a little different than > flickering images on the output monitor. The "EXTREMELY gray and > lacking in contrast" is most likely due to changes Parallax made to > fix problems in the way they were dealing with quantization tables > (actually, they had gotten buggy code from C-Cube, and recently fixed > the problem). The problem can be seen if you use software that was > compiled against an older version of Parallax's libraries but run it > against a new server. This is because the older software constructs Q > tables in the old way, but the server interprets them in the "correct" > way. "the old way" means that Q tables are not zig-zagged, but the > newer, correct servers expect zig-zagged Q tables. The resulting > mismatch in Q table formats causes images to lack contrast when going > one way, and to have too much contrast when going the other. In > addition, you will notice more extreme artifacts. > > So, two things, if you can: > > * recompile your software against the latest Plx libraries Mark Ganzer Naval Command, Control & Ocean Surveillance Center, ganzer@nosc.mil RDT&E Div (NRaD), Code 4123, San Diego, CA Ph: (619) 553-1186 FAX: (619) 553-4808 From rem-conf-request@es.net Thu Jun 27 17:52:32 1996 Received: from trystero.radio.com (actually trystero.media.org) by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Jun 1996 14:51:52 -0700 Received: (carl@localhost) by trystero.radio.com (8.7.5/940816.06ccg) id FAA25392; Fri, 21 Jun 1996 05:26:58 -0400 (EDT) From: "Carl Malamud [IMS]" Message-Id: <199606210926.FAA25392@trystero.radio.com> Subject: Re: To: Mbone User in other country , help pls. To: mskim@iexpo.expo.or.kr Date: Fri, 21 Jun 1996 05:26:58 -0400 (EDT) Cc: rem-conf@es.net, mskim@expo.or.kr In-Reply-To: <31CA0250.3B43@expo.or.kr> from "Kim Mansu" at Jun 21, 96 11:00:48 am Organization: Internet Multicasting Service X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I need people who can use 512Kbps or higher lines, and can use Mbone > tools(SD, SDR,NV, VAT, VIC) > is there any people who help me? Just to clarify. The Korean Broadcast will observe MBONE guidelines of total aggregate bandwidth on the MBONE of < 500 kbps and individual sessions of << 128 kbps, less if conflicts occur. I'll work with Mr. Kim offline on this. Regards, Carl > > I plan to broadcaste open concert July 7th 18:00 pm KST(sorry I cannot > find other standard time) > > If you can help me, please mail to me. > > World Internet Exposition 1996 Korean Organization, > Kim, Mansu(mskim2expo.or.kr, +82-2-3443-7585) > > ps) sorry If disturbing you, > From rem-conf-request@es.net Fri Jun 28 02:25:32 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 27 Jun 1996 20:34:33 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA17316; Thu, 27 Jun 1996 20:34:23 -0700 Date: Thu, 27 Jun 1996 20:34:23 -0700 (PDT) From: Stephen Casner To: Ofer Shapiro Cc: 'h323list' , "'rem-conf@es.net'" Subject: Re: RTP payload for G.728 In-Reply-To: <96Jun27.155428idt.24193@firewall.radvision.rad.co.il> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ofer Shapira: > In the last ITU-T/SG15 meeting in Geneva a need to specify RTP payload > for LAN carried G.728 in H.323 environment was identified. > > It is my intention to make a submission to the IETF of such a payload, in > one of it's next meetings. There is already an RTP static payload type number assigned for G.728. No payload format header is specified; this implies that some number of G.728 blocks would be packaged in an RTP data packet with no additional framing. It that insufficient? Unless this is wrong and some additional header information is required, it is not necessary to prepare a separate payload format specification for G.728. -- Steve From rem-conf-request@es.net Fri Jun 28 14:27:22 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Fri, 28 Jun 1996 11:26:39 -0700 Received: from ibeam.intel.com (ibeam.jf.intel.com [134.134.208.3]) by ormail.intel.com (8.7.4/8.7.3) with SMTP id LAA26934 for ; Fri, 28 Jun 1996 11:26:37 -0700 (PDT) Received: from lscline2 by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0uZiEW-000RVgC; Fri, 28 Jun 96 11:25 PDT Message-Id: <2.2.32.19960628182715.008cfc5c@ibeam.jf.intel.com> X-Sender: lscline@ibeam.jf.intel.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_836011635==_" Date: Fri, 28 Jun 1996 11:27:15 -0700 To: rem-conf@es.net From: Linda Cline Subject: RTP Payload Format for G.723 Cc: mojy@ibeam.jf.intel.com, Ken_K_Mills@ccm.jf.intel.com, Christian_Maciocco@ccm.jf.intel.com, Hariharan_Kumar@ccm.jf.intel.com X-Attachments: a:.\g723pyld.txt; --=====================_836011635==_ Content-Type: text/plain; charset="us-ascii" Attached is a draft for G.723 payload format for RTP. Please send any comments to the list, or to myself at lscline@ibeam.jf.intel.com, as well the author, Ken_K_Mills@ccm.jf.intel.com, as Ken will be taking some sabbatical time off shortly. Questions and feedback would be welcome. thanks, Linda Cline --=====================_836011635==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="g723pyld.txt" Internet Draft RTP Payload for G.723 May 17,1996 Internet Engineering Task Force Audio-Video Transport WG INTERNET-DRAFT Ken Mills Intel Corp. May 17, 1996 Expires: 11/17/96 RTP Payload Format for G.723 Audio Streams 1. 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 lid-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 Cost). Distribution of this document is unlimited. Abstract This document specifies the RTP payload format for encapsulating the G.723 bitstream in the Real-Time Transport Protocol (RTP). RTP can use one of three possible formats to encapsulate the G.723 data depending on the network characteristics. These are: Sequential G.723 audio data, interleaving frames across packets and duplicating frames. 2. Introduction This document describes a method for packetizing a G.723 bitstream for transport using RTP. The G.723 bitstream is defined by ITU-T Recommendation G.723 for a very low bit rate speech coder. G723 is a dual rate speech coder that operates at 5.3 and 6.3 kbit/s. The higher bit rate has greater quality. The lower bit rate gives good quality and provides additional flexibility. Both rates are a mandatory part of the encoder and decoder. Mills [Page 1] Internet Draft RTP Payload for G.723 May 17,1996 3. Specification of the packetization scheme 3.1 RTP Header Usage - The payload type should specify G.723 payload format. - Each RTP packet contains a timestamp for the first frame of audio data in that packet. The same RTP timestamp is used for all packets in a sequence of interleaved packets. - The Marker bit shall be used to specify an alternate header and data format that provides a higher tolerance to packet loss. A cleared marker bit (set to 0) indicates no G.723 payload header, and no special format for the audio data. A set marker bit (set to 1) indicates the payload header is present, and the audio data includes either interleaved or replicated frames. 3.2 Audio Packet Structure The G.723 bitstream is carried as a payload within each RTP packet. For each RTP packet containing G.723 data, there are two possible header formats. The first format consists of the RTP header with the marker bit set to zero, which is then followed by n frames of standard G.723 bitstream data as defined in the ITU specification. A packet may contain any combination of 5.3kb, 6.3kb and silence frames. This is shown below: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Compressed G.723 data | | ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In the second header format the marker bit is set to 1. This indicates that the format of this packet is as follows: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | G.723 Payload Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interleaved or replicated G.723 frames | | ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mills [Page 2] Internet Draft RTP Payload for G.723 May 17,1996 4. G.723 Payload Header For each G.723 audio packet with the marker bit set to one, there is one G.723 payload header. This header specifies which one of two data formats are to be used. The first format (mode 0) is an interleave format where sequential G.723 frames are placed across multiple packets. For example, frames 1 through 4 could be interleaved across two packets: {1,3} and {2,4}. In the case of a packet loss, this has the effect of spreading out lost frames in time, allowing the decoder to do a better job of filling in the missing data. This is shown in 4.1. In the second format (mode 1), each packet consists of both current audio frames and frames included in a previous packet. This provides redundant information in the event of a packet loss. The arrangement of these replicated packets is specified in the G.723 header as shown in 4.2 below: 4.1 Mode 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCNT | SEQ |F| IF | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Frame Count (FCNT):4 bits Number of frames in the packet. Sequence Number (SEQ): 4 bits The sequence number indicates where this packet is placed within a group of interleaved packets. This starts at zero for each group. Mode bit (F): 1 bit This indicates the format of the packet. 0 for mode 0. Interleave Factor (IF): 4 bits Number of packets across which the frames are spread. For example, if IF is set to 010 then the frames will be interleaved across two packets with the even frames in packet sequence number zero and the odds in packet number one. This is shown in 4.1.1 below: Mills [Page 3] Internet Draft RTP Payload for G.723 May 17,1996 4.1.1 Interleaved Frames Example Frame count is set to 3 and interleave is set to 2. Packet #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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1|0 0 0 0|0|0 0 1 0| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet #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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1|0 0 0 1|0|0 0 1 0| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.2 Mode 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FCNT | REP |F|PKTOFF | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Frame Count (FCNT):4 bits Number of frames in the packet. Mills [Page 4] Internet Draft RTP Payload for G.723 May 17,1996 Repeat Count (REP): 4 bits Specifies the number of frames that will be duplicates of frames >from a previous packet. The duplicated frames always start with the first "new" frame in the packet. Mode bit (F): 1 bit This indicates the format of the packet. 1 for mode 1. Packet Offset (PKTOFF): 4 bits This field specifies how many packets are between the packet supplying the original frames and the packet supplying the retransmitted frames. For example, if the retransmitted frames are in the packet subsequent to the packet containing the original frames, the packet offset would be zero. 4.2.1 Frame Replication Example In the following example the REP field is set to two indicating we will retransmit two "old" frames in each packet. The PKTOFF field is set to zero to indicate that the frames will be pulled from the packet prior to this one. The replicated packets are always placed in the packet ahead of the "new" frames. This is shown below. Packet #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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 0|0 0 1 0|1|0 0 0 0| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mills [Page 5] Internet Draft RTP Payload for G.723 May 17,1996 Packet #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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 0|0 0 1 0|1|0 0 0 0| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Packet #2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 1 0 0|0 0 1 0|1|0 0 0 0| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5. References [1] Dual Rate Speech Coder for Multimedia Communications Transmitting at 5.3 & 6.3 Kbits/s, ITU-T Recommendation G.723 (draft of 1995-October-17). Mills [Page 6] Internet Draft RTP Payload for G.723 May 17,1996 6. Author's Address Ken Mills Mail Stop: JF2-78 Intel Architecture Lab Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97124 USA Tel: (503) 264-8988 FAX: (503) 264-6067 Email: kmills@ibeam.intel.com 7. Table of Contents 1. Status of This Memo..................1 2. Introduction.........................1 3. Specification of the packetization...2 3.1 RTP Header Usage.....................2 3.2 Audio Packet Structure...............2 4. G.723 Payload Header.................3 4.1 Mode 0...............................3 4.1.1 Interleaved Frames Example...........3 4.2 Mode 1...............................4 4.2.1 Frame Replication Example............5 5. References...........................6 6. Author's Address.....................7 Mills [Page 7] --=====================_836011635==_ Content-Type: text/plain; charset="us-ascii" --=====================_836011635==_-- From rem-conf-request@es.net Sat Jun 29 15:23:54 1996 Received: from cs.umass.edu (actually freya.cs.umass.edu) by osi-east.es.net with ESnet SMTP (PP); Sat, 29 Jun 1996 12:23:21 -0700 Received: from sahir.cs.umass.edu by cs.umass.edu (5.65/Ultrix3.0-C) id AA10152; Sat, 29 Jun 1996 15:23:16 -0400 Received: by sahir.cs.umass.edu.cnet (SMI-8.6/SMI-SVR4) id PAA15037; Sat, 29 Jun 1996 15:29:20 -0400 Date: Sat, 29 Jun 1996 15:29:20 -0400 From: hgschulz@sahir.cs.umass.edu (Henning Schulzrinne) Message-Id: <199606291929.PAA15037@sahir.cs.umass.edu.cnet> To: rem-conf@osi-east.es.net Subject: RTP library and RTP implementations Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: gVN+Nff3GjXuc/MEVp60Rw== In preparation for advancing RTP to "proposed", I'm cleaning up the implementations database (www.fokus.gmd.de/step/rtp). If anybody knows the current electronic whereabouts of Mastromartino E. A. Fantoni (author of an RTP library), I'd appreciate a note. Also, let me know if any of the information on implementations is no longer correct or if you know of additional implementations that are not listed (or are listed as implementing older versions of RTP). Thanks. Henning