From rem-conf-request@es.net Mon Jul 01 04:54:45 1996 Received: from radvision.rad.co.il by osi-east.es.net with ESnet SMTP (PP); Mon, 1 Jul 1996 01:54:06 -0700 Received: by firewall.radvision.rad.co.il id <24194>; Mon, 1 Jul 1996 12:48:54 +0300 From: Ofer Shapiro To: Stephen Casner Cc: 'h323list' , 'rem-conf' Subject: G.728 payload. Date: Mon, 1 Jul 1996 21:56:00 +0300 Message-Id: <96Jul1.124854idt.24194@firewall.radvision.rad.co.il> Encoding: 26 TEXT X-Mailer: Microsoft Mail V3.0 Hi steve, I'll try to explain to context of my question about G.728: If you go through H.225 section 6.2.1, you understand that whole number of frames shall be send in RTP packet (frame- I mean 2.5ms, you mentioned blocks- I hope we mean same thing). This is clear enough. The part that is missing is the packing in the "sample level". For instance, When G.728 arrives from the ISDN (H.320) it comes in a format of 2 bits in a byte, one might suggest that in order to ease implementation, a 320/323 GW would pack these 2 bits in one byte (actually it wouldn't necessarily help, this is only example). This course of action is actually mandated by 225 for G.711, G.722 section 6.2.1). Obviously when dealing with G.728 the waste in bandwidth would be larger, so one could argue that the packing should be complete: each frame (40 bit) in 5 bytes. Hybrid solutions were also suggested. I think that no new header information is needed, just some text to define the packing and maybe bit ordering. I hope that this clarify things, Ofer shapira ofer@radvision.rad.co.il From rem-conf-request@es.net Mon Jul 01 05:43:07 1996 Received: from ceres.fokus.gmd.de by osi-east.es.net with ESnet SMTP (PP); Mon, 1 Jul 1996 02:42:29 -0700 Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Mon, 1 Jul 1996 11:39:30 +0200 X-Mailer: exmh version 1.6.7 5/3/96 To: Linda Cline cc: rem-conf@es.net, mojy@ibeam.jf.intel.com, Ken_K_Mills@ccm.jf.intel.com, Christian_Maciocco@ccm.jf.intel.com, Hariharan_Kumar@ccm.jf.intel.com From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: RTP Payload Format for G.723 In-reply-to: Your message of "Fri, 28 Jun 1996 11:27:15 PDT." <2.2.32.19960628182715.008cfc5c@ibeam.jf.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jul 1996 11:39:24 +0200 Sender: schulzrinne@fokus.gmd.de I'm a bit concerned about 'rededicating' the marker bit to indicate an alternate encoding. Unless there's a good reason to do this that I'm missing, I'd much rather stick with the original meaning and use two different encodings. One might also argue that the interleaving proposed should be addressed in a general way (see the proposal for redundant encodings aired at the AVT meeting), rather than a G.723-specific method. Henning From rem-conf-request@es.net Mon Jul 01 10:58:26 1996 Received: from riker.read.tasc.com by osi-west.es.net with ESnet SMTP (PP); Mon, 1 Jul 1996 07:57:39 -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 KAA22445; Mon, 1 Jul 1996 10:58:15 -0400 From: wgsmith@riker.read.tasc.com (W. Garth Smith) Received: by snowflake (5.x) id AA22373; Mon, 1 Jul 1996 11:01:00 -0400 Date: Mon, 1 Jul 1996 11:01:00 -0400 Message-Id: <9607011501.AA22373@snowflake> To: rem-conf@es.net Subject: unsubscribe X-Sun-Charset: US-ASCII unsubscribe wgsmith@tasc.com From rem-conf-request@es.net Mon Jul 01 11:18:48 1996 Received: from cyclops.ece.ncsu.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 1 Jul 1996 08:18:05 -0700 Received: by cyclops.ece.ncsu.edu (8.6.9/EC06jan95) id LAA08906; Mon, 1 Jul 1996 11:18:02 -0400 From: Kathy Lynn Hewitt Message-Id: <9607011118.ZM8904@eos.ncsu.edu> Date: Mon, 1 Jul 1996 11:18:00 -0400 X-Mailer: Z-Mail (3.2.1 10oct95) To: rem-conf@es.net Subject: linux and Matrox Pulsar Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I'm looking to set up the MBone tools on a PC running linux. I have a Matrox Pulsar for my video input. Has anybody done this setup or know of where I could possibly get linux drivers for the Pulsar board? Thanks for the help!! Kathy Hewitt -- ------------------------------------------------- Kathy Hewitt Dept. of Electrical and Computer Engineering North Carolina State University 919-515-5604 ------------------------------------------------- From rem-conf-request@es.net Mon Jul 01 14:04:40 1996 Received: from ormail.intel.com by osi-east.es.net with ESnet SMTP (PP); Mon, 1 Jul 1996 11:04:12 -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 LAA02989; Mon, 1 Jul 1996 11:04:04 -0700 (PDT) Received: by ibeam.intel.com (Smail3.1.28.1 #6) id m0uamZh-000RWaC; Mon, 1 Jul 96 10:15 PDT Message-Id: To: Henning Schulzrinne cc: rem-conf@osi-east.es.net, mojy@ibeam.jf.intel.com, Ken_K_Mills@ccm.jf.intel.com, Christian_Maciocco@ccm.jf.intel.com, Hariharan_Kumar@ccm.jf.intel.com Subject: Re: RTP Payload Format for G.723 In-reply-to: Your message of Mon, 01 Jul 96 11:39:24 +0200. <199607011203.FAA09654@ormail.intel.com> Date: Mon, 01 Jul 96 10:15:39 PDT From: Linda Cline >I'm a bit concerned about 'rededicating' the marker bit to indicate an >alternate encoding. Unless there's a good reason to do this that I'm >missing, I'd much rather stick with the original meaning and use two >different encodings. One might also argue that the interleaving >proposed should be addressed in a general way (see the proposal for >redundant encodings aired at the AVT meeting), rather than a >G.723-specific method. From the RTP spec, we have been working under the impression that the marker bit is to be specified by the payload format, for things such as marking the last packet for a video frame. There is also the recommendation in the profile spec to use the marker bit in audio for the first packet in a talkspurt, which is entirely optional. Other than that, I'm not aware of any dedicated purpose for the marker bit. Can you clarify the "original meaning"? Perhaps this could be clarified in the RTP spec as well. The reason that we would like to use the marker bit to indicate the presence of a payload specific header is that we would like to eliminate a payload header completely in the normal mode. An alternative to this would be to use a separate payload type for the normal and alternate modes, but this would preclude the option of mixing the modes in a stream. Would like to get feedback from everyone about this. It is a valid argument that interleaving could be handled in a general way, such as the redundant encoding scheme. That particular scheme could work for the replicated data alternative in the G.723.1 proposal, which we put together before seeing the redundant encodings proposal, but would not work as well for the interleaved data, since it would require a header for each frame. That is quite alot of overhead for frames which are 20 or 24 bytes in length. Also, it is not useful to interleave video data, but is it useful to interleave any audio data, or is it better to define an interleaving scheme on a payload basis? On another note, I received a clarification from Bob Webber that the G.723 encoding of this proposal is actually G.723.1, and he is perfectly correct, so I would like to clarify this here as well. Linda Cline From rem-conf-request@es.net Mon Jul 01 22:05:20 1996 Received: from engr.orst.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 1 Jul 1996 19:04:38 -0700 Received: from ia.ENGR.ORST.EDU (ia.ENGR.ORST.EDU [198.106.200.25]) by engr.orst.edu (8.6.10/8.6.10) with ESMTP id TAA17733 for ; Mon, 1 Jul 1996 19:04:36 -0700 Received: from localhost by ia.ENGR.ORST.EDU (1.39.111.2/ENGR-Client) id AA031733073; Mon, 1 Jul 1996 19:04:33 -0700 Date: Mon, 1 Jul 1996 19:04:33 -0700 (PDT) From: Stephane Chatre Cc: rem-conf@es.net Subject: unsubscribe In-Reply-To: <9607011501.AA22373@snowflake> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII From rem-conf-request@es.net Mon Jul 01 22:05:58 1996 Received: from engr.orst.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 1 Jul 1996 19:05:26 -0700 Received: from ia.ENGR.ORST.EDU (ia.ENGR.ORST.EDU [198.106.200.25]) by engr.orst.edu (8.6.10/8.6.10) with ESMTP id TAA17747 for ; Mon, 1 Jul 1996 19:05:25 -0700 Received: from localhost by ia.ENGR.ORST.EDU (1.39.111.2/ENGR-Client) id AA031783121; Mon, 1 Jul 1996 19:05:21 -0700 Date: Mon, 1 Jul 1996 19:05:21 -0700 (PDT) From: Stephane Chatre Cc: rem-conf@es.net Subject: unsubscribe In-Reply-To: <9607011501.AA22373@snowflake> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe chatre@engr.orst.edu From rem-conf-request@es.net Tue Jul 02 06:32:31 1996 Received: from kaukau.comp.vuw.ac.nz by osi-west.es.net with ESnet SMTP (PP); Tue, 2 Jul 1996 03:31:22 -0700 Received: from bats.comp.vuw.ac.nz (bats.comp.vuw.ac.nz [130.195.8.13]) by kaukau.comp.vuw.ac.nz (8.7.5/8.6.9-VUW) with ESMTP id WAA06532; Tue, 2 Jul 1996 22:31:04 +1200 (NZST) From: Mark Davies Received: from localhost (mark@localhost) by bats.comp.vuw.ac.nz (8.7.5/8.7.3) with SMTP id WAA29834; Tue, 2 Jul 1996 22:31:03 +1200 (NZST) Message-Id: <199607021031.WAA29834@bats.comp.vuw.ac.nz> X-Mailer: exmh version 1.6.5 12/11/95 To: George Michaelson cc: "Dwight E. Spencer" , ajv@axiom.co.nz, Russell Sutherland , rem-conf@es.net Subject: Re: vat/rat and X terminals In-reply-to: Your message of "Wed, 26 Jun 1996 08:38:48 +1000." <22090.835742328@connect.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Jul 1996 22:31:02 +1200 From: George Michaelson Date: Wed, 26 Jun 1996 08:38:48 +1000 > 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. We have a version of vat-4.0a6 with NAS support. It works OK with traditional NAS supporting NCD terminals and works as well as probably can be expected on the half duplex audio in the Explora's -- OK for listening, don't try and hold a two way conversation. The person who did the work isn't here anymore so I'm CC'ing this message to him. From memory what he said about it was that it will need some work for the latest (tcl7.5/tk4.1) based versions of vat as the event handling changes and it makes heavy use of it. Andrew, care to comment? cheers mark From rem-conf-request@es.net Tue Jul 02 08:29:40 1996 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 2 Jul 1996 05:28:07 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id FAA25817; Tue, 2 Jul 1996 05:24:48 -0700 Message-Id: <199607021224.FAA25817@rx7.ee.lbl.gov> To: Linda Cline cc: rem-conf@es.net, mojy@ibeam.jf.intel.com, Ken_K_Mills@ccm.jf.intel.com, Christian_Maciocco@ccm.jf.intel.com, Hariharan_Kumar@ccm.jf.intel.com Subject: Re: RTP Payload Format for G.723 In-reply-to: Your message of Mon, 01 Jul 96 10:15:39 PDT. Date: Tue, 02 Jul 96 05:24:46 PDT From: Van Jacobson > From the RTP spec, we have been working under the impression > that the marker bit is to be specified by the payload format, > for things such as marking the last packet for a video frame. > There is also the recommendation in the profile spec to use the > marker bit in audio for the first packet in a talkspurt, which > is entirely optional. Other than that, I'm not aware of any > dedicated purpose for the marker bit. Can you clarify the > "original meaning"? You have apparently not read the relevant RFCs. G.723 is an audio coding and falls under the RTP A/V profile (RFC1890). The opening paragraph of the "Audio" section (sec. 4) of RFC1890 says: For applications which send no packets during silence, the first packet of a talkspurt (first packet after a silence period) is distinguished by setting the marker bit in the RTP data header. Applications without silence suppression set the bit to zero. That was the "original meaning". It seemed clear enough to me and to the authors of every other RTP audio coding in use today. As a general comment, I read Intel's draft expecting to find something about G.723 (e.g., do you send or suppress silence frames [VADFLAG_B0 = 1] or do you anything to mitigate the fact that g.723 works on 30ms frames when every other currently used coding uses 20ms frames). Instead I discovered it contained not one word about G.723 (other than the title) and I found myself reading abount an FEC scheme designed by someone who appeared to know nothing about the characteristics of Internet packet loss. Perhaps you could re-title your draft to reflect its actual contents. At that point we could compare it with the FEC / redundent coding work done by UCL where the parties involved spent several years understanding the problem they eventually solved. - Van From rem-conf-request@es.net Tue Jul 02 09:25:40 1996 Received: from server21.digital.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 2 Jul 1996 06:24:42 -0700 Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by server21.digital.fr (8.7.5/8.7) with ESMTP id PAA06090 for ; Tue, 2 Jul 1996 15:26:01 +0200 (MET DST) Received: from valmts.vbe.dec.com (valmts.vbe.dec.com [16.36.176.78]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id PAA11401 for ; Tue, 2 Jul 1996 15:28:06 +0200 (MET DST) Received: from mts.dec.com by valmts.vbe.dec.com (PMDF V5.0-7 #16475) id <01I6LOI3T6K000KRNS@valmts.vbe.dec.com> for rem-conf@es.net; Tue, 02 Jul 1996 15:21:24 +0100 (CET) Received: with PMDF-MR; Tue, 02 Jul 1996 13:20:41 +0000 (GMT) MR-Received: by mta BERIS3; Relayed; Tue, 02 Jul 1996 13:20:41 +0000 MR-Received: by mta GYMRC; Relayed; Tue, 02 Jul 1996 13:20:44 +0000 MR-Received: by mta VALMTS; Relayed; Tue, 02 Jul 1996 13:21:01 +0000 Alternate-recipient: prohibited Disclose-recipients: prohibited Date: Tue, 02 Jul 1996 13:19:00 +0000 (GMT) From: "TORSTEN KERSCHAT @BEO 39083" <"TORSTEN KERSCHAT"@A1.BERIS3.BEO.mts.dec.com> Subject: unsubscribe To: =?ISO-8859-1?Q?Fern=FCbertragung?= Message-id: <01I6LOMQRXIQ00KRNS@mts.dec.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Posting-date: Tue, 02 Jul 1996 13:20:00 +0000 (GMT) Importance: normal Priority: normal X400-MTS-identifier: [;14023120706991/782518@BERIS3] A1-type: MAIL Hop-count: 3 torsten@prz.tu-berlin.de From rem-conf-request@es.net Tue Jul 02 11:03:03 1996 Received: from vtt.fi by osi-west.es.net with ESnet SMTP (PP); Tue, 2 Jul 1996 08:02:02 -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 SAA09901 for ; Tue, 2 Jul 1996 18:01:50 +0300 Message-Id: <2.2.32.19960702150401.00735678@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: Tue, 02 Jul 1996 18:04:01 +0300 To: rem-conf@es.net From: Jan Lucenius Subject: nv & CuSeeMe questions As Nv supports CuSeeme coding algorithm, I would like to know whether these two softwares may interwork with each other. I also have some more detailed questions: - does Nv in any way adjust its frame rate dynamically according to bandwidth, delays or congestion in the network? How is it with CuSeeMe? - Does CuSeeMe use rtp ? _________________________________________________________________________ _/ _/ _/ _/_/_ _/_/_ _/_/_/_/ Jan Lucenius _/ _/ _/ _/ _/ _/ phone +358-0-4566511 _/ _/ _/ _/_/ _/_/ _/_/_/ fax +358-0-4567013 _/ _/ _/ _ _/ _ _/ _/ VTT Information Technology _/_/_/_/ _/_/_/ _/_/ _/_/ _/_/_/_/ PB 1202, 02044 VTT, Finland www http://www.vtt.fi/tte/tte22/lucenius/ From rem-conf-request@es.net Tue Jul 02 12:49:54 1996 Received: from ns.research.att.com by osi-west.es.net with ESnet SMTP (PP); Tue, 2 Jul 1996 09:49:06 -0700 Received: from research.research.att.com by ns; Tue Jul 2 12:47:09 EDT 1996 Received: from raptor.research.att.com by research; Tue Jul 2 12:45:31 EDT 1996 Received: from [135.104.106.104] (quetzalcoatl.research.att.com [135.104.106.104]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id MAA27935; Tue, 2 Jul 1996 12:45:28 -0400 (EDT) Date: Tue, 2 Jul 1996 12:45:28 -0400 (EDT) X-Sender: otto@raptor.research.att.com (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: mbone@cilia.it From: George Otto Cc: rem-conf@es.net, otto@research.att.com Could you add the following URL to the announcement about the broadcast on July 4 of the Utah Phillips Benefit concert? The URL is http://www.att.com/community/groups/folkproject/fp_special.html Thanks for your help, George Otto (908) 582-5482 otto@research.att.com Folk Project Publicity ---------------------- From rem-conf-request@es.net Tue Jul 02 14:29:13 1996 Received: from netcom.netcom.com by osi-west.es.net with ESnet SMTP (PP); Tue, 2 Jul 1996 11:28:28 -0700 Received: (from maurer@localhost) by netcom.netcom.com (8.6.13/Netcom) id LAA17695; Tue, 2 Jul 1996 11:28:22 -0700 Date: Tue, 2 Jul 1996 11:28:22 -0700 From: maurer@netcom.com (William J. Maurer) Message-Id: <199607021828.LAA17695@netcom.netcom.com> To: rem-conf@es.net Subject: RTP profile for sensor encoding? Hi, I'm participating in a project to develop an "internet sensing capability" intended to allow clients to collect data from mobile sensors in real time for advanced signal processing applications. We're building a system on top of RTP and need to be able to obtain data from a variety of sensors (audio included). My presumption here is there are people in the RTP community doing these sorts of things already and it would be helpful to me, if no one else, to know what efforts or "sensor profiles" are under way. It would at least prevent us from re-inventing the wheel and it would be nice to get tied in with the RTP community. Thanks in advance for your help, William Maurer (maurer@netcom.com) From rem-conf-request@es.net Tue Jul 02 20:18:25 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 2 Jul 1996 17:17:53 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA25348; Tue, 2 Jul 1996 17:17:43 -0700 Date: Tue, 2 Jul 1996 17:17:42 -0700 (PDT) From: Stephen Casner To: Ofer Shapiro Cc: 'h323list' , 'rem-conf' Subject: Re: G.728 payload. In-Reply-To: <96Jul1.124854idt.24194@firewall.radvision.rad.co.il> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Ofer, > If you go through H.225 section 6.2.1, you understand that whole number > of frames shall be send in RTP packet (frame- I mean 2.5ms, you mentioned > blocks- I hope we mean same thing). This is clear enough. Yes, I did mean the same thing. > The part that is missing is the packing in the "sample level". For > instance, When G.728 arrives from the ISDN (H.320) it comes in a format > of 2 bits in a byte, one might suggest that in order to ease > implementation, a 320/323 GW would pack these 2 bits in one byte > (actually it wouldn't necessarily help, this is only example). This > course of action is actually mandated by 225 for G.711, G.722 section > 6.2.1). Obviously when dealing with G.728 the waste in bandwidth would be > larger, so one could argue that the packing should be complete: each > frame (40 bit) in 5 bytes. Hybrid solutions were also suggested. You raise a good point. I have discovered the hard way that there are different interpretations for the packing of GSM data, for example. I believe that we should add more information in the RTP A/V Profile for each of the audio payload formats that it specifies to clarify bit and byte packing, for example. > I think that no new header information is needed, just some text to > define the packing and maybe bit ordering. You are welcome to write this description as a separate Internet Draft if you would like. Alternatively, if only a couple of paragraphs are needed, you might write those to be included in the Profile. Are there existing implementations of G.728 being sent in RTP? -- Steve From rem-conf-request@es.net Wed Jul 03 02:49:11 1996 Received: from radvision.rad.co.il by osi-west.es.net with ESnet SMTP (PP); Tue, 2 Jul 1996 23:48:37 -0700 Received: by firewall.radvision.rad.co.il id <24194>; Wed, 3 Jul 1996 10:43:29 +0300 Message-Id: <96Jul3.104329idt.24194@firewall.radvision.rad.co.il> Date: Wed, 3 Jul 1996 06:00:03 +0300 Sender: neta@radvision.rad.co.il From: Neta Weinryb X-Mailer: Mozilla 1.1IS (X11; I; IRIX 5.3 IP22) Mime-Version: 1.0 Newsgroups: comp.dcom.videoconf To: rem-conf@es.net, videoconf@es.net Subject: RADVision's web site opened X-Url: news:comp.dcom.videoconf Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, RADVision now has a web site, and you're all invited! http://www.radvision.rad.co.il/ -- +++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Jul 03 03:32:52 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Wed, 3 Jul 1996 00:31:41 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA25841; Wed, 3 Jul 1996 00:26:08 -0700 Date: Wed, 3 Jul 1996 00:26:07 -0700 (PDT) From: Stephen Casner To: Linda Cline Cc: Henning Schulzrinne , rem-conf@osi-east.es.net, mojy@ibeam.jf.intel.com, Ken_K_Mills@ccm.jf.intel.com, Christian_Maciocco@ccm.jf.intel.com, Hariharan_Kumar@ccm.jf.intel.com Subject: Re: RTP Payload Format for G.723 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > >I'm a bit concerned about 'rededicating' the marker bit to indicate an > >alternate encoding. Unless there's a good reason to do this that I'm > >missing, I'd much rather stick with the original meaning and use two > >different encodings. One might also argue that the interleaving > >proposed should be addressed in a general way (see the proposal for > >redundant encodings aired at the AVT meeting), rather than a > >G.723-specific method. I concur with Henning on both counts. > From the RTP spec, we have been working under the impression that > the marker bit is to be specified by the payload format, for things such as > marking the last packet for a video frame. No. The RTP spec allows a Profile to define the marker bit. Since an application is likely to work with multiple payload formats within one profile, changing the definition of the marker bit from one payload format to another would make the application more difficult to implement. Within the profile, the meaning of the marker bit is defined independently for audio and for video. > There is also the recommendation > in the profile spec to use the marker bit in audio for the first packet in > a talkspurt, which is entirely optional. Please point out where the optional notion came from. > The > reason that we would like to use the marker bit to indicate the presence of > a payload specific header is that we would like to eliminate a payload > header completely in the normal mode. As others have suggested, if an interleaving scheme is to be defined, it should be done in a way that is not specific to the G.723 encoding. It should be indicated by a separate payload type, perhaps defined dynamically instead of statically in particular if the interleaving scheme might be selected from a number of options. > An alternative to this would be to use > a separate payload type for the normal and alternate modes, but this would > preclude the option of mixing the modes in a stream. Not true. One can change payload types during the course of a stream, including switching among static and dynamic payload types. > Also, it is not useful to interleave video data, Oh? I have seen many proposals to do this in papers published over the past 10 years or more. I have another question not raised earlier. The reason I have been anxiously awaiting the G.723 payload format spec was that H.225.0 said, "For audio algorithms such as G.723 which use more than one size of audio frame, audio frame boundaries within each packet shall be signaled in-band to the audio channel." That's what I expected the payload format to define, but if I read it correctly, it just says you can mix together whatever combination of audio frames you like. Please explain this apparent difference. -- Steve From rem-conf-request@es.net Wed Jul 03 09:19:45 1996 Received: from mroute.uni-mannheim.de (actually bibo.rz.uni-mannheim.de) by osi-west.es.net with ESnet SMTP (PP); Wed, 3 Jul 1996 06:19:04 -0700 Received: by mroute.uni-mannheim.de id AA07799 (5.67a/IDA-1.5 for rem-conf@es.net); Wed, 3 Jul 1996 15:19:39 -0100 Date: Wed, 3 Jul 1996 15:19:37 -0100 (GMT) From: ph@mroute.uni-mannheim.de To: rem-conf@es.net Subject: Problem with Sparc 5 Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, i have Problems running vat4.0a8 and vic2.7a38 on a Sparc 5 with Solaris 2.5 both tools quit receiving packets after appr. 5 minutes. When I start the sessions new, everything is ok again for another 5 minutes. I have read something about problems with mbone tools and Sparc 5 in this group but i can't find it anymore. Are there any patches or fixes available ? Thanks P.H ------------------------------------------------------------------- Peter Heiligers Email: heiligers@rz.uni-mannheim.de Computing Center Tel.: ++49-621-2921434 University Mannheim FAX: ++49-621-2925783 L15, 16 68131 Mannheim From rem-conf-request@es.net Wed Jul 03 15:34:50 1996 Received: from gaia.cs.umass.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 3 Jul 1996 12:33:26 -0700 Received: (from yajnik@localhost) by gaia.cs.umass.edu (8.7.3/8.6.9) id PAA17298 for rem-conf@es.net; Wed, 3 Jul 1996 15:33:24 -0400 (EDT) From: Maya Yajnik Message-Id: <199607031933.PAA17298@gaia.cs.umass.edu> Subject: Data on MBone Loss Available To: rem-conf@es.net Date: Wed, 3 Jul 1996 15:33:24 -0400 (EDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Data on the packet loss in the MBone is now available at the web-site http://www.cs.umass.edu/~yajnik/datasets.html A technical report describing the measurement setup is also available. Comments/criticisms/suggestions are greatly appreciated. -- Maya Yajnik ---------------------------------------- Maya Yajnik (yajnik@cs.umass.edu) Computer Networks Research Group University of Massachusetts at Amherst Phone: (413)545-3179 http://www.cs.umass.edu/~yajnik ---------------------------------------- Abstract of tech. report: "Packet Loss Correlation in the MBone Multicast Network" UMASS CMPSCI Techical Report # 96-32 A critical issue for such multicast applications and the higher layer protocols required to support them is the manner in which packet losses occur within the multicast network. In this paper we present and analyze packet loss data collected on multicast-capable hosts at 17 geographically distinct locations in Europe and the US and connected via the MBone. We experimentally and quantitatively examine the spatial and temporal correlation in packet loss among participants in a multicast session. Our results show that there is some spatial correlation in loss among the multicast sites. However, the shared loss in the backbone of the MBone is, for the most part, low. We find a fairly significant amount of burst loss (consecutive losses) at most sites. In every dataset, at least one receiver experienced a long loss burst greater than 8 seconds (100 consecutive packets). A predominance of solitary loss was observed in all cases, but periodic losses of length approximately 0.6 seconds and at 30 second intervals were seen by some receivers. ------------------------------------------------------------------------- From rem-conf-request@es.net Wed Jul 03 22:17:23 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 3 Jul 1996 19:16:56 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA27908; Wed, 3 Jul 1996 19:16:39 -0700 Date: Wed, 3 Jul 1996 19:16:38 -0700 (PDT) From: Stephen Casner To: Colin Perkins , Andres Vega Garcia Cc: rem-conf@es.net, merci@cs.ucl.ac.uk Subject: Re: Release of FreePhone audio tool In-Reply-To: <199606261604.SAA24009@fun.inria.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Colin and Andres, > 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). I took a look at this page and was very disturbed by what I saw, on a couple of counts: - We've moved past the early days of RTP experimentation. RTP and the A/V Profile are now standards track protocols, and it is no longer reasonable to take static payload types without registering them with IANA. - I think the high-quality audio payload format you've defined is a bad idea in several ways. I'll explain in more detail. 1) Payload Types You have used payload types 37 and 38 for the new formats. IANA has just assigned payload type 34, the next available number, to the H.263 video encoding. If you were using that one instead, then we would now have a problem. Or perhaps you are using that one as well for the variable-size ADPCM or some other encoding, and we already have a problem. Given that you are at the stage of releasing this software for general consumption, taking numbers without registering them is just not good practice. My position is that new experimental applications should use a dynamic type first, and then possibly get a static type assigned later if warranted. An impediment to this practice is that the sdr program does not yet support the creation of sessions using dynamic payload types, even though the SDP protocol does -- Mark Handley please consider yourself poked, or if I'm wrong, I will gladly accept chastisement. Precept's software uses a table in the initialization file (.INI in the PC world) to express mappings from static types to encoding descriptions of the form PCMU/8000 as defined in sdp. The program sets up its own table mapping from payload types (static or dynamic) to the encoding description. That way, if an encoding that was dynamic is later defined as static, all we have to do is update the .INI file. If we continue to receive the dynamic payload type definition, that works fine, too. In the UNIX world, this might be done in a .tcl file. The redundant audio scheme will probably get a registered static payload type assignment. As you note, it's been discussed in AVT and meets the criteria listed in the Profile. On the other hand, the definition may not yet be finalized -- Mark said the payload headers may all be aggregated at the beginning of the packet as was suggested during the recent AVT meeting. Also, this redundant audio scheme would probably get a number assigned >from the 18-23 range rather than the 35-71 range since we were trying to keep the audio and video assignments segregated. 2) High Quality Audio There is no need to define a static payload type for high-quality audio as you have done, and introduce another level of multiplexing/option processsing in the data path. All of these payload formats can be expressed in a form such as L8/11025/2 (linear 8-bit samples, 11025 Hz sampling, 2 channels) and mapped to a dynamic payload type (in the range 96-127). SDP supports that. I know it works because we've implemented it in Precept's software. Your format introduces an extra 16-bit header that wastes space in each packet; perhaps that is not critical if 1000 bytes of audio are being sent, but in the high data rate case the fact that you've shifted to a 16-bit alignment may reduce cache efficiency when copying the data into and out of packets. One notion that is part of the payload formats defined in the A/V Profile is that each payload type has an RTP clock rate associated with it. That's important because the clock rate is used in RTP timestamp and jitter calculations for RTCP messages in addition to processing by the decoder. For audio, the RTP clock rate is the sampling rate of the audio, but what do you do for this high-quality audio payload type? Does it change whenever you change the freq field? Another problem is that the high quality audio format overlaps with the static payload types for L16/44100 and L16/44100/2, but the two would not be compatible because your high-quality audio format includes an additional header. This impairs interoperability. My last question is regarding the PT field. If the PT field of the RTP header is 38, and the data is L8/11025/2, what goes into the PT field in the 16-bit header? I assume that you've created this payload type because there are so many combinations that you could not expect to have static types assigned for each one. That is exactly the problem that the dynamic payload types were intended to solve. Let's use them. -- Steve From rem-conf-request@es.net Thu Jul 04 04:16:33 1996 Received: from moon (actually moon.bjnet.edu.cn) by osi-west.es.net with ESnet SMTP (PP); Thu, 4 Jul 1996 01:15:21 -0700 Received: by moon (5.x/SMI-SVR4) id AA27566; Thu, 4 Jul 1996 16:13:22 +0900 Date: Thu, 4 Jul 1996 16:13:22 +0900 From: haitao@moon.bjnet.edu.cn (Zhang Haitao) Message-Id: <9607040713.AA27566@moon> Apparently-To: rem-conf@es.net hi, i have compiled the IP Multicast 3.5 kernel on an DTK CLASSIC+ machine ( architecure: sun4m , OS: sun_os 4.1.3) , and the compilation is right. but after reboot progress, the following error message keep displayed: le0: TINT but buffer owned by LANCE le0: RINT but buffer owned by LANCE is that the problem of network card le0 , or some compile problems? thanks for suggestions, haitao, From rem-conf-request@es.net Thu Jul 04 05:01:57 1996 Received: from pec.etri.re.kr by osi-west.es.net with ESnet SMTP (PP); Thu, 4 Jul 1996 02:01:21 -0700 Received: by pec.etri.re.kr (8.6.9H1/8.6.4) id SAA19786; Thu, 4 Jul 1996 18:55:36 +1000 From: Myung-Ki Shin Posted-Date: Thu, 4 Jul 1996 18:55:36 +1000 Message-Id: <199607040855.SAA19786@pec.etri.re.kr> Subject: KRNET'96 on MBone To: rem-conf@es.net Date: Thu, 4 Jul 1996 18:55:36 +0900 (GMT+9:00) X-Mailer: ELM [version 2.4 PL21-h4] Content-Type: text Content-Length: 1655 ************************************* * KRNET'96 * * * * July 8-11, 1996 * * Seoul, Korea * ************************************* KRNET'96 is one of the biggest network show in Korea. We will broadcast a tutorial of KRNET'96 on July 8. Please see also http://pec.etri.re.kr/krnet/ . And SDR can give you the information to participate in the session by the network. Title : Network Security Lecturer : Charles Kaufman(IRIS) Date : 1996.7.8 10:00 - 17:00 (KST), 01:00 - 08:00 (UTC) Abstract : The International, intercoporate, information superhighway is a scary place. There are spies anxious to steal our secrets, there are tabloid reporters eager for a juicy scoop. There are criminals hoping to steal good and services Aimed at the technically asute but security novice, this tutorial covers the nuts and bolts of designing secure protocols to thwart these various threats. This is not a survey of existing secury products, but rather a grounding in security fundamentals to help you evaluate products or develop new ones. For further information, please contact krnet-mbone@pec.etri.re.kr. We'll eagerly looking forward to your participation. Sincerely, MBONE-KR mbone-kr@knc.or.kr -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Myung-Ki Shin | mkshin@pec.etri.re.kr ETRI/PEC | P.O. Box 106, Yusong | Daejeon, 305-350, Korea $)C | "O:+82-42-860-4847 | FAX:+82-42-861-5404 | http://pec.etri.re.kr/~mkshin/ From rem-conf-request@es.net Thu Jul 04 05:27:00 1996 Received: from moon (actually moon.bjnet.edu.cn) by osi-west.es.net with ESnet SMTP (PP); Thu, 4 Jul 1996 02:26:19 -0700 Received: by moon (5.x/SMI-SVR4) id AA27946; Thu, 4 Jul 1996 17:25:47 +0900 Date: Thu, 4 Jul 1996 17:25:47 +0900 From: haitao@moon.bjnet.edu.cn (Zhang Haitao) Message-Id: <9607040825.AA27946@moon> Apparently-To: rem-conf@es.net hi, i have compiled the IP Multicast 3.5 kernel on an DTK CLASSIC+ machine ( architecure: sun4m , OS: sun_os 4.1.3) , and the compilation is right. but after reboot progress, the following error message keep displayed: le0: TINT but buffer owned by LANCE le0: RINT but buffer owned by LANCE is that the problem of network card le0 , or some compile problems? thanks for suggestions, haitao, From rem-conf-request@es.net Thu Jul 04 09:25:06 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 4 Jul 1996 06:24:31 -0700 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 4 Jul 1996 14:23:34 +0100 To: Stephen Casner cc: Andres.Vega_Garcia@sophia.inria.fr, rem-conf@es.net, merci@cs.ucl.ac.uk Subject: Re: Release of FreePhone audio tool In-reply-to: Your message of "Wed, 03 Jul 1996 19:16:38 PDT." Date: Thu, 04 Jul 1996 14:23:30 +0100 Message-ID: <2493.836486610@cs.ucl.ac.uk> From: Colin Perkins --> Stephen Casner writes: >--> Andres Vega Garcia writes: >> 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). > >I took a look at this page and was very disturbed by what I saw, on a >couple of counts: > > - We've moved past the early days of RTP experimentation. RTP and > the A/V Profile are now standards track protocols, and it is no > longer reasonable to take static payload types without registering > them with IANA. > > - I think the high-quality audio payload format you've defined is a > bad idea in several ways. There are two issues here: redundancy and high-quality audio. I think it's important to note that these proposals are entirely separate, and should stand or fall on their individual merits. 1) Redundancy You are, of course, correct to say that the use of unregistered static payload types is bad practice, and I think it's fair to say we made a mistake in choosing the default to be in this range. It was my hope that we could eventually be assigned a static payload type for redundant encodings by IANA, and the temporary value we have used would quietly fade away; hence our redundant encodings draft does not in any way specify a choice of payload type, and I was a little surprised to find this choice documented on the WWW. Note that the UCL Robust Audio Tool (RAT) supports a command line option (-rpt ) to select the payload type used for redundancy, and so fully supports the use of dynamic payload types once the infrastructure required to communicate this choice to all participants in a session becomes available. 2) High Quality Audio Since the UCL audio tool does not currently support high quality audio, I will leave discussion of this to others more knowledgable. My only comment is that this payload format was intended for private testing use, and that my minutes of the meeting where this format was defined refer to it as a "temporary hack" and suggest that further work is required in this area. Regards, Colin From rem-conf-request@es.net Thu Jul 04 09:52:11 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 4 Jul 1996 06:51:26 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 4 Jul 1996 14:49:01 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Stephen Casner cc: Colin Perkins , Andres Vega Garcia , rem-conf@es.net, merci@cs.ucl.ac.uk Subject: Re: Release of FreePhone audio tool In-reply-to: Your message of "Wed, 03 Jul 96 19:16:38 PDT." Date: Thu, 04 Jul 96 14:49:00 +0100 Message-ID: <15523.836488140@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >> 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). ... >My position is that new experimental applications should use a dynamic >type first, and then possibly get a static type assigned later if >warranted. An impediment to this practice is that the sdr program >does not yet support the creation of sessions using dynamic payload >types, even though the SDP protocol does -- Mark Handley please >consider yourself poked, or if I'm wrong, I will gladly accept >chastisement. Steve is completely correct here, and we did ensure that the redundancy draft (draft-perkins-rtp-redundancy-00.txt) does not specify a payload type. Fully supporting dynamic types in sdr is very near the top of the priority list - it simply didn't get added because there were no tools (til RAT 2.5) that supported it. On the receive side, it's already supported in sdr - it just requires an appropriate plugin for tools that support dynamic payload types. The main problem with sdr is that it doesn't yet fully support payload lists. >The redundant audio scheme will probably get a registered static >payload type assignment. As you note, it's been discussed in AVT and >meets the criteria listed in the Profile. On the other hand, the >definition may not yet be finalized -- Mark said the payload headers >may all be aggregated at the beginning of the packet as was suggested >during the recent AVT meeting. This is current under discussion - if we do adopt this idea, it would be good to attribute it to whoever suggested it, but unfortunately neither Steve or I can remember whose idea it was! We'll make a decision either way regarding this change in the next few days. Mark From rem-conf-request@es.net Thu Jul 04 11:00:30 1996 Received: from fun.inria.fr by osi-west.es.net with ESnet SMTP (PP); Thu, 4 Jul 1996 07:59:56 -0700 Received: by fun.inria.fr (8.7.5/8.6.12) id QAA04351; Thu, 4 Jul 1996 16:59:37 +0200 (MET DST) Message-Id: <199607041459.QAA04351@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 Wed, 03 Jul 1996 19:16:38 PDT. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 04 Jul 1996 16:59:36 +0200 From: Andres Vega Garcia : Stephen Casner wrote: >Colin and Andres, > >> 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). > >I took a look at this page and was very disturbed by what I saw, on a >couple of counts: > > - We've moved past the early days of RTP experimentation. RTP and > the A/V Profile are now standards track protocols, and it is no > longer reasonable to take static payload types without registering > them with IANA. > > - I think the high-quality audio payload format you've defined is a > bad idea in several ways. > Next release of Free Phone will support dynamic payload types. > >2) High Quality Audio > >There is no need to define a static payload type for high-quality >audio as you have done, and introduce another level of >multiplexing/option processsing in the data path. All of these >payload formats can be expressed in a form such as L8/11025/2 (linear >8-bit samples, 11025 Hz sampling, 2 channels) and mapped to a dynamic >payload type (in the range 96-127). SDP supports that. I know it >works because we've implemented it in Precept's software. >Your format introduces an extra 16-bit header that wastes space in >each packet; Well, I completly agree with the two previous paragraphs, that's why we are going to implement the dynamic assignment of payload types for Free Phone. > >One notion that is part of the payload formats defined in the A/V >Profile is that each payload type has an RTP clock rate associated >with it. That's important because the clock rate is used in RTP >timestamp and jitter calculations for RTCP messages in addition to >processing by the decoder. I guess jitter calculation must be done only with the main block's timestamp and not with the redundant block which may be data with an inherent sampling rate different (under-sampling). > For audio, the RTP clock rate is the >sampling rate of the audio, but what do you do for this high-quality >audio payload type? Does it change whenever you change the freq >field? Every block (main/redundancy/high_quality) has to have a timestamp as if they were sampled at the same frequency. That is normal as in fact the redundancy is derived by `undersampling or/and coding with a different codec' the main data and as we need anyway to under/over sample the data from any given source in order it has our local sampling rate. Playout calculation is done only with main data. > >Another problem is that the high quality audio format overlaps with >the static payload types for L16/44100 and L16/44100/2, but the two >would not be compatible because your high-quality audio format >includes an additional header. This impairs interoperability. Once the dynamic PTs is implemented in Free Phone, we wont need that header. > >My last question is regarding the PT field. If the PT field of the >RTP header is 38, and the data is L8/11025/2, what goes into the PT >field in the 16-bit header? At this time you specify with PT=38 that a high quality audio block follows, then your *high quality* parameters are specified in that header, of course, once again, with a dynamic payload type assigned to L16/44100/2, the information before was contained in that header will be taken from the payload type especification. > >I assume that you've created this payload type because there are so >many combinations that you could not expect to have static types >assigned for each one. Right. > That is exactly the problem that the dynamic >payload types were intended to solve. Let's use them. > -- Steve -Andres From rem-conf-request@es.net Thu Jul 04 12:52:10 1996 Received: from pax.inria.fr by osi-west.es.net with ESnet SMTP (PP); Thu, 4 Jul 1996 09:51:15 -0700 Received: by pax.inria.fr (8.7.5/8.6.12) id SAA17628; Thu, 4 Jul 1996 18:51:02 +0200 (MET DST) Message-Id: <199607041651.SAA17628@pax.inria.fr> To: Stephen Casner cc: Colin Perkins , Andres Vega Garcia , rem-conf@es.net, merci@cs.ucl.ac.uk Subject: Re: Release of FreePhone audio tool In-reply-to: Your message of "Wed, 03 Jul 1996 19:16:38 PDT." Date: Thu, 04 Jul 1996 18:51:01 +0200 From: Jean-Chrysostome Bolot Steve, A couple of comments on the redundant and high quality audio coding. The work on redundant coding has been going on for quite a while now. A year ago, we used in Free Phone the X extension bit in the RTP header to indicate the use of redundant coding. Discussions with UCL identified 3 ways of using redundant coding, namely using the X bit, using a special static payload type, or using a dynamic payload type. We wanted our tools (Free Phone and RAT) to work together without having to rely on tools such as sdr that allow (or will allow) the creation of sessions with dynamic types. So we chose the static type solution (the 3 solutions and the "preferred solution" (static payloal) were actually presented by Mark in the Feb IETF meeting). We modified Free Phone, and RAT people modified RAT, accordingly. As you rightly point out, the choice of payload type 37 was not optimal in any case. This specific number does not appear in the ID. We do mention it in the Free Phone Web page, though, because Free Phone does rely on it (plus you know your first question would have been "which nb did you pick?", right? -) The choice of static payload type 38 for HQ audio was made in parallel with that of type 37 for redundant coding, and for similar reasons (too many combinations to assign a static type to each, rapid interoperability without session creation tools, etc). As Andres and Colin indicate, both Free Phone and RAT can, with little or no modification, select specific payload types for both redundant and HQ audio, and thus support (e.g. via sdr) the use of dynamic payload types. -Jean From rem-conf-request@es.net Thu Jul 04 22:49:14 1996 Received: from mail.ncku.edu.tw by osi-west.es.net with ESnet SMTP (PP); Thu, 4 Jul 1996 19:48:45 -0700 Received: (from ckwen@localhost) by mail.ncku.edu.tw (8.6.12/8.6.12) id KAA19402; Fri, 5 Jul 1996 10:45:12 +0800 From: Cheng-Kang Wen Message-Id: <199607050245.KAA19402@mail.ncku.edu.tw> Subject: Re: your mail To: haitao@moon.bjnet.edu.cn (Zhang Haitao) Date: Fri, 5 Jul 1996 10:45:12 +0800 (WST) Cc: rem-conf@es.net In-Reply-To: <9607040713.AA27566@moon> from "Zhang Haitao" at Jul 4, 96 04:13:22 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 144 > ( architecure: sun4m , OS: sun_os 4.1.3) , and the compilation is right. Upgrade SunOS 4.1.3 to 4.1.3U1. I did so to fix the problem. -Wen From rem-conf-request@es.net Fri Jul 05 08:50:52 1996 Received: from ceres.fokus.gmd.de by osi-west.es.net with ESnet SMTP (PP); Fri, 5 Jul 1996 05:50:15 -0700 Received: from fokus.gmd.de by ceres.fokus.gmd.de id <23032-0@ceres.fokus.gmd.de>; Fri, 5 Jul 1996 14:46:52 +0200 To: rem-conf@es.net Subject: CFP: Communications Magazine Feature Series on Internet Technology Content-Length: 3506 Date: Fri, 5 Jul 1996 14:46:52 +0200 From: Henning Schulzrinne Sender: schulzrinne@fokus.gmd.de Call for Papers: IEEE Communications Magazine: Internet Technology The IEEE Communications Magazine is starting a new feature series on Internet Technology. You are invited to contribute articles for the first installment to be published in January 1997. For the feature series, articles of a tutorial and survey nature are particularly welcome. Topics Topics of interest include: * General topics: o Evolution of the Internet and WWW: past, present, and future o Legal and regulatory issues (e.g., regulation of Internet telephony) o Privacy, security and billing * Internet technologies and applications: o Broadband consumer/home access to the Internet o Using the Internet to improve telecom services o Routing, addressing, naming, and large scale multicast o ATM, Frame Relay and SMDS as part of the Internet o Performance and reliability o Nomadic computing and communications o Multimedia services to the desktop, e.g. real-time audio/video conferencing, signaling, QoS guarantees o Interactive multimedia video, sound and more on commercial networks o Internet telephony o Distributed simulation o Internet management experiences and solutions o Enterprise networking architectures and applications o Internet access in sparsely populated regions o Virtual corporate networks o Security, billing, and privacy for electronic commerce IEEE Communications Magazine is read by tens of thousands of Communications Society members. The papers will be available on the Internet through Communications Magazine Interactive, the WWW edition of the magazine. Details about IEEE Communications Magazine can be found at http://www.ieee.org/comsoc/commag.html. Schedule Manuscripts due: September 1, 1996 Notification of acceptance: October 1, 1996 Final copy due: November 1, 1996 Magazine issue: January 1997 Note: Articles submitted after the due date may be considered for publication in a later installment of the series. How to submit manuscripts Articles should not exceed 4500 words. Figures and tables should be limited to a combined total of six. Mathematical equations should not be used unless they are vital to the presentation. Even then, they should be kept to a minimum. References should be included only to guide a reader to more information on the topic; the reference list should not include every available source (a limit of ten references is recommend.) Use footnotes only where necessary. Submitted manuscripts should not have been published before in other journals or magazines; papers revised from workshop and conference contributions are welcome. The author kit can be found at http://gaia.cs.umass.edu/tccc/ComMag/authorkit.html. Electronic submission of manuscripts as either Postscript or PDF is preferred. Please send manuscripts by electronic mail to Henning Schulzrinne at schulzrinne@fokus.gmd.de If you prefer to submit hardcopy, please send four copies of the manuscript (double-sided if possible, double-spaced) to: Until July 20: Henning Schulzrinne GMD Fokus Hardenbergplatz 2 10623 Berlin Germany After July 20: Henning Schulzrinne Dept. of Computer Science Columbia University New York, NY 10027 This CFP is available at http://www-net.cs.umass.edu/tccc/1996/ComMag_IT.html From rem-conf-request@es.net Sat Jul 06 04:07:28 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sat, 6 Jul 1996 01:06:47 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA29545; Sat, 6 Jul 1996 01:06:39 -0700 Date: Sat, 6 Jul 1996 01:06:38 -0700 (PDT) From: Stephen Casner To: Jean-Chrysostome Bolot Cc: Colin Perkins , Andres Vega Garcia , rem-conf@es.net, merci@cs.ucl.ac.uk Subject: Re: Release of FreePhone audio tool In-Reply-To: <199607041651.SAA17628@pax.inria.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Jean, Thanks for your note and those of the others supporting the conversion to dynamic payload types. One clarification: > Discussions with UCL identified > 3 ways of using redundant coding, namely using the X bit, using a special > static payload type, or using a dynamic payload type. My recollection is that in the option to use dynamic payload types, several types would be defined, each specifying one combination of primary and redundant encodings. During a session one would switch among the dynamic payload types as needed to choose the desired combination of encodings. This was actually my preference among the three options, but it wasn't the winner. What I'm talking about now is different. Given that the new redundant payload format with a chain of headers has been defined, I'm just talking about identifying that new format with a single dynamic payload type instead of an unregistered static payload type for initial testing. > We wanted our tools > (Free Phone and RAT) to work together without having to rely on tools > such as sdr that allow (or will allow) the creation of sessions with > dynamic types. This depencence is a valid concern. However, I believe almost all uses of tools like RAT and Free Phone would involve some control communication (like sdr or the signaling protocol of Free Phone) to convey information such as addresses and ports to be used. Those communication paths can also carry the dynamic payload type mappings. -- Steve From rem-conf-request@es.net Sun Jul 07 20:36:36 1996 Received: from matilda.wpine.com by osi-west.es.net with ESnet SMTP (PP); Sun, 7 Jul 1996 17:36:03 -0700 Received: from visual.wpine.com ([140.249.4.31]) by matilda.wpine.com (post.office MTA v1.9.3 ID# 0-13495) with SMTP id AAA9086; Sun, 7 Jul 1996 20:30:00 -0400 Received: from boggs.wpine.com.wpine.com by visual.wpine.com (8.6.9/VM-941107.1) id UAA26785; Sun, 7 Jul 1996 20:37:39 -0400 Received: by boggs.wpine.com.wpine.com (4.1/VN941029.1) id AA29536; Sun, 7 Jul 96 20:30:14 EDT Message-Id: <9607080030.AA29536@boggs.wpine.com.wpine.com> To: Jan Lucenius Cc: rem-conf@es.net, boshea@wpine.com Subject: Re: nv & CuSeeMe questions In-Reply-To: Your message of "Tue, 02 Jul 1996 18:04:01 +0300." <2.2.32.19960702150401.00735678@tel1.tte.vtt.fi> Date: Sun, 07 Jul 1996 20:30:13 -0400 From: Brian O'Shea >Subject: nv & CuSeeMe questions > >As Nv supports CuSeeme coding algorithm, I would like to know >whether these two softwares may interwork with each other. Only through a reflector that is enabled to support NV. The White Pine public reflector, cuseeme.com (192.233.34.5), allows NV connections on port 4444. > >I also have some more detailed questions: > >- does Nv in any way adjust its frame rate dynamically according >to bandwidth, delays or congestion in the network? As far as I know, it does not. You do however have a slider that controls the bandwidth, and for the WP Public reflector we request that you use 80kb/s. >How is it with CuSeeMe? Yes, CU-SeeMe does dynamic configuration and adjustment of the amount of data that is sent based on observed packet loss. >- Does CuSeeMe use rtp ? Yes and No. NV uses RTP, version 1.0 I beleive, but it could be version 0, to transport video in the B+W CU-SeeMe video format. The reflector then strips off the RTP header and fabricates a CU-SeeMe header for transmission to the CU-SeeMe participants connected. In the other direction it strips off the CU-SeeMe header and fabricates an RTP header when sending to NV. The CU-SeeMe Windows and MAC clients don't understand RTP, but the reflectors do. Hope that answers your questions. +***********************************************************************+ + Brian O'Shea White Pine Software + + Reflector Group Leader 15 Messenger Square + + boshea@wpine.com Suite 8A + + Fax 508-695-2378 Plainville MA, 02762 + + All it takes is all you've got. + +***********************************************************************+ From rem-conf-request@es.net Mon Jul 08 12:15:37 1996 Received: from yosemite.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Mon, 8 Jul 1996 09:15:08 -0700 Received: (from kamps@localhost) by yosemite.lbl.gov (8.7.3/8.7.3/NERSC-Feb96) id JAA05912; Mon, 8 Jul 1996 09:15:05 -0700 (PDT) Date: Mon, 8 Jul 1996 09:15:05 -0700 (PDT) From: Marcy Kamps Message-Id: <199607081615.JAA05912@yosemite.lbl.gov> To: cliff@organic.com Subject: Re: subscribe Cc: rem-conf@es.net X-Sun-Charset: US-ASCII Cliff, You have been added to the rem-conf@es.net mailing list. Here is some information about the list: 1) The rem-conf mailing list is used for IETF Remote Conferencing. 2) To UNSUBSCRIBE from the rem-conf mailing list, send email to rem-conf-request@es.net. 3) To SUBSCRIBE to the rem-conf mailing list, send email to rem-conf-request@es.net. 4) Please do not send subscribe or unsubscribe requests directly to the list address, rem-conf@es.net. This address is used only for discussions related to the purpose of the mailing list (see #1). 5) Before posting to the mailing list, we strongly encourage you to view the appropriate use guidelines for electronic mailing lists which can be viewed using your favorite WWW browser: http://www.es.net/hypertext/listmgr/list-netiquette.html 6) The ESnet mailhubs do not run listserv software, so listserv commands will not work. 7) The archive for the rem-conf@es.net mailing list may be retrieved via: http://www.es.net/pub/mailing-lists/mail-archive/rem-conf Please report any suggestions or problems to rem-conf-request@es.net. Thanks, Marcy L. Kamps ************************************************************************ National Energy Research Scientific Computing Center (NERSC) Energy Sciences Network (ESnet) Lawrence Berkeley National Laboratory Phone : 1-510-486-6448 One Cyclotron Road, Bldg. 50C, Room 103 (or) : 1-800-66-NERSC Berkeley, CA 94720 USA Email : kamps@nersc.gov Internet: postmaster@es.net ************************************************************************ ----- Begin Included Message ----- >From rem-conf-postmaster-request@es.net Sat Jul 6 03:11 PDT 1996 X-Authentication-Warning: bauhaus.organic.com: cliff owned process doing -bs Date: Sat, 6 Jul 1996 03:14:45 -0700 (PDT) From: Cliff Skolnick To: rem-conf-request@es.net Subject: subscribe MIME-Version: 1.0 subscribe -- Cliff Skolnick, CIO http://www.organic.com/ cliff@organic.com Organic Online, Inc. ** we're hiring ** (415) 278-5650 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 ----- End Included Message ----- From rem-conf-request@es.net Mon Jul 08 16:34:02 1996 Received: from my28.sm.luth.se by osi-west.es.net with ESnet SMTP (PP); Mon, 8 Jul 1996 13:33:31 -0700 Received: from orion.hip.berkeley.com (ip229.concord.ca.interramp.com [38.28.3.229]) by my28.sm.luth.se (8.7.5/8.7.2) with SMTP id WAA01799; Mon, 8 Jul 1996 22:32:48 +0200 Message-Id: <1.5.4.32.19960708202346.0066b2d8@my28.sm.luth.se> X-Sender: micke@my28.sm.luth.se (Unverified) X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 08 Jul 1996 13:23:46 -0700 To: Stephen Casner From: Mikael Degermark Subject: Global vs. per-stream sequence numbers Cc: micke@sm.luth.se, rem-conf@es.net Hello Steve, I have been mulling around what we talked about at IETF concerning whether the sequence numbers should be A. global - a single counter is used for all streams and is incremented for every packet the compressor sends. This requires loss indication from the link layer, and when a loss is indicated all contexts are invalidated so new full headers must be sent. B. per-stream - a counter per stream is incremented for every packet belonging to the stream. This means that the sequence numbers are slower to wrap around and fewer bits can be used (if there are many streams). It is also natural to have selective CONTEXT_ERROR messages that indicate which CID to refresh in this case. A problem with A is that if there are many streams each loss momentarily increases bandwidth required by headers considerably, because all headers must be refreshed. This is very bad for wireless links where losses are fairly frequent. On such links losses usually occur in small bursts, which means that sequence numbers should be long enough to cover such burst. Using a global sequence number then means that more bits are required for the sequence number. A problem with B is that if a single packet in a stream is lost, it is not detected until the next in that stream arrives. Even if the link-layer tells the decompressor that a packet was lost, there is no information as to what stream the packet belonged to. I guess the time could concievably be used as an indication, but then things quickly get complicated because you need to keep track of the current time and the expected arrival times of packets, etc. So you always lose one extra packet in a stream before the inconsistent compression state is detected. With B, a decompressor could invalidate *all* streams when there are few streams and revert to per-stream invalidation when there are many streams. Assuming there is some locality in the packet streams, so that only a few are active at a given time, the "one extra loss" problem with B can be alleviated when there are many flows by having the decompressor request header refreshes for a small number of recently used streams when loss is indicated by the link layer. If this works, B is clearly the better choice. If you haven't figured this out yet, I think B is the way to go and that slightly clever use of CONTEXT_ERROR indications can solve the "one extra loss" problem. Micke Degermark From rem-conf-request@es.net Mon Jul 08 23:53:13 1996 Received: from dfw-ix1.ix.netcom.com by osi-west.es.net with ESnet SMTP (PP); Mon, 8 Jul 1996 20:52:44 -0700 Received: from (gvsi@sjx-ca13-21.ix.netcom.com [199.182.128.181]) by dfw-ix1.ix.netcom.com (8.6.13/8.6.12) with SMTP id UAA20206; Mon, 8 Jul 1996 20:52:38 -0700 Date: Mon, 8 Jul 1996 20:52:38 -0700 Message-Id: <199607090352.UAA20206@dfw-ix1.ix.netcom.com> From: gvsi@ix.netcom.com (Megan Kirst) Subject: Fwd: Re: ISDN, Videoconferencing and Telecom Books To: videophone@es.net To: cu-seeme-l@cornell.edu To: rem-conf@es.net To: mbone@isi.net ---- Begin Forwarded Message 220 41328 <4rsjpc$469@dfw-ixnews4.ix.netcom.com> article Path: ix.netcom.com!news From: Newsgroups: comp.dcom.isdn Subject: Re: ISDN, Videoconferencing and Telecom Books Date: 9 Jul 1996 03:30:52 GMT Organization: Netcom Lines: 40 Message-ID: <4rsjpc$469@dfw-ixnews4.ix.netcom.com> NNTP-Posting-Host: sjx-ca13-21.ix.netcom.com X-NETCOM-Date: Mon Jul 08 10:30:52 PM CDT 1996 Robert, In reference to your question about ISDN and Videoconferencing books, yes we do carry a number of them, some of the titles include: ISDN A Practical Guide to get up and Running.....$22.00 on sale The Basics Book of ISDN..........................$10.00 on sale Special Edition, Using ISDN......................$27.00 on sale A couple of other titles that might be of interest to you are: ATM Asynchronous Transfer Mode User's Guide......$31.00 on sale The Guide to T-1 Networking......................$27.00 on sale As for videoconferencing books, we carry: Videoconferencing the Whole Picture..............$22.00 on sale Internet TV with CU-SeeMe........................$23.00 on sale MBone: Interactive multimedia on the Internet....$29.00 on sale And in the area of Telephony: PC Telephony, The Complete Guide.................$31.00 on sale Understanding Computer Telephony.................$22.00 on sale How to cable the Home Office/Small Office........$22.00 on sale You can reach us by calling 1-800-909-4874 or 408-280-1400. We accept Visa, MasterCard and AmEx. If you would like, you can also fax us a P.O. at 408-280-1402. Our email address is GVSI@aol.com Hope all of this helps, please feel free to call if you have any questions. Jim Global Videoconferencing Solutions http:\\www.globalvideoconf.com ---- End Forwarded Message From rem-conf-request@es.net Tue Jul 09 11:22:08 1996 Received: from IETF.cnri.reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Tue, 9 Jul 1996 08:21:25 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11037; 9 Jul 96 9:49 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-h261-02.txt Date: Tue, 09 Jul 96 09:49:14 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9607090949.aa11037@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 for H.261 video streams Author(s) : T. Turletti, C. Huitema Filename : draft-ietf-avt-h261-02.txt Pages : 14 Date : 07/08/1996 This draft describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-h261-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-h261-02.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-h261-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: <19960708130505.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-h261-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-h261-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960708130505.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Jul 09 11:22:41 1996 Received: from IETF.cnri.reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Tue, 9 Jul 1996 08:21:27 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11059; 9 Jul 96 9:49 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-08.txt Date: Tue, 09 Jul 96 09:49:25 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9607090949.aa11059@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-08.txt Pages : 8 Date : 07/08/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-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-cellb-08.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-08.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: <19960708131641.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-cellb-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-cellb-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960708131641.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Jul 09 11:23:14 1996 Received: from IETF.cnri.reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Tue, 9 Jul 1996 08:21:30 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11082; 9 Jul 96 9:49 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-jpeg-03.txt Date: Tue, 09 Jul 96 09:49:21 -0400 Sender: cclark@CNRI.Reston.VA.US Message-ID: <9607090949.aa11082@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 for JPEG-compressed Video Author(s) : L. Berc, W. Fenner, R. Frederick, S. McCanne Filename : draft-ietf-avt-jpeg-03.txt Pages : 15 Date : 07/08/1996 This draft describes the RTP payload format for JPEG video streams. The packet format is optimized for real-time video streams where codec parameters change rarely from frame to frame. This document is a product of the Audio-Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the author(s). 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-jpeg-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-avt-jpeg-03.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-jpeg-03.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: <19960708131122.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-avt-jpeg-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-avt-jpeg-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960708131122.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From rem-conf-request@es.net Tue Jul 09 17:12:07 1996 Received: from cesit1.unifi.it by osi-west.es.net with ESnet SMTP (PP); Tue, 9 Jul 1996 14:11:30 -0700 Received: from INGFI1.ING.UNIFI.IT by CESIT1.UNIFI.IT (PMDF V5.0-4 #3688) id <01I6VUXQML0W000IOF@CESIT1.UNIFI.IT> for rem-conf@es.net; Tue, 09 Jul 1996 22:09:45 +0100 (MET) Received: from aguirre.ing.unifi.it by INGFI1.ING.UNIFI.IT with SMTP; Tue, 09 Jul 1996 22:09:15 +0200 (MET-DST) Received: from ozon180.ing.unifi.it by aguirre.ing.unifi.it (4.1/SMI-4.1) id AA04796; Tue, 09 Jul 1996 15:54:00 +0200 Received: by ozon180.ing.unifi.it (5.0/SMI-SVR4) id AA03360; Tue, 09 Jul 1996 15:46:18 +0200 Date: Tue, 09 Jul 1996 15:46:18 +0200 From: oq95@aguirre.ing.unifi.it Subject: CFP: 1st Euromicro Conf. on Soft. Maint. and ReEngineering. To: selist@aguirre.ing.unifi.it Errors-to: oq95@aguirre.ing.unifi.it Errors-to: oq95@aguirre.ing.unifi.it Reply-to: oq95@aguirre.ing.unifi.it Message-id: <9607091346.AA03360@ozon180.ing.unifi.it> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII Please accept my apologies if you receive multiple copies of this Call-for-Paper. ============================================================================== Call for Papers FIRST EUROMICRO WORKING CONFERENCE ON SOFTWARE MAINTENANCE AND REENGINEERING Berlin, GERMANY, March 17-19, 1997 The purpose of the working conference is to promote discussion and interaction about a series of topics which are yet underrepresented. We are particularly interested in exchanging concepts, prototypes, research ideas, and other results which should not only contribute to the academic arena but will also benefit the business community. Topics of interest include but are not limited to: Maintenance and Reengineering Tools (CARE-Tools), Reverse Engineering Tools, Support of Reengineering Tasks by CASE-Tools, Software Reusability, Tele-Maintenance (Concepts, Experiences, Use of New Technologies), Maintainability of Programming Languages (eg. OOPLs), Models and Methods for Error Prediction, Measurement of Software Quality, Maintenance Metrics, Formal Methods, Reengineering and Reverse Engineering Concepts, Experiences >from Redesign and Reengineering Projects, Millennium Problem (Year 2000), Organizational Framework and Models for "RE"-Projects, Software Evolution, Migration and Maintenance Strategies, Design for Maintenance, Preventive Maintenance, Personnel Aspects of Maintenance (Motivation, Team building), Third Party Maintenance, Empirical Results about the Maintenance Situation in Businesses, Version and Configuration Management, Legal Aspects and Jurisdiction, Organization and Management of Large Maintenance Projects, Software Offloading, Related Areas such as Software Documentation Submission of papers There are two types of papers: full length papers (30 minutes presentation, not exceeding 4000 words in length and including a 150-200 word abstract) and short papers (15 minutes presentation, not exceeding 2000 words in length and including a 75-100 word abstract). Prospective authors are strongly encouraged to send a PostScript version of their paper by anonymous ftp to ftp.ifi.unizh.ch and put this file into the directory pub/CSMR97/incoming (in order to avoid overwritings, the PostScript file should be named: .ps). In addition, they should send by e-mail to CSMR97@ifi.unizh.ch the title of the paper, full names, affiliations, postal and e-mail addresses of all authors, fax and telephone numbers. Alternatively, the paper can be sent by postal mail. In that case, five copies of all the above items should be sent to the program chairman. The following signed information should be included in the submission: All necessary clearances have been obtained for the publication of this paper. If accepted, the author(s) prepare the camera-ready manuscript in time for inclusion in the proceedings, and will personally present the paper at the working conference. The proceeding will be published by IEEE Computer Society. Full papers exceeding 8 pages (short papers 4 pages) will be charged DM 100 per page in excess. Important dates The deadline for submissions is Sept. 15, 1996. Authors will be notified of acceptance by Nov.21, 1996. The camera ready version of the paper will be required by Dec. 20, 1996. Special sessions Sessions of special interest proposed by delegates will be welcome. Please send suggestions to the program chairman before the closing date of submissions. General information The working conference will take place at the Fraunhofer Institute for Software and Systems Engineering (ISST). Enquiries about the working conference arrangements should be directed to the organizing chairman or to the local chairman. For more information access the following Web pages http://rrws12.wiwi.uni-regensburg.de/~c1389/confcall.html http://www.isst.fhg.de/csmr Program Chair Lutz Richter Dept. of Computer Science University of Zurich Winterthurerstrasse 190 CH-8057 ZURICH, Switzerland Tel. +41-1-257-4330 (4331) Fax +41-1-363-0035 e-mail richter@ifi.unizh.ch Program Committee V. Ambriola, University of Pisa (I) I. Baker, IBM Europe (UK) K. Bennett, University of Durham (UK) D. Glatthaar, IBM Germany (D) J.-L. Hainaut, University of Namur (B) W. Kirchgaessner, SAP AG (D) F. Lehner, University of Regensburg (D) M. Loewe, HIF Hannover (D) P. Nesi, University of Florence (I) Z. Oery, Siemens-Nixdorf Informationssysteme AG (D) G. Sechi, IFCTR-CNR Milano (I) H. Sneed, SES Software (D) Organizing Chair Franz Lehner Institute for Business Informatics University of Regensburg Universitatsstr. 31 D-93040 REGENSBURG, Germany Tel.: +49-941-943-2734 Fax: +49-941-943-4986 e-mail: Franz.Lehner@wiwi.uni-regensburg.de Local Chair Ingo Classen Fraunhofer Institute for Software and Systems Engineering (ISST) Kurstrasse 33 D-10117 BERLIN, Germany Tel.: +49-30-20224-700 Fax: +49-30-20224-799 e-mail: Ingo.Classen@isst.fhg.de From rem-conf-request@es.net Wed Jul 10 08:53:38 1996 Received: from omnigate.clarkson.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 10 Jul 1996 05:52:47 -0700 Received: from CLVM.CLARKSON.EDU by omnigate.clarkson.edu with smtp (Smail3.1.29.1 #7) id m0udyl1-0001W9C; Wed, 10 Jul 96 08:52 EDT Message-Id: Received: from CLVM.CLARKSON.EDU by CLVM.CLARKSON.EDU (IBM VM SMTP V2R3) with BSMTP id 8938; Wed, 10 Jul 96 08:51:52 EDT Received: from CLVM (NJE origin DED@CLVM) by CLVM.CLARKSON.EDU (LMail V1.2a/1.8a) with BSMTP id 9501; Wed, 10 Jul 1996 08:51:52 -0400 Date: Wed, 10 Jul 96 08:51:14 EDT From: Dan Dullea To: rem-conf@es.net subscribe mbone-na From rem-conf-request@es.net Wed Jul 10 11:56:46 1996 Received: from www45.inria.fr by osi-west.es.net with ESnet SMTP (PP); Wed, 10 Jul 1996 08:56:10 -0700 Received: by www45.inria.fr (8.7.5/8.6.12) id RAA01715; Wed, 10 Jul 1996 17:56:06 +0200 (MET DST) Message-Id: <199607101556.RAA01715@www45.inria.fr> To: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-jpeg-03.txt In-reply-to: Your message of "Tue, 09 Jul 1996 09:49:21 EDT." <9607090949.aa11082@IETF.CNRI.Reston.VA.US> Date: Wed, 10 Jul 1996 17:56:06 +0200 From: Philipp Hoschka What happened to the draft for the MPEG payload type ? The current draft expired June 1st. Is this still being worked on, or will there be no payload type document for MPEG in RTP ?? -Philipp Hoschka, INRIA, WWW Consortium From rem-conf-request@es.net Wed Jul 10 16:32:55 1996 Received: from monet.caad.ed.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 10 Jul 1996 13:32:23 -0700 Received: from [129.215.100.202] (mac-202.caad.ed.ac.uk [129.215.100.202]) by monet.caad.ed.ac.uk (8.6.10/8.6.9) with SMTP id VAA06846; Wed, 10 Jul 1996 21:32:09 +0100 X-Sender: richard@monet.caad.ed.ac.uk Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jul 1996 21:37:03 +0100 To: tccc@cs.umass.edu, IETF@cnri.reston.va.us, fokus-user@fokus.gmd.de, giga@tele.pitt.edu, performance@haven.epm.ornl.gov, rem-conf@es.net, ccrc@dworkin.wustl.edu, cabernet-general@newcastle.ac.uk, osimcast@bbn.com, hipparch@sophia.inria.fr, multicomm@cc.bellcore.com, sigmedia@bellcore.com, alg@comm.toronto.edu, atm@bbn.com, cost237-transport@comp.lancs.ac.uk, xtp-relay@cs.concordia.ca, reres@laas.fr, enternet@bbn.com, isadsoc@fokus.gmd.de, richard@caad.ed.ac.uk From: richard@caad.ed.ac.uk (Richard Coyne) Subject: EuropIA'97 Call for Papers please distribute if of interest ----------------------- CONFERENCE ANNOUNCEMENT & CALL FOR PAPERS ----------------------- europia`97 @EDINBURGH =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D DESIGN and the NET =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Sixth International Conference on the Application/Implications of Computer Networking in Architecture, Construction, Design, Civil Engineering and Urban Planning Sixi=E8me Conf=E9rence Internationale sur les applications/implications des nouvelles technologies de communication en Architecture, Construction, Design, Ing=E9nierie et Planification urbaine 2-3 April 1997 Department of Architecture University of Edinburgh Edinburgh EH1 1JZ Scotland http://www.caad.ed.ac.uk/europia/ This conference brings together researchers in design, architecture, engineering, construction management, cognitive science, computer science, artificial intelligence, sociology, geography and education as well as industry partners, practitioners and other users of networked communications. The focus for this diverse group is design - how we design with and for networked communications - appropriating recent exciting developments in medium and broad band local area and wide area networks, new protocols for interaction and new communications tools such as Web browsers and network aware multimedia tools. Topics covered include: design and ... World Wide Web applications Distributed design decision support Collaborative systems Information and communication spaces Distributed interactive multimedia Virtual reality on the net Java applications Architecture of cyberspace Role of the Internet in industry and in practice Intranets Networked digital video Desktop video conferencing Computer supported collaborative work Virtual studios Virtual offices Spatial and social implications of networked communications Distributed Geographical Information Systems / Urban Information Systems Distributed facilities management Design of networked multimedia Cette conf=E9rence vise la rencontre des communaut=E9s industrielles et de l= a recherche scientifique (=E9ducation, informatique, science cognitive, sociologie, ...) impliqu=E9es dans une probl=E9matique favorisant ou d=E9favorisant l'usage des nouvelles technologies de communications en Architecture, Construction, Design, Ing=E9nierie et Planification urbaine. Par le biais de cette rencontre, nous souhaitons solliciter et d=E9velopper diverses approches conceptuelles et exp=E9rimentales relevant de cette probl=E9matique et traitant plus particuli=E8rement l'=E9mergence de nouveau= x protocoles d'interaction et de communications par les outils de multim=E9dia et la mise en place des autoroutes de l'informations (WWW). Th=E8mes abord= =E9s Toute contribution relative =E0 la conception et =E0 la communication tell= e que les: Applications de World Wide Web Applications de JAVA Architecture de cyberspace Ateliers Virtuels Bureaux d'=C9tudes virtuels Conception des r=E9seaux multim=E9dia Implications sociales et spatiales des nouveaux r=E9seaux de communication= s MultiMedia Interactive R=E9alit=E9 Virtuel. R=F4le d'Internet dans la vie professionnelle Intranets R=E9seaux de vid=E9o num=E9rique Syst=E8mes Distribu=E9s d'aide =E0 la D=E9cision Syst=E8mes de Conception Collaborative Syst=E8mes d'Information G=E9ographique Syst=E8me d'Information Urbaine T=E9l=E9conf=E9rences DATES Papers due in electronic form 11 December 1996 Notification of acceptance 7 February 1997 Final paper in electronic form 28 February 1997 Final date for registration 14 March 1997 Conference 2-3 April 1997 REGISTRATION FEE Authors 175 pounds stirling Non-authors 250 pounds stirling Conference Dinner 27 pounds stirling VENUE UnivEd Training and Conference Centre 11 South College Street Edinburgh EH8 9AA ORGANISING COMMITTEE Richard Coyne University of Edinburgh richard@caad.ed.ac.uk John Lee University of Edinburgh john@caad.ed.ac.uk Alan Bridges University of Strathclyde a.h.bridges@strath.ac.uk Linda Candy University of Loughborough L.Candy@lut.ac.uk Reza Beheshti Delft University of Technology R.Beheshti@CT.TUDelft.nl Khaldoun Zreik University of Caen zreik@univ-caen.fr ADVISORY BOARD Richard Buchanan, Carnegie Mellon University, USA Ernesto Costa, Universidade de Coimbra, Portugal Ernest Edmonds, Loughborough University, England Niklaus Kohler, University of Karlsruhe, Germany John Lansdown, University of Middlesex, England Marcel Miramond, INSA Lyon, France Sidney Newton, University of Western Sydney, Australia James Rutherford, University of Sydney, Australia Gerhard Schmitt, ETH Z=8Drich, Switzerland Keith Stenning, University of Edinburgh, Scotland Peter Szalapaj, University of Sheffield, England David Week, Pacific Architecture, Australia Robert Woodbury, University of Adelaide, Australia SEND TECHNICAL QUERIES TO Richard Coyne Tel: +44 131 650 2332 Department of Architecture Fax: +44 131 650 8019 University of Edinburgh richard@caad.ed.ac.uk 20 Chambers Street EH1 1JZ Scotland http://www.caad.ed.ac.uk/~richard/ SEND QUEURIES ABOUT REGISTRATION AND ACCOMMODATION TO Peter Niven Conference Manager Peter.Niven@ed.ac.uk UnivEd Technologies Limited 11 South College Street, Edinburgh, EH8 9AA Ph +44 131 650 9020 Fax +44 131 650 9019 REGISTRATION OF INTEREST send to Peter.Niven@ed.ac.uk Title: Mr/Mrs/Ms/Dr/Prof Name -------------------------------------------------------------- Organisation -------------------------------------------------------------- Address -------------------------------------------------------------- Tel Fax ------------------------------ ----------------------------- Email -------------------------------------------------------------- I wish to attend EuropIA'97 Design and the Net on YES/NO 2-3 April 1997 at the University of Edinburgh I intend to submit a paper YES/NO Title/Topic of paper -------------------------------------------------------------- -------------------------------------------------------------- Please send me information on accommodation in Edinburgh YES/NO - Richard --------------------------------------------------------------------------- Richard Coyne Tel: +44 131 650 2332 Department of Architecture Fax: +44 131 650 8019 University of Edinburgh richard@caad.ed.ac.uk 20 Chambers Street EH1 1JZ Scotland http://www.caad.ed.ac.uk/~richard/ From rem-conf-request@es.net Wed Jul 10 20:51:38 1996 Received: from ormail.intel.com by osi-east.es.net with ESnet SMTP (PP); Wed, 10 Jul 1996 17:51:04 -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 RAA15430; Wed, 10 Jul 1996 17:51:01 -0700 (PDT) Received: by ibeam.intel.com (Smail3.1.28.1 #6) id m0ue9xL-000RTGC; Wed, 10 Jul 96 17:50 PDT Message-Id: To: Stephen Casner Cc: rem-conf@osi-east.es.net, mojy@ibeam.jf.intel.com, Ken_K_Mills@ccm.jf.intel.com, Christian_Maciocco@ccm.jf.intel.com, Hariharan_Kumar@ccm.jf.intel.com, Jeff_Kidder@ccm.jf.intel.com, Michael_Deisher@ccm.jf.intel.com Subject: Re: RTP Payload Format for G.723 In-reply-to: Your message of Wed, 03 Jul 96 00:26:07 -0700. Date: Wed, 10 Jul 96 17:49:52 PDT From: Linda Cline >> From the RTP spec, we have been working under the impression that >> the marker bit is to be specified by the payload format, for things such as >> marking the last packet for a video frame. > >No. The RTP spec allows a Profile to define the marker bit. Since an >application is likely to work with multiple payload formats within one >profile, changing the definition of the marker bit from one payload >format to another would make the application more difficult to >implement. Within the profile, the meaning of the marker bit is >defined independently for audio and for video. Thanks for clarifying that. Note that the H.261, JPEG and H.263 payload format specs do define the use of the marker bit. However, I see the concern when one payload spec deviates from a default definition in the profile. >> There is also the recommendation >> in the profile spec to use the marker bit in audio for the first packet in >> a talkspurt, which is entirely optional. > >Please point out where the optional notion came from. This comes from our impression (that you dispelled above) that the payload format specs can define the use of the marker bit, along with the fact that the mention of the marker bit in the profile document is labeled a recommendation rather than a requirement. What you are saying, then, is that setting the marker bit to indicate a talkspurt is recommended (not necessarily required), but that use of the marker bit differently for that class of encoding is not allowed. >> An alternative to this would be to use >> a separate payload type for the normal and alternate modes, but this would >> preclude the option of mixing the modes in a stream. > >Not true. One can change payload types during the course of a stream, >including switching among static and dynamic payload types. This impression was from the following in the profile spec: "An RTP source emits a single RTP payload type at any given time; the interleaving of several RTP payload types in a single RTP session is not allowed, but multiple RTP sessions may be used in parallel to send multiple media." This excerpt must then be referring to multiple media types rather than multiple payload types. There is the section 5.2 in the RTP spec which implies that payload types can be switched during a session, also. Is this clarified elsewhere? In any case, since payload types can be changed midstream, there is no need to overload the definition of the marker bit. >I have another question not raised earlier. The reason I have been >anxiously awaiting the G.723 payload format spec was that H.225.0 >said, "For audio algorithms such as G.723 which use more than one size >of audio frame, audio frame boundaries within each packet shall be >signaled in-band to the audio channel." That's what I expected the >payload format to define, but if I read it correctly, it just says you >can mix together whatever combination of audio frames you like. >Please explain this apparent difference. In G.723.1, the audio frame boundaries are easily determined from the first two bits of the frame data itself. This should be described in the G.723.1 payload spec draft. There didn't seem to be a need to replicate this information elsewhere in the stream, or to constrain the mix of audio frames. These bits can also be used to detect silence frames so that a general silence packet scheme could be used, also without requiring additional information. This can be described in the draft as well, but a G.723.1 specific silence scheme did not seem to be warranted. Senders should be able to send or not send silence; receivers should be able to handle either. It seems that if a general scheme needed to be defined, it might belong in the profile. We are looking at general interleaving formats. To be feasible for G.723.1 with its small frames, an interleaved data format would have to be low overhead; otherwise it has few advantages over redundant data and would leave low data rate applications without a packet loss resiliency option. This would be unfortunate, as the error concealment scheme defined in the G.723.1 ITU recommendation is especially suited for a frame interleaving format. Any pointers to relevant work on interleaved data would be appreciated. We will remove the replicated data option from the draft, as the general redundant payload format should be sufficient for that option. Van mentioned a concern about the 30ms frame size as opposed to 20ms for other encodings. It should be noted in the draft that the packetization interval for G.723.1 is one frame, 30ms. From rem-conf-request@es.net Thu Jul 11 02:35:33 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 10 Jul 1996 23:35:04 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA07114; Wed, 10 Jul 1996 23:34:56 -0700 Date: Wed, 10 Jul 1996 23:34:56 -0700 (PDT) From: Stephen Casner To: Philipp Hoschka Cc: rem-conf@es.net Subject: Re: I-D ACTION:draft-ietf-avt-jpeg-03.txt In-Reply-To: <199607101556.RAA01715@www45.inria.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Philipp, > What happened to the draft for the MPEG payload type ? You probably noticed the recent re-posting of the H.261, JPEG and CellB drafts to incorporate comments received during Last Call. The only reason the MPEG draft was not included with them was because there were no edits to be made for that one, unlike the others. > The current draft expired June 1st. Don't worry, drafts that are in Last Call don't expire. > Is this still being worked on, or will there be no payload type > document for MPEG in RTP ?? As I mentioned in the AVT meeting in Montreal, all four video payload format drafts have been approved by the IESG for publication as proposed standard RFCs. We should be seeing the "protocol action" message on this any day now. -- Steve From rem-conf-request@es.net Thu Jul 11 18:11:15 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 11 Jul 1996 15:10:46 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA09344; Thu, 11 Jul 1996 15:10:45 -0700 Date: Thu, 11 Jul 1996 15:10:44 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Multicast of "World Wide Live" event Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Microsoft is presenting "World Wide Live", an event for website creators, designers and managers in which web experts will explain how to use Microsoft's web client/server technology. For more details, see http://www.microsoft.com/wwlive/ The main distribution channel for this event is satellite broadcast to movie theaters around the US and Canada, but it will be simultaneously multicast over the MBONE with help from Precept Software. Video will be H261, and audio will be DVI, both to be delivered using RTPv2 with Precept's IP/TV server software. Program Name: WWLive (Microsoft Multicast) Start Date & Time: Jul/16/96 - 08:00 PST (16:00 GMT) Length: 9 Hours The program will be rebroadcast later via satellite and MBONE for the European audience: Program Name: WWLive (European Re-broadcast) Start Date & Time: Jul/17/96 - 08:00 GMT Length: 9 Hours You can tune in to this MBONE event two ways. The event is being advertised with Precept's IP/TV Program Guide, which sends out an sdr-compatible session advertisement to be received by sdr or a local Program Guide server. Those who want to use Precept's viewer software for MS Windows but are not running a local Program Guide may access the one at www.precept.com (this is set by default for the downloaded viewer). Also located on that web site are details on downloading the viewer. From rem-conf-request@es.net Thu Jul 11 23:43:54 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 11 Jul 1996 20:43:23 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA10646; Thu, 11 Jul 1996 20:39:29 -0700 Date: Thu, 11 Jul 1996 20:39:28 -0700 (PDT) From: Stephen Casner To: Linda Cline Cc: rem-conf@osi-east.es.net, mojy@ibeam.jf.intel.com, Ken_K_Mills@ccm.jf.intel.com, Christian_Maciocco@ccm.jf.intel.com, Hariharan_Kumar@ccm.jf.intel.com, Jeff_Kidder@ccm.jf.intel.com, Michael_Deisher@ccm.jf.intel.com Subject: Re: RTP Payload Format for G.723 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Note that the H.261, JPEG and H.263 > payload format specs do define the use of the marker bit. Yes, but they are simply restating the function of the bit as in the profile. In the MPEG spec, there is a difference in the definition of the marker bit for the case of MPEG transport streams, but that is a new beast which is neither audio nor video. Perhaps the profile needs to say more about this. > ... the mention of the marker bit in the profile document is labeled > a recommendation rather than a requirement. Perhaps we should reconsider our use of the word "recommendation" in the heading of section 4.1 in the profile, and/or be more specific about must/should/may for the topics in that section. > What you are saying, then, is > that setting the marker bit to indicate a talkspurt is recommended (not > necessarily required), Well, I didn't really mean to say that. If you don't ever set the marker bit, the receiver should be robust enough to still work, even if there are silence periods. The receiver may not work as well, though, or it may need to infer the start of a talkspurt by noticing when the sequence number is contiguous but the timestamp changes by more than a packets worth of data. To do this, the program needs to know how much time the previous packet occupied; the audio decoder should know this, but the RTP packet processing code might not. > but that use of the marker bit differently for that > class of encoding is not allowed. Yes, the alternate meaning you proposed would cause some real complications for the implementations, I believe. > This impression was from the following in the profile spec: > > "An RTP source emits a single RTP payload type at any given time; the > interleaving of several RTP payload types in a single RTP session is > not allowed, but multiple RTP sessions may be used in parallel to > send multiple media." > > This excerpt must then be referring to multiple media types rather > than multiple payload types. Thanks for pointing out this wording which is not clear enough. Indeed, the intention here was to disallow the interleaving of different media in one RTP session. This sentence is about the behaviour of an "RTP source", i.e., one SSRC being sent in a particular RTP session. Even sending two stream of audio and interleaving their packets, whether the payload type happens to be the same or different, will cause problems with interpreting the sequence numbers and timestamps. That's what this sentence was about: the payload type field should not be used for multiplexing. > In G.723.1, the audio frame boundaries are easily determined from > the first two bits of the frame data itself. This should be described in > the G.723.1 payload spec draft. I didn't know this (the sentence in H.225.0 made me think otherwise); stating this in the payload format spec would be good (and I don't see a problem with stating something that is already stated in the G.723.1 spec itself). > There didn't seem to be a need to replicate > this information elsewhere in the stream, or to constrain the mix of audio > frames. I agree. > These bits can also be used to detect silence frames so that a > general silence packet scheme could be used, also without requiring > additional information. This can be described in the draft as well, > but a G.723.1 specific silence scheme did not seem to be warranted. > Senders should be able to send or not send silence; receivers should > be able to handle either. Please do add this to the draft. Is there any reason to send the silence? (Does it contain any information?) > Any pointers to relevant work on interleaved data would be > appreciated. The work I've learned about was presented in the series of "International Workshops on Packet Video" also called VISICOM, starting in 1988 or so, since I happened to attend a few of those. But the proceedings of these were not published in a widely accessible form. Perhaps other readers of this list can give you some better references. > We will remove the replicated data option from the draft, as the > general redundant payload format should be sufficient for that option. Good. -- Steve From rem-conf-request@es.net Fri Jul 12 02:54:48 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 11 Jul 1996 23:54:20 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA11029; Thu, 11 Jul 1996 23:54:08 -0700 Date: Thu, 11 Jul 1996 23:54:07 -0700 (PDT) From: Stephen Casner To: Mikael Degermark Cc: rem-conf@es.net Subject: Re: Global vs. per-stream sequence numbers In-Reply-To: <1.5.4.32.19960708202346.0066b2d8@my28.sm.luth.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mikael, You've given a good summary of the global/per-stream sequence number tradeoff. I think there is consensus for the per-stream sequence numbers and no context-id compression. I like your optimization of invalidating the likely stream (or few streams) when an error is detected by the modem and before waiting to detect the sequence number gap. This optimization is appealing in that it can be applied locally. -- Steve From rem-conf-request@es.net Fri Jul 12 04:02:32 1996 Received: from trystero.media.org by osi-west.es.net with ESnet SMTP (PP); Fri, 12 Jul 1996 01:01:53 -0700 Received: (carl@localhost) by trystero.media.org (8.7.5/960629.01bjb) id EAA29060; Fri, 12 Jul 1996 04:01:49 -0400 (EDT) From: "Carl Malamud [IMS]" Message-Id: <199607120801.EAA29060@trystero.media.org> Subject: Multicast of the Brain Opera To: rem-conf@es.net Date: Fri, 12 Jul 1996 04:01:49 -0400 (EDT) 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 The MIT Media Lab and Composer Tod Machover will be multicasting live from Lincoln Center from July 24-August 3. The Brain Opera, based on the works of Marvin Minsky, is a featured event of the Lincoln Center Festival. To support the multicast, MCI, Bay Networks, and Nynex have run a DS3 line from the Lincoln Center into the Expo 96 router at MAE-East. You can find more information on the Brain Opera at: http://brainop.media.mit.edu/ Exact details on performance times (8 per day) will be available on the web and via SDR after we setup onsite. This multicast takes full advantage of "client-server technology" and all other applicable current buzzwords. While we won't have Bill(tm) or Jim(tm) or other trendy multicast technologies, we hope you'll enjoy a bit of music with us. Carl Malamud MIT Media Lab From rem-conf-request@es.net Fri Jul 12 04:04:16 1996 Received: from tide19.microsoft.com by osi-east.es.net with ESnet SMTP (PP); Fri, 12 Jul 1996 01:03:31 -0700 Received: by tide19.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.985.1) id <01BB6F8D.F02EC750@tide19.microsoft.com>; Fri, 12 Jul 1996 01:03:29 -0700 Message-ID: From: Thomas Pfenning To: "'rem-conf@osi-east.es.net'" Subject: Port ranges assigned to Video and Audio Date: Fri, 12 Jul 1996 01:03:22 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.985.1 Encoding: 7 TEXT I recall a short conversation on part ranges assigned to video and audio streams but I did not save the messages. Could some helpful soul send me her/his copies of these mails. Thanks Thomas From rem-conf-request@es.net Fri Jul 12 08:51:00 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Fri, 12 Jul 1996 05:50:25 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 12 Jul 1996 13:47:56 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Thomas Pfenning cc: "'rem-conf@osi-east.es.net'" Subject: Re: Port ranges assigned to Video and Audio In-reply-to: Your message of "Fri, 12 Jul 96 01:03:22 PDT." Date: Fri, 12 Jul 96 13:47:56 +0100 Message-ID: <19388.837175676@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >I recall a short conversation on part ranges assigned to video and audio >streams but I did not save the messages. Could some helpful soul send me >her/his copies of these mails. >From the mrouted README: o the packet classifier in the kernel now uses the following udp port ranges: [0, 16384) - lowest priority, unclassified [16384, 32768) - highest priority, i.e. audio [32768, 49152) - medium priority, i.e. whiteboard [49152, 65536) - low priority, i.e. video A future release of a session directory will allocate ports in these ranges. sdr has allocated in these ranges since version 2.1a1 in November 95. Note: the port ranges in question do not make any difference unless the traffic traverses an interface or tunnel where the multicast traffic rate exceeds the configured mrouted rate-limiter. Mark From rem-conf-request@es.net Fri Jul 12 08:54:27 1996 Received: from dip.eecs.umich.edu by osi-east.es.net with ESnet SMTP (PP); Fri, 12 Jul 1996 05:53:49 -0700 Received: (from thalerd@localhost) by dip.eecs.umich.edu (8.7.5/8.7.3) id IAA25765; Fri, 12 Jul 1996 08:55:10 -0400 (EDT) From: Dave Thaler Message-Id: <199607121255.IAA25765@dip.eecs.umich.edu> Subject: Re: Port ranges assigned to Video and Audio To: thomaspf@microsoft.com (Thomas Pfenning) Date: Fri, 12 Jul 1996 08:55:10 -0400 (EDT) Cc: rem-conf@osi-east.es.net In-Reply-To: from "Thomas Pfenning" at Jul 12, 96 01:03:22 am X-Mailer: ELM [version 2.4 PL24 PGP1] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I recall a short conversation on part ranges assigned to video and audio > streams but I did not save the messages. Could some helpful soul send me > her/his copies of these mails. >From the multicast 3.5 kernel sources: /* * The UDP port space is divided up into four priority ranges: * [0, 16384) : unclassified - lowest priority * [16384, 32768) : audio - highest priority * [32768, 49152) : whiteboard - medium priority * [49152, 65536) : video - low priority */ -Dave From rem-conf-request@es.net Fri Jul 12 10:55:32 1996 Received: from hpserv0.cs.uit.no by osi-west.es.net with ESnet SMTP (PP); Fri, 12 Jul 1996 07:54:52 -0700 Received: from lgserv1.cs.uit.no by hpserv0.cs.uit.no with ESMTP (1.37.109.16/IOH-1.0) id AA230823289; Fri, 12 Jul 1996 16:54:49 +0200 Received: (from frodef@localhost) by lgserv1.cs.uit.no (8.7.5/8.7.3) id QAA20035; Fri, 12 Jul 1996 16:54:48 +0200 (METDST) Date: Fri, 12 Jul 1996 16:54:48 +0200 (METDST) From: Frode Vatvedt Fjeld Message-Id: <199607121454.QAA20035@lgserv1.cs.uit.no> To: rem-conf@es.net Subject: vic & linux trouble I'm running vic on a linux-box, and have a problem with linux dropping incoming packets. The datarate is not very large (aproximately 60kpbs, 7-8 packets/second, each carried in a single IP fragment), and top reports the cpu is 80% idle. I can't see any reason why packets should be dropped, yet about 3-5% of them are. Has anyone else experienced similar things with linux? Also, could someone please point me to a charter for this list? Thanks, - -- Frode Vatvedt Fjeld e-mail..: frodef@stud.cs.uit.no WWW.....: http://www.cs.uit.no/~frodef/ From rem-conf-request@es.net Fri Jul 12 19:59:44 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 12 Jul 1996 16:59:13 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA15142; Fri, 12 Jul 1996 16:59:10 -0700 Date: Fri, 12 Jul 1996 16:59:09 -0700 (PDT) From: Stephen Casner To: Steve Deering Cc: rem-conf@es.net Subject: Re: Multicast of "World Wide Live" event In-Reply-To: <96Jul12.142618pdt."75270"@digit.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Steve, > It wasn't clear to me from your message whether or not this event will be > viewable and audible by vic and vat. Will it? Yes, sorry my message was unclear on that. You should be able to see the session description for "WWLive" in sdr now, and if you tune in >from sdr using vat and vic you should be able to receive the RTPv2-based DVI audio and H.261 video (once transmission starts). You may notice vic telling to you upgrade to vic 2.8, which isn't available yet; that's because Precept's software transmits H.261 RTP payload format headers according to the spec as vic 2.8 will do when it is released, whereas vic 2.7 sends the headers with a couple of fields swapped. vic 2.7a32 and newer versions are capable of receiving the headers in either form, as is Precept's viewer. Versions of vic older than 2.7a32 may crash on this video. I should also take this opportunity to mention that the event includes other vendors and web experts outside of Microsoft -- see the web page for information. -- Steve From rem-conf-request@es.net Sat Jul 13 13:03:31 1996 Received: from sirius.ctr.columbia.edu by osi-west.es.net with ESnet SMTP (PP); Sat, 13 Jul 1996 10:02:56 -0700 Received: from yosemite.ctr.columbia.edu (campbell@yosemite.ctr.columbia.edu [128.59.68.25]) by sirius.ctr.columbia.edu (8.7.5/8.6.4.287) with ESMTP id NAA26845; Sat, 13 Jul 1996 13:02:52 -0400 (EDT) From: campbell@ctr.columbia.edu (Andrew T. Campbell) Received: (campbell@localhost) by yosemite.ctr.columbia.edu (8.7.5/8.6.4.788743) id NAA04610; Sat, 13 Jul 1996 13:02:50 -0400 (EDT) Message-Id: <199607131702.NAA04610@yosemite.ctr.columbia.edu> Subject: CFP: IFIP 5th International Workshop on QoS (IWQoS'97) To: rem-conf@es.net Date: Sat, 13 Jul 1996 13:02:49 -0400 (EDT) Cc: campbell@ctr.columbia.edu (Andrew T. Campbell) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Apologies for duplicates. ---------------------------------------------------------------------------- CALL FOR PAPERS IFIP Fifth International Workshop on Quality of Service (IWQoS '97) -Building QoS into Distributed Systems- http://www.ctr.columbia.edu/iwqos/ May 22-24, 1997 Center for Telecommunications Research, Columbia University, New York, USA Sponsored by IFIP* WG6.1 Technical co-sponsorship by the IEEE* Communications Society Technical Committee on Multimedia Communications Corporate sponsorship by IBM, HP and Lucent Technologies In co-operation with the IFIP Joint International Conference on Open Distributed Processing and Distributed Platforms * to be approved ---------------------------------------------------------------------------- SCOPE This is the fifth in a series of workshops aimed at providing an international forum for the exchange of information on quality of service (QoS) research in distributed systems. The objective of the Fifth International Workshop on Quality of Service is to bring together researchers, developers, and practitioners working in all facets of QoS research addressing multimedia applications and services, programmability, operating systems, communications, multimedia devices and middleware. Contributions are solicited in all areas of QoS research in distributed systems, including, but not limited to: * Human Perception and Dynamic * QoS and the WWW, MBone and QoS Internet * QoS Programmability, Languages * QoS Issues in Storage and Formal Method Techniques Systems/Databases * Multimedia Tools, Protocols and * QoS and Operating Networking System/Micro-kernels * QoS Guarantees in an Integrated * QoS Architectures Services Internet * Media Scaling and QoS Filtering * QoS-based APIs for Techniques Applications, Transport and * QoS and Mobility in Wireless Management Networks * Audio and Video * QoS Translation, Negotiation, Coding/Compression Techniques Monitoring and Maintenance and QoS * QoS in Standards * QoS Modeling, Analysis and * QoS in MIBs for Network Evaluation Management * Adaptive Applications and * Experimental Studies on QoS Services * Middleware Solutions for End-to-End QoS In the past the workshop has been cross-disciplinary, small and well focused, consisting of keynote speakers, invited papers and solicited contributions. As a result, a considerable amount of time is devoted to informal discussion. The Fifth International Workshop on Quality of Service will be limited to 80 participants. ---------------------------------------------------------------------------- SUBMISSIONS Authors are invited to submit full papers and position statements for review. Full papers should not exceed 12 single-spaced pages including figures, tables, and references, using a typeface no smaller than 12 points. Position statements should not exceed 3 single-spaced pages. To expedite the reviewing process, please submit the paper electronically (in postscript format, through e-mail) to workshop@ctr.columbia.edu. All submissions must include name and affiliation of the authors, a contact address of the main author, an abstract, and keywords. In the case where electronic submission is impossible please send 4 copies to the correspondence address below. ---------------------------------------------------------------------------- PUBLICATION Papers will be published as proceedings by Chapman & Hall. ---------------------------------------------------------------------------- IMPORTANT DATES: Today: Send a message stating your intention to submit a paper or stating your general interest in the workshop to workshop@ctr.columbia.edu Submission of contribution: March 18, 1997 Notification of acceptance: April 24, 1997 Camera-ready paper for participants proceedings due: May 1, 1997 ---------------------------------------------------------------------------- WORKSHOP ORGANIZATION Program Co-Chairs: * Andrew T. Campbell, Columbia University, USA. * Klara Nahrstedt, University of Illinois at Urbana Champaign, USA Program Committee: * Steve McCanne, Lawrence Berkeley * Gordon Blair, University of National Laboratories, USA Lancaster, UK * Mahmoud Nagshineh, IBM Thomas J. * Simon Crosby, Cambridge Watson Research Center, USA University, UK * Elie Najm, Ecole Nationale * Jon Crowcroft, UCL, UK Superieure des Telecommunications, * Hermann de Meer, University France of Hamburg, Germany * Max Ott, C&C Research, NEC USA * Jan de Meer, GMD Fokus, * Guru Parulkar, Washington Germany University * Alexandros Eleftheriadis, * Jerry Rolia, Carleton University, Columbia University, USA Canada * Richard Friedrich, * Cormac Sreenan, Lucent Technologies Hewlett-Packard Company, USA Bell Labs, USA * Michael Fry, University of * Chris Sluman, OpenIT Ltd, UK, Technology, Australia * Hideyuki Tokuda, Keio University, * Andrew Herbert, APM Ltd., UK Japan * Jean-Peirre Hubaux, EPFL, * James VanLoo, Sun Microsystems USA Switzerland * Andreas Vogel, DSTC, Australia * Kevin Jeffay, University of * Andrew Watson, OMG, USA North Carolina at Chapel * Hartmut Wittig, Multimedia Software, Hill, USA Germany * Brigitte Kerherve, Universite * Lixia Zhang, University of du Quebec a Montreal, Canada California, Los Angeles, USA * S. Keshav, ATT Research, USA * Hui Zhang, Carnegie Mellon * Glenford Mapp, Olivetti University, USA Research Ltd, UK * Martina Zitterbart, TU Braunschweig, Germany Local Organization Committee: * Cormac Sreenan, Lucent Technologies Bell Labs, USA * Koon-Seng Lim, Columbia University, USA * Alexandros Eleftheriadis, Columbia University, USA * Cristina Aurrecoechea, Columbia University, USA ---------------------------------------------------------------------------- HISTORY The Fifth International Workshop on Quality of Service is part of a continuing series: The first workshop, held in May 1994 in Montreal, Canada, was supported by the European RACE project `QoS TOPIC' and the Canadian CITR project `Broadband Services'. The second workshop was organized within the European RACE Conference on Integrated Services and Networks (IS&N) and took place in September 1994 in Aachen, Germany. The third workshop was held in February 1995 in Brisbane, Australia, in conjunction with the International IFIP Conference on Open Distributed Processing. The last workshop was held in March 1996 in Paris, France, in conjunction with the IFIP/IEEE International Conference on Distributed Platforms and IFIP International Workshop on Formal Methods for Open Object-based Distributed Systems. ---------------------------------------------------------------------------- LOCATION The workshop will be held at the Schapiro Research Building, Columbia University, Manhattan in the City of New York. A variety of hotels options will be available to the participants. Internet access will be provided. ---------------------------------------------------------------------------- RELATED EVENTS The Fifth International Workshop on Quality of Service will be held immediately before the Joint IFIP International Conference on Open Distributed Processing (ICODP) and Distributed Platforms (ICDP) , Toronto, Canada, May 26-30, 1997. ---------------------------------------------------------------------------- CORRESPONDENCE ADDRESS Please notify us of your interest in the workshop by contacting the workshop co-chairs, either electronically (workshop@ctr.columbia.edu) or by mailing to the address below: Prof. Andrew T. Campbell Center for Telecommunications Research Columbia University Room 801 Schapiro Research Building 530 West 120th Street New York, N.Y., 10027-6699 USA email: campbell@ctr.columbia.edu w3: http://www.ctr.columbia.edu/~campbell/ voice: (212) 854-3109 fax: (212) 316-9068 ---------------------------------------------------------------------------- From rem-conf-request@es.net Sun Jul 14 07:21:20 1996 Received: from VNET.IBM.COM by osi-east.es.net with ESnet SMTP (PP); Sun, 14 Jul 1996 04:20:43 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7367; Sun, 14 Jul 96 07:20:43 EDT Date: Sun, 14 Jul 96 11:15:15 IST From: Scott Petrack To: rem-conf@osi-east.es.net Subject: "at any one time" and "media types" - clarification needed > This impression was from the following in the profile spec: > >> "An RTP source emits a single RTP payload type at any given time; the >> interleaving of several RTP payload types in a single RTP session is >> not allowed, but multiple RTP sessions may be used in parallel to >> send multiple media." > > This excerpt must then be referring to multiple media types rather > than multiple payload types. > Thanks for pointing out this wording which is not clear enough. > Indeed, the intention here was to disallow the interleaving of > different media in one RTP session. Steve, by "media" in your sentence did you mean the same thing as "media type" in Linda's sentence? And am I right to think that "media type" just means one of the set {audio, video}? I am still confused about this whole issue - could I ask for a clarification please? Line 426 of rfc 1889 says: >A synchronization source >may change its data format, e.g., audio encoding, over time. Is it correct to state that: A. a single SSRC is *allowed* to send one audio payload format "for a while," and then to change and send a different audio payload format -- this is "changing its data format." B. a single SSRC is *NOT allowed* to change the audio payload format "too often" (like each frame) -- this is interleaving or multiplexing. C. a single SSRC is *not allowed* to change from an audio payload format to a video payload format within the same RTP session ever. This is what I understand from the RFC and from the current discussion about interleaving not being allowed. Is there some definition of the time threshold is -- i.e. how much time must elapse once a payload type begins before it can be changed? Or are we just expected to be "reasonable." Sorry to be slow, and thanks in advance, Scott From rem-conf-request@es.net Mon Jul 15 02:55:25 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Sun, 14 Jul 1996 23:54:54 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA19558; Sun, 14 Jul 1996 23:54:44 -0700 Date: Sun, 14 Jul 1996 23:54:43 -0700 (PDT) From: Stephen Casner To: Scott Petrack Cc: rem-conf@osi-east.es.net Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: <9607141205.AA17892@precept.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Scott, > Steve, by "media" in your sentence did you mean the same thing as > "media type" in Linda's sentence? Yes. > And am I right to think that "media > type" just means one of the set {audio, video}? Well, yes, for the current well-known applications using RTP. But that would be too narrow a view for the long term. The basic idea is to not try to mix things that don't mix. > I am still confused about this whole issue - could I ask for a > clarification please? I think section 5.2 in the RTP spec (RFC 1889) gives a pretty good explanation of why one should not try to use the payload type field to multiplex RTP streams. (If not, please point out any deficiencies.) And even if the two streams of different media types were being transmitted from completely separate hosts rather than being interleaved by one host, it still would not make sense to send them to the same RTP session (e.g., same multicast address and port). The receiver would likely have trouble processing the streams together if one contained video and the other contained audio. The receiver is likely to be set up for one of audio or video on that RTP session, and would likely discard packets for the other medium because the payload type would not be in the allowed set. > Line 426 of rfc 1889 says: > >A synchronization source > >may change its data format, e.g., audio encoding, over time. > > Is it correct to state that: > > A. a single SSRC is *allowed* to send one audio > payload format "for a while," and then to change and send a different > audio payload format -- this is "changing its data format." Yes. > B. a single SSRC is *NOT allowed* to change the audio payload format > "too often" (like each frame) -- this is interleaving or multiplexing. No. If an application wanted to an 8kHz audio signal with the first 20ms encoded as mu-law PCM and the next 20ms encoded as GSM and alternating every 20ms thereafter, that should work. It might be unwise because the variation in sound quality would probably be annoying and the GSM encoder or decoder might get confused if not processing the signal continuously, but the processing of the stream is straighforward. On the other hand, if a source sent 20ms of 44.1 kHz audio then 20ms of 32 kHz audio, that might well cause troule for the receiver because there might be a time delay and audible glitch resulting from changing the sampling rate on the audio device. This would be within the spec but "unreasonable". However, sending the first 33ms of audio in the first packet and then the first frame of video in the second packet of the same stream would be interleaving/multiplexing and "not allowed". > C. a single SSRC is *not allowed* to change from an audio payload > format to a video payload format within the same RTP session ever. Right. > This is what I understand from the RFC and from the current > discussion about interleaving not being allowed. Is there some > definition of the time threshold is -- i.e. how much time must elapse > once a payload type begins before it can be changed? Or are we just > expected to be "reasonable." There is no definition of the time threshold. Some reasonableness examples were given above. -- Steve From rem-conf-request@es.net Mon Jul 15 07:37:41 1996 Received: from IETF.cnri.reston.VA.US by osi-west.es.net with ESnet SMTP (PP); Mon, 15 Jul 1996 04:37:09 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa09029; 15 Jul 96 7:31 EDT To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: RTP Payload Format to Proposed Standard Date: Mon, 15 Jul 96 07:31:14 -0400 Sender: scoya@CNRI.Reston.VA.US Message-ID: <9607150731.aa09029@IETF.CNRI.Reston.VA.US> The IESG has approved the following Internet-Drafts as Proposed Standards: 1. RTP Payload Format of Sun Microsystems CellB Video Encoding 2. RTP Payload Format for H.261 video streams 3. RTP Payload Format for JPEG-compressed Video 4. RTP Payload Format for MPEG1/MPEG2 Video These documents are the product of the Audio/Video Transport Working Group. The IESG contact person is Allison Mankin. Technical Summary These specifications describe the packetizing and formatting of widely used video encodings, in a standard fashion, for use in payloads of the Proposed Standard Real-time Transport Protocol (RTP, RFC 1889-1890). RFC 1890 describes the method of registering new payload types for RTP with the Internet Assigned Numbers Authority. Working Group Summary The AVT Working Group reached strong consensus on these specifications. In addition, they have the consensus of active video protocol standards work outside of the IETF. Protocol Quality Review of the specs was by Allison Mankin, Transport Area Director, by members of the Transport Directorate, and by members of the ITU video standards committees. There are fielded implementations of the first four payloads, and prototypes of MPEG2. From rem-conf-request@es.net Mon Jul 15 10:38:36 1996 Received: from cbgw1.att.com by osi-east.es.net with ESnet SMTP (PP); Mon, 15 Jul 1996 07:37:57 -0700 Cc: rem-conf@osi-east.es.net, mrc@big.att.com Received: from big.att.com by cbig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id KAA28126; Mon, 15 Jul 1996 10:33:01 -0400 Received: from lexicon.info.att.com (lexicon.info.att.com [135.180.160.120]) by big.att.com (8.7.5/8.7.3) with ESMTP id KAA19801; Mon, 15 Jul 1996 10:36:24 -0400 (EDT) Received: from march (march.info.att.com [135.16.210.57]) by lexicon.info.att.com (8.7.5/8.7.3) with SMTP id KAA25856; Mon, 15 Jul 1996 10:36:23 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <31EA577D.15FB7483@att.com> Date: Mon, 15 Jul 1996 10:36:45 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b3 (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: casner@precept.com Original-CC: rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: Re: "at any one time" and "media types" - clarification needed Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve, > > And am I right to think that "media > > type" just means one of the set {audio, video}? > > Well, yes, for the current well-known applications using RTP. But > that would be too narrow a view for the long term. The basic idea is > to not try to mix things that don't mix. We have an application that puts mpeg video slices and corresponding synchronized audio in a single packet. This way the lip-synch is implied and the overhead (of headers and processing two seperate streams) is reduced. We found this approach to be particularly useful for VOD applications. My question is: can we consider audio and video mixable in this case and is it possible to define a new RTP payload covering these type of applications? -- M. Reha Civanlar AT&T Research Ph: (908) 949 6705 Fax: (908) 949 3697 From rem-conf-request@es.net Mon Jul 15 11:02:04 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Mon, 15 Jul 1996 08:01:35 -0700 Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.4/8.7.3) with ESMTP id IAA14059 for ; Mon, 15 Jul 1996 08:01:33 -0700 (PDT) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.4/8.7.3) id IAA19947 for rem-conf@es.net; Mon, 15 Jul 1996 08:01:30 -0700 (PDT) Original-Received: by ccm.hf.intel.com (ccmgate 3.2 #7) Mon, 15 Jul 96 08:01:29 PDT PP-warning: Illegal Received field on preceding line Date: Mon, 15 Jul 96 08:00:00 PDT From: Mary D Smiley Message-ID: To: rem-conf@es.net Subject: Subscribe. Hello- Please subscribe me to this mailing list. Thank you. Mary_D_Smiley_at_jfccm@ccm.hf.intel.com subscribe. From rem-conf-request@es.net Mon Jul 15 15:29:34 1996 Received: from bsd.prognet.com by osi-west.es.net with ESnet SMTP (PP); Mon, 15 Jul 1996 12:28:59 -0700 Received: from localhost (localhost [127.0.0.1]) by bsd.prognet.com (8.7.5/8.6.12) with SMTP id MAA27626 for ; Mon, 15 Jul 1996 12:27:33 -0700 (PDT) Message-Id: <199607151927.MAA27626@bsd.prognet.com> X-Authentication-Warning: bsd.prognet.com: Host localhost [127.0.0.1] didn't use HELO protocol From: bakul@BitBlocks.com To: rem-conf@es.net Reply-To: bakul@BitBlocks.com Subject: Use of RTP for broadcasting as opposed to conferencing Date: Mon, 15 Jul 1996 12:27:33 -0700 Sender: bakul@bsd.prognet.com Seems to me that if RTP is used for broadcasting (that is, there is one sender and many receivers) there are some scaling problems with RTCP. If 5% of the bandwidth is limited to RTCP traffic and we have, say, 1000 receivers and the audio stream BW is 2Kbytes/sec (possible with today's audio codecs), A receiver can send an RTCP packet no more often than once per 20 minutes. With larger audiences, each receiver can send even less frequently. So in a sense the primary purpose of the RTCP is lost. Not to mention that ramping upto 1000 receivers itself be problematic and it will be hard to stick to a 5% BW use limit. And yet, these numbers are quite realistic (or will be as more people connect to the net). What am I missing? That RTP should not be used for broadcasting? Or that you (i.e., the authors of RTP) envision a different scheme for reaching large audiences (but within the RTP framework)? [Also note that a) typically members of a large audience do not care to know about each other b) in a geographically distributed audience, person A in, say, Taiwan does not care about a packet lost by person B in Germany and even if he knows about it, there is precious little he can do about it. So it seems to me that either RTCP must be enhanced in some way or there should be guidelines on how to deploy your `broadcasting network'. By that I mean translators and mixers. ] You guys must have thought about these issues so I must be missing something very obvious. I would be grateful if you can enlighten me or point me in the right direction. Many thanks! Bakul Shah From rem-conf-request@es.net Mon Jul 15 15:56:01 1996 Received: from VNET.IBM.COM by osi-east.es.net with ESnet SMTP (PP); Mon, 15 Jul 1996 12:55:23 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1175; Mon, 15 Jul 96 15:55:24 EDT Date: Mon, 15 Jul 96 22:02:04 IST From: Scott Petrack To: casner@precept.com Cc: rem-conf@osi-east.es.net Subject: interleaving media types via payload type field Steve, Thanks a lot for the clarification. I was confused about the distinction between "media types" and "payload types." Section 5.2 says: It is not intended that the audio and video be carried in a single RTP session and demultiplexed based on the payload type or SSRC fields. Interleaving packets with different payload types but using the same SSRC would introduce several problems:.... My confusion came because it *is* in fact allowed to "interleave packets with different payload types but using the same SSRC." There is "only" a problem if the different payload types correspond to different media. Could I suggest that the second setence be changed to: Interleaving packets of different media types by using different payload types but using the same SSRC would introduce several problems. and that you say somewhere that interleaving packets of the same media types using the payload format is allowed (but be reasonable). Also, I got confused by "problem 1" from Section 5.2: ("If one payload type were switched during a session....") If this is talking about two different media types, then there *is* a "general means" to identify which of the old values is being replaced - the obvious rule would be that a new payload type replaces the old payload type of the same media type. You certainly know what media type each payload type belongs to. Last question: the discussion implies that it is ok to multiplex two full streams of the same media type in a single RTP session, multiplexed by SSRC only? In the normal situation you are sending only one full stream, even if there are several SSRCs. For example, if I am sending the video of a tennis match, then on my screen sometimes I see camera A, and sometimes camera B. But I could imagine sending a full set of frames for both cameras in a single RTP session, so that I can see a "split screen" of both cameras simultaneously all the time. Is this allowed, allowed-but-frowned-upon, or disallowed? It seems to be at least allowed by the RFC, but I can't see why you should allow it. Certainly the objection 5 of section 5.2 holds even if the streams are of one media type as well. Maybe this was just obviously disallowed by you. A sentence in the Definitions section 3 which defines "media type" might help too. Although this is obvious to you, it took me some time to figure out that this had a precise meaning. To summarize, it was clear to me that a single RTP session should not be used for multiplexing two realtime streams, but it was less clear to me that within a single RTP session: 1. "changing among different encodings of the same media type is allowed" 2. "multiplexing encodings of different media type is disallowed" 3. "multiplexing two full streams of same media via SSRC is ?????" 3. Exactly what is a "media type." Sorry to be so heavy handed with language, but I do want to make myself clear here. From rem-conf-request@es.net Mon Jul 15 18:20:06 1996 Received: from hplms26.hpl.hp.com by osi-west.es.net with ESnet SMTP (PP); Mon, 15 Jul 1996 15:19:28 -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 AA105909140; Mon, 15 Jul 1996 15:19:01 -0700 Received: by hplabsz.hpl.hp.com (1.37.109.15/15.5+ECS 3.3+HPL1.1) id AA067289140; Mon, 15 Jul 1996 15:19:00 -0700 From: deleon@hplabsz.hpl.hp.com (Laura de Leon) Message-Id: <9607151519.ZM6726@hplabsz.hpl.hp.com> Date: Mon, 15 Jul 1996 15:19:00 -0700 X-Mailer: Z-Mail (3.0.0 15dec93) To: baylisa@hplabsz.hpl.hp.com, rem-conf@es.net, sage-members@usenix.org Subject: BayLISA: Network General and AIM 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 -------- July 18: Bob Cousins, Network General/AIM Bob Cousins will talk about what they are learning in the labs at AIM about system performance and management. 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. August 15: Bryan O'Sullivan, Sun Microelectronics A system for load sharing a huge computational load between over 1000 CPUs on several hundred machines. 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 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. From rem-conf-request@es.net Mon Jul 15 18:22:08 1996 Received: from seawind.bellcore.com by osi-east.es.net with ESnet SMTP (PP); Mon, 15 Jul 1996 15:21:30 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id SAA06336; Mon, 15 Jul 1996 18:20:09 -0400 Date: Mon, 15 Jul 1996 18:20:09 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9607151820.ZM6334@seawind.bellcore.com> In-Reply-To: Scott Petrack "interleaving media types via payload type field" (Jul 15, 10:02pm) References: <199607152128.RAA25505@thumper.bellcore.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: Scott Petrack , casner@precept.com Subject: Re: interleaving media types via payload type field Cc: rem-conf@osi-east.es.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii > My confusion came because it *is* in fact allowed to "interleave packets > with different payload types but using the same SSRC." There is "only" a > problem if the different payload types correspond to different media. There would also be serious confusion if one switched between different compatible payload types that don't have the same clock. It is possible to switch between LPC, GSM, 8 kHz DVI4, 8 kHz PCM. But swicth between 8 kHz PCM and 44.1 kHz DVI4 is, hum, undesirable... -- Christian Huitema From rem-conf-request@es.net Tue Jul 16 00:00:26 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 15 Jul 1996 20:59:51 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA25960; Mon, 15 Jul 1996 20:59:50 -0700 Date: Mon, 15 Jul 1996 20:59:49 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Re: Multicast of "World Wide Live" event In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm sorry to report that the delayed rebroadcast of "World Wide Live" event on the MBone for the European audience has been cancelled because there is no location where the video feed and an MBone transmitter can be set up in the same place. (The main site will be torn down after the event.) The rebroadcast via satellite to locations in Europe will still occur. A "highlights" video will be produced from the day-long session, and there may be an opportunity to transmit that video via the MBone during daytime in Europe at a later date not too far in the future. From rem-conf-request@es.net Tue Jul 16 03:26:27 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 00:25:46 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA26649; Tue, 16 Jul 1996 00:25:40 -0700 Date: Tue, 16 Jul 1996 00:25:39 -0700 (PDT) From: Stephen Casner To: "M. Reha Civanlar" Cc: rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: Re: "at any one time" and "media types" - clarification needed In-Reply-To: <31EA577D.15FB7483@att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reha, > We have an application that puts mpeg video slices and corresponding > synchronized audio in a single packet. This way the lip-synch > is implied and the overhead (of headers and processing two > seperate streams) is reduced. We found this approach to be > particularly useful for VOD applications. There are arguments for both approaches. Point 5 in RTP section 5.2 lists several for using separate streams. Another example for the "broadcast" case is to send out a video stream accompanied by separate audio streams each in one of several languages. However, in particular I want to point out that it is not necessary to send audio and video in one packet in order to synchronize them; RTP provides a means to synchronize streams by relating the timestamps in two RTP data streams through the timestamps carried in RTCP packets. > My question is: can we consider audio and video mixable in this case > and is it possible to define a new RTP payload covering these type of > applications? This is different from the problem I've been trying to describe. For example, interleaving packets of payload type 0 (mu-law PCM) and payload type 31 (H.261) on a single session creates a problem. However, sending a payload type which indicates multiplexed audio and video is not a problem; receivers of that stream would be expecting a multiplexed format and would be prepared to deal with it. There is already a payload type defined for MPEG audio+video streams multiplexed in MPEG-2 Transport Streams format. That payload type is of media type "AV" in the table. Other payload formats that combine multiple data types together could be defined. There are issues with defining multiplexed streams; for example, the meaning of the RTP timestamp and the marker bit may be problematic. (The MPEG spec defines these; should that apply for all "AV" payload types?) -- Steve From rem-conf-request@es.net Tue Jul 16 04:10:05 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 01:09:15 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA26790; Tue, 16 Jul 1996 01:08:39 -0700 Date: Tue, 16 Jul 1996 01:08:38 -0700 (PDT) From: Stephen Casner To: bakul@BitBlocks.com Cc: rem-conf@es.net Subject: Re: Use of RTP for broadcasting as opposed to conferencing In-Reply-To: <199607151927.MAA27626@bsd.prognet.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 15 Jul 1996 bakul@BitBlocks.com wrote: > What am I missing? That RTP should not be used for broadcasting? > Or that you (i.e., the authors of RTP) envision a different scheme > for reaching large audiences (but within the RTP framework)? You are missing one key point, the first one in the list of bullets in RTP section 6.2: senders are allocated 1/4 of the RTCP bandwidth for exactly this case. In a broadcast session with one sender, that one sender gets 1.25% of the session bandwidth all to itself, no matter how many receivers there are. For the 2Kbytes/sec example you gave, that would allow an RTCP packet every 4 or 5 seconds, i.e., at the maximum rate allowed by the second bullet in section 6.2. > [Also note that > a) typically members of a large audience do not care to know about > each other You are right, it is not important to know the whole list. But we expect receives will still be interested to know how their reception compares with that of the audience at large. Each receiver will still be receiving reception reports at the same overall rate independent of the number of receivers, and over a shorter period that the 20 minute reception report interval, these reports represent a statistical sample of the total audiences' reception. There is an issue that one needs two reception reports from one source in order to take the difference between them; that's why the "loss fraction" field was added to allow singleton reports to be useful for the large audience case. I think we might want to change the definition of the loss fraction to cover a shorter interval than the whole reception report interval when that becomes long, but that's something we need more experience to answer. > b) in a geographically distributed audience, person A in, say, Taiwan > does not care about a packet lost by person B in Germany and even > if he knows about it, there is precious little he can do about > it. Even if A is in San Francisco and B is in Los Angeles, the situation he still may not be able to do anything about it. It is more a matter of comparing one's local reception to the global reception. > So it seems to me that either RTCP must be enhanced in some way > or there should be guidelines on how to deploy your `broadcasting > network'. By that I mean translators and mixers. > ] There are some valid applications of translators and mixers, but I would not install them in the data path just to change the behavior of RTCP. Instead, we have talked about schemes for limiting the scope of RTCP reports from individual senders, then having an RTCP aggregator send a single combined report with a larger scope. This is still research. > Not to mention that > ramping upto 1000 receivers itself be problematic and it will be > hard to stick to a 5% BW use limit. Actually, theory has it that the algorithm given in Appendix A.7 converges pretty rapidly. I don't recall the numbers at the moment. -- Steve From rem-conf-request@es.net Tue Jul 16 04:24:02 1996 Received: from rsung.crn.cogs.susx.ac.uk by osi-west.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 01:23:36 -0700 Received: by rsung.crn.cogs.susx.ac.uk (Smail3.1.29.1 #3) id m0ug5Qa-000211C; Tue, 16 Jul 96 09:24 BST Message-Id: Date: Tue, 16 Jul 96 09:24 BST From: ianw@cogs.susx.ac.uk (Ian Wakeman) To: bakul@BitBlocks.com cc: rem-conf@es.net Subject: Re:Use of RTP for broadcasting as opposed to conferencing In-Reply-To: <199607151927.MAA27626@bsd.prognet.com> References: <199607151927.MAA27626@bsd.prognet.com> >>>>> "bakul" == bakul writes: bakul> Seems to me that if RTP is used for broadcasting (that is, bakul> there is one sender and many receivers) there are some bakul> scaling problems with RTCP. If 5% of the bandwidth is bakul> limited to RTCP traffic and we have, say, 1000 receivers bakul> and the audio stream BW is 2Kbytes/sec (possible with bakul> today's audio codecs), A receiver can send an RTCP packet bakul> no more often than once per 20 minutes. With larger bakul> audiences, each receiver can send even less frequently. So bakul> in a sense the primary purpose of the RTCP is lost. Not really - whilst the standard advises that the RTCP bandwidth should be 5%, it doesn't specify how that bandwidth should be divided (from memory). One can design ways of dividing up the bandwidth to achieve one's policy aims. For instance, if you're mainly interested in who is joining the group, a process knows that 80% of that 5% is dedicated to joining processes, 10% is dedicated to source RTCP packets, and so one waits to determine what the current rate of joins is and then sends after an appropriate random period. Alternatively do a bit of random probing a la my (and Jean and Thierry) paper in Sigcomm94, or use a hierarchical approach, where representatives are elected for local areas. Hopefully one of the authors will reply and give you a more authorative answer. bakul> Not to bakul> mention that ramping upto 1000 receivers itself be bakul> problematic and it will be hard to stick to a 5% BW use bakul> limit. And yet, these numbers are quite realistic (or will bakul> be as more people connect to the net). Actually, look to design for the millions... cheers ian From rem-conf-request@es.net Tue Jul 16 06:47:30 1996 Received: from hosim.kwangju.ac.kr (actually 202.30.35.43) by osi-east.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 03:46:05 -0700 Received: from vclab.kwangju.ac.kr ([203.246.49.243]) by hosim.kwangju.ac.kr (8.7.1H1/8.7.1) with SMTP id UAA03132 for ; Tue, 16 Jul 1996 20:41:53 -0700 (PDT) Message-ID: <31EB7127.4251@csbbs.kwangju.ac.kr> Date: Tue, 16 Jul 1996 19:38:31 +0900 From: Jeongmin Cho Reply-To: cjm@csbbs.kwangju.ac.kr Organization: Dept. of computer science Kwangju University X-Mailer: Mozilla 3.0b3Gold (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Help me !! The UDP overflow Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Hello ! My name is jeongmin Cho. My current project is to develop a videophone system on Win95. I have a problem which must be solved. 1. The operation model S1 <----------->+ S1 <--------------->+ + + S2-S/R A/V codec s2-S/R A/V codec ---------- ----------- protocol UDP UDP stack ---------- ------------ IP IP ---------- ------------ Network I/F Network I/F ---------- ------------ + + + <---------------------------> + S1 : application's thread(GUI, packetizer) S2 : communication's thread S/R : sender and receiver A/V : audio and video 1) The audio data is generated a 1024Kb at a 125 ms. 2) The video data is generated a 1024Kb at the setting rate (i.g. 128kbps, 256kbps,384kbps...) from the video codec, and it is sent to the receiver by a S2 thread. 3) The application is implemented with MFC. 4) The S1 is a main thread that is inherited from CWinApp. 5) The S2 is a communication thread that is inherited from the CWinThread and the CSocket. 6) The communication is a dual. 7) The application have a polling the codec to get data from the codec. And a polling routine is in the onIdle routine. 8) There is no protocol to manager the audio and the video data from/to the UDP. 9) The operation mode of winsock is a unblocking. 2) The problem 1) UDP overflow. 2) The behavior of mouse have a consideration of the performance of application. 3) Then, what's the problem ? what's the solution ? From rem-conf-request@es.net Tue Jul 16 09:31:41 1996 Received: from cebaf1.cebaf.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 06:31:04 -0700 Received: from CEBAF.GOV by CEBAF.GOV (PMDF V5.0-5 #9103) id <01I74WEVIOY890N83N@CEBAF.GOV> for rem-conf@es.net; Tue, 16 Jul 1996 09:31:01 -0500 (EST) Date: Tue, 16 Jul 1996 09:31:01 -0500 (EST) From: Lan Fan Subject: video card for Sparc Station To: rem-conf@es.net Message-id: <01I74WEVKH0290N83N@CEBAF.GOV> X-VMS-To: IN%"rem-conf@es.net" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hello, I have a SparcStation 4. I would like to buy a video card to support video camera and current conferencing software. Here is what I found from Sun Web page: Video Capture Board (VideoPix), part # X218A Sun Video Board, part # X1085A Could anyone confirm that it would work on Sparc Station 4? Any help would be highly appreciated. Lan Fan ----------------------------------------------------------------------------- System Administrator Thomas Jefferson National Accelerator Facility fanl@cebaf.gov (804)-249-5814 From rem-conf-request@es.net Tue Jul 16 09:55:57 1996 Received: from VNET.IBM.COM by osi-east.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 06:55:22 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4449; Tue, 16 Jul 96 09:55:19 EDT Date: Tue, 16 Jul 96 15:56:11 IST From: petrack@VNET.IBM.COM To: HUITEMA@BELLCORE.COM Cc: rem-conf@osi-east.es.net Subject: Re: interleaving media types via payload type field Reply-To: PETRACK@HAIFASC3.VNET.IBM.COM News-Software: UReply 3.1 In a previous message, you wrote: > >There would also be serious confusion if one switched between different >compatible payload types that don't have the same clock. It is possible to >switch between LPC, GSM, 8 kHz DVI4, 8 kHz PCM. But swicth between 8 kHz >PCM and 44.1 kHz DVI4 is, hum, undesirable... > It depends, no? Sometimes this might be ok, I think. This is all within those questions of "being reasonable." I understood >from Steve's clarification that he wanted to avoid giving a precise definition of what is reasonable to do and what is not. I understood the RFC (plus the clarifications) to imply the following: 1. If the two clocks are really different physical clocks then I am required by the RFC to switch SSRCs, and this is a perfectly legal thing to do within one RTP session. Of course, it may sound bad, but it is perfectly allowed, as long as you switch SSRCs. 2. If the two sampling rates come from the same clock, as in some computer sound cards which have a single clock on them, but give you the possibility to output various sampling rates, then it is possible to switch payload types from one to the other *without* changing the SSRC. (On some of these cards the D/A is always 44.1 and they have on-card down-sampling). Assuming that the decoder can handle this, I can even imagine situations where this is reasonable. In any case I believe that the RFC allows this. Please correct me if I'm wrong. From rem-conf-request@es.net Tue Jul 16 11:37:30 1996 Received: from alpha.xerox.com by osi-east.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 08:36:59 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15717(1)>; Tue, 16 Jul 1996 08:36:53 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 16 Jul 1996 08:36:45 PDT To: "M. Reha Civanlar" Cc: rem-conf@osi-east.es.net, mrc@big.att.com, deering@parc.xerox.com Subject: Re: "at any one time" and "media types" - clarification needed Date: Tue, 16 Jul 1996 08:36:45 PDT Sender: Steve Deering From: Steve Deering Message-Id: <96Jul16.083645pdt."75270"@digit.parc.xerox.com> > We have an application that puts mpeg video slices and corresponding > synchronized audio in a single packet. This way the lip-synch > is implied and the overhead (of headers and processing two > seperate streams) is reduced. We found this approach to be > particularly useful for VOD applications. Steve Casner mentioned the alternative of using the RTP timestamps to accomplish lip-synch. Regarding the bandwidth overhead of separating the audio and video into separate packets (and separate sessions), an alternative way to cope with that overhead is to use header compression (of IP+UDP+RTP headers) over slow links. That way, you can retain the modularity (e.g., the ability to receive just the audio, just the video, or both) and the flexibility (e.g., simple demuxing of the audio and video to separate processing elements, using the UDP port numbers) of separate packets, while still keeping the header overhead very low. Steve From rem-conf-request@es.net Tue Jul 16 13:12:43 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 10:12:10 -0700 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 16 Jul 1996 18:11:51 +0100 To: petrack@VNET.IBM.COM Cc: rem-conf@osi-east.es.net In-reply-to: Your message of "Tue, 16 Jul 1996 15:56:11 +0700." Date: Tue, 16 Jul 1996 18:11:50 +0100 Message-ID: <4780.837537110@cs.ucl.ac.uk> From: Colin Perkins >There would also be serious confusion if one switched between different >compatible payload types that don't have the same clock. It is possible to >switch between LPC, GSM, 8 kHz DVI4, 8 kHz PCM. But swicth between 8 kHz >PCM and 44.1 kHz DVI4 is, hum, undesirable... Undesirable maybe, but not necessarily unreasonable. Once one has an audio tool capable of running at high sampling rates, it is natural to include sample rate conversion code to handle input streams at many different formats and rates. Once you have such a set-up, switching between 8kHz PCM and 44.1kHz DVI4, is no more difficult than switching any other set of encodings..... Colin From rem-conf-request@es.net Tue Jul 16 13:22:00 1996 Received: from unb.ca (actually hermes.csd.unb.ca) by osi-west.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 10:21:18 -0700 Received: (from cythera.unb.ca [131.202.3.18]) by unb.ca (8.7.5/960430-08:40) id OAA19837; Tue, 16 Jul 1996 14:21:16 -0300 (ADT) Received: (from cythera.unb.ca [131.202.3.18]) by cythera.unb.ca (8.7.5/8.7.1) with SMTP id OAA14429; Tue, 16 Jul 1996 14:21:15 -0300 (ADT) Date: Tue, 16 Jul 1996 14:21:14 -0300 (ADT) From: "Dwight E. Spencer" To: Lan Fan cc: rem-conf@es.net Subject: Re: video card for Sparc Station In-Reply-To: <01I74WEVKH0290N83N@CEBAF.GOV> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 16 Jul 1996, Lan Fan wrote: > I have a SparcStation 4. I would like to buy a video card to support > video camera and current conferencing software. Here is what > Video Capture Board (VideoPix), part # X218A > Sun Video Board, part # X1085A I use this on my sparc 4 all the time (using nv, vic and SunVideo) with no problems, except the 8bit color map restraints. I will mention, however, if you plan on doing multicast on your sparc 4, that it does not come with the audio card by default, and you may need to purchase that (my last one cost $155 canadian) as well. dwight. ----------------------------------------------------------------------- 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 Jul 16 14:00:30 1996 Received: from cbgw2.att.com by osi-east.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 10:59:28 -0700 Cc: deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com Received: from lexicon.dnrc.bell-labs.com by cbig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id NAA15489; Tue, 16 Jul 1996 13:57:55 -0400 Received: from march (march.info.att.com [135.16.210.57]) by lexicon.dnrc.bell-labs.com (8.7.5/8.7.3) with SMTP id NAA10624; Tue, 16 Jul 1996 13:56:38 -0400 (EDT) Sender: mrc@dnrc.bell-labs.com Message-ID: <31EBD7EB.13728473@att.com> Date: Tue, 16 Jul 1996 13:56:59 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b3 (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Stephen Casner Original-CC: deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com Subject: Re: "at any one time" and "media types" - clarification needed References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for the prompt responses. I believe, defining a mixed payload type will be beneficial. Stephen Casner wrote: > > There are arguments for both approaches. Point 5 in RTP section 5.2 > lists several for using separate streams. Another example for the > "broadcast" case is to send out a video stream accompanied by separate > audio streams each in one of several languages. > I completely agree that those points are valid for many applications; however, there exist an important group of other applications, e.g. retrieval of audio/video information referred from an html document, which do not need seperate streams. > However, in particular I want to point out that it is not necessary to > send audio and video in one packet in order to synchronize them; RTP > provides a means to synchronize streams by relating the timestamps in > two RTP data streams through the timestamps carried in RTCP packets. > Again, returning to the example above, this approach requires generating two sets of carefully synchronized time stamps at the source and handling two sockets at both ends increasing the processing overhead. Also, the two streams will suffer varying and difficult to estimate delays in the network which necessitate using larger buffers at the receiver. > > My question is: can we consider audio and video mixable in this case > > and is it possible to define a new RTP payload covering these type of > > applications? > > This is different from the problem I've been trying to describe. For > example, interleaving packets of payload type 0 (mu-law PCM) and > payload type 31 (H.261) on a single session creates a problem. > However, sending a payload type which indicates multiplexed audio and > video is not a problem; receivers of that stream would be expecting a > multiplexed format and would be prepared to deal with it. > Sorry for the confusion. Although, I may see some applications switching >from one coding type to another to adapt themselves better to changing network conditions during a single session, my main point was not that. > There is already a payload type defined for MPEG audio+video streams > multiplexed in MPEG-2 Transport Streams format. That payload type is > of media type "AV" in the table. Other payload formats that combine > multiple data types together could be defined. > > There are issues with defining multiplexed streams; for example, the > meaning of the RTP timestamp and the marker bit may be problematic. > (The MPEG spec defines these; should that apply for all "AV" payload > types?) > -- Steve In many cases, the transport stream will be good for nothing but overhead. As for the RTP timestamp and the marker bit, they can still have their values as defined for the video. The audio segment corresponding to the video segment contained in the packet can be appended to the end. In our application, we pack several video slices followed by corresponding audio section. Steve Deering wrote: > > Steve Casner mentioned the alternative of using the RTP timestamps to > accomplish lip-synch. Regarding the bandwidth overhead of separating > the audio and video into separate packets (and separate sessions), an > alternative way to cope with that overhead is to use header compression > (of IP+UDP+RTP headers) over slow links. That way, you can retain the > modularity (e.g., the ability to receive just the audio, just the video, > or both) and the flexibility (e.g., simple demuxing of the audio and > video to separate processing elements, using the UDP port numbers) of > separate packets, while still keeping the header overhead very low. > > Steve Unfortunately, (IP+UDP+RTP) header compression is not (widely?) available yet. Also, this does not help with the processing overhead for handling two time stamps and dealing with two sockets. -- M. Reha Civanlar AT&T Research From rem-conf-request@es.net Tue Jul 16 14:21:04 1996 Received: from paris.ics.uci.edu by osi-west.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 11:20:32 -0700 Received: from ballet.ics.uci.edu by paris.ics.uci.edu id aa26847; 16 Jul 96 10:52 PDT X-Sender: shimojo@paris.ics.uci.edu X-Mailer: Windows Eudora Pro Version 2.2-Jr1 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Date: Tue, 16 Jul 1996 10:50:15 -0700 To: Stephen Casner , bakul@bitblocks.com From: Shinji Shimojo Subject: Re: Use of RTP for broadcasting as opposed to conferencing Cc: rem-conf@es.net Message-ID: <9607161052.aa26847@paris.ics.uci.edu> At 01:08 96/07/16 -0700, Stephen Casner wrote: > You are missing one key point, the first one in the list of bullets in > RTP section 6.2: senders are allocated 1/4 of the RTCP bandwidth for > exactly this case. In a broadcast session with one sender, that one > sender gets 1.25% of the session bandwidth all to itself, no matter > how many receivers there are. For the 2Kbytes/sec example you gave, > that would allow an RTCP packet every 4 or 5 seconds, i.e., at the > maximum rate allowed by the second bullet in section 6.2. I think this gives a point but another point is a BW given to receivers. If one wants to implement a feedback based video transmission mechanism like Wakeman proposed in Sigcomm 94[1] or Busse [2], 5% RTCP traffic limit for all the receivers makes a feedback by RTCP useless. If the sender sends a video of rate 1Mbps to 1000 receivers, a receiver can get only 37.5bps bandwidth. The receiver can not send a RTCP within a second. Therefore, I have a following questions: 1. Can RTCP be used as a feedback rate control mechanism ? 2. Is Aggrigation of RTCPs worth considering ? but how, a mixer or a translator ? or other ? > There are some valid applications of translators and mixers, but I > would not install them in the data path just to change the behavior of > RTCP. Instead, we have talked about schemes for limiting the scope of > RTCP reports from individual senders, then having an RTCP aggregator > send a single combined report with a larger scope. This is still > research. Sounds interesting. Could you show some pointers ? [1] Jean-Chrysostome Bolot, Thierry Turletti, Ian Wakeman, "Scalable Feedback Control for Multicast Video Distribution in the Internet" Sigcomm 94. [2] Ingo Busse, Bernd Deffner, Henning Schulzrinne, "Dynamic QoS Control of Multimedia Application based on RTP", Computer Communications, Jan. 1996. (also found at http://www.fokus.gmd.de/step/rtp) ------------------- Shinji Shimojo Calfornia (2/24/96-) Information & Computer Science University of Calfornia Irvine, CA 92717 PHONE: +1 714 824-3097 FAX: +1 714 824-4056 shimojo@ics.uci.edu Japan Computer Center Osaka University 5-1 Mihogaoka, Ibaraki 567 JAPAN Tel: +81 (6) 879-8793 fax: 06-879-8814 shimojo@center.osaka-u.ac.jp From rem-conf-request@es.net Tue Jul 16 15:44:42 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 12:44:14 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA06066; Tue, 16 Jul 1996 12:44:06 -0700 Date: Tue, 16 Jul 1996 12:44:06 -0700 (PDT) From: Karl Auerbach To: "M. Reha Civanlar" Cc: Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: <31EBD7EB.13728473@att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > However, in particular I want to point out that it is not necessary to > > send audio and video in one packet in order to synchronize them; RTP > > provides a means to synchronize streams by relating the timestamps in > > two RTP data streams through the timestamps carried in RTCP packets. > > > Again, returning to the example above, this approach requires generating > two sets of carefully synchronized time stamps at the source and > handling two sockets at both ends increasing the processing overhead. > Also, the two streams will suffer varying and difficult to estimate > delays in the network which necessitate using larger buffers at the > receiver. I would assert that having audio and video arrive synchronized is merely convenient. The data pathways through the receiving computer's software and presentation hardware are potentially very different for audio and video. Consequently, even if audio data and video data were to arrive synchronized, absent additional efforts, they would often not be rendered in synchrony. As a result, the effort to deliver audio and video streams in almost-exact synchrony at the receiver's network interface is potentially a wasted effort since it does little to help the synchronized delivery of that audio and video in synchrony to the user's ears and eyes. --karl-- From rem-conf-request@es.net Tue Jul 16 17:05:01 1996 Received: from ihgw1.att.com by osi-east.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 14:04:23 -0700 Cc: Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Received: from big.att.com by ihig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id PAA20226; Tue, 16 Jul 1996 15:19:32 -0500 Received: from march (march.info.att.com [135.16.210.57]) by big.att.com (8.7.5/8.7.3) with SMTP id QAA08974; Tue, 16 Jul 1996 16:14:07 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <31EBF7C2.500F9F30@att.com> Date: Tue, 16 Jul 1996 16:14:30 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b3 (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Karl Auerbach Original-CC: Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Karl Auerbach wrote: > > I would assert that having audio and video arrive synchronized is merely > convenient. > > The data pathways through the receiving computer's software and > presentation hardware are potentially very different for audio and video. > > Consequently, even if audio data and video data were to arrive > synchronized, absent additional efforts, they would often not be rendered > in synchrony. > > As a result, the effort to deliver audio and video streams in almost-exact > synchrony at the receiver's network interface is potentially a wasted > effort since it does little to help the synchronized delivery of that > audio and video in synchrony to the user's ears and eyes. > > --karl-- I tend to disagree with your assertation. Although audio and video data may experience different delays through the receiving SW and presentation HW of different receiving computers, this delay difference is a parameter of each receiving computer. Given synchronized input audio and video data, the necessary buffer size to compensate for this delay difference can be determined exactly for each receiving station. This determination is merely a set up process and needs to be done only when new SW/HW is installed. On the other hand, taking care of the network delay jitter requires complicated estimation and/or large buffer sizes (->large delay) for all stations, all the time. -- M. Reha Civanlar AT&T Research From rem-conf-request@es.net Tue Jul 16 17:35:22 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 14:34:39 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA07048; Tue, 16 Jul 1996 14:34:01 -0700 Date: Tue, 16 Jul 1996 14:34:00 -0700 (PDT) From: Karl Auerbach To: "M. Reha Civanlar" Cc: Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: <31EBF7C2.500F9F30@att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > As a result, the effort to deliver audio and video streams in almost-exact > > synchrony at the receiver's network interface is potentially a wasted > > effort since it does little to help the synchronized delivery of that > > audio and video in synchrony to the user's ears and eyes. > I tend to disagree with your assertation. > > Although audio and video data may experience different delays through > the receiving SW and presentation HW of different receiving computers, > this delay difference is a parameter of each receiving computer. Given > synchronized input audio and video data, the necessary buffer size to > compensate for this delay difference can be determined exactly for each > receiving station. This determination is merely a set up process and > needs to be done only when new SW/HW is installed. On the other hand, > taking care of the network delay jitter requires complicated estimation > and/or large buffer sizes (->large delay) for all stations, all the > time. Your method of combining audio and video into the same packet does not elminate variations in transit time, and hence those elastic receiver mechanisms are still necessary. And you are also assuming that audio processing delay and video processing delay through the receiving computer are constants, unaffected by the data content. --karl-- From rem-conf-request@es.net Tue Jul 16 18:08:38 1996 Received: from alpha.xerox.com by osi-east.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 15:07:29 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16126(2)>; Tue, 16 Jul 1996 15:07:13 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 16 Jul 1996 15:06:52 PDT To: "M. Reha Civanlar" Cc: rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com, deering@parc.xerox.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: civanlar's message of Tue, 16 Jul 96 10:56:59 -0800. <31EBD7EB.13728473@att.com> Date: Tue, 16 Jul 1996 15:06:52 PDT Sender: Steve Deering From: Steve Deering Message-Id: <96Jul16.150652pdt."75270"@digit.parc.xerox.com> > From: "M. Reha Civanlar" > > Also, this [header compression] does not help with the processing overhead > for handling two time stamps and dealing with two sockets. That may be true, but is the overhead so significant that it is worth the loss of receiver modularity and flexibility that is a consequence of putting both audio and video in the same packet? Steve From rem-conf-request@es.net Tue Jul 16 21:38:37 1996 Received: from necom830.hpcl.titech.ac.jp by osi-west.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 18:38:07 -0700 From: Masataka Ohta Message-Id: <199607170128.KAA12937@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA12937; Wed, 17 Jul 1996 10:28:12 +0900 Subject: Re:Use of RTP for broadcasting as opposed to conferencing To: rem-conf@es.net Date: Wed, 17 Jul 96 10:28:11 JST X-Mailer: ELM [version 2.3 PL11] > Seems to me that if RTP is used for broadcasting (that is, > there is one sender and many receivers) there are some > scaling problems with RTCP. If 5% of the bandwidth is > limited to RTCP traffic and we have, say, 1000 receivers > and the audio stream BW is 2Kbytes/sec (possible with > today's audio codecs), A receiver can send an RTCP packet > no more often than once per 20 minutes. With larger > audiences, each receiver can send even less frequently. So > in a sense the primary purpose of the RTCP is lost. It is of course that simple multicast, with or without RTCP, can't work well with a lot heterogeneous receivers. The increase of the number of receivers tends to increase the heterogeneousness. In such a case, it is not a meaningful goal to control average loss ratio over all the receivers, which means some receivers are assured to suffer from loss and some links are assured to have overly congestion. It cause a serious congestion for a large scale broadcast. A little more meaningful goal to control the worst (over all the receivers) loss ratio, assures no congestion. But, then, RTCP feedback, which is sent only once per 20 minuits >from the worst loss receiver, does not work. RTCP works only to estimate the average. That is, you are right. The only reasonable thing to do for large scale multicast is, it seems to me, to have layered encoding with prioritized packet dropping. Masataka Ohta From rem-conf-request@es.net Tue Jul 16 21:48:49 1996 Received: from rx7.ee.lbl.gov by osi-west.es.net with ESnet SMTP (PP); Tue, 16 Jul 1996 18:48:11 -0700 Received: by rx7.ee.lbl.gov (8.6.12/1.43r) id SAA17824; Tue, 16 Jul 1996 18:49:03 -0700 Message-Id: <199607170149.SAA17824@rx7.ee.lbl.gov> To: rem-conf@es.net Subject: MBone broadcast of Berkeley Lab's Summer Lecture series Date: Tue, 16 Jul 96 18:49:01 PDT From: Van Jacobson We plan to broadcast the LBNL Summer Lecture series over the MBone. The lectures are given by leading Berkeley Lab scientists every Wednesday from noon to 1pm, PDT (1900-2000 GMT). More information on the series is available at: http://www.lbl.gov/Workplace/summer-lectures96.html Tomorrow's lecture will be Bill McCurdy, LBNL's Associate Director for Computing, speaking on "Large Scale Scientific Computing - the Year 2000 and Beyond." Audio format will be RTP/DVI4 and video will be H.261. The session is announced in sdr. Please let van@ee.lbl.gov know if there are any problems or conflicts. Thanks. - Van Jacobson From rem-conf-request@es.net Wed Jul 17 03:25:52 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 00:24:19 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA09064; Wed, 17 Jul 1996 00:23:59 -0700 Date: Wed, 17 Jul 1996 00:23:58 -0700 (PDT) From: Stephen Casner To: Scott Petrack Cc: rem-conf@osi-east.es.net Subject: Re: interleaving media types via payload type field In-Reply-To: <9607151955.AA23225@precept.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Scott, > My confusion came because it *is* in fact allowed to "interleave packets > with different payload types but using the same SSRC." There is "only" a > problem if the different payload types correspond to different media. Well, not really. One problem with the writing is that I meant more by "interleave" than is evident. For example, it would also be a problem if there were two streams of audio, say the English soundtrack encoded in PCM and the French soundtrack encoded in DVI, and both streams were sent from the same SSRC to the same RTP session by interleaving (alternating) packets of those two streams. One could, in theory, demultiplex the packets based on the payload type and process the two streams independently. However, if the encoding on one of them was changed to GSM, to which stream should the audio be assigned when the first GSM packet was seen? So, it's OK to change the encoding on a stream (and hence its payload type), but it's not OK to multiplex streams from a single SSRC by using multiple payload types, whether they are of the same "media type" or not. I claim it is also not "reasonable" to multiplex different media types within one RTP session by sending them from different SSRCs either, because that forces a single receiver to be able to handle all the media types and figure out what it means to present them together. On the other hand, for some applications, it might be considered just as unreasonable for different encodings of the same "medium" to be sent in one session if receivers are not expected to be able to combine multiple encodings for presentation. Therefore, in the main RTP spec, I would shy away from defining "media" and "reasonable". Granted, it is a problem if those terms are used without definition. Now in the context of the A/V profile, I think we can be more strict because we are trying to define a set of rules to allow multiple implementations of A/V applications to interoperate. However, even that can be a problem because there are a variety of applications being implemented under that profile. > Also, I got confused by "problem 1" from Section 5.2: > ("If one payload type were switched during a session....") > If this is talking about two different media types, then there *is* > a "general means" to identify which of the old values is being > replaced - the obvious rule would be that a new payload type replaces > the old payload type of the same media type. You certainly know > what media type each payload type belongs to. OK, but what if there are three media types and one stream switches >from a payload type in one media type to this third media type. The goal is not to see what we can shoe-horn in; the basic idea I'm trying to get across here is that one should use the addresses and port numbers for multiplexing -- that's what they are there for. > Last question: the discussion implies that it is ok to multiplex two > full streams of the > same media type in a single RTP session, multiplexed by SSRC only? > In the normal situation you are sending only one full stream, even > if there are several SSRCs. For example, if I am sending the video of > a tennis match, then on my screen sometimes I see camera A, > and sometimes camera B. But I could imagine sending a full set of > frames for both cameras in a single RTP session, so that I can see > a "split screen" of both cameras simultaneously all the time. > Is this allowed, allowed-but-frowned-upon, or disallowed? This question is for the application to answer. There's no reason for the RTP spec to disallow it. I'll give a couple of examples. In an audio conference, each participant sends an audio stream from his microphone, and these all get mixed together for playback. These are "full streams" multiplexed by SSRC on the same session. (They are probably also coming from separate hosts, that that is unimportant.) Social protocols allow multiple participants to talk at the same time to a limited extent. Now, say one of the participants wants to play a tape recording and talk over it for annotation purposes. These could be sent as separate streams with separate SSRC ids from the one host. That's fine. Similarly, if each participant sends video from a camera providing a talking-head view and then one participant also wants to send video from a copy-stand camera, it may be reasonable for the copy-stand video to be sent to the same session. The participants can view all of those video streams in separate windows. On the other hand, say everyone in the conference has both a talking-head view and a copy-stand camera. Then suppose the application is selecting a single participants talking-head view to show in one window based on voice activity detection, but is somehow mixing all the copystand video streams together into one image to form a simulation of a shared whiteboard (bear with me, I'm making this up as I go along). In that case, it would be better to send the talking head views and the copystand streams to different RTP sessions. Even though they are both video media, it would be unreasonable (from the application's point of view) for one participant to send the copystand view to the same session as the talking-head view. > >There would also be serious confusion if one switched between different > >compatible payload types that don't have the same clock. It is possible to > >switch between LPC, GSM, 8 kHz DVI4, 8 kHz PCM. But swicth between 8 kHz > >PCM and 44.1 kHz DVI4 is, hum, undesirable... > > It depends, no? Sometimes this might be ok, I think. This is all within > those questions of "being reasonable." I understood > from Steve's clarification that he wanted to avoid giving a precise > definition of what is reasonable to do and what is not. Right. In a given RTP session, an allowable set of encodings might be defined. The set is determined by the capabilities of the receives to switch among them. I agree with Christian that the switch from 8 kHz to 44.1 kHz might be undesirable because it would cause a disturbing glitch in the output. Some apps might not want to allow it at all; for others it might be reasonable to switch, but just not too often. > I understood the RFC (plus the clarifications) to imply the following: > > 1. If the two clocks are really different physical clocks > then I am required by the RFC to switch SSRCs, and > this is a perfectly legal thing to do within one RTP session. > Of course, it may sound bad, but > it is perfectly allowed, as long as you switch SSRCs. Two different physical clocks has nothing to do with it, and no, you are not required by the RFC to switch SSRCs. You can switch encodings emanating from a single SSRC, even if they are derived from different physical clocks. As you say, it might sound bad, especially if you switch frequently. You should use two different SSRCs if you are sending two logically separate streams. > 2. If the two sampling rates come from the same clock, as in some computer > sound cards which have a single clock on them, but give you the possibility > to output various sampling rates, then it is possible to switch > payload types from one to the other *without* changing the SSRC. > (On some of these cards the D/A is always 44.1 and they have on-card > down-sampling). > Assuming that the decoder can handle this, I can even imagine situations > where this is reasonable. In any case I believe that the RFC allows this. Yes, but there is no requirement that the sound card have a single clock (though I would expect most have only one, be it adjustable). -- Steve From rem-conf-request@es.net Wed Jul 17 03:54:08 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 00:52:43 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA09094; Wed, 17 Jul 1996 00:52:24 -0700 Date: Wed, 17 Jul 1996 00:52:24 -0700 (PDT) From: Stephen Casner To: "M. Reha Civanlar" Cc: deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: <31EBD7EB.13728473@att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I completely agree that those points are valid for many applications; > however, there exist an important group of other applications, e.g. > retrieval of audio/video information referred from an html document, > which do not need seperate streams. Perhaps. Then again, if I am at the end of a 14.4 line and can handle the audio but not the video, I might appreciate the ability to separate them. > Again, returning to the example above, this approach requires generating > two sets of carefully synchronized time stamps at the source and Actually, the generation of RTP and RTCP timestamps for the case of playing audio and video from a file is simple because it is all virtual time. Tracking real capture devices on machines with poor device drivers and worse excuses for an operating system is much harder. > handling two sockets at both ends increasing the processing overhead. Depending upon implementation, this may be true. > Also, the two streams will suffer varying and difficult to estimate > delays in the network which necessitate using larger buffers at the > receiver. Yes, the delays in the network may be difficult to estimate, but once you have built a mechanism to do it, doing it separately for audio and video is not really harder than doing it once for a combined stream. I don't agree that the buffers must be larger -- the size of the buffer is determined by the maximum jitter. Sending the streams separately doesn't (necessarily) make the maximum jitter worse. You still have to estimate the varying delays and have a buffer of the same size in the combined case. -- Steve From rem-conf-request@es.net Wed Jul 17 11:40:58 1996 Received: from ormail.intel.com by osi-east.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 08:40:20 -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 IAA10017; Wed, 17 Jul 1996 08:40:07 -0700 (PDT) Received: from pcrsvp.jf.intel.com by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0ugYh5-000RTPC; Wed, 17 Jul 96 08:39 PDT Message-Id: X-Sender: mbaugher@ibeam.jf.intel.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 17 Jul 1996 08:36:06 -0700 To: Steve Deering , "M. Reha Civanlar" From: Mark Baugher Subject: Re: "at any one time" and "media types" - clarification needed Cc: rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com, deering@parc.xerox.com At 03:06 PM 7/16/96 PDT, Steve Deering wrote: >That may be true, but is the overhead so significant that it is worth the >loss of receiver modularity and flexibility that is a consequence of >putting both audio and video in the same packet? > >Steve > For a video server it probably is. Also, for very low bitrate streams, say a 20kbps video stream and 5 kpbs audio stream, even the overhead of the link-layer header is considerable. I think there's little, if anything, to be gained by a receiver receiving one stream and not another. Mark From rem-conf-request@es.net Wed Jul 17 13:37:35 1996 Received: from mail-relay-BLR.ernet.in (actually 202.141.1.4) by osi-west.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 10:36:59 -0700 Received: from iisc.ernet.in (iisc [144.16.64.3]) by mail-relay-BLR.ernet.in (8.6.11/8.6.9) with SMTP id WAA17637; Wed, 17 Jul 1996 22:07:41 +0530 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id AA22206; Wed, 17 Jul 96 22:58:32+0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA10283; Wed, 17 Jul 96 22:51:46+0530 From: anand@ece.iisc.ernet.in (SVR Anand) Message-Id: <9607171721.AA10283@ece.iisc.ernet.in> Subject: Re: "at any one time" and "media types" - clarification needed To: mbaugher@ibeam.jf.intel.com (Mark Baugher) Date: Wed, 17 Jul 96 22:51:46 GMT+5:30 Cc: rem-conf@es.net In-Reply-To: ; from "Mark Baugher" at Jul 17, 96 8:36 am X-Mailer: ELM [version 2.3 PL11] Mark I feel that RTP is not just restricted to any specific kinds of media. Why only audio and video ? There can be images (slides, annotations therein etc), and "file transfers" during a realtime multimedia session. So, trying to achieve a strong synchrony between a number of media can become a tough job and impratical at times. In such a situation one wouldn't mind compromising on synchronisation and giving preference to one particular media over another. Instead of either totally accepting or totally rejecting as in the case of combined media travelling together, I may prefer a reception of a subset of the total media. At the source, as the number of media types increase, trying to pass them through some kind of "common point" and waiting if need be for the arrival of these to that common point so that they can be sent on the network together can be a painful task. So, keep the sources of media separate, and handle them separately. Lets sync whenever possible, and not overly mind at the lack of it, at times. Regards Anand. > > At 03:06 PM 7/16/96 PDT, Steve Deering wrote: > > >That may be true, but is the overhead so significant that it is worth the > >loss of receiver modularity and flexibility that is a consequence of > >putting both audio and video in the same packet? > > > >Steve > > > For a video server it probably is. > > Also, for very low bitrate streams, say a 20kbps video stream and 5 kpbs > audio stream, even the overhead of the link-layer header is considerable. > I think there's little, if anything, to be gained by a receiver receiving > one stream and not another. > > Mark > > From rem-conf-request@es.net Wed Jul 17 13:59:46 1996 Received: from cbgw1.att.com by osi-east.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 10:59:13 -0700 Cc: deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Received: from big.att.com by cbig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id NAA02124; Wed, 17 Jul 1996 13:53:59 -0400 Received: from march (march.info.att.com [135.16.210.57]) by big.att.com (8.7.5/8.7.3) with SMTP id NAA08179; Wed, 17 Jul 1996 13:58:38 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <31ED29E4.33590565@att.com> Date: Wed, 17 Jul 1996 13:59:00 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b3 (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Stephen Casner Original-CC: deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve, > > Then again, if I am at the end of a 14.4 line and can handle > the audio but not the video, I might appreciate the ability to > separate them. A separate URL can always be provided for the low bit rate audience. This way, we may do better than sending audio only to low bandwidth connections. > I don't agree that the buffers must be larger -- the size of the > buffer is determined by the maximum jitter. Sending the streams > separately doesn't (necessarily) make the maximum jitter worse. You > still have to estimate the varying delays and have a buffer of the > same size in the combined case. Well, not exactly. The range of the maximum of two random variables is generally larger than that of each one of them particularly when their distributions are similar. -- M. Reha Civanlar AT&T Research 101 Crawfords Crnr. Rd., 4C520 Holmdel, NJ 07733-3030 Ph: (908) 949 6705 Fax: (908) 949 3697 From rem-conf-request@es.net Wed Jul 17 17:01:22 1996 Received: from mail2.digital.com by osi-west.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 14:00:51 -0700 Received: from zkons1.zko.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA28817; Wed, 17 Jul 1996 13:45:08 -0700 Received: from mmsrv by zkons1.zko.dec.com; (5.65v3.2/1.1.8.2/28Oct95-0953AM) id AA13318; Wed, 17 Jul 1996 16:45:01 -0400 Received: by mmsrv.zko.dec.com; id AA28643; Wed, 17 Jul 1996 16:44:30 -0400 Received: from localhost by mmeapp.zko.dec.com; (5.65v3.2/1.1.8.2/10May96-0945AM) id AA12698; Wed, 17 Jul 1996 16:47:48 -0400 Message-Id: <9607172047.AA12698@mmeapp.zko.dec.com> X-Mailer: exmh version 1.6.7 5/3/96 To: rem-conf@es.net, j300@foto.chemie.unibas.ch Subject: MBONE Tools for Digital Unix release Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Jul 96 16:47:48 -0400 From: "Jeff Walker, Multimedia/Light and Sound Software Group" X-Mts: smtp The T1.0b External Field Test distribution of the MBONE Tools for Digital Unix is available at: ftp://gatekeeper.dec.com/private/MME/mbone_kit_t1.0b.tar.Z Prerequisites for the MBONE Tools for Digital Unix: o Digital Unix 3.2 or 4.0 o Multimedia Services for Digital Unix V2.2 (This is also available at the FTP site above) o Baseboard Audio or MSB for audio receive o J300 or FullVideo capture card for video transmit o The MBONE Tools for Digital Unix T1.0b distribution Please feel free to send mail with questions/comments to jwalker@zko.dec.com or the j300 mailing list: Messages: j300@foto.chemie.unibas.ch Subscribe: majordomo@foto.chemie.unibas.ch Mail content: subscribe j300 ------------- Release Notes ----------------- Digital Unix MBONE Tools Version T1.0b Release Notes VIC The vic video tool will crash when switching in and out of JPEG mode while transmitting. Also, if you change the quality setting while transmitting in JPEG mode, vic crashes. To work around this bug, first stop transmitting before switching to or out of JPEG mode or changing the quality setting. Vic may hang or transmit garbage frames when using JPEG "large" mode. If you have been transmitting in H261 mode and you switch to JPEG, you may get a "pure virtual method called" error message. To workaround this problem, restart vic, and choose JPEG mode immediately, without first transmitting in H261 mode. VAT Vat will exibit audio breakups occasionally when continuously transmitting. If you stop, then start transmitting, the audio will clear up. The LPC encoding gives garbled audio. Use either PCM or GSM encodings. --------------- README.txt ------------------- Digital Unix MBONE Tools README This guide contains information about installing the MBONE tools under Digital Unix. Unpacking and Installing the Distribution The MBONE Tools for Digital Unix are distributed as a single compressed tar file. To unpack the distribution, do the following: uncompress distribution.tar.z (Where distribution is the name of the MBONE distribution file) tar xvf distribution.tar This will create a directory, called mbone, which contains bin and doc directories. The binaries typically go in the /usr/local/bin directory. Copy them as follows: cp mbone/bin/* /usr/local/bin The doc directory contains the documentation for the MBONE package. To view the documentation, use your favorite web browser to open the file: mbone/doc/index.htm Sanity check You can check to see that the Multimedia Services and the hardware that you have installed are functioning correctly by running /usr/bin/mme/alphavcr, and choosing the "Live" mode. Once you have verified that Multimedia Services is functioning correctly, you can try broadcasting an audio and video session using sdr (See the Users Guide for instructions on how to do this.) --------------------------------------------------------------------------- Jeff Walker Digital Equipment Corporation Light And Sound Software Group Multimedia Apps Nashua, NH. jwalker@zko.dec.com USA (603) 881-1033 From rem-conf-request@es.net Wed Jul 17 17:05:27 1996 Received: from mailhost.Ipsilon.COM (actually foo-5-10.Ipsilon.COM) by osi-east.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 14:04:43 -0700 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id OAA19602; Wed, 17 Jul 1996 14:04:41 -0700 Message-Id: <199607172104.OAA19602@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: "M. Reha Civanlar" cc: rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Wed, 17 Jul 1996 13:59:00 EDT." <31ED29E4.33590565@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Jul 1996 14:04:39 -0700 From: Greg Minshall > Well, not exactly. The range of the maximum of two random variables is > generally larger than that of each one of them particularly when their > distributions are similar. This is probably *more* true of two *uncorrelated* random variables? From rem-conf-request@es.net Wed Jul 17 17:57:59 1996 Received: from hogw2.att.com (actually 204.179.186.34) by osi-east.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 11:12:05 -0700 Cc: Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Received: from big.att.com by hoig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id OAA21360; Wed, 17 Jul 1996 14:05:56 -0400 Received: from march (march.info.att.com [135.16.210.57]) by big.att.com (8.7.5/8.7.3) with SMTP id OAA08516; Wed, 17 Jul 1996 14:09:57 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <31ED2C8C.4DAA423A@att.com> Date: Wed, 17 Jul 1996 14:10:20 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b3 (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Karl Auerbach Original-CC: Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Karl Auerbach wrote: > > Your method of combining audio and video into the same packet does not > elminate variations in transit time, and hence those elastic receiver > mechanisms are still necessary. Yes, but in general, they are smaller. > > And you are also assuming that audio processing delay and video processing > delay through the receiving computer are constants, unaffected by the > data content. If they are content dependent, the corresponding SW/HW vendors need to develop the delay equalization techniques for their particular variations. I have several systems for which this delay difference is practically constant. -- M. Reha Civanlar AT&T Research From rem-conf-request@es.net Wed Jul 17 21:50:35 1996 Received: from nautique.epm.ornl.gov (actually nautiquee.epm.ornl.gov) by osi-west.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 16:07:05 -0700 Received: from nautique (lpz@localhost [127.0.0.1]) by nautique.epm.ornl.gov (8.7.4/8.7.3) with SMTP id TAA02097 for ; Wed, 17 Jul 1996 19:07:03 -0400 (EDT) Sender: lpz@nautique.epm.ornl.gov Message-ID: <31ED7216.52BF@nautique.epm.ornl.gov> Date: Wed, 17 Jul 1996 19:07:02 -0400 From: Lawrence Macintyre Organization: Oak Ridge National Laboratory X-Mailer: Mozilla 3.0b4 (X11; I; OSF1 V3.2 alpha) MIME-Version: 1.0 To: rem-conf@es.net Subject: nt and xm tools Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: SDR wants a program called xm for displaying help and nt for broadcasting and viewing text. Where can I obtain these tools? I am assuming that they work on Unix, hopefully on Digital Unix, since that's what I have on my desktop. -- 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 Wed Jul 17 22:11:58 1996 Received: from linus.socs.uts.EDU.AU by osi-west.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 19:11:29 -0700 Received: from kant.socs.uts.EDU.AU (root@kant [138.25.8.74]) by linus.socs.uts.EDU.AU (8.7.5/8.7.3) with ESMTP id MAA26446; Thu, 18 Jul 1996 12:11:20 +1000 (EST) Received: from kant (atanu@localhost [127.0.0.1]) by kant.socs.uts.EDU.AU (8.7.3/8.7.3) with ESMTP id MAA01475; Thu, 18 Jul 1996 12:11:19 +1000 (EST) To: Lawrence Macintyre cc: rem-conf@es.net Subject: Re: (rem-conf:992) nt and xm tools In-reply-to: Your message of "Wed, 17 Jul 1996 19:07:02 -0400." <31ED7216.52BF@nautique.epm.ornl.gov> X-Organisation: School of Computer Science, University of Technology, Sydney. X-Phone: +61 2 9514 2353 X-Fax: +61 2 9514 1807 X-Url: Reply-To: atanu@socs.uts.EDU.AU Date: Thu, 18 Jul 1996 12:11:18 +1000 Message-ID: <1472.837655878@kant> From: Atanu Ghosh >>>>> "Lawrence" == Lawrence Macintyre writes: Lawrence> Hi: SDR wants a program called xm for displaying help Lawrence> and nt for broadcasting and viewing text. Where can I Lawrence> obtain these tools? I am assuming that they work on Lawrence> Unix, hopefully on Digital Unix, since that's what I Lawrence> have on my desktop. -- This is my version of xm. You will probably want to remove the code which looks for Mosaic. There is also a version at , which I think I wrote. Atanu. #!/bin/ksh if [ $# != 1 ] then echo "$0: No arguments" >&2 exit 1 fi # The correct way of specifying a URL is: # # The problem is that the "URL:" needs to be removed as the browsers do # not require it. URL=$(echo $1 | sed -e 's/^URL://') NETSCAPE=netscape pid=$(/usr/bin/ps -u $LOGNAME | grep Mosaic | awk '{print $1}') pid=$(echo $pid | awk '{print $1}') if [ ${pid:-no} = "no" ] then echo No Mosaic running trying netscape $NETSCAPE -remote "openURL($URL)" if [ $? != 0 ] then echo Starting netscape $NETSCAPE $URL & fi exit 0 fi echo goto > /tmp/Mosaic.$pid echo $URL >> /tmp/Mosaic.$pid kill -USR1 $pid exit 0 From rem-conf-request@es.net Wed Jul 17 22:12:16 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 19:11:20 -0700 From: Masataka Ohta Message-Id: <199607180200.KAA15998@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA15998; Thu, 18 Jul 1996 10:59:47 +0859 Subject: Re: "at any one time" and "media types" - clarification needed To: casner@precept.com (Stephen Casner) Date: Thu, 18 Jul 96 10:59:46 JST Cc: civanlar@att.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com In-Reply-To: ; from "Stephen Casner" at Jul 17, 96 12:52 am X-Mailer: ELM [version 2.3 PL11] > > I completely agree that those points are valid for many applications; > > however, there exist an important group of other applications, e.g. > > retrieval of audio/video information referred from an html document, > > which do not need seperate streams. > > Perhaps. Then again, if I am at the end of a 14.4 line and can handle > the audio but not the video, I might appreciate the ability to > separate them. Even if audio and video RTP are not merged, we can have a single unified URL for a combined audio and video sessions, can't we? I prefer merging because it will reduce HOL delay. > > Again, returning to the example above, this approach requires generating > > two sets of carefully synchronized time stamps at the source and > > Actually, the generation of RTP and RTCP timestamps for the case of > playing audio and video from a file is simple because it is all > virtual time. Tracking real capture devices on machines with poor > device drivers and worse excuses for an operating system is much > harder. I think audio and video processes can share a socket. Masataka Ohta From rem-conf-request@es.net Thu Jul 18 00:53:21 1996 Received: from sangam.ncst.ernet.in by osi-west.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 21:52:44 -0700 Received: from saathi.ncst.ernet.in (saathi.ncst.ernet.in [144.16.1.2]) by sangam.ncst.ernet.in (8.6.12/8.6.6) with ESMTP id KAA15944 for ; Thu, 18 Jul 1996 10:26:46 +0530 Received: from localhost (localhost [127.0.0.1]) by saathi.ncst.ernet.in (8.6.8.1/8.6.5) with SMTP id KAA12388 for ; Thu, 18 Jul 1996 10:22:36 +0530 Message-Id: <199607180452.KAA12388@saathi.ncst.ernet.in> To: rem-conf@es.net Subject: unsunscribe Return-receipt-to: satam@saathi.ncst.ernet.in Date: Thu, 18 Jul 1996 10:22:30 +0530 From: "Kirtikumar G. Satam" unsubscribe please unsubscribe me from this list. thanks. From rem-conf-request@es.net Thu Jul 18 02:33:26 1996 Received: from piper.cs.colorado.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 17 Jul 1996 23:32:51 -0700 Received: (from evi@localhost) by piper.cs.colorado.edu (8.7.5/8.7.3) id AAA22913; Thu, 18 Jul 1996 00:32:47 -0600 (MDT) Date: Thu, 18 Jul 1996 00:32:47 -0600 (MDT) From: Evi Nemeth Message-Id: <199607180632.AAA22913@piper.cs.colorado.edu> To: rem-conf@es.net Subject: mbone broadcast, usenix security symposium Cc: ellie@usenix.org, evi@piper.cs.colorado.edu we plan to broadcast the keynote address and selected sessions >from the technical track, the panels, and the invited talks track. the symposium is wednesday july 24 and thursday july 25. more information is available at: http://www.usenix.org/sec96.html#TECHNICAL sessions will be advertised in sdr, audio vat:rtp/dvi4, video vic:h261. the conference is on lunch break during the lbnl summer lecture series broadcast; if there are other conflicts please email evi@usenix.org. -evi evi nemeth, assoc prof computer science dept university of colorado boulder, co 80309-0430 From rem-conf-request@es.net Thu Jul 18 07:37:30 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 04:36:53 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 18 Jul 1996 12:36:39 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Lawrence Macintyre cc: rem-conf@es.net Subject: Re: nt and xm tools In-reply-to: Your message of "Wed, 17 Jul 96 19:07:02 EDT." <31ED7216.52BF@nautique.epm.ornl.gov> Date: Thu, 18 Jul 96 12:36:39 +0100 Message-ID: <12806.837689799@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >SDR wants a program called xm for displaying help and nt for >broadcasting and viewing text. Where can I obtain these tools? I am >assuming that they work on Unix, hopefully on Digital Unix, since that's >what I have on my desktop. xm is just a simple shell script. It's in the sdr master directory: ftp://cs.ucl.ac.uk/mice/sdr/ nt is a shared text editor. Sometime soon I'll rename it nte due to increasing confusion... Not so many people were running the other nt when I first wrote the bulk of nte back in 1994 :-) It's in ftp://cs.ucl.ac.uk/mice/nt/ There are binaries there for SunOS4, Solaris2, Irix and HPUX. The MICE-NSC sites mirror a lot of this software, so for example, if you have problems retrieving nt from UCL, you could try ftp://mice.uio.no/pub/mice-nsc/nt/ Mark From rem-conf-request@es.net Thu Jul 18 07:54:33 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 04:53:39 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 18 Jul 1996 12:52:22 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Masataka Ohta cc: casner@precept.com (Stephen Casner), civanlar@att.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Thu, 18 Jul 96 10:59:46 +0200." <199607180200.KAA15998@necom830.hpcl.titech.ac.jp> Date: Thu, 18 Jul 96 12:52:22 +0100 Message-ID: <12856.837690742@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >> > I completely agree that those points are valid for many applications; >> > however, there exist an important group of other applications, e.g. >> > retrieval of audio/video information referred from an html document, >> > which do not need seperate streams. >> >> Perhaps. Then again, if I am at the end of a 14.4 line and can handle >> the audio but not the video, I might appreciate the ability to >> separate them. > >Even if audio and video RTP are not merged, we can have a single >unified URL for a combined audio and video sessions, can't we? > >I prefer merging because it will reduce HOL delay. Audio and Video are just a subset of media types that might want to be included in a session, whether it's an Mbone session, or on demand >from a server. There are many many other media types ranging from shared editors and whiteboards, to multiple video streams with a single audio stream, to accompanying slides, etc. All of these may require cross-media synchronisation. We must not let out ideas be constrained by legacy technology. Separating audio and video makes sense from so many points of view, and merging them gives you so little gain in such a constrained range of circumstances and is a pain in so many others. Try reading the H.221 spec if you want to see where that path leads. Then imagine trying to do *two* video streams and a synced audio stream and you'll see what I mean. Mark From rem-conf-request@es.net Thu Jul 18 09:29:29 1996 Received: from dau.physics.sunysb.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 06:29:02 -0700 Received: by dau.physics.sunysb.edu; id AA00811; Thu, 18 Jul 1996 09:29:01 -0400 From: Edward Shuryak Message-Id: <9607181329.AA00811@dau.physics.sunysb.edu> Subject: unsubscibe To: rem-conf@ES.net Date: Thu, 18 Jul 1996 09:29:00 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 43 Please unsubscibe me from the list, Thanks From rem-conf-request@es.net Thu Jul 18 11:08:06 1996 Received: from netserv1.NetLiveCom.COM (actually 206.137.237.5) by osi-west.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 08:07:27 -0700 Received: from pc6.netlive (vrysin [206.137.237.16]) by netserv1.NetLiveCom.COM (8.6.12/8.6.9) with SMTP id LAA04994 for ; Thu, 18 Jul 1996 11:06:01 -0400 Message-ID: <31EE52EE.1B68@netlivecom.com> Date: Thu, 18 Jul 1996 11:06:22 -0400 From: Vladislav Rysin Organization: NetLive Communications, Inc. X-Mailer: Mozilla 3.0b5a (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: unsubscibe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please unsubscibe me from the list, Thanks -- Vladislav Rysin E-mail: vrysin@NetLiveCom.com NetLive Communications, Inc. Phone: (212) 343-8568 584 Broadway, Suite 806 Fax: (212) 343-7090 New York, New York 10012 www: WWW.NetLiveCom.COM From rem-conf-request@es.net Thu Jul 18 14:09:06 1996 Received: from deputy.pavilion.co.uk by osi-west.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 11:08:20 -0700 Received: from dialup1-58.pavilion.co.uk (dialup2-13.pavilion.co.uk [194.242.131.141]) by deputy.pavilion.co.uk (8.7/8.7) with SMTP id SAA26071; Thu, 18 Jul 1996 18:20:24 +0100 (BST) Date: Thu, 18 Jul 1996 18:20:24 +0100 (BST) Message-Id: <199607181720.SAA26071@deputy.pavilion.co.uk> X-Sender: izi@mailhost.pavilion.co.uk (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: From: izi@pavilion.co.uk (Izi Muraben) Subject: Telecoms @ the Internet II, 28-31 October, The Intercontinental, Geneva X-Mailer: Telecoms @ the Internet II, 28-31 October 1996, The Intercontinental, Geneva I produce ca. 20 telecoms conferences per year and I seriously do not plan to abuse precious bandwidth with self promotion. I do, however, honestly believe that Telecoms @ the Internet II is THE best conference I'm ever likely to produce and xtremely relevant to your readers. Have a quick browse on http://iir.co.uk/tel-inet and pls let me have your comments. I hope to see you in Geneva. Rgds Izi _______________________________________________ IZI MURABEN izi@pavilion.co.uk CONFERENCES IIR (Institute for International Research) Ltd tel +44 171 9155095 fax +44 171 9155001 PRIVATE tel +44 1273 722986 From rem-conf-request@es.net Thu Jul 18 15:03:03 1996 Received: from cbgw2.att.com by osi-east.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 12:02:19 -0700 Cc: Masataka Ohta , Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Received: from big.att.com by cbig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id PAA14389; Thu, 18 Jul 1996 15:00:56 -0400 Received: from march (march.info.att.com [135.16.210.57]) by big.att.com (8.7.5/8.7.3) with SMTP id PAA13847; Thu, 18 Jul 1996 15:00:54 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <31EE89FD.1B37ADEA@att.com> Date: Thu, 18 Jul 1996 15:01:17 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b3 (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Mark Handley Original-CC: Masataka Ohta , Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed References: <12856.837690742@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark, You are right in that Audio and Video constitute a subset of media types that might be included in a session and there may be several other media types that may share "the same time-base." Why should we forbid defining a bundle of media types sharing "the same time base" as a new payload type if and when applications may use such a PT? This definitely does not prevent other applications to use several media types in the unbundled form. Therefore, I don't think that it will be a source of pain for anyone :) Also, the way H.221 spec is written has very little to do with bundling or not bundling several media types. -- M. Reha Civanlar AT&T Research From rem-conf-request@es.net Thu Jul 18 15:31:25 1996 Received: from jupiter.cc.gettysburg.edu (actually gettysburg.edu) by osi-west.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 12:30:46 -0700 Received: from jupiter2.cc.gettysburg.edu by jupiter.cc.gettysburg.edu with SMTP id AA21325 (5.67b/IDA-1.4.4 for ); Thu, 18 Jul 1996 15:34:30 -0400 Received: by jupiter2.CC.Gettysburg.EDU (5.0/SMI-SVR4-Gburg-Sun-dummy-(cc.gettysburg.edu)-1.1) id AA06374; Thu, 18 Jul 1996 15:34:29 +0500 Date: Thu, 18 Jul 1996 15:22:55 -0400 (EDT) From: "Charles.A.Ross" Subject: Video Card Questions. To: rem-conf@es.net Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1025 Hi, I am mot a subscriber of the list, but I have a question. I was directed this way and figured I'd give it a shot. I am looking for a S-bus video card with the following specs: o Video Compression/Decompression o NTSC video out o MBONE support I have already looked at vigra pix, They have no compression. :( Sun video has no ntsc out, and only cellb compression :P We looked at parallax, and although it LOOKS like they fit the bill... you cant do ntsc out while compressing an image. (The NTSC flickers with every compressed frame) I have meen looking for information on a "SC300 card from Image Manipulation Systems... but I cant get any information from them. We are looking at the Osprey-1000 that is due out next month... and it sounds great, but it dosent exist until next month. Does anyone know of any video cards that I have overlooked? or am I chasing a dream? Thanks... and again please reply to me... I am not a subscriber... thanks -Chuck s253343@gettysburg.edu (717)-337-7105 From rem-conf-request@es.net Thu Jul 18 15:50:14 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 12:49:19 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 18 Jul 1996 20:48:37 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: "M. Reha Civanlar" cc: Masataka Ohta , Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Thu, 18 Jul 96 15:01:17 EDT." <31EE89FD.1B37ADEA@att.com> Date: Thu, 18 Jul 96 20:48:37 +0100 Message-ID: <14526.837719317@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >You are right in that Audio and Video constitute a subset of media types >that might be included in a session and there may be several other media >types that may share "the same time-base." > >Why should we forbid defining a bundle of media types sharing "the same >time base" as a new payload type if and when applications may use such a >PT? This definitely does not prevent other applications to use several >media types in the unbundled form. Therefore, I don't think that it will >be a source of pain for anyone :) It's not whether it's forbidden or not, but whether it's setting an undesirable precedent. If bundling of media types becomes common, it becomes so much harder to do anything interesting because the deployed code-base makes it hard. And you gain so little from bundling anyway. MPEG transport over RTP bundles because the "native" format of such streams is bundled, and unbundling would waste resources when you need to bundle again before passing the stream to your MPEG decode hardware. But that's probably an expection (and not a very robust one at that). Both Precept and UCL have code that does lip-sync with separate RTP streams - it's not that hard, and under overload conditions (hopefully transient ones before we adapt) allows preferential treatment of audio over video in the mrouted (or similar) rate limiters. Given that you need to demux anyway, you seem to gain from demuxing at the lowest level possible - i.e. at the UDP level in this case. Sure bundling would let you use one adaptive playout buffer rather than two, but the constraints it imposes serve to counteract this. For example, someone may have an audio device not tuned correctly to (say) 8KHz (this is very common in practice). If you bundle, you need to do a bunch of fancy correction for each packet at the sender to drop/add samples to make it up to what should have been there for the length of real-time the bundled RTP clock states. Alternatively you surprise the receiver with a different number of samples from what the expect from the timestamps. If you don't bundle, you don't need to fix it at the sender, and you can let the clock drift slightly - the receiver's adaptive playout buffer will absorb it and they can adjust between talk-spurts or during loss, but they only need to do it as required when you start to violate your (fairly loose) lip-sync parameters. This extra work you need to do if you bundle is likely to make bundling significantly *more* expensive and complex than using separate streams in terms of processing requirements. But don't we seem to have the same argument every 18 months on rem-conf... Mark From rem-conf-request@es.net Thu Jul 18 16:55:28 1996 Received: from cbgw1.att.com by osi-east.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 13:54:12 -0700 Cc: Masataka Ohta , Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Received: from big.att.com by cbig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id QAA09921; Thu, 18 Jul 1996 16:49:17 -0400 Received: from march (march.info.att.com [135.16.210.57]) by big.att.com (8.7.5/8.7.3) with SMTP id QAA16759; Thu, 18 Jul 1996 16:53:56 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <31EEA47B.7AAE88DB@att.com> Date: Thu, 18 Jul 1996 16:54:19 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b3 (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Mark Handley Original-CC: Masataka Ohta , Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed References: <14526.837719317@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Handley wrote: > > It's not whether it's forbidden or not, but whether it's setting an > undesirable precedent. If bundling of media types becomes common, it > becomes so much harder to do anything interesting because the deployed > code-base makes it hard. And you gain so little from bundling anyway. > In the last few days, at least three applications have been mentioned that can benefit from bundling and I am sure there are several others. The deployed code tends to implement whatever is feasible for an important application at a given time and it is very hard to prevent this with rules and regulations. > MPEG transport over RTP bundles because the "native" format of such > streams is bundled, and unbundling would waste resources when you need > to bundle again before passing the stream to your MPEG decode > hardware. But that's probably an expection (and not a very robust one > at that). > MPEG does have elementary streams in its native format. Allowing bundled MPEG streams as a valid PT answers a real need of some real applications. What I have been suggesting from the begining is nothing but allowing a light-weight version of this already accepted PT to eliminate the transport layer overhead. > ... Again, allowing to bundle does not prevent unbundled applications to flourish. Several arguments about implementation benefits of bundled MPEG have already been mentioned. > > But don't we seem to have the same argument every 18 months on > rem-conf... I guess this shows the importance of the issue... -- M. Reha Civanlar AT&T Research From rem-conf-request@es.net Thu Jul 18 17:21:12 1996 Received: from nuclear.physics.sunysb.edu by osi-west.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 14:20:27 -0700 Received: by nuclear.physics.sunysb.edu (MX V4.2 VAX) id 18; Thu, 18 Jul 1996 17:20:20 EST Date: Thu, 18 Jul 1996 17:20:19 EST From: verbaarschot@nuclear.physics.sunysb.edu To: rem-conf@ES.net Message-ID: <009A5855.DBA2E85A.18@nuclear.physics.sunysb.edu> Subject: unsubscribe From rem-conf-request@es.net Thu Jul 18 19:39:31 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 16:38:27 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA16097; Thu, 18 Jul 1996 16:38:21 -0700 Date: Thu, 18 Jul 1996 16:38:20 -0700 (PDT) From: Karl Auerbach To: "M. Reha Civanlar" Cc: rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: <31EEA47B.7AAE88DB@att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Again, allowing to bundle does not prevent unbundled applications to > flourish. A proliferation of payload types will impede interoperability. And that's not good for anybody. By-the-way, if types are bundled, one won't be able to make distinct quality-of-service reservations. --karl-- From rem-conf-request@es.net Thu Jul 18 20:12:52 1996 Received: from mail1.digital.com by osi-west.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 17:12:08 -0700 Received: from bigpink.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA28890; Thu, 18 Jul 1996 17:02:06 -0700 Received: by bigpink.pa.dec.com; id AA14117; Thu, 18 Jul 1996 17:02:05 -0700 Message-Id: <9607190002.AA14117@bigpink.pa.dec.com> To: rem-conf@es.net Cc: band@std.org Subject: Catch STD, Mon 22-Jul-1996 5pm PDT Date: Thu, 18 Jul 96 17:02:04 -0700 From: berc@pa.dec.com X-Mts: smtp Severe Tire Damage, the first band to rock the Internet, is back again. Like it or not, STD is warming the MBone to celebrate the premature-release of their eagerly anticipated upcoming CD, "Who Cares". The Mcast, from a secret Silicon Valley hi-tech location, will take place Monday, 22-July-1996 at 5pm PDT, during the US vs. Angola Men's basketball match. Rumours are circulating that STD has nearly completed arrangements for the Who Cares Tour, which from the album release party to the final echos will cover the entire networked world: \both/ the 415 \and/ 408 area codes, plus a trip "over the pond" to 510 for a special performance. Sources within Pacific Bell report that special high-speed circuits are being installed to enable all the action to be Mcast live to the entire universe. As always, details may be found a http://www.std.org. band@std.org From rem-conf-request@es.net Thu Jul 18 21:44:17 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 18:43:31 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA16439; Thu, 18 Jul 1996 18:43:27 -0700 Date: Thu, 18 Jul 1996 18:43:26 -0700 (PDT) From: Stephen Casner To: "M. Reha Civanlar" Cc: rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: <31EEA47B.7AAE88DB@att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > But don't we seem to have the same argument every 18 months on > > rem-conf... > > I guess this shows the importance of the issue... It's pretty clear there are two sides to this issue. I favor unbundled media, but I expect that there will be applications implementing bundled media as well. In some cases, the two will not intend to interoperate with each other, and that nobody will care. In other cases, someone is likely to ask why a particular viewer can't be used to listen to a particular server, and "the market will decide" which approach is better. Even in the case of the MPEG payload formats defined in the draft just approved for publication as a Proposed Standard, both the unbundled elementary streams formats and the bundled transport streams format are defined because differing application requirements are envisioned. But it is not certain which will prove to be successful. It is similarly uncertain whether a lighter-weight bundled format would be successful (the old performance vs. standards compliance question). One point I'd like to make (here I go on my soapbox again) is that it's not practical to define static payload types for the various combinations of media that might be bundled. Therefore, apps using bundled media should define their own dynamic payload types. -- Steve From rem-conf-request@es.net Thu Jul 18 21:59:51 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 18:58:44 -0700 From: Masataka Ohta Message-Id: <199607190148.KAA19248@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA19248; Fri, 19 Jul 1996 10:48:09 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Fri, 19 Jul 96 10:48:08 JST Cc: mohta@necom830.hpcl.titech.ac.jp, casner@precept.com, civanlar@att.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com In-Reply-To: <12856.837690742@cs.ucl.ac.uk>; from "Mark Handley" at Jul 18, 96 12:52 pm X-Mailer: ELM [version 2.3 PL11] > >I prefer merging because it will reduce HOL delay. > > Audio and Video are just a subset of media types that might want to be > included in a session, whether it's an Mbone session, or on demand > from a server. There are many many other media types ranging from > shared editors and whiteboards, to multiple video streams with a single > audio stream, to accompanying slides, etc. All of these may require > cross-media synchronisation. Synchronisation means that all the media share the same clock. Sounds like a very good reason FOR the merger. > We must not let out ideas be constrained > by legacy technology. What, do you think, is legacy technology? The current RTP? > Separating audio and video makes sense from so many points of view, Which one made sense when the current RTP was designed? Masataka Ohta From rem-conf-request@es.net Thu Jul 18 22:03:39 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 19:03:14 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA16479; Thu, 18 Jul 1996 19:03:12 -0700 Date: Thu, 18 Jul 1996 19:03:12 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Pleased to see discussions Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As a side comment, let me say that I am glad to see the messages pointing out places where the RTP specs are insufficiently clear, and other messages exploring different ways in which RTP might be used. It is time for RTP will make the transition from Proposed Standard to Draft Standard, so now is the time to: - fix problems with the spec; - thoroughly test the protocol over scale and functionality to make sure it works as intended. I encourage further comments. These discussions have stimulated a few uninformed folks to send unsubscribe messages to the main mailing list rather than to rem-conf-request@es.net where they belong, but that's the price we pay. -- Steve From rem-conf-request@es.net Thu Jul 18 22:13:39 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 19:12:34 -0700 From: Masataka Ohta Message-Id: <199607190202.LAA19336@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA19336; Fri, 19 Jul 1996 11:02:07 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Fri, 19 Jul 96 11:02:06 JST Cc: civanlar@att.com, mohta@necom830.hpcl.titech.ac.jp, casner@precept.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com In-Reply-To: <14526.837719317@cs.ucl.ac.uk>; from "Mark Handley" at Jul 18, 96 8:48 pm X-Mailer: ELM [version 2.3 PL11] Mark; > For example, someone may have an audio device not tuned correctly to > (say) 8KHz (this is very common in practice). If you bundle, you need > to do a bunch of fancy correction for each packet at the sender to > drop/add samples to make it up to what should have been there for the > length of real-time the bundled RTP clock states. Isn't it better to do the fancy correction once by the sender than multiple times by the receivers? > the > receiver's adaptive playout buffer will absorb it and they can adjust > between talk-spurts or during loss, but they only need to do it as > required when you start to violate your (fairly loose) lip-sync > parameters. For the legacy application of low quality AV conference with some silence period, maybe. What can you do with movies with continuous music? Masataka Ohta From rem-conf-request@es.net Fri Jul 19 00:01:11 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 21:00:30 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14669(2)>; Thu, 18 Jul 1996 21:00:27 PDT Received: by redwing.parc.xerox.com id <3659>; Thu, 18 Jul 1996 21:00:17 PDT Date: Thu, 18 Jul 1996 21:00:16 PDT Sender: Lixia Zhang From: Lixia Zhang To: rem-conf@es.net Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: Your message of Thu, 18 Jul 1996 04:52:22 PDT Message-ID: > Audio and Video are just a subset of media types that might want to be > included in a session, whether it's an Mbone session, or on demand > >From a server. There are many many other media types ranging from > shared editors and whiteboards, to multiple video streams with a single > audio stream, to accompanying slides, etc. All of these may require > cross-media synchronisation. Exactly. If we have N different types of media, with un-bundled approach we only need to define N types, and people can have arbitrary combination of cross-media synchronization by using timestamps. With arbitrary bundling of different media types, how many different media types would have to be defined ?! Furthermore, as Karl pointed out, how could one possibly cope with interopebility issues in that case ?! Lixia PS: "Seems that every 15 years we have to push the reset button to go back to small and simple" --- Anonymous quote From rem-conf-request@es.net Fri Jul 19 00:14:27 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 21:13:55 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <14947(3)>; Thu, 18 Jul 1996 21:13:49 PDT Received: by redwing.parc.xerox.com id <3659>; Thu, 18 Jul 1996 21:13:35 PDT Date: Thu, 18 Jul 1996 21:13:35 PDT Sender: Lixia Zhang From: Lixia Zhang To: rem-conf@es.net Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: Your message of Thu, 18 Jul 1996 13:54:19 PDT Message-ID: > Again, allowing to bundle does not prevent unbundled applications to > flourish. It does affect the interoperability between bundled and unbundled implementations. > > But don't we seem to have the same argument every 18 months on > > rem-conf... > > I guess this shows the importance of the issue... hmm... Not sure if it shows the importance of the issue, or the push for a different design. Lixia From rem-conf-request@es.net Fri Jul 19 02:42:53 1996 Received: from ormail.intel.com by osi-east.es.net with ESnet SMTP (PP); Thu, 18 Jul 1996 23:42:09 -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 XAA28697; Thu, 18 Jul 1996 23:42:07 -0700 (PDT) Received: from pcrsvp.jf.intel.com by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0uh9Fb-000RUxC; Thu, 18 Jul 96 23:41 PDT Message-Id: X-Sender: mbaugher@ibeam.jf.intel.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Jul 1996 23:38:03 -0700 To: Mark Handley From: Mark Baugher Subject: Re: "at any one time" and "media types" - clarification needed Cc: rem-conf@osi-east.es.net At 12:52 PM 7/18/96 +0100, Mark Handley wrote: > >from a server. There are many many other media types ranging from >shared editors and whiteboards, to multiple video streams with a single >audio stream, to accompanying slides, etc. All of these may require >cross-media synchronisation. We must not let out ideas be constrained >by legacy technology. > > Do you really think that slides will frequently need to be synchronized with, say, audio? Some experience with a still-frame/audio service has led me to believe otherwise. Mark From rem-conf-request@es.net Fri Jul 19 03:03:45 1996 Received: from necom830.hpcl.titech.ac.jp by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 00:01:56 -0700 From: Masataka Ohta Message-Id: <199607190701.QAA20287@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA20287; Fri, 19 Jul 1996 16:01:42 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: lixia@parc.xerox.com (Lixia Zhang) Date: Fri, 19 Jul 96 16:01:41 JST Cc: rem-conf@es.net In-Reply-To: ; from "Lixia Zhang" at Jul 18, 96 9:00 pm X-Mailer: ELM [version 2.3 PL11] > > Audio and Video are just a subset of media types that might want to be > > included in a session, whether it's an Mbone session, or on demand > > >From a server. There are many many other media types ranging from > > shared editors and whiteboards, to multiple video streams with a single > > audio stream, to accompanying slides, etc. All of these may require > > cross-media synchronisation. > > Exactly. If we have N different types of media, with un-bundled > approach we only need to define N types, and people can have arbitrary > combination of cross-media synchronization by using timestamps. > With arbitrary bundling of different media types, how many different > media types would have to be defined ?! I'm confused. It seems to me that the number of existing combined merged media types is less than the sum of the numbers of existing separate audio and video types. I'm afraid, even without the merger, 7 bit payload type is not enough to emumerate all the possible realtime applications in the world. > Furthermore, as Karl pointed out, how could one possibly cope with > interopebility issues in that case ?! What is the interoperability issue? How can you know the UDP port number of media? Just as UDP port numbers, media types can be given with OOB information, can't they? Perhaps, we don't need payload type at all. Masataka Ohta From rem-conf-request@es.net Fri Jul 19 03:19:23 1996 Received: from alpha.xerox.com by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 00:18:33 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15012(2)>; Fri, 19 Jul 1996 00:18:26 PDT Received: by redwing.parc.xerox.com id <3659>; Fri, 19 Jul 1996 00:18:09 PDT Date: Fri, 19 Jul 1996 00:18:09 PDT Sender: Lixia Zhang From: Lixia Zhang To: Masataka Ohta Cc: rem-conf@es.net Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: Your message of Fri, 19 Jul 1996 00:01:41 PDT Message-ID: > > Exactly. If we have N different types of media, with un-bundled > > approach we only need to define N types, and people can have arbitrary > > combination of cross-media synchronization by using timestamps. > > > With arbitrary bundling of different media types, how many different > > media types would have to be defined ?! > > I'm confused. Sorry I did not make it clear enough. Let me try again. > It seems to me that the number of existing combined merged media > types is less than the sum of the numbers of existing separate > audio and video types. The number of existing combined media types is small because the resistence to that approach. If we have N media types, possible bundled types may include any subset of N (combinatorial growth of difference combinations of media types) > I'm afraid, even without the merger, 7 bit payload type is not > enough to emumerate all the possible realtime applications in > the world. My guess is that, without merger, we should be fine for a long time to come. > > Furthermore, as Karl pointed out, how could one possibly cope with > > interopebility issues in that case ?! > > What is the interoperability issue? unless everyone implements every type, otherwise you'll see problems like "I implemented PCM, but I cannot hear his audio because it's bundled together with video and I dont support that bundled type". > How can you know the UDP port number of media? what??? you lost me entirely. From rem-conf-request@es.net Fri Jul 19 03:47:45 1996 Received: from necom830.hpcl.titech.ac.jp by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 00:46:41 -0700 From: Masataka Ohta Message-Id: <199607190746.QAA20432@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA20432; Fri, 19 Jul 1996 16:46:39 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: lixia@parc.xerox.com (Lixia Zhang) Date: Fri, 19 Jul 96 16:46:38 JST Cc: mohta@necom830.hpcl.titech.ac.jp, rem-conf@es.net In-Reply-To: ; from "Lixia Zhang" at Jul 19, 96 12:18 am X-Mailer: ELM [version 2.3 PL11] > > I'm confused. > > Sorry I did not make it clear enough. Let me try again. Thank you. > > It seems to me that the number of existing combined merged media > > types is less than the sum of the numbers of existing separate > > audio and video types. > > The number of existing combined media types is small because the > resistence to that approach. I meant existing media types in the world, not pay load types registered to IANA. > If we have N media types, possible bundled types may include any > subset of N (combinatorial growth of difference combinations of media > types) At the same time, if we have N audio-vidual media types, possible number of separated types may be 2*N. > > I'm afraid, even without the merger, 7 bit payload type is not > > enough to emumerate all the possible realtime applications in > > the world. > > My guess is that, without merger, we should be fine for a long time to > come. You are more optimistic than me. But, anyway, with merger, we MAY be fine for a longer time. > > > Furthermore, as Karl pointed out, how could one possibly cope with > > > interopebility issues in that case ?! > > > > What is the interoperability issue? > > unless everyone implements every type, otherwise you'll see problems > like "I implemented PCM, but I cannot hear his audio because it's > bundled together with video and I dont support that bundled type". What is the difference to: I implemented bundled MP2T, but I cannot hear his audio, MPA, because it's separated from video and I dont support that separated type. Regardless of whether you merge or not, unless everyone implements every type, you'll see problems. > > How can you know the UDP port number of media? > > what??? > you lost me entirely. For the operation of RTP, you need session management to know the IP address, port number, contents etc. Then, why you need pre-determined payload type embedded in the data stream? Masataka Ohta From rem-conf-request@es.net Fri Jul 19 04:27:59 1996 Received: from rah.star-gate.com by osi-east.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 01:27:07 -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 BAA00664; Fri, 19 Jul 1996 01:25:29 -0700 (PDT) Message-Id: <199607190825.BAA00664@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Mark Baugher cc: Mark Handley , rem-conf@osi-east.es.net Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Thu, 18 Jul 1996 23:38:03 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jul 1996 01:25:28 -0700 From: Amancio Hasty >From The Desk Of Mark Baugher : > At 12:52 PM 7/18/96 +0100, Mark Handley wrote: > > > >from a server. There are many many other media types ranging from > >shared editors and whiteboards, to multiple video streams with a single > >audio stream, to accompanying slides, etc. All of these may require > >cross-media synchronisation. We must not let out ideas be constrained > >by legacy technology. > > > > > Do you really think that slides will frequently need to be synchronized > with, say, audio? Some experience with a still-frame/audio service > has led me to believe otherwise. > > Mark Darn, and I was thinking that it may be cool to multiplex many objects in an rtp stream and have the application retrieve the "mib" via a separate protocol. For instance, a 3d environment in which a world is fairly well specified hence its objects and a rtp stream could consist of messages directed to the objects or just plain old video/audio 8) Cheers, Amancio From rem-conf-request@es.net Fri Jul 19 06:57:56 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 03:53:20 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jul 1996 11:52:53 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Masataka Ohta cc: civanlar@att.com, casner@precept.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Fri, 19 Jul 96 11:02:06 +0200." <199607190202.LAA19336@necom830.hpcl.titech.ac.jp> Date: Fri, 19 Jul 96 11:52:49 +0100 Message-ID: <16494.837773569@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >> For example, someone may have an audio device not tuned correctly to >> (say) 8KHz (this is very common in practice). If you bundle, you need >> to do a bunch of fancy correction for each packet at the sender to >> drop/add samples to make it up to what should have been there for the >> length of real-time the bundled RTP clock states. > >Isn't it better to do the fancy correction once by the sender than >multiple times by the receivers? Bear in mind that even if the sender's audio clock is accurate, receivers won't be. You still need some receiver correction. >What can you do with movies with continuous music? If there's loss, you can adapt a little there before calling your loss masking function. If there's no loss, you notice you're starting to violate your sync bounds, run a linear estimator to figure out how fast playout point drift is happening, and start to add or drop samples as appropriate (assuming you're using a sample based coding). Note that it may take *many* packets before you start to violate your sync bounds. And that you may need to do this irrespective of whether you bundle or not. Mark From rem-conf-request@es.net Fri Jul 19 07:21:33 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 04:20:54 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jul 1996 12:20:35 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Masataka Ohta cc: lixia@parc.xerox.com (Lixia Zhang), rem-conf@es.net Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Fri, 19 Jul 96 16:46:38 +0200." <199607190746.QAA20432@necom830.hpcl.titech.ac.jp> Date: Fri, 19 Jul 96 12:20:33 +0100 Message-ID: <16573.837775233@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >> If we have N media types, possible bundled types may include any >> subset of N (combinatorial growth of difference combinations of media >> types) > >At the same time, if we have N audio-vidual media types, possible >number of separated types may be 2*N. I'm sorry? If we have N audio encodings and M video encodings, possible number of bundled types is N*M (always assuming only one video stream and no other media are present). Number of unbundled types is N+M. Actually this by itself is not an issue because you could define a generic bundling frame with a single payload type much as we've done for redundant audio. However, there are significant differences between bundling for redundant audio (same clock, no sync probs, etc) and cross-media bundling as the last 50 messages to remconf have testified. >> unless everyone implements every type, otherwise you'll see problems >> like "I implemented PCM, but I cannot hear his audio because it's >> bundled together with video and I dont support that bundled type". > >What is the difference to: > > I implemented bundled MP2T, but I cannot hear his audio, MPA, > because it's separated from video and I dont support that > separated type. The different in the first case if that you didn't implement the bundled type because the bundled type is *defined* as including a format you don't support. Quite possibly the video encoding (and therefore the bundled type) did not even exist at the time your conferencing tool was written, so it couldn't know about the bundled type, but would cope OK in audio only mode if it wasn't bundled. In the latter case, the unbundled type is a payload type you do support and so you'd be dumb not to know the payload type. Of course you don't have these problems with a generic bundling frame... I think bundling is (almost always) a bad idea, but if people must do it, then defining a single bundling frame payload format would at least prevent some of these problems. You still lose lots of flexibility though, and the only real reason I've heard to do it is to save some packet headers, and that reason goes away with deployment of RTP/UDP/IP compression. >Then, why you need pre-determined payload type embedded in the >data stream? Because I can change encoding within a single stream on the fly (for example, to adapt to congestion I change audio encoding from PCM to DVI to GSM). The really interesting research is going in exactly the opposite direction from bundling - layered encoding of a single media encoding across multiple multicast groups. This has real potential to solve many of the heterogeneity problems with large multicast groups... Mark From rem-conf-request@es.net Fri Jul 19 07:47:17 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 04:46:09 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 19 Jul 1996 12:45:04 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Masataka Ohta cc: casner@precept.com, civanlar@att.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Fri, 19 Jul 96 10:48:08 +0200." <199607190148.KAA19248@necom830.hpcl.titech.ac.jp> Date: Fri, 19 Jul 96 12:44:58 +0100 Message-ID: <16629.837776698@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >> >I prefer merging because it will reduce HOL delay. >> >> Audio and Video are just a subset of media types that might want to be >> included in a session, whether it's an Mbone session, or on demand >> from a server. There are many many other media types ranging from >> shared editors and whiteboards, to multiple video streams with a single >> audio stream, to accompanying slides, etc. All of these may require >> cross-media synchronisation. > >Synchronisation means that all the media share the same clock. Synchronisation means we know the relationships between the different clocks at the source and have enough information to be able to restore that relationship at the receiver. Mark From rem-conf-request@es.net Fri Jul 19 08:07:27 1996 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 05:06:52 -0700 Received: from faui42.informatik.uni-erlangen.de (faui42.informatik.uni-erlangen.de [131.188.2.42]) by immd4.informatik.uni-erlangen.de with ESMTP id OAA26516 (8.7.5/7.5b-FAU); Fri, 19 Jul 1996 14:06:44 +0200 (MET DST) From: Toerless Eckert Message-Id: <199607191206.OAA26516@faui40.informatik.uni-erlangen.de> Subject: Re: Video Card Questions. To: Charles.A.Ross@cc.gettysburg.edu (Charles.A.Ross) Date: Fri, 19 Jul 1996 14:06:43 +0200 (MET DST) Cc: rem-conf@es.net In-Reply-To: from "Charles.A.Ross" at Jul 18, 96 03:22:55 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 > From rem-conf-request@es.net Thu Jul 18 21:33 MET 1996 > Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.2.45]) by immd4.informatik.uni-erlangen.de with SMTP > id VAA02265 (8.7.5/7.5b-FAU); for ; Thu, 18 Jul 1996 21:32:59 +0200 (MET DST) > Received: from osi-west.es.net (osi-west.es.net [198.128.3.61]) by uni-erlangen.de with SMTP > id VAA09415 (8.6.12/7.4g-FAU); for ; Thu, 18 Jul 1996 21:32:57 +0200 > Received: from jupiter.cc.gettysburg.edu (actually gettysburg.edu) > by osi-west.es.net with ESnet SMTP (PP); > Thu, 18 Jul 1996 12:30:46 -0700 > Received: from jupiter2.cc.gettysburg.edu by jupiter.cc.gettysburg.edu > with SMTP id AA21325 (5.67b/IDA-1.4.4 for ); > Thu, 18 Jul 1996 15:34:30 -0400 > Received: by jupiter2.CC.Gettysburg.EDU (5.0/SMI-SVR4-Gburg-Sun-dummy-(cc.gettysburg.edu)-1.1) > id AA06374; Thu, 18 Jul 1996 15:34:29 +0500 > Date: Thu, 18 Jul 1996 15:22:55 -0400 (EDT) > From: "Charles.A.Ross" > Subject: Video Card Questions. > To: rem-conf@es.net > Message-Id: > Mime-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Content-Length: 1025 > > > Hi, I am mot a subscriber of the list, but I have a question. I was > directed this way and figured I'd give it a shot. > > I am looking for a S-bus video card with the following specs: > > o Video Compression/Decompression > o NTSC video out > o MBONE support > > I have already looked at vigra pix, They have no compression. :( > Sun video has no ntsc out, and only cellb compression :P > We looked at parallax, and although it LOOKS like they fit the bill... you > cant do ntsc out while compressing an image. (The NTSC flickers with every > compressed frame) The SunVideo does not have decompression, so what. As for compression and decompression you have to state more accurately what your needs are. If you plan to use Mbone with H261 than there is only a slight advantage of the SunVideo over the VigraPix (or the SlicVideo which is similar but superior to the VigraPix). In this case the Parallax Card is slower because there you have to do framegrabbing without DMA from the On Screen Display without utizilizing the JPEG compression/decompression chip on the parallax. The parallax XVideo board can do NTSC/PAL output to video while decompressing video. It just can't do simultaneous (Video-In AND Video-OUT AND compression/ decompression). As long as you need to do only two of these simultaneously you are in luck. As for Video-Out, this probably will be available with the Osprey-1000, once it is available for SBus (for marketing hype see www.mmac.com). Currently available alternatives include using an external digital scan-converter box or simply using a 640x480 resolution display adapter running at 60 Hz and connecting it to a very inexpensive VGA to TV converter. > We are looking at the Osprey-1000 that is due out next month... and it > sounds great, but it dosent exist until next month. Well, as far as i've heart, this may take a bit longer. I too am waiting for these cards for some time now. I still am not quite sure how fast the video-DSP is that they use, but an alternative to the parallax cards is really needed. > Does anyone know of any video cards that I have overlooked? or am I > chasing a dream? I don't know. Depends on your exact requirements. You might as well try to use an external SCSI to D1 Jpeg compression/decompression unit. They connect to fast&wide SCSI and deliver digital D1 component video for NTSC ;-) > Thanks... and again please reply to me... I am not a subscriber... thanks Just subscribe From rem-conf-request@es.net Fri Jul 19 08:55:07 1996 Received: from volitans.MorningStar.Com by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 05:54:20 -0700 Received: from remora.MorningStar.Com by volitans.MorningStar.Com (8.7.1/95070701) id MAA02172; Fri, 19 Jul 1996 12:53:42 GMT Received: by remora.MorningStar.Com (8.7.1/93052901) id MAA23844; Fri, 19 Jul 1996 12:53:39 GMT From: Aydin Edguer Message-Id: <199607191253.MAA23844@remora.MorningStar.Com> Subject: Re: "at any one time" and "media types" - clarification needed To: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 19 Jul 1996 08:53:37 -0400 (EDT) Cc: lixia@parc.xerox.com, mohta@necom830.hpcl.titech.ac.jp, rem-conf@es.net In-Reply-To: <199607190746.QAA20432@necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Jul 19, 96 04:46:38 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > It seems to me that the number of existing combined merged media > > > types is less than the sum of the numbers of existing separate > > > audio and video types. > > > > The number of existing combined media types is small because the > > resistence to that approach. > > I meant existing media types in the world, not pay load types > registered to IANA. Hmmm, please tell us what existing media encodings current exist on data networks outside of the payload types registered with the IANA. Even outside of data networks, in the broadcast world, the audio and video encodings are generally separated (you can buy radios that can tune in the audio portion of TV shows). > > If we have N media types, possible bundled types may include any > > subset of N (combinatorial growth of difference combinations of media > > types) > > At the same time, if we have N audio-vidual media types, possible > number of separated types may be 2*N. That is an incorrect assumption. There are a variety of audio only formats. These formats are standardized and will not go away. There are a variety of video formats. These formats are standardized and will not go away. There are very few "AV" protocols and they are generally composed of two or more existing audio or video formats. There are strong reasons for retaining audio-only or video-only formats. There is no reason for a "phone" or "voice-conferencing" system to include unused video overhead. Thus by your numbers, there will have to be 3*N if you have N audio-visual media types rather than 2*N if you only use separate media streams. This argument about N/2*N/3*N and exhausting a 7-bit field ignores another very strong and immediate (as opposed to future) real issue. That issue is bandwidth utilization. Not everyone has an ISDN line. Not everyone has a T1 line. This is a physical constraint. Either the originating site would have to send out multiple data streams of AV, V, and A for different purposes, consuming 2X or more bandwidth or someone else would have to run some sort of mixing program to generate the separate A and V from the AV. This is generally difficult to arrange. There is also a personal preference constraint. Not everyone wants to see the video for a conference. Why force them to use up bandwidth when it is not needed. Using pruning in the mrouters with separate A and V permits efficient bandwidth utilization and reduce the needed resources that must be reserved. > > > > Furthermore, as Karl pointed out, how could one possibly cope with > > > > interopebility issues in that case ?! > > > > > > What is the interoperability issue? > > > > unless everyone implements every type, otherwise you'll see problems > > like "I implemented PCM, but I cannot hear his audio because it's > > bundled together with video and I dont support that bundled type". > > What is the difference to: > > I implemented bundled MP2T, but I cannot hear his audio, MPA, > because it's separated from video and I dont support that > separated type. > > Regardless of whether you merge or not, unless everyone implements > every type, you'll see problems. If everyone was to decide on a single or small set of AV formats - there would be no more interoperability issue than there would be for A and V. The problem is that if you do not understand "type 107" then you cannot know that it is using the same audio format as "type 63" and thus that you can recover at least some of the information. Instead you have to toss all the information. This is worse than the separate A and V case. By using separate audio and video streams you can also send out multiple audio streams with only a little increase in bandwidth to support multiple listening needs. If you use a single AV format, you would need to unnecessarily duplicate the video in each stream, greatly increasing the need for bandwidth and thus reducing the chances that other encodings will be available for the different consumer needs. From rem-conf-request@es.net Fri Jul 19 09:00:18 1996 Received: from bitscout.com (actually nuplanet.bitscout.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 05:59:31 -0700 Received: from ntplanet (Administrator@localhost) by bitscout.com (1.0 (Berkeley 8.7) Build 331/8.6.10.1) with SMTP id JAA00095; Fri, 19 Jul 1996 09:03:05 -0400 Date: Fri, 19 Jul 1996 09:03:05 -0400 Message-Id: <199607191303.JAA00095@bitscout.com> X-Authentication-Warning: nuplanet.bitscout.com: Host ntplanet.bitscout.com [198.137.170.2] didn't use HELO protocol X-Sender: jsteer@nuplanet.bitscout.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Lixia Zhang , Masataka Ohta From: Jon Steer Subject: Re: "at any one time" and "media types" - clarification needed Cc: rem-conf@es.net At 12:18 AM 7/19/96 PDT, Lixia Zhang wrote: > >> > Furthermore, as Karl pointed out, how could one possibly cope with >> > interopebility issues in that case ?! >> >> What is the interoperability issue? > >unless everyone implements every type, otherwise you'll see problems >like "I implemented PCM, but I cannot hear his audio because it's >bundled together with video and I dont support that bundled type". > The way that it is handled in H.320 (and other protocols that have multiple implementations) is that there is a lowest common denominator implementation that everyone must have to be considered compliant. However, I believe in the multi-cast case that the receiver would be forced to subscribe to a rebroadcast server that does format conversion. jon Jon Steer --- BitScout Software,Inc --- Software Consulting and Products Specialties: Device Drivers, Communications, H.320 Systems Consulting BitScout Software,Inc 40 Berkeley St, Nashua N.H. 03060 phone:(603)889-1185 video: (603)889-1125 fax: (603)-883-9365 E-mail: jsteer@BitScout.com URL: http://www.BitScout.com/ "I got a box!!" a joyous Lucy Steer, age 2.5; receiving her Christmas present before realizing that there was actually something inside. From rem-conf-request@es.net Fri Jul 19 09:33:59 1996 Received: from VNET.IBM.COM by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 06:32:36 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5034; Fri, 19 Jul 96 09:32:35 EDT Received: by RTP (XAGENTA 4.0) id 0931; Fri, 19 Jul 1996 09:32:28 -0400 Received: by vision.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA17567; Fri, 19 Jul 1996 09:33:42 -0400 Message-Id: <9607191333.AA17567@vision.raleigh.ibm.com> X-Mailer: exmh version 1.5.3 12/28/94 To: Mark Handley Cc: rem-conf@es.net Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: Your message of "Fri, 19 Jul 1996 12:20:33 EDT." <16573.837775233@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Jul 1996 09:33:38 +22299904 From: Steve Blake Mark Handley wrote: > Of course you don't have these problems with a generic bundling > frame... I think bundling is (almost always) a bad idea, but if > people must do it, then defining a single bundling frame payload > format would at least prevent some of these problems. You still lose > lots of flexibility though, and the only real reason I've heard to do > it is to save some packet headers, and that reason goes away with > deployment of RTP/UDP/IP compression. I think the other reason, which I believe you mentioned, is for support of hardware codecs (e.g. MPEG-2) that generate bundled, synchronized (common clock) streams natively (e.g., MPEG-2 Transport Streams). /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Steven L. Blake slblake@vnet.ibm.com | | Internetworking Technology (919)254-2030 | | IBM Networking Hardware Division | | "You like the 'Net? You ain't seen nothin' yet!" | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/ From rem-conf-request@es.net Fri Jul 19 09:56:45 1996 Received: from nuclear.physics.sunysb.edu by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 06:56:01 -0700 Received: by nuclear.physics.sunysb.edu (MX V4.2 VAX) id 41; Fri, 19 Jul 1996 09:55:50 EST Date: Fri, 19 Jul 1996 09:55:49 EST From: verbaarschot@nuclear.physics.sunysb.edu To: rem-conf@es.net Message-ID: <009A58E0.ED89356B.41@nuclear.physics.sunysb.edu> Subject: unsubscribe Please, unsubscribe me from this list. Thanks. From rem-conf-request@es.net Fri Jul 19 11:41:15 1996 Received: from poptart.home.net by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 08:40:22 -0700 Received: from huber-lap.biz.home.net ([24.0.8.135]) by poptart.home.net (Netscape Mail Server v1.1) with SMTP id AAA4426 for ; Fri, 19 Jul 1996 08:39:47 -0700 Message-ID: <31EFA7EC.980@home.net> Date: Fri, 19 Jul 1996 08:21:16 -0700 From: huber@home.net (Jeff Huber) Reply-To: huber@home.net Organization: @Home Network X-Mailer: Mozilla 3.0b5aGold (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Unsubscribe me Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please unsubscribe me from rem-conf. Thanks. From rem-conf-request@es.net Fri Jul 19 12:24:37 1996 Received: from ormail.intel.com by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 09:23:02 -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 JAA12809 for ; Fri, 19 Jul 1996 09:23:00 -0700 (PDT) Received: from MGRAFTON.jf.intel.com by ibeam.intel.com with smtp (Smail3.1.28.1 #6) id m0uhIJo-000RUoC; Fri, 19 Jul 96 09:22 PDT Message-Id: Comments: Authenticated sender is From: "Michael A. Grafton" To: rem-conf@es.net Date: Fri, 19 Jul 1996 09:22:58 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: layered encoding Reply-to: mgrafton@ibeam.jf.intel.com Priority: normal X-mailer: Pegasus Mail for Win32 (v2.32a) Mark Handley said: > The really interesting research is going in exactly the opposite > direction from bundling - layered encoding of a single media encoding > across multiple multicast groups. This has real potential to solve > many of the heterogeneity problems with large multicast groups... Can you give some pointers? Thanks! -- Mike From rem-conf-request@es.net Fri Jul 19 13:47:57 1996 Received: from gateway-gw.pictel.com by osi-east.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 10:47:25 -0700 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA11526; Fri, 19 Jul 96 13:46:44 EDT Received: from magicland.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA16709; Fri, 19 Jul 96 13:46:42 EDT Received: from magicland.pictel.com by magicland.pictel.com (SMI-8.6/SMI-SVR4) id NAA07873; Fri, 19 Jul 1996 13:44:39 -0400 Message-Id: <2.2.32.19960719174239.0072f0d4@magicland.pictel.com> X-Sender: webberr@magicland.pictel.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Jul 1996 13:42:39 -0400 To: "M. Reha Civanlar" , Mark Handley From: Bob Webber Subject: Re: "at any one time" and "media types" - clarification needed Cc: Masataka Ohta , Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com At 04:54 PM 7/18/96 -0400, M. Reha Civanlar wrote: >Mark Handley wrote: ... >In the last few days, at least three applications have been mentioned >that can benefit from bundling and I am sure there are several others. >The deployed code tends to implement whatever is feasible for an >important application at a given time and it is very hard to prevent >this with rules and regulations. ... As we see from your participation in this e-mail exchange, standards aren't rules and regulations to prevent doing a thing in a particular way, but a written agreement on how things ought to be done. Nobody can force an implementor not to do things in a non-compliant way, but that implementor also can't claim compliance without convincing other people to change the agreement. Fortunately, it's usually possible to add one's own notions to the agreement through an extension mechanism, which in this case might be the use of a dynamic payload type. But I wonder if you've considered a "quality of service" aspect of the bundled payload you're interested in. Looking at your packet format, it struck me that you might be generating rather large packets and that these packets might well be subject to fragmentation somewhere in the Internet. If so, then the loss rate of your combined video and audio stream will be the packet loss rate multiplied by the ratio of transmitted packet size to fragment size multiplied by the number of video or audio frames per transmitted packet. Furthermore, if you combine media types in a single packet, when you lose that packet you're left with nothing to keep the audience busy: you can't freeze video and go on playing audio, for example. If the overhead of opening two ports is a problem, maybe you should work toward interleaving payload types on a single stream. I think it is also possible that there's an architectural gap between the kind of server-based unicast media your application wants and the multicast-oriented thinking behind RTP/RTCP. Another approach to your application would be to play your multimedia presentation on a multicast address as a continuous loop and "invite" clients to join the next showing of the presentation. On a busy server you could get a pretty amazing efficiency gain with a delay to gather an audience of only a few seconds. By leaving the streams unbundled you'd allow users to get just the media streams they wanted and even have a path to upgrade to better video than MPEG-2 without fixing all the clients at once or adding overhead to the set-up of a playback event. All of this is just my personal, underinformed opinion, by the way, and these opinions are not necessarily shared by my employer, PictureTel Corporation. I'm on vacation even as I write! And in my personal, underinformed opinion, bundling media types is generally a bad idea. Not only does it cause growth of packet size and put more eggs in single baskets, it may lead to undesirable developments such as H.221 packetization. Now, personally I actually have a sneaking fondness for H.221, and I think it is a very clever response to a set of requirements and constraints which were hard to satisfy all at once. Not to mention the difficulty of understanding the requirements and constraints written by the CCITT. But those constraints have nothing to do with working in IP packets, and they resulted in the specification of a bitwise multiplex of media streams that most microprocessors find challenging to pull apart. As with the current MPEG-2 bundled media type, one would only want H.221 packetization so that one could use existing hardware or software to encode and decode the media streams. Adopting an existing multiplex is an exception to current practice, though perhaps sometimes a necessary one. So it would seem that there needs to be a mechanism by which people can try out ideas for bundled media streams to find out if they really are necessary. Perhaps it is possible to accomodate the desire for these bundled media streams with dynamic payload types? Mr Civanlar's application in particular should be able to pass the required information in setting up the playback. From rem-conf-request@es.net Fri Jul 19 14:20:51 1996 Received: from sgigate.sgi.com by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 11:20:08 -0700 Received: from cthulhu.engr.sgi.com by sgigate.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/940406a.SGI) id LAA09040; Fri, 19 Jul 1996 11:18:47 -0700 Received: from pimtest.engr.sgi.com (pimtest.engr.sgi.com [150.166.75.13]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id LAA19979; Fri, 19 Jul 1996 11:18:46 -0700 Received: (from ahelmy@localhost) by pimtest.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id LAA01661; Fri, 19 Jul 1996 11:18:45 -0700 From: Ahmed Helmy Message-Id: <9607191118.ZM1659@pimtest.engr.sgi.com> Date: Fri, 19 Jul 1996 11:18:42 -0700 In-Reply-To: "Michael A. Grafton" "layered encoding" (Jul 19, 9:22am) References: X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: mgrafton@ibeam.jf.intel.com, rem-conf@es.net Subject: Re: layered encoding Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii > Mark Handley said: > > > The really interesting research is going in exactly the opposite > > direction from bundling - layered encoding of a single media encoding > > across multiple multicast groups. This has real potential to solve > > many of the heterogeneity problems with large multicast groups... > > Can you give some pointers? Thanks! There's a Berkeley/LBL paper submitted to SIGCOMM '96 in Stanford about that: Steven McCanne, Van Jacobson, and Martin Vetterli, Receiver-driven Layered Multicast. but I'd have to dig up the http link to that.. ! does anyone have it ?! -A > -- Mike From rem-conf-request@es.net Fri Jul 19 16:09:06 1996 Received: from cbgw3.att.com by osi-east.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 13:08:29 -0700 Cc: Mark Handley , Masataka Ohta , Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Received: from big.att.com by cbig3.att.att.com (SMI-8.6/EMS-1.2 sol2) id QAA18033; Fri, 19 Jul 1996 16:02:51 -0400 Received: from march (march.info.att.com [135.16.210.57]) by big.att.com (8.7.5/8.7.3) with SMTP id QAA18859; Fri, 19 Jul 1996 16:05:45 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <31EFEA97.167EB0E7@att.com> Date: Fri, 19 Jul 1996 16:05:43 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b5aGold (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Bob Webber Original-CC: Mark Handley , Masataka Ohta , Stephen Casner , deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed References: <2.2.32.19960719174239.0072f0d4@magicland.pictel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Webber wrote: > > As we see from your participation in this e-mail exchange, standards aren't > rules and regulations to prevent doing a thing in a particular way, but a > written agreement on how things ought to be done. Nobody can force an > implementor not to do things in a non-compliant way, but that implementor > also can't claim compliance without convincing other people to change the > agreement. I am quite familiar with the definition of standards; however, I fail to understand why MY participation in this e-mail exchange made you see something in particular. If you re-read my message to Mr. Handley, you may notice that the real meaning of my comment is: a standard not accommodating the needs of practical applications is bound to fail. You may see several examples for such standards everywhere. -- M. Reha Civanlar AT&T Research From rem-conf-request@es.net Fri Jul 19 16:48:30 1996 Received: from gatekeeper.sprintlabs.com (actually dmz.sprintlabs.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 13:47:55 -0700 Received: by gatekeeper.sprintlabs.com id AA25980 (5.67b/IDA-1.5 for ); Fri, 19 Jul 1996 13:46:28 -0700 Message-Id: <199607192046.AA25980@gatekeeper.sprintlabs.com> Received: from unknown(199.2.53.28) by gatekeeper.sprintlabs.com via smap (V3.1) id xma025978; Fri, 19 Jul 96 13:46:11 -0700 X-Sender: aollikai@gatekeeper Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 19 Jul 1996 13:47:40 -0700 To: Ahmed Helmy From: ari@sprintlabs.com (Ari Ollikainen) Subject: Re: layered encoding Cc: rem-conf@es.net >> Mark Handley said: >> >> > The really interesting research is going in exactly the opposite >> > direction from bundling - layered encoding of a single media encoding >> > across multiple multicast groups. This has real potential to solve >> > many of the heterogeneity problems with large multicast groups... >> >> Can you give some pointers? Thanks! > >There's a Berkeley/LBL paper submitted to SIGCOMM '96 in Stanford about that: > >Steven McCanne, Van Jacobson, and Martin Vetterli, >Receiver-driven Layered Multicast. > >but I'd have to dig up the http link to that.. ! does anyone have it ?! > It's: ftp://ftp.ee.lbl.gov/papers/mccanne-sigcomm96.ps.gz _/_/ _/_/_/_/ _/ 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 Jul 19 18:24:06 1996 Received: from csla.csl.sri.com by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 15:23:14 -0700 Received: from pansy-atm.csl.sri.com (pansy.csl.sri.com [192.12.33.101]) by csla.csl.sri.com (8.7.3/8.7.3) with ESMTP id PAA28717; Fri, 19 Jul 1996 15:23:06 -0700 (PDT) Received: from localhost.csl.sri.com (localhost.csl.sri.com [127.0.0.1]) by pansy-atm.csl.sri.com (8.7.3/8.7.3) with SMTP id PAA02971; Fri, 19 Jul 1996 15:15:21 -0700 (PDT) Message-Id: <199607192215.PAA02971@pansy-atm.csl.sri.com> X-Authentication-Warning: pansy.csl.sri.com: Host localhost.csl.sri.com [127.0.0.1] didn't use HELO protocol To: mgrafton@ibeam.jf.intel.com cc: rem-conf@es.net Cc: Shacham@csl.sri.com Subject: Re: layered encoding In-reply-to: Your message of Fri, 19 Jul 96 09:22:58 -0000. Date: Fri, 19 Jul 96 15:15:20 -0700 From: Nachum Shacham > > > Mark Handley said: > > > The really interesting research is going in exactly the opposite > > direction from bundling - layered encoding of a single media encoding > > across multiple multicast groups. This has real potential to solve > > many of the heterogeneity problems with large multicast groups... > > Can you give some pointers? Thanks! At SRI we've been working in this area for the last 5 years. See N. Shacham, ``{\it Multipoint Communication by Hierarchically Encoded Data,}'' Proceedings of INFOCOM'92, Florence, Italy, May 1992 for an early discussion on issues and approach. See also http://www.ito.darpa.mil/Summaries95/8990--SRI.html for a description of our current project (joint effort with Sun), which includes heterogeneous multicast of layered video over ATM, IP multicast, and a gateway to interconnect the two signaling domains. Nachum ====================================================================== Nachum Shacham voice: (415) 859-5710 Computer Science Laboratory (EL252) fax: (415) 859-2844 SRI International email: shacham@csl.sri.com 333 Ravenswood Ave Menlo Park, CA 94025 ====================================================================== From rem-conf-request@es.net Fri Jul 19 22:28:59 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 19 Jul 1996 19:28:23 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA19474; Fri, 19 Jul 1996 19:28:20 -0700 Date: Fri, 19 Jul 1996 19:28:18 -0700 (PDT) From: Stephen Casner To: Bob Webber Cc: rem-conf@es.net Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: <2.2.32.19960719174239.0072f0d4@magicland.pictel.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > If the overhead of opening two ports is a problem, maybe you should > work toward interleaving payload types on a single stream. I consider this to be a particularly bad idea. I'd rather see a bundled format defined. > I think it is also possible that there's an architectural gap between the > kind of server-based unicast media your application wants and the > multicast-oriented thinking behind RTP/RTCP. RTP should work well for unicast also, but I agree that one should consider ways to use multicast to reduce the load imposed by multiple unicast VODs. > So it would seem that there needs to be a mechanism by which people can try > out ideas for bundled media streams to find out if they really are > necessary. Perhaps it is possible to accomodate the desire for these > bundled media streams with dynamic payload types? This is the position I've been trying to promote, too. -- Steve From rem-conf-request@es.net Sun Jul 21 04:31:51 1996 Received: from VNET.IBM.COM by osi-east.es.net with ESnet SMTP (PP); Sun, 21 Jul 1996 01:31:00 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6461; Sun, 21 Jul 96 04:30:54 EDT Date: Sun, 21 Jul 96 11:24:25 IST From: Scott Petrack To: rem-conf@osi-east.es.net Subject: multiplexing, interleaving, interchanging etc. Does the following summarize the orthodox position about interleaving, multiplexing, and interchanging? ("orthodox" = intent of the RFC's creators ;-)) 0. "Media types" are a set of tags which are used to group payload types which are considered "interchangeable." Simple examples of media types are "audio," "video", and "AV". Each payload type belongs to exactly one media type. The mapping of payload types to media types is defined in the profile. (and/or perhaps by some dynamic non-RTP means.) 1. Sending packets of two (or more) different media types in the same session should not be done. 2. Multiplexing two (or more) streams of the same media type via multiple payload types should not be done. 3. Thou shalt be reasonable w.r.t. other kinds of multiplexing, interleaving, and encoding switching. Rule 1 disallows "multiplexing," "interleaving," and "switching" encodings of different media types. Even if you did the multiplexing by SSRC and payload type, you shouldn't send two media types in one session. Rule 2 disallows only "multiplexing" and "interleaving" via multiple payload types. A particular profile may define some precise examples of "unreasonableness," which will then be disallowed by rule 3. One could imagine a profile defining an "MPEG" media type which would consist of a bytestream which has MPEG audio-only, video-only, or audio-video mixed in a system layer. These might get separate payload types within this profile. An application receiving this session would know that it might get "any kind of MPEG." Then the above principles would rule out sending other audio, video, or audio-video data. For an application running under such a profile it would be reasonable to switch from MPEG audio to MPEG video within one session. The key thing about media types is the rule that each payload type belonging to exactly one media type. This precludes doing something like starting an GSM audio stream, switching to an MPEG audio stream, then switching to an MPEG-encoded system layer stream which has only audio packets (since it has type "audio" *and* type "AV") then switching to an AV stream which has MPEG-encoded system Audio+Video, and then switching to pure video. Rule 0 would say that a stream can't be both "audio" and "AV". My goal is not to be anal, but just to get a simple set of principles that I can remember, so that I can really see what the originators of RTP had in mind. Scott From rem-conf-request@es.net Sun Jul 21 06:16:55 1996 Received: from mail.Germany.EU.net by osi-west.es.net with ESnet SMTP (PP); Sun, 21 Jul 1996 03:15:47 -0700 Received: by mail.Germany.EU.net with SMTP (5.59:21/EUnetD-2.5.4.c) via EUnet id MAA27791; Sun, 21 Jul 1996 12:15:38 +0200 Message-ID: <31F2834E.2A1E@vcs.n.eunet.de> Date: Sun, 21 Jul 1996 12:21:50 -0700 From: "Dr. Michael Gilge" Organization: VCS Video Communication Systems X-Mailer: Mozilla 2.01 (Win16; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Unsubscribe References: <009A58E0.ED89356B.41@nuclear.physics.sunysb.edu> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello, please, unsubscribe me from this list. My account names are: mgilge@vcs.n.eunet.de dtvf_gil@pki-nbg.philips.de Thanks, Michael -- Dr. Michael Gilge Tel. : (0911) 205 3793 VCS Video Communication Systems GmbH Fax : (0911) 209 614 Mittlere Kreuzgasse 11 email: mgilge@vcs.n.eunet.de 90403 N=FCrnberg H.320: (0911) 205 3795 From rem-conf-request@es.net Sun Jul 21 08:20:59 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Sun, 21 Jul 1996 05:20:07 -0700 Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 21 Jul 1996 13:15:57 +0100 To: ari@sprintlabs.com (Ari Ollikainen) cc: Ahmed Helmy , rem-conf@es.net Subject: Re: layered encoding In-reply-to: Your message of "Fri, 19 Jul 1996 13:47:40 PDT." <199607192046.AA25980@gatekeeper.sprintlabs.com> Date: Sun, 21 Jul 1996 13:15:56 +0100 Message-ID: <5818.837951356@cs.ucl.ac.uk> From: Jon Crowcroft >>Steven McCanne, Van Jacobson, and Martin Vetterli, >>Receiver-driven Layered Multicast. see also http://www.acm.org/sigcomm/sigcomm96/ for all the procedings (and papers) please dont let this stop anyone coming to the conference, since that is where next years work gets discussed! jon From rem-conf-request@es.net Sun Jul 21 23:05:03 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Sun, 21 Jul 1996 20:04:20 -0700 From: Masataka Ohta Message-Id: <199607220303.MAA04227@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA04227; Mon, 22 Jul 1996 12:03:11 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Mon, 22 Jul 96 12:03:10 JST Cc: mohta@necom830.hpcl.titech.ac.jp, civanlar@att.com, casner@precept.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com In-Reply-To: <16494.837773569@cs.ucl.ac.uk>; from "Mark Handley" at Jul 19, 96 11:52 am X-Mailer: ELM [version 2.3 PL11] > >> For example, someone may have an audio device not tuned correctly to > >> (say) 8KHz (this is very common in practice). If you bundle, you need > >> to do a bunch of fancy correction for each packet at the sender to > >> drop/add samples to make it up to what should have been there for the > >> length of real-time the bundled RTP clock states. > > > >Isn't it better to do the fancy correction once by the sender than > >multiple times by the receivers? > > Bear in mind that even if the sender's audio clock is accurate, > receivers won't be. You still need some receiver correction. Receivers' clocks should be synchronized to the sender's and no drop/add of data is necessary. Masataka Ohta From rem-conf-request@es.net Sun Jul 21 23:12:39 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Sun, 21 Jul 1996 20:12:14 -0700 From: Masataka Ohta Message-Id: <199607220312.MAA04263@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA04263; Mon, 22 Jul 1996 12:11:45 +0859 Subject: Re: "at any one time" and "media types" - clarification needed To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Mon, 22 Jul 96 12:11:45 JST Cc: mohta@necom830.hpcl.titech.ac.jp, casner@precept.com, civanlar@att.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com In-Reply-To: <16629.837776698@cs.ucl.ac.uk>; from "Mark Handley" at Jul 19, 96 12:44 pm X-Mailer: ELM [version 2.3 PL11] > >> Audio and Video are just a subset of media types that might want to be > >> included in a session, whether it's an Mbone session, or on demand > >> from a server. There are many many other media types ranging from > >> shared editors and whiteboards, to multiple video streams with a single > >> audio stream, to accompanying slides, etc. All of these may require > >> cross-media synchronisation. > > > >Synchronisation means that all the media share the same clock. > > Synchronisation means we know the relationships between the different > clocks at the source and have enough information to be able to restore > that relationship at the receiver. With the merged encoding, the restoration of cross-media synchronization is not necessary. So, how can you conclude that not merging is the way to go? Masataka Ohta From rem-conf-request@es.net Sun Jul 21 23:34:26 1996 Received: from necom830.hpcl.titech.ac.jp by osi-west.es.net with ESnet SMTP (PP); Sun, 21 Jul 1996 20:33:52 -0700 From: Masataka Ohta Message-Id: <199607220332.MAA04316@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA04316; Mon, 22 Jul 1996 12:32:16 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: edguer@MorningStar.Com (Aydin Edguer) Date: Mon, 22 Jul 96 12:32:15 JST Cc: mohta@necom830.hpcl.titech.ac.jp, lixia@parc.xerox.com, rem-conf@es.net In-Reply-To: <199607191253.MAA23844@remora.MorningStar.Com>; from "Aydin Edguer" at Jul 19, 96 8:53 am X-Mailer: ELM [version 2.3 PL11] > > > > It seems to me that the number of existing combined merged media > > > > types is less than the sum of the numbers of existing separate > > > > audio and video types. > Hmmm, please tell us what existing media encodings current exist on > data networks outside of the payload types registered with the IANA. Why, do you think, I must show there are a lot of combined media types? For the merger, the fewer, the better. > > At the same time, if we have N audio-vidual media types, possible > > number of separated types may be 2*N. > > That is an incorrect assumption. There are a variety of audio > only formats. These formats are standardized and will not go away. > There are a variety of video formats. These formats are standardized > and will not go away. There are very few "AV" protocols Thank you. > If everyone was to decide on a single or small set of AV formats - there > would be no more interoperability issue than there would be for A and V. > The problem is that if you do not understand "type 107" then you cannot > know that it is using the same audio format as "type 63" and thus that > you can recover at least some of the information. Instead you have to > toss all the information. This is worse than the separate A and V case. To make your point clearer, you need different payload types of audio for different channels of monoral, stereo, 3ch, 4ch, 5ch, 6ch, ..., audio to recover at least some of the information. But, as you can see, there are 12 types of monoral audio types already registered to IANA in RFC 1890. Do you think 128 is enough number of payload types? > By using separate audio and video streams you can also send out multiple > audio streams with only a little increase in bandwidth to support multiple > listening needs. That's a waste of bandwidth. > If you use a single AV format, you would need to > unnecessarily duplicate the video in each stream, greatly increasing > the need for bandwidth and thus reducing the chances that other encodings > will be available for the different consumer needs. What's wrong with AV format with layered encoding? Masataka Ohta From rem-conf-request@es.net Sun Jul 21 23:39:22 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Sun, 21 Jul 1996 20:38:58 -0700 From: Masataka Ohta Message-Id: <199607220338.MAA04361@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA04361; Mon, 22 Jul 1996 12:38:33 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 22 Jul 96 12:38:32 JST Cc: M.Handley@cs.ucl.ac.uk, mohta@necom830.hpcl.titech.ac.jp, casner@precept.com, civanlar@att.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com In-Reply-To: <199607220312.MAA04263@necom830.hpcl.titech.ac.jp>; from "Masataka Ohta" at Jul 22, 96 12:11 pm X-Mailer: ELM [version 2.3 PL11] This is repost with blank lines, because rem-conf processor rejects articles with short quoting and even shorter comments, a bogus feature. > >> Audio and Video are just a subset of media types that might want to be > >> included in a session, whether it's an Mbone session, or on demand > >> from a server. There are many many other media types ranging from > >> shared editors and whiteboards, to multiple video streams with a single > >> audio stream, to accompanying slides, etc. All of these may require > >> cross-media synchronisation. > > > >Synchronisation means that all the media share the same clock. > > Synchronisation means we know the relationships between the different > clocks at the source and have enough information to be able to restore > that relationship at the receiver. With the merged encoding, the restoration of cross-media synchronization is not necessary. So, how can you conclude that not merging is the way to go? Masataka Ohta From rem-conf-request@es.net Mon Jul 22 00:58:04 1996 Received: from trout.nosc.mil by osi-west.es.net with ESnet SMTP (PP); Sun, 21 Jul 1996 21:57:31 -0700 Received: from cod.nosc.mil by trout.nosc.mil (4.1/SMI-4.1) id AA02281; Sun, 21 Jul 96 21:57:30 PDT Received: from catbert.nosc.mil by cod.nosc.mil (4.1/SMI-4.1) id AA10701; Sun, 21 Jul 96 21:57:28 PDT Date: Sun, 21 Jul 1996 21:56:45 -0700 (PDT) From: "Mark T. Ganzer" To: Toerless Eckert Cc: "Charles.A.Ross" , rem-conf@es.net Subject: Re: Video Card Questions. In-Reply-To: <199607191206.OAA26516@faui40.informatik.uni-erlangen.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 19 Jul 1996, Toerless Eckert wrote: > The SunVideo does not have decompression, so what. As for compression and > decompression you have to state more accurately what your needs are. > If you plan to use Mbone with H261 than there is only a slight advantage of > the SunVideo over the VigraPix (or the SlicVideo which is similar but > superior to the VigraPix). In this case the Parallax Card is slower because > there you have to do framegrabbing without DMA from the On Screen Display > without utizilizing the JPEG compression/decompression chip on the parallax. Actually, if you enable the JPEG->H261 transcoder option in Vic ("Use JPEG for H261" under Menu->Transmit->Options), the JPEG compression chip on the Parallax card is enabled. However this is only an option if you are running the Parallax card with pre-2.0 drivers. The Vic executables on the LBL server were compiled with pre-2.0 Parallax libraries. Parallax changed the JPEG encoding routines in their 2.0 drivers, and this results in very low contrast images being transmitted. I have had a few other non-Mbone related problems with the Parallax PowerVideo card I was using (CDE on Solaris 2.5 wouldn't run, etc). Also, the Parallax REQUIRES you to keep a "capture" window of what you are transmitting open. This can take up an annoying amount of screen real-estate, which is often already tight when you have vic, vat, and wb running at the same time. ON the plus side, the PowerVideo also provides you with a 24-bit color frame-buffer if you machine doesn't already have it (no more problems with dithering and running out of colors on an 8-bit display). 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 Mon Jul 22 02:50:46 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Sun, 21 Jul 1996 23:50:14 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA22562; Sun, 21 Jul 1996 23:50:12 -0700 Date: Sun, 21 Jul 1996 23:50:12 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Montreal AVT minutes Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Folks, Here are my minutes for the AVT meeting in Montreal at the end of June. These minutes are a week late, but I expect there will be an opportunity nonetheless to make corrections. For those who attended, please let me know if I have omitted something important, attibuted some statement incorrectly, or inaccurately remembered what transpired. -- Steve Minutes of the Audio/Video Transport Working Group Reported by Steve Casner 1. Working group status The primary output of the AVT working group is the Real-time Transport Protocol, which was published in January 1996 as a Proposed Standard RFC1889 along with the companion RTP profile for audio/video conferencing RFC1890. Progression to Draft Standard is discussed below. In addition, there are four Internet-Drafts awaiting publication which define the RTP payload formats for H.261, JPEG, MPEG and CellB video encodings. These drafts have just been passed by the IESG and will be sent to the RFC Editor for publication right after the IETF meeting. Work continues on the definition of additional proposed payload formats, one of which was presented at this meeting. AVT met for two sessions at this IETF. The first session was dedicated to the major topic, header compression for RTP applications running over low-speed lines. A portion of the second session was given over to presentation of a signaling protocol that is more relevant to the MMUSIC area but did not fit in that group's schedule. The miscellaneous RTP topics comprising the remainder of the session are detailed in later sections of this report. 2. Compression of RTP headers In a presentation to the AVT working group at the March 1996 IETF meeting, Scott Petrack explained the need for compression of RTP headers in order to allow low data rate applications such as Internet telephony over 28.8 kb/s modems to use RTP. He outlined some techniques that could be used between cooperating endpoints to reduce the size of the RTP header. However, at that meeting and in subsequent discussions, some have argued that compression should instead be applied at the endpoints of slow links so that the IP and UDP headers may also be compressed. 2.1. Hop-by-hop compression At this meeting, Steve Casner presented a proposal for hop-by-hop compression of IP/UDP/RTP headers developed with Van Jacobson and derived from RFC1144 TCP/IP compression. The basic idea comes from the observation that although there are several fields that vary from packet to packet in RTP, the differences are often constant from one packet to the next. For example, audio packets are often of constant duration, so the timestamp changes by a constant amount. For this case, all that must be communicated is an indication that the second-order difference is zero along with a small sequence number to detect packet loss between the compressor and decompressor. Additional bits are used to allow indication that individual fields have changed by an unexpected amount, in which case only the differences for those fields are appended in a compact encoding, rather than requiring the full uncompressed header be transmitted. This scheme compresses the 40 bytes of IP, UDP and RTP headers down to 2-4 bytes for most packets. The proposal was well accepted by the group. One question was whether this scheme is too dependent upon characteristics of audio and video, but the delta coding of sequence and timestamp fields seems generally applicable. Timestamps such as those in MPEG which are not monotonic can be handled because the delta is signed. Further details were given in a draft-casner-jacobson-crtp-00.txt, which was sent to the working group mailing list (rem-conf@es.net) but was somehow lost and failed to be officially posted. This draft is to be updated to include changes decided since it was sent to the list as well as completion of the protocol details left for finalization during initial implementation. The group agreed that this proposal should be taken as an AVT work item, so the updated draft will be titled draft-ietf-avt-crtp-00.txt. 2.2. Need for an interim solution The working group agreed that the hop-by-hop compression scheme should be completed and implemented as soon as possible. However, since publication, implementation and deployment of this scheme into the Internet infrastructure will take 12-18 months, vendors of Internet telephones and other applications had asked that AVT define an interim compression scheme that could be implemented right away in the endpoint applications alone. The tradeoff is that the compression gain is marginal (12 byte compress to 2 or 3) compared to compressing IP and UDP headers as well. Furthermore, the ability to measure packet loss and accurately reconstruct media timing would be reduced compared to the full RTP. As a strawman idea, Steve Casner presented a straightforward modification of the hop-by-hop scheme for use in compressing RTP alone end-to-end, but pointed out that the performance was likely to be unacceptable due to the higher loss rate and longer round-trip delay. Instead, Van Jacobson proposes that RTP be sent over TCP to take advantage of the installed base of RFC1144 TCP/IP compression. The RTP header could be compressed to an average of 1 byte if carried over TCP. The problem is that until congestion control algorithms such as Random Early Drop (RED) are deployed in routers, UDP traffic will displace TCP traffic, so vendors may be reluctant to use this TCP solution. Deployment of RED is expected within a few months. Scott Petrack presented some issues in defining an end-to-end protocol and making the transition from that interim solution to the complete solution. Since the end-to-end delay and loss rate are much higher than on a single link, the 4-bit sequence number of the hop-by-hop scheme would not be sufficient, but adding 8 more might be, assuming that the application is willing to proceed even when some packets are lost. An alternative would be to send RTP directly over IP to save the 8 bytes of UDP. However, this does not provide any means for multiplexing RTP and RTCP unless two IP protocol types were allocated (none have been). Scott noted that implementation of the IP/UDP/RTP compression scheme is elective for each applicable link and argued that applications would not be willing to transmit uncompressed RTP packets unless they could get a guarantee that compression was available on all slow links along the path. Carsten Bormann noted that an RSVP bandwidth guarantee provides sufficient information given traffic control that considers header compression in determining the available bandwidth. This is part of his ISSLOW proposal in the ISSLL working group. If a more relaxed guarantee of compression availability separate from bandwidth availability is required, that should be defined as an additional type of service to be provided via RSVP rather than having AVT define a new mechanism specific to this problem. Greg Minshall suggested that applications could measure the performance of the network to decide if sufficient bandwidth was available. Applications might start off using a lower-bandwidth encoding with full RTP for interoperability, but switch to a higher quality encoding if hop-by-hop compression were available or when communicating with another copy of the same program such that a proprietary protocol could be used in place of RTP. There was substantial discussion centering around practicality and timing of an interim solution. Carsten Bormann claimed that Internet Telephony would not really be effective without the latency reduction mechanisms underway in ISSLOW and V.80 modems expected in 1997. Francois Menard noted that even with agreement on the use of RTP (with or without compression), interoperation would not be possible without agreement on voice coding and call control protocols as well, which will take time. If the purpose of the interim solution is to get vendors to switch >from proprietary protocols to RTP, then that goal will not have been achieved by defining a new, reduced version of RTP. Bob Webber felt that this would tend to cause confusion by presenting multiple solutions to vendors. Scott Petrack pointed out that suggesting a compressed form of RTP over compressed TCP could cause the same confusion, and that carrying full RTP on compressed TCP might therefore be preferable as an interim solution. Considering that the gain of compressing RTP alone would be relatively small and that it could not be standardized in the necessary timeframe, the prevalent position was that AVT should not define an interim solution. The consensus, supported by a straw poll of the meeting participants, was to move as quickly as possible with the complete solution of IP/UDP/RTP compression and to try to give the industry confidence that this solution will be put in place and will solve the problem. 3. Proposed new RTP payload formats In the second session, Walid Dabbous and Mark Handley presented the redundant audio encoding technique and payload format developed by UCL and INRIA. Walid graphed the results of packet loss studies showing that most packet losses are less than three packets in length, with single-packet losses predominating. Therefore, forward error correction via redundant audio appended to later packets can be effective, as demonstrated by intelligibility tests. The penalty is increased end-to-end delay since the receiver must allow time for the later packets carrying the redundant audio to arrive. Van Jacobson observed that the results of this study might be biased by the location of the test sites. Many paths on the MBone have shown a predominant loss pattern of 500 ms outages occurring at 30, 60 or 90 second intervals coincident with the routing updates in some routers. This would require the spacing between the original and redundant audio data to be increased beyond 3 or 4 packets. Mark Handley described the payload format used for redundant audio as defined in draft-perkins-rtp-redundancy-00.txt. This payload format is to be indicated by a single payload type of its own in the RTP header. Then, in the payload section of the packet, a separate block header is included for each encoding (original data and redundant encodings of earlier data). The block header includes the payload type of the individual block, the length of the block, and the offset of the timestamp for that block relative to the timestamp in the main RTP header. The original data occurs last and its block header includes only the payload type. The length is implied and may be greater than would fit in the 8-bit length field of the block header. No timestamp offset is needed since the RTP timestamp is used directly. Per the draft, the data for each redundant encoding follows immediately after its block header. Van Jacobson suggested appending the redundant encodings after the original data so that the first part of the packet would be in the same form as a packet without redundant encodings. However, that would still require parsing from the end to determine the length of the original data unless the redundant information was all included within a padding field as suggested by Henning Schulzrinne on the mailing list sometime earlier. Philip Lantz suggested that all the block headers be collected at the beginning of the payload section to simplify parsing; Mark Handley plans to make this modification. It was also suggested that the payload format could be generalized to allow multiple data types (such as audio and video) in a single packet, but there are two problems with that suggestion: the small length field in the block header depends upon the fact that compact encodings are used for redundant audio, and using a timestamp offset would not work for timestamps that are unrelated (as is the case for most RTP audio and video encodings). There was no presentation on the draft H.263 video payload format since there have been no significant changes. Presentation of a payload format for G.723 audio was anticipated, but was not ready yet. Another new submission is a proposal by Neil Harris to develop a profile for using RTP in professional audio and video production. Steve Casner put up an overview slide, but there was no presentation at this meeting since the author could not attend. However, working group participants are encouraged to read the draft which is available as draft-harris-rtp-pro-av-00.txt. 4. Progressing RTP to Draft Standard Sufficient time has elapsed so that the RTP spec may now be submitted for elevation from Proposed to Draft Standard status. Steve Casner brought up a few outstanding minor issues that must be addressed as part of this process. A wording change will be made to allow separate destination port numbers to be used for unicast RTP sessions, along with additional "rule changes" proposed by Michael Speer and Steve McCanne to support layered encoding schemes on multiple parallel RTP sessions. An update to the description of the SSRC loop/collision detection algorithm is needed to remove the restriction that the same source port be shared between the RTP and RTCP packets in a session. This is a simple change. However, the algorithm has not had sufficient operational experience in either its current form or with the proposed change. Assistance from implementers is solicited in testing the loss/collision detection algorithm in particular, but also in documenting overall interoperation of multiple independent RTP implementations as is required for progression to the Draft Standard stage. One collision detection issue posed by Karl Auerbach is the "hidden terminal" problem: two colliding sources A and B may not be able to hear each other due to multicast scope limits, but a third host C in between might be able to hear both. The use of network source addresses in the algorithm should allow C to distinguish the two sources and listen to only one. C could also intentionally cause a collision in both directions to induce A and B to change SSRCs. Since there will be edits to the RTP spec in progressing to Draft Standard, it will be necessary to issue the spec again as an updated Internet-Draft to allow comment on the changes. That draft will then be submitted for elevation. 5. Additions to RTCP A portion of the session was given over to an MMUSIC topic that did not fit into that group's schedule. Scott Petrack presented his proposal for a new Simple Internet Signaling Protocol to set up and control RTP sessions. SISP is based on extensions to RTCP to take advantage of the communication path that RTCP provides and save bandwidth by utilizing the source description (SDES) information already transmitted rather than repeating it via another channel. The extensions to RTCP include a new RDES (receiver description) packet type to identify the intended callee, a new RCAP packet type to negotiate capabilities, and a new CP (call progress) item in the SDES packet to indicate "Ringing", "Busy", etc. The RDES packet would be sent to a well-known port, separate from the RTP streams, to initiate the setup. There was substantial discussion of the overlap of this proposal with other protocols under development in MMUSIC (SIP, SCIP and SCCP). Another suggestion was that the subset of Q.931 used in H.323 conferencing would serve the same purpose. Others expressed concern that only providing separate control for each medium misses a user requirement to be able to control some aspects of the multimedia session all at once. Greg Minshall expressed concern that the RCAP function would not be adaptable to new signaling needs that were likely to arise. In short, there was not much support for SISP in its current form. However, the SISP proposal does point out the need for control functions during the course of a session which SIP, for example, does not address. A similar need arises for VCR-like controls when using RTP for video-on-demand. Steve Casner presented a slide on the use of RTCP for VCR controls based on a suggestion from Larry Rowe. In a later MMUSIC session and an after-hours BOF led by Jeff Smith, a new line of discussion was started to consider control functions during a session for purposes such as call control as contained in SISP as well as recording, playback, and other functions. This discussion will continue on the MMUSIC mailing list (confctrl@isi.edu). 6. Miscellaneous issues / logistics The AVT meeting ended with only a couple of minutes available to introduce a few miscellaneous issues but not discuss them: should the working group define an API and a MIB for RTP? The MIB may be a requirement for RTP as a standards-track protocol, but there has not been a strong need for it because RTP monitoring is provided via RTCP. Since there is continuing work to be done, and because the working group has reached the end of the existing charter, the charter must be revised. The chairman takes this task. New work includes: - Finishing work on new payload formats - Possibly adding variable reliability to RTP - Managing the standards track transitions The group agreed to address these issues on the mailing list and to meet again at the December IETF in San Jose. From rem-conf-request@es.net Mon Jul 22 04:40:09 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 01:39:24 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Jul 1996 09:38:22 +0100 To: Masataka Ohta cc: M.Handley@cs.ucl.ac.uk (Mark Handley), casner@precept.com, civanlar@att.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Mon, 22 Jul 1996 12:11:45 +0200." <199607220312.MAA04263@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Jul 1996 09:38:19 +0100 Message-ID: <769.838024699@cs.ucl.ac.uk> From: Jon Crowcroft >With the merged encoding, the restoration of cross-media synchronization >is not necessary. >So, how can you conclude that not merging is the way to go? 1/ different sources 2/ different accuracy soruces 3/ different accuracy sources for different media fro msame source machine 4/ hetergeity support (for differnece i nsink clock accuracy jon From rem-conf-request@es.net Mon Jul 22 04:40:30 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 01:39:32 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Jul 1996 09:39:03 +0100 To: Masataka Ohta cc: M.Handley@cs.ucl.ac.uk (Mark Handley), civanlar@att.com, casner@precept.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Mon, 22 Jul 1996 12:03:10 +0200." <199607220303.MAA04227@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Jul 1996 09:39:00 +0100 Message-ID: <776.838024740@cs.ucl.ac.uk> From: Jon Crowcroft >> Bear in mind that even if the sender's audio clock is accurate, >> receivers won't be. You still need some receiver correction. >Receivers' clocks should be synchronized to the sender's and >no drop/add of data is necessary. RTP is the mechanism to synchronise the sender/recveviers clock we have no telepathy i nthe internet yet jon From rem-conf-request@es.net Mon Jul 22 04:56:21 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 01:55:36 -0700 From: Masataka Ohta Message-Id: <199607220855.RAA05373@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA05373; Mon, 22 Jul 1996 17:55:03 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Mon, 22 Jul 96 17:55:03 JST Cc: mohta@necom830.hpcl.titech.ac.jp, M.Handley@cs.ucl.ac.uk, casner@precept.com, civanlar@att.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com In-Reply-To: <769.838024699@cs.ucl.ac.uk>; from "Jon Crowcroft" at Jul 22, 96 9:38 am X-Mailer: ELM [version 2.3 PL11] > >With the merged encoding, the restoration of cross-media synchronization > >is not necessary. > > >So, how can you conclude that not merging is the way to go? > > > 1/ different sources The point is "cross-media synchronization". > 2/ different accuracy soruces A single source host has a single clock. > 3/ different accuracy sources for different media fro msame source > machine "fro msame"? Do you mean "from same"? Why can't you put space characters in the proper places? A single source host have a single clock. If the clock is not shared by related media, cross-media synchronization between them is impossible. > 4/ hetergeity support (for differnece i nsink clock accuracy Can you type the above statement correctly? Otherwise, I can't even guess your intention. Masataka Ohta From rem-conf-request@es.net Mon Jul 22 05:00:58 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 02:00:12 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Jul 1996 09:59:45 +0100 To: Masataka Ohta cc: M.Handley@cs.ucl.ac.uk, casner@precept.com, civanlar@att.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Mon, 22 Jul 1996 17:55:03 +0200." <199607220855.RAA05373@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Jul 1996 09:59:42 +0100 Message-ID: <992.838025982@cs.ucl.ac.uk> From: Jon Crowcroft >The point is "cross-media synchronization". different sources can have different media (i don't have to capture video and audio on the same machine >> 2/ different accuracy soruces >A single source host has a single clock. nope, notif the clock is stamped o nthe packet in a capture device or i use 2 different machines >Why can't you put space characters in the proper places? consistency is the last resort of the incompetent >> 4/ hetergeity support (for differnece i nsink clock accuracy >Can you type the above statement correctly? Otherwise, I can't >even guess your intention. HETEROGENEITY SUPPORT: difference in the accuracy of the sink clocks at different receivers as well as all the above.... apologies for the lack of typing skills, i think everyone else got it first tiem around though....english is quite a nice redundent language... jon From rem-conf-request@es.net Mon Jul 22 05:15:53 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 02:15:12 -0700 From: Masataka Ohta Message-Id: <199607220913.SAA05508@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA05508; Mon, 22 Jul 1996 18:13:40 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Mon, 22 Jul 96 18:13:39 JST Cc: mohta@necom830.hpcl.titech.ac.jp, M.Handley@cs.ucl.ac.uk, civanlar@att.com, casner@precept.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com In-Reply-To: <776.838024740@cs.ucl.ac.uk>; from "Jon Crowcroft" at Jul 22, 96 9:39 am X-Mailer: ELM [version 2.3 PL11] > >> Bear in mind that even if the sender's audio clock is accurate, > >> receivers won't be. You still need some receiver correction. > > >Receivers' clocks should be synchronized to the sender's and > >no drop/add of data is necessary. > > RTP is the mechanism to synchronize the sender/recveviers clock RTP is an Internet mechanism to coarsely synchronize the sender/recveviers clock frequency. NTP is an Internet mechanism to accurately synchronize the sender/recveviers clock frequency. It is also a mechanism to coarsely synchronize the sender/recveviers clock phase. GPS gives an accurate mechanism to synchronize the sender/recveviers clock frequency and phase. Anyway, don't bother to drop/add data. > we have no telepathy i nthe internet yet "in the Internet"? That's why you should type as correctly as possible. Masataka Ohta From rem-conf-request@es.net Mon Jul 22 05:34:17 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 02:33:33 -0700 From: Masataka Ohta Message-Id: <199607220933.SAA05727@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA05727; Mon, 22 Jul 1996 18:33:03 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Mon, 22 Jul 96 18:33:03 JST Cc: mohta@necom830.hpcl.titech.ac.jp, M.Handley@cs.ucl.ac.uk, casner@precept.com, civanlar@att.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com In-Reply-To: <992.838025982@cs.ucl.ac.uk>; from "Jon Crowcroft" at Jul 22, 96 9:59 am X-Mailer: ELM [version 2.3 PL11] > >> 2/ different accuracy soruces > >A single source host has a single clock. > > nope, notif the clock is stamped o nthe packet in a capture device Motif of the clock of n-th packet? What do you mean? > or > i use 2 different machines If you use 2 different machines? The issue is covered by the point 1/ and resolved by NTP or GPS. > >Why can't you put space characters in the proper places? > > consistency is the last resort of the incompetent When your logic is broken, how can other people find the consistency? > HETEROGENEITY SUPPORT: difference in the accuracy of the sink clocks > at different receivers as well as all the above.... What is the accuracy problem caused by the merged media but not by the separated media? > apologies for the lack of typing skills, It's a lack of intention to use editors and spell checkers. Masataka Ohta From rem-conf-request@es.net Mon Jul 22 05:42:01 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 02:40:40 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Jul 1996 10:38:59 +0100 To: Masataka Ohta cc: M.Handley@cs.ucl.ac.uk, civanlar@att.com, casner@precept.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Mon, 22 Jul 1996 18:13:39 +0200." <199607220913.SAA05508@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Jul 1996 10:38:54 +0100 Message-ID: <1191.838028334@cs.ucl.ac.uk> From: Jon Crowcroft >RTP is an Internet mechanism to coarsely synchronize the >sender/recveviers clock frequency. it is as good as the media timestamp which is as good as the media source and sink can manage, which is often better than the system clock >NTP is an Internet mechanism to accurately synchronize the >sender/recveviers clock frequency. It is also a mechanism to >coarsely synchronize the sender/recveviers clock phase. NTP coordinates a system of clocks; it is not optimised for media synchronisation - the motivation is subtly different, but importantly so.......for example, an NTP synchronised system wil ladjust its clock towards the most trusted source - this may not necessarily be appropriate for multiple sources of multiple media... >GPS gives an accurate mechanism to synchronize the sender/recveviers >clock frequency and phase. why do you want to add 200$ per receiver and sender by requiring or suggesting GPS? it doesn't work in some environments anyhow.... a minimal internet mbone phone should not need to cost more than 200$ total. jon From rem-conf-request@es.net Mon Jul 22 06:49:50 1996 Received: from aic.net by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 03:45:39 -0700 Received: by aic.net (8.7.3/8.7.3) id OAA00464; Mon, 22 Jul 1996 14:34:21 +0400 (AMT) From: "Edgar V.S. Der-Danieliantz" Message-Id: <199607221034.OAA00464@aic.net> Subject: Re: "at any one time" and "media types" - clarification needed To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Mon, 22 Jul 1996 14:34:20 +0400 (AMT) Cc: mohta@necom830.hpcl.titech.ac.jp, M.Handley@cs.ucl.ac.uk, casner@precept.com, civanlar@att.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@dnrc.bell-labs.com In-Reply-To: <992.838025982@cs.ucl.ac.uk> from "Jon Crowcroft" at Jul 22, 96 09:59:42 am Content-Type: text > ....english is quite a nice redundent > language... > > jon nope :o) -edd From rem-conf-request@es.net Mon Jul 22 06:53:03 1996 Received: from gamma.qmw.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 03:50:59 -0700 Received: from canary.dcs.qmw.ac.uk by gamma.qmw.ac.uk with SMTP-QMW with ESMTP; Mon, 22 Jul 1996 11:50:41 +0100 Received: from andromeda.dcs.qmw.ac.uk [138.37.89.2] by canary.dcs.qmw.ac.uk (8.7.5/QMW-server-2.8s+SMS) with SMTP; for ""; poster "Jyrki Heikkinen "; id LAA15741; Mon, 22 Jul 1996 11:50:39 +0100 (BST) Full-Name: Jyrki Heikkinen Date: Mon, 22 Jul 1996 11:49:45 +0100 Message-Id: <199607221049.LAA00830@andromeda> From: Jyrki Heikkinen To: rem-conf@es.net Subject: Group collaboration questionnaire Hi At Queen Mary and Westfield College, University of London, we are developing Mrooms, work spaces that support group collaboration in the Internet. To obtain requirements for collaboration and user interaction, we have formulated a user questionnaire. You can answer the questionnaire by replying to this message, or using the Web version at http://www.dcs.qmw.ac.uk/research/distrib/Mushroom/userq.html Mrooms in a nutshell: In Mrooms, users share applications and information such as documents, multimedia presentations and whiteboards. Mrooms can be accessed with Web browsers, and access can be restricted to group members. Users have tools for awareness of and communication with other users in the Mroom; when users occupy the Mroom at different times, they can observe one another's changes to information. Mrooms also guarantee persistence and consistency of information. ------------------------------------------------------------- MROOM USER QUESTIONNAIRE 1. Collaboration in a recent or current project In this first section we would like information about a recent or current collaborative project -- preferably one using computer support of some type, and/or one in which the collaborators are geographically dispersed. If you can think of several such projects, then please send a message for each of them. Characterise your collaboration, in terms of shared tasks, goals and information: Number of people you collaborated with directly: How were people distributed geographically? What different roles did collaborators play? How often did collaborators meet face to face, and what was the purpose of these meetings? Did the meetings achieve their purpose, and how important were they to the project? Which tools or systems (e.g., e-mail, whiteboard, conferencing) did you use in the project, and how? Were you satisfied or dissatisfied with the tools? Why? What kind of problems or good aspects in collaboration have you encountered with the project? Do you have any other comments on the collaborative aspects of the project? 2. Requirements for collaboration Which tools or systems (whether or not they exist) would you like to use, and for what tasks? What support would you like for coordinating activities and tasks? What kind of objects would you like to share in collaborative activities? Can you envisage using a system that enables you to 'encounter' users while browsing or searching for information on the Web, and to hold on-line discussions and interactions with them? If so, how? How else would you like to see the Web enhanced to support collaboration and interaction? Beyond the Web, what other requirements do you have for computer support for collaboration and user interaction? 3. Personal information (optional) Provide this information if you don't mind us contacting you with further questions. Your name: E-mail address: Company or organization: Comments on this questionnaire: ------------------------------------------------------------- *** END OF THE QUESTIONNAIRE *** ------------------------------------------------------------- Jyrki Heikkinen Distributed Systems Research assistant Computer Science Department jyrki@dcs.qmw.ac.uk Queen Mary & Westfield College http://www.dcs.qmw.ac.uk/~jyrki/ University of London Tel: +44 171 975 5244 Mile End Road Fax: +44 181 980 6533 London E1 4NS From rem-conf-request@es.net Mon Jul 22 11:02:55 1996 Received: from netserv1.NetLiveCom.COM (actually 206.137.237.5) by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 08:02:19 -0700 Received: from pc6.netlive (vrysin [206.137.237.16]) by netserv1.NetLiveCom.COM (8.6.12/8.6.9) with SMTP id LAA08301; Mon, 22 Jul 1996 11:00:21 -0400 Message-ID: <31F3977C.6D6D@netlivecom.com> Date: Mon, 22 Jul 1996 11:01:12 -0400 From: Vladislav Rysin Organization: NetLive Communications, Inc. X-Mailer: Mozilla 3.0b5a (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net, rem-conf-request@es.net CC: com-priv-request@psi.com, com-priv-request@es.com, listserv@es.net, majordomo@es.net Subject: unsubscibe Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please unsubscibe me from the list, Thanks -- Vladislav Rysin E-mail: vrysin@NetLiveCom.com NetLive Communications, Inc. Phone: (212) 343-8568 584 Broadway, Suite 806 Fax: (212) 343-7090 New York, New York 10012 www: WWW.NetLiveCom.COM From rem-conf-request@es.net Mon Jul 22 11:35:41 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 08:35:05 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Jul 1996 16:33:15 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: Masataka Ohta cc: civanlar@att.com, casner@precept.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Mon, 22 Jul 96 12:03:10 +0200." <199607220303.MAA04227@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Jul 96 16:33:13 +0100 Message-ID: <3948.838049593@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >> >> For example, someone may have an audio device not tuned correctly to >> >> (say) 8KHz (this is very common in practice). If you bundle, you need >> >> to do a bunch of fancy correction for each packet at the sender to >> >> drop/add samples to make it up to what should have been there for the >> >> length of real-time the bundled RTP clock states. >> > >> >Isn't it better to do the fancy correction once by the sender than >> >multiple times by the receivers? >> >> Bear in mind that even if the sender's audio clock is accurate, >> receivers won't be. You still need some receiver correction. > >Receivers' clocks should be synchronized to the sender's and >no drop/add of data is necessary. There are more than one clock involved at each site. - each host has a real-time clock. - each host has an audio device clocked at some rate. These may bear little relation to each other - for example a device which claims it's running at 8KHz may or may not deliver 8K samples in one second as measured by the real-time clock. The real-time clocks at a sender and receiver are unlikely to be synchronised, but this is irrelevant. Several effect cause problems: 1: sender audio clock *rate* mismatch with sender real-time clock *rate* 2: sender real-time clock *rate* mismatch with receiver real-time clock *rate* 3: receiver audio clock *rate* mismatch with receiver real-time clock *rate* 4: sender audio clock *rate* mismatch with receiver audio clock *rate* For our purposes, 2 doesn't seem to cause great problems. However workstation manufacturers don't seem to care much about audio device clock rates, so 1, 3 and 4 can all be significant (I haven't checked recently, but this used to be very noticable if you run vat without silence supression on an ethernet and listen to the playout differences between different workstations in the same room) Returning to the original discussion... If you bundle, then I'm assuming you put the real-time clock in the bundled RTP timestamp. Thus 1 and 3 bite you immediately and you need to be able to correct at the sender for every packet (by adding/droping samples) and this gets ugly as you now have strange numbers of samples in a packet, plus you add noise every time you make such a correction. If you don't bundle, then on a long time scale you can correct 4 at the receiver only when absolutely required and only when you're about to violate your lip-sync bounds. 1 and 3 only become apparent when an RTCP SR packet arrives, and are used to update the lip-sync bounds, which you won't have violated anyway if the audio clock rates are reasonably close to each other, or you've been correcting at the receiver anyway. Bundling makes all this a whole lot harder.... Mark From rem-conf-request@es.net Mon Jul 22 11:37:07 1996 Received: from ns.gte.com by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 08:35:50 -0700 Original-Received: from popserver.gte.com by ns.gte.com (8.7.5/) PP-warning: Illegal Received field on preceding line Received: from [132.197.144.52] by popserver.gte.com (8.6.9/8.6.9) with SMTP id LAA10832; Mon, 22 Jul 1996 11:21:37 -0400 Date: Mon, 22 Jul 1996 11:21:37 -0400 X-Sender: bk00@pophost.gte.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: tccc@cs.umass.edu, dbworld@cs.wisc.edu, end2end-interest@isi.edu, f-troup@aurora.cis.upenn.edu, cost237-transport@comp.lancs.ac.uk, reres@laas.fr, hipparch@sophia.inria.fr, xtp-relay@cs.concordia.ca, rem-conf@es.net, sigmedia@bellcore.com, mobile-ip@Tadpole.Com, cellular@comnets.rwth-aachen.de, badri@cs.rutgers.edu, ieeetcpc@ccvm.sunysb.edu, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comswtc@gmu.edu, G_F_Wetzel@att.com, wolfson@ouri.eecs.uic.edu From: bhumip@gte.com (Dr Bhumip Khasnabish +1-617-466-2080) Subject: CFP of the WOSBIS-96 (Nov.13/96). Pls Distribute. Thanks. Cc: wolfson@ouri.eecs.uic.edu, BLeiner@arpa.mil, bb@cs.purdue.edu, chiueh@cs.sunysb.edu, chlamtac@BCN.BU.EDU, danzig@pollux.usc.edu, dbarbara@bellcore.com, epitoura@cc.uoi.gr, grossman@uic.edu, hfk@research.att.com, imielins@cs.rutgers.edu, jimf@aro.ncren.net, liny@liny.csie.nctu.edu.tw, mhd@seas.smu.edu, ralonso@peanut.sarnoff.com, randy@cs.Berkeley.edu, sbz@cs.brown.edu, sharony@hazeltine.com, son@aic.hrl.hac.com, szabo@hit.bme.hu, wildman@arl.mil, wolfson@bert.eecs.uic.edu, yemini@cs.columbia.edu, yeyesha@cesdis.edu, ygz@aic.hrl.hac.com Call for papers for the First International Workshop on Satellite-based Information Services (WOSBIS) to be held on November 13, 1996 (new deadline for submission is Aug.15, 96) in the Rye Hilton, Rye, New York, USA (Immediately following ACM MobiCom'96) [Sponsored by Hughes Research Laboratories and ACM Sigmobile (pending)] Further information is available at the following URL: http://www.eecs.uic.edu/~wolfson/html/wosbis96cfp.html Questions and queries should be directed to: Prof. Ouri Wolfson (wolfson@eecs.uic.edu) or Bhumip Khasnabish (bhumip@gte.com) ------------------------------------------------------------------ Thanks a lot, with all the best wishes and regards, --------------------------------------------------------------------- Dr. Bhumip Khasnabish, GTE Labs. Inc., Tel +1-617-466-2080 40 Sylvan Road, Fax +1-617-890-9320 Waltham MA 02254 Res +1-617-647-5356 U.S.A. E-Mail: bhumip@gte.com ..................................................................... Web Page within GTE Labs: http://cnsmacic.gte.com/users/bhumip/ ===================================================================== From rem-conf-request@es.net Mon Jul 22 12:07:17 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 09:06:50 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 22 Jul 1996 17:06:42 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: rem-conf@osi-east.es.net Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Mon, 22 Jul 96 12:11:45 +0200." <199607220312.MAA04263@necom830.hpcl.titech.ac.jp> Date: Mon, 22 Jul 96 17:06:41 +0100 Message-ID: <4011.838051601@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >> >> Audio and Video are just a subset of media types that might want to be >> >> included in a session, whether it's an Mbone session, or on demand >> >> from a server. There are many many other media types ranging from >> >> shared editors and whiteboards, to multiple video streams with a single >> >> audio stream, to accompanying slides, etc. All of these may require >> >> cross-media synchronisation. >> > >> >Synchronisation means that all the media share the same clock. >> >> Synchronisation means we know the relationships between the different >> clocks at the source and have enough information to be able to restore >> that relationship at the receiver. > >With the merged encoding, the restoration of cross-media synchronization >is not necessary. For either bundled or unbundled, you need to do multiple *single-media* synchronisations to restore the original timing relationships in the data that have been modified by network jitter. Once you have a buffer per-media to do this, sync is a matter of modifying the playout points from these per-media buffers. Whether this data arrived in RTP headers or implicitly from bundling+RTP header makes no difference. Lets assume you do bundle... Assuming you need to spread a video frame over several packets, and that for each video frame you have approximately one packet worth of audio (a reasonable assumption for 25fps video), you can now send this audio at the beginning of the video frame packet sequence, at the end, or spaced out all the way through. If you try to space it out all the way through, it gets somewhat ugly with VBR compressed video. Still, I assume that the first sample of the audio corresponds with the time the frame was captured, and therefore the RTP timestamp in all these packets. So now we depacketise the video and audio, mark both the audio and video data with the real-time stamp included in the packet, decompress them separately, put them each into a buffer til the slower of the decompression processes has finished, figure out what the audio device lag is (due to samples in the device waiting to be played out), compensate for audio-clock drift, fill in any spare time due to packet loss, send the audio to the audio device buffer, and wait until the decided time (based on the original RTP timestamp) to display the video. Or some similar varient - you can do some parts in different orders but the basic tasks are the same. If you don't bundle, you do the *same*thing* except the data arrived separately and the playout points from the buffers are based on per-media RTP clocks (which therefore involve no rounding problems) rather than a single bundled clock. So bundling doesn't make anything easier, and may make some things harder. It does not simplyfy synchronisation. There are two times it makes sense: - to reduce packet header overheads. - where you need to rebundle anyway for dumb hardware codecs. Mark From rem-conf-request@es.net Mon Jul 22 13:18:48 1996 Received: from mail-d.bcc.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 10:17:46 -0700 Received: from busby (actually busby.ee.ucl.ac.uk) by mail-d.bcc.ac.uk with SMTP (PP); Mon, 22 Jul 1996 18:13:46 +0100 From: a.galis@eleceng.ucl.ac.uk Received: from [128.40.40.86] (ee-at8th-mac86) by busby; Mon, 22 Jul 96 18:13:23 BST X-Sender: agalis@busby Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jul 1996 18:15:00 +0000 To: ss96@greco.dit.upm.es, SS96 Distribution List , cnom@maestro.bellcore.com, tccc@cs.umass.edu, osimcast@bbn.com, sc6wg4@ntd.comsat.com, hipparch@sophia.inria.fr, reres@laas.fr, prs@masi.ibp.fr, ieeetcpc@ccvm.sunysb.edu, comswtc@gmu.edu, multicomm@cc.bellcore.com, giga@tele.pitt.edu, isadsoc@fokus.gmd.de, ctc-members@redbank.tinac.com, ieee_rtc_list@cs.tamu.edu, enternet@bbn.com, cnom@maestro.bellcore.com, gcomlist1@manjaro.ece.iit.edu, comsoc.bog@tab.ieee.org, sigmedia@bellcore.com, comsoc.tac@tab.ieee.org, comsoc-gicb@ieee.org, commsoft@cc.bellcore.com, BM-Mist1@cs.ucdavis.edu, modern-heuristics@uk.ac.mailbase.ucdavis.edu, alg@comm.toronto.edu, cellular@dfv.rwth-aachen.edu, cost237-transport@comp.lancs.ac.uk, testnet@canarie.ca, igawdan@bnr.ca, end2end-interest@venera.isi.edu, f-troup@aurora.cis.upenn.edu, g-troup@dworkin.wustl.edu, ietf@venera.isi.edu, rem-conf-request@es.net, 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, 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, ytw@hoserve.ho.att.com, epmcc_distribution@comnets.rwth-aachen.de, COMSWTC@gmu.edu, sigmedia@bellcore.com, jdc@mojave.ece.arizona.edu From: a.galis (Alex Galis) Subject: GLOBCOM'96 London U.K. / 18-22 November 1996 Cc: a.galis@busby, c.todd@busby Dear All, In the name of the Organising Committee I am pleased to invite you to attend GLOBCOM'96 Telecommunications Conference organised by IEEE in London ( 18th - 22nd November 1996). Yours sincerely Alex Galis University College London ............................................................................ ........................... 1996 IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE 18th - 22nd November 1996 Queen Elizabeth II Conference Centre, Westminster, London "Communications: The Key to Global Prosperity" This major international communications conference, held annually for some 25 years, is to be hosted in London for its first staging in Europe. Sponsored by the IEEE Communications Society and in conjunction with the IEE, Globecom 96 aims to attract 1000+ of the leading telecommunication development engineers, academics, operators and manufacturers from all parts of the world. The Conference will consist of 50 Technical Sessions (in 9 parallel tracks), 6 Sessions of a Mini-Conference on Communications Theory, 4 Sessions of a Mini-Conference called "IEEE Global Internet '96" and 4 Panel Session discussions on key Business Topics over the 3 days (Tuesday 19th, Wednesday 20th and Thursday 21st November 1996). On Monday 18th and Friday 22nd November there will be some 27 half-day equivalent sessions devoted to Tutorials and Workshops on key Hot Topics. Throughout the week there will be a 20 stand Exhibition of sponsoring companies, publishers and future ComSoc Conferences. In addition there will be a separate Exhibition on Internet and related telecomms topics. Hot Topics The Hot Topics below have been identified by the ComSoc Technical Committees. These titles have been accepted by the Globecom '96 Technical Programme Committee as forming a basis on which to assemble Technical Session and Tutorials etc. - Advances in PCS - Wireless ATM - Advanced switching architectures for broadband networks - Network issues in wireless communications - Distributed Software Challenges - Software Support for Interactive MultiMedia Services and Applications - Wireless Communication and ATM - Towards ATM Switching Systems with Terabit/s Capacity - Signal Processing for Multimedia Services - Advanced VLSI Signal Processing in Communications - Quality of service for advanced communication services (PCS, Multimedia, Internet) - Software engineering technologies and experience to Improve and sustain network quality objectives - Mobile Satellite Communications - Satellite Communications for Broadband Networks - Security and Privacy in the GII/NII - Multicasting - Multimedia over the Internet - Interactive Video Applications and Supporting Technologies - Optical Access Networks and New Services Development - Very High-Speed ( OC-192) Optical Transmission Panel Sessions These will consist of short presentations followed by discussion, lead by a group of the leading Global Players on the Topics of:- 1. Visions of the 21st Century 2. Wireless revolution towards global roaming 3. The Information highway - market and service provider perspectives 4. Service and quality: customer's perceptions Tutorials and Workshops - mixture of full and half day Sessions The titles and leaders are: Monday tutorials and workshop T01 Telecommunications Management Network:- Standards, Implementation and Applications (Veli Sahin, NEC America Inc) T02 Introduction to ATM (Khosrow Sohraby, IBM) T03 GSM - Recent Advances and Future Developments (Paul Kakaes, Cosmos Communications Consulting) T04 Traffic Modelling and Management in Wireless Communications Systems (am) (Sirin Tekinay, Bell Northern Research) T05 Modelling and Transmission issues for VBR video over B-ISDN Networks (am) (Dr Ghanbari, University of Essex) T06 High Speed Wireless Data (Len Cimini, AT&T Bell Laboratories and Andrea Goldsmith, California Institute of Technology) T07 JAVA (Prof John N Daigle) T08 The Intelligent Network and Mobile System Control (pm) (Prof Bijan Jabbari, George Mason University) T09 Iterative Turbo-Decoding (pm) (Joachim Hagenauer, TU Munich) T10 Interactive Multimedia over the Internet (pm) (Mark Handley and Ian Wakemen, UCL and Sussex University) W01 Very-high-speed Digital Subscriber Lines (Prof John M Cioffi, Stanford University) Friday tutorials and workshop T11 Mobile and Multimedia Satellite Systems (Dr K M S Murthy, VISTAR Telecommunications) T12 Spread Spectrum Systems for PCS (Elvino S Sousa, University of Toronto) T13 Mobility Management in TCP/IP Networks (Dr Zygmunt Haas, Cornell University) T14 Operation and Management of Multi-Wavelength Optical Networks (am) (Dr Mari Maeda, Bell Communications Research) T15 Internet IP Security (am) ( Ran Atkinson, Internet Security) T16 Adaptive Antennas for Wireless Systems (pm) (Jack Winters, AT&T Bell Laboratories) T17 IP and ATM - Enterprise Internetworking (pm) (David Ginsburg, CISCO Corp) W02 Transport Protocols for High-Speed Broadband Networks (Douglas J Hoder, NASA) Although the Call-for-Paper deadline is March 1st 1996, further details of the Globecom 96 Technical Programme are available from Professor Hamid Aghvami, Tel: + 44 171 873 2898, Fax: + 44 171 836 4781, E-mail: h.aghvami@kcl.ac.uk CO1 Mini-Conference - Communications Theory This will consist of 6 Sessions running as a separate stream in parallel with the Main Sessions from Tuesday 19th to Thursday 21st November. For further details contact General Chair, F Marvasti at fam@orion.eee.kcl.ac.uk or for Call for Papers contact the Technical Programme Chair, Enzin Bigliori at biglieri@polito.it C02 Mini-Conference - IEEE Global Internet '96 This will consist of Technical Sessions, Panel Sessions, Tutorials, Keynote Speeches and major player Demonstrations and Exhibits on the subject of the Internet. The main sessions of the mini-conference are on Wednesday 20th and Thursday 21st November. If successful, this may be the first of a new annual IEEE ComSoc Conference on the topic. For further details contact John Crowcroft at j.crowcroft@cs.ucl.ac.uk London has of course, many tourist attractions and shopping facilities. Opposite the Queen Elizabeth II Conference Centre (QEIICC) is Westminster Abbey with the Houses of Parliament, Whitehall, Trafalgar Square, Buckingham Palace and St. James s Park all within close walking distance. Globecom 96 have organised a range of tours and social functions. These are:- SO1-Panoramic London Tour - Monday 18th (am) and Wednesday 20 November (pm) SO2-St James's Walking Tour - Monday 18th (am) SO3-Churchill War Rooms - two tours organised for Tuesday 19th November (am or pm) SO4-Westminster Abbey - two tours organised for Tuesday 19th November (am or pm) SO5-Thames Dinner Cruise - Tuesday 19th November (evening) SO6-Windsor Castle and Runnymede - Wednesday 20th November (am) SO7-Stratford-upon-Avon and Oxford - Thursday 21st November (all day) Three post conference tours to Edinburgh(PO1), Paris(PO2) and Bath(PO3) have also been organised commencing Friday 22nd to Sunday 24th November. On Tuesday 19th November there will be an IEEE Awards Luncheon in the QEIICC and on Wednesday evening (20th November) a Conference Banquet will be held in the Banqueting Suite of Whitehall Palace which was built in 1620 for King James 1st of England and Scotland. Some 1000 bedrooms have been reserved in the area of the QEIICC, all within 10-20 minutes walk or 2-3 stops on the Underground - Circle Line - nearest stations St. James's Park and Westminster. Prices range from ?30 - ?120 per night per room. Heathrow and Gatwick Airports, near London, between them serve more International Destinations and Passengers than anywhere else. Special discounted airfares are available from British Airways, when booking through one of their offices and quoting reference CIC*115/30. Within London, the network of Tube Trains, Buses and Taxis offer frequent services to all local destinations. Fuller, updated information is available via the Globecom '96 WWW homepage, see: http://www.labs.bt.com/profsoc/globecom/ If you would like a copy of the Early Registration form faxed to you, please complete your details below and return via mail, fax or e-mail to Jane Chopping (as below). Note that a version of the Registration form will appear on the WWW pages above from mid June '96. ---------------------------------------------------------------------------- ---------------------------------------- To: Jane Chopping IEE Conference Tel: +44 171 344 5469 Savoy Place Fax: +44 171 497 3633 London E-mail: jchopping@iee.org.uk WC2R 0BL, UK ---------------------------------------------------------------------------- ---------------------------------------- FULL NAME AND TITLE: JOB/POSITION: COMPANY/UNIVERSITY: ADDRESS: CITY/STATE: POSTCODE/ZIP CODE: COUNTRY: TELEPHONE NUMBER: FAX NUMBER: E-MAIL ADDRESS: From rem-conf-request@es.net Mon Jul 22 13:25:40 1996 Received: from mail-d.bcc.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 10:24:47 -0700 Received: from busby (actually busby.ee.ucl.ac.uk) by mail-d.bcc.ac.uk with SMTP (PP); Mon, 22 Jul 1996 18:17:19 +0100 From: a.galis@eleceng.ucl.ac.uk Received: from [128.40.40.86] (ee-at8th-mac86) by busby; Mon, 22 Jul 96 18:16:48 BST X-Sender: agalis@busby Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jul 1996 18:18:30 +0000 To: cnom@maestro.bellcore.com, nhe@postman.dg13.cec.be, announcements.chi@xerox.com, arl@arl1.wustl.edu, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, bcs-hci-request@mailbase.ac.uk, ccrc@dworkin.wustl.edu, cellular@dfv.rwth-aachen.de, cip@bbn.com, cnom@maestro.bellcore.com, cybsys-l@bingvmb.cc.binghamton.edu, diagrams@cs.swarthmore.edu, elsnet-list@cogsci.ed.ac.uk, end2end-interest@isi.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, 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, kdd@gte.com, perform@tay1.dec.com, rem-conf@es.net, sig11@roses.stanford.edu, sigmedia@bellcore.com, smds@cnri.reston.va.us, sound@acm.org, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, visual-l@vtvm1.cc.vt.edu, xtp-relay@cs.concordia.ca, commsoft@cc.bellcore.com, cnom@maestro.bellcore.com, utheorynt@vm1.nodak.edu, ietf-announce@cnri.reston.va.us, sigmedia@bellcore.com, ccrc@dworkin.wustl.edu, ie-list@cs.ucl.ac.uk, cost237-transport@comp.lancs.ac.uk, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, batnir@agcs.com, klaus.baumer@telekom.dbp.de, besier@eurescom.d400.de, vab@cc.bellcore.com, /dd.fax=14079558015/G=Stephen/S=Cannon/ADMD=MCI/C=US/@qmx400gate.nt.com, laura.cerchio@cselt.stet.it, j.cheong@trl.oz.au, TAIR%TL9000@nt.com, cnom@maestro.bellcore.com, Edwin.Frank.Crabill@att.att.com, DCrosby@VTRLMEL1.TRL.OZ.AU, /dd.id=ME.Cullum/ADMD=TELECOM.CANADA/C=CA/@qmx400gate.nt.com, dick.dodd@bridge.bst.bls.com, adoughe@Gateway.Uswnvg.COM, enternet@bbn.com, javan@comm.toronto.edu, fulvio.faraci@MacPost.cselt.stet.it, igorf@arch4.att.com, rlfike@aol.com, fogarty@eurescom.d400.de, larryg@arch4.att.com, edgar@tid.es, geradsd@agcs.com, bur_goode@vnet.ibm.com, gotz@cc.bellcore.com, epa.epacdh@memo3.ericsson.se, bich@cc.bellcore.com, epa.epajkj@memo3.ericsson.se, roberto.kung@issy.cnet.fr, kusaura@krsun.nslab.ntt.jp, hlu@arch4.att.com, kjl@cc.bellcore.com, ilka@prz.tu-berlin.de, mukasa@ast.lab.kdd.co.jp, niitsu@krsun.nslab.ntt.jp, oyamada@krsun.nslab.ntt.jp, etienne.paul@issy.cnet.fr, ieeetcpc@ccvm.sunysb.edu, swami@cc.bellcore.com, commsoft@cc.bellcore.com, roberto.saracco@cselt.stet.it, seb@cc.bellcore.com, cjs1@psp.att.com, hikaru@kopenews.nslab.ntt.jp, 0002912712@mcimail.com, /dd.id=towaij.s/ADMD=TELECOM.CANADA/C=CA/@qmx400gate.nt.com, brunosv@cpqd.br, waecdb@aur.alcatel.com, Carl.@eleceng.ucl.ac.uk War@nt.com, comswtc@gmu.edu, giga@tele.pitt.edu, enternet@bbn.com, ifip-nm@bbn.com, cnom@maestro.bellcore.com, nmf-members@nmf.com, netmgt@ncri.com, sig-dsm@doc.imperial.ac.uk, netmgt@ncri.com, enternet@bbn.com, dsm@nemo.ncsl.nist.gov, nmsig@nemo.ncsl.nist.gov, aow-nmsig@stc.ipa.go.jp, ewos-egnm@extend.iihe.ac.be, snmsigl@nemo.ncsl.nist.gov, noms96@joker.bellcore.com, corpcom@osf.org, nmf-members@nmf.org, ifip-emailmgt@ics.uci.edu, snmp@psi.com, nadism@mbunix.mitre.org, mitre-osi@bistromath.mitre.org, nsm-info@gateway.mitre.org, x3t54@mbunix.mitre.org, nmsig@ics.uci.edu, rwnmcc@external.iihe.rtt.be, OSIMIS@cs.ucl.ac.uk, ietf-madman@innosoft.com, nms@netmgrs.co.uk, iimc@thumper.bellcore.com, OVForum@andrew.cmu.edu, ieeetcpc@ccvm.sunysb.edu, commsoft@cc.bellcore.com, comswtc@gmu.edu, isinm97_oc@ctr.columbia.edu, news.announce.conferences%USENET@maestro.bellcore.com, ieee.announce@bellcore.com, comp.protocols.snmp%USENET@maestro.bellcore.com, comp.protocols.iso@bellcore.com, comp.org.ieee%USENET@maestro.bellcore.com, barrere@irit.fr, benzekri@irit.fr, bergougn@irit.fr, betourne@irit.fr, castanet@labri.u-bordeaux.fr, courtiat@laas.fr, cousin@irisa.fr, diaz@laas.fr, fdida@masi.ibp.fr, filali@irit.fr, fourneau@masi.ibp.fr, horlait@masi.ibp.fr, jard@irisa.fr, jezequel@irisa.fr, juanole@laas.fr, mbl@lri.lri.fr, plateau@imag.imag.fr, Guy.Pujolle@prism.uvsq.fr, rafiq@crisv2.univ-pau.fr, raynal@irisa.fr, raynaud@irit.fr, trehel@comte.univ-fcomte.fr, hipparch@sophia.inria.fr, lib@comte.univ-fcomte.fr, prs@uvsq.fr, prs@masi.ibp.fr, tous.rumeur@lip.ens-lyon.fr, alg@comm.toronto.edu, BM-List1@cs.ucdavis.edu, cellular@dfv.rwth-aachen.edu, cnom@maestro.bellcore.com, comsoc.bog@tab.ieee.org, comsoc-gicb@ieee.org, commsoft@cc.bellcore.com, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, enternet@bbn.com, forte@informatik.uni-kl.de, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, ieeetcpc@ccvm.sunysb.edu, ieee_rtc_list@cs.tamu.edu, isadsoc@fokus.gmd.de, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, osimcast@bbn.com, reres@comm.polymtl.ca, reres@uklirb.informatik.uni-kl.de, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@cs.umass.edu, testnet@canarie.ca, xtp-relay@cs.concordia.ca From: a.galis (Alex Galis) Subject: GLOBCOM'96 - London U.K. / 18-22 November 1996 Cc: a.galis@busby, c.todd@busby Dear All, In the name of the Organising Committee I am pleased to invite you to attend GLOBCOM'96 Telecommunications Conference organised by IEEE in London ( 18th - 22nd November 1996). Yours sincerely Alex Galis University College London ............................................................................ ........................... 1996 IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE 18th - 22nd November 1996 Queen Elizabeth II Conference Centre, Westminster, London "Communications: The Key to Global Prosperity" This major international communications conference, held annually for some 25 years, is to be hosted in London for its first staging in Europe. Sponsored by the IEEE Communications Society and in conjunction with the IEE, Globecom 96 aims to attract 1000+ of the leading telecommunication development engineers, academics, operators and manufacturers from all parts of the world. The Conference will consist of 50 Technical Sessions (in 9 parallel tracks), 6 Sessions of a Mini-Conference on Communications Theory, 4 Sessions of a Mini-Conference called "IEEE Global Internet '96" and 4 Panel Session discussions on key Business Topics over the 3 days (Tuesday 19th, Wednesday 20th and Thursday 21st November 1996). On Monday 18th and Friday 22nd November there will be some 27 half-day equivalent sessions devoted to Tutorials and Workshops on key Hot Topics. Throughout the week there will be a 20 stand Exhibition of sponsoring companies, publishers and future ComSoc Conferences. In addition there will be a separate Exhibition on Internet and related telecomms topics. Hot Topics The Hot Topics below have been identified by the ComSoc Technical Committees. These titles have been accepted by the Globecom '96 Technical Programme Committee as forming a basis on which to assemble Technical Session and Tutorials etc. - Advances in PCS - Wireless ATM - Advanced switching architectures for broadband networks - Network issues in wireless communications - Distributed Software Challenges - Software Support for Interactive MultiMedia Services and Applications - Wireless Communication and ATM - Towards ATM Switching Systems with Terabit/s Capacity - Signal Processing for Multimedia Services - Advanced VLSI Signal Processing in Communications - Quality of service for advanced communication services (PCS, Multimedia, Internet) - Software engineering technologies and experience to Improve and sustain network quality objectives - Mobile Satellite Communications - Satellite Communications for Broadband Networks - Security and Privacy in the GII/NII - Multicasting - Multimedia over the Internet - Interactive Video Applications and Supporting Technologies - Optical Access Networks and New Services Development - Very High-Speed ( OC-192) Optical Transmission Panel Sessions These will consist of short presentations followed by discussion, lead by a group of the leading Global Players on the Topics of:- 1. Visions of the 21st Century 2. Wireless revolution towards global roaming 3. The Information highway - market and service provider perspectives 4. Service and quality: customer's perceptions Tutorials and Workshops - mixture of full and half day Sessions The titles and leaders are: Monday tutorials and workshop T01 Telecommunications Management Network:- Standards, Implementation and Applications (Veli Sahin, NEC America Inc) T02 Introduction to ATM (Khosrow Sohraby, IBM) T03 GSM - Recent Advances and Future Developments (Paul Kakaes, Cosmos Communications Consulting) T04 Traffic Modelling and Management in Wireless Communications Systems (am) (Sirin Tekinay, Bell Northern Research) T05 Modelling and Transmission issues for VBR video over B-ISDN Networks (am) (Dr Ghanbari, University of Essex) T06 High Speed Wireless Data (Len Cimini, AT&T Bell Laboratories and Andrea Goldsmith, California Institute of Technology) T07 JAVA (Prof John N Daigle) T08 The Intelligent Network and Mobile System Control (pm) (Prof Bijan Jabbari, George Mason University) T09 Iterative Turbo-Decoding (pm) (Joachim Hagenauer, TU Munich) T10 Interactive Multimedia over the Internet (pm) (Mark Handley and Ian Wakemen, UCL and Sussex University) W01 Very-high-speed Digital Subscriber Lines (Prof John M Cioffi, Stanford University) Friday tutorials and workshop T11 Mobile and Multimedia Satellite Systems (Dr K M S Murthy, VISTAR Telecommunications) T12 Spread Spectrum Systems for PCS (Elvino S Sousa, University of Toronto) T13 Mobility Management in TCP/IP Networks (Dr Zygmunt Haas, Cornell University) T14 Operation and Management of Multi-Wavelength Optical Networks (am) (Dr Mari Maeda, Bell Communications Research) T15 Internet IP Security (am) ( Ran Atkinson, Internet Security) T16 Adaptive Antennas for Wireless Systems (pm) (Jack Winters, AT&T Bell Laboratories) T17 IP and ATM - Enterprise Internetworking (pm) (David Ginsburg, CISCO Corp) W02 Transport Protocols for High-Speed Broadband Networks (Douglas J Hoder, NASA) Although the Call-for-Paper deadline is March 1st 1996, further details of the Globecom 96 Technical Programme are available from Professor Hamid Aghvami, Tel: + 44 171 873 2898, Fax: + 44 171 836 4781, E-mail: h.aghvami@kcl.ac.uk CO1 Mini-Conference - Communications Theory This will consist of 6 Sessions running as a separate stream in parallel with the Main Sessions from Tuesday 19th to Thursday 21st November. For further details contact General Chair, F Marvasti at fam@orion.eee.kcl.ac.uk or for Call for Papers contact the Technical Programme Chair, Enzin Bigliori at biglieri@polito.it C02 Mini-Conference - IEEE Global Internet '96 This will consist of Technical Sessions, Panel Sessions, Tutorials, Keynote Speeches and major player Demonstrations and Exhibits on the subject of the Internet. The main sessions of the mini-conference are on Wednesday 20th and Thursday 21st November. If successful, this may be the first of a new annual IEEE ComSoc Conference on the topic. For further details contact John Crowcroft at j.crowcroft@cs.ucl.ac.uk London has of course, many tourist attractions and shopping facilities. Opposite the Queen Elizabeth II Conference Centre (QEIICC) is Westminster Abbey with the Houses of Parliament, Whitehall, Trafalgar Square, Buckingham Palace and St. James s Park all within close walking distance. Globecom 96 have organised a range of tours and social functions. These are:- SO1-Panoramic London Tour - Monday 18th (am) and Wednesday 20 November (pm) SO2-St James's Walking Tour - Monday 18th (am) SO3-Churchill War Rooms - two tours organised for Tuesday 19th November (am or pm) SO4-Westminster Abbey - two tours organised for Tuesday 19th November (am or pm) SO5-Thames Dinner Cruise - Tuesday 19th November (evening) SO6-Windsor Castle and Runnymede - Wednesday 20th November (am) SO7-Stratford-upon-Avon and Oxford - Thursday 21st November (all day) Three post conference tours to Edinburgh(PO1), Paris(PO2) and Bath(PO3) have also been organised commencing Friday 22nd to Sunday 24th November. On Tuesday 19th November there will be an IEEE Awards Luncheon in the QEIICC and on Wednesday evening (20th November) a Conference Banquet will be held in the Banqueting Suite of Whitehall Palace which was built in 1620 for King James 1st of England and Scotland. Some 1000 bedrooms have been reserved in the area of the QEIICC, all within 10-20 minutes walk or 2-3 stops on the Underground - Circle Line - nearest stations St. James's Park and Westminster. Prices range from ?30 - ?120 per night per room. Heathrow and Gatwick Airports, near London, between them serve more International Destinations and Passengers than anywhere else. Special discounted airfares are available from British Airways, when booking through one of their offices and quoting reference CIC*115/30. Within London, the network of Tube Trains, Buses and Taxis offer frequent services to all local destinations. Fuller, updated information is available via the Globecom '96 WWW homepage, see: http://www.labs.bt.com/profsoc/globecom/ If you would like a copy of the Early Registration form faxed to you, please complete your details below and return via mail, fax or e-mail to Jane Chopping (as below). Note that a version of the Registration form will appear on the WWW pages above from mid June '96. ---------------------------------------------------------------------------- ---------------------------------------- To: Jane Chopping IEE Conference Tel: +44 171 344 5469 Savoy Place Fax: +44 171 497 3633 London E-mail: jchopping@iee.org.uk WC2R 0BL, UK ---------------------------------------------------------------------------- ---------------------------------------- FULL NAME AND TITLE: JOB/POSITION: COMPANY/UNIVERSITY: ADDRESS: CITY/STATE: POSTCODE/ZIP CODE: COUNTRY: TELEPHONE NUMBER: FAX NUMBER: E-MAIL ADDRESS: From rem-conf-request@es.net Mon Jul 22 13:26:35 1996 Received: from mail-d.bcc.ac.uk by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 10:24:50 -0700 Received: from busby (actually busby.ee.ucl.ac.uk) by mail-d.bcc.ac.uk with SMTP (PP); Mon, 22 Jul 1996 18:22:54 +0100 From: a.galis@eleceng.ucl.ac.uk Received: from [128.40.40.86] (ee-at8th-mac86) by busby; Mon, 22 Jul 96 18:22:05 BST X-Sender: agalis@busby Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jul 1996 18:23:54 +0000 To: ifip-nm@bbn.com, cnom@maestro.bellcore.com, nmf-members@nmf.com, netmgt@ncri.com, sig-dsm@doc.imperial.ac.uk, netmgt@ncri.com, enternet@bbn.com, dsm@nemo.ncsl.nist.gov, nmsig@nemo.ncsl.nist.gov, aow-nmsig@stc.ipa.go.jp, ewos-egnm@extend.iihe.ac.be, snmsigl@nemo.ncsl.nist.gov, noms96@joker.bellcore.com, corpcom@osf.org, nmf-members@nmf.org, ifip-emailmgt@ics.uci.edu, snmp@psi.com, nadism@mbunix.mitre.org, mitre-osi@bistromath.mitre.org, nsm-info@gateway.mitre.org, x3t54@mbunix.mitre.org, nmsig@ics.uci.edu, rwnmcc@external.iihe.rtt.be, OSIMIS@cs.ucl.ac.uk, ietf-madman@innosoft.com, nms@netmgrs.co.uk, iimc@thumper.bellcore.com, OVForum@andrew.cmu.edu, ieeetcpc@ccvm.sunysb.edu, commsoft@cc.bellcore.com, comswtc@gmu.edu, isinm97_oc@ctr.columbia.edu, news.announce.conferences%USENET@maestro.bellcore.com, ieee.announce@bellcore.com, comp.protocols.snmp%USENET@maestro.bellcore.com, comp.protocols.iso@bellcore.com, comp.org.ieee%USENET@maestro.bellcore.com, barrere@irit.fr, benzekri@irit.fr, bergougn@irit.fr, betourne@irit.fr, castanet@labri.u-bordeaux.fr, courtiat@laas.fr, cousin@irisa.fr, diaz@laas.fr, fdida@masi.ibp.fr, filali@irit.fr, fourneau@masi.ibp.fr, horlait@masi.ibp.fr, jard@irisa.fr, jezequel@irisa.fr, juanole@laas.fr, mbl@lri.lri.fr, plateau@imag.imag.fr, Guy.Pujolle@prism.uvsq.fr, rafiq@crisv2.univ-pau.fr, raynal@irisa.fr, raynaud@irit.fr, trehel@comte.univ-fcomte.fr, hipparch@sophia.inria.fr, lib@comte.univ-fcomte.fr, prs@uvsq.fr, prs@masi.ibp.fr, tous.rumeur@lip.ens-lyon.fr, alg@comm.toronto.edu, BM-List1@cs.ucdavis.edu, cellular@dfv.rwth-aachen.edu, cnom@maestro.bellcore.com, comsoc.bog@tab.ieee.org, comsoc-gicb@ieee.org, commsoft@cc.bellcore.com, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, enternet@bbn.com, forte@informatik.uni-kl.de, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, ieeetcpc@ccvm.sunysb.edu, ieee_rtc_list@cs.tamu.edu, isadsoc@fokus.gmd.de, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, osimcast@bbn.com, reres@comm.polymtl.ca, reres@uklirb.informatik.uni-kl.de, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@cs.umass.edu, testnet@canarie.ca, xtp-relay@cs.concordia.ca, mss@gummo.doc.ic.ac.uk, TreDS96@Informatik.RWTH-Aachen.DE, 100765.3267@compuserve.com, Faouzi.Daoud@prism.uvsq.fr, G_F_Wetzel@gw1.att.com, Ron.Horn.0090874@nt.com, ahmadi@engn.uwindsor.ca, ahmed@ece.concordia.ca, aidarous@bnr.ca, announcements.chi@Xerox.c om, arl@arl.wustl.edu, atm-list@csc.com, atm@BBN.COM, badri@cs.rutgers.edu, bhumip@gte.com, bobchap@ibm.net, bran@silcom.com, braudyb@aol.com, bumblis@mcc.com, c.desmond@ieee.org, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, christos@ece.miami.edu, chuanyi@ecse.rpi.edu, cip@BBN.COM, clytle@sed.stel.com, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, craig@BBN.COM, dbworld@cs.wisc.edu, dotti@fokus.gmd.de, end2end-interest@isi.edu, enternet-ec@BBN.COM, enternet-ec@BBN.COM, enternet@BBN.COM, f-troup@aurora.cis.upenn.edu, fad@prism.uvsq.fr, g-troup@dworkin.wustl.edu, g.weisman@ieee.org, globecom@signet.com.sg, guthery@austin.sar.slb.com, hegering@lrz-muenchen.de, hipparch@sophia.inria.fr, icad-request@santafe.edu, ieeetcpc@ccvm.sunysb.edu, iplpdn@cnri.reston.va.us, jandre@imtn.tpd.dsccc.com, jerry@ece.concordia.ca, jne@glasgow-caledonian.ac.uk, just4net@aol.com, kjl@bellcore.com, knecht@mvuss.att.com, kseo@BBN.COM, labetoul@eurecom.fr, lanworks@delphi.com, lewis@ctron.com, mobile-ip@Tadpole.Com, mohan@ccmail.inet.com, mouftah@eleceng.ee.queensu.ca, murase@nwk.cl.nec.co.jp, mustafa@ece.concordia.ca, nkc@bellcore.com, oliveira@eurecom.fr, paulcov@bnr.ca, perform@tay1.dec.com, pogran@BBN.COM, prabhu@ee.uta.edu, pradeep@dstc.uts.edu.au, rdantu@tddcae99.fnts.com, rem-conf@es.net, reres@laas.fr, rlfike@aol.com, saracco@cselt.stet.it, sbw@ccrl.nj.nec.com, scott_linke@aus.hp.com, sidou@eurecom.fr, sigmedia@bellcore.com, smds@cnri.reston.va.us, staples@bnr.ca, t.stevenson@ieee.org, tccc@cs.umass.edu, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-a, tsuzuki@ccsd.ho.nec.co.jp, uist.chi@Xerox.com, vik@ihades.att.com, vkb@mvgsf.mv.att.com, w2xd@mtnms.att.com, waisum@buckaroo.ho.att.com, wolfson@ouri.eecs.uic.edu, wz@prosun.first.gmd.de, xrjo@atc.boeing.com, xtp-relay@cs.concordia.ca, yemini@cs.columbia.edu, yoshida@netwk.ntt-at.co.jp, yoshida@rosso.mss.netwk.ntt-at.co.jp, 100765.3267@compuserve.com, Faouzi.Daoud@prism.uvsq.fr, G_F_Wetzel@att.com, Ron.Horn.0090874@nt.com, ahmadi@engn.uwindsor.ca, ahmed@ece.concordia.ca, aidarous@bnr.ca, announcements.chi@Xerox.com, arl@arl1.wustl.edu, atm-list@csc.com, atm@BBN.COM, badri@cs.rutgers.edu, bhumip@gte.com, bobchap@ibm.net, bran@silcom.com, braudyb@aol.com, bumblis@mcc.com, c.desmond@ieee.org, ccrc@dworkin.wustl.edu, cellular@comnets.rwth-aachen.de, christos@ece.miami.edu, chuanyi@ecse.rpi.edu, cip@BBN.COM, clytle@sed.stel.com, cnom@maestro.bellcore.com, commsoft@cc.bellcore.com, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, craig@bbn.com, dbworld@cs.wisc.edu, dotti@fokus.gmd.de, end2end-interest@isi.edu, enternet-ec@BBN.COM, enternet-ec@bbn.com, enternet@BBN.COM, f-troup@aurora.cis.upenn.edu, fad@prism.uvsq.fr, g-troup@dworkin.wustl.edu, g.weisman@ieee.org, globecom@signet.com.sg, guthery@austin.sar.slb.com, hegering@lrz-muenchen.de, hipparch@sophia.inria.fr, icad-request@santafe.edu, ieeetcpc@ccvm.sunysb.edu, iplpdn@cnri.reston.va.us, jandre@imtn.tpd.dsccc.com, jerry@ece.concordia.ca, jne@glasgow-caledonian.ac.uk, just4net@aol.com, kjl@bellcore.com, kseo@bbn.com, labetoul@eurecom.fr, lanworks@delphi.com, lewis@ctron.com, mobile-ip@Tadpole.Com, mohan@ccmail.inet.com, mouftah@eleceng.ee.queensu.ca, murase@nwk.cl.nec.co.jp, mustafa@ece.concordia.ca, nkc@bellcore.com, oliveira@eurecom.fr, paulcov@bnr.ca, perform@tay1.dec.com, pogran@bbn.com, prabhu@ee.uta.edu, pradeep@dstc.uts.edu.au, rdantu@tddcae99.fnts.com, rem-conf@es.net, reres@laas.fr, rlfike@aol.com, saracco@cselt.stet.it, sbw@ccrl.nj.nec.com, scott_linke@aus.hp.com, sidou@eurecom.fr, sigmedia@bellcore.com, smds@cnri.reston.va.us, staples@bnr.ca, t.stevenson@ieee.org, tccc@cs.umass.edu, tcplw@cray.com, tf-mm@i4serv.informatik.rwth-a, tsuzuki@ccsd.ho.nec.co.jp, uist.chi@Xerox.com, vik@ihades.att.com, vkb@mvgsf.mv.att.com, w2xd@mtnm s.att.com, waisum@buckaroo.ho.att.com, wolfson@ouri.eecs.uic.edu, wz@prosun.first.gmd.de, xrjo@atc.boeing.com, xtp-relay@cs.concordia.ca, yemini@cs.columbia.edu, yoshida@netwk.ntt-at.co.jp, yoshida@rosso.mss.netwk.ntt-at.co.jp From: a.galis (Alex Galis) Subject: GLOBCOM'96 - London U.K. / 18-22 November 1996 Cc: a.galis@busby, c.todd@busby Dear All, In the name of the Organising Committee I am pleased to invite you to attend GLOBCOM'96 Telecommunications Conference organised by IEEE in London ( 18th - 22nd November 1996). Yours sincerely Alex Galis University College London ............................................................................ ........................... 1996 IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE 18th - 22nd November 1996 Queen Elizabeth II Conference Centre, Westminster, London "Communications: The Key to Global Prosperity" This major international communications conference, held annually for some 25 years, is to be hosted in London for its first staging in Europe. Sponsored by the IEEE Communications Society and in conjunction with the IEE, Globecom 96 aims to attract 1000+ of the leading telecommunication development engineers, academics, operators and manufacturers from all parts of the world. The Conference will consist of 50 Technical Sessions (in 9 parallel tracks), 6 Sessions of a Mini-Conference on Communications Theory, 4 Sessions of a Mini-Conference called "IEEE Global Internet '96" and 4 Panel Session discussions on key Business Topics over the 3 days (Tuesday 19th, Wednesday 20th and Thursday 21st November 1996). On Monday 18th and Friday 22nd November there will be some 27 half-day equivalent sessions devoted to Tutorials and Workshops on key Hot Topics. Throughout the week there will be a 20 stand Exhibition of sponsoring companies, publishers and future ComSoc Conferences. In addition there will be a separate Exhibition on Internet and related telecomms topics. Hot Topics The Hot Topics below have been identified by the ComSoc Technical Committees. These titles have been accepted by the Globecom '96 Technical Programme Committee as forming a basis on which to assemble Technical Session and Tutorials etc. - Advances in PCS - Wireless ATM - Advanced switching architectures for broadband networks - Network issues in wireless communications - Distributed Software Challenges - Software Support for Interactive MultiMedia Services and Applications - Wireless Communication and ATM - Towards ATM Switching Systems with Terabit/s Capacity - Signal Processing for Multimedia Services - Advanced VLSI Signal Processing in Communications - Quality of service for advanced communication services (PCS, Multimedia, Internet) - Software engineering technologies and experience to Improve and sustain network quality objectives - Mobile Satellite Communications - Satellite Communications for Broadband Networks - Security and Privacy in the GII/NII - Multicasting - Multimedia over the Internet - Interactive Video Applications and Supporting Technologies - Optical Access Networks and New Services Development - Very High-Speed ( OC-192) Optical Transmission Panel Sessions These will consist of short presentations followed by discussion, lead by a group of the leading Global Players on the Topics of:- 1. Visions of the 21st Century 2. Wireless revolution towards global roaming 3. The Information highway - market and service provider perspectives 4. Service and quality: customer's perceptions Tutorials and Workshops - mixture of full and half day Sessions The titles and leaders are: Monday tutorials and workshop T01 Telecommunications Management Network:- Standards, Implementation and Applications (Veli Sahin, NEC America Inc) T02 Introduction to ATM (Khosrow Sohraby, IBM) T03 GSM - Recent Advances and Future Developments (Paul Kakaes, Cosmos Communications Consulting) T04 Traffic Modelling and Management in Wireless Communications Systems (am) (Sirin Tekinay, Bell Northern Research) T05 Modelling and Transmission issues for VBR video over B-ISDN Networks (am) (Dr Ghanbari, University of Essex) T06 High Speed Wireless Data (Len Cimini, AT&T Bell Laboratories and Andrea Goldsmith, California Institute of Technology) T07 JAVA (Prof John N Daigle) T08 The Intelligent Network and Mobile System Control (pm) (Prof Bijan Jabbari, George Mason University) T09 Iterative Turbo-Decoding (pm) (Joachim Hagenauer, TU Munich) T10 Interactive Multimedia over the Internet (pm) (Mark Handley and Ian Wakemen, UCL and Sussex University) W01 Very-high-speed Digital Subscriber Lines (Prof John M Cioffi, Stanford University) Friday tutorials and workshop T11 Mobile and Multimedia Satellite Systems (Dr K M S Murthy, VISTAR Telecommunications) T12 Spread Spectrum Systems for PCS (Elvino S Sousa, University of Toronto) T13 Mobility Management in TCP/IP Networks (Dr Zygmunt Haas, Cornell University) T14 Operation and Management of Multi-Wavelength Optical Networks (am) (Dr Mari Maeda, Bell Communications Research) T15 Internet IP Security (am) ( Ran Atkinson, Internet Security) T16 Adaptive Antennas for Wireless Systems (pm) (Jack Winters, AT&T Bell Laboratories) T17 IP and ATM - Enterprise Internetworking (pm) (David Ginsburg, CISCO Corp) W02 Transport Protocols for High-Speed Broadband Networks (Douglas J Hoder, NASA) Although the Call-for-Paper deadline is March 1st 1996, further details of the Globecom 96 Technical Programme are available from Professor Hamid Aghvami, Tel: + 44 171 873 2898, Fax: + 44 171 836 4781, E-mail: h.aghvami@kcl.ac.uk CO1 Mini-Conference - Communications Theory This will consist of 6 Sessions running as a separate stream in parallel with the Main Sessions from Tuesday 19th to Thursday 21st November. For further details contact General Chair, F Marvasti at fam@orion.eee.kcl.ac.uk or for Call for Papers contact the Technical Programme Chair, Enzin Bigliori at biglieri@polito.it C02 Mini-Conference - IEEE Global Internet '96 This will consist of Technical Sessions, Panel Sessions, Tutorials, Keynote Speeches and major player Demonstrations and Exhibits on the subject of the Internet. The main sessions of the mini-conference are on Wednesday 20th and Thursday 21st November. If successful, this may be the first of a new annual IEEE ComSoc Conference on the topic. For further details contact John Crowcroft at j.crowcroft@cs.ucl.ac.uk London has of course, many tourist attractions and shopping facilities. Opposite the Queen Elizabeth II Conference Centre (QEIICC) is Westminster Abbey with the Houses of Parliament, Whitehall, Trafalgar Square, Buckingham Palace and St. James s Park all within close walking distance. Globecom 96 have organised a range of tours and social functions. These are:- SO1-Panoramic London Tour - Monday 18th (am) and Wednesday 20 November (pm) SO2-St James's Walking Tour - Monday 18th (am) SO3-Churchill War Rooms - two tours organised for Tuesday 19th November (am or pm) SO4-Westminster Abbey - two tours organised for Tuesday 19th November (am or pm) SO5-Thames Dinner Cruise - Tuesday 19th November (evening) SO6-Windsor Castle and Runnymede - Wednesday 20th November (am) SO7-Stratford-upon-Avon and Oxford - Thursday 21st November (all day) Three post conference tours to Edinburgh(PO1), Paris(PO2) and Bath(PO3) have also been organised commencing Friday 22nd to Sunday 24th November. On Tuesday 19th November there will be an IEEE Awards Luncheon in the QEIICC and on Wednesday evening (20th November) a Conference Banquet will be held in the Banqueting Suite of Whitehall Palace which was built in 1620 for King James 1st of England and Scotland. Some 1000 bedrooms have been reserved in the area of the QEIICC, all within 10-20 minutes walk or 2-3 stops on the Underground - Circle Line - nearest stations St. James's Park and Westminster. Prices range from ?30 - ?120 per night per room. Heathrow and Gatwick Airports, near London, between them serve more International Destinations and Passengers than anywhere else. Special discounted airfares are available from British Airways, when booking through one of their offices and quoting reference CIC*115/30. Within London, the network of Tube Trains, Buses and Taxis offer frequent services to all local destinations. Fuller, updated information is available via the Globecom '96 WWW homepage, see: http://www.labs.bt.com/profsoc/globecom/ If you would like a copy of the Early Registration form faxed to you, please complete your details below and return via mail, fax or e-mail to Jane Chopping (as below). Note that a version of the Registration form will appear on the WWW pages above from mid June '96. ---------------------------------------------------------------------------- ---------------------------------------- To: Jane Chopping IEE Conference Tel: +44 171 344 5469 Savoy Place Fax: +44 171 497 3633 London E-mail: jchopping@iee.org.uk WC2R 0BL, UK ---------------------------------------------------------------------------- ---------------------------------------- FULL NAME AND TITLE: JOB/POSITION: COMPANY/UNIVERSITY: ADDRESS: CITY/STATE: POSTCODE/ZIP CODE: COUNTRY: TELEPHONE NUMBER: FAX NUMBER: E-MAIL ADDRESS: From rem-conf-request@es.net Mon Jul 22 17:43:15 1996 Received: from cbgw2.att.com by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 14:41:24 -0700 Received: from big.att.com by cbig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id RAA18730; Mon, 22 Jul 1996 17:39:58 -0400 Received: from march (march.info.att.com [135.16.210.57]) by big.att.com (8.7.5/8.7.3) with SMTP id RAA14812 for ; Mon, 22 Jul 1996 17:41:14 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <31F3F57B.794BDF32@att.com> Date: Mon, 22 Jul 1996 17:41:15 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b5aGold (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: rem-conf@es.net Subject: [Fwd: Re: A new payload type for ligth-weight bundled MPEG] Content-Type: multipart/mixed; boundary="------------15FB748359E2B6001CFBAE39" This is a multi-part message in MIME format. --------------15FB748359E2B6001CFBAE39 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -- M. Reha Civanlar AT&T Research --------------15FB748359E2B6001CFBAE39 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from big.att.com (big.info.att.com [192.11.33.3]) by lexicon.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id VAA12852 for ; Fri, 19 Jul 1996 21:23:12 -0400 (EDT) Received: from research.research.att.com (research.research.att.com [135.104.117.5]) by big.att.com (8.7.5/8.7.3) with SMTP id VAA26663 for ; Fri, 19 Jul 1996 21:23:09 -0400 (EDT) Received: from precept.com by research; Fri Jul 19 21:21:20 EDT 1996 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA19372; Fri, 19 Jul 1996 18:21:13 -0700 Date: Fri, 19 Jul 1996 18:21:12 -0700 (PDT) From: Stephen Casner To: "M. Reha Civanlar" Cc: mrc@big.info.att.com Subject: Re: A new payload type for ligth-weight bundled MPEG In-Reply-To: <31EFE737.41C67EA6@att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reha, > First of all, I would like to thank you for your position supporting an > open and fair discussion environment. I do encourage discussion -- that's an important role as chairman of the working group. One point of my comments was that I doubted that either side was going to be convinced in this email discussion, so it makes sense to prove the point one way or the other by trying both schemes. > I think, defining payloads for all possible combinations of multimedia > bundlings is not any different than defining payloads for all possible > forms of single media encoding types. Clearly, both are impractical to > say the least. Therefore, the decision for defining a bundled payload > should be based on practical considerations for specific applications. There is an N*M versus N+M consideration which I think makes the difference significant. However, I agree that both are potentially larger than 127, so allocation of static payload types must be done conservatively. > The subject of my original proposal was to define a payload type for a > light-weight bundled MPEG video and audio. My response to this proposal depends upon what you want to do. You may propose a new bundled MPEG video and audio payload format to the working group by writing an Internet-Draft defining the details of the format. However, if you are asking to add another format to the existing draft defining paylod formats for MPEG, I am not willing to pull back that draft at this stage. It has gone through discussion in the working group and then Last Call in the working group and IESG, and has just been approved for publication as an RFC by the IESG. Also, if you are asking that a static payload type be defined for this bundled format, I don't think that would be appropriate before the format demonstrates some measure of success and acceptance. This should not be an impediment because you can use a dynamic payload type. I assume that you will have some path over which other control communication will be flowing that you can use to convey the mapping between a dynamic payload type number and the parameters of the particular bundling to be used (presuming that there may be variations). The existing MPEG draft does have three static payload types defined. A consideration in the assignment policy is the standardization of an encoding, and in the case of MPEG, both the elementary and transport streams are part of the standard. I think it is pretty clear that we want to be able to send audio and video elementary streams because it is the natural fit to RTP as a transport protocol. We need to be able to send them separately because an application may use only one medium. The justification for transport streams format is that existing programming will already be packaged in that format as it comes from hardware encoders, satellite feeds, and server disks, and as you note, for high-performance servers one wants to do the minimum work on the data as it is transmitted, perhaps with the CPU not touching the data at all. The new bundling you propose doesn't fit that standard criterion. However, if it is a successful proposal, it might be incorporated into the MPEG RFC at the next stage, or might become an RFC of its own. Now, taking off my chairman's hat, I personally remain unconvinced by several of the advantages you claim: > The main application of this > is high quality VOD on relatively high bandwidth networks. Such a > payload is useful for: > > 1. Reducing the overhead of detemining and assigning time stamps to > audio and video streams separately at a server which may serve several > such streams simultaneously. I believe the sending of RTP timestamps on the data packets is very simple because these are chosen to be natural to the data type. In any case, this seems like a small amount of work compared to the work of moving the data, or assembling the audio and video data into packets. If the file consists of packets already assembled, then they could just as easily be separate streams with timestamps already attached. The RTCP timestamps are a little bit trickier, but still don't represent any significant execution time, especially when you consider that RTCP packets are sent once every 5 seconds or less. > 2. Reduce the overhead of handling two ports per "program" (i.e. A/V) at > the servers and at the receivers which becomes particularly difficult at > higher bit rates. I don't see the connection with bit rate. The efficiency has to do with the number of send operations (see the next point) and not really on the number of ports on which those sends are done. If do see a connection with the number of programs if the system limits the number of ports. > 3. Reduce the header overhead. If you are sending MTU-size packets in both the separate and bundled cases, then the header overhead is no different. Since you are interested in the high data-rate case, this is likely. > 4. Reduce the receiver buffer size. Your comment about the behaviour of random variables is right in an abstract sense, but I don't believe it applies to the real conditions of sending packets because assumptions of independence and other considerations don't hold. Besides, memory costs less than $10/MB, so this isn't really an issue. > The proposed payload is different from the existing bundled MPEG > transport layer payload because: > > 1. It does not have MPEG system layer overhead which is not useful > unless a decoder which can only decode such streams is used. > > 2. It makes implementation of superior error recovery mechanisms > possible. I agree with these points; I would rather not use the MPEG transport layer. -- Steve p.s. It appears that your message I'm answering did not go to the rem-conf list because the "rem-conf@es.net" part was included in quotations along with my name. If you did intend your message to go to the list, you may forward it and my reply. --------------15FB748359E2B6001CFBAE39-- From rem-conf-request@es.net Mon Jul 22 18:33:10 1996 Received: from cbgw2.att.com by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 15:32:17 -0700 Cc: rem-conf@es.net, mrc@big.att.com Received: from big.att.com by cbig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id SAA00063; Mon, 22 Jul 1996 18:30:55 -0400 Received: from march (march.info.att.com [135.16.210.57]) by big.att.com (8.7.5/8.7.3) with SMTP id SAA16167; Mon, 22 Jul 1996 18:29:40 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <31F400D5.3F54BC7E@att.com> Date: Mon, 22 Jul 1996 18:29:41 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b5aGold (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Stephen Casner Original-CC: rem-conf@es.net, mrc@big.att.com Subject: Re: A new payload type for ligth-weight bundled MPEG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Casner wrote: > My response to this proposal depends upon what you want to do. You > may propose a new bundled MPEG video and audio payload format to the > working group by writing an Internet-Draft defining the details of the > format. This is fair. I will do it. > Now, taking off my chairman's hat, I personally remain unconvinced by > several of the advantages you claim: > > > The main application of this > > is high quality VOD on relatively high bandwidth networks. Such a > > payload is useful for: > > > > 1. Reducing the overhead of detemining and assigning time stamps to > > audio and video streams separately at a server which may serve several > > such streams simultaneously. > > I believe the sending of RTP timestamps on the data packets is very > simple because these are chosen to be natural to the data type. In > any case, this seems like a small amount of work compared to the work > of moving the data, or assembling the audio and video data into > packets. If the file consists of packets already assembled, then they > could just as easily be separate streams with timestamps already > attached. The RTCP timestamps are a little bit trickier, but still > don't represent any significant execution time, especially when you > consider that RTCP packets are sent once every 5 seconds or less. If the packet sizes are not fixed the timestamps need to be determined in real-time. Inaccuracies in the CPU's real-time clock can make this quite a difficult task. > > > 2. Reduce the overhead of handling two ports per "program" (i.e. A/V) at > > the servers and at the receivers which becomes particularly difficult at > > higher bit rates. > > I don't see the connection with bit rate. The efficiency has to do > with the number of send operations (see the next point) and not really > on the number of ports on which those sends are done. If do see a > connection with the number of programs if the system limits the number > of ports. The connection with the bit rate is through the increased demand for the resources to move and to process the A/V data. > > 3. Reduce the header overhead. > > If you are sending MTU-size packets in both the separate and bundled > cases, then the header overhead is no different. Since you are > interested in the high data-rate case, this is likely. If you have two streams instead of one using a light-weight combination, the header overhead is twice. I guess, Mark Handley agrees with this also :) > > 4. Reduce the receiver buffer size. > > Your comment about the behaviour of random variables is right in an > abstract sense, but I don't believe it applies to the real conditions > of sending packets because assumptions of independence and other > considerations don't hold. Besides, memory costs less than $10/MB, so > this isn't really an issue. The increased buffer size causes incresed delay which may be important in some applications. -- M. Reha Civanlar AT&T Research Fax: (908) 949 3697 From rem-conf-request@es.net Mon Jul 22 18:33:59 1996 Received: from helix.mgh.harvard.edu by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 15:33:26 -0700 Received: from neuro-mancer.mgh.harvard.edu by HELIX.MGH.HARVARD.EDU (PMDF V4.3-10 #5571) id <01I7DT5N4TU88XR01V@HELIX.MGH.HARVARD.EDU>; Mon, 22 Jul 1996 18:33:11 -0500 (EST) Date: Mon, 22 Jul 1996 18:36:02 -0400 From: John Lester Subject: unsubscribe To: rem-conf@es.net Message-id: MIME-version: 1.0 Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7BIT Please unsubscribe me from this list. lester@helix.mgh.harvard.edu John Lester From rem-conf-request@es.net Mon Jul 22 19:21:22 1996 Received: from sgigate.sgi.com by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 16:20:27 -0700 Received: from cthulhu.engr.sgi.com by sgigate.sgi.com via ESMTP (951211.SGI.8.6.12.PATCH1042/940406a.SGI) id QAA27585; Mon, 22 Jul 1996 16:20:21 -0700 Received: from pimtest.engr.sgi.com (pimtest.engr.sgi.com [150.166.75.13]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id QAA22552; Mon, 22 Jul 1996 16:20:03 -0700 Received: (from ahelmy@localhost) by pimtest.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA04328; Mon, 22 Jul 1996 16:20:00 -0700 From: Ahmed Helmy Message-Id: <9607221619.ZM4326@pimtest.engr.sgi.com> Date: Mon, 22 Jul 1996 16:19:57 -0700 In-Reply-To: Van Jacobson "Re: alpha release of rtcp monitor program" (Jun 5, 3:26pm) References: <199606052226.PAA19640@rx7.ee.lbl.gov> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Van Jacobson , Andrew Swan Subject: Re: alpha release of rtcp monitor program Cc: rem-conf@es.net, drbacher@cs.Berkeley.EDU Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii > 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".) rtpmon seems to work fine up to 50 rxrs or so... but when the number of rxrs grows to about 350 ro so... it crashes.. !! is there a limit on the # of rxrs... or am I doing something wrong. ?! Regards, -A > - Van From rem-conf-request@es.net Mon Jul 22 20:32:20 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 17:31:35 -0700 From: Masataka Ohta Message-Id: <199607230031.JAA07030@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA07030; Tue, 23 Jul 1996 09:30:47 +0859 Subject: Re: "at any one time" and "media types" - clarification needed To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Tue, 23 Jul 96 9:30:46 JST Cc: mohta@necom830.hpcl.titech.ac.jp, civanlar@att.com, casner@precept.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com In-Reply-To: <3948.838049593@cs.ucl.ac.uk>; from "Mark Handley" at Jul 22, 96 4:33 pm X-Mailer: ELM [version 2.3 PL11] > There are more than one clock involved at each site. Because you don't want to have hardware for merged encoding. Merged encoding with separate hardware is only as bad as separate encoding with merged encoding, because synchronization of hardware sampling clocks are just as easy/difficult as synchronization to the NTP clock. On the other hand, merged encoding with merged hardware needs no further synchronization. That is, considering the cross-media synchronization, merged encoding is better (though only slightly, I'm afraid). > If you bundle, then I'm assuming you put the real-time clock in the > bundled RTP timestamp. Thus 1 and 3 bite you immediately and you need > to be able to correct at the sender for every packet (by > adding/droping samples) and this gets ugly as you now have strange > numbers of samples in a packet, plus you add noise every time you make > such a correction. Study signal processing technologies of the real world audio. There are a lot of ways to compensate clock differences. Just adding/droping is not an acceptable solution except for low quality applications such as the current Internet audio. Masataka Ohta From rem-conf-request@es.net Mon Jul 22 20:32:58 1996 Received: from gateway-gw.pictel.com by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 17:32:31 -0700 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA12042; Mon, 22 Jul 96 20:32:16 EDT Received: from magicland.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA29246; Mon, 22 Jul 96 20:32:14 EDT Received: by magicland.pictel.com (SMI-8.6/SMI-SVR4) id UAA11845; Mon, 22 Jul 1996 20:30:14 -0400 From: webberr@pictel.com (Bob Webber) Message-Id: <199607230030.UAA11845@magicland.pictel.com> Subject: standards clarification To: civanlar@att.com (M. Reha Civanlar) Date: Mon, 22 Jul 1996 20:30:13 -0400 (EDT) Cc: M.Handley@cs.ucl.ac.uk, mohta@necom830.hpcl.titech.ac.jp, casner@precept.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com In-Reply-To: <31EFEA97.167EB0E7@att.com> from "M. Reha Civanlar" at Jul 19, 96 04:05:43 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text ... > If you re-read my message to Mr. Handley, you may notice that the real > meaning of my comment is: a standard not accommodating the needs of > practical applications is bound to fail. You may see several examples > for such standards everywhere. This is so, but you will also find examples of standards which happily ignored some "practical" applications and thrived in spite of it. As noted in my earlier e-mail, there are a number of ways to solve the problem your application sets out to solve, and some of the solutions are compliant with the ideas behind RTP and don't require changing the standard to solve the problem. In videoconferencing, for example, a number of manufacturers' approaches to the problem were left out, but the standard survives nonetheless. What you appear to be saying is that _your_ application has some property which makes the standard's accomodating it vital, and clearly many others do not agree with you. How widely is your application used, such that its force in the world will cause a standard to fall if it is not accomodated? From rem-conf-request@es.net Mon Jul 22 20:56:20 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 17:55:15 -0700 Received: from rah.star-gate.com (localhost.cdrom.com [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id RAA00773; Mon, 22 Jul 1996 17:55:10 -0700 (PDT) Message-Id: <199607230055.RAA00773@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: "M. Reha Civanlar" cc: rem-conf@es.net Subject: Re: [Fwd: Re: A new payload type for ligth-weight bundled MPEG] In-reply-to: Your message of "Mon, 22 Jul 1996 17:41:15 EDT." <31F3F57B.794BDF32@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Jul 1996 17:55:10 -0700 From: Amancio Hasty >From The Desk Of "M. Reha Civanlar" : > > I think, defining payloads for all possible combinations of multimedia > > bundlings is not any different than defining payloads for all possible > > forms of single media encoding types. Clearly, both are impractical to > > say the least. Therefore, the decision for defining a bundled payload > > should be based on practical considerations for specific applications. > > There is an N*M versus N+M consideration which I think makes the > difference significant. However, I agree that both are potentially > larger than 127, so allocation of static payload types must be done > conservatively. > Gosh, I am a little lost here where does the N*M versus N+M figures comes in. Conceptually, there is very little difference between an application which handles audio/video and two separate application for audio and video. I would say that the problem of handling bundle types for an application is N+M. Amancio From rem-conf-request@es.net Mon Jul 22 22:10:38 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 19:09:45 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA28395; Mon, 22 Jul 1996 19:09:39 -0700 Date: Mon, 22 Jul 1996 19:09:38 -0700 (PDT) From: Stephen Casner To: Scott Petrack Cc: rem-conf@osi-east.es.net Subject: Re: multiplexing, interleaving, interchanging etc. In-Reply-To: <9607210907.AA21262@precept.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Scott, > Does the following summarize the orthodox > position about interleaving, multiplexing, and > interchanging? ("orthodox" = intent of the RFC's creators ;-)) I think what you've written is pretty much right. > 3. Thou shalt be reasonable w.r.t. other kinds of > multiplexing, interleaving, and encoding switching. This one is true but not very specific. If reasonable multiplexing means using multiple UDP ports, then sure. If this is regarding the SSRC and payload type, then I'd just reduce rule 3 to: 3. Thou shalt be reasonable w.r.t. encoding switching. > One could imagine a profile defining > an "MPEG" media type which would consist of > a bytestream which has MPEG audio-only, video-only, > or audio-video mixed in a system layer. Yes, but I'm not sure it would be a good idea. One thing about profiles is that you don't want a lot of them since a program typically operates under only one, and the choice is implicit. -- Steve From rem-conf-request@es.net Mon Jul 22 22:59:41 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 19:59:05 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA28463; Mon, 22 Jul 1996 19:59:01 -0700 Date: Mon, 22 Jul 1996 19:59:01 -0700 (PDT) From: Stephen Casner To: "M. Reha Civanlar" Cc: rem-conf@es.net, mrc@big.att.com Subject: Re: A new payload type for ligth-weight bundled MPEG In-Reply-To: <31F400D5.3F54BC7E@att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reha, I think we're talking past each other and not really connecting. However, there is one point I want to comment on because a number of people have been confused about RTP timestamps: > If the packet sizes are not fixed the timestamps need to be determined > in real-time. Inaccuracies in the CPU's real-time clock can make this > quite a difficult task. In most cases, RTP timestamps should not be generated from the CPU's real-time clock. As in the example given in the spec, for a mu-law PCM audio stream, the timestamp for each packet is simply the sample number of the first sample in the packet. That is, the timestamp for packet N+1 is the timestamp for packet N plus the number of samples in packet N (assuming there is no silence suppression and all samples are sent). For video, including MPEG elementary streams, the RTP timestamp is incremented by the nominal frame time, measured in 90kHz ticks, for the first packet of a frame and is unchanged between packets of a frame. When sending RTCP packets, calculating the RTP timestamp that corresponds to the NTP timestamp does require that the relationship be maintained between the audio or video clock and the CPU's real-time clock (if that is the source of NTP timestamps). -- Steve From rem-conf-request@es.net Mon Jul 22 23:13:48 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 20:12:49 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA28474; Mon, 22 Jul 1996 20:12:16 -0700 Date: Mon, 22 Jul 1996 20:12:16 -0700 (PDT) From: Stephen Casner To: Amancio Hasty Cc: rem-conf@es.net Subject: Re: [Fwd: Re: A new payload type for ligth-weight bundled MPEG] In-Reply-To: <199607230055.RAA00773@rah.star-gate.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > There is an N*M versus N+M consideration which I think makes the > > difference significant. However, I agree that both are potentially > > larger than 127, so allocation of static payload types must be done > > conservatively. > > Gosh, I am a little lost here where does the N*M versus N+M figures comes > in. What I meant was very simple. If there are N audio encodings and M video encodings, then if a static payload type were to be defined for every combination of an audio encoding and a video encoding to be carried as a bundled type, it would require N*M static payload types. If only unbundled audio and video types are carried, only N+M static payload types would be needed. Now, you probably would not expect to define all N*M possible combinations, but still that product creates more of a demand for types than the sum does. Since the space is small, dynamic payload types provide a solution. > I would say that the problem of handling bundle types for an application > is N+M. You are right that the number of encodings the bundled app needs to handle is still N+M. -- Steve From rem-conf-request@es.net Mon Jul 22 23:22:09 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 20:21:28 -0700 From: Masataka Ohta Message-Id: <199607230321.MAA07375@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA07375; Tue, 23 Jul 1996 12:21:07 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: M.Handley@cs.ucl.ac.uk (Mark Handley) Date: Tue, 23 Jul 96 12:21:06 JST Cc: rem-conf@osi-east.es.net In-Reply-To: <4011.838051601@cs.ucl.ac.uk>; from "Mark Handley" at Jul 22, 96 5:06 pm X-Mailer: ELM [version 2.3 PL11] > Assuming you need to spread a video frame over several packets, and > that for each video frame you have approximately one packet worth of > audio (a reasonable assumption for 25fps video), First, it is unlikely that something which can encode more than 25fps video does not have its own audio encoder. But, you insists to support all the audio/video combinaiton by separate hardware. OK. Still, there are a lot of ways of correct synchronization. > you can now send this > audio at the beginning of the video frame packet sequence, at the end, > or spaced out all the way through. The easiest one is to time-stamp video frame with audio clock. Even with lowly 8KHz audio sampling, no one can notice the jitter effect on video. > So now we depacketise the video and audio, mark both the audio and > video data with the real-time stamp included in the packet, decompress > them separately, put them each into a buffer til the slower of the > decompression processes has finished, figure out what the audio device > lag is (due to samples in the device waiting to be played out), > compensate for audio-clock drift, fill in any spare time due to packet > loss, send the audio to the audio device buffer, and wait until the > decided time (based on the original RTP timestamp) to display the > video. Or some similar varient - you can do some parts in different > orders but the basic tasks are the same. > If you don't bundle, you do the *same*thing* And, it's a lot of work. That is, we are rather motivated to have dedicated merged hardware for lip-sync, which naturally leads to the merged encoding. > There are two times it makes sense: > - to reduce packet header overheads. > - where you need to rebundle anyway for dumb hardware codecs. Three more. hardware lip-sync less HOL delay Masataka Ohta From rem-conf-request@es.net Mon Jul 22 23:30:27 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 20:30:00 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Jul 1996 04:29:43 +0100 To: Masataka Ohta cc: M.Handley@cs.ucl.ac.uk (Mark Handley), civanlar@att.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Tue, 23 Jul 1996 09:30:46 +0200." <199607230031.JAA07030@necom830.hpcl.titech.ac.jp> Date: Tue, 23 Jul 1996 04:29:45 +0100 Message-ID: <538.838092585@cs.ucl.ac.uk> From: Jon Crowcroft >> There are more than one clock involved at each site. >Because you don't want to have hardware for merged encoding. >Merged encoding with separate hardware is only as bad as separate >encoding with merged encoding, because synchronization of hardware >sampling clocks are just as easy/difficult as synchronization to >the NTP clock. you confound 2 assumptions here 1/ yes you could have a merged media codec but that does NOT necessarily imply.... 2/ that the codec sampling clocks is easily set from the workstation but i agree, it could be the case [but no hardware codec we have looked at lets you set its internal clock from the networking host side in any accurate way - but things might change....) >On the other hand, merged encoding with merged hardware needs no >further synchronization. > >That is, considering the cross-media synchronization, merged encoding >is better (though only slightly, I'm afraid). > >> If you bundle, then I'm assuming you put the real-time clock in the >> bundled RTP timestamp. Thus 1 and 3 bite you immediately and you need >> to be able to correct at the sender for every packet (by >> adding/droping samples) and this gets ugly as you now have strange >> numbers of samples in a packet, plus you add noise every time you make >> such a correction. > >Study signal processing technologies of the real world audio. There >are a lot of ways to compensate clock differences. Just adding/droping >is not an acceptable solution except for low quality applications such >as the current Internet audio. sure, but again, addressing the current technology - we need to run these loss repair algorithms at quite high rates in software in existing workstations clearly, in some future mergedmedia codec receiver, one can do arbitrarily complex clock resynch and DSP work on the post-reception separated streams but why make the codec cost so high? why not work with incrementally improvable software solutions and monmedia codecs that are available now, and getting better rapidly....? and, as per various messages, if you bundle at source multimedia codec and/or host, what price heterogeneity (i.e. software unbundling)? why impose this overhead on the VERY receivers who can't affords the more complex codec, and are restricted to only one of the media types? one major whole strength of the ip multicast model is the ability to support ranges of receivers and seems a good goal to engineer for solutions that accommodate the lowest common factor, rather than the highest.....(note i say accomodate - that doesn't mean limit ourselves to them). jon From rem-conf-request@es.net Mon Jul 22 23:49:58 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Mon, 22 Jul 1996 20:49:28 -0700 From: Masataka Ohta Message-Id: <199607230349.MAA07494@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA07494; Tue, 23 Jul 1996 12:48:53 +0859 Subject: Re: "at any one time" and "media types" - clarification needed To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Tue, 23 Jul 96 12:48:52 JST Cc: mohta@necom830.hpcl.titech.ac.jp, M.Handley@cs.ucl.ac.uk, civanlar@att.com, rem-conf@osi-east.es.net, mrc@big.att.com In-Reply-To: <538.838092585@cs.ucl.ac.uk>; from "Jon Crowcroft" at Jul 23, 96 4:29 am X-Mailer: ELM [version 2.3 PL11] > >Study signal processing technologies of the real world audio. There > >are a lot of ways to compensate clock differences. Just adding/droping > >is not an acceptable solution except for low quality applications such > >as the current Internet audio. > > sure, but again, addressing the current technology - we need to run > these loss repair algorithms at quite high rates in software in > existing workstations > > clearly, in some future mergedmedia codec receiver, one can do > arbitrarily complex clock resynch and DSP work on the post-reception > separated streams > > but why make the codec cost so high? FYI, table lookup of sinc function for audio is just a memory reference. For low quality audio of current Mbone, linear interpolation is a lot more than enough. > one major whole strength of the ip multicast model is the ability to > support ranges of receivers Which means that all the receivers recognize a single common encoding. Masataka Ohta From rem-conf-request@es.net Tue Jul 23 03:20:08 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 00:19:20 -0700 From: Masataka Ohta Message-Id: <199607230719.QAA07983@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA07983; Tue, 23 Jul 1996 16:19:15 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: rem-conf@osi-east.es.net Date: Tue, 23 Jul 96 16:19:15 JST In-Reply-To: <199607230349.MAA07494@necom830.hpcl.titech.ac.jp>; from "Masataka Ohta" at Jul 23, 96 12:48 pm X-Mailer: ELM [version 2.3 PL11] > >Study signal processing technologies of the real world audio. There > >are a lot of ways to compensate clock differences. Just adding/droping > >is not an acceptable solution except for low quality applications such > >as the current Internet audio. > > sure, but again, addressing the current technology - we need to run > these loss repair algorithms at quite high rates in software in > existing workstations > > clearly, in some future mergedmedia codec receiver, one can do > arbitrarily complex clock resynch and DSP work on the post-reception > separated streams > > but why make the codec cost so high? FYI, table lookup of sinc function for audio is just a memory reference. For low quality audio of current Mbone, linear interpolation is a lot more than enough. > one major whole strength of the ip multicast model is the ability to > support ranges of receivers Which means that all the receivers recognize a single common encoding. Masataka Ohta From rem-conf-request@es.net Tue Jul 23 04:05:07 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 01:04:23 -0700 From: Masataka Ohta Message-Id: <199607230803.RAA08224@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA08224; Tue, 23 Jul 1996 17:03:41 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Tue, 23 Jul 96 17:03:40 JST Cc: mohta@necom830.hpcl.titech.ac.jp, M.Handley@cs.ucl.ac.uk, civanlar@att.com, casner@precept.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com In-Reply-To: <1191.838028334@cs.ucl.ac.uk>; from "Jon Crowcroft" at Jul 22, 96 10:38 am X-Mailer: ELM [version 2.3 PL11] > > >RTP is an Internet mechanism to coarsely synchronize the > >sender/recveviers clock frequency. > > it is as good as the media timestamp which is as good as the media > source and sink can manage, which is often better than the system > clock What you miss is that RTP does not synchrnonize absolute time. Moreover, as I taught you a simple mathematical fact in IPATM ML, accurate synchornization with a lot of jitter takes a lot of time, that's why its coarse. With 1 seccond of jitter, it takes 1,000 seconds to reduce clock frequency error below 0.1%. Masataka Ohta From rem-conf-request@es.net Tue Jul 23 04:37:03 1996 Received: from net.tsinghua.edu.cn (actually oar.net.tsinghua.edu.cn) by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 01:35:44 -0700 Received: by net.tsinghua.edu.cn (5.x/SMI-SVR4) id AA12020; Tue, 23 Jul 1996 17:26:59 +0900 Date: Tue, 23 Jul 1996 17:26:59 +0900 From: wxd@net.tsinghua.edu.cn (Xiaodong Wang) Message-Id: <9607230826.AA12020@net.tsinghua.edu.cn> To: rem-conf@es.net help From rem-conf-request@es.net Tue Jul 23 04:46:17 1996 Received: from rah.star-gate.com by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 01:45:37 -0700 Received: from rah.star-gate.com (localhost.cdrom.com [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id BAA01100; Tue, 23 Jul 1996 01:45:22 -0700 (PDT) Message-Id: <199607230845.BAA01100@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Masataka Ohta cc: rem-conf@osi-east.es.net Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Tue, 23 Jul 1996 16:19:15 +0200." <199607230719.QAA07983@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jul 1996 01:45:21 -0700 From: Amancio Hasty Hi Masataka, Can you write an app to demonstrate your idea of bundling ? Domo, Amancio From rem-conf-request@es.net Tue Jul 23 04:55:33 1996 Received: from rah.star-gate.com by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 01:54:59 -0700 Received: from rah.star-gate.com (localhost.cdrom.com [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id BAA01141; Tue, 23 Jul 1996 01:54:53 -0700 (PDT) Message-Id: <199607230854.BAA01141@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Stephen Casner cc: rem-conf@es.net Subject: Re: [Fwd: Re: A new payload type for ligth-weight bundled MPEG] In-reply-to: Your message of "Mon, 22 Jul 1996 20:12:16 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jul 1996 01:54:52 -0700 From: Amancio Hasty >From The Desk Of Stephen Casner : > > > There is an N*M versus N+M consideration which I think makes the > > > difference significant. However, I agree that both are potentially > > > larger than 127, so allocation of static payload types must be done > > > conservatively. > > > > Gosh, I am a little lost here where does the N*M versus N+M figures comes > > in. > > What I meant was very simple. If there are N audio encodings and M > video encodings, then if a static payload type were to be defined for > every combination of an audio encoding and a video encoding to be > carried as a bundled type, it would require N*M static payload types. > If only unbundled audio and video types are carried, only N+M static > payload types would be needed. Nope , it depends on your RTP packet format . I would include the datatype of the object along with the object . This reduces the problem to N+M. Regards, Amancio From rem-conf-request@es.net Tue Jul 23 05:50:23 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 02:49:17 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Jul 1996 10:46:53 +0100 To: Masataka Ohta cc: M.Handley@cs.ucl.ac.uk (Mark Handley), rem-conf@osi-east.es.net Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Tue, 23 Jul 1996 12:21:06 +0200." <199607230321.MAA07375@necom830.hpcl.titech.ac.jp> Date: Tue, 23 Jul 1996 10:46:44 +0100 Message-ID: <1304.838115204@cs.ucl.ac.uk> From: Jon Crowcroft >> Assuming you need to spread a video frame over several packets, and >> that for each video frame you have approximately one packet worth of >> audio (a reasonable assumption for 25fps video), >First, it is unlikely that something which can encode more than 25fps >video does not have its own audio encoder. bullshit - we have plenty of workstations with fuill frame rate video cards and seperate audio cards with seperate audio clocks.... > hardware lip-sync weird, and wonderful - you think lip synch is hard so ytou want harware - its the EASY part of syncrhionisation.... > less HOL delay see other comments....bundling INCREASES HOL delay to the WORST clock and packet size choice....unless you do patheological framing, like H.221, which is pathelogically bad for software to disentanlge for single media only receivers... jon From rem-conf-request@es.net Tue Jul 23 05:51:08 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 02:49:19 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Jul 1996 10:48:36 +0100 To: Masataka Ohta cc: M.Handley@cs.ucl.ac.uk, civanlar@att.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Tue, 23 Jul 1996 12:48:52 +0200." <199607230349.MAA07494@necom830.hpcl.titech.ac.jp> Date: Tue, 23 Jul 1996 10:48:28 +0100 Message-ID: <1313.838115308@cs.ucl.ac.uk> From: Jon Crowcroft >> but why make the codec cost so high? >FYI, table lookup of sinc function for audio is just a memory >reference. do you mean sine function? please type more carefully,especially when putting function lookup entries into a table or you will cause ariane 5 type disasters.... >For low quality audio of current Mbone, linear interpolation >is a lot more than enough. fine, so yo uagree then that we can use seperate media.....and combine quite happily - why are you arguing for combined media then? >> one major whole strength of the ip multicast model is the ability to >> support ranges of receivers >Which means that all the receivers recognize a single common encoding. WRONG. which means that subsets of the receivers recognize DIFFERENT subsets of the encodings..... jon From rem-conf-request@es.net Tue Jul 23 05:52:39 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 02:51:26 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 23 Jul 1996 10:50:17 +0100 To: Masataka Ohta cc: M.Handley@cs.ucl.ac.uk, civanlar@att.com, casner@precept.com, deering@parc.xerox.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Tue, 23 Jul 1996 17:03:40 +0200." <199607230803.RAA08224@necom830.hpcl.titech.ac.jp> Date: Tue, 23 Jul 1996 10:50:11 +0100 Message-ID: <1322.838115411@cs.ucl.ac.uk> From: Jon Crowcroft >What you miss is that RTP does not synchrnonize absolute time. what you miss is tat NTP doesn't synchronise clocks to absolute time DTS (for example) does do that, but NTP has a very different goal which is to reach an AGREED version of time..... >Moreover, as I taught you a simple mathematical fact in IPATM ML, >accurate synchornization with a lot of jitter takes a lot of time, >that's why its coarse. you mistake clock jitter for network trasnfer delay variance >With 1 seccond of jitter, it takes 1,000 seconds to reduce clock >frequency error below 0.1%. see above - we don't have that level of problem in the CLOCKS, only in the network as per our discussion on IPATM, i see you fail to understand packet networks yet again jon From rem-conf-request@es.net Tue Jul 23 10:33:57 1996 Received: from nasla.yonsei.ac.kr by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 07:32:45 -0700 Received: (from chair@localhost) by nasla.yonsei.ac.kr (8.6.9H1/8.6.9) id XAA13084 for rem-conf@es.net; Tue, 23 Jul 1996 23:25:42 +0900 From: Cho Young Jin Message-Id: <199607231425.XAA13084@nasla.yonsei.ac.kr> Subject: To: rem-conf@es.net Date: Tue, 23 Jul 1996 23:25:42 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h4] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Content-Length: 10 subscribe From rem-conf-request@es.net Tue Jul 23 11:08:22 1996 Received: from cbgw1.att.com (actually 192.20.239.133) by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 08:07:46 -0700 Cc: rem-conf@osi-east.es.net Received: from big.att.com by cbig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id LAA21072; Tue, 23 Jul 1996 11:02:35 -0400 Received: from march (march.info.att.com [135.16.210.57]) by big.att.com (8.7.5/8.7.3) with SMTP id LAA04817; Tue, 23 Jul 1996 11:04:46 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <31F4EA0F.FF6D5DF@att.com> Date: Tue, 23 Jul 1996 11:04:47 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b5aGold (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Bob Webber Original-CC: rem-conf@osi-east.es.net Subject: Re: standards clarification References: <199607230030.UAA11845@magicland.pictel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Webber wrote: > In videoconferencing, for example, a number of > manufacturers' approaches to the problem were left out, but the standard > survives nonetheless. > I would like to point out the difference between hardware bound applications and software applications. The video conferencing standards that you are referring to are, so far, hardware bound. Since the number of users is the main determinant of the price of hardware, it is beneficial to stick with a reasonable standard. On the other hand, when SW only codecs become good enough, we can always load and run the new and better applications whether they are standard or not. > What you appear to be saying is that _your_ application has some property > which makes the standard's accomodating it vital, and clearly many > others do not agree with you. How widely is your application used, such > that its force in the world will cause a standard to fall if it is > not accomodated? What I am saying is that I have an application that benefits from a slight extension to the standard. There are several others that agree with me, and since both sides of the issue have supporters, it should be left to the market to make the final decision. On the other hand, if a proposed standard is to be protected strictly and religiously, several applications will look for other ways out. -- M. Reha Civanlar From rem-conf-request@es.net Tue Jul 23 11:17:32 1996 Received: from cbgw2.att.com by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 08:16:56 -0700 Cc: rem-conf@es.net Received: from big.att.com by cbig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id LAA06292; Tue, 23 Jul 1996 11:15:26 -0400 Received: from march (march.info.att.com [135.16.210.57]) by big.att.com (8.7.5/8.7.3) with SMTP id LAA05175; Tue, 23 Jul 1996 11:16:40 -0400 (EDT) Sender: mrc@big.att.com Message-ID: <31F4ECDA.ABD322C@att.com> Date: Tue, 23 Jul 1996 11:16:42 -0400 From: "M. Reha Civanlar" Organization: AT&T Research X-Mailer: Mozilla 3.0b5aGold (X11; I; SunOS 4.1.3 sun4m) MIME-Version: 1.0 To: Stephen Casner Original-CC: rem-conf@es.net Subject: Re: A new payload type for ligth-weight bundled MPEG References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Casner wrote: > > Reha, > > I think we're talking past each other and not really connecting. As you recommended in your message, I forwarded your answer to my previous message which did not appear on the mailing list because of my mistake. If this caused an anachronism, I am sorry. Are you still interested in a draft describing my packetization scheme? If there is a strict decision about not including any mixed media payloads other than the existing MPEG transport type as an RTP payload, I am definitely not interested in wasting time. -- M. Reha Civanlar From rem-conf-request@es.net Tue Jul 23 11:47:16 1996 Received: from shiva.jussieu.fr by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 08:45:50 -0700 Received: from moka.ccr.jussieu.fr (moka.ccr.jussieu.fr [134.157.1.23]) by shiva.jussieu.fr (8.7.5/jtpda-5.2) with ESMTP id RAA09792 for ; Tue, 23 Jul 1996 17:45:48 +0200 (METDST) Received: from (delahaye@localhost) by moka.ccr.jussieu.fr (8.7.5/jtpda-5.2) id RAA106304 for rem-conf@es.net; Tue, 23 Jul 1996 17:45:47 +0200 From: delahaye@ccr.jussieu.fr (Stephane DELAHAYE) Message-Id: <199607231545.RAA106304@moka.ccr.jussieu.fr> To: rem-conf@es.net Date: Tue, 23 Jul 1996 17:45:47 +0200 (DST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit unsubscribe From rem-conf-request@es.net Tue Jul 23 12:43:18 1996 Received: from hera.rbi.informatik.uni-frankfurt.de by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 09:42:15 -0700 Received: from roma.dbis.informatik.uni-frankfurt.de by hera.rbi.informatik.uni-frankfurt.de with SMTP (1.38.193.4/16.2) id AA27030; Tue, 23 Jul 1996 18:20:16 +0200 Received: from atlas.rbi.informatik.uni-frankfurt.de by dbis.informatik.uni-frankfurt.de with smtp (Smail3.1.28.1 #4) id m0uik8j-000BnGC; Tue, 23 Jul 96 18:16 MET DST Received: by atlas.rbi.informatik.uni-frankfurt.de (1.39.111.2/16.2) id AA149068613; Tue, 23 Jul 1996 18:16:53 +0200 From: zicari@informatik.uni-frankfurt.de Posted-Date: Tue, 23 Jul 1996 18:16:53 +0200 Received-Date: Tue, 23 Jul 1996 18:16:53 +0200 Message-Id: <199607231616.AA149068613@atlas.rbi.informatik.uni-frankfurt.de> Subject: Web site To: Telecom.Int.3@dbis.informatik.uni-frankfurt.de Date: Tue, 23 Jul 1996 18:16:53 +0200 (METDST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 163 The full conference programs of Object World Frankfurt 96 and Internet Forum Europe 96 are on line at http://www.ltt.de Regards Roberto Zicari OWF/IFE Chair From rem-conf-request@es.net Tue Jul 23 13:32:55 1996 Received: from hera.rbi.informatik.uni-frankfurt.de by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 10:32:08 -0700 Received: from roma.dbis.informatik.uni-frankfurt.de by hera.rbi.informatik.uni-frankfurt.de with SMTP (1.38.193.4/16.2) id AA26991; Tue, 23 Jul 1996 18:16:16 +0200 Received: from atlas.rbi.informatik.uni-frankfurt.de by dbis.informatik.uni-frankfurt.de with smtp (Smail3.1.28.1 #4) id m0uik89-000BmsC; Tue, 23 Jul 96 18:16 MET DST Received: by atlas.rbi.informatik.uni-frankfurt.de (1.39.111.2/16.2) id AA148948577; Tue, 23 Jul 1996 18:16:17 +0200 From: zicari@informatik.uni-frankfurt.de Posted-Date: Tue, 23 Jul 1996 18:16:17 +0200 Received-Date: Tue, 23 Jul 1996 18:16:17 +0200 Message-Id: <199607231616.AA148948577@atlas.rbi.informatik.uni-frankfurt.de> Subject: Web Site To: Telecom.Int.1@dbis.informatik.uni-frankfurt.de Date: Tue, 23 Jul 1996 18:16:17 +0200 (METDST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 163 The full conference programs of Object World Frankfurt 96 and Internet Forum Europe 96 are on line at http://www.ltt.de Regards Roberto Zicari OWF/IFE Chair From rem-conf-request@es.net Tue Jul 23 13:53:32 1996 Received: from hera.rbi.informatik.uni-frankfurt.de by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 10:51:48 -0700 Received: from roma.dbis.informatik.uni-frankfurt.de by hera.rbi.informatik.uni-frankfurt.de with SMTP (1.38.193.4/16.2) id AA27033; Tue, 23 Jul 1996 18:20:35 +0200 Received: from atlas.rbi.informatik.uni-frankfurt.de by dbis.informatik.uni-frankfurt.de with smtp (Smail3.1.28.1 #4) id m0uik8U-000BnFC; Tue, 23 Jul 96 18:16 MET DST Received: by atlas.rbi.informatik.uni-frankfurt.de (1.39.111.2/16.2) id AA149008598; Tue, 23 Jul 1996 18:16:38 +0200 From: zicari@informatik.uni-frankfurt.de Posted-Date: Tue, 23 Jul 1996 18:16:38 +0200 Received-Date: Tue, 23 Jul 1996 18:16:38 +0200 Message-Id: <199607231616.AA149008598@atlas.rbi.informatik.uni-frankfurt.de> Subject: Web address To: Telecom.Int.2@dbis.informatik.uni-frankfurt.de Date: Tue, 23 Jul 1996 18:16:38 +0200 (METDST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 163 The full conference programs of Object World Frankfurt 96 and Internet Forum Europe 96 are on line at http://www.ltt.de Regards Roberto Zicari OWF/IFE Chair From rem-conf-request@es.net Tue Jul 23 14:09:57 1996 Received: from faui40.informatik.uni-erlangen.de by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 11:09:12 -0700 Received: from faui42.informatik.uni-erlangen.de (faui42.informatik.uni-erlangen.de [131.188.2.42]) by immd4.informatik.uni-erlangen.de with ESMTP id UAA16033 (8.7.5/7.5b-FAU); Tue, 23 Jul 1996 20:08:59 +0200 (MET DST) From: Toerless Eckert Message-Id: <199607231808.UAA16033@faui40.informatik.uni-erlangen.de> Subject: Re: Video Card Questions. To: ganzer@nosc.mil (Mark T. Ganzer) Date: Tue, 23 Jul 1996 20:08:57 +0200 (MET DST) Cc: Toerless.Eckert@Informatik.Uni-Erlangen.de, Charles.A.Ross@cc.gettysburg.edu, rem-conf@es.net In-Reply-To: from "Mark T. Ganzer" at Jul 21, 96 09:56:45 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 > Actually, if you enable the JPEG->H261 transcoder option in Vic ("Use JPEG > for H261" under Menu->Transmit->Options), the JPEG compression chip on the > Parallax card is enabled. However this is only an option if you are > running the Parallax card with pre-2.0 drivers. The Vic executables on > the LBL server were compiled with pre-2.0 Parallax libraries. Parallax > changed the JPEG encoding routines in their 2.0 drivers, and this results > in very low contrast images being transmitted. I knew about this JPEG->H261 transposer, but it never really worked when i tried it a couple of month ago. Nice to hear it's finally working. Parallax: Well, they just changed the Q-factor by a factor of 2. We got our own software to compile again with 2.5. Another interesting effect is that you now can only compress windows with X and Y sizes mod 8 == 0. Of course, Vic will not have problems with this. > I have had a few other non-Mbone related problems with the Parallax > PowerVideo card I was using (CDE on Solaris 2.5 wouldn't run, etc). Also, > the Parallax REQUIRES you to keep a "capture" window of what you are > transmitting open. This can take up an annoying amount of screen That's a feature of the hardware. > real-estate, which is often already tight when you have vic, vat, and wb > running at the same time. ON the plus side, the PowerVideo also provides > you with a 24-bit color frame-buffer if you machine doesn't already have > it (no more problems with dithering and running out of colors on an 8-bit > display). Well, all our Parallax machines (about 5) are dual headed with SX. best combination. Toerless From rem-conf-request@es.net Tue Jul 23 15:34:43 1996 Received: from mercury.acs.unt.edu by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 12:33:59 -0700 Received: from sol.acs.unt.edu (sol.acs.unt.edu [129.120.1.42]) by mercury.acs.unt.edu (8.7.1/8.7.1) with ESMTP id OAA16189; Tue, 23 Jul 1996 14:33:27 -0500 (CDT) Received: (from mstgil@localhost) by sol.acs.unt.edu (8.7.1/8.7.1) id OAA18405; Tue, 23 Jul 1996 14:33:25 -0500 (CDT) Date: Tue, 23 Jul 1996 14:33:24 -0500 (CDT) From: "Marc Ph. A. J. St.-Gil - UNIX/VAX Systems Manager" To: Jon Crowcroft cc: Masataka Ohta , Mark Handley , civanlar@att.com, rem-conf@osi-east.es.net, mrc@big.att.com Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: <538.838092585@cs.ucl.ac.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I thought this was supposed to be a conference reminders mailing list - not a low level protocol discussion list. What gives? Marc -- Marc St.-Gil, UNIX Systems Manager AKA: The UNIXMeister(tm) Academic Computing Services E-Mail: mstgil@unt.edu University of North Texas Voice: 817/565-3408 FAX: 565-4060 PO Box 13495, Denton TX, 76203-6495 WWW: http://www.unt.edu/~mstgil From rem-conf-request@es.net Tue Jul 23 19:47:08 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 16:46:36 -0700 Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 24 Jul 1996 00:45:58 +0100 From: Mark Handley X-Organisation: University College London, CS Dept. X-Phone: +44 171 419 3666 To: "Marc Ph. A. J. St.-Gil - UNIX/VAX Systems Manager" cc: rem-conf@osi-east.es.net Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Tue, 23 Jul 96 14:33:24 CDT." Date: Wed, 24 Jul 96 00:45:55 +0100 Message-ID: <8704.838165555@cs.ucl.ac.uk> Sender: M.Handley@cs.ucl.ac.uk >I thought this was supposed to be a conference reminders mailing list - >not a low level protocol discussion list. What gives? There is some history, but rem-conf is the official mailing list of the Audio/Video Transport working group of the IETF, so any RTP discussion should happen here. By common concensus, it's also used for mbone session announcements (as opposed to mbone engineering which happens on mbone@isi.edu) but that's really a secondary purpose, and normally the two are not contradictory. I hope the last week is an exception... Mark From rem-conf-request@es.net Tue Jul 23 21:08:20 1996 Received: from hera.rbi.informatik.uni-frankfurt.de by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 18:07:44 -0700 Received: from roma.dbis.informatik.uni-frankfurt.de by hera.rbi.informatik.uni-frankfurt.de with SMTP (1.38.193.4/16.2) id AA04280; Wed, 24 Jul 1996 03:02:53 +0200 Received-Date: Wed, 24 Jul 1996 03:02:53 +0200 Received: from central.cis.upenn.edu by dbis.informatik.uni-frankfurt.de with smtp (Smail3.1.28.1 #4) id m0uisLr-000BmsC; Wed, 24 Jul 96 03:02 MET DST Received: from graphics.cis.upenn.edu (GRAPHICS.CIS.UPENN.EDU [158.130.2.10]) by central.cis.upenn.edu (8.6.12/UPenn 1.4) with ESMTP id VAA04704; Tue, 23 Jul 1996 21:02:52 -0400 Received: from LOCALHOST by graphics.cis.upenn.edu id VAA24642; Tue, 23 Jul 1996 21:02:30 -0400 Posted-Date: Tue, 23 Jul 1996 21:02:30 -0400 Message-Id: <199607240102.VAA24642@graphics.cis.upenn.edu> To: zicari@hera.rbi.informatik.uni-frankfurt.de Cc: Telecom.Int.3@dbis.informatik.uni-frankfurt.de Reply-To: tnj@graphics.cis.upenn.edu X-Url: http://www.cis.upenn.edu/~tnj/home.html Subject: Re: Web site In-Reply-To: Your message of "Tue, 23 Jul 96 09:16:53 PDT." <199607231616.AA149068613@atlas.rbi.informatik.uni-frankfurt.de> Date: Tue, 23 Jul 96 21:02:30 -0400 From: "Timothy N. Jones" How many times are we going to see this message? How do I get off this mailing list, anyway? Tim In message <199607231616.AA149068613@atlas.rbi.informatik.uni-frankfurt.de> you write: > > The full conference programs of Object World Frankfurt 96 > and Internet Forum Europe 96 are on line at > > http://www.ltt.de > > Regards > > Roberto Zicari > > OWF/IFE Chair > From rem-conf-request@es.net Tue Jul 23 21:29:33 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 18:29:02 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA01643; Tue, 23 Jul 1996 18:28:52 -0700 Date: Tue, 23 Jul 1996 18:28:52 -0700 (PDT) From: Stephen Casner To: "M. Reha Civanlar" Cc: rem-conf@es.net Subject: Re: A new payload type for ligth-weight bundled MPEG In-Reply-To: <31F4ECDA.ABD322C@att.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reha, I wrote: > > I think we're talking past each other and not really connecting. and you responded: > As you recommended in your message, I forwarded your answer to my > previous message which did not appear on the mailing list because of my > mistake. If this caused an anachronism, I am sorry. Sorry, I was not clear. Your forwarding of my message was fine. What I meant was, I did not think either of us was convinced by the other's arguments on the 5 or so points that you've listed, so I was not going to go another round. However, I did want to make that one point about how RTP timestamps are calculated. > Are you still interested in a draft describing my packetization scheme? > If there is a strict decision about not including any mixed media > payloads other than the existing MPEG transport type as an RTP payload, > I am definitely not interested in wasting time. There is _not_ a strict decision to preclude any additional mixed media payloads. I am not personally in favor of them, but as AVT chairman I encourage proposals and discussion on whatever ideas people may have. Some may be clearly out of bounds, and may be declared closed (e.g., WG chairs are allowed to cut off an attempt to reopen an issue on which the working group has already held a debate and reached a conclusion). For this particular case, as I said before, I think "the market will decide" is a reasonable response. Now, there are several points that I think you must consider in this proposal. Each payload type has a fixed RTP timestamp clock rate associated with it. This is important for several reasons, one of which is that the RTP timestamps and jitter calculations in RTCP packets are based on that clock rate as well, and there is no place for a varying clock rate to be indicated. For third-party RTCP monitors to make sense of reception reports, the clock rate needs to not vary. Accordingly, I would argue strongly against a proposal in which the payload type in the RTP header essentially indicated that the payload contained multiple RTP packets (each with its own RTP timestamp) in some encapsulation and that the information in the outer RTP header was irrelevant. The RTCP packets would be associated with the outer RTP payload, and therefore the synchronization information as well as the reception information would probably be hard to relate to the real streams. I believe the bundled payload type only makes sense for a combined encoding, such as might come from a hardware encoder, where the timing of the individual media is all linked to a common clock. It really is one stream. That's why I favor using a dynamic payload type which indicates a particular combination of individual encodings rather than a format that allows specifying any separate payload types on the inside, which won't necessarily have a fixed timing relationship. This was my preference for the redundant audio format as well, but I lost that one. However, in that case, the clock is the same (I believe) for all the encodings and the format just includes timestamp offsets. Furthermore, I would think that the common clock for this combined stream should be directly related to the audio sample rate. Otherwise, off-by-one errors can be introduced when trying to calculate the proper playback position of the first audio sample in the packet, resulting in a one-sample gap or overlap. -- Steve From rem-conf-request@es.net Tue Jul 23 22:03:48 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 19:02:39 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA01729; Tue, 23 Jul 1996 19:02:37 -0700 Date: Tue, 23 Jul 1996 19:02:37 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Cc: "Marc Ph. A. J. St.-Gil - UNIX/VAX Systems Manager" Subject: Rem-conf mailing list; closing debate In-Reply-To: <8704.838165555@cs.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > >I thought this was supposed to be a conference reminders mailing list - > >not a low level protocol discussion list. What gives? As Mark Handley said, rem-conf is the official mailing list of the AVT working group. The list was created for the "Remote Conferencing BOF" in IETF, from which the AVT WG was a spin-off. The purpose of the rem-conf list is (was?) to discuss general issues in remote conferencing such as architectures, protocols and implementations. The list was also a convenient place for MBone session announcements, though the original list creators sometimes objected to the list being usurped for that purpose. At times, it has been suggested that the AVT WG move off to a list of its own, but I have resisted that because the group's work seemed nearly done and moving to a new list involves a non-trivial amount of inconvenience. Perhaps that was short-sighted, but given the publication of the RTP RFCs, now it seems more likely to be true. While I encourage discussion of RTP, I agree with Mark in hoping that the past few days were an unusual case. Therefore: --------------------------------------------------------------------- | | | As AVT chair, I wish to declare this debate regarding bundled | | versus unbundled streams closed. An invitation has been given | | for an Internet Draft describing the proposed bundled format. | | When that draft is completed so that we all can talk from a | | shared concrete basis rather than suppositions, and when the | | proposal has been implemented so advantages/disadvantages can | | be demonstrated, then we can make any necessary decisions. | |___________________________________________________________________| -- Steve From rem-conf-request@es.net Tue Jul 23 22:49:09 1996 Received: from necom830.hpcl.titech.ac.jp by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 19:48:33 -0700 From: Masataka Ohta Message-Id: <199607240248.LAA10741@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA10741; Wed, 24 Jul 1996 11:48:18 +0900 Subject: Re: "at any one time" and "media types" - clarification needed To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Wed, 24 Jul 96 11:48:17 JST Cc: mohta@necom830.hpcl.titech.ac.jp, M.Handley@cs.ucl.ac.uk, civanlar@att.com, rem-conf@osi-east.es.net, mrc@big.att.com In-Reply-To: <1313.838115308@cs.ucl.ac.uk>; from "Jon Crowcroft" at Jul 23, 96 10:48 am X-Mailer: ELM [version 2.3 PL11] Jon; > >FYI, table lookup of sinc function for audio is just a memory > >reference. > > do you mean sine function? No, I don't. It's sinc. The sinc function has a shape of sin(x)/x and is THE BASIC FUNCTION TO ADJUST THE SAMPLING FREQUENCY MISMATCH. Maybe, you are not the only person in this list who don't know sinc. But, it's really a waste of time to discuss digital multimedia communication with people who don't know how to adjust sampling frequencies. So, I kindly give you a homework. Study signal processing textbooks on how sampling frequency can be adjusted perfectly well and practically well enough without adding/dropping any data. Then, you must report the result to this list. Note that only a few typing errors will be allowed. After that, you may resume the current thread, if you think part of it is still meaningful. Until then, discussion on the thread with you is no meaningful. Masataka Ohta From rem-conf-request@es.net Tue Jul 23 23:22:25 1996 Received: from rah.star-gate.com by osi-east.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 20:21:39 -0700 Received: from rah.star-gate.com (localhost.cdrom.com [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id UAA00396; Tue, 23 Jul 1996 20:21:25 -0700 (PDT) Message-Id: <199607240321.UAA00396@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Mark Handley cc: "Marc Ph. A. J. St.-Gil - UNIX/VAX Systems Manager" , rem-conf@osi-east.es.net Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Wed, 24 Jul 1996 00:45:55 BST." <8704.838165555@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Jul 1996 20:21:24 -0700 From: Amancio Hasty Also if people have a decent mail reader is rather trivial to select all messages related to a topic and hit delete 8) Amancio From rem-conf-request@es.net Tue Jul 23 23:55:07 1996 Received: from necom830.hpcl.titech.ac.jp by osi-west.es.net with ESnet SMTP (PP); Tue, 23 Jul 1996 20:54:33 -0700 From: Masataka Ohta Message-Id: <199607240354.MAA11082@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA11082; Wed, 24 Jul 1996 12:54:18 +0900 Subject: Re: Rem-conf mailing list; closing debate To: casner@precept.com (Stephen Casner) Date: Wed, 24 Jul 96 12:54:17 JST Cc: rem-conf@es.net, mstgil@unt.edu In-Reply-To: ; from "Stephen Casner" at Jul 23, 96 7:02 pm X-Mailer: ELM [version 2.3 PL11] Steve; > | As AVT chair, I wish to declare this debate regarding bundled | > | versus unbundled streams closed. An invitation has been given | > | for an Internet Draft describing the proposed bundled format. | As I have an opinion that not all the AV combinations need to be supported and that the fewer encoding the better, the existing documents (RFC 1890 and draft-ietf-avt-mpeg-01.txt) are good enough to me. Are there anything wrong with MPEG2-TS? Masataka Ohta From rem-conf-request@es.net Wed Jul 24 03:33:22 1996 Received: from alpha.ntu.ac.sg by osi-east.es.net with ESnet SMTP (PP); Wed, 24 Jul 1996 00:32:01 -0700 Received: from 155.69.9.187 (155.69.9.187) by ntuvax.ntu.ac.sg (PMDF V5.0-6 #7636) id <01I7GEDUOHKWAJMUGV@ntuvax.ntu.ac.sg> for rem-conf@osi-east.es.net; Wed, 24 Jul 1996 15:02:14 +0800 Date: Wed, 24 Jul 1996 14:34:00 -0700 From: Yip Weng Sum Subject: (no subject) To: rem-conf@osi-east.es.net Message-id: <31F696C8.36D1@ntuvax.ntu.ac.sg> MIME-version: 1.0 X-Mailer: Mozilla 2.0 (Win16; I) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7bit SUBSCRIBE ------------------------------------------ Yip Weng Sum CE1/F4 sf7437867@ntuvax.ntu.ac.sg H6-35-4-667 9-4982547 ------------------------------------------ From rem-conf-request@es.net Wed Jul 24 04:47:59 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Wed, 24 Jul 1996 01:47:14 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 24 Jul 1996 09:46:40 +0100 To: Masataka Ohta cc: rem-conf@osi-east.es.net Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Wed, 24 Jul 1996 11:48:17 +0200." <199607240248.LAA10741@necom830.hpcl.titech.ac.jp> Date: Wed, 24 Jul 1996 09:46:33 +0100 Message-ID: <1282.838197993@cs.ucl.ac.uk> From: Jon Crowcroft >> >FYI, table lookup of sinc function for audio is just a memory >> >reference. >> do you mean sine function? >No, I don't. It's sinc. The sinc function has a shape of sin(x)/x and >is THE BASIC FUNCTION TO ADJUST THE SAMPLING FREQUENCY MISMATCH. oh, that sort of sinc, yes, i believe i've heard of that... >Maybe, you are not the only person in this list who don't know >sinc. um, its possible, unlikely, but possible - but since i do, i guess its impossible >But, it's really a waste of time to discuss digital multimedia >communication with people who don't know how to adjust sampling >frequencies. well, lets see - i didn't see any discussion - do you want to talk about the actual measured clock rate and phase error distributions found on audio devices and typical PC and workstation sysem clocks, versus the error rates for packet network inter-arrival rate variance.....do you have such figures for a particular (for example well engineered) piece of the internet - have you loiked at the papers by dave mills on system clocks, by jean bolot and jim kurose on mbone traffic loss/delay characteristics? there's some neat work out there.... >So, I kindly give you a homework. so kind....luckily i have a home, and some work, so this will fit in quite nicely. >Study signal processing textbooks on how sampling frequency can be >adjusted perfectly well and practically well enough without >adding/dropping any data. um, my advisors always suggest a _particular_ book when saying this sort of thing - do you have one in mind? >Then, you must report the result to this list. Note that only >a few typing errors will be allowed. what do i report to the list? stuff they can find in this book? stuff some of them know already? that would be a bit of a waste of bandwidth wouldn't it? >After that, you may resume the current thread, if you think part >of it is still meaningful. we've been told to lay off the thread, so sorry, no joy - you don't get me to explain something to you that you know already.... >Until then, discussion on the thread with you is no meaningful. ok - seems fair; i couldn't understand anything you said anyhow. i wonder if there is some other explanation for this.... jon From rem-conf-request@es.net Wed Jul 24 05:53:57 1996 Received: from VNET.IBM.COM by osi-east.es.net with ESnet SMTP (PP); Wed, 24 Jul 1996 02:53:19 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9978; Wed, 24 Jul 96 05:53:14 EDT Date: Wed, 24 Jul 96 12:49:24 IST From: Scott Petrack To: rem-conf@osi-east.es.net Subject: Papers on system clocks please? > have you loiked at the papers > by dave mills on system clocks Could you post a (some) reference(s) please? Even just a place to get started would be kind. If this is not appropriate for the list then just write to me. But I think it is. Sorry if this is super famous work. We all gotta start somewhere. Scott From rem-conf-request@es.net Wed Jul 24 09:06:11 1996 Received: from antares.mcs.anl.gov (actually mcs.anl.gov) by osi-east.es.net with ESnet SMTP (PP); Wed, 24 Jul 1996 06:05:33 -0700 Received: from mcs.anl.gov (putnam-atm.mcs.anl.gov [192.5.198.117]) by antares.mcs.anl.gov (8.6.10/8.6.10) with ESMTP id IAA23975; Wed, 24 Jul 1996 08:05:26 -0500 Message-Id: <199607241305.IAA23975@antares.mcs.anl.gov> To: Scott Petrack cc: rem-conf@osi-east.es.net Subject: Re: Papers on system clocks please? In-reply-to: Your message of "Wed, 24 Jul 1996 12:49:24 +0700." <199607241227.HAA23631@antares.mcs.anl.gov> Date: Wed, 24 Jul 1996 08:05:25 -0500 From: Bob Olson There are a bunch of pointers in http://www.eecis.udel.edu/~ntp/database/html_xntp3.5f/biblio.html. --bob From rem-conf-request@es.net Wed Jul 24 09:53:53 1996 Received: from ussenterprise.ufp.org by osi-west.es.net with ESnet SMTP (PP); Wed, 24 Jul 1996 06:53:12 -0700 Received: (bicknell@localhost) by ussenterprise.ufp.org (8.7.1/8.7.ufp) id JAA04643 for rem-conf@es.net; Wed, 24 Jul 1996 09:53:10 -0400 From: Leo Bicknell Message-Id: <199607241353.JAA04643@ussenterprise.ufp.org> Subject: Access-Virginia Broadcast To: rem-conf@es.net Date: Wed, 24 Jul 1996 09:53:09 -0400 (EDT) Reply-To: bicknell@ufp.org X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sorry for the short notice, my previous e-mail didn't make it. Today at 2PM EST there will be a broadcast of the Access Virginia statewide ATM network announcement. This network will be available to all state agency's as well as all educational institutions in the state. It will offer high speed access at distance insensitive prices. If there are any problems with this broadcast don't hesitate to contact me, I will be watching my mail box. -- 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 Wed Jul 24 10:48:36 1996 Received: from tis-mail.thepoint.net (actually tis-backup.thepoint.net) by osi-west.es.net with ESnet SMTP (PP); Wed, 24 Jul 1996 07:47:41 -0700 Received: by tis-mail.thepoint.net with Microsoft Exchange (IMC 4.0.837.3) id <01BB7944.49B84250@tis-mail.thepoint.net>; Wed, 24 Jul 1996 09:41:28 -0400 Message-ID: From: Arlie Davis To: "'rem-conf@es.net'" Cc: Arlie Davis , Michael Jung Subject: FW: "at any one time" and "media types" - clarification needed Date: Wed, 24 Jul 1996 09:40:13 -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 At least until now, the conversation has been thought-provoking and informative. Now, it appears as if it will degrade into a pissing contest. *sigh* Use of all caps is a sure sign. (Or is that "sin"? Ar ar ar...) -- arlie >---------- >From: Jon Crowcroft[SMTP:J.Crowcroft@cs.ucl.ac.uk] >Sent: Wednesday, July 24, 1996 4:46 AM >To: Masataka Ohta >Cc: rem-conf@osi-east.es.net >Subject: Re: "at any one time" and "media types" - clarification >needed > > > > >> >FYI, table lookup of sinc function for audio is just a memory > >> >reference. > >> do you mean sine function? > > >No, I don't. It's sinc. The sinc function has a shape of sin(x)/x and > >is THE BASIC FUNCTION TO ADJUST THE SAMPLING FREQUENCY MISMATCH. > >oh, that sort of sinc, yes, i believe i've heard of that... > > >Maybe, you are not the only person in this list who don't know > >sinc. [... deletia ...] From rem-conf-request@es.net Wed Jul 24 12:11:43 1996 Received: from mercury.acs.unt.edu by osi-east.es.net with ESnet SMTP (PP); Wed, 24 Jul 1996 09:11:06 -0700 Received: from sol.acs.unt.edu (sol.acs.unt.edu [129.120.1.42]) by mercury.acs.unt.edu (8.7.1/8.7.1) with ESMTP id LAA10360; Wed, 24 Jul 1996 11:10:53 -0500 (CDT) Received: (from mstgil@localhost) by sol.acs.unt.edu (8.7.1/8.7.1) id LAA29607; Wed, 24 Jul 1996 11:10:48 -0500 (CDT) Date: Wed, 24 Jul 1996 11:10:47 -0500 (CDT) From: "Marc Ph. A. J. St.-Gil - UNIX/VAX Systems Manager" To: Amancio Hasty cc: Mark Handley , rem-conf@osi-east.es.net Subject: Re: "at any one time" and "media types" - clarification needed In-Reply-To: <199607240321.UAA00396@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 23 Jul 1996, Amancio Hasty wrote: > Also if people have a decent mail reader is rather trivial to select > all messages related to a topic and hit delete 8) Actually, I'll use procmail to filter it out before it gets to my mbox... I was just curious. The name "rem-conf" is not very suggestive of the "one true purpose" here. 'nuf said Marc -- Marc St.-Gil, UNIX Systems Manager AKA: The UNIXMeister(tm) Academic Computing Services E-Mail: mstgil@unt.edu University of North Texas Voice: 817/565-3408 FAX: 565-4060 PO Box 13495, Denton TX, 76203-6495 WWW: http://www.unt.edu/~mstgil From rem-conf-request@es.net Wed Jul 24 13:54:06 1996 Received: from hillhouse.ckp.edu by osi-west.es.net with ESnet SMTP (PP); Wed, 24 Jul 1996 10:53:22 -0700 Received: (from queene@localhost) by hillhouse.ckp.edu (8.6.12/8.6.9) id NAA05262; Wed, 24 Jul 1996 13:52:50 -0400 Date: Wed, 24 Jul 1996 13:52:50 -0400 (EDT) From: Queene Cottingham To: Arlie Davis cc: "'rem-conf@es.net'" , Arlie Davis , Michael Jung Subject: Re: FW: "at any one time" and "media types" - clarification needed In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII calm down boys...... On Wed, 24 Jul 1996, Arlie Davis wrote: > At least until now, the conversation has been thought-provoking and > informative. Now, it appears as if it will degrade into a pissing > contest. *sigh* Use of all caps is a sure sign. (Or is that "sin"? > Ar ar ar...) > > -- arlie > > >---------- > >From: Jon Crowcroft[SMTP:J.Crowcroft@cs.ucl.ac.uk] > >Sent: Wednesday, July 24, 1996 4:46 AM > >To: Masataka Ohta > >Cc: rem-conf@osi-east.es.net > >Subject: Re: "at any one time" and "media types" - clarification > >needed > > > > > > > > >> >FYI, table lookup of sinc function for audio is just a memory > > >> >reference. > > >> do you mean sine function? > > > > >No, I don't. It's sinc. The sinc function has a shape of sin(x)/x and > > >is THE BASIC FUNCTION TO ADJUST THE SAMPLING FREQUENCY MISMATCH. > > > >oh, that sort of sinc, yes, i believe i've heard of that... > > > > >Maybe, you are not the only person in this list who don't know > > >sinc. > > [... deletia ...] > From rem-conf-request@es.net Wed Jul 24 22:30:15 1996 Received: from omega.ntu.ac.sg by osi-east.es.net with ESnet SMTP (PP); Wed, 24 Jul 1996 19:26:48 -0700 Received: from 155.69.9.193 (155.69.9.193) by ntuvax.ntu.ac.sg (PMDF V5.0-6 #7636) id <01I7HIVS42CGAJMWJM@ntuvax.ntu.ac.sg> for rem-conf@osi-east.es.net; Thu, 25 Jul 1996 10:22:00 +0800 Date: Thu, 25 Jul 1996 09:53:42 -0700 From: Yip Weng Sum Subject: subscript To: rem-conf@osi-east.es.net Message-id: <31F7A696.1CEF@ntuvax.ntu.ac.sg> MIME-version: 1.0 X-Mailer: Mozilla 2.0 (Win16; I) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7bit -- ------------------------------------------ Yip Weng Sum CE1/F4 sf7437867@ntuvax.ntu.ac.sg H6-35-4-667 9-4982547 ------------------------------------------ From rem-conf-request@es.net Thu Jul 25 03:38:33 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Thu, 25 Jul 1996 00:37:27 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA05873; Thu, 25 Jul 1996 00:37:24 -0700 Date: Thu, 25 Jul 1996 00:37:23 -0700 (PDT) From: Stephen Casner To: casner@precept.com Subject: What happened to att.com? Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII [This note sent to rem-conf in a Bcc so replies would not go there.] Does anyone know that happened to att.com or research.att.com? My message, summarizing this payload format discussion and inviting preparation of an Internet-Draft, is failing to be delivered to civanlar@att.com (attempts on two days). I don't want to appear as not having replied. -- Steve From rem-conf-request@es.net Thu Jul 25 03:40:49 1996 Received: from VNET.IBM.COM by osi-east.es.net with ESnet SMTP (PP); Thu, 25 Jul 1996 00:40:01 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7737; Thu, 25 Jul 96 03:39:52 EDT Date: Thu, 25 Jul 96 10:36:40 IST From: Scott Petrack To: rem-conf@osi-east.es.net Subject: Thanks, but I was hoping for system clocks and D/A clocks Thanks guys for all the pointers, you can stop now. It's true that I never really learned NTP and I see that I need to. But I was hoping that there might be some measurements about the relationship between system clocks and the clocks on peripheral cards (like audio cards, CTI cards, synchronous modems, etc.). Scott From rem-conf-request@es.net Thu Jul 25 05:18:30 1996 Received: from rah.star-gate.com by osi-east.es.net with ESnet SMTP (PP); Thu, 25 Jul 1996 02:17:24 -0700 Received: from rah.star-gate.com (localhost.cdrom.com [127.0.0.1]) by rah.star-gate.com (8.7.5/8.7.3) with ESMTP id CAA00692; Thu, 25 Jul 1996 02:17:11 -0700 (PDT) Message-Id: <199607250917.CAA00692@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Scott Petrack cc: rem-conf@osi-east.es.net Subject: Re: Thanks, but I was hoping for system clocks and D/A clocks In-reply-to: Your message of "Thu, 25 Jul 1996 10:36:40 +0700." <199607250854.BAA00511@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Jul 1996 02:17:10 -0700 From: Amancio Hasty >From The Desk Of Scott Petrack : > Thanks guys for all the pointers, you can stop now. It's true that I > never really learned NTP and I see that I need to. But I was hoping that > there might be some measurements about the relationship between system > clocks and the clocks on peripheral cards (like audio cards, CTI cards, > synchronous modems, etc.). Well PC soundcards are notorious for their clock timing in applications such as vat. Sound cards based on the cs4231 are okay since they have a function to calibrate the codec. You can pretty safely assume that depending on PC soundcards for timing measurements is a bad idea. Also full-duplex dma gets very interesting ... Amancio From rem-conf-request@es.net Thu Jul 25 08:20:30 1996 Received: from gpo.cc.bellcore.com by osi-west.es.net with ESnet SMTP (PP); Thu, 25 Jul 1996 05:19:37 -0700 Received: from itc.cc.bellcore.com by gpo.cc.bellcore.com with SMTP id AA20197 (5.67b/IDA-1.5 for ); Thu, 25 Jul 1996 08:07:37 -0400 Original-Received: from cc:Mail by itc.cc.bellcore.com id AA838307186 Thu, 25 Jul 96 08:06:26 EDT PP-warning: Illegal Received field on preceding line Date: Thu, 25 Jul 96 08:06:26 EDT From: shh Message-Id: <9606258383.AA838307186@itc.cc.bellcore.com> To: a.galis@eleceng.ucl.ac.uk, cnom@maestro.bellcore.com, nhe@postman.dg13.cec.be, announcements.chi@xerox.com, arl@arl1.wustl.edu, arpanet-bboard@mc.lcs.mit.edu, atm@bbn.com, bcs-hci-request@mailbase.ac.uk, ccrc@dworkin.wustl.edu, cellular@dfv.rwth-aachen.de, cip@bbn.com, cybsys-l@bingvmb.cc.binghamton.edu, diagrams@cs.swarthmore.edu, elsnet-list@cogsci.ed.ac.uk, end2end-interest@isi.edu, enternet-ec@bbn.com, enternet@bbn.com, f-troup@aurora.cis.upenn.edu, 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, kdd@gte.com, perform@tay1.dec.com, rem-conf@es.net, sig11@roses.stanford.edu, sigmedia@bellcore.com, smds@cnri.reston.va.us, sound@acm.org, tf-mm@i4serv.informatik.rwth-aachen.de, uist.chi@xerox.com, visual-l@vtvm1.cc.vt.edu, xtp-relay@cs.concordia.ca, commsoft@cc.bellcore.com, utheorynt@vm1.nodak.edu, ietf-announce@cnri.reston.va.us, cost237-transport@comp.lancs.ac.uk, batnir@agcs.com, klaus.baumer@telekom.dbp.de, besier@eurescom.d400.de, vab@cc.bellcore.com, /dd.fax=14079558015/G=Stephen/S=Cannon/ADMD=MCI/C=US/@qmx400gate.nt.com, laura.cerchio@cselt.stet.it, j.cheong@trl.oz.au, TAIR%TL9000@nt.com, Edwin.Frank.Crabill@att.att.com, DCrosby@VTRLMEL1.TRL.OZ.AU, /dd.id=ME.Cullum/ADMD=TELECOM.CANADA/C=CA/@qmx400gate.nt.com, dick.dodd@bridge.bst.bls.com, adoughe@Gateway.Uswnvg.COM, javan@comm.toronto.edu, fulvio.faraci@MacPost.cselt.stet.it, igorf@arch4.att.com, rlfike@aol.com, fogarty@eurescom.d400.de, larryg@arch4.att.com, edgar@tid.es, geradsd@agcs.com, bur_goode@vnet.ibm.com, gotz@cc.bellcore.com, epa.epacdh@memo3.ericsson.se, bich@cc.bellcore.com, epa.epajkj@memo3.ericsson.se, roberto.kung@issy.cnet.fr, kusaura@krsun.nslab.ntt.jp, hlu@arch4.att.com, kjl@cc.bellcore.com, ilka@prz.tu-berlin.de, mukasa@ast.lab.kdd.co.jp, niitsu@krsun.nslab.ntt.jp, oyamada@krsun.nslab.ntt.jp, etienne.paul@issy.cnet.fr, ieeetcpc@ccvm.sunysb.edu, swami@cc.bellcore.com, roberto.saracco@cselt.stet.it, seb@cc.bellcore.com, cjs1@psp.att.com, hikaru@kopenews.nslab.ntt.jp, 0002912712@mcimail.com, /dd.id=towaij.s/ADMD=TELECOM.CANADA/C=CA/@qmx400gate.nt.com, brunosv@cpqd.br, waecdb@aur.alcatel.com, Carl.@eleceng.ucl.ac.uk Subject: Re: From rem-conf-request@es.net Thu Jul 25 18:57:55 1996 Received: from maxwell.ucsf.EDU by osi-west.es.net with ESnet SMTP (PP); Thu, 25 Jul 1996 15:57:15 -0700 Received: by maxwell.ucsf.EDU (4.1/GSC4.23) id AA02166; Thu, 25 Jul 96 15:57:11 PDT Date: Thu, 25 Jul 96 15:57:11 PDT From: rodgers@maxwell.ucsf.EDU (R. P. C. Rodgers, M.D.) Message-Id: <9607252257.AA02166@maxwell.ucsf.EDU> To: rem-conf@es.net Subject: Used Sun VideoPix card for sale Dear Colleagues, We have one used Sun VideoPix card (Sun part X218) available for sale at $150 in original packaging with full documentation and drivers for SunOS and Solaris 2.3/4 (buyer to pay shipping); pardon my posting this here, but past mailings to the list suggest that some folks are eager to find these for older machines that won't support some of the newer boards. Cheerio, Rick Rodgers From rem-conf-request@es.net Thu Jul 25 20:55:47 1996 Received: from precept.com (actually hydra.precept.com) by osi-east.es.net with ESnet SMTP (PP); Thu, 25 Jul 1996 17:55:07 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA07811; Thu, 25 Jul 1996 17:54:57 -0700 Date: Thu, 25 Jul 1996 17:54:56 -0700 (PDT) From: Stephen Casner To: Scott Petrack Cc: rem-conf@osi-east.es.net Subject: Re: Thanks, but I was hoping for system clocks and D/A clocks In-Reply-To: <9607250825.AA05938@precept.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > But I was hoping that > there might be some measurements about the relationship between system > clocks and the clocks on peripheral cards (like audio cards, CTI cards, > synchronous modems, etc.). I'm not sure what you mean by measurements. I mean, I've seen errors on the order of 1 to 2% on some popular but pathetic hardware, but I expect you've made those same observations. An interesting part of NTP that may be in line with what you are thinking are the algorithms for operating an accurate virtual clock based on a hardware clock of less accuracy. The same ideas are useful in tracking the relationship between system clocks and audio clocks. -- Steve From rem-conf-request@es.net Fri Jul 26 05:43:58 1996 Received: from internet-gw.zurich.ibm.com (actually internet-gw.zurich.ibm.ch) by osi-west.es.net with ESnet SMTP (PP); Fri, 26 Jul 1996 02:43:05 -0700 Received: from emme.zurich.ibm.com by internet-gw.zurich.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA13268 from ; Fri, 26 Jul 1996 11:42:51 +0200 Received: from ahoreli.zurich.ibm.com by emme.zurich.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA44522 from ; Fri, 26 Jul 1996 11:42:50 +0200 Return-Path: Received: from salo.zurich.ibm.com by ahoreli.zurich.ibm.com (AIX 3.2/UCB 5.64/ZuriNotes0.9) id AA14576; Fri, 26 Jul 1996 11:41:54 +0200 Received: by salo.zurich.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.14/2.12um) id AA8088; Fri, 26 Jul 96 11:38:59 +0200 Message-Id: <9607260938.AA8088@salo.zurich.ibm.com> Received: by Zurich (Lotus Notes Mail Gateway for SMTP V1.1) id E483C483BBFCE9EDC125636F005FC1A9; Fri, 26 Jul 96 11:11:47 To: cnom , nhe , "announcements.chi" , arl , arpanet-bboard , atm , bcs-hci-request , ccrc , cellular , cip , cnom , cybsys-l , diagrams , elsnet-list , end2end-interest , enternet-ec , enternet , f-troup , g-troup , globecom , hipparch , icad-request , ie-list , ietf , ikbsbb , iplpdn , kdd , perform , rem-conf , sig11 , sigmedia , smds , sound , tf-mm , "uist.chi" , visual-l , xtp-relay , commsoft , cnom , utheorynt , ietf-announce , sigmedia , ccrc , ie-list , cost237-transport , arpanet-bboard , atm , batnir , "klaus.baumer" , besier , vab , "/dd.fax=14079558015/G=Stephen/S=Cannon/ADMD=MCI/C=US /" , "laura.cerchio" , "j.cheong" , TAIR , cnom , "Edwin.Frank.Crabill" , DCrosby , "/dd.id=ME.Cullum /ADMD=TELECOM.CANADA/C=CA/" , "dick.dodd" , adoughe , enternet , javan , "fulvio.faraci" , igorf , rlfike , fogarty , larryg , edgar , geradsd , bur_goode , gotz , "epa.epacdh" , bich , "epa.epajkj" , "roberto.kung" , kusaura , hlu , kjl , ilka , mukasa , niitsu , oyamada , "etienne.paul" , ieeetcpc , swami , commsoft , "roberto.saracco" , seb , cjs1 , hikaru , 0002912712 <0002912712@mcimail.com>, "/dd.id=towaij.s/ADMD=TELECOM.CANADA/C=CA/" From: Dieter Gantenbein/Zurich/IBM Date: 22 Jul 96 19:28:47 Subject: -No Subject- Mime-Version: 1.0 Content-Type: Text/Plain War@nt.com, comswtc@gmu.edu, giga@tele.pitt.edu, enternet@bbn.com, ifip-nm@bbn.com, cnom@maestro.bellcore.com, nmf-members@nmf.com, netmgt@ncri.com, sig-dsm@doc.imperial.ac.uk, netmgt@ncri.com, enternet@bbn.com, dsm@nemo.ncsl.nist.gov, nmsig@nemo.ncsl.nist.gov, aow-nmsig@stc.ipa.go.jp, ewos-egnm@extend.iihe.ac.be, snmsigl@nemo.ncsl.nist.gov, noms96@joker.bellcore.com, corpcom@osf.org, nmf-members@nmf.org, ifip-emailmgt@ics.uci.edu, snmp@psi.com, nadism@mbunix.mitre.org, mitre-osi@bistromath.mitre.org, nsm-info@gateway.mitre.org, x3t54@mbunix.mitre.org, nmsig@ics.uci.edu, rwnmcc@external.iihe.rtt.be, OSIMIS@cs.ucl.ac.uk, ietf-madman@innosoft.com, nms@netmgrs.co.uk, iimc@thumper.bellcore.com, OVForum@andrew.cmu.edu, ieeetcpc@ccvm.sunysb.edu, commsoft@cc.bellcore.com, comswtc@gmu.edu, isinm97_oc@ctr.columbia.edu, news.announce.conferences%USENET@maestro.bellcore.com, ieee.announce@bellcore.com, comp.protocols.snmp%USENET@maestro.bellcore.com, comp.protocols.iso@bellcore.com, comp.org.ieee%USENET@maestro.bellcore.com, barrere@irit.fr, benzekri@irit.fr, bergougn@irit.fr, betourne@irit.fr, castanet@labri.u-bordeaux.fr, courtiat@laas.fr, cousin@irisa.fr, diaz@laas.fr, fdida@masi.ibp.fr, filali@irit.fr, fourneau@masi.ibp.fr, horlait@masi.ibp.fr, jard@irisa.fr, jezequel@irisa.fr, juanole@laas.fr, mbl@lri.lri.fr, plateau@imag.imag.fr, Guy.Pujolle@prism.uvsq.fr, rafiq@crisv2.univ-pau.fr, raynal@irisa.fr, raynaud@irit.fr, trehel@comte.univ-fcomte.fr, hipparch@sophia.inria.fr, lib@comte.univ-fcomte.fr, prs@uvsq.fr, prs@masi.ibp.fr, tous.rumeur@lip.ens-lyon.fr, alg@comm.toronto.edu, BM-List1@cs.ucdavis.edu, cellular@dfv.rwth-aachen.edu, cnom@maestro.bellcore.com, comsoc.bog@tab.ieee.org, comsoc-gicb@ieee.org, commsoft@cc.bellcore.com, comswtc@gmu.edu, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, enternet@bbn.com, forte@informatik.uni-kl.de, gcomlist1@manjaro.ece.iit.edu, giga@tele.pitt.edu, ieeetcpc@ccvm.sunysb.edu, ieee_rtc_list@cs.tamu.edu, isadsoc@fokus.gmd.de, modern-heuristics@uk.ac.mailbase.ucdavis.edu, multicomm@cc.bellcore.com, osimcast@bbn.com, reres@comm.polymtl.ca, reres@uklirb.informatik.uni-kl.de, sc6wg4@ntd.comsat.com, sigmedia@bellcore.com, tccc@cs.umass.edu, testnet@canarie.ca, xtp-relay@cs.concordia.ca From: a.galis (Alex Galis) Subject: GLOBCOM'96 - London U.K. / 18-22 November 1996 Cc: a.galis@busby, c.todd@busby Dear All, In the name of the Organising Committee I am pleased to invite you to attend GLOBCOM'96 Telecommunications Conference organised by IEEE in London ( 18th - 22nd November 1996). Yours sincerely Alex Galis University College London ............................................................................ ........................... 1996 IEEE GLOBAL TELECOMMUNICATIONS CONFERENCE 18th - 22nd November 1996 Queen Elizabeth II Conference Centre, Westminster, London "Communications: The Key to Global Prosperity" This major international communications conference, held annually for some 25 years, is to be hosted in London for its first staging in Europe. Sponsored by the IEEE Communications Society and in conjunction with the IEE, Globecom 96 aims to attract 1000+ of the leading telecommunication development engineers, academics, operators and manufacturers from all parts of the world. The Conference will consist of 50 Technical Sessions (in 9 parallel tracks), 6 Sessions of a Mini-Conference on Communications Theory, 4 Sessions of a Mini-Conference called "IEEE Global Internet '96" and 4 Panel Session discussions on key Business Topics over the 3 days (Tuesday 19th, Wednesday 20th and Thursday 21st November 1996). On Monday 18th and Friday 22nd November there will be some 27 half-day equivalent sessions devoted to Tutorials and Workshops on key Hot Topics. Throughout the week there will be a 20 stand Exhibition of sponsoring companies, publishers and future ComSoc Conferences. In addition there will be a separate Exhibition on Internet and related telecomms topics. Hot Topics The Hot Topics below have been identified by the ComSoc Technical Committees. These titles have been accepted by the Globecom '96 Technical Programme Committee as forming a basis on which to assemble Technical Session and Tutorials etc. - Advances in PCS - Wireless ATM - Advanced switching architectures for broadband networks - Network issues in wireless communications - Distributed Software Challenges - Software Support for Interactive MultiMedia Services and Applications - Wireless Communication and ATM - Towards ATM Switching Systems with Terabit/s Capacity - Signal Processing for Multimedia Services - Advanced VLSI Signal Processing in Communications - Quality of service for advanced communication services (PCS, Multimedia, Internet) - Software engineering technologies and experience to Improve and sustain network quality objectives - Mobile Satellite Communications - Satellite Communications for Broadband Networks - Security and Privacy in the GII/NII - Multicasting - Multimedia over the Internet - Interactive Video Applications and Supporting Technologies - Optical Access Networks and New Services Development - Very High-Speed ( OC-192) Optical Transmission Panel Sessions These will consist of short presentations followed by discussion, lead by a group of the leading Global Players on the Topics of:- 1. Visions of the 21st Century 2. Wireless revolution towards global roaming 3. The Information highway - market and service provider perspectives 4. Service and quality: customer's perceptions Tutorials and Workshops - mixture of full and half day Sessions The titles and leaders are: Monday tutorials and workshop T01 Telecommunications Management Network:- Standards, Implementation and Applications (Veli Sahin, NEC America Inc) T02 Introduction to ATM (Khosrow Sohraby, IBM) T03 GSM - Recent Advances and Future Developments (Paul Kakaes, Cosmos Communications Consulting) T04 Traffic Modelling and Management in Wireless Communications Systems (am) (Sirin Tekinay, Bell Northern Research) T05 Modelling and Transmission issues for VBR video over B-ISDN Networks (am) (Dr Ghanbari, University of Essex) T06 High Speed Wireless Data (Len Cimini, AT&T Bell Laboratories and Andrea Goldsmith, California Institute of Technology) T07 JAVA (Prof John N Daigle) T08 The Intelligent Network and Mobile System Control (pm) (Prof Bijan Jabbari, George Mason University) T09 Iterative Turbo-Decoding (pm) (Joachim Hagenauer, TU Munich) T10 Interactive Multimedia over the Internet (pm) (Mark Handley and Ian Wakemen, UCL and Sussex University) W01 Very-high-speed Digital Subscriber Lines (Prof John M Cioffi, Stanford University) Friday tutorials and workshop T11 Mobile and Multimedia Satellite Systems (Dr K M S Murthy, VISTAR Telecommunications) T12 Spread Spectrum Systems for PCS (Elvino S Sousa, University of Toronto) T13 Mobility Management in TCP/IP Networks (Dr Zygmunt Haas, Cornell University) T14 Operation and Management of Multi-Wavelength Optical Networks (am) (Dr Mari Maeda, Bell Communications Research) T15 Internet IP Security (am) ( Ran Atkinson, Internet Security) T16 Adaptive Antennas for Wireless Systems (pm) (Jack Winters, AT&T Bell Laboratories) T17 IP and ATM - Enterprise Internetworking (pm) (David Ginsburg, CISCO Corp) W02 Transport Protocols for High-Speed Broadband Networks (Douglas J Hoder, NASA) Although the Call-for-Paper deadline is March 1st 1996, further details of the Globecom 96 Technical Programme are available from Professor Hamid Aghvami, Tel: + 44 171 873 2898, Fax: + 44 171 836 4781, E-mail: h.aghvami@kcl.ac.uk CO1 Mini-Conference - Communications Theory This will consist of 6 Sessions running as a separate stream in parallel with the Main Sessions from Tuesday 19th to Thursday 21st November. For further details contact General Chair, F Marvasti at fam@orion.eee.kcl.ac.uk or for Call for Papers contact the Technical Programme Chair, Enzin Bigliori at biglieri@polito.it C02 Mini-Conference - IEEE Global Internet '96 This will consist of Technical Sessions, Panel Sessions, Tutorials, Keynote Speeches and major player Demonstrations and Exhibits on the subject of the Internet. The main sessions of the mini-conference are on Wednesday 20th and Thursday 21st November. If successful, this may be the first of a new annual IEEE ComSoc Conference on the topic. For further details contact John Crowcroft at j.crowcroft@cs.ucl.ac.uk London has of course, many tourist attractions and shopping facilities. Opposite the Queen Elizabeth II Conference Centre (QEIICC) is Westminster Abbey with the Houses of Parliament, Whitehall, Trafalgar Square, Buckingham Palace and St. James s Park all within close walking distance. Globecom 96 have organised a range of tours and social functions. These are:- SO1-Panoramic London Tour - Monday 18th (am) and Wednesday 20 November (pm) SO2-St James's Walking Tour - Monday 18th (am) SO3-Churchill War Rooms - two tours organised for Tuesday 19th November (am or pm) SO4-Westminster Abbey - two tours organised for Tuesday 19th November (am or pm) SO5-Thames Dinner Cruise - Tuesday 19th November (evening) SO6-Windsor Castle and Runnymede - Wednesday 20th November (am) SO7-Stratford-upon-Avon and Oxford - Thursday 21st November (all day) Three post conference tours to Edinburgh(PO1), Paris(PO2) and Bath(PO3) have also been organised commencing Friday 22nd to Sunday 24th November. On Tuesday 19th November there will be an IEEE Awards Luncheon in the QEIICC and on Wednesday evening (20th November) a Conference Banquet will be held in the Banqueting Suite of Whitehall Palace which was built in 1620 for King James 1st of England and Scotland. Some 1000 bedrooms have been reserved in the area of the QEIICC, all within 10-20 minutes walk or 2-3 stops on the Underground - Circle Line - nearest stations St. James's Park and Westminster. Prices range from ?30 - ?120 per night per room. Heathrow and Gatwick Airports, near London, between them serve more International Destinations and Passengers than anywhere else. Special discounted airfares are available from British Airways, when booking through one of their offices and quoting reference CIC*115/30. Within London, the network of Tube Trains, Buses and Taxis offer frequent services to all local destinations. Fuller, updated information is available via the Globecom '96 WWW homepage, see: http://www.labs.bt.com/profsoc/globecom/ If you would like a copy of the Early Registration form faxed to you, please complete your details below and return via mail, fax or e-mail to Jane Chopping (as below). Note that a version of the Registration form will appear on the WWW pages above from mid June '96. ---------------------------------------------------------------------------- ---------------------------------------- To: Jane Chopping IEE Conference Tel: +44 171 344 5469 Savoy Place Fax: +44 171 497 3633 London E-mail: jchopping@iee.org.uk WC2R 0BL, UK ---------------------------------------------------------------------------- ---------------------------------------- FULL NAME AND TITLE: JOB/POSITION: COMPANY/UNIVERSITY: ADDRESS: CITY/STATE: POSTCODE/ZIP CODE: COUNTRY: TELEPHONE NUMBER: FAX NUMBER: E-MAIL ADDRESS: From rem-conf-request@es.net Fri Jul 26 08:07:10 1996 Received: from nusunix2.nus.sg by osi-west.es.net with ESnet SMTP (PP); Fri, 26 Jul 1996 05:06:10 -0700 Received: from leonis.nus.sg (engp4369@leonis.nus.sg [137.132.1.18]) by nusunix2.nus.sg (8.7.5/8.7.3) with ESMTP id UAA12494 for ; Fri, 26 Jul 1996 20:05:00 +0800 Received: from localhost (engp4369@localhost) by leonis.nus.sg (8.6.10/8.6.9/CNS-3.5) with SMTP id UAA05189 for ; Fri, 26 Jul 1996 20:04:59 +0800 Date: Fri, 26 Jul 1996 20:04:59 +0800 (SST) From: Lew Chai Seck To: rem-conf@es.net Subject: unsubscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I would like to unsubscribe from the list. ==================================================================== Lew Chai Seck National University of Singapore email address : engp4369@leonis.nus.sg cslew@mip.ee.nus.sg cslew@eeserver.nus.sg ==================================================================== From rem-conf-request@es.net Fri Jul 26 11:53:28 1996 Received: from aware.com (actually amaterasu.aware.com) by osi-west.es.net with ESnet SMTP (PP); Fri, 26 Jul 1996 08:52:37 -0700 Received: from ariadne.aware.com by aware.com (4.1/SMI-3.2) id AA19829; Fri, 26 Jul 96 11:51:45 EDT Received: by ariadne.aware.com (5.x/SMI-SVR4) id AA09605; Fri, 26 Jul 1996 11:53:57 -0400 Date: Fri, 26 Jul 1996 11:53:57 -0400 From: shapiro@aware.com (Jerry Shapiro) Message-Id: <9607261553.AA09605@ariadne.aware.com> To: rem-conf@es.net X-Sun-Charset: US-ASCII subscribe shapiro@aware.com From rem-conf-request@es.net Fri Jul 26 13:00:28 1996 Received: from edelweb.fr by osi-west.es.net with ESnet SMTP (PP); Fri, 26 Jul 1996 09:59:46 -0700 Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (8.7.1/8.6.9) with ESMTP id SAA05967; Fri, 26 Jul 1996 18:59:36 +0200 (MET DST) Received: from mercier (mercier.gctech.edelweb.fr [193.51.14.7]) by champagne.edelweb.fr (8.6.10/8.6.6) with SMTP id SAA21339; Fri, 26 Jul 1996 18:59:35 +0200 Sender: guest@champagne.edelweb.fr Message-ID: <31F8F977.41C67EA6@edelweb.fr> Date: Fri, 26 Jul 1996 18:59:35 +0200 From: Emmanuel Cerisier X-Mailer: Mozilla 3.0b5a (X11; I; SunOS 4.1.4 sun4m) MIME-Version: 1.0 To: Jerry Shapiro CC: rem-conf@es.net Subject: Re: References: <9607261553.AA09605@ariadne.aware.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jerry Shapiro wrote: > > subscribe shapiro@aware.com me too ! ;-) -- Emmanuel. From rem-conf-request@es.net Sat Jul 27 08:11:33 1996 Received: from hillhouse.ckp.edu by osi-west.es.net with ESnet SMTP (PP); Sat, 27 Jul 1996 05:10:45 -0700 Received: (from brandon@localhost) by hillhouse.ckp.edu (8.6.12/8.6.9) id IAA26500; Sat, 27 Jul 1996 08:10:43 -0400 Date: Sat, 27 Jul 1996 08:10:43 -0400 (EDT) From: Brandon Pamplin cc: rem-conf@es.net Subject: Re: In-Reply-To: <31F8F977.41C67EA6@edelweb.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII unsubscribe me.....brandon@hillhouse.ckp.edu %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % Brandon Pamplin brandon@hillhouse.ckp.edu % % http://hillhouse.ckp.edu/~brandon % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% From rem-conf-request@es.net Sun Jul 28 06:38:52 1996 Received: from lowell.ecn.purdue.edu by osi-west.es.net with ESnet SMTP (PP); Sun, 28 Jul 1996 03:37:20 -0700 Received: from lowell.ecn.purdue.edu (salama@localhost) by lowell.ecn.purdue.edu (8.7.5/3.8.1davy) for delivery to "rem-conf@es.net" id FAA15514; Sun, 28 Jul 1996 05:37:08 -0500 (EST) Message-Id: <199607281037.FAA15514@lowell.ecn.purdue.edu> Date: Sun, 28 Jul 1996 05:37:08 -0500 (EST) From: Paul Salama To: rem-conf@es.net Subject: unsubscribe X-Sun-Charset: US-ASCII unsubscribe Please unsubscribe me Thank you Paul From rem-conf-request@es.net Sun Jul 28 18:08:33 1996 Received: from VNET.IBM.COM by osi-east.es.net with ESnet SMTP (PP); Sun, 28 Jul 1996 15:07:51 -0700 Received: from HAIFASC3 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2257; Sun, 28 Jul 96 02:02:33 EDT Date: Sun, 28 Jul 96 08:08:24 IST From: Scott Petrack To: casner@precept.com, rem-conf@osi-east.es.net Subject: Thou shalt be reasonable Steve, > I think what you've written is pretty much right. > >> 3. Thou shalt be reasonable w.r.t. other kinds of >> multiplexing, interleaving, and encoding switching. > >This one is true but not very speific. If reasonable multiplexing >means using multiple UDP ports, then sure. If this is regarding the >SSRC and payload type, then I'd just reduce rule 3 to: > >3. Thou shalt be reasonable w.r.t. encoding switching. You gave a few examples where there were multiple "full streams" of same-encoded media within a single session, multiplexed by SSRC only. The streams really were multiplexed or interleaved. There was no encoding switching. My point in my version of rule 3 was that indeed there is another way to multiplex than the "usual" way via UDP port, at least for certain applications. At least one other way, in any case. But if you use this other way, you'd better have a good reason. (Like that all the packets will be combined within the same process for presentation). If indeed one can say that there are only two kinds of acceptable multiplexing - via different sessions or via SSRC within the same session, then I'd rather make rule 3. saying precisely this. I wrote the more general version because I got the impression that there were a set of multiplexing and interleaving possibilities that were *not* just UDP ports but that would be considered reasonable for certain applications. Maybe now that there is a notion of "RTP context" (for compression) is address+port+SSRC, then you want to say that you can multiplex/interleave only via "RTP contexts." Within a context you can only switch encodings. Scott From rem-conf-request@es.net Sun Jul 28 20:25:19 1996 Received: from gateway-gw.pictel.com by osi-east.es.net with ESnet SMTP (PP); Sun, 28 Jul 1996 17:24:34 -0700 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA27955; Sun, 28 Jul 96 20:24:21 EDT Received: from magicland.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA16526; Sun, 28 Jul 96 20:24:19 EDT Received: from magicland.pictel.com by magicland.pictel.com (SMI-8.6/SMI-SVR4) id UAA16506; Sun, 28 Jul 1996 20:22:18 -0400 Message-Id: <2.2.32.19960729001946.00a20b70@magicland.pictel.com> X-Sender: webberr@magicland.pictel.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Jul 1996 20:19:46 -0400 To: "M. Reha Civanlar" , Bob Webber From: Bob Webber Subject: Re: standards clarification Cc: rem-conf@osi-east.es.net At 11:04 AM 7/23/96 -0400, M. Reha Civanlar wrote: >Bob Webber wrote: > >> In videoconferencing, for example, a number of >> manufacturers' approaches to the problem were left out, but the standard >> survives nonetheless. >> > >I would like to point out the difference between hardware bound >applications and software applications. The video conferencing standards >that you are referring to are, so far, hardware bound. Since the number >of users is the main determinant of the price of hardware, it is >beneficial to stick with a reasonable standard. On the other hand, when >SW only codecs become good enough, we can always load and run the new >and better applications whether they are standard or not. Yes, you can, but you can't say that they're compliant: nobody will try to stop you from experimenting with new formats and discovering/showing which is better. Interestingly, to me your comment suggests that software doesn't derive a benefit from sticking "with a reasonable standard." Admittedly, you can always add more modules to handle more variations in software up to the limit of the memory in your workstation, but those new software modules are not "free" of complexity (or presumably cost to somebody, if only the developer. They make standard compliance a more complex matter if they are included, they make the standard more complex (since most modes are based on a single idea of best practice, but some on some other idea) and harder to read and implement. ... >What I am saying is that I have an application that benefits from a >slight extension to the standard. There are several others that agree >with me, and since both sides of the issue have supporters, it should be >left to the market to make the final decision. On the other hand, if a >proposed standard is to be protected strictly and religiously, several >applications will look for other ways out. And if they succeed, the market will have proven the standard incorrect and the standard will be superseded or changed. At the moment, arguments about the packetization standards are centered around technical issues, and some experts believe that mixed media types in a packet are a bad idea. If those experts are right, then applications which "look for other ways out" may not do very well in the market. If they are wrong, they'll have egg on their faces and those wanting mixed-media packets can point this out. Since the standard supports dynamic payload types, it is possible for vendors with mixed-media packets to try out their technology and actually find out how the market reacts. In the meantime, it's necessary to convince the experts with technical arguments, as Mr Ohta seems to be attempting to do. If the experts can't be convinced that it's a good idea, why should they support putting a bad idea into the standard? Bob From rem-conf-request@es.net Mon Jul 29 10:36:59 1996 Received: from bnr.ca (actually x400gate.bnr.ca) by osi-east.es.net with ESnet SMTP (PP); Mon, 29 Jul 1996 07:36:20 -0700 X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 29 Jul 1996 10:35:00 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 29 Jul 1996 09:56:25 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 29 Jul 1996 09:53:00 -0400 Date: Mon, 29 Jul 1996 09:53:00 -0400 X400-Originator: /dd.id=1663884/g=vivek/i=v/s=kapil/@bnr.ca X400-MTS-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.520:29.06.96.13.56.25] X400-Content-Type: P2-1984 (2) Content-Identifier: Charts from M... From: "vivek (v.) kapil" Sender: "vivek (v.) kapil" Message-ID: <"29026 Mon Jul 29 10:12:32 1996"@bnr.ca> To: rem-conf@osi-east.es.net Subject: Charts from MMUSIC and AVT WGs Folks, I was wondering if the charts presented at these working groups or related BOFs are already available at some server. Please let me know. Regards, \\\// -(@ @)- ------------------oOO--(_)--OOo---------------------- Vivek Kapil, Internet Business Solutions Nortel Technology E-mail: vkapil@nortel.ca (bus) ak982@freenet.carleton.ca (res) ------------------------------------------------------ From rem-conf-request@es.net Mon Jul 29 15:47:48 1996 Received: from george.lbl.gov (actually george-2.lbl.gov) by osi-west.es.net with ESnet SMTP (PP); Mon, 29 Jul 1996 12:45:15 -0700 Received: (deba@localhost) by george.lbl.gov (8.6.10/8.6.5) id MAA20108; Mon, 29 Jul 1996 12:44:07 -0700 From: Deb Agarwal Message-Id: <199607291944.MAA20108@george.lbl.gov> Subject: Demonstration of MBONE for UCOP . . . To: rem-conf@es.net Date: Mon, 29 Jul 1996 12:44:06 -0700 (PDT) Cc: johnston@george.lbl.gov (Bill Johnston-Lawrence Berkeley Laboratory-ITG), tgill@george.lbl.gov (Thomas Gill), jrtaylor@george.lbl.gov (John R. Taylor), beattie@george.lbl.gov (Keith Beattie[SFSU Student]) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 561 Hi all, Sorry for the late notice but we have been asked to run a demonstration of the MBONE videoconferencing tools for the University of California, Office of the President. We will run the demonstration from 4-5pm PDT, Monday, July 29. The advertisement will be in sdr and we will transmit using RTPv2. A low rate feed will begin at 2pm PDT for testing purposes. Please e-mail DAAgarwal@lbl.gov if there are any problems with this transmission. We will be sending at ttl 75. Thank you, Deb Agarwal Lawrence Berkeley National Laboratory (510) 486-7078 From rem-conf-request@es.net Mon Jul 29 19:14:36 1996 Received: from vlsi.cs.caltech.edu by osi-east.es.net with ESnet SMTP (PP); Mon, 29 Jul 1996 16:14:05 -0700 Received: from fides.cs.caltech.edu by vlsi.cs.caltech.edu (4.1/1.34.1) id AA12374; Mon, 29 Jul 96 16:13:55 PDT Date: Mon, 29 Jul 96 16:13:55 PDT From: schooler@cs.caltech.edu (Eve Schooler) Message-Id: <9607292313.AA12374@vlsi.cs.caltech.edu> To: vkapil@nortel.ca Subject: Re: Charts from MMUSIC and AVT WGs Cc: rem-conf@osi-east.es.net >I was wondering if the charts presented at these working >groups or related BOFs are already available at some >server. The MMUSIC slides are available from: ftp://ftp.isi.edu/confctrl/minutes/slides.6.96.{tar, tar.Z} We're still working on putting the accompanying minutes there... E. From rem-conf-request@es.net Mon Jul 29 21:09:03 1996 Received: from paris.ics.uci.edu by osi-east.es.net with ESnet SMTP (PP); Mon, 29 Jul 1996 18:08:20 -0700 Received: from cupid.ics.uci.edu by paris.ics.uci.edu id aa20478; 29 Jul 96 17:59 PDT To: Jon Crowcroft Cc: rem-conf@osi-east.es.net Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Wed, 24 Jul 1996 09:46:33 BST." <1282.838197993@cs.ucl.ac.uk> Date: Mon, 29 Jul 1996 17:58:54 -0700 From: Shinji Shimojo Message-ID: <9607291759.aa20478@paris.ics.uci.edu> Hi. > by dave mills on system clocks, by jean bolot and jim kurose on mbone > traffic loss/delay characteristics? there's some neat work out > there.... Could you specify these two papers ? Thanks. Shinji Shimojo Calfornia (2/24/96-) Information & Computer Science University of Calfornia Irvine, CA 92717 PHONE: +1 714 824-3097 FAX: +1 714 824-4056 shimojo@ics.uci.edu Japan Computer Center Osaka University 5-1 Mihogaoka, Ibaraki 567 JAPAN Tel: +81 (6) 879-8793 fax: 06-879-8814 shimojo@center.osaka-u.ac.jp From rem-conf-request@es.net Tue Jul 30 04:48:53 1996 Received: from bells.cs.ucl.ac.uk by osi-east.es.net with ESnet SMTP (PP); Tue, 30 Jul 1996 01:48:11 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 30 Jul 1996 09:47:45 +0100 To: Shinji Shimojo cc: rem-conf@osi-east.es.net Subject: Re: "at any one time" and "media types" - clarification needed In-reply-to: Your message of "Mon, 29 Jul 1996 17:58:54 PDT." <9607291759.aa20478@paris.ics.uci.edu> Date: Tue, 30 Jul 1996 09:47:43 +0100 Message-ID: <1151.838716463@cs.ucl.ac.uk> From: Jon Crowcroft >> by dave mills on system clocks, by jean bolot and jim kurose on mbone >> traffic loss/delay characteristics? there's some neat work out >> there.... >Could you specify these two papers ? Mills best summarry paper is "Improved Algorithms for Synchrinizing Computer Network Clocks", D.L.Mills, SIGCOMM 94, pp 317-327, also available as Computer Communication Review Vol 24, No 4, Oct 1994 Bolot's work is described in J. Bolot, H. Crepin, and A. Garcia, "Analysis of audio packet loss in the internet," in Proc. International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), Lecture Notes in Computer Science, pp. 163-174, Springer, Apr. 1995. and Jean Chrysostome Bolot, "End-to-end packet delay and loss behavior in the Internet," in SIGCOMM 93, pp. 289-298, ACM, Sept. 1993. also available as Computer Communication Review, Vol 23, No. 4, Oct 93 Kurose's (et al) work is described in one of the reports run by the MIST project, available from http://www.tascnets.com/mist/doc/mist.html regards jon From rem-conf-request@es.net Tue Jul 30 10:13:27 1996 Received: from terra.com21.com by osi-west.es.net with ESnet SMTP (PP); Tue, 30 Jul 1996 07:12:56 -0700 Received: from walnut.com21.com (walnut.com21.com [140.174.223.120]) by terra.com21.com (8.7.3/8.6.5) with SMTP id HAA22329 for ; Tue, 30 Jul 1996 07:15:57 -0700 (PDT) Received: by walnut.com21.com (SMI-8.6/SMI-SVR4) id HAA14917; Tue, 30 Jul 1996 07:12:43 -0700 Date: Tue, 30 Jul 1996 07:12:43 -0700 From: nichols@walnut.com21.com (Kathleen Nichols) Message-Id: <199607301412.HAA14917@walnut.com21.com> To: rem-conf@es.net Subject: Program and registration: Hot Interconnects IV Content-Type: X-sun-attachment ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: hoti.call X-Sun-Charset: us-ascii X-Sun-Content-Lines: 414 HOT INTERCONNECTS SYMPOSIUM IV 1996 Sponsored by the Technical Committee on Microprocessors and Microcomputers of the IEEE Computer Society. A Symposium on High Performance Interconnects CALL FOR PARTICIPATION AND ADVANCE PROGRAM August 15-17, 1996 Kresge Auditorium, Stanford University, Palo Alto, CA URL: http://sunrise.scu.edu/pub/HotI ------------------------------------------------------------------ ADVANCE PROGRAM Thursday, August 15, 1996 8:15-8:30 Welcome and Opening Remarks 8:30-9:30 Keynote Presentation, Judy Estrin, Precept Software 9:30-10:45 Hot Routers I A High-Performance Router Design for the Massively Parallel Computer RWC-1 Takashi Yokota, Hiroshi Matsuoka, Kazuaki Okamoto, Hideo Hirono, Shuichi Sakai; Real World Computing Partnership Presenting Author: Takashi Yokota RCube: A Gigabit Serial Links Low Latency Adaptive Router B. Zerrouk, V. Reibaldi, F. Potter, A. Greiner, A. Derieux; Institut Blaise Pascal Universite Pierre et Marie Curie Presenting Author:Belkacem Zerrouk AP-Net Advanced High-Performance Network for Scalable Parallel Server Osamu Shiraki, Masaaki Nagatsuka, Takeshi Horie, Yoichi Koyanagi, Toshiyuki Shimizu, Hiroaki Ishihata; Fujitsu Ltd. Presenting Author: Osamu Shiraki 10:45-11:00 Break 11:00-12:30 For Friends of the Electron Transmitter Equalization for 4Gb/s Signalling William J. Dally, MIT; John Poulton, UNC-Chapel Hill Presenting Author: William J. Dally Rambus 2-Layer PCB Technology for Nintendo-64 John Dillon, Alfredo Moncayo, Don Perino; Rambus Inc. Ko Shiota; Nintendo Ltd. presenting Author: John Dillon Gigaplane (TM): A High Performance Bus for Large SMPs Ashok Singhal, David Broniarczyk, Fred Ceraukis, Jeff Price, Leo Yuan, Chris Cheng, Drew Doblar, Steve Fosth, Nalini Agarwal, Kenneth Harvey, Erik Hagersten, Bjorn Liencres; Sun Microsystems, Inc. Presenting Author: Ashok Singhal 12:30-2:00 Lunch 2:00-3:30 ATM Endpoint Implementations of ATM Congestion Control Protocols Prashant R. Chandra, Allan L. Fisher, Corey Kosak, Peter Steenkiste; CS/ECE Depts., Carnegie Mellon Univ. Presenting Author: Allan Fisher ATLAS I: A General-Purpose, Single-Chip ATM Switch with Credit-Based Flow Control Manolis Katevenis, Dimitrios Serpanos, Panagiota Vatsolaki; ICS FORTH Presenting Author: Manolis Katevenis IP Switching: ATM Under IP Peter Newman, Greg Minshall, Tom Lyon; Ipsilon Networks Presenting Author: Peter Newman A 622 Mb/s ATM LAN/WAN Gatway with Cell Level Measurement and Pacing Capabilities Joseph B. Evans, Victor S. Frost, Douglas Niehaus, David W. Petr, Gary J. Minden, Benjamin J. Ewy; University of Kansas Presenting Author: Gary J. Minden 4:00-5:30 Serial Links Ultra SCSI, Serial Storage Architecture and Fibre Channel - Arbitrated Loop: a Performance Comparison Andrew W. Wilson; Adaptec Inc. Presenting Author: Andrew W. Wilson Serial Express (IEEE 1394.2) Bill Van Loo, Sun and David James, Apple 5:30-7:30 Reception and Buffet Dinner 7:30 Panel: "Gigabit What?". Chuck Thacker, Moderator. Friday, August 16, 1996 8:30-9:15 Invited Talk: "Making Interconnect Commodity" Charles L. Seitz, Myricom Inc. 9:15-10:15 New Twists HIPPI-6400 Architecture and Design Greg Chesson, Hansel Collins, Jim Davis, Mike Ficarra, Mike Galles, Bob Newhall, Ron Nikel, Dave Parry, Don Tolmie; SGI Presenting Author: Greg Chesson A mm-Wave High Speed Wireless Lan for Mobile Computing - Architecture and Prototype Modem/Codec Implementation David J. Skellern, Terence M.P. Percival*, Charles Lee, Philip J. Ryan*, Tom McDermott, Neil H.E. Weste, John Dalton, Tan F. Wong, Jeffrey Graham, Andrew F. Myles; Macquarie University Electronics and (*)CSIRO Division of Radiophysics Presenting Author: David J. Skellern 10:15-10:30 Break 10:30-12:30 Hot Routers II The SGI SPIDER Chip Mike Galles; SGI Presenting Author: Mike Galles The Cray T3E Network: Adaptive Routing in a High Performance 3D Torus Steve Scott, Greg Thorson; Cray Research Presenting Author: Steve Scott Cavallino: The TeraFlops Router and NIC Joseph Carbonaro, Frank Verhoorn; Intel Presenting Author: Joseph Carbonaro The Tiny Tera: A 320 Gbps Switch Adisak Mekkittikul, Nick McKeown, Ritesh Ahuja, Martin Izzard, Mark Horowitz; Stanford University Presenting Author: Nick McKeown 12:30-2:00 Lunch 2:00-3:30 NICs and Software DART-A Low Overhead ATM Network Interface Chip Randy Osborne, Qin Zheng, John Howard; MERL Research Lab, Mitsubishi Electric Information Technical Center America, Inc.; Ross Casley, Doug Hahn; Sunnyvale Research Lab, Mitsubishi Electric Information Technical Center America, Inc; Takeo Nakabayashi, System LSI Laboratory, Mitsubishi Electric Corp. Presenting Author: Randy Osborne Client-Server Computing on the SHRIMP Multicomputer Angelos Bilas, Stefanos N. Damianakis, Cezary Dubnicki, Edward W. Felten; Princeton University Presenting Author: Edward W. Felten Experiences Using the 1st-Generation Memory Channel for PCI Network Richard Gillett, Richard Kaufman; Digital Equipment Corp. Presenting Author: Richard Gillett 4:00-5:30 PCI and SCI Using RACEway as a Transparent Switching Fabric for PCI Bob Blau; Mercury Computer Systems, Inc. Presenting Author: Bob Blau SCI Interconnect Chipset and Adapter: Building Large Scale Enterprise Servers with Pentium Pro SHV Nodes Roy Clark, Data General Corp. Knut Alnes, Dolphin Interconnect Solutions Presenting Author: Roy Clark A Low Cost CMOS 500 Mbyte/sec SCI Link Controller Ali Bozkaya, Steinar Forsmo, Petter Gustad, Mathias Hoddevik, Hans Rygh, Morten Schanke; Dolphin Interconnect Solutions Presenting Author: Morten Schanke ----------------------------------------------------------------------- Tutorials Saturday, August 17 (Tutorials, Tentative) Morning (8:30-12:00) 1. 100Base-T2: The Best Fast Ethernet Standard Sailesh Rao, SDE, Inc. 2. Implementing Intelligent I/O in the PC Server Byron Gillespie and Mark Brown, Intel Enterprise Computing I/O Operations; members of the I2O SIG 3. CMOS RF Circuits Tom Lee, Stanford University Afternoon (1:30-5:00) 4. High Performance Signalling:L How to Transmit a Gigabit/sec per Pin William Dally, MIT and John Poulton, UNC 5. Cable Modems Mark Laubach, Com21, Inc. 6. SSA - The High Performance, Low Cost Serial Interface Michelle Tidwell, Storage Systems Div, IBM --------------------------------------------------------------------- Committees Organizing Committee General Chair: Qiang Li, Santa Clara University Vice General Chair: Vivian Shen, Hewlett-Packard Program Co-Chair: Kai Li, Princeton University Program Co-Chair: Chuck Thacker, DEC, Palo Alto Research Cetner Treasurer: Diane Smith, Consultant Registration: Yongcheng Miao, Santa Clara University Local Arragement: Saravanan Agasaveeran, ISI Publicity: Weijia Shang, Santa Clara University Publication: Thomas Schwarz, Technological University of Munich Tutorials: Jeremy Gorman, TRW Program Committee David Culler, Berkeley David Gustavson, SCIzzL and Santa Clara University Chuck Kalmanek, ATT Kai Li, Princeton University Gary Minden, ARPA Kathleen Nichols, Com21 Greg Papadopolous, SUN Justin Rattner, Intel Nori Suzuki, Sony Shanker Singh, IBM Chuck Thacker, DEC ------------------------------------------------------------------------ Early Registration Price To reduce the on-site registration delay, registrations for the technical program (Thursday and Friday) recevied before or on Friday, August 12 will automatically enter a drawing for a HP 200LX Palmtop PC. FEES for the TECHNICAL PROGRAM (Thursday and Friday): July 22 or ealier After July 22 IEEE/CS or ACM Members: $230 $290 Non-members: $285 $360 Fulltime Students: $100 $125 Registration for the Technical Program includes: attendance; one copy of the notes; parking; Thursday evening dinner and reception; two lunches; coffee breaks. A Stanford map, parking permit, the location of parking, a list of local hotels, and a receipt will be mailed to early registrants. On-campus housing can also be arranged through the Stanford Housing Office, (415) 723-2287. Please note that Stanford has instituted a very restrictive no-smoking policy on campus that is strictly enforced, including in on-campus housing. FEES for half-day tutorials (Saturday): July 22 or ealier After July 22 IEEE/CS or ACM Members: $105 $125 Non-members: $130 $155 Fulltime Students: $25 $35 Tax Id: Institute of Electrical and Electronics Engineers Computer Society 13-1656633 Cancellation of Registration: Must be made in writing prior to Wednesday, August 8, 1995. A $40 fee will be charged for cancellation. On-Site Registration will start at 7:30 am, Thursday, August 15, 1996. Preregistration will be accepted through August 9, 1996. Registration may be faxed or e-mailed if paid by credit card. Send registration to: Mr. Yongcheng Miao Department of Computer Engineering Santa Clara University Santa Clara, CA 95053 phone: 408-554-6812 fax: 408-551-1634 email: miao@sunrise.scu.edu REGISTRATION INFORMATION REQUESTED: Name _________________________________________________ Affiliation __________________________________________ Mailing Address______________________________________ _____________________________________________________ Telephone _________________Fax ______________________ E-mail________________________________ Check all that apply: ____ Please don't include my name in any mailing list ____ IEEE Member, membership number ___________________ ____ ACM Member, membership number ___________________ ____ Full-time student ____ Please send me housing information Payment Method: _____ Check (Make checks withdrawable from a US Bank and payable to Hot Interconnects Symposium) _____ VISA _____ Mastercard If paying by credit card: Exact cardholder name: ____________________________ Credit Card number: __________________________ Expiration date: _____________________________ SELECTIONS AND FEES: Technical Program: _______ Tutorials: _______ ______ 8:30-12:00 Tutorial 1 ______ 8:30-12:00 Tutorial 2 ______ 8:30-12:00 Tutorial 3 ______ 1:30-5:00 Tutorial 4 ______ 1:30-5:00 Tutorial 5 ______ 1:30-5:00 Tutorial 6 TOTAL AMOUNT for Technical Program/Tutorials _______ PGP Public Key of Hot Interconnects Symposium If you use pgp and want to submit your registration more securely, the following is our public key generated by pgp: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQBNAzGxREIAAAECANfKovTsWiNagm+CthspDN3NdPlfIU8TusVQUR39c85U0j1f QcX7NhVCgvgfANMMa3UaMnwYslJNpBCJdwgQrqUABRO0KEhvdCBJbnRlcmNvbm5l Y3RzIDxob3RpQHN1bnJpc2Uuc2N1LmVkdT4= =Umki -----END PGP PUBLIC KEY BLOCK----- From rem-conf-request@es.net Tue Jul 30 13:33:46 1996 Received: from hubbub.cisco.com by osi-west.es.net with ESnet SMTP (PP); Tue, 30 Jul 1996 10:33:12 -0700 Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id KAA19834; Tue, 30 Jul 1996 10:36:44 -0700 Message-Id: <2.2.32.19960730173310.0067ef90@pointer.cisco.com> X-Sender: oran@pointer.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Jul 1996 13:33:10 -0400 To: rem-conf@es.net From: David Oran Subject: MIB for RTP? Can anyone point me a work going on for an RTP/RTCP MIB? I'm interested in something that can either be incorporated into a participating host (e.g. to produce management statistics for an I-Phone conversation or an H.323-style session), or an RTCP monitor to make the global stats for a multicast session available via SNMP. It isn't clear that these two thing need or want to be identical, but of course they could be. Thanks, Dave Oran. ----------------- David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Phone: 508-264-2048 or 508-263-2705 EMail: oran@cisco.com From rem-conf-request@es.net Tue Jul 30 15:19:46 1996 Received: from vagate.usrva.com (actually 204.151.242.200) by osi-west.es.net with ESnet SMTP (PP); Tue, 30 Jul 1996 12:19:10 -0700 Received: from ccMail by vagate.usrva.com (IMA Internet Exchange 1.04b) id 1fe5fa00; Tue, 30 Jul 96 15:16:48 -0400 Mime-Version: 1.0 Date: Tue, 30 Jul 1996 15:10:44 -0400 Message-ID: <1fe5fa00@usrva.com> From: snaudus@usrva.com (Stan Naudus) To: rem-conf@es.net, David Oran Subject: Re: MIB for RTP? Content-Type: multipart/mixed; boundary="IMA.Boundary.802457838" This is a Mime message, which your current mail reader may not understand. Parts of the message will appear as text. To process the remainder, you will need to use a Mime compatible mail reader. Contact your vendor for details. --IMA.Boundary.802457838 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Received: from osi-west.es.net by vagate.usrva.com with SMTP (IMA Internet Exchange 1.04b) id 1fe50aa0; Tue, 30 Jul 96 14:12:58 -0400 Received: from hubbub.cisco.com by osi-west.es.net with ESnet SMTP (PP); Tue, 30 Jul 1996 10:33:12 -0700 Received: from oranlt.cisco.com (oran-toshiba.cisco.com [171.69.210.2]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id KAA19834; Tue, 30 Jul 1996 10:36:44 -0700 Message-Id: <2.2.32.19960730173310.0067ef90@pointer.cisco.com> X-Sender: oran@pointer.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Jul 1996 13:33:10 -0400 To: rem-conf@es.net From: David Oran Subject: MIB for RTP? --IMA.Boundary.802457838 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part David and all, Please send this information to myself as well. Thanks for your help, Stan Naudus ______________________________ Reply Separator _________________________________ Subject: MIB for RTP? Author: David Oran at Internet Date: 7/30/96 1:33 PM Can anyone point me a work going on for an RTP/RTCP MIB? I'm interested in something that can either be incorporated into a participating host (e.g. to produce management statistics for an I-Phone conversation or an H.323-style session), or an RTCP monitor to make the global stats for a multicast session available via SNMP. It isn't clear that these two thing need or want to be identical, but of course they could be. Thanks, Dave Oran. ----------------- David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Phone: 508-264-2048 or 508-263-2705 EMail: oran@cisco.com --IMA.Boundary.802457838-- From rem-conf-request@es.net Tue Jul 30 17:42:00 1996 Received: from emout16.mail.aol.com (actually emout16.mx.aol.com) by osi-west.es.net with ESnet SMTP (PP); Tue, 30 Jul 1996 14:41:28 -0700 Received: by emout16.mail.aol.com (8.6.12/8.6.12) id RAA05037 for rem-conf@es.net; Tue, 30 Jul 1996 17:43:59 -0400 Date: Tue, 30 Jul 1996 17:43:59 -0400 From: FredHous@aol.com Message-ID: <960730174335_249020932@emout16.mail.aol.com> To: rem-conf@es.net Subject: unscribe me Unscribe From rem-conf-request@es.net Tue Jul 30 20:36:54 1996 Received: from warp10.smartlink.net (actually smartlink.net) by osi-west.es.net with ESnet SMTP (PP); Tue, 30 Jul 1996 17:36:24 -0700 Original-Received: by warp10.smartlink.net(8.6.12/SMARTLINK-1.0) with id RAA02612 for rem-conf@es.net on Tue, 30 Jul 1996 17:38:34 -0700 PP-warning: Illegal Received field on preceding line From: Robert Lord Message-Id: <199607310038.RAA02612@warp10.smartlink.net> Subject: [WANTED] Multicast Pro in LA To: rem-conf@es.net Date: Tue, 30 Jul 1996 17:38:33 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 675 Multicast Event Producer Wanted ------------------------------- Highly visible rock music site is looking for a multicast event producer in the Los Angeles, California area. Knowledge of current software across platforms and experience multicasting is essential. Please send resume and availabity to roblord@smartlink.net. hoping this message doesn't consistute list abuse, rl. ________________________________________________________________________ Robert Lord roblord@smartlink.net N2K, V.P. Rocktropolis/allstar -- http://www.rocktropolis.com/ Internet Underground Music Archive, IUMA Founder -- http://www.iuma.com/ From rem-conf-request@es.net Wed Jul 31 07:04:21 1996 Received: from www45.inria.fr by osi-west.es.net with ESnet SMTP (PP); Wed, 31 Jul 1996 04:03:47 -0700 Received: by www45.inria.fr (8.7.5/8.6.12) id NAA27759; Wed, 31 Jul 1996 13:03:49 +0200 (MET DST) Message-Id: <199607311103.NAA27759@www45.inria.fr> To: rem-conf@es.net Subject: Inconsistency in MPEG Payload format draft ? Date: Wed, 31 Jul 1996 13:03:49 +0200 From: Philipp Hoschka The draft for the RTP payload format for MPEG states: "Payload Type: Distinct payload types should be assigned for of MPEG1 System Streams, MPEG2 Program Streams and MPEG2 Transport Streams. See [4] for payload type assignments." where [4] references RFC 1890 ("RTP Profile for Audio and Video with Minimal Control"). However, only a payload type for MPEG2 Transport Streams is defined in RFC 1890 - MPEG1 System Streams and MPEG2 Program streams are missing. Or are they supposed to be dynamically assigned ? ---------------------------------------------------------------------- Philipp Hoschka WWW: http://www.inria.fr/rodeo/personnel/hoschka/hoschka.html | INRIA - WWW Consortium hoschka@sophia.inria.fr | 2004, Route des Lucioles, BP 93 Tel:(+33) 93 65 79 84 | 06902 Sophia Antipolis Cedex Fax:(+33) 93 65 77 65 | France ---------------------------------------------------------------------- From rem-conf-request@es.net Wed Jul 31 10:55:39 1996 Received: from ctrvx1.Vanderbilt.Edu by osi-west.es.net with ESnet SMTP (PP); Wed, 31 Jul 1996 07:55:01 -0700 Received: from ctrvax.Vanderbilt.Edu by ctrvax.Vanderbilt.Edu (PMDF V5.0-5 #11488) id <01I7PU1VX9O08X6SV7@ctrvax.Vanderbilt.Edu> for list3@ctrvax.Vanderbilt.Edu; Wed, 31 Jul 1996 09:09:11 -0500 (CDT) Date: Wed, 31 Jul 1996 09:09:11 -0500 (CDT) From: BEZALEL GAVISH Subject: CFP - 5th International Conference on Telecommunication Systems To: list3:; Message-id: <01I7PU1VXJB68X6SV7@ctrvax.Vanderbilt.Edu> X-VMS-To: IN%"list3" X-VMS-Cc: GAVISHB MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT TSM97CFP C A L L for P A P E R S 5th International Conference on Telecommunication Systems Modelling and Analysis March 20-23, 1997 Nashville, TN Sponsored by: American Telecommunications Systems Management Association BellSouth Telecommunications, Inc. IFIP Working Group 7.3 "Computer system modelling and performance evaluation" INFORMS Technical Section on Telecommunications INFORMS College of Information Systems Owen Graduate School of Management The 5th International Conference on Telecommunication Systems - Modelling and Analysis will be held in Nashville on March 20-23, 1997. The conference will build on the tradition of the earlier conferences with a few changes in format due to the new conference location. The general idea is to limit the number of participants, concentrate on a few topics, present new problems and problem areas, encouraging informal interaction and exchanges of ideas. The objective is to advance the state of the modelling and analysis in telecommunications by stimulating research activity on new and important problems. The conference will be divided into segments with each segment devoted to a specific topic. This will allow for little conflict between segments. All papers will be screened by the Program Committee to ensure the quality of presentations. A decentralized paper handling process will be used. The Program Committee has been divided along geographical regions with a separate Program Subcommittee assigned to each region. Abstracts and papers should be submitted directly to the Program Committee Chair of the appropriate area. It is expected that this will expedite the paper review process. In response to suggestions made by last year's participants, social and cultural activities will be included in the 1997 agenda. The conference will be held at two sites, Thursday and Friday meetings will take place at the Tenessee Economic Development Center at the BellSouth Tower in downtown Nashville. The Saturday and Sunday meeting will be held at the Union Station hotel (see description at the end of the message). Lead Speakers and Keynote speakers include: Erol Gelenbe, Andrew Viterbi, Paul Kuehn. The Chairmen of the geographic Program Committees are: ---Australia, New Zealand and South East Asia: Prof. Richard Harris Department of Communication and Electronic Engineering Royal Melbourne Institute of Technology 723 Swanston Street Carlton, Victoria Australia, 3001 Phone : 61 3 9282 2450 (CATT), 61 3 9660 2457 (RMIT) Fax : 61 3 9282 2490 (CATT), 61 3 9660 1060 (RMIT) E-Mail : richard@catt.rmit.edu.au ---Europe: (except Scandinavia and Baltic states) Prof. Guy Pujolle Laboratoire PRiSM Universite de Versailles - Saint Quentin 45 avenue des Etats-Unis 78 035 Versailles Cedex FRANCE Phone : +33 (1) 39 25 40 61 Fax : +33 (1) 39 25 40 57 E-Mail : guy.pujolle@prism.uvsq.fr ---Europe: (Scandinavia and Baltic states) Dr. Johan M. Karlsson Department of Communication Systems Lund Institute of Technology P.O. Box 118 S-221 00 Lund Sweden E-Mail : johan@tts.lth.se ---North America: Prof. June S. Park Department of Management Sciences The University of Iowa 108 Pappajohn Business Administration Bldg. Iowa City, IA 52242-1000 USA Phone : 319-335-2087 Fax : 319-335-1956 E-Mail : jpark@scout-po.biz.uiowa.edu ---North East Asia: Prof. Yutaka Takahashi Nara Institute of Science and Technology Takayama-cho 8916-5, Ikoma-shi, Nara, 630-01 JAPAN Phone : 81 74 372 5350 Fax : 81 74 372 5359 E-Mail : ytanaka@mn.waseda.ac.jp ---South and Central America: Dr. Ernesto Santibanez-Gonzalez Escuela de Ingenieria Industrial Universidad Catolica, Valparaiso Av. Brasil 2147 Valparaiso Chile Phone : 56 32 257331 Fax : 56 2 214823 E-Mail : esantiba@aix1.ucv.cl ---Chairman of the Economics track: Prof. William W. Sharkey Federal Communications Commission 1919 M Street Washington, DC 20554 USA Phone : 202-418-2743 Fax : 202-418-1413 E-Mail : wsharkey@fcc.gov ---All other geographic areas: Prof. Bezalel Gavish Owen Graduate School of Management Vanderbilt University Tel: 615-322-3659 401 21st Avenue South FAX: 615-343-7177 Nashville, TN 37203 Email: gavishb@ctrvax.vanderbilt.edu Listed below are some of the potential segments: -- Configuration of ATM networks -- Internet and its Impact on Commerce -- Internet and Intranet -- Standards -- Topological Design and Network Configuration Problems -- Design and Analysis of Local Access Networks and Outside Plant Problems -- Low Earth Orbit Satellite Communication Systems -- Cellular Systems and PCS Modelling and Configuration -- Time Dependent Expansion of Telecommunication Systems -- Designing Networks for Reliability and Availability -- Network Design Problems in Gigabit and Terabit Networks -- LAN, WAN Global Network Interconnection -- ATM, ISDN, BISDN Modeling and Analysis Issues -- Artificial Intelligence/Heuristics in Telecommunication Systems -- Group Decision Support Systems -- Quantitative Methods in Network Management -- Pricing and Economic Analysis of Telecommunications -- Impact of Telecommunications on Industrial Organization -- Performance Evaluation of Telecommunication Systems -- Distributed Computing and Distributed Data Bases -- Security and Privacy Issues in Telecommunications -- Virtual Reality, Multimedia and their Impact The Program Committee is open to any ideas you might have regarding additional topics or format of the conference. The intention is whenever possible, to limit the number of parallel sessions to two. The conference is scheduled over a weekend so as to reduce teaching conflicts for academic participants, enabling participants to take advantage of weekend hotel and airfare rates and of the many events that take place in the downtown area. Due to the limit on the number of participants early conference and hotel registration is recommended. The Union Station Hotel is the official hotel of the conference. To ensure your participation, please use the following steps: 1. Send to the appropriate Program Committee Chair by October 1, 1996, a paper (preferable), or titles and extended abstracts for potential presentations to be considered for the conference. Sending more than one extended abstract is encouraged, enabling the Program Committee to have a wider choice in terms of assigning talks to segments. Use E-mail to expedite the submission of titles and abstracts. 2. Use the forms at the end of this message to preregister for the conference and the hotal. Let us also know if you would like to have a formal duty during the conference as: Session Chair, or Discussant. 3. You will be notified by December 1, 1996, which abstract/s have been selected for the conference. Detailed instructions on how to prepare camera ready copies will be sent to authors of accepted presentations. January 30, 1997, is the deadline for sending a final version of the paper. Participants will receive copies of the collection of papers to be presented. All papers submitted to the conference will be considered for publication in the "Telecommunication Systems" Journal. The Program Committee looks forward to receiving your feedback/ideas. Feel free to volunteer any help you can offer. If you have suggestions for Segment Leaders (i.e., individuals who will have a longer time to give an overview/state of the art talk on their segment subject) please E-mail them to Prof Gavish. Also, if there are individuals whose participation you view as important, please send their names and E-mail addresses to the Program Committee Chairman, or forward to them a copy of this message. I look forward to a very successful conference. Sincerely yours, Bezalel Gavish ------------------------------------------------------------------------------- Cut Here ------------------------------------------------------------------------------- Fifth International Conference on Telecommunication Systems Modelling and Analysis REGISTRATION FORM Date: __________________ Dates: March 20, 1997 (afternoon) to March 23, 1997 Name: ________________________________________ Title: __________________ Affiliation: __________________________________________________________________ Address: __________________________________________________________________ __________________________________________________________________ Phone: ____________________________ FAX: _______________________________ E-mail: __________________________________________________________________ Potential Title of Paper(s): __________________________________________________ ____________________________________________________________________ I would like to Volunteer as Comments A Session Chair : Yes No ________________________________________________ A Discussant : Yes No ________________________________________________ Organize a Session: Yes No ________________________________________________ ________________________________________________ REGISTRATION RATES and DEADLINES Last Applica- Academic Industry Corporate ble Date Rate Rate Rate --------------- -------- -------- -------- 1. Preregistration Until Dec. 9, 1996 $ 400 $ 500 $1,300 2. Registration Until Jan. 15, 1997 $ 500 $ 600 $1,300 3. On Site Registration After Jan. 15, 1997 $ 600 $ 750 $1,500 As part of the conference registration dues you can become a member of the "American Telecommunication Systems Management Association" . Please mark an X in the following entry if you wish to become an ATSMA member. ____ Yes, I wish to become an ATSMA member. ____ No, I don't wish to become an ATSMA member. Mail your registration form and check to: Mrs. Dru Lundeng Owen Graduate School of Management Vanderbilt University 401 21st Avenue, South Nashville, TN 37203, USA The check should be endorsed to: ATSMA, Inc. Refund Policy: Half refund, for requests received by February 1, 1997. No refund after February 1, 1997. ----------------------------------------------------------------------------- If you have any questions regarding the conference, please contact Dru Lundeng at 615-322-3694 or through E-mail at lundeng@ctrvax.vanderbilt.edu. Hotel Reservation A block of rooms has been reserved at Union Station Hotel for the Conference participants. Please make your hotel arrangements early, to insure getting a room at the special conference rate. You will need to mention that you are a participant of the Telecommunication Systems Conference to receive the best price. Our advice is to make your reservations as soon as possible. Hotel rooms will be released from the Telecommunication Systems Conference blocks on February 15, 1997, so please be sure and reserve your rooms before February 15th. Union Station Hotel 1001 Broadway Nashville, TN 37203 Phone: 615-726-1001 or 1-800-331-2123 Fax: 615-742-3084 $99.00 Single or Double Occupancy Room $109.00 Triple or Quad Occupancy Room - Rates are subject to state and local tax, which is now 12.25 percent. ------------------------------------------------------------------------- Union Station Hotel Reservation Request Form Name of Conference: Telecommunication Systems Conference Arrival Date _________________ Departure Date __________________ Guest Name:__________________________________________________ Address :__________________________________________________ :__________________________________________________ Phone No. :__________________________________________________ A one night deposit should be enclosed to guarantee the reservation Payment Method: Check Check No.______________ Amount____________ Credit Card Type______________ No.____________________ Expiration Date____________ Type of Room: King or 2 Double Beds Smoking or Nonsmoking -------------------------------------------------------------------------- Union Station Hotel Description A Grand Heritage Hotel Features and Amenities In the heart of "Music City" stands a hotel with the personality of an intimate friend...Union Station Hotel. The heartbeat of Nashville has always been strongest at the Union Station. >From the grand opening in 1890 until the decline of rail travel in the 50s no other building in the city has been the site of more commercial activity and human drama. Nearly a century later, the Union Station Hotel, a National Historic Landmark, is again an integral part of life in Music City 124 guest rooms including 13 suites on seven levels are architecturally distinctive and capture the historic elegance of a bygone era. Stained glass, glittering gold leaf and newly silvered mirrors scatter reflections of an era which has endured for nearly a century. 4 conference rooms with over 10,000 square feet of flexible meeting and banquet space to accommodate groups of 5 to 200. * Arthur's Restaurant - gourmet dining, the recipient of the Mobil Travel Guide's Four Stars, Wine Spectator's Award of Excellence, and the Travel Holiday Award. * Broadway Bistro - casual dining open for lunch and dinner. Selected in the 1996 Zagat Survey as the city's best overall and best dining hotel. Heritage Executive Level with enhanced amenities ideal for the business and leisure traveler including concierge service, continental breakfast and evening cocktails Monday through Friday. * Valet parking. * Complimentary limo service in downtown Nashville. * Complimentary newspaper. * Blocks from downtown area, famed Music Row, Vanderbilt University and Convention Center. Recommended Airport: Nashville Metro Airport, 7 miles to the East. Transportation: Grayline Shuttle to the hotel. $8.00 one way, $14.00 round trip. Complimentary shuttle service within three mile radius of hotel for conference guests. ------------------------------------------------------------------------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Nashville, TN, 37203 Bitnet: GAVISHB@VUCTRVAX Internet: GAVISHB@CTRVAX.VANDERBILT.EDU Tel: (615) 322-3659 Home: (615) 370-0813 FAX: (615) 343-7177 ------------------------------------------------------------------------------- From rem-conf-request@es.net Wed Jul 31 12:51:45 1996 Received: from bells.cs.ucl.ac.uk by osi-west.es.net with ESnet SMTP (PP); Wed, 31 Jul 1996 09:50:46 -0700 Received: from rat.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 31 Jul 1996 17:50:34 +0100 To: rem-conf@es.net Subject: RTP packet format for redundant encodings Date: Wed, 31 Jul 1996 17:50:32 +0100 Message-ID: <23065.838831832@cs.ucl.ac.uk> From: Colin Perkins I enclose a revised copy of our draft on "Payload format issues for redundant encodings in RTP" (in addition postscript is available at the usual internet-drafts ftp sites). This draft incorparates a number of suggestions made during the last IETF meeting. This is the payload format which will be used for audio redundancy in the UCL Robust Audio Tool (RAT), version 2.6, which is currently undergoing testing, and will shortly be available. If you have any comments/suggestions on this, I'd be grateful to hear them. Colin ------------------------------------------------------------------------------ INTERNET-DRAFT 19 July 1996 Mark Handley Vicky Hardman Isidor Kouvelas Colin Perkins University College London Jean-Chrysostome Bolot Andres Vega-Garcia Sacha Fosse-Parisis INRIA Sophia Antipolis Payload Format Issues for Redundant Encodings in RTP draft-perkins-rtp-redundancy-01.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Comments are solicited and should be addressed to the authors and/or the AVT working group's mailing list at rem-conf@es.net. Abstract This document describes a payload type for use with the real-time transport protocol (RTP), version 2, for encoding redundant data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications. Handley et al Page 1 INTERNET-DRAFT 19 July 1996 1 Introduction If multimedia conferencing is to become widely used by the Internet Mbone community, users must perceive the quality to be sufficiently good for most applications. We have identified a number of problems which impair the quality of conferences, the most significant of which is packet loss over the Mbone. Packet loss is a persistent problem, particularly given the increasing popularity, and therefore increasing load, of the Internet. The disruption of speech intelligibility even at low loss rates which is currently experienced may convince a whole generation of users that multimedia conferencing over the Internet is not viable. The addition of redundancy to the data stream is offered as a solution [1]. If a packet is lost then the missing information may be reconstructed at the receiver from the redundant data that arrives in the following packet(s). This draft proposes an RTP payload format for the transmission of data encoded in a redundant fashion. Although the primary use of this packet format to date has been in audio applications, the packet format specified is quite general, and is not limited to these applications. 2 Packetisation problem The main requirements for a redundant encoding scheme under RTP are as follows: o Packets have to carry a primary encoding and one or more redundant encodings. o As a multitude of encodings may be used for redundant information, each block of redundant encoding has to have an encoding type identifier. o As the use of variable size encodings is desirable, each encoded block in the packet has to have a length indicator. o The RTP header provides a timestamp field that corresponds to the time of creation of the encoded data. When redundant encodings are used this timestamp field can refer to the time of creation of the primary encoding data. Redundant blocks of data will correspond to different time intervals than the primary data. Each block of redundant encoding has to have its own timestamp. To reduce the number of bytes needed to carry the timestamp, it can Handley et al Page 2 INTERNET-DRAFT 19 July 1996 be computed as the difference of the timestamp for the redundant encoding to timestamp for the primary. There are two essential means by which redundant audio may be added to the standard RTP specification: a header extension may hold the redundancy, or one, or more, additional payload types may be defined. These are now discussed in turn. 3 Use of RTP Header Extension The RTP specification [2] states that applications should be prepared to ignore a header extension. Including all the redundancy information for a packet in a header extension would make it easy for applications that do not implement redundancy to discard it and just process the primary encoding data. There are, however, a number of disadvantages with this scheme: o There is a large overhead from the number of bytes needed for the extension header (4) and the possible padding that is needed at the end of the extension to round up to a four byte boundary (up to 3 bytes). Even for longer duration packets especially when high compression encodings are used the overhead is considerable. o Use of the header extension limits applications to a single redundant encoding, unless further structure is introduced into the extension. This would result in further overhead. For these reasons, the use of RTP header extension to hold redundant audio encodings is disregarded. 4 Use Of Additional RTP Payload Types Currently the RTP profile for audio and video conferences [3] lists a set of payload types and provides for a dynamic range of 32 encodings that may be defined through a conference control protocol. This leads to two possible schemes for assigning additional RTP payload types for redundant audio applications: 1.A dynamic encoding scheme may be defined, for each combination of primary/redundant payload types, using the RTP dynamic payload type range. Handley et al Page 3 INTERNET-DRAFT 19 July 1996 2.A fixed payload type may be defined to represent a packet with redundancy. This may then be assigned to either a static RTP payload type, or the payload type for this may be assigned dynamically. 4.1 Dynamic Encoding Schemes It is possible to define a set of payload types that signify a particular combination of primary and secondary encodings for each of the 32 dynamic payload types provided. This would be a slightly restrictive yet feasible solution for packets with a single block of redundancy as the number of possible combinations is not too large. However the need for multiple blocks of redundancy greatly increases the number of encoding combinations and makes this solution not viable. A modified version of the above solution could be to decide prior to the beginning of a conference on a set a 32 encoding combinations that will be used for the duration of the conference. All tools in the conference can be initialized with this working set of encoding combinations. Communication of the working set can be made through the use of an external mechanism such as SDR. Setup is complicated as great care needs to be taken in starting tools with identical parameters. This scheme is more efficient as only one byte is used to identify combinations of encodings. 4.2 Payload type to mean packet-with-redundancy A more flexible solution would be to have only one payload type to signify a packet with redundancy and have each of the encoding blocks in the packet contain it's own payload type field: such a packet acts as a container, encapsulating multiple packets into one. Such a scheme is flexible, since any number of redundant encodings may be enclosed within a single packet. There is, however, a small overhead since each encapsulated packet must be preceded by a header indicating the type of data enclosed. This is the preferred solution, since it is both flexible, extensible, and has a relatively low overhead. The remainder of this document describes this solution. Handley et al Page 4 INTERNET-DRAFT 19 July 1996 5 RTP payload type for redundant data The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. An RTP packet containing redundant data shall have a standard RTP header, with payload type indicating redundancy. The other fields of the RTP header relate to the primary data block of the redundant data. Following the RTP header are a number of additional headers, specified in the figure below, which specify the contents of each of the encodings carried by the packet. Following these additional headers are a number of data blocks, which contain the standard RTP payload data for these encodings. It is noted that all the headers are aligned to a 32 bit boundary, but that the payload data will typically not be aligned. 0 1 2 3 0 1 23 4 5 6 7 8 90 1 2 3 4 5 67 8 9 0 1 23 4 5 6 7 8 90 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| block PT | timestamp offset | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The bits in the header are specified as follows: F: 1 bitFirst bit in header indicates whether another encoding block follows. If 1 further redundant data blocks follow, if 0 this is the last data block. block PT: 7 bitsPayload type for this block. timestamp offset: 14 bitsUnsigned offset of timestamp of this block relative to timestamp given in RTP header. The use of an unsigned offset implies that redundant data must be sent after the primary data, and is hence a time to be subtracted from the current timestamp to determine the timestamp of the data for which this block is the redundancy. block length: 10 bitsLength in bytes of the next redundant data block excluding header. It is noted that this limits the use of redundant data slightly: it is not possible to send redundancy before the primary encoding. This may possibly affect schemes, such as GSM audio, where a low bandwidth coding suitable for redundancy is produced early in the encoding process, and hence could feasibly be transmitted early. The addition of a sign bit would unacceptably reduce the range of the timestamp offset, Handley et al Page 5 INTERNET-DRAFT 19 July 1996 and increasing the size of the field above 14 bits limits the block length field. It seems that limiting redundancy to be transmitted after the primary will cause fewer problems than limiting the size of the other fields. It is noted that the block length and timestamp offset are 10 bits, and 14 bits respectively; rather than the more obvious 8 and 16 bits. Whilst such an encoding complicates parsing the header information slightly, and adds some additional processing overhead, there are a number of problems involved with the more obvious choice: An 8 bit block length field is sufficient for most, but not all, possible encodings: for example 80ms PCM and DVI audio packets comprise more than 256 bytes, and cannot be encoded with a single byte length field. It is possible to impose additional structure on the block length field (for example the high bit set could imply the lower 7 bits code a length in words, rather than bytes), however such schemes are complex. The use of a 10 bit block length field retains simplicity and provides an enlarged range, at the expense of a reduced range of timestamp values. A 14 bit timestamp value does, however, allow for 4.5 complete packets delay with 48KHz audio, more at lower sampling rates, and it is felt that this is sufficient. The primary encoding block should be placed last in the packet. It is therefore required to omit the timestamp and block-length fields from the header of this block, since they may be determined from the RTP header and overall packet length. The header for the primary (final) block comprises only a zero marker bit, and the block payload type information, a total of 8 bits. This is illustrated in below: 0 1 23 4 5 6 7 +-+-+-+-+-+-+-+-+ |0| Block PT | +-+-+-+-+-+-+-+-+ 6 Limitations The RTP marker bit is not preserved. That is, a redundant copy of the RTP marker is not sent, hence if the primary (containing this marker) is lost, the marker is lost. It is not thought that this will cause undue problems: even if the marker bit was transmitted with the redundant information, there would be the possibility of its loss, so applications would still have to be written with this in mind. Handley et al Page 6 INTERNET-DRAFT 19 July 1996 7 Example Packet A redundant audio data packet containing DVI4 (8KHz) primary, and a single block of redundancy encoded using 8KHz LPC is illustrated: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number of primary | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp of primary encoding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| block PT=7 | timestamp offset | block length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| block PT=5 | | +-+-+-+-+-+-+-+-+ + | | + LPC encoded redundant data + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | DVI4 encoded primary data | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 Author's Addresses Mark Handley/Vicky Hardman/Isidor Kouvelas/Colin Perkins Department of Computer Science University College London London WC1E 6BT United Kingdom Email: M.Handley|V.Hardman|I.Kouvelas|C.Perkins@cs.ucl.ac.uk Jean-Chrysostome Bolot/Andres Vega-Garcia/Sacha Fosse-Parisis INRIA Sophia Antipolis 2004 Route des Lucioles, BP 93 06902 Sophia Antipolis France Email: bolot@sophia.inria.fr Handley et al Page 7 INTERNET-DRAFT 19 July 1996 9 References [1] Hardman, V. J. and Sasse, M. A. and Handley, M. and Watson, A., Reliable Audio for Use over the Internet, Proceecings INET'95, Honalulu, Oahu, Hawaii, September 1995. http://www.isoc.org/in95prc/ [2] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, RFC 1889, January 1996 [3] H. Schulzrinne, RTP Profile for Audio and Video Conferences with Minimal Control, RFC 1890, January 1996 Handley et al Page 8 ------------------------------------------------------------------------------ From rem-conf-request@es.net Wed Jul 31 16:58:13 1996 Received: from gateway-gw.pictel.com by osi-west.es.net with ESnet SMTP (PP); Wed, 31 Jul 1996 13:57:32 -0700 Received: from roadrunner.pictel.com by gateway-gw.pictel.com (4.1/cf.gw.940128.1740) id AA11528; Wed, 31 Jul 96 16:57:30 EDT Received: from magicland.pictel.com by roadrunner.pictel.com (4.1/runner.910925.1) id AA16009; Wed, 31 Jul 96 16:57:29 EDT Received: from moosejaw by magicland.pictel.com (SMI-8.6/SMI-SVR4) id QAA19751; Wed, 31 Jul 1996 16:55:30 -0400 Message-Id: <2.2.32.19960731205457.010b7924@magicland.pictel.com> X-Sender: webberr@magicland.pictel.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Jul 1996 16:54:57 -0400 To: rem-conf@es.net From: Bob Webber Subject: Mirror of AVC ftp site in US Hi, folks. PictureTel is pleased to announce that we are now providing a mirror of the contents of Mr Okubo's ftp site on an accessible server in Massachusetts. Use of the PictureTel mirror will make it easier to get copies of documents posted by Mr Okubo and others for readers in the US and Europe. The URL for the site is: ftp://standard.pictel.com/avc-site/ (or, ftp standard.pictel.com as user "anonymous" or "ftp" and give your e-mail address for a password; cd avc-site) The mirror is updated from the original GCL site twice daily, at 5 AM and 8 PM US Eastern time. If you experience any problems accessing the server, please contact Bob Webber at e-mail webberr@pictel.com. Bob Webber PictureTel Corporation From rem-conf-request@es.net Wed Jul 31 23:14:41 1996 Received: from precept.com (actually hydra.precept.com) by osi-west.es.net with ESnet SMTP (PP); Wed, 31 Jul 1996 20:14:12 -0700 Received: from little-bear.precept.com by precept.com (5.x/SMI-4.1) id AA19142; Wed, 31 Jul 1996 20:14:00 -0700 Date: Wed, 31 Jul 1996 20:13:59 -0700 (PDT) From: Stephen Casner To: Philipp Hoschka Cc: rem-conf@es.net Subject: Re: Inconsistency in MPEG Payload format draft ? In-Reply-To: <199607311103.NAA27759@www45.inria.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Philipp, > However, only a payload type for MPEG2 Transport Streams is defined > in RFC 1890 - MPEG1 System Streams and MPEG2 Program streams are missing. > Or are they supposed to be dynamically assigned ? My recollection is that assigning 3 static payload types for MPEG already seemed like a lot, and that MPEG1 System Streams and MPEG2 Program streams were left for dynamic payload type assignment or future static payload type definition if warranted. I hope to hear a comment from Don Hoffman and/or Michael Speer as well. -- Steve