From rem-conf Tue Sep 02 09:15:22 1997 From rem-conf-request@es.net Tue Sep 02 09:15:19 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x5vL0-00033J-00; Tue, 2 Sep 1997 08:57:54 -0700 Message-ID: <340C3760.3A8A@darmstadt.gmd.de> Date: Tue, 02 Sep 1997 17:57:20 +0200 From: Peter Hoermann X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: rem-conf@es.net CC: bahr@sonne.darmstadt.gmd.de, reinema@sonne.darmstadt.gmd.de, peha@sonne.darmstadt.gmd.de Subject: H.320/H.323-Gateways & Pricing Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, looking for H.320/H.323 videoconferencing gateways I came across 3 companies offering these products: + RADVision (L2W-323) + Picturetel (LiveGateway 3.0) + First Virtual Corporation (V-Gate 323) Are their more companies offering these kind of gateways ? Very interesting would be their features, the date of availability and the pricing, too. Regards Peter From rem-conf Tue Sep 02 12:24:26 1997 From rem-conf-request@es.net Tue Sep 02 12:24:26 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x5yRj-00055C-00; Tue, 2 Sep 1997 12:17:03 -0700 Date: Tue, 2 Sep 1997 12:17:05 -0700 X-Sender: alagu@mail.apple.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: confctrl@ISI.EDU, rem-conf@es.net From: Alagu Periyannan Subject: Sending "cliprect" over SDP X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all: Popular video compressions schemes used with RTP (H.262, H.263) offer a restricted set of picture sizes. These are CIF (376x288), QCIF (188x144) and in the case of H.263, 4CIF, 16CIF. Since these sizes are fixed many of today's conferencing and broadcast tools place a gray border around an image captured at a different size. This looks fine when the aspect ratio is close to the CIF ratio as is the case for NTSC. However, if one needs to send say cinema-style letterbox format the gray borders will be fat and will not look good. Letterbox format will be popular for sending movies over RTP in conjuction with RTSP. I would like to propose a scheme that can be used to send the real video size over SDP. This will not solve the gray border problem for conferencing since each participant can potential have a different size border. However, it will solve the problem in broadcast and unicast (in conjunction with RTSP) situtations. The "cliprect", i.e. the rectangle containing the useful part of the picture, will be sent in an "a=" attribute line within the "m=video" context. a=cliprect: Examples: if we want to send 160x120 centered inside a QCIF RTP session we send, a=cliprect: 12 14 132 174 if we want to send 160x120 top left justified inside a QCIF RTP session we send, a=cliprect: 0 0 120 160 if we want to send letterbox (160x69) top left justified inside a QCIF RTP session we send, a=cliprect: 0 0 69 160 It would be useful if we all agree to this and generate/recognize it. Any suggestions? Also, how does one formalize an "a=" attribute? (IANA?) --------------------------------------------------- Alagu Periyannan alagu@apple.com Interactive Multimedia Group Apple Computer, Inc. From rem-conf Tue Sep 02 13:04:39 1997 From rem-conf-request@es.net Tue Sep 02 13:04:39 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x5zAa-0005t1-00; Tue, 2 Sep 1997 13:03:24 -0700 From: Mark Handley X-Organisation: Information Sciences Institute, USC X-Phone: +1 617 253 6011 To: Alagu Periyannan cc: confctrl@ISI.EDU, rem-conf@es.net Subject: Re: Sending "cliprect" over SDP In-reply-to: Your message of "Tue, 02 Sep 1997 12:17:05 PDT." Date: Tue, 02 Sep 1997 16:01:06 -0400 Message-ID: <1012.873230466@north.lcs.mit.edu> Sender: mjh@north.lcs.mit.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list >The "cliprect", i.e. the rectangle containing the useful >part of the picture, will be sent in an "a=" attribute >line within the "m=video" context. > >a=cliprect: >It would be useful if we all agree to this and generate/recognize it. > >Any suggestions? This seems like a reasonable suggestion to me. It would be even better if there was a simple way to indicate the same thing for multi-party conferencing, but short of adding a new RTCP message type (which isn't really a good idea) I can't think of one. >Also, how does one formalize an "a=" attribute? (IANA?) The process isn't formalized yet, but we expect this to happen through IANA. Whether we expect people to write a one-page RFC for each attribute, or whether we'll collect new attributes together periodically, or whatever is not decided yet, but will I expect be sorted out when the IESG approve SDP for Proposed Standard. Mark From rem-conf Tue Sep 02 14:40:14 1997 From rem-conf-request@es.net Tue Sep 02 14:40:14 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x60ci-0006pQ-00; Tue, 2 Sep 1997 14:36:32 -0700 Message-Id: <3.0.1.32.19970902233456.006bc994@mail.cs.tu-berlin.de> X-Sender: stewe@mail.cs.tu-berlin.de X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 02 Sep 1997 23:34:56 +0200 To: Alagu Periyannan , confctrl@ISI.EDU, rem-conf@es.net From: "Dr. Stephan Wenger" Subject: Re: Sending "cliprect" over SDP In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 12:17 02.09.97 -0700, Alagu Periyannan wrote: > >Hi all: > >Popular video compressions schemes used with RTP >(H.262, H.263) offer a restricted set of picture sizes. > >These are CIF (376x288), QCIF (188x144) and in the >case of H.263, 4CIF, 16CIF. Since these sizes are fixed >many of today's conferencing and broadcast tools >place a gray border around an image captured at a >different size. I think that everyone agrees to the necessity of having a more flexible choice of picture sizes than the old CIF model. ITU-T expert groups on video compression realized this as well. The new version of H.263, currently known as it's working name H.263+, offers pictures sizes between 4 and 2048 pixels in X and Y dimension, which can be negotiated in an 4 pixel granularity. The signalling of the size of the coded picture is done within the Picture Header of H.263+. Similar mechanisms are available in MPEG 2 alias H.262. H.263+ will be a ITU-T recommendation around January 1998. It might be worth to wait for this new standard, especially because the implementation effort for the enhancement of the current (1995) version of H.263 to the new standard is not very high, if none of the optional modes are implemented. However, it might be very useful to think today about the necessity of having any announcement of this information, if it is already contained in the bitstream. One reason for that, which comes in mind, is recource allocation in the receivers. Opinions? Regards Stephan -- -- Dr. Stephan Wenger stewe@cs.tu-berlin.de From rem-conf Wed Sep 03 03:26:55 1997 From rem-conf-request@es.net Wed Sep 03 03:26:54 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x6CWa-0002m5-00; Wed, 3 Sep 1997 03:19:00 -0700 Date: Wed, 3 Sep 1997 10:25:18 +0200 From: Baltzer Science Message-Id: <199709030825.KAA00384@ns.baltzer.nl> Subject: Annals of Software Engineering content list Bcc: To: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Dear Reader Please find below the contents of our journal Annals of Software Engineering 3 More information on this journal: http://www.baltzer.nl/ansoft/ Sincerely, Baltzer Science Publishers mailer@ns.baltzer.nl _________________________________________ Annals of Software Engineering 3 (1997) Software Requirements Engineering Editor: Nancy R. Mead Nancy R. Mead Preface 1-3 Michael Jackson The meaning of requirements 5-21 Colin Potts and Idris Hsi Abstraction and context in requirements engineering: Toward a synthesis 23-61 Alan M. Davis, Kathleen Jordan and Tsuyoshi Nakajima Elements underlying the specification of requirements 63-100 Ian Sommerville and Pete Sawyer Viewpoints: principles, problems and a practical approach to requirements engineering 101-130 Jawed I. Siddiqi, Ian C. Morrey, Chris R. Roast and Mehmet B. Ozcan Towards quality requirements via animated formal specifications 131-155 Mark A. Ardis Formal methods for telecommunication system requirements: A survey of standardized languages 157-187 P. Ciancarini, S. Cimato and C. Mascolo Engineering formal requirements: An analysis and testing method for Z documents 189-219 David L. Coleman and Albert L. Baker Synthesizing structured analysis and object-based formal specifications 221-253 Fran Lustman A formal approach to scenario integration 255-271 Sunil Vadera and Farid Meziane Tools for producing formal specifications: a view of current architectures and future directions 273-290 Pei Hsia, David Kung and Chris Sell Software requirements and acceptance testing 291-317 Hermann Kaindl A practical approach to combining requirements definition and object-oriented analysis 319-343 F. Javier Lerch, Deborah J. Ballou and Donald E. Harter Using simulation-based experiments for software requirements engineering 345-366 Christof Ebert Dealing with nonfunctional requirements in large software systems 367-395 Balasubramaniam Ramesh, Curtis Stubbs, Timothy Powers and Michael Edwards Requirements traceability: Theory and practice 397-415 Richard E. Fairley and Richard H. Thayer The concept of operations: The bridge from operational requirements to technical specifications 417-432 George Spanoudakis and Anthony Finkelstein Reconciling requirements: a method for managing interference, inconsistency and conflict 433-457 Robyn R. Lutz and Robert M. Woodhouse Requirements analysis using forward and backward search 459-475 Robert J. Kosman A two-step methodology to reduce requirement defects 477-494 From rem-conf Wed Sep 03 04:14:10 1997 From rem-conf-request@es.net Wed Sep 03 04:14:09 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x6DMA-0003RW-00; Wed, 3 Sep 1997 04:12:18 -0700 To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: rem-conf@es.net From: The IESG Subject: Protocol Action: RTP Payload for Redundant Audio Data to Proposed Standard Date: Wed, 03 Sep 1997 07:11:18 -0400 Sender: scoya@ietf.org Message-ID: <9709030711.aa04346@ietf.org> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The IESG has approved the Internet-Draft "RTP Payload for Redundant Audio Data" as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact person is Allyn Romanow. Technical Summary This document describes a payload format for use with the Real-time Transport Protocol (RTP), verson 2, for encoding redundant data. Motivation for the protocol is the development of audio conferencing tools used in lossy packet networks such as the Internet Mbone. In a packet network, packet loss disrupts speech intelligibility making audio applications such as multimedia conferencing over the Internet undesirable to users. This protocol specifies a method for introducing redundancy into the data stream which allows the message to be reconstructed by the receiver when there is packet loss. Research referenced in the draft shows that the method works in situations found in the internet where simpler solutions are less effective. Working Group Summary There were initially two or three approaches to indicate which encodings are being carried. However, joint development between UCL and INRIA led to a single approach which is reflected in this draft. Bottom line, no WG dissension. Protocol Quality This draft was reviewed for the IESG by Allyn Romanow. From rem-conf Wed Sep 03 04:41:27 1997 From rem-conf-request@es.net Wed Sep 03 04:41:26 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x6DkC-0003wb-00; Wed, 3 Sep 1997 04:37:08 -0700 Message-ID: <340D4BAE.41E8@darmstadt.gmd.de> Date: Wed, 03 Sep 1997 13:36:14 +0200 From: Peter Hoermann X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: M.Connell@cqu.edu.au CC: rem-conf@es.net Subject: Re: H.320/H.323-Gateways & Pricing References: <340C3760.3A8A@darmstadt.gmd.de> <340CA549.791A@janus.cqu.edu.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > > + RADVision (L2W-323) > > + Picturetel (LiveGateway 3.0) > > + First Virtual Corporation (V-Gate 323) > > > > Do you have URLs for these products? Hi Merv and all, in addition to my request of yesterday I'm adding the URLs for the above gateways (the ones I already know of): Radvision: http://www.radvision.com/press.htm Picturetel: http://www.pictel.com/livelanp.htm FVC: http://www.fvc.com/whatsnew/gate.html Regards Peter From rem-conf Wed Sep 03 15:08:13 1997 From rem-conf-request@es.net Wed Sep 03 15:08:12 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x6NRb-0000i4-00; Wed, 3 Sep 1997 14:58:35 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Wed, 3 Sep 1997 14:58:23 -0700 (PDT) Message-Id: <199709032158.OAA11943@hille.msri.org> To: rem-conf@es.net From: Reply-to: wu@bmrc.berkeley.edu Subject: Advanced Perspective Display Formats for Air Traffic Control X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Advanced Perspective Display Formats for Air Traffic Control Date: Oct 01, 1997 Time: 12:30 PST8PDT 2 hours Contact: wu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w6.html Description: An on-line dynamic method for automated viewing parameters management in perspective displays is presented. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Wed Sep 03 21:33:07 1997 From rem-conf-request@es.net Wed Sep 03 21:33:06 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x6TVB-0002jM-00; Wed, 3 Sep 1997 21:26:41 -0700 From: Malcolm Caldwell Message-Id: <199709040426.NAA14312@morinda.cs.ntu.edu.au> Subject: Broadcast AUUG97 To: rem-conf@es.net Date: Thu, 4 Sep 1997 13:56:15 +0930 (CST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This broadcast is already in progress. MBone Broadcast Announcement ---------------------------- Title: AUUG97 conference from Brisbane Australia Date: 3-5 September 1997 Time: 0900-2330 AEST (GMT+10) Contact: malcolm@it.ntu.edu.au URL: http://www.auug.org.au/auug97/ Description: Keynote speakers and the technical stream from the AUUG97 conference. This event (and MBONE broadcast) is already half over - but there is still many things to come, including the conference dinner which will feature Robots >from the University of Queensland! (Dinner starts at 1900 AEST (GMT+10) don't miss it!) -- Malcolm Caldwell - Network Supervisor Email:malcolm@it.ntu.edu.au Information Technology Support Ph: +61 8 89466631 Northern Territory University,Darwin Fax: +61 8 89466630 CASUARINA 0909 Australia From rem-conf Thu Sep 04 11:47:44 1997 From rem-conf-request@es.net Thu Sep 04 11:47:44 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x6gnx-0007HR-00; Thu, 4 Sep 1997 11:38:57 -0700 Date: Thu, 4 Sep 1997 11:09:01 -0700 X-Sender: alagu@mail.apple.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: confctrl@ISI.EDU, rem-conf@es.net From: Alagu Periyannan Subject: Re: Sending "cliprect" over SDP X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all, There was an error in the CIF/QCIF numbers I sent out in my previous email. Thanks to Kipp (H.A. Kippenhan Jr.) for pointing this out. Actually the CIF size is 352x288 and the QCIF size is 176x144. (I had incorrectly used 376x288 and 188x144) Also please note that the origin for the purposes of sending the cliprect is located at the top left corner of the image. So the examples will read, Examples: if we want to send 160x120 centered inside a QCIF RTP session we send, a=cliprect: 12 8 132 168 if we want to send 160x120 top left justified inside a QCIF RTP session we send, a=cliprect: 0 0 120 160 if we want to send letterbox (160x69) top left justified inside a QCIF RTP session we send, a=cliprect: 0 0 69 160 --------------------------------------------------- Alagu Periyannan alagu@apple.com Interactive Multimedia Group Apple Computer, Inc. From rem-conf Fri Sep 05 11:13:30 1997 From rem-conf-request@es.net Fri Sep 05 11:13:30 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x72dw-0000b2-00; Fri, 5 Sep 1997 10:58:04 -0700 Message-ID: <341047C3.9A0EB8CB@dnrc.bell-labs.com> Date: Fri, 05 Sep 1997 13:56:19 -0400 From: "Jonathan D. Rosenberg" Reply-To: jdrosen@dnrc.bell-labs.com X-Mailer: Mozilla 4.0 [en] (Win95; U) MIME-Version: 1.0 To: rem-conf@es.net Subject: MPEG Boards X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list avt'ers, Does anyone know of any good MPEG2 encoder/decoder boards for PC's (Win NT) that come with software that allow me to send the compressed video over a network? A board with an NTSC output to display the decompressed video on a TV would also be a big plus. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 PHONE: (908) 949-6418 Rm. 4B-505 FAX: (908) 834-5379 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Fri Sep 05 12:26:26 1997 From rem-conf-request@es.net Fri Sep 05 12:26:26 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x73wp-0003xx-00; Fri, 5 Sep 1997 12:21:39 -0700 X-Sender: ari@mailman Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 5 Sep 1997 12:24:22 -0700 To: jdrosen@dnrc.bell-labs.com From: ari@sprintlabs.com (Ari Ollikainen) Subject: Re: MPEG Boards Cc: rem-conf@es.net X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list jdrosen@dnrc.bell-labs.com wrote: >avt'ers, > >Does anyone know of any good MPEG2 encoder/decoder boards for PC's (Win >NT) that come with software that allow me to send the compressed video >over a network? A board with an NTSC output to display the decompressed >video on a TV would also be a big plus. You could just go and by the IBM 8300 V(ideo)A(ccess)Node for about ~$40K and have a complete, integrated (encoder + decoder+ ATM25/155 interface + software+ development tools) solution all packaged in a 200Mhz Pentium running OS/2! Alternatively: Check out the "The MPEGXpress 2000...a real-time MPEG-2 encoding and playback solution. Similar configurations are available for Windows NT and for PCI-based Power Macintosh..." more info at: http://www.mpegexpress.com/2000specs.html Wired Inc makes a encoder (PCI) board, ButaneII, which is available by special order for ~$5K. They also make PCI decoder boards that are around ~$.5K. more info at: http://www.wiredinc.com InnovaCom has an encoder board (PCI), DV2100/2110, that's ~$10K. more info at: http:www.innovacom-mpeg2.com Expect these prices to plummet by 1Q/2Q98 when single-chip encoders will become available to build single-board codecs... _/_/ _/_/_/_/ _/ Ari Ollikainen _/ _/ _/ _/ _/ Sprint Advanced Technology Laboratories _/_/_/_/ _/_/_/_/ _/ Switching and Interworking Development _/ _/ _/ _/ _/ 1 Adrian Court (M/S: CABURS0102) _/ _/ _/ _/ _/ Burlingame, CA 94010 ~~~~~~~~~~ OLTECO ~~~~~~~~~ Voice: 415.375.4265 FAX: 415.375.4490 From rem-conf Fri Sep 05 13:46:10 1997 From rem-conf-request@es.net Fri Sep 05 13:46:08 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x75Dp-0006uB-00; Fri, 5 Sep 1997 13:43:17 -0700 Message-Id: <199709052043.AA20771@www0.reith.bbc.co.uk> From: gordon.joly@bbc.co.uk (Dr. Gordon Joly) To: mbone@isi.edu, rem-conf@es.net Cc: webweaver@bbc.co.uk X-Phone: +44 181 752 5454 X-Fax: +44 181 752 5862 X-Url: http://www.bbc.co.uk/ X-Organisation: British Broadcasting Corporation Subject: BBC Radio 5 Live multicast - Saturday 6th September 1997 Date: Fri, 05 Sep 1997 21:42:41 +0100 Sender: gordon.joly@bbc.co.uk X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The BBC has joined to the MBONE to provide a service to the public, both within the UK and abroad. There will be a live multicast of BBC Radio 5 Live, for part of Saturday, 6th September, 1997, with coverage of the funeral of Diana, Princess of Wales, in London. Please see the announcement in sd(r). -- gordon.joly@bbc.co.uk gjoly@acm.org http://www.bbc.co.uk/ BBC White City, Room G374, 201 Wood Lane, LONDON W12 7TS. From rem-conf Fri Sep 05 14:55:03 1997 From rem-conf-request@es.net Fri Sep 05 14:55:02 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x76It-00000X-00; Fri, 5 Sep 1997 14:52:35 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Fri, 5 Sep 1997 14:52:28 -0700 (PDT) Message-Id: <199709052152.OAA13012@hille.msri.org> To: rem-conf@es.net From: Reply-to: mmadrid@psc.edu Subject: Pittsburgh Supercomputing Center Workshop X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Pittsburgh Supercomputing Center Workshop Date: Sep 08, 1997 Time: 09:30 GMT 9 hours Contact: mmadrid@psc.edu URL: http://www.psc.edu/training/J90_Sept_97/welcome.html Description: The Pittsburgh Supercomputing Center will be broadcasting its CRAY J90/C90 workshop, September 8-11. Agenda and lecture notes can be found at http://www.psc.edu/training/J90_Sept_97/welcome.html mbone broadcast schedule http://www.msri.org/mbone From rem-conf Fri Sep 05 15:10:10 1997 From rem-conf-request@es.net Fri Sep 05 15:10:09 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x76Xc-0000cH-00; Fri, 5 Sep 1997 15:07:48 -0700 Message-ID: <340FDAB7.1887@netlink.co.uk> Date: Fri, 05 Sep 1997 11:11:05 +0100 From: Dennis Johnstone Reply-To: dennisj@netlink.co.uk X-Mailer: Mozilla 3.0 (Macintosh; I; PPC) MIME-Version: 1.0 To: Gordon Joly , dominik@tecc.co.uk, brandon@bbc.co.uk, Simon Lockhart , tim.locke@bbc.co.uk, mbone@isi.edu, rem-conf@es.net Subject: Re: BBC Radio 5 Live multicast - Saturday 6th September 1997 References: <199709052043.AA20774@www0.reith.bbc.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Gordon Joly wrote: >There will be a live multicast of BBC > Radio 5 Live, for part of Saturday, 6th September, >1997 Actually we're live from 2300 on Friday (right now actually!) until 1300 on Sunday. I'd say that's more than part of Saturday... The mirrors kick in between 0830 and 0930, and then drop out at 1700. Dennis Johnstone From rem-conf Fri Sep 05 21:16:40 1997 From rem-conf-request@es.net Fri Sep 05 21:16:40 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x7CDa-0003Bu-00; Fri, 5 Sep 1997 21:11:30 -0700 Message-ID: <3410D76B.2CFC3A59@nc.u-tokyo.ac.jp> Date: Sat, 06 Sep 1997 13:09:15 +0900 From: Shingo Ichii X-Mailer: Mozilla 4.01 [ja] (Win95; I) MIME-Version: 1.0 To: jdrosen@dnrc.bell-labs.com CC: rem-conf@es.net Subject: Re: MPEG Boards X-Priority: 3 (Normal) References: <341047C3.9A0EB8CB@dnrc.bell-labs.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cream.nc.u-tokyo.ac.jp id NAA03654 X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Jonathan D. Rosenberg wrote: > Does anyone know of any good MPEG2 encoder/decoder boards for PC's (Win > NT) that come with software that allow me to send the compressed video > over a network? A board with an NTSC output to display the decompressed > video on a TV would also be a big plus. Though I don't know if they export, NTT Electronics (www.nel.co.jp) makes a signle-board (PCI) MPEG2 real-time encoder.=81@=81@ As long as I could = see, the quality is very good, but the price is high (~ 4Myen =3D $33K). Shingo Ichii Computer Center, University of Tokyo =81@ From rem-conf Sun Sep 07 21:21:28 1997 From rem-conf-request@es.net Sun Sep 07 21:21:28 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x7v3p-0003fG-00; Sun, 7 Sep 1997 21:04:25 -0700 Message-Id: <01BCBBE9.47F146E0.paul@vela.com> From: Paul Mears Reply-To: "paul@vela.com" To: "'ari@sprintlabs.com'" Cc: "'jdrosen@dnrc.bell-labs.com'" , "'rem-conf@es.net'" Subject: Don't forget about Vela Research Date: Sun, 7 Sep 1997 16:51:27 -0400 Organization: Vela Research X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list > From: Ari Ollikainen > To: jdrosen@dnrc.bell-labs.com > Cc: rem-conf@es.net > Subject: Re: MPEG Boards > Date: Friday, September 05, 1997 3:24 PM > > jdrosen@dnrc.bell-labs.com wrote: > >avt'ers, > > > >Does anyone know of any good MPEG2 encoder/decoder boards for PC's (Win > >NT) that come with software that allow me to send the compressed video > >over a network? A board with an NTSC output to display the decompressed > >video on a TV would also be a big plus. > > > You could just go and by the IBM 8300 V(ideo)A(ccess)Node for > about ~$40K and have a complete, integrated (encoder + decoder+ > ATM25/155 interface + software+ development tools) solution all > packaged in a 200Mhz Pentium running OS/2! > > Alternatively: > > Check out the "The MPEGXpress 2000...a real-time MPEG-2 encoding and > playback solution. Similar configurations are available for > Windows NT and for PCI-based Power Macintosh..." > > more info at: http://www.mpegexpress.com/2000specs.html > > Wired Inc makes a encoder (PCI) board, ButaneII, which is available > by special order for ~$5K. They also make PCI decoder boards > that are around ~$.5K. > > more info at: http://www.wiredinc.com > > InnovaCom has an encoder board (PCI), DV2100/2110, that's ~$10K. > > more info at: http:www.innovacom-mpeg2.com > > Expect these prices to plummet by 1Q/2Q98 when single-chip > encoders will become available to build single-board codecs... > > > > > _/_/ _/_/_/_/ _/ Ari Ollikainen > _/ _/ _/ _/ _/ Sprint Advanced Technology Laboratories > _/_/_/_/ _/_/_/_/ _/ Switching and Interworking Development > _/ _/ _/ _/ _/ 1 Adrian Court (M/S: CABURS0102) > _/ _/ _/ _/ _/ Burlingame, CA 94010 Vela Research also designs and sells MPEG-2 encoders and decoders. Check out our web page at http://www.vela.com/ for our extensive set of products based upon C-Cube and IBM encoder chip sets, and LSI Logic and IBM decoder chip sets. Drop me an email or call if you have questions. Paul... From rem-conf Mon Sep 08 08:26:49 1997 From rem-conf-request@es.net Mon Sep 08 08:26:48 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x85bY-0007Z5-00; Mon, 8 Sep 1997 08:19:56 -0700 Message-Id: Comments: Authenticated sender is From: "Frank P. Troy" To: rem-conf@es.net Date: Mon, 8 Sep 1997 11:15:27 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Mrouted Reply-to: ftroy@csc.com Priority: normal X-mailer: Pegasus Mail for Win32 (v2.53/R1) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi all Is there a white paper published somewhere that explains (in detail) how Mrouted works? Thanks -------------------------------------------- Frank P. Troy Phone: 703-471-3694 Sr. Network Engineer Fax: 703-471-1575 AT&T DISC Development Page: 888-808-0593 3001 Centreville Rd. e-mail: ftroy@csc.com Herndon, VA 20171 From rem-conf Tue Sep 09 08:16:29 1997 From rem-conf-request@es.net Tue Sep 09 08:16:28 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x8Rn8-0002QD-00; Tue, 9 Sep 1997 08:01:22 -0700 Sender: helbig@pfa.research.philips.com Message-Id: <341566D0.1826@pfa.research.philips.com> Date: Tue, 09 Sep 1997 17:10:08 +0200 From: "Dr. Tobias Helbig" Organization: Philips Research Labs Aachen X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.4 sun4m) Mime-Version: 1.0 To: rem-conf@es.net Subject: Looking for video conferencing system Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi there, I'm looking for a video conferencing system to be installed at our site based on Win 95 and/or Win NT PCs. It shall support the feature of redirecting on-going video conferencing calls from one room to another (e.g., when the person is moving to another room). Can anybody help me locating a product or stable prototype that (a) supports the feature of redirecting on-going calls? (b) enables to control this feature by external software (i.e., by our code which detects when a person is moving from one room to another)? I appreciate any reply to my address given below. Thanks a lot. Tobias Helbig -- ---------------------------------------------------------------------- | Dr. Tobias Helbig | Philips GmbH Research Laboratories | | Research Scientist | Weisshausstr. 2 | | | D-52066 Aachen, Germany | | | Phone +49-241-6003-515 / Fax -518 | | | Email helbig@pfa.research.philips.com | ---------------------------------------------------------------------- From rem-conf Tue Sep 09 19:17:06 1997 From rem-conf-request@es.net Tue Sep 09 19:17:04 1997 Received: from list by mail1.es.net with local (Exim 1.62 #2) id 0x8cDA-0000Su-00; Tue, 9 Sep 1997 19:08:56 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Tue, 9 Sep 1997 19:08:42 -0700 (PDT) Message-Id: <199709100208.TAA15742@hille.msri.org> To: rem-conf@es.net From: Reply-to: jyluke@ew.mimos.my Subject: Multimedia Asia 97 Conference and Plenary Sessions X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Multimedia Asia 97 Conference and Plenary Sessions Date: Sep 16, 1997 Time: 08:00 GMT+8 10 hours Contact: jyluke@ew.mimos.my URL: http://www2.jaring.my/nitc/events/mma97/ Description: Multimedia Asia 97 is an annual multimedia event held in Malaysia for Malaysia's Multimedia Super Corridor (MSC). The event will bill held from Sept 16 to 19, 1997. This broadcast will include key note address by the Prime Minister of Malaysia and other selected plenary sessions. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Wed Sep 10 21:51:03 1997 From rem-conf-request@es.net Wed Sep 10 21:51:03 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x90rv-0000ma-00; Wed, 10 Sep 1997 21:28:39 -0700 Sender: mueller@es.net Message-ID: <34177372.6628@fh-zwickau.de> Date: Thu, 11 Sep 1997 06:28:34 +0200 From: Rainer Mueller Organization: HTW-Zwickau X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: rem-conf@es.net Subject: International ICEM Surf User Meeting 1997 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: International ICEM Surf User Meeting 1997 Date: September 23-24, 1997 Time: 10:30 MET; 2 hours Contact org: lutz.nagel@fh-zwickau.de icem.technologies@cdc.com Contact tech: rainer.mueller@fh-zwickau.de URL: http://www.fh-zwickau.de/veranst/icem/icem.htm Description: The first two hours of the meeting will be broadcasted -- Name: Rainer Mueller Org: Westsaechsische Hochschule Zwickau (FH) / HRZ Phone: +49 375 536-1203 Fax : +49 375 536-1202 E-Mail: rainer.mueller@fh-zwickau.de From rem-conf Thu Sep 11 09:05:46 1997 From rem-conf-request@es.net Thu Sep 11 09:05:45 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9Bd5-0005VI-00; Thu, 11 Sep 1997 08:58:03 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 11 Sep 1997 08:57:51 -0700 (PDT) Message-Id: <199709111557.IAA20083@hille.msri.org> To: rem-conf@es.net From: Reply-to: davidwu@bmrc.berkeley.edu Subject: Virtual Prototyping of Mathematically Inspired Sculptures X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Virtual Prototyping of Mathematically Inspired Sculptures Date: Sep 17, 1997 Time: 12:30 PST8PDT 2 hours Contact: davidwu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w4.html Description: A computer program has been developed to visualize different configurations of abstract geometrical sculptures involving knots and saddle surfaces, and to optimize the parameters that define the final shape. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 11 10:22:11 1997 From rem-conf-request@es.net Thu Sep 11 10:22:11 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9Csd-0007J4-00; Thu, 11 Sep 1997 10:18:11 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 11 Sep 1997 10:17:13 -0700 (PDT) Message-Id: <199709111717.KAA20295@hille.msri.org> To: rem-conf@es.net From: Reply-to: rdhobby@ucdavis.edu Subject: Internet2 Campus networking Workshop X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Internet2 Campus networking Workshop Date: Sep 15, 1997 Time: 08:30 PST8PDT 3.5 hours Contact: rdhobby@ucdavis.edu URL: http://ansa.ucdavis.edu/cenic/ws_agenda.html Description: The Workshop will discuss campus networking issues in implementing Internet2 functionality. See http://www.internet2.edu for more details on the Internet2 Project. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 11 10:22:11 1997 From rem-conf-request@es.net Thu Sep 11 10:22:11 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9Ctb-0007KJ-00; Thu, 11 Sep 1997 10:19:11 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 11 Sep 1997 10:18:17 -0700 (PDT) Message-Id: <199709111718.KAA20324@hille.msri.org> To: rem-conf@es.net From: Reply-to: rdhobby@ucdavis.edu Subject: Internet2 Campus networking Workshop X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Internet2 Campus networking Workshop Date: Sep 16, 1997 Time: 08:30 PST8PDT 6.5 hours Contact: rdhobby@ucdavis.edu URL: http://ansa.ucdavis.edu/cenic/ws_agenda.html Description: The Workshop will discuss campus networking issues in implementing Internet2 functionality. See http://www.internet2.edu for more details on the Internet2 Project. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 11 12:05:16 1997 From rem-conf-request@es.net Thu Sep 11 12:05:16 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9EVO-0001U9-00; Thu, 11 Sep 1997 12:02:18 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 11 Sep 1997 12:02:00 -0700 (PDT) Message-Id: <199709111902.MAA20505@hille.msri.org> To: rem-conf@es.net From: Reply-to: mbone@msri.org Subject: Mathematics of Games and Sports by Joseph B. Keller, Stanford University X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Mathematics of Games and Sports by Joseph B. Keller, Stanford University Date: Sep 15, 1997 Time: 12:00 GMT+8 1 hours Contact: mbone@msri.org URL: http://www.msri.org/lecturenotes/97/SIAM/keller/ Description: The speaker will present a mathematician's perspective on some games and sports, and answer questions like these: How many shuffles to mix a deck? When is a team eliminated? What is the probability of heads? How should teams be ranked? What is the probability of a shutout? How do world records vary with time? How should a runner vary his speed in a race? Does it pay to exercise? mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 11 12:19:22 1997 From rem-conf-request@es.net Thu Sep 11 12:19:21 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9Ejw-000202-00; Thu, 11 Sep 1997 12:17:20 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 11 Sep 1997 12:16:57 -0700 (PDT) Message-Id: <199709111916.MAA20561@hille.msri.org> To: rem-conf@es.net From: Reply-to: mbone@msri.org Subject: The Baleful Effect of Computer Languages and Benchmarks Upon Applied Mathematics, Physics and Chemistry X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: The Baleful Effect of Computer Languages and Benchmarks Upon Applied Mathematics, Physics and Chemistry Date: Sep 15, 1997 Time: 12:00 GMT+8 1 hours Contact: mbone@msri.org URL: http://www.msri.org/lecturenotes/97/SIAM/kahan/ Description: mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 11 12:23:40 1997 From rem-conf-request@es.net Thu Sep 11 12:23:40 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9Epn-0002Fx-00; Thu, 11 Sep 1997 12:23:23 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 11 Sep 1997 12:22:50 -0700 (PDT) Message-Id: <199709111922.MAA20602@hille.msri.org> To: rem-conf@es.net From: Reply-to: mbone@msri.org Subject: Multiresolution Algorithms in Computer Graphics by Peter Schroder, California Institute of Technology X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Multiresolution Algorithms in Computer Graphics by Peter Schroder, California Institute of Technology Date: Sep 16, 1997 Time: 12:00 GMT+8 1 hours Contact: mbone@msri.org URL: http://msri.org/lecturenotes/97/SIAM/schroder/ Description: Computational techniques based on wavelets and more generally multiresolution approaches have made tremendous inroads into computer graphics applications. Examples include illumination computations, hierarchical mesh editing, geometric modeling, and 3D scanning. This development is motivated by the twin challenges of computer graphics: complexity and interactivity. In order to generate realistic images of objects and creatures with realistic motion, accurate simulations need to be performed for ever more complicated geometry. At the same time fast updates are necessary for interactive environments. Multiresolution as a general tool provides representations and algorithms which scale well to large problem sizes, are very general and robust, and have modest storage costs. The speaker will give an overview of these applications and algorithms and discuss some of the issues that arise when attempting to take classical constructions into the messiness of real ! ! applications. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 11 13:09:53 1997 From rem-conf-request@es.net Thu Sep 11 13:09:52 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9FUW-0003L9-00; Thu, 11 Sep 1997 13:05:28 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 11 Sep 1997 13:04:55 -0700 (PDT) Message-Id: <199709112004.NAA20750@hille.msri.org> To: rem-conf@es.net From: Reply-to: mbone@msri.org Subject: High Performance Computer Architecture by John L. Hennessy, Stanford University X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: High Performance Computer Architecture by John L. Hennessy, Stanford University Date: Sep 16, 1997 Time: 13:00 GMT+8 1 hours Contact: mbone@msri.org URL: http://www.msri.org/lecturenotes/97/SIAM/hennessy/ Description: Recent directions in high performance computers for scientific computing have been driven by two key factors: the advantages of employing commodity technology as building blocks and the understanding of how to build scalable multiprocessors that efficiently support shared-memory programming. The first capability can lead to high performance computers that are cost competitive with workstations and servers, while the second capability allows high performance machines to be software compatible with small and mid-range computers that uniformly use shared-memory multiprocessing. While these trends may increase the usability and generality of high performance computing, other technology trends will require users to be more aware of issues such as locality of access and data distribution. The challenge in the future will be in creating hardware and software that helps the user to achieve high performance without undue programming effort. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 11 13:09:57 1997 From rem-conf-request@es.net Thu Sep 11 13:09:57 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9FXQ-0003M6-00; Thu, 11 Sep 1997 13:08:28 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 11 Sep 1997 13:08:24 -0700 (PDT) Message-Id: <199709112008.NAA20795@hille.msri.org> To: rem-conf@es.net From: Reply-to: mbone@msri.org Subject: 35 Years of (Linear) Probing, by Donald E. Knuth, Professor Emeritus, Stanford University X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: 35 Years of (Linear) Probing, by Donald E. Knuth, Professor Emeritus, Stanford University Date: Sep 17, 1997 Time: 12:00 GMT+8 1 hours Contact: mbone@msri.org URL: http://www.msri.org/lecturenotes/97/SIAM/knuth/ Description: Many computer programs access large tables of data by using a classical variant of hashing called "linear probing," also known to children as the game of "musical chairs." When the author first studied the characteristics of this simple method in 1962, he came to understand that the mathematical analysis of algorithms was a rich subject suitable for a lifetime of study. This talk surveys the mathematical analysis of algorithms by focussing on advances that have been in the analysis of linear probing from 1962 to 1997, and by noting surprising relations between this algorithm and other important algorithms and combinatorial problems, including the study of random graphs. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 11 13:12:58 1997 From rem-conf-request@es.net Thu Sep 11 13:12:57 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9FbO-0003gI-00; Thu, 11 Sep 1997 13:12:34 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 11 Sep 1997 13:11:33 -0700 (PDT) Message-Id: <199709112011.NAA20830@hille.msri.org> To: rem-conf@es.net From: Reply-to: mbone@msri.org Subject: Clusters and Massively Parallel Computers: Are the Architectures Converging? by Paul C. Messina, California Institute of Technology X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Clusters and Massively Parallel Computers: Are the Architectures Converging? by Paul C. Messina, California Institute of Technology Date: Sep 17, 1997 Time: 13:00 GMT+8 1 hours Contact: mbone@msri.org URL: http://www.msri.org/lecturenotes/97/SIAM/messina/ Description: Clusters of powerful workstations or PCs connected by various network technologies have become a popular, inexpensive computing resource. Massively parallel computers are still considered to be the right tool for the biggest scientific and engineering computations. However, from an application standpoint, the difference between the two architectural options seem to be getting less and less obvious. The cluster approach can scale to very large configurations effectively, although perhaps not to equal the level of the very biggest MPPs. Perhaps the most important issues have to do with how the system is managed (as one powerful system or as many workstations), and on the entire system environment, including the type of job scheduling, system software, and software tools, and the availability of mass storage and archival file systems. This talk will explore these issues and present data from a variety of applications and configurations in use today. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 11 13:18:24 1997 From rem-conf-request@es.net Thu Sep 11 13:18:24 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9FgH-0004XA-00; Thu, 11 Sep 1997 13:17:37 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 11 Sep 1997 13:17:18 -0700 (PDT) Message-Id: <199709112017.NAA20866@hille.msri.org> To: rem-conf@es.net From: Reply-to: mbone@msri.org Subject: IP10 Impact of the Internet on Scientific Computing by Eric Grosse, Bell Laboratories, Lucent Technologies X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: IP10 Impact of the Internet on Scientific Computing by Eric Grosse, Bell Laboratories, Lucent Technologies Date: Sep 18, 1997 Time: 12:00 GMT+8 1 hours Contact: mbone@msri.org URL: http://www.msri.org/lecturenotes/97/SIAM/grosse/ Description: The scientific computing community has long used the Internet for communication of email, software, and papers. SIAM's online journal server this year is a welcome further step. But, with the notable early exception of the Macsyma server at MIT in the 70s, there has been little use of the Internet for actual computation. In the past few years, we have again started to see experimental computational servers appearing. What are their prospects for success? What is needed at the client end? What languages and protocols should be used for maximum interoperability and efficiency? How can we structure our applications to allow flexible adaptation to clients and channels of different strengths? Slides are available for this talk in pdf format http:http://cm.bell-labs.com/who/ehg/slides/siam97/talk.pdf mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 11 13:22:05 1997 From rem-conf-request@es.net Thu Sep 11 13:22:05 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9Fk9-0004tS-00; Thu, 11 Sep 1997 13:21:37 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 11 Sep 1997 13:21:16 -0700 (PDT) Message-Id: <199709112021.NAA20904@hille.msri.org> To: rem-conf@es.net From: Reply-to: mbone@msri.org Subject: Past-President's Address: The Pursuit of Optimality: From the Big Picture to the Gory Details by Margaret H. Wright, Bell Laboratories X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Past-President's Address: The Pursuit of Optimality: From the Big Picture to the Gory Details by Margaret H. Wright, Bell Laboratories Date: Sep 18, 1997 Time: 13:00 GMT+8 1 hours Contact: mbone@msri.org URL: http://www.msri.org/lecturenotes/97/SIAM/wright/ Description: A desire to optimize---to do the best thing---is ubiquitous throughout mathematics, computing, science, and engineering (not to mention everyday life). Research in optimization comes in forms ranging from mathematical theory to practical rules of thumb, from general-purpose methods to application-specific heuristics. This talk will be a melange of topics involving recent work in non-derivative optimization and interior methods, chosen by the speaker to convey an overview of selected themes in optimization today. The punch line will be the joy of seeking, and finding, underlying commonalities and substantive distinctions. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 11 14:54:18 1997 From rem-conf-request@es.net Thu Sep 11 14:54:18 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9H9n-0006Tf-00; Thu, 11 Sep 1997 14:52:11 -0700 Date: Thu, 11 Sep 1997 17:51:55 -0400 From: Debanjan Saha Message-Id: <9709112151.AA17796@tapti.watson.ibm.com> To: end2end-interest@ISI.EDU, tccc@cs.umass.edu, ietf@ietf.org, int-serv@ISI.EDU, rem-conf@es.net Subject: JHSN special issue on Multimedia Network (CFP) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please feel free to circulate the CFP by any means you deem appropriate. Also, please excuse any multiple copies of this CFP you may receive due to your memberships in multiple mailing lists. Thanks and regards, Debanjan CALL FOR PAPERS ---------------------------------------------------------------------------- JOURNAL OF HIGH SPEED NETWORKS Special Issue On Multimedia Networking ----------------------------------------------------------------------------- The rapid proliferation of multimedia applications has severely strained an already overloaded networking infrastructure. In order to foster an environment for ubiquitous deployment of these applications, it is imperative that we design and implement the next generation of network protocols and services that provide scalable end-to-end support to networked multimedia applications. The purpose of this journal issue is to report on the latest technological advances that will enable the development of such an infrastructure. The journal is looking for contributions in the following areas: o RSVP and integrated services in the Internet o Queue management in routers and switches o QoS signaling and routing in IP and ATM networks o Audio/Video streaming, push and pull technologies o Multicasting and media scaling, rate control o Network conscious/adaptive applications and protocols o Application level framing, customizable protocol features o New applications, experimental protocols and systems o Multimedia over cable modems/xDSL, wireless/satellite links o Traffic analysis, performance modeling and evaluation Important Dates: Paper submission deadline: October 31, 1997. First Round of Reviews: February 15, 1998 Acceptance Notification: March 30, 1998 Expected Publication Date: Summer, 1998 Please submit 4 copies of your paper to the editors of the special issue: Satish K. Tripathi Debanjan Saha Dean and Johnson Chair Professor Research Staff Member Bourns College of Engineering Room# H3-D32 University of California IBM T.J. Watson Research Center Riverside, CA 92521-0425 Hawthorne, NY 10532 Phone: (909) 787-6374 Phone: (914) 784-7194 Fax: (909) 787-3188 Fax: (914) 784-6205 Email: tripathi@engr.ucr.edu Email: debanjan@watson.ibm.com http://www.research.ibm.com/people/d/debanjan From rem-conf Fri Sep 12 01:44:42 1997 From rem-conf-request@es.net Fri Sep 12 01:44:41 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0x9RCB-0002qU-00; Fri, 12 Sep 1997 01:35:19 -0700 From: petri.koskelainen@research.nokia.com (Koskelainen Petri NRC/Tre) To: confctrl@isi.edu ('confctrl@isi.edu'), rem-conf@es.net ('rem-conf@es.net') Message-ID: <1997Sep12.112945.1751.1063168@nrchub01he.research.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 12 Sep 1997 11:36:09 +0200 Subject: SDP format for H.263 options X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Currently it is not possible to specify any codec specific options in SIP/SDP architecture. For example, H.263 has many options and parameters which are almost mandatory (it makes no sense to say "lets use H.263" without knowledge of its capabilities). Best place to include these codec specific parameters in SDP is: a=fmtp: So, these format speficic parameters must be defined somewhere and it seems (like Henning proposed) that the best place to do it, is in corresponding RTP mapping draft as an annex. Another solution is to make new internet-draft (for every codec). Below is a proposal for H.263 SDP format specific parameter mapping, to be included into "RTP Payload Format for H.263 Video Streams" draft. This proposal assumes: (needs to be said also in the SIP draft) In the case of SIP, these codec options mean decoder capabilities. The idea is, that when making an INVITE, it includes the codec (H.263) and those codec options (e.g. SAC, PB-frames) which are decodeable by this decoder. Example excerpt from SIP INVITE message: ... m=video 55514 RTP/AVP 34 a=fmtp 34 CIF=4 QCIF=2/MaxBitRate=1000/SAC/AP Syntax above means that H.263 codec with preferred picture size of CIF (with min picture interval of 4) and secondary picture size is QCIF and arithmetic coding and advance prediction are in use and max bitrate decoable by decoder is 100 kbit/s. If caller does not want to receive all options (perhaps because his pc is a slow 486) then he just tells what options he wishes to receive. Other end, may (or may not) use them in the encoder. Any comments about mapping or the right place to define these ? --------------------------------------- clip clip---------------------- Harri Honko Petri Koskelainen Jouni Salonen Nokia Research Center ANNEX A (in "RTP payload format for H.263 video") SDP syntax for H.263 video This annex defines the SDP [2] syntax for H.263 codec options and parameters. It is often useful to know beforehand (in call setup phase) what features of H.263 the other end supports. This annex defines the for H.263, which exists in a=fmtp: as defined in the SDP document. Actual usage and negotiation of attributes is specified in SIP [3] and SAP [4] documents. These options are especially useful in SIP. In SAP it is not clear whether they have any use. In SIP, these format specific parameters are decoder properties, and in SAP they are encoder capabilities. The SAP rules are applied also if a multicast session is advertized in a web page in SDP format. Following text assumes that SIP is used. In the end of this annex, there is a short chapter which discusses how these options and parameters are used with SAP. A.1 H.263 Codec Options Following words describe 4 options defined for H.263. Later versions of H.263 (e.g. so called H.263+, currently a ITU-T draft) defines more options and they should be specified later for SDP. These options are separated by single slash ("/") between them. For further description about these parameters, please refer to ITU documents [1]. Word: URV Explanation: UnRestricted motion Vector option. Word: SAC Explanation: Syntax based Arithmetic Coding. Word: AP Explanation: Advanced Prediction. Word: PB Explanation: PB Frames. These words exist only if the sender of this SDP message is able or willing to decode those. E.g. If a terminal is capable of decoding SAC and AP options, it can put SAC/AP in the beginning of . Then the other party knows it, and can use those options in its encoder. A.2 Other H.263 codec parameters This chapter describes parameters in H.263 to be used with SIP Supported picture sizes and their corresponding minimum picture interval (MPI) information can be combined. All picture sizes can be advertised to other party, or only some subset of it. Terminal announces only those picture sizes (with their MPIs) which it is willing to receive. MPI is an integer value (1..32) and it means that maximum picture (frame) rate is 29.97/MPI value/s. MPI value may be bigger, meaning that picture rate is slower. For example, MPI=2 means that maximum (decodeable) picture rate per sec is about 15. Parameter occurring first is the preferred picture mode to be received, and last is the least preferred (but still supported) one. Following words are presented with no slash ("/") symbol between them, and are separated by space. Following words are present in SDP list only if a terminal is willing to decode the picture size. If terminal is not willing to receive some size, it is not present in the list. Word: SQCIF=MPI(1..32) Explanation: SQCIF picture size and its MPI value. Means that sender can decode SQCIF resolution with this MPI value. Word: QCIF=MPI(1..32) Explanation: QCIF picture size and its MPI value. Means that sender can decode QCIF resolution with this MPI value. Word: CIF=MPI(1..32) Explanation: CIF picture size and its MPI value. If present, means that sender can decode CIF resolution with this MPI value. Word: CIF4=MPI(1..32) Explanation: CIF4 picture size and its MPI value. If present, means that sender can decode this resolution with this MPI value. Word: CIF16=MPI(1..32) Explanation: CIF16 picture size and its MPI value. If present, means that sender can decode this resolution with this MPI value. Word: XMAX=maximum_x_size YMAX=maximum_y_size MPI=MPI(1..32) This list of words means that terminal is capable and willing to receive arbitrary picture sizes. These X and Y values are the maximum of allowed picture sizes with corresponding MPI value. All these three words must exist together in this order, or none is allowed to exist. Both picture sizes must be divisible by 4. Example of the usage of these words: CIF=4 QCIF=3 SQCIF=2 XMAX=360 YMAX=240 MPI=2 This means that sender hopes to receive CIF picture size, which it can decode at MPI=4. If that is not possible, then QCIF with MPI value 3, if that is neither possible, then SQCIF with MPI value =2. It is also allowed (but least preferred) to send arbitrary picture sizes (max 360x240) with MPI=2. Note that most encoders support at least QCIF and CIF fixed resolutions and they are expected to be available almost in every H.263-based video application. Following two parameters are used only with SIP. MaxBitRate=INTEGER(1..19200) Explanation: maximum video stream bitrate receivable by the sending terminals H.263 decoder, presented at 100 bits/s. BitsPerPictureMaxKb=INTEGER(0..65536) Explanation: Maximum amount of kilobits allowed to represent a single picture frame, value is specified by largest supported picture resolution, see [1]. If this parameter is not present, then default value, that is based on the maximum supported resolution, is used. All these parameters must be presented in SDP a=fmtp line exactly in this order if they are present. Example: (in SIP) a=fmtp 34 CIF=4 QCIF=2/MaxBitRate=1000/SAC/AP This means that the sender of this message can decode H.263 (RTP payload type 34) bitstream with following options and parameters: Preferred resolution is CIF (its MPI is 4), but if that is not possible then QCIF size is ok. Maximum receivable bitrate is 100 kbit/s (1000*100 bit/s) and SAC and AP options can be used. A.3 Use of SDP H.263 options and parameters with SAP SAP announcements are one-way only. H.263 options (like SAC) mean that sending terminal (host) is going to use these options in its transmitted H.263 stream. It is just an informal message. Usually only one picture size (with its MPI) exists. However, since it is possible for a video source (terminal) to change its picture size during session, several picture sizes can exist in the parameter list. First one is the original picture size to be used in the beginning of the session. Other H.263 parameters are not used with SAP (nor when announced in web-page). Example (with SAP): a=fmtp 34 CIF=2 URV/SAC The video source is sending an H.263 bitstream and picture size is CIF, MPI=2 and URV and SAC options are used. This kind of announcement can be used, e.g., in the MBone. Authors' Addresses Harri Honko, Petri Koskelainen, Jouni Salonen Nokia Research Center P.O.Box 100 FIN-33721 Tampere Finland e-mail: harri.honko@research.nokia.com, petri koskelainen@research.nokia.com, jouni.salonen@research.nokia.com References: [1] International Telecommunication Union. Video Coding for Low Bitrate Communication, ITU-T Recommendation H.263, 1996 [2] Handley et al, ``SDP - Session Description Protocol'', INTERNET-DRAFT, IETF 1997. [3] Handley et al, ``SIP - Session Initiation Protocol'', INTERNET-DRAFT, IETF 1997. [4] ``SAP - Session Announcement Protocol'', INTERNET-DRAFT, IETF 1997. From rem-conf Sun Sep 14 00:15:59 1997 From rem-conf-request@es.net Sun Sep 14 00:15:58 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xA8hF-0007Fv-00; Sun, 14 Sep 1997 00:02:17 -0700 Date: Sat, 13 Sep 1997 23:35:47 -0700 (PDT) From: e77s@e77sny.net To: Friends@onthe.net Subject: Welcome to the first intellectual game on the net !!! Reply-To: vadim@ndim.com X-PMFLAGS: 20720340.50 X-UIDL: 20720340_201230.501 Comments: Authenticated Sender is Message-Id: <94739435_95164289> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list **************** If you wish to be removed from our mailing list, please hit REPLY and type in the key word REMOVE in the subject field. This message has been sent to you by F.G.I.G.E. Please address any remarks to our attention. **************** Play a fun and innovative game that tests you according to your level of skill. CHALLENGE yourself, have FUN - WIN MONEY (up to $20,000) - PLAY The Winning Spin TODAY! http://www.fortune-wheel.com You have nothing to lose, and so much to gain! Try The Winning Spin ---and soon, you’ll be THANKING us! Your Friends at F.G.I.G.E. PS To receive a $12 gift certificate and have the opportunity to win $20,000 in cash- go to our sponsor site - http://effect-inc.com and click on "Bonus". If you would like to be removed, please let us know. From rem-conf Mon Sep 15 05:41:08 1997 From rem-conf-request@es.net Mon Sep 15 05:41:07 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xAZV4-0000N8-00; Mon, 15 Sep 1997 04:39:30 -0700 Date: Mon, 15 Sep 1997 13:39:00 +0200 (MET DST) Message-Id: <199709151139.NAA06521@chouette.inria.fr> From: Emmanuel Duros To: udlr@sophia.inria.fr CC: rem-conf@es.net, mbone@ISI.EDU, end2end-interest@ISI.EDU, merci@cs.ucl.ac.uk, dabbous@chouette.inria.fr, bolot@chouette.inria.fr, cdiot@chouette.inria.fr, flyonnet@chouette.inria.fr, sfosse@chouette.inria.fr Subject: SIGCOMM 97 - Mbone event Reply-to: Emmanuel.Duros@sophia.inria.fr X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The following SIGCOMM events will be retransmitted on-line on the Mbone: Sigcomm award talk by Jon Postel Tuesday September 16 from 9:00 am to 10:30 am GMT+2 Sigcomm award talk by Louis Pouzin Wednesday September 17 from 9:00 am to 10:30 am GMT+2 These two talks will be multicast from INRIA using a satellite link offered by EUTELSAT. UCL (London, England) and GMD (Darmstadt, Germany) are equipped with reception hardware and will forward the sessions to the rest of the MBone. Technical note : ---------------- The sending tool will be the integrated audio and video MBone tool Rendez-Vous (http://www.inria.fr/rodeo/rv). Rendez-Vous is vic and vat compatible. The sdr session entry is SIGCOMM '97. High quality audio will also be broadcast separately on its own channel (see SIGCOMM '97 HQ Audio) with the FreePhone audio MBone tool (http://www.inria.fr/rodeo/fphone). This HQ transmission will only be available to FreePhone users. Please use wb for transmission feedback. For Rendez-Vous users : as sd/sdr do not take into account integrated audio and video tools, Rendez-Vous users will have to launch it manually by typing the following command : ./ivstng.sh 224.6.224.2 31034 224.8.224.4 51488 255 Emmanuel From rem-conf Mon Sep 15 19:00:30 1997 From rem-conf-request@es.net Mon Sep 15 19:00:29 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xAmnG-0001Bf-00; Mon, 15 Sep 1997 18:51:10 -0700 Date: Mon, 15 Sep 97 18:51 PDT To: mbone@ISI.EDU,rem-conf@ES.NET From: Denis DeLaRoca Subject: SDR 2.4a6 calendar bug: syntax err in expression "09/3" Message-Id: X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list The calendar of sdr 2.4a6 is failing with the above syntax error -- most likely a bad session announcement. Any workaround for this? -- Denis From rem-conf Tue Sep 16 17:06:51 1997 From rem-conf-request@es.net Tue Sep 16 17:06:51 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xB7Tu-0007Ib-00; Tue, 16 Sep 1997 16:56:34 -0700 Date: Tue, 16 Sep 1997 16:51:15 -0700 () From: Stephen Casner To: Koskelainen Petri NRC/Tre cc: "'confctrl@isi.edu'" , "'rem-conf@es.net'" Subject: Re: SDP format for H.263 options In-Reply-To: <1997Sep12.112945.1751.1063168@nrchub01he.research.nokia.com> Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list On Fri, 12 Sep 1997, Koskelainen Petri NRC/Tre wrote: > Currently it is not possible to specify any codec specific options > in SIP/SDP architecture. For example, H.263 has many options and > parameters which are almost mandatory (it makes no sense to say > "lets use H.263" without knowledge of its capabilities). > > Best place to include these codec specific parameters in SDP is: > a=fmtp: I agree that this is the right place to convey additional H.263 parameters for a session. I presume that these parameter are instructions to the encoder; that is, except for performance or implementation constraints, the decoder can tell from the headers what functions are in use and can decode can decode the stream without knowing these option settings. > So, these format speficic parameters must be defined somewhere > and it seems (like Henning proposed) that the best place to do it, > is in corresponding RTP mapping draft as an annex. > Another solution is to make new internet-draft (for every codec). Not sure what you mean by "mapping draft". The only example use of a=fmtp I know of so far is in the Redundant Audio payload format, recently published as RFC 2198. > Below is a proposal for H.263 SDP format specific parameter mapping, > to be included into "RTP Payload Format for H.263 Video Streams" draft. Since the H.263 payload format spec has also been published now as RFC 2190, it would be necessary to produce a revised RFC to add the format mapping info. The way to start that process would be to write an Internet-Draft specifying the details of the format parameters. That could be published as a separate RFC, but more likely it would be better to publish a new combined RFC. Since the additional information would be specifying part of the standard, it would probably not be an annex or appendix but rather an additional section of the document. > m=video 55514 RTP/AVP 34 > a=fmtp 34 CIF=4 QCIF=2/MaxBitRate=1000/SAC/AP > > Syntax above means that H.263 codec with preferred picture size of CIF (with > min picture interval of 4) and secondary picture size is QCIF and arithmetic > coding and advance prediction are in use and max bitrate decoable by decoder > is 100 kbit/s. There are already SDP fields to specify maximum bandwidth, so I suspect that should not be included as a codec parameter. I don't know enough about the options in H.263 to say whether what you have proposed is appropriate/sufficient/etc. Those who know more about H.263 should chime in. One simple comment on the text structure is that I think it would be better to define the options independent of the protocol in which they would be used (SIP, SAP or something else) and then state the applicability to particular scenarios. The SIP spec should address the capability negotiation (or capability statement if negotiation does not really occur) in an encoding-independent manner. -- Steve From rem-conf Wed Sep 17 10:51:42 1997 From rem-conf-request@es.net Wed Sep 17 10:51:41 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xBO8E-0006GD-00; Wed, 17 Sep 1997 10:43:18 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Wed, 17 Sep 1997 10:42:58 -0700 (PDT) Message-Id: <199709171742.KAA29043@hille.msri.org> To: rem-conf@es.net From: Reply-to: davidwu@bmrc.berkeley.edu Subject: Disney's Aladdin: First Steps Towards Storytelling in Virtual Reality X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: Disney's Aladdin: First Steps Towards Storytelling in Virtual Reality Date: Sep 24, 1997 Time: 12:30 PST8PDT 2 hours Contact: davidwu@bmrc.berkeley.edu URL: http://bmrc.berkeley.edu/298/w5.html Description: Walt Disney Imagineering has developed a high-fidelity virtual reality (VR) attraction where guest fly a magic carpet through a virtual world based on the animated film "Aladdin." mbone broadcast schedule http://www.msri.org/mbone From rem-conf Thu Sep 18 14:39:24 1997 From rem-conf-request@es.net Thu Sep 18 14:39:24 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xBo8j-0005h9-00; Thu, 18 Sep 1997 14:29:33 -0700 X-Authentication-Warning: msri.org: smap set sender to using -f Date: Thu, 18 Sep 1997 14:28:59 -0700 (PDT) Message-Id: <199709182128.OAA00250@hille.msri.org> To: rem-conf@es.net From: Reply-to: blw@baylisa.org Subject: BayLISA: Sendmail and DNS X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list MBone Broadcast Announcement ---------------------------- Title: BayLISA: Sendmail and DNS Date: Sep 18, 1997 Time: 19:00 PST8PDT 2 hours Contact: blw@baylisa.org URL: http://www.baylisa.org Description: Hal Pomeranz speaks about setting up split DNS and SMAP/Sendmail on an Internet firewall. mbone broadcast schedule http://www.msri.org/mbone From rem-conf Fri Sep 19 18:58:25 1997 From rem-conf-request@es.net Fri Sep 19 18:58:25 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xCEe3-0000nu-00; Fri, 19 Sep 1997 18:47:39 -0700 Message-Id: <3.0.3.32.19970919184733.0125bbd8@mail.prognet.com> X-Sender: robla@mail.prognet.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 19 Sep 1997 18:47:33 -0700 To: rem-conf@es.net, confctrl@isi.edu From: Rob Lanphier Subject: ASF Specification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi folks, I just wanted to solicit comments on the "Active Streaming Format (ASF)" specification that Microsoft announced with the support of Progressive Networks, Intel, Adobe, and Vivo, and a whole buncha other companies who are interested in putting the file format compatibility problem to bed. I'm sure most folks here are more interested in wire protocols, but having a common file format that all tools can use to record to and servers can use to playback from is a very handy thing, so I'd really encourage you to look at it. The folks at MS have put together a very good web site over at: http://www.microsoft.com/asf The spec, open issues, and instructions for joining the mailing list are all on the MS web site (e-mail to Listserv@listserv.msn.com, no subject, body: "subscribe ASF your name" (no quotes)) This is *really* on the fast track (period for public comment ends September 30). After this, tool and server vendors will plow ahead with the current version, and the spec will be submitted to a standards body for future versions (destination TBD). Now's really the time to get your two cents in on this. There's a lot of really knowledgeable people on this list who could usefully contribute to this spec, and we'd love to hear what y'all have to say. Thanks Rob --- Rob Lanphier Voice: (206)674-2322 Fax: (206)674-2699 Program Manager-Protocols Email: robla@prognet.com Progressive Networks-Home of RealAudio Web: http://www.real.com For more information on firewalls: http://www.real.com/help/firewall For more information on RTSP: http://www.real.com/rtsp From rem-conf Sat Sep 20 06:01:00 1997 From rem-conf-request@es.net Sat Sep 20 06:00:59 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xCP2G-0003GR-00; Sat, 20 Sep 1997 05:53:20 -0700 Sender: hgs@cs.columbia.edu Message-ID: <3423C738.A026FCC8@cs.columbia.edu> Date: Sat, 20 Sep 1997 08:53:12 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ASF@listserv.msn.com, rem-conf@es.net Subject: ASF for RTP-based servers and other comments Content-Type: multipart/mixed; boundary="------------006277611CED184687564E48" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------006277611CED184687564E48 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Attached are some of my quick observations on the current ASF draft. -- Henning Schulzrinne email: schulzrinne@cs.columbia.edu Dept. of Computer Science phone: +1 212 939-7042 (@Bell Labs: 908 949 8344) Columbia University fax: +1 212 666-0140 New York, NY 10027 URL: http://www.cs.columbia.edu/~hgs --------------006277611CED184687564E48 Content-Type: text/plain; charset=us-ascii; name="asf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="asf.txt" Comments on ASF Spec (version of Sept. 8, 1997) These remarks are addressing the basic need of ASF to be efficient and suitable for streaming data using the Internet standard or to-be-standardized protocols for these purposes (RTP and RTSP, respectively). (x.y) refers to section x.y (1.2) ASF is not clear: it says it is a file format, but then says "it supports data delivery over a wide variety of networks". The latter implies (or may be read to imply) that ASF would be transported in real-time (streamed) across networks. This seems unlikely and inappropriate. Adding a disclaimer would avoid confusion, e.g., with the role of RTP payload type definitions. (1.3) Design Goals should list "operating system independence". Or am I right in suspecting that this was not a goal :-)? (1.3) Simplicity is also notably absent. The spec should at least outline what objects a minimal implementation should understand. (See SIP and RTSP specs for examples on this...) (3.1) The GUID is not described in a level of detail that makes this document self-contained. The GUID does not solve any real problems: There is no way (at least not described within the document) that I can find out who "owns" a particular GUID and who I might ask what this object type is that I just found in an ASF file. If there is a registry, I don't need 16-byte GUIDs. Internet MIME types, for example, allow me to do this by consulting the IANA web site. Collisions are not a real problem for file format objects, finding descriptions is. The spec cannot be implemented as is, since the values of the GUIDs are not provided. (3.1) Non-network byte order: I suppose this explains the omission in (1.3) :-) This is very inconvenient; all systems offering socket or Winsock services have htonl() and ntohl() to allow to write byte-order independent code, with one of these functions being a null op. There are no standard routines for the reverse-byte order suggested here. (4.1) Major problem: ASF assumes that a single stream has a single clock and media type. When streaming or recording RTP data, this is not true. The media type (RTP payload type) within a single stream may change frequently, with each payload type having its own "natural" sampling and clock frequency. The number and type of these payload types within a stream is not known ahead of time if I record data from a live session (e.g., a conference). Thus, for this reason and the reasons listed below, ASF as it currently stands is useless for efficient and general RTP recording and playback. The format assumes, by having a fixed number of stream property objects, that the number of streams is known ahead of time. For recording conferences, for example, this is not the case. To record a conference, I would have to rewrite the whole data file after the conference has concluded - very inefficient. This also makes it impossible to allow simultaneous recording and playback, useful for sessions with "late joiners". (5) The separation of material in Sections 5 and 6 is only confusing. The only information not contained in Section 5 is the data type and field length (the former should imply the latter in any event). Thus, I suggest moving the second column of the tables in Section 6 into Section 5. The first column in the tables in Section 5 is useless and should be removed to avoid confusion. Having two sections simply means that I need to flip back and forth; plus, there is the danger of misalignment between the two. The data types UINT, UINT8, FILETIME and others are not defined. UINT refers to datatypes ranging from 16 to 32 bits - why not have UINT16 and UINT32? No values are given for 'invalid' fields. According to Internet protocol custom, should be zero for writing and ignored on reading. (5.2): The time field contains no indication of the time zone to be used. (5.3): The explanation of 'preroll' is confusing. What's a delay *factor*? (A factor is a multiplier - what is being multiplied?) What does it mean to 'start' a stream? Extension System and Extension Data Size is not explained. Recordable: recording by whom? Is caching ok - in the network, at the end system? (5.4) Mainy of the MARC fields are inappropriate for multimedia content or not defined. What for, example, should 'physical description' stand for - the size and color of the bits? This makes sense for books, not for ASF. I have no idea what 'System Details' or 'Leader' should be in this context. Instead (or at least in addition), the Dublin core elements should be used, as these are generic: http://purl.org/metadata/dublin_core_elements ftp://ds.internic.net/internet-drafts/draft-kunze-dc-01.txt (6.2) The File Properties Object should contain the standard IETF IntServ Tspec parameters. From the parameters given, I cannot compute this and thus not make an RSVP reservation. (7.1) The ASF Packet Definition has, I believe, too many variants (two packet length, three presentation time, offset, and size each, for a total of 54 combinations), making it very difficult to overlay a structure onto the data read from disk. The space savings are marginal. A common format (16 bit long size, with pres. time, no fragment) should be defined. All variants should be listed and should have fixed-length headers for ease and speed of implementation. The 'clean point' should be mapped into RTP marker bits (possibly in an 'Use of RTP with ASF appendix'), if they are indeed equivalent. Major problem: As is, the Packet Definition cannot be used for RTP packets, since it does not contain a Payload type field. CSRC and SSRC values cannot be stored. Since the size of these fields is not known, the Stream Properties Object Extension Data size is not known. Since only a single extension is specified, this would be "used up" for RTP immediately, with no ability to add per-media extensions. (9) This should refer and use the existing RTP payload definitions, as these define channel orderings, byte order, etc. The data given in the spec is not sufficient for interoperability. Trivial example: PCM can mean mu-law or A-law and the channel ordering for multiple channels needs to be specified. The RTP Profile (RFC 1890) does this at great detail. Other remarks: - No provision to store RTCP SDES information for conferences and streaming media. (See RFC 1889) General nits: - e.g. should always be followed by a comma. - When referring to data types, the section # should be given for easy reference. - 9.1 -> typo: UNIT -> UINT - It is, I believe, generally useful to add motivation to spec decisions. (This seems to be, at least, the consensus within the Internet RFC community. See "Guide to Standards Writers".) --------------006277611CED184687564E48-- From rem-conf Mon Sep 22 02:50:00 1997 From rem-conf-request@es.net Mon Sep 22 02:49:59 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xD4uA-0004Rh-00; Mon, 22 Sep 1997 02:35:46 -0700 Message-ID: <34263A3F.5620B116@KEGO.COM> Date: Mon, 22 Sep 1997 02:28:31 -0700 From: Cameron Elliott Organization: KEGO - Software & Datacommunications X-Mailer: Mozilla 4.03 [en] (WinNT; I) MIME-Version: 1.0 To: rem-conf@es.net Subject: Vic work continuing? Content-Type: multipart/mixed; boundary="------------3AE62E6F399114FB77A5E4E3" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This is a multi-part message in MIME format. --------------3AE62E6F399114FB77A5E4E3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I'm wondering if anyone is continuing work on VIC? I sent a message to the developers, but didn't receive a reply. Thanks, Cameron Elliott -- Cameron Elliott Kego - Software & Datacommuncations Unix, Embedded Software, TCP/IP, H.323 888-FOR-KEGO Cam@Kego.com --------------3AE62E6F399114FB77A5E4E3 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Cameron Elliott Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Cameron Elliott n: Elliott;Cameron email;internet: cam@kego.com x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------3AE62E6F399114FB77A5E4E3-- From rem-conf Mon Sep 22 09:12:59 1997 From rem-conf-request@es.net Mon Sep 22 09:12:59 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xDAwV-0006iy-00; Mon, 22 Sep 1997 09:02:35 -0700 Message-Id: <199709221602.SAA02901@ganymede.cdt.luth.se> X-Mailer: exmh version 1.6.7 5/3/96 To: Cameron Elliott cc: rem-conf@es.net Subject: Re: Vic work continuing? In-reply-to: Your message of "Mon, 22 Sep 1997 02:28:31 PDT." <34263A3F.5620B116@KEGO.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Mon, 22 Sep 1997 18:02:48 +0200 From: Hakan Lennestal Content-Transfer-Encoding: quoted-printable X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <34263A3F.5620B116@KEGO.COM>, Cameron Elliott writes: > This is a multi-part message in MIME format. > --------------3AE62E6F399114FB77A5E4E3 > Content-Type: text/plain; charset=3Dus-ascii > Content-Transfer-Encoding: 7bit >=20 > Hello, >=20 > I'm wondering if anyone is continuing work on VIC? >=20 > I sent a message to the developers, but didn't receive > a reply. >=20 > Thanks, > Cameron Elliott Well, I guess that we are quite a few people eagerly awaiting the 2.8.1 (memory leak-free ?) release. Last rumor I heard said "September". /H=E5kan From rem-conf Tue Sep 23 00:00:25 1997 From rem-conf-request@es.net Tue Sep 23 00:00:24 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xDOr2-00015P-00; Mon, 22 Sep 1997 23:53:52 -0700 Date: Mon, 22 Sep 1997 23:52:46 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Minutes of Munich AVT meeting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Enclosed are the minutes I have prepared for the AVT meeting held last month at IETF in Munich. Comments are welcome. -- Steve Minutes of the Audio/Video Transport Working Group Reported by Steve Casner 1. Introduction and status The AVT working group had not planned to meet in Munich during a period of dormancy while implementation and testing of RTCP scaling mechanisms was underway. However, in response to several requests, one AVT session was scheduled to discuss a new problem with the RTCP scaling plus open issues for several new payload formats that were submitted since the last meeting. The next goal for AVT is to get RFCs 1889 and 1890, the Real-time Transport Protocol and the companion RTP profile for audio/video conferencing, revised for advancement to Draft Standard by year's end. The profile has been revised in draft-ietf-avt-new-profile-01.txt and .ps. The main RTP specification needs to incorporate RTCP scaling changes that are still being refined; however, an interim first draft of the other revisions, including extensions for layered encodings, should be published as soon as posible. As of the Munich meeting, the RTP payload format for H.263 video had been approved for publication as a Proposed Standard, and the payload format for redundant audio was close to approval. (Since the meeting, both have been published as RFCs 2190 and 2198.) The drafts on compression of IP/UDP/RTP headers and a revision to the RTP payload format for MPEG2 in RFC 2038 have been posted for IESG Last Call before publication as Proposed Standards. 2. RTCP "timer reconsideration" Jonathan Rosenberg gave a brief review of the problem that a flood of RTCP packets can occur if a large number of participants simultaneously join a session. This problem and the solution of RTCP "timer reconsideration" have been discussed at the previous two IETF meetings and are explained in the recently posted Internet-Draft draft-ietf-avt-reconsider-00.ps. However, a concern raised at the last meeting was that the timer reconsideration algorithm exhibits a "plateau effect" wherein no RTCP packets are sent for a period after the algorithm stops the flood. New simulations show that the plateau effect is significantly reduced as the joins are spread out in time and disappears when the join rate is no more than 500 users/sec. Since perfectly synchronized joins are very unlikely, the plateau effect is not considered to be a problem. There is an analogous problem of an RTCP BYE packet flood on simultaneous leaves. Unlike the initial RTCP packets at the time of joining, BYE packets can't be delayed because the application is terminating. Some partial remedies were discussed at the last meeting. The newly discovered problem is a relatively minor one related to the BYE flood: if many participants leave a session at once, other participants that remain in the session may be falsely timed out. Some of the remaining participants will have their RTCP interval expire earlier than others. These participants will reduce their estimate of the number of participant and consequently also reduce their RTCP interval. Since the remaining participants may still have a long time to wait before their previously calculated RTCP interval expires, they might not send any RTCP packets while multiple shorter RTCP intervals elapse for the particpants that have noticed the drop. The long-waiting participants will therefore be timed out (considered inactive) by those that have adjusted to shorter intervals. Even if the BYE flood is slowed to the normal 5% RTCP bandwidth, simulations show that a single missed packet can cause a timeout. An extension to the timer reconsideration algorithm, dubbed "reverse reconsideration", avoids this timeout. Whenever the group size estimate decreases (due to a BYE), the RTCP timer is recomputed. There is still a problem that the group size estimate drops to zero. This problem can be eliminated, as suggested by Sharma and Jacobson in an INFOCOM97 paper on a similar problem, using a filter to slow the rate of decrease of the estimate. Further analysis to determine the right kind of filter is underway. Jon Crowcroft suggested keeping a bit of history from interval to interval and continuously estimating the group size to use as a predictor. However, a predictor might not work well with unexpected sharp transitions in group size. He also suggested that the BYE flood might be managed by having participants send BYEs with a limited scope and then having the participants that remain act as proxies to retransmit the BYEs spread out in time. A proxy election protocol would be needed. This starts to get pretty complicated. Dave Oran suggested that there could be a server thread that takes responsibility for sending a delayed BYE after the application is closed, just as TCP implementations must save some state when a connection closes to shut down gracefully. Steve Casner responded that if some implementations can do this, great, but we can't assume all will. Similarly, it is important to note that although we want to define a timer reconsideration algorithm to go in the appendix of the RTP spec, different implementations can implement different timer reconsideration algorithms and the whole system will still work. The group was asked if there were any objections to the proposal to add the timer reconsideration algorithm to the RTP spec. There were none. 2.1 Large-scale tests of the RTCP scaling mechanisms The timer reconsideration algorithm has been simulated, but we would have more confidence if it was tested on a large scale with real implementations. If that is not practical, testing on a large-scale simulation/emulation testbed network would be a good backup for the initial simulations. The audience was queried about any planned tests, but no plans were reported at this time. Jonthan Rosenberg is implementing a test program called rtpbomb that can emulate a large number of participants. It may be used in combination real participants to test timer reconsideration and other aspects of RTCP scaling. His analysis suggests that most of the phenomena in the algorithm are linear with group size, so a smaller test should still be useful to predict behavior of a larger group. 3. Other RTP Issues/Questions Steve Casner brought up three other issues for the group to consider, but there were few comments: - During the discussion of the global multicast address allocation scheme in MBONED working group, Van Jacobson asserted that applications should not depend upon sequential multicast addresses being allocated for multiple groups carrying the different layers of a layered coding scheme. The layered encoding extension to RTP proposed by Speer and McCanne does assume sequential addresses, so a revision may be necessary. - AVT has received a Request for Proposals from the DAVIC group. It would be difficult for the group as a whole to respond, but individual participants are invited to do so. - Should AVT set a policy of allocating no more static payload types such that dynamic payload types should be used instead? Scott Petrack responded to the last point to say that we should consider none of the assigned payload types to be static, but rather default assignments. When a session control protocol is in use, if there is a need for more than the 32 dynamic payload types already set aside, the default values could be reassigned. The group seemed to be in general agreement with this proposal, but it should be discussed on the mailing list as well. 4. New RTP payload format proposals It is expected that additional payload formats for RTP will continue to be developed as new encodings are developed and as RTP is employed in new applications. At this meeting, new payload formats were introduced for H.263+, MPEG4, BT-656 and QuickTime video, and DTMF tone signalling in audio. In addition, "meta" payload formats that specify methods for repair of packet losses were discussed, including the question of how much error correction is appropriate. 4.1 H.263+ video payload format As noted in the introduction, the payload format specification for H.263 video has been published as a Proposed Standard. However, enhancement of the encoding itself continues under the label H.263+ for improved loss resilience and to utilize increased processing power to achieve higher quality. As agreed in previous AVT meetings, a separate RTP payload format is to be devised to support the enhanced encoding. In fact, two different approaches were proposed in draft payload format specifications sent to the AVT mailing list just before the meeting. Stephen Wenger, who is the primary author of one and a co-author on the other, gave an overview of the H.263+ encoding enhancements and the tradeoffs between the two payload formats. The first approach, from TU-Berlin and U-Bremen, uses a very simple payload header but includes the H.263+ picture header in each packet. This allows for the use of almost all of the optional modes defined in the H.263+ encoding scheme. The second approach, from Intel, follows more the design of the existing H.263 payload format in which selected fields from the picture header are incorporated into a set of payload format headers for different modes. This approach reduces overhead to support small packet sizes but precludes use of some encoding options deemed to be rarely used. Wenger stated the intention of the authors of both approaches to resolve the differences and produce one merged proposal. He suggested that the merged proposal might include both approaches. Steve Casner countered that this might not be a good result because it increases complexity and reduces interoperability -- putting in all the options when a decision can't be made is often the result of a committee design. Christian Huitema commented that some encoding functions were left out when the H.261 payload format was designed because they were not applicable to packet transport, and asked if a similar analysis could be made here. Wenger replied that in H.263+ the enhancements were expressly designed to work with packet loss. Wenger requested input soon from the working group regarding the tradeoffs between the two approaches because the recommendations for mode combinations to use are being prepared now by the ad-hoc group he leads. The two specifications should be posted as Internet-Drafts for wider exposure. 4.2 MPEG4 payload format There is no draft payload format specification for MPEG4 yet because Gerard Fernando would like feedback on some design questions first. He gave a brief overview of the scope and structure of MPEG4, which is a framework for integrating different kinds of natural and synthetic media streams built around audio/visual objects called AVIOs. There are two primary questions: - How can MPEG4 payload format refer to existing and forthcoming payload formats for the encodings of individual media streams (AVIOs) rather than trying to redo them all? - How should the "scene description data", which composes the individual AVIOs into the complete presentation, be transmitted? If this data is lost, the whole scene is lost, so adequate loss resilience mechanisms must be employed. Can the scene description data be decomposed over both time and "space" -- time because a transmission may be joined after the start, and space because media are sent in separate streams and some receivers might not tune into all of them? MPEG4 is still being developed, with standardization due in January 1999. The MPEG4 committee would like to work with AVT to ensure that packetization considerations are included in the design; they view RTP/UDP multiplexing as an appropriate means of multiplexing elementary streams. This is clearly beneficial from AVT's point of view as well. One aspect of the use of separate media streams in RTP is the ability to apply different network QoS and reliability mechanisms as needed; the VMIF part of MPEG4 is trying to formalize the selection of stream-specific QoS in a transport-independent and network-independent way. Fernando and Casner are to explore what formal or informal liaison procedures should be followed in this case, both for information transfer and to enable reference to RTP in the MPEG4 specification. 4.3 BT-656 video payload format Dermot Tynan presented a proposal, draft-tynan-rtp-bt656-00.txt, for carrying ITU-R BT.656-3 uncompressed video over RTP. BT656 is studio-quality digital video sampled according to BT.601-5 (formerly CCIR601) at 13.5 or 18 MHz. At the normal, lower rate, each scan line contains 720 samples occupying 1440 bytes in the 4:2:2 chrominance encoding. At the "high definition" rate, each line contains 1144 samples for NTSC or 1152 samples for PAL. The payload format consists of a simple header with bit fields to indicate NTSC/PAL, sampling rate, framing and scan line information, followed by one scan line of samples. Steve Casner expressed the concern that the packet size might exceed the MTU for some networks. Although at the lower sampling rate an IP/UDP/RTP packet will fit within a 1500-byte MTU, at the higher sampling it would not. Don Hoffman pointed out that if the packet size does exceed the MTU such that IP fragmentation occurs, integrated services packet classification won't work on fragments other than the first so those packets won't get the desired QoS. Christian Huitema claimed it is important to have application-level fragmentation so that services such as forward error correction will apply when a fragment is lost. It should not cost much to be able to indicate that a packet contained part of a scan line, perhaps by giving the starting sample number. Tynan agreed to consider this addition. 4.4 QuickTime payload format Alagu Periyannan just asked to call the working group's attention to the recently posted draft "RTP Payload Format for QuickTime Media Streams", draft-ietf-avt-qt-rtp-00.txt, and in particular to the list of open issues in section 4 of that draft. The motivation in developing this format was to carry all the payloads in QuickTime without having to define an RTP payload format for each. Steve Casner pointed out that the tradeoff of this technique is that there is some amount of additional constant description info that must be carried in each packet but would not be needed with separate formats. Philipp Hoschka asked if it wouldn't be better to define individual payload formats because the encodings might also be used outside of QuickTime as well. Periyannan replied that where individual payload formats are defined, they should be used in preference to this format. However, several of the encodings used with QuickTime are not standardized, such as Apple Video, Cinepak, and several proprietary codecs. 4.5 DTMF audio payload format Jonathan Rosenberg presented Henning Schulzrinne's proposed audio payload format to carry DTMF (tone dialing) signals as defined in draft-ietf-avt-dtmf-00.txt and .ps. This payload format might be used for calling across the Internet through IP telephony gateways to control an answering machine or other device. Low data rate speech codecs may not reproduce the DTMF tones faithfully enough to work properly at the far end. This payload format essentially provides a very low rate encoding specialized for DTMF tones. The draft defines a primary format in which each DTMF digit is represented by 32 bits to control frequency, amplitude and duration. Redundancy can be provided using the mechanism specified in RFC 2198. This introduces 64 bits of overhead, but the data rate is so low that this probably does not matter. Alternatively, a more compact representation of each digit would allow adding redundancy within the DTMF payload format and still fitting each digit into 32 bits. The selection between these techniques is an open issue on which input >from the working group is sought. Steve Casner noted that the more compact format would require the RTP clock rate to be different than that of the normal audio payload format within which the DTMF packets are interspersed, and suggested that this is a significant enough disadvantage to prefer the larger format. Scott Petrack agreed that the size difference was probably not significant. 4.6 Forward Error Correction payload format Two "meta" payload formats on forward error correction (that is, independent of media type and format) have recently been posted: draft-budge-media-error-correction-00.txt by Budge, et al., and draft-ietf-avt-fec-00.txt by Rosenberg and Schulzrinne. The authors of the first draft did not attend, but Jonathan Rosenberg presented the second draft which builds on ideas from the first, and compared the two drafts. Both schemes are based on the idea of sending additional FEC packets which are the XOR of multiple packets from the original packet stream. It should be noted that the scheme presented by Rosenberg differs from that described in the second draft. An RTP header extension (X bit) is no longer used; instead, the payload type is changed to indicate an FEC packet, and an additional format-specific header is inserted before the XOR of the covered payloads, as in the Budge scheme. One drawback of the Budge draft was that the timestamp and marker bit of lost packets could not always be recovered. The proposed remedy is for these fields in the FEC packets to be the XOR of the corresponding fields from the original packets covered by the FEC packet. This has its own drawback that the timestamp will vary erratically, perturbing the jitter feedback calculation. Carsten Bormann also pointed out that when RTP header fields are perturbed from their usual increments, it can have a negative impact on the efficiency of RTP header compression. A second drawback of the Budge scheme was that the payload type was changed in the original packets to be the FEC payload type which means that a receivers without FEC capability could not receive just the original packets and ignore the FEC packets. In Rosenberg's scheme, the original packets are unmodified, including the payload type. To extend the range of packet patterns that could be covered by an FEC without having to predefine specific scemes, Rosenberg proposes to carry a bit mask to indicate the pattern explicitly. The RTP sequence number of FEC packets in Rosenberg's proposal is the minimum of the sequence numbers of the packets covered by the FEC to serve as a base for the mask. Steve Casner claimed that this is not acceptable because it will prevent the FEC packets from passing header validation and duplicate suppression algorithms in RTP packet processing. Rosenberg said alternative sequence number schemes had been considered, but the cost is additional overhead. Christian Huitema argued that if a general FEC payload format is to be defined, it should support other schemes with better performance and only a marginal increase in complexity compared to that of "n+1" schemes like XOR. For example, it is possible to specify a scheme that adds two FEC packets to eight original packets which will allow recovery from a loss of any two of the ten packets. This is important because simulations have shown that one packet of redundancy was not enough. Rosenberg agreed that the FEC proposals need further refinement. 4.7 Applicability of error correction In addition to the redundant audio and FEC payload formats already mentioned, retransmission and interleaving are two more loss resilience schemes that might be employed with RTP. Colin Perkins reviewed these four methods to compare the tradeoffs in latency, bandwidth overhead and processing overhead (details are available at http://www.cs.ucl.ac.uk/staff/c.perkins/slides/). It is an important question to consider when these schemes are applicable to particular applications or to particular network conditions. Colin presented some network loss statistics showing that single packet losses predominated by a factor of four over two-packet loss bursts. The probability drops rapidly such that long burst losses are rare. On the other hand, in a large conference, most packets will be lost by at least one receiver, therefore a retransmission scheme may need to resend almost every packet. The redundant transmission scheme has low latency and low bandwidth overhead, but potentially high processor overhead if the low-rate redundant encoding is computationally complex. A retransmission scheme is likely to impose much longer delay and will incur the overhead of control traffic in addition to the duplicate data, but provides exact repair and can correct more than single-packet losses. There is a synergy between redundancy and retransmission in that redundancy can cover most of the errors, leaving retransmission to pick up the remainder for those receivers that care more about low loss than low delay. Interleaving disperses the effects of loss, but does not eliminate them. It has low overhead, but high latency. FEC may have a similarly high latency or a high bandwidth overhead, depending on the size of the pattern covered, but its major advantage is media and format independence. For interactive applications, either redundant transmission or a low-latency FEC would seem most suitable, while for broadcast-style applications interleaving works well. An important open question is what constitutes a sensible operating point for real-time media transmission? How much loss should applications try to cope with before declaring that the user should try again at some less congested time? There is little congestion control in many real-time media applications, and extreme loss resilience measures would just worsen congestion. That would not be network friendly. If fair congestion avoidance mechanisms are deployed in routers, then applications that don't implement congestion control may be penalized. Therefore, any loss resilience schemes that are defined for RTP should consider not just loss performance but also impact on the network. 5. Revision of RTP MIB specification The final topic of the meeting was an update by Mark Baugher on the RTP MIB design and implementation plans. An interim draft of the MIB was sent to the mailing list before the meeting to provide an opportunity for feedback; a real Internet-Draft will be posted in October. A more complete description of the MIB was given in Memphis; the changes since then were to fix errors identified by Fred Baker in his review of the MIB, to add reporting of receiver feedback, to support RTP operation over different underlying protocols, and to remove from the specification those parts that won't be included in initial implementions and hence won't be validated yet. In particular, support for RTP translators was removed. Receiver feedback is reported through additional tables that are created only upon request from the network manager as a side-effect of creating an entry in the Session Table. This avoids the state explosion that might occur if all receiver feedback was always monitored for all sessions. There are a few details remaining to be worked out, but implementation of a network management application using the RTP MIB is underway to evaluate how well this MIB works for managing real-time applications on networks that weren't designed for them. To make this really workable, the management application needs to handle multicast routing in addition to RTP. The next stage of MIB development will be based on the results of the implementation. 6. Next meeting Steve Casner closed the meeting saying that AVT will meet again at the next IETF in December. As stated above, a goal for the working group is to get the RTP spec revised for Draft Standard by then. In addition, there is outstanding work on several topics presented at this meeting which should be discussed on the mailing list so that completed drafts are ready by the next meeting. From rem-conf Tue Sep 23 06:05:40 1997 From rem-conf-request@es.net Tue Sep 23 06:05:39 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xDULy-000386-00; Tue, 23 Sep 1997 05:46:10 -0700 Message-ID: <3427B9BC.7EB00284@dnrc.bell-labs.com> Date: Tue, 23 Sep 1997 08:44:44 -0400 From: "Jonathan D. Rosenberg" Reply-To: jdrosen@dnrc.bell-labs.com X-Mailer: Mozilla 4.0 [en] (Win95; U) MIME-Version: 1.0 To: Stephen Casner CC: rem-conf@es.net Subject: Re: Minutes of Munich AVT meeting X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Stephen Casner wrote: > > An extension to the timer reconsideration algorithm, dubbed "reverse > reconsideration", avoids this timeout. Whenever the group size > estimate decreases (due to a BYE), the RTCP timer is recomputed. > There is still a problem that the group size estimate drops to zero. > This problem can be eliminated, as suggested by Sharma and Jacobson in > an INFOCOM97 paper on a similar problem, using a filter to slow the > rate of decrease of the estimate. Further analysis to determine the > right kind of filter is underway. > A minor clarification here. With reverse reconsideration, you can still get premature timeouts (that is why the group size drops to zero, even when members remain). The effect of reverse reconsideration is to make the group size estimate return to the correct value more rapidly. Without it, the amount of time for which the estimate is wrong can be as large as the RTCP interval before the sudden drop in membership. With reverse reconsideration, the amount of time can only be as large (in the worst case) as the RTCP interval after the drop in membership. > 4.6 Forward Error Correction payload format > One drawback of the Budge draft was that the timestamp and marker bit > of lost packets could not always be recovered. The proposed remedy is > for these fields in the FEC packets to be the XOR of the corresponding > fields from the original packets covered by the FEC packet. This has > its own drawback that the timestamp will vary erratically, perturbing > the jitter feedback calculation. This is only true if you include the FEC packet in the jitter computation. Thanks, Jonathan R. -- Jonathan D. Rosenberg Lucent Technologies Member of Technical Staff 101 Crawfords Corner Rd. High Speed Networks Research Holmdel, NJ 07733 PHONE: (908) 949-6418 Rm. 4B-505 FAX: (908) 834-5379 EMAIL: jdrosen@bell-labs.com URL: http://www.cs.columbia.edu/~jdrosen From rem-conf Tue Sep 23 12:57:31 1997 From rem-conf-request@es.net Tue Sep 23 12:57:31 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xDavf-0005wQ-00; Tue, 23 Sep 1997 12:47:27 -0700 Date: Tue, 23 Sep 1997 12:46:09 -0700 () From: Stephen Casner To: rem-conf@es.net Subject: Re: Minutes of Munich AVT meeting In-Reply-To: Message-ID: X-X-Sender: casner@big-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Oops. I owe an apology to Stephan Wenger for misspelling his name in the AVT meeting minutes I sent last evening. I should be more sensitive to the spelling of that particular name! I'll make edits for the comments I have received and send that to the IETF minutes editor. -- Steve From rem-conf Tue Sep 23 20:17:58 1997 From rem-conf-request@es.net Tue Sep 23 20:17:58 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xDhoX-0004IQ-00; Tue, 23 Sep 1997 20:08:33 -0700 Date: Tue, 23 Sep 1997 22:02:26 -0500 (CDT) From: BEZALEL GAVISH Subject: CFP - 6th International Conference on Telecommunication Systems To: LIST3: ; Message-id: <01INZX6KCZ3I9BXKTT@ctrvax.Vanderbilt.Edu> X-VMS-To: IN%LIST3 X-VMS-Cc: GAVISHB MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list ---------------------------------------------------------------------------- Call for Papers 6th International Conference on Telecommunication Systems Modeling and Analysis March 5-8, 1998 Nashville, TN The 6th International Conference on Telecommunication Systems - Modeling and Analysis will be held in Nashville on March 5-8, 1998. 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, and to encourage informal interaction and exchanges of ideas. The objective is to advance the state of the modeling 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. Social and cultural activities will be included in the 1998 agenda. The deadline for submission of papers and extended abstracts is October 1, 1997. Additional information about the conference can be obtained from the conference web page at URL http://munin.utdallas.edu/telsys/cfp6.htm Listed below are some of the potential conference segments: - Configuration and Management of ATM networks - Internet and its Impact on Commerce and Organizational Structures - Internet and Intranet - Mobility and Nomadicity - Topological Design and Network Configuration Problems - Design and Analysis of Local Access Networks and Outside Plant Problems - Low and Medium Earth Orbit Satellite Communication Systems - Cellular Systems and PCS Modeling 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 - ADSL and its Impact - ATM, ISDN, BISDN Modeling and Analysis Issues - Telecommunication Standards - Artificial Intelligence/Heuristics in Telecommunication Systems - Group Decision Support Systems - Quantitative Methods in Network Management - Pricing and Economic Analysis of Telecommunications - Handling Investments in High Risk Technologies - 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 I look forward to a very successful conference. Sincerely yours, Bezalel Gavish ------------------------------------------------------------------------------- Bezalel Gavish Owen Graduate School of Management Vanderbilt University Tel : (615) 322-3659 Nashville, TN, 37203 FAX : (615) 343-7177 Internet: GAVISHB@CTRVAX.VANDERBILT.EDU Home: (615) 370-0813 ------------------------------------------------------------------------------- From rem-conf Wed Sep 24 08:04:07 1997 From rem-conf-request@es.net Wed Sep 24 08:04:06 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xDrpg-0007h7-00; Wed, 24 Sep 1997 06:50:24 -0700 Message-Id: <199709241350.JAA15486@east.isi.edu> To: rem-conf@es.net Subject: MBONE Event: Deering on IPv6, 9-11 AM EDT, Sep 25 Reply-To: mankin@EAST.ISI.EDU Date: Wed, 24 Sep 1997 09:50:33 EDT From: Allison Mankin X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list A seminar on IPv6 by Steve Deering will be presented on the MBONE 9-11 AM EDT, tomorrow, Thursday Sep 25. See the session advertisement for more information. From rem-conf Wed Sep 24 09:37:42 1997 From rem-conf-request@es.net Wed Sep 24 09:37:41 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xDuEK-0001Z3-00; Wed, 24 Sep 1997 09:24:00 -0700 Date: Wed, 24 Sep 1997 18:22:43 +0200 From: likavec@igd.fhg.de (Jaromir Likavec) Message-Id: <199709241622.SAA11360@owl.igd.fhg.de> To: rem-conf@es.net Subject: vic2.8/Parallax_Xtra_Problem Cc: likavec@igd.fhg.de X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I've changed SUN Video Card with Parallax XVideo Xtra overlay card on the SUN Ultra 1 with creator 3D under Solaris 2.6. Parallax tools VideoTool, MovieTool are working without any problem Vic 2.8 brings the message vic:can't open parallax capture device. Any idea what to do? Regards Jaromir ******************************************************************************** Jaromir Likavec Computer Graphics Center | A journey of a thousand (likavec@igd.fhg.de) Rundeturmstr. 6 | miles begins with a D-64283 Darmstadt, Germany | single step. Phone: +49/6151/155-314 | Lao-Tsu Dao De Sing Fax: +49/6151/155-399 | ******************************************************************************** From rem-conf Wed Sep 24 09:48:53 1997 From rem-conf-request@es.net Wed Sep 24 09:48:53 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xDua4-0002CS-00; Wed, 24 Sep 1997 09:46:28 -0700 Date: Wed, 24 Sep 1997 09:46:27 -0700 Message-Id: <199709241646.AA18484@zephyr.isi.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@ISI.EDU To: rem-conf@es.net Subject: Murray Campbell, IBM, Deep Blue: The IBM Chess Machine Reply-To: estrin@usc.edu X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list As part of the USC COMPUTER SCIENCE AND COMPUTER ENGINEERING DISTINGUISHED LECTURE SERIES 1997-1998 Murray Campbell IBM Deep Blue: The IBM Chess Machine Wednesday, Sept. 24, 1997 1:00 PM Host: Steven Minton Today on the mbone (we hope). Join us on USCLectureSeries now being advertised in sdr. Sorry for the late notice. I will try to get these out earlier for future seminars. (FYI Upcoming events in the series) Butler Lampson Microsoft Title: (to be announced) Wednesday, Nov. 19, 1997, 12 noon Host: Deborah Estrin Ernest S. Kuh University of California at Berkeley Interconnect modeling and simulation for deep-submicron design Wednesday, January 28, 1998, 12 noon Host: Massoud Pedram Yale Patt University of Michigan The Microprocessor of the Year 2008 Thursday, February 19, 1998, 12 noon Host: Jean-Luc Gaudiot Barbara Grosz Harvard University Title: (To be announced) Thursday, March 19, 12 noon Host: Milind Tambe David Dill Stanford University Towards Formal Verification of Microprocessor Designs Wednesday, April 29, 12 noon Host: Peter Beerel NOTE: we also have a more or less regular wed noon seminar approximately three times a month which we also plan to mbone. Next week Wed Oct 1, 12 noon, Vern Paxson will be speaking From rem-conf Wed Sep 24 10:31:43 1997 From rem-conf-request@es.net Wed Sep 24 10:31:42 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xDvC4-000375-00; Wed, 24 Sep 1997 10:25:44 -0700 Date: Wed, 24 Sep 1997 10:00:29 -0700 X-Sender: alagu@mail.apple.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rem-conf@es.net From: Alagu Periyannan Subject: Re: Minutes of Munich AVT meeting X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 11:52 PM -0700 9/22/97, Stephen Casner wrote: > > >4. New RTP payload format proposals > >It is expected that additional payload formats for RTP will continue >to be developed as new encodings are developed and as RTP is employed >in new applications. At this meeting, new payload formats were >introduced for H.263+, MPEG4, BT-656 and QuickTime video, and DTMF >tone signalling in audio. In addition, "meta" payload formats that >specify methods for repair of packet losses were discussed, including >the question of how much error correction is appropriate. > Hi all, I would like to point put that the QuickTime payload format covers not just video but all the QuickTime track types. This includes audio, video, text, MIDI, etc. --------------------------------------------------- Alagu Periyannan alagu@apple.com Interactive Multimedia Group Apple Computer, Inc. From rem-conf Thu Sep 25 05:45:30 1997 From rem-conf-request@es.net Thu Sep 25 05:45:29 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xED4Q-0006jc-00; Thu, 25 Sep 1997 05:31:02 -0700 Date: Thu, 25 Sep 1997 14:30:06 +0200 From: wangd@sebb.bel.alcatel.be Message-Id: <199709251230.OAA26892@btmplq.god.bel.alcatel.be> To: rem-conf@es.net Subject: How to attend multicast meeting? X-Sun-Charset: US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, I have a SUN workstation connected to Internet. I also downloaded "vat", and ran "vat" in our LAN, it works. Now I have following questions: Can I attend multicast meetings? and how? What else do I need? My workstation does not have a video card, can I run "vic" to receive and play video session information? Thanks! David Wang e-mail: wangd@sebb.bel.alcatel.be From rem-conf Thu Sep 25 10:52:12 1997 From rem-conf-request@es.net Thu Sep 25 10:52:11 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xEHzC-0001O0-00; Thu, 25 Sep 1997 10:45:58 -0700 Message-Id: <199709251744.NAA01983@surfcity.research.att.com> From: "Glenn L. Cash" To: Subject: RTP JPEG payload and interlaced video Date: Thu, 25 Sep 1997 13:40:19 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Has anyone tried to use RFC2035 for JPEG payloads with hardware codecs that code/decode 2 fields per frame? If so, how are you indicating which field is contained in the payload? Thanks, Glenn Cash -- Glenn L. Cash AT&T Labs - Research 100 Schulz Drive, Room 3-221, Red Bank, NJ 07701-7033 tel: 732 345 3303 fax: 732 345 3033 E-mail: glenn@research.att.com WWW: http://www.research.att.com/info/glenn From rem-conf Thu Sep 25 17:20:26 1997 From rem-conf-request@es.net Thu Sep 25 17:20:25 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xEO5s-0005uv-00; Thu, 25 Sep 1997 17:17:16 -0700 Message-Id: <199709252348.QAA23152@toaster.parc.xerox.com> X-Mailer: exmh version 2.0zeta 7/24/97 Reply-To: stewart@parc.xerox.com To: "Glenn L. Cash" cc: rem-conf@es.net Subject: Re: RTP JPEG payload and interlaced video In-reply-to: Your message of "Thu, 25 Sep 1997 10:40:19 PDT." <199709251744.NAA01983@surfcity.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Sep 1997 16:47:39 PDT From: Paul Stewart X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list In message <199709251744.NAA01983@surfcity.research.att.com>you write: >Has anyone tried to use RFC2035 for JPEG payloads >with hardware codecs that code/decode 2 fields per >frame? If so, how are you indicating which field is >contained in the payload? In previous versions of the payload specification, there were bits in the type field that specified interlace information, but that was dropped in later revisions. I've recently been meeting with Ron Frederick and Bill Fenner to work out a number of issues related to this standard, so hopefully in an upcoming revision you will be able to specify this sort of information without need for non-standard extensions. I'll post a bit more detail about some of these changes in an upcoming message to rem-conf. -- Paul From rem-conf Thu Sep 25 17:38:29 1997 From rem-conf-request@es.net Thu Sep 25 17:38:28 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xEOOV-0006QZ-00; Thu, 25 Sep 1997 17:36:31 -0700 Message-Id: <199709260035.RAA23344@toaster.parc.xerox.com> X-Mailer: exmh version 2.0zeta 7/24/97 Reply-To: stewart@parc.xerox.com To: rem-conf@es.net Subject: RTP JPEG payload format Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Sep 1997 17:35:26 PDT From: Paul Stewart X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Recently Ron Frederick, Bill Fenner and I have been spending a little time working on some of the issues related to the RTP Payload Format for JPEG-compressed Video (RFC 2035). We'd like to petition the public for their opinions on some of the topics we are addressing. * Interlace support We'd like to one again resurrect a 4:2:2 interlaced video format type. Even and odd video fields can specified using the "Type specific" data field. A separate type can be used for video where only one of the two fields are encoded so that decoders know they need to line double video in order to display the content at the correct aspect ratio. * Restart markers Restart markers as they are currently specified are only partially useful. Firstly, they are a separate type, and as such, cannot be added orthogonally to a additional JPEG types. Secondly, the optional DRI segment is 6 bytes, causing the real payload data not to be 4 byte aligned. In light of these issues, we'd like to move the restart marker information to being a single high order bit in the type field, and encoding both a 16 bit RCOUNT and the 16 bits of pertinent info in a single 4 byte block immediately after the RTP/JPEG header, leaving the "Type specific" data field free for use by the specific format specified in the low order bits of the type field. How many software and hardware codecs currently support types 2-5? * Q-Factor support Allow for a special Q-factor value that specifies that the Q-table is specified at the beginning of the payload data. This can be used with codecs for which the table for the encoder can be queried but cannot be set. -- Paul From rem-conf Thu Sep 25 22:49:47 1997 From rem-conf-request@es.net Thu Sep 25 22:49:46 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xETBq-0000lr-00; Thu, 25 Sep 1997 22:43:46 -0700 Message-Id: <199709260543.BAA28610@east.isi.edu> To: Jim Lowe , rem-conf@es.net Reply-To: mankin@EAST.ISI.EDU Subject: Re: MBONE Event: Deering on IPv6, 9-11 AM EDT, Sep 25 In-reply-to: Your message of Thu, 25 Sep 1997 09:32:51 -0500. <199709251432.JAA21676@miller.cs.uwm.edu> Date: Fri, 26 Sep 1997 01:44:05 EDT From: Allison Mankin X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list This event was taped and as soon as we check that the tape came out ok, we will announce a rebroadcast time. > It looks like part of the mbone was down during this transmission. > I was unable to receive it. Do you know if it was recorded anywhere? From rem-conf Fri Sep 26 00:38:08 1997 From rem-conf-request@es.net Fri Sep 26 00:38:07 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xEUu8-0001jI-00; Fri, 26 Sep 1997 00:33:36 -0700 From: petri.koskelainen@research.nokia.com (Koskelainen Petri NRC/Tre) To: confctrl@isi.edu ('confctrl@isi.edu'), rem-conf@es.net ('rem-conf@es.net') Message-ID: <1997Sep26.102327.1751.1109517@nrchub01he.research.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Fri, 26 Sep 1997 10:35:18 +0200 Subject: SDP syntax fo H.263 options (draft) X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list There is new internet-draft coming out soon describing the SDP syntax for H.263 options and parameters, and their relation to SIP and SAP. For those who can't wait, see it in: http://www.cs.tut.fi/~petkos/draft-koskelainen-sdp263-00.txt We have made most changes suggested by Stephen Casner, except that MaxBitRate is still used since we think that SDP b attribute is not the same as MaxBitRate in SDP H.263 decoder capabilities. Moreover, SIP spec would need minor changes to say that unicast codec / codec options are not always symmetric. To make asymmetric usage possible, it is necessary to define that SDP codecs and codec options are only (advertized) decoder capabilities. Both ends (in INVITE, and its OK reply messages), define their decoders. Current SIP spec is not saying anything about this. -- Petri From rem-conf Fri Sep 26 09:22:01 1997 From rem-conf-request@es.net Fri Sep 26 09:21:59 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xEcxU-0005Hp-00; Fri, 26 Sep 1997 09:09:36 -0700 Message-Id: <342BDEC8.83622A6F@watson.ibm.com> Date: Fri, 26 Sep 1997 12:11:52 -0400 From: Ping Pan Organization: IBM Research Center X-Mailer: Mozilla 4.03 [en] (Win95; U) Mime-Version: 1.0 To: "rem-conf@es.net" Subject: wb for Window'95 and NT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Hi, Where can I find wb for NT or win95? Many thanks! -- Ping Pan pan@watson.ibm.com From rem-conf Fri Sep 26 14:59:56 1997 From rem-conf-request@es.net Fri Sep 26 14:59:55 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xEiKJ-00034O-00; Fri, 26 Sep 1997 14:53:31 -0700 Date: Fri, 26 Sep 1997 16:53:02 -0500 Message-Id: <199709262153.QAA31637@themis.host4u.net> Return-Error: altavista@hispavista.com Reply-to: altavista@hispavista.com From: HiapaVista To: rem-conf@es.net Subject: http://www.hispavista.com/ X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list http://www.hispavista.com/ From rem-conf Fri Sep 26 18:40:53 1997 From rem-conf-request@es.net Fri Sep 26 18:40:51 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xElnD-00051y-00; Fri, 26 Sep 1997 18:35:35 -0700 Message-Id: <3.0.3.32.19970926182838.00cd085c@mail.arc.nasa.gov> X-Sender: mallard@mail.arc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 26 Sep 1997 18:28:38 -0700 To: mankin@EAST.ISI.EDU, Jim Lowe , rem-conf@es.net From: Mark Allard Subject: Re: MBONE Event: Deering on IPv6, 9-11 AM EDT, Sep 25 In-Reply-To: <199709260543.BAA28610@east.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Please restart your tools and try again. Thanks, M At 01:44 AM 9/26/97 EDT, Allison Mankin wrote: >This event was taped and as soon as we check that >the tape came out ok, we will announce a rebroadcast time. > >> It looks like part of the mbone was down during this transmission. >> I was unable to receive it. Do you know if it was recorded anywhere? > > From rem-conf Sat Sep 27 00:16:17 1997 From rem-conf-request@es.net Sat Sep 27 00:16:16 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xEqvA-0007Cq-00; Sat, 27 Sep 1997 00:04:08 -0700 Date: Sat, 27 Sep 1997 00:07:40 -0700 (PDT) From: Stephen Casner To: rem-conf@es.net Subject: Revised AVT Munich minutes Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list I've revised the minutes according to the comments received both on this list and privately. Thanks for the feedback. -- Steve Minutes of the Audio/Video Transport Working Group Reported by Steve Casner 1. Introduction and status The AVT working group had not planned to meet in Munich during a period of dormancy while implementation and testing of RTCP scaling mechanisms was underway. However, in response to several requests, one AVT session was scheduled to discuss a new problem with the RTCP scaling plus open issues for several new payload formats that were submitted since the last meeting. The next goal for AVT is to get RFCs 1889 and 1890, the Real-time Transport Protocol and the companion RTP profile for audio/video conferencing, revised for advancement to Draft Standard by year's end. The profile has been revised in draft-ietf-avt-new-profile-01.txt and .ps. The main RTP specification needs to incorporate RTCP scaling changes that are still being refined; however, an interim first draft of the other revisions, including extensions for layered encodings, should be published as soon as posible. As of the Munich meeting, the RTP payload format for H.263 video had been approved for publication as a Proposed Standard, and the payload format for redundant audio was close to approval. (Since the meeting, both have been published as RFCs 2190 and 2198.) The drafts on compression of IP/UDP/RTP headers and a revision to the RTP payload format for MPEG2 in RFC 2038 have been posted for IESG Last Call before publication as Proposed Standards. 2. RTCP "timer reconsideration" Jonathan Rosenberg gave a brief review of the problem that a flood of RTCP packets can occur if a large number of participants simultaneously join a session. This problem and the solution of RTCP "timer reconsideration" have been discussed at the previous two IETF meetings and are explained in the recently posted Internet-Draft draft-ietf-avt-reconsider-00.ps. However, a concern raised at the last meeting was that the timer reconsideration algorithm exhibits a "plateau effect" wherein no RTCP packets are sent for a period after the algorithm stops the flood. New simulations show that the plateau effect is significantly reduced as the joins are spread out in time and disappears when the join rate is no more than 500 users/sec. Since perfectly synchronized joins are very unlikely, the plateau effect is not considered to be a problem. There is an analogous problem of an RTCP BYE packet flood on simultaneous leaves. Unlike the initial RTCP packets at the time of joining, BYE packets can't be delayed because the application is terminating. Some partial remedies were discussed at the last meeting. The newly discovered problem is a relatively minor one related to the BYE flood: if many participants leave a session at once, other participants that remain in the session may be falsely timed out. Some of the remaining participants will have their RTCP interval expire earlier than others. These participants will reduce their estimate of the number of participant and consequently also reduce their RTCP interval. Since the remaining participants may still have a long time to wait before their previously calculated RTCP interval expires, they might not send any RTCP packets while multiple shorter RTCP intervals elapse for the particpants that have noticed the drop. The long-waiting participants will therefore be timed out (considered inactive) by those that have adjusted to shorter intervals. Even if the BYE flood is slowed to the normal 5% RTCP bandwidth, simulations show that a single missed packet can cause a timeout. An extension to the timer reconsideration algorithm, dubbed "reverse reconsideration", recomputes the RTCP timer whenever the group size estimate decreases (due to a BYE). This significantly reduces the amount of time during which the group size estimate may be wrong, but there is still a problem that the estimate can drop to zero. This problem can be eliminated, as suggested in an INFOCOM97 paper by Sharma, Estrin, Floyd and Jacobson on a similar problem, using a filter to slow the rate of decrease of the estimate. Further analysis to determine the right kind of filter is underway. Jon Crowcroft suggested keeping a bit of history from interval to interval and continuously estimating the group size to use as a predictor. However, a predictor might not work well with unexpected sharp transitions in group size. He also suggested that the BYE flood might be managed by having participants send BYEs with a limited scope and then having the participants that remain act as proxies to retransmit the BYEs spread out in time. A proxy election protocol would be needed. This starts to get pretty complicated. Dave Oran suggested that there could be a server thread that takes responsibility for sending a delayed BYE after the application is closed, just as TCP implementations must save some state when a connection closes to shut down gracefully. Steve Casner responded that if some implementations can do this, great, but we can't assume all will. Similarly, it is important to note that although we want to define a timer reconsideration algorithm to go in the appendix of the RTP spec, different implementations can implement different timer reconsideration algorithms and the whole system will still work. The group was asked if there were any objections to the proposal to add the timer reconsideration algorithm to the RTP spec. There were none. 2.1 Large-scale tests of the RTCP scaling mechanisms The timer reconsideration algorithm has been simulated, but we would have more confidence if it was tested on a large scale with real implementations. If that is not practical, testing on a large-scale simulation/emulation testbed network would be a good backup for the initial simulations. The audience was queried about any planned tests, but no plans were reported at this time. Jonthan Rosenberg is implementing a test program called rtpbomb that can emulate a large number of participants. It may be used in combination real participants to test timer reconsideration and other aspects of RTCP scaling. His analysis suggests that most of the phenomena in the algorithm are linear with group size, so a smaller test should still be useful to predict behavior of a larger group. 3. Other RTP Issues/Questions Steve Casner brought up three other issues for the group to consider, but there were few comments: - During the discussion of the global multicast address allocation scheme in MBONED working group, Van Jacobson asserted that applications should not depend upon sequential multicast addresses being allocated for multiple groups carrying the different layers of a layered coding scheme. The layered encoding extension to RTP proposed by Speer and McCanne does assume sequential addresses, so a revision may be necessary. - AVT has received a Request for Proposals from the DAVIC group. It would be difficult for the group as a whole to respond, but individual participants are invited to do so. - Should AVT set a policy of allocating no more static payload types such that dynamic payload types should be used instead? Scott Petrack responded to the last point to say that we should consider none of the assigned payload types to be static, but rather default assignments. When a session control protocol is in use, if there is a need for more than the 32 dynamic payload types already set aside, the default values could be reassigned. The group seemed to be in general agreement with this proposal, but it should be discussed on the mailing list as well. 4. New RTP payload format proposals It is expected that additional payload formats for RTP will continue to be developed as new encodings are developed and as RTP is employed in new applications. At this meeting, payload formats were introduced for H.263+ and BT-656 video, MPEG4 and QuickTime multimedia, and DTMF tone signalling in audio. In addition, "meta" payload formats that specify methods for repair of packet losses were discussed, including the question of how much error correction is appropriate. 4.1 H.263+ video payload format As noted in the introduction, the payload format specification for H.263 video has been published as a Proposed Standard. However, enhancement of the encoding itself continues under the label H.263+ for improved loss resilience and to utilize increased processing power to achieve higher quality. As agreed in previous AVT meetings, a separate RTP payload format is to be devised to support the enhanced encoding. In fact, two different approaches were proposed in draft payload format specifications sent to the AVT mailing list just before the meeting. Stephan Wenger, who is the primary author of one and a co-author on the other, gave an overview of the H.263+ encoding enhancements and the tradeoffs between the two payload formats. The first approach, from TU-Berlin and U-Bremen, uses a very simple payload header but includes the H.263+ picture header in each packet except for "follow-on packets" when app-level fragmentation is done. This allows for the use of almost all of the optional modes defined in the H.263+ encoding scheme. The second approach, from Intel, follows more the design of the existing H.263 payload format in which selected fields from the picture header are incorporated into a set of payload format headers for different modes. This approach reduces overhead to support small packet sizes but precludes use of some encoding options deemed to be rarely used. Wenger stated the intention of the authors of both approaches to resolve the differences and produce one merged proposal. He suggested that the merged proposal might include both approaches. Steve Casner countered that this might not be a good result because it increases complexity and reduces interoperability -- putting in all the options when a decision can't be made is often the result of a committee design. Christian Huitema commented that some encoding functions were left out when the H.261 payload format was designed because they were not applicable to packet transport, and asked if a similar analysis could be made here. Wenger replied that H.263+ has been designed to work with packet loss and that some of the optional modes were added expressly to deal with packet loss. Wenger requested input soon from the working group regarding the tradeoffs between the two approaches because the recommendations for mode combinations to use are being prepared now by the ad-hoc group he leads. The two specifications should be posted as Internet-Drafts for wider exposure. 4.2 MPEG4 payload format There is no draft payload format specification for MPEG4 yet because Gerard Fernando would like feedback on some design questions first. He gave a brief overview of the scope and structure of MPEG4, which is a framework for integrating different kinds of natural and synthetic media streams built around audio/visual objects called AVIOs. There are two primary questions: - How can MPEG4 payload format refer to existing and forthcoming payload formats for the encodings of individual media streams (AVIOs) rather than trying to redo them all? - How should the "scene description data", which composes the individual AVIOs into the complete presentation, be transmitted? If this data is lost, the whole scene is lost, so adequate loss resilience mechanisms must be employed. Can the scene description data be decomposed over both time and "space" -- time because a transmission may be joined after the start, and space because media are sent in separate streams and some receivers might not tune into all of them? MPEG4 is still being developed, with standardization due in January 1999. The MPEG4 committee would like to work with AVT to ensure that packetization considerations are included in the design; they view RTP/UDP multiplexing as an appropriate means of multiplexing elementary streams. This is clearly beneficial from AVT's point of view as well. One aspect of the use of separate media streams in RTP is the ability to apply different network QoS and reliability mechanisms as needed; the VMIF part of MPEG4 is trying to formalize the selection of stream-specific QoS in a transport-independent and network-independent way. Fernando and Casner are to explore what formal or informal liaison procedures should be followed in this case, both for information transfer and to enable reference to RTP in the MPEG4 specification. 4.3 BT-656 video payload format Dermot Tynan presented a proposal, draft-tynan-rtp-bt656-00.txt, for carrying ITU-R BT.656-3 uncompressed video over RTP. BT656 is studio-quality digital video sampled according to BT.601-5 (formerly CCIR601) at 13.5 or 18 MHz. At the normal, lower rate, each scan line contains 720 samples occupying 1440 bytes in the 4:2:2 chrominance encoding. At the "high definition" rate, each line contains 1144 samples for NTSC or 1152 samples for PAL. The payload format consists of a simple header with bit fields to indicate NTSC/PAL, sampling rate, framing and scan line information, followed by one scan line of samples. Steve Casner expressed the concern that the packet size might exceed the MTU for some networks. Although at the lower sampling rate an IP/UDP/RTP packet will fit within a 1500-byte MTU, at the higher sampling it would not. Don Hoffman pointed out that if the packet size does exceed the MTU such that IP fragmentation occurs, integrated services packet classification won't work on fragments other than the first so those packets won't get the desired QoS. Christian Huitema claimed it is important to have application-level fragmentation so that services such as forward error correction will apply when a fragment is lost. It should not cost much to be able to indicate that a packet contained part of a scan line, perhaps by giving the starting sample number. Tynan agreed to consider this addition. 4.4 QuickTime payload format Alagu Periyannan just asked to call the working group's attention to the recently posted draft "RTP Payload Format for QuickTime Media Streams", draft-ietf-avt-qt-rtp-00.txt, and in particular to the list of open issues in section 4 of that draft. The motivation in developing this format was to carry all the payloads in QuickTime without having to define an RTP payload format for each. Steve Casner pointed out that the tradeoff of this technique is that there is some amount of additional constant description info that must be carried in each packet but would not be needed with separate formats. Philipp Hoschka asked if it wouldn't be better to define individual payload formats because the encodings might also be used outside of QuickTime as well. Periyannan replied that where individual payload formats are defined, they should be used in preference to this format. However, several of the encodings used with QuickTime are not standardized, such as Apple Video, Cinepak, and several proprietary codecs. 4.5 DTMF audio payload format Jonathan Rosenberg presented Henning Schulzrinne's proposed audio payload format to carry DTMF (tone dialing) signals as defined in draft-ietf-avt-dtmf-00.txt and .ps. This payload format might be used for calling across the Internet through IP telephony gateways to control an answering machine or other device. Low data rate speech codecs may not reproduce the DTMF tones faithfully enough to work properly at the far end. This payload format essentially provides a very low rate encoding specialized for DTMF tones. The draft defines a primary format in which each DTMF digit is represented by 32 bits to control frequency, amplitude and duration. Redundancy can be provided using the mechanism specified in RFC 2198. This introduces 64 bits of overhead, but the data rate is so low that this probably does not matter. Alternatively, a more compact representation of each digit would allow adding redundancy within the DTMF payload format and still fitting each digit into 32 bits. The selection between these techniques is an open issue on which input >from the working group is sought. Steve Casner noted that the more compact format would require the RTP clock rate to be different than that of the normal audio payload format within which the DTMF packets are interspersed, and suggested that this is a significant enough disadvantage to prefer the larger format. Scott Petrack agreed that the size difference was probably not significant. 4.6 Forward Error Correction payload format Two "meta" payload formats on forward error correction (that is, independent of media type and format) have recently been posted: draft-budge-media-error-correction-00.txt by Budge, et al., and draft-ietf-avt-fec-00.txt by Rosenberg and Schulzrinne. The authors of the first draft did not attend, but Jonathan Rosenberg presented the second draft which builds on ideas from the first, and compared the two drafts. Both schemes are based on the idea of sending additional FEC packets which are the XOR of multiple packets from the original packet stream. It should be noted that the scheme presented by Rosenberg differs from that described in the second draft. An RTP header extension (X bit) is no longer used; instead, the payload type is changed to indicate an FEC packet, and an additional format-specific header is inserted before the XOR of the covered payloads, as in the Budge scheme. One drawback of the Budge draft was that the timestamp and marker bit of lost packets could not always be recovered. The proposed remedy is for these fields in the FEC packets to be the XOR of the corresponding fields from the original packets covered by the FEC packet. This has its own drawback that the timestamp will vary erratically, perturbing the jitter feedback calculation unless the FEC packets are excluded. Carsten Bormann also pointed out that when RTP header fields are perturbed from their usual increments, it can have a negative impact on the efficiency of RTP header compression. A second drawback of the Budge scheme was that the payload type was changed in the original packets to be the FEC payload type which means that a receivers without FEC capability could not receive just the original packets and ignore the FEC packets. In Rosenberg's scheme, the original packets are unmodified, including the payload type. To extend the range of packet patterns that could be covered by an FEC without having to predefine specific scemes, Rosenberg proposes to carry a bit mask to indicate the pattern explicitly. The RTP sequence number of FEC packets in Rosenberg's proposal is the minimum of the sequence numbers of the packets covered by the FEC to serve as a base for the mask. Steve Casner claimed that this is not acceptable because it will prevent the FEC packets from passing header validation and duplicate suppression algorithms in RTP packet processing. Rosenberg said alternative sequence number schemes had been considered, but the cost is additional overhead. Christian Huitema argued that if a general FEC payload format is to be defined, it should support other schemes with better performance and only a marginal increase in complexity compared to that of "n+1" schemes like XOR. For example, it is possible to specify a scheme that adds two FEC packets to eight original packets which will allow recovery from a loss of any two of the ten packets. This is important because simulations have shown that one packet of redundancy was not enough. Rosenberg agreed that the FEC proposals need further refinement. 4.7 Applicability of error correction In addition to the redundant audio and FEC payload formats already mentioned, retransmission and interleaving are two more loss resilience schemes that might be employed with RTP. Colin Perkins reviewed these four methods to compare the tradeoffs in latency, bandwidth overhead and processing overhead (details are available at http://www.cs.ucl.ac.uk/staff/c.perkins/slides/). It is an important question to consider when these schemes are applicable to particular applications or to particular network conditions. Colin presented some network loss statistics showing that single packet losses predominated by a factor of four over two-packet loss bursts. The probability drops rapidly such that long burst losses are rare. On the other hand, in a large conference, most packets will be lost by at least one receiver, therefore a retransmission scheme may need to resend almost every packet. The redundant transmission scheme has low latency and low bandwidth overhead, but potentially high processor overhead if the low-rate redundant encoding is computationally complex. A retransmission scheme is likely to impose much longer delay and will incur the overhead of control traffic in addition to the duplicate data, but provides exact repair and can correct more than single-packet losses. There is a synergy between redundancy and retransmission in that redundancy can cover most of the errors, leaving retransmission to pick up the remainder for those receivers that care more about low loss than low delay. Interleaving disperses the effects of loss, but does not eliminate them. It has low overhead, but high latency. FEC may have a similarly high latency or a high bandwidth overhead, depending on the size of the pattern covered, but its major advantage is media and format independence. For interactive applications, either redundant transmission or a low-latency FEC would seem most suitable, while for broadcast-style applications interleaving works well. An important open question is what constitutes a sensible operating point for real-time media transmission? How much loss should applications try to cope with before declaring that the user should try again at some less congested time? There is little congestion control in many real-time media applications, and extreme loss resilience measures would just worsen congestion. That would not be network friendly. If fair congestion avoidance mechanisms are deployed in routers, then applications that don't implement congestion control may be penalized. Therefore, any loss resilience schemes that are defined for RTP should consider not just loss performance but also impact on the network. 5. Revision of RTP MIB specification The final topic of the meeting was an update by Mark Baugher on the RTP MIB design and implementation plans. An interim draft of the MIB was sent to the mailing list before the meeting to provide an opportunity for feedback; a real Internet-Draft will be posted in October. A more complete description of the MIB was given in Memphis; the changes since then were to fix errors identified by Fred Baker in his review of the MIB, to add reporting of receiver feedback, to support RTP operation over different underlying protocols, and to remove from the specification those parts that won't be included in initial implementions and hence won't be validated yet. In particular, support for RTP translators was removed. Receiver feedback is reported through additional tables that are created only upon request from the network manager as a side-effect of creating an entry in the Session Table. This avoids the state explosion that might occur if all receiver feedback was always monitored for all sessions. There are a few details remaining to be worked out, but implementation of a network management application using the RTP MIB is underway to evaluate how well this MIB works for managing real-time applications on networks that weren't designed for them. To make this really workable, the management application needs to handle multicast routing in addition to RTP. The next stage of MIB development will be based on the results of the implementation. 6. Next meeting Steve Casner closed the meeting saying that AVT will meet again at the next IETF in December. As stated above, a goal for the working group is to get the RTP spec revised for Draft Standard by then. In addition, there is outstanding work on several topics presented at this meeting which should be discussed on the mailing list so that completed drafts are ready by the next meeting. From rem-conf Sat Sep 27 02:02:38 1997 From rem-conf-request@es.net Sat Sep 27 02:02:38 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xEshA-0000HS-00; Sat, 27 Sep 1997 01:57:48 -0700 Date: Sat, 27 Sep 1997 01:34:20 -0700 (PDT) From: 1million@uhes4a.net To: Friends@onthe.net Subject: $250 per million for Bulk Email Reply-To: 1million@250.net X-PMFLAGS: 20720340.50 X-UIDL: 20720340_201230.501 Comments: Authenticated Sender is <1million@250.net> Message-Id: <1072117_63763076> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list LET US DO YOUR BULK MAILINGS!!! ...$250 PER MILLION ...$150 PER 500,000 THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS Our company will do bulk emailing for your product/service. Addresses are extracted daily by four of our computers, which run 24 hours a day 7 days a week, scanning the net for new addresses. They are fresh! Over 30 million addresses on file. Our prices start at $150 per 1/2 million mailed. No more than 2 pages (50 lines), no porn and no foul language. We do not do targeted mailings at this price. There are no lower prices on the net. Your mailing can be done in a matter of hours. We have 6 computers sending and processing messages. 4 more computers extracting addresses 24/7. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts office at 904-282-0945, Monday - Friday 9 - 5 EST. Large corporate mailings available - ask for details. Email addresses available on CD, zipped text files. If interested, let our office know and will send our daily extracted list for only $250. Available on CD are over 30 million for ONLY $250. Overnight delivery $14, priority $5 and regular mail $3. New addresses are added daily. All domains available. No .edu,.mil and .gov. domains. Addresses are processed to remove any key names and flamers, who have notified our company and/or clients. $100 extra insures you of new addresses extracted up to 6 months. To have your name removed, call our processing office. Any negative responses will be dealt with accordingly. From rem-conf Sun Sep 28 20:33:40 1997 From rem-conf-request@es.net Sun Sep 28 20:33:38 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xFWKN-00036I-00; Sun, 28 Sep 1997 20:16:55 -0700 Date: Sun, 28 Sep 1997 19:51:42 -0700 (PDT) From: 1j14@1j14mv.net To: Friends@onthe.net Subject: BANK OFFSHORE !!! Reply-To: offshore@bank.net X-PMFLAGS: 20720340.50 X-UIDL: 20720340_201230.501 Comments: Authenticated Sender is Message-Id: <29875554_80222509> X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list From rem-conf Mon Sep 29 06:06:03 1997 From rem-conf-request@es.net Mon Sep 29 06:06:03 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xFfNo-0005tD-00; Mon, 29 Sep 1997 05:57:04 -0700 Message-Id: X-Mailer: exmh version 1.6.9 8/22/96 To: rem-conf@es.net, confctrl@ISI.EDU Subject: Any RTP RTSP libraries available? Organisation: Multi-media group, CWI, Kruislaan 413, Amsterdam Phone: +31 20 5924098(work), +31 20 5924199 (fax), +31 20 6160335(home) X-Last-Band-Seen: Dead Moon, Brotherhood Foundation (Melkweg, 28-9) X-Mini-Review: DM were a revelation, charming trashy sixtiespunk Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Sep 1997 14:55:19 +0200 From: Jack Jansen X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list Does anyone know of libraries to handle the RTP and RTSP protocols? I've come across PN's RTSP package, but the architecture of that is rather integrated and I would prefer something that was designed as a library to drop into other applications. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From rem-conf Mon Sep 29 09:37:37 1997 From rem-conf-request@es.net Mon Sep 29 09:37:36 1997 Received: from list by mail1.es.net with local (Exim 1.71 #1) id 0xFidf-0000Ho-00; Mon, 29 Sep 1997 09:25:39 -0700 Message-Id: <3.0.3.32.19970929092530.013711bc@mail.real.com> X-Sender: robla@mail.real.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 29 Sep 1997 09:25:30 -0700 To: Jack Jansen , rem-conf@es.net, confctrl@ISI.EDU From: Rob Lanphier Subject: Re: Any RTP RTSP libraries available? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailing-List: X-Loop: rem-conf@es.net Precedence: list At 02:55 PM 9/29/97 +0200, Jack Jansen wrote: >Does anyone know of libraries to handle the RTP and RTSP protocols? I've come >across PN's RTSP package, but the architecture of that is rather integrated >and I would prefer something that was designed as a library to drop into other >applications. Just to make things clear, RealNetworks (formerly Progresive Networks, "formerly" being 4 days ago) offers two different implementations of RTSP. The RTSP Reference kit was released pretty early on in the standardization of RTSP primarily as a test bed, and has the properties you describe. The RealMedia SDK, released for developer beta earlier this year, is also an implementation of RTSP, and is available for free download now. It's much more modular than the RTSP reference, and has a lot more features. The downside is that it doesn't include source code, and that the redistribution licensing is slightly trickier (but we are a pretty reasonable bunch of folks to work with, IMHO :). It also may not give you the exact entry point into the system that you want. For example, you can create new datatypes and file formats, and it has hooks for adding new headers on the DESCRIBE message, but doesn't allow you "down to the metal" access to RTSP. Other than that, it's a complete system, and is where we are putting the bulk of our engineering effort (and have for the past year), so it's very well-designed and is only going to get better. A lot of our efforts have been geared squarely at folks making tools (such as yourselves), so I think it's worth looking at. Rob --- Rob Lanphier (robla@real.com) Voice: (206)674-2322 Fax: (206)674-2699 RealNetworks: http://www.real.com RTSP Info: http://www.real.com/rtsp Firewall Info: http://www.real.com/help/firewall